1.3 自动化测试实施三要素
1.3.1 有明确的目标
做事情如果没有目标，那就是盲目的、随意的，做自动化测试也是如此。下面分别举例说明如何制定提高软件质量和测试效率的目标。
1．制定提高软件质量的目标
以缺陷遗漏率为例。表1-1为某项目的线上缺陷分析情况。
表1-1
从表1-1可以看出，后端逻辑的线上缺陷数最高，如果能降低后端逻辑的线上缺陷数，则可有效降低缺陷遗漏率（缺陷遗漏率=线上缺陷数/缺陷总数×100%）。
如果采用接口自动化测试来覆盖后端逻辑，实现50%的接口逻辑全覆盖，那么理论上线上缺陷数将减少一半，即降低为11个，最后可算出缺陷遗漏率为3.56%。此时提高软件质量的目标定为4%比较合适，毕竟真正做到“逻辑全覆盖”是很难的。
2．制定提高测试效率的目标
以回归测试效率为例。假设某项目的界面自动化用例约为1500个，项目迭代周期为半个月，平均每个迭代周期内需要做两轮回归测试，手工用例执行效率为100个/人/天。自动化测试用例采用5台执行机并发执行，开发提交测试的当天晚上配置好5台执行机开始执行，第二天花1人/天即可分析完成。但每次迭代完成后，需要花费约2人/天做自动化测试用例的维护，如表1-2所示。
表1-2
通过表1-2可以看出，自动化测试明显节省了人力。下面计算对回归测试效率的提高（以每迭代为例）：
(30-4)/4×100%=650%
也就是说，当自动化用例数为1500个时，回归测试效率是原来的6.5倍（即650%），不过有两点需要说明。
（1）前期投入
这1500个自动化用例的编写大约需要一年时间，平均每个工作日投入人力为2人，按一年250个工作日计算，投入人力为500人/天，即一天一个人实现3条自动化测试用例。
（2）维护成本
每迭代只需花费2人/天做自动化测试用例的维护，可以看出项目界面变更并不频繁。如果项目界面变更很频繁，则势必要增加维护成本。
通过这个例子可以看出，在做自动化测试之前，需要计算项目的回归测试用例数、前期投入和维护成本，才能得出真正提高测试效率的目标。对于界面变更很频繁的项目，做界面自动化测试甚至比手工测试投入的人力更多，对于这种项目，必须果断放弃界面自动化测试。笔者就经历过很多这样的项目。
1.3.2 有足够的资源
当目标明确以后，就初步确认了需要做哪种类型的自动化测试，以及待实现自动化的手工用例数量（工作量）。接下来还要做一件事情，即申请资源。
1．人力资源
根据测试人员水平的不同，可以做不同程度的自动化，理想情况需要至少一位测试开发工程师和一位自动化测试工程师，其他参与者为普通测试工程师。
测试开发工程师：负责自动化测试整体框架的维护，做必要的扩展开发。
自动化测试工程师：负责底层函数封装，供自动化测试用例组装时直接调用。
普通测试工程师：组装、调试、执行、维护自动化测试用例。
2．硬件资源
（1）被测系统
被测系统（System Under Test，SUT）需要的服务器数量需要明确，同时服务器的操作系统版本、CPU大小、内存大小和磁盘大小同样需要确定下来。
（2）自动化测试基础框架
自动化测试基础框架包含CI/CD服务器、执行机、SVN/Git服务器和私服等。这些同样需要明确操作系统版本、CPU大小、内存大小和磁盘大小。
1.3.3 有合理的计划
计划不是万能的，但没有计划是万万不能的。计划一般分为短期计划和长期计划两种。以采用关键字驱动的界面自动化为例。
1．短期计划
有目标、任务项、完成时间、责任人，另外还需要明确反馈机制，即反馈频率和反馈内容。反馈频率一般按周反馈比较合适，具体可根据实际情况制定。反馈内容包括公共关键字数、业务关键字数、自动化用例数、自动化率等。对测试开发人员来说，还可以将代码行数加入反馈内容。
2．长期计划
长期计划比较粗糙，且不确认因素较多，主要展示自动化测试的潜力。
表1-3为自动化测试计划示例。
表1-3
任务项说明如下。
（1）界面自动化测试工具（框架）调研
在确定要做哪种类型的自动化测试后就可以对工具（框架）进行选型，即使之前有成熟的案例，由于新工具（框架）的不断涌现，在实施自动化测试之前也有必要再对比一下。
（2）自动化测试基础框架搭建（CI、执行机等）
资源申请下来后，需要对自动化测试基础框架进行搭建，包括CI、执行机、SVN/Git服务器和私服等。CI一般使用Jenkins、TeamCity和Bamboo等。Web测试执行机一般用Windows系统的电脑，App测试执行机还需要用到macOS系统的电脑及Android/iOS手机。SVN/Git服务器和私服一般用Linux搭建。
（3）SUT搭建
首先搭建数据库、缓存、MQ和应用服务器等基础组件，搭建完成后，再将项目部署到新的环境上。这个过程通常需要开发人员配合修改一些必要的配置文件。
（4）Demo开发及演示
基于自动化测试基础框架及SUT编写Demo，Demo用于演示技术上的可行性。
（5）自动化测试用例开发流程及标准制定
“不以规矩，不能成方圆”，自动化测试用例的开发必须要有相应的流程和标准来作为指导和约束。流程可参考图1-1。
图1-1
对于标准，这里只介绍几个核心点。
①用例之间必须解耦。
解耦的目的主要是为了方便维护，以及执行时不相互影响。具体可理解为用例A不依赖用例B，也不影响用例C。
②测试用例与测试数据分离。
方便分别维护逻辑（用例）和输入（数据）。
③手工测试环境与自动化测试环境分离。
避免手工测试与自动化测试相互影响。
④执行策略与执行任务分离。
执行策略包括定时执行、延时执行、周期执行、执行的用例级别等，与具体业务无关。执行策略和执行任务的关系类似于公共关键字和业务关键字的关系。
（6）公共关键字实现
公共关键字与具体业务无关，可在所有项目中复用。
（7）业务关键字与自动化测试用例实现
业务关键字与具体业务有关，仅可在一个或少数项目中复用。自动化测试用例的实现同时依靠公共关键字和业务关键字。
（8）P0级别界面自动化持续维护
第一阶段实现的自动化测试用例必须持续维护，不然容易“荒废”，因此在第二阶段必然会维护第一阶段实现的自动化测试用例。
（9）实现P0/P1级别接口自动化
敏捷大师Mike Cohn提出了测试金字塔，如图1-2所示，主要思想是多做底层的测试，少做上层的测试，因为底层测试收益高，上层测试收益低。因此界面自动化测试不宜过多投入，精力应该下放到服务层和单元层。所以在第二阶段将接口自动化测试的实现范围扩展到了P0/P1级别。
图1-2
（10）Mock测试接入
Mock测试在单元测试中非常常见，另外，在对接第三方服务时往往需要先使用Mock测试对内部功能测试完成后，再对接第三方服务联测。
（11）代码覆盖率接入
代码覆盖率是软件质量的度量标准之一，因此非常有必要把代码覆盖率工具（框架）和自动化测试进行整合。