这是《落叶》文集里第 179 片落叶，希望你能喜欢，不为别的，只为这份坚持。
【背景】
请教：如何更好的制定自动化计划？组里框架用的是 selenium，maven，testNG。
自动化开发流程: 在功能测试设计下个 release 的新需求时，开发上个 release 的测试用例，使其自动化用于今后的回归测试。目前遇到的问题是 每次新的 release 总会有些改动，比如前台的改动，新需求改变了之前的某些功能块，等等。这些会影响之前的自动化代码，并且这些内容是不容易提前预知的。
如何在制定自动化计划时更有效的制定自动化开发的策略呢？
【你问】
如何有效地制定自动化开发策略？
【我答】
我们一般会把自动化测试分为三层：
由外到内划分为：
第一：UI 层
第二：接口层
第三：单元层
按性价比由高到低排序：
第一：接口层
第二：单元层
第三：UI 层
这里说的性价比，是从好几个维度综合考量的，比如需求改动频率、测试人员投入成本、后期的脚本维护量等等。
所以，建议在产品初期变化相对频繁的阶段，测试人员应该把精力放在接口层的自动化测试开发上，UI 层上投入太多的精力和时间，回报其实并不高，单元层因为门槛略高，所以需要结合测试团队的技术储备来决定在什么时期投入比较好。
最后，再简单说下我对自动化开发的一些基本策略：
1、框架/工具开发者角度：
a. 易用性：让测试工程师能较为方便地使用该框架编写测试脚本；
b. 低门槛：让测试工程师不需要具备太多的开发知识就能使用该框架；
c. 稳定性：保证框架运行时的稳定，避免很多因为运行不稳定而产生的不必要问题排查；
d. 效率：框架的执行效率，不过如果不是特别的缓慢，也可以忽略不计；
2、脚本编写者角度：
a. 高效率：如何才能让脚本编写的工作变得简单高效；
b. 灵活性：如何才能降低脚本编写的依赖性，比如减少对框架开发者的依赖，或者是被测对象开发进度的依赖；
c. 封闭性：也可以称之为约束性，从而提高测试脚本后期的可维护性；
3、用户角度：
a. 运行环境和数据环境分离：可以灵活选择脚本的运行环境，包括准备数据的脚本和运行时的脚本；
b. 直观性：通过简单的交互形式去选择所需要的测试脚本、测试环境，能直观的看到 TA Job 的状态，脚本执行完之后也能方便快捷地查看结果报告；
c. 数据化：手工用例的自动化覆盖率、脚本执行结果、错误日志等都要经过处理形成相应 Job 的 TA 数据；
4、被测对象角度：
a. 业务流：能够快速检查被测对象的业务流程是否存在 Block 问题；
b. 逻辑检查：能选择针对具体的功能模块逻辑点进行测试；
c. 页面巡检：能 Schedule 定期执行的巡检脚本 Job，目的即检查现网的服务是否都正常运行中；
5、测试脚本角度：
a. 设计模式：Object MAP + Keywords，对象属性和通用操作的封装；
b. 底层驱动：Driver Level，即同一套测试脚本，运行时可调用相应的 Android 和 iOS 底层驱动分别解释执行；
c. 分发运行：脚本执行时可以根据选择的测试机，分发对应的脚本到指定的机器；
《测试路上你问我答》里的 Q&A 37，如果是你要的，甚好！如果不是，你问，我答！
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
