1.2 自动化测试的目的

1.2.1 提高软件质量

既然谈到软件质量，那么就有必要了解一下软件质量的度量标准。

1．需求覆盖率

需求覆盖率更多的是从产品经理的角度出发，统计产品需求文档中的需求被覆盖了多少，从而计算出需求覆盖率：

需求覆盖率=测试覆盖的需求数/需求总数×100%

2．代码覆盖率

开发人员可能更关心代码覆盖率。代码覆盖方式有很多种，下面举例说明。

有一个名为demo的Java方法如下：

（1）语句覆盖

语句覆盖的原则是覆盖每条语句，针对demo方法，一条测试用例即可完成覆盖：

Case 1：a=true，b=true，c=true，d=false

（2）分支（判定）覆盖

语句覆盖并没有考虑if语句为假（false）的情况，显然测试并不充分。分支（判定）覆盖可以解决这个问题。采用分支（判定）覆盖重写的测试用例如下：

（3）条件覆盖

分支（判定）覆盖看似比语句覆盖更加完美，但分支（判定）覆盖并没有考虑每个条件的每个取值（即a、b、c、d均可以取true或false两个值）。条件覆盖能覆盖到每个条件的每个取值，采用条件覆盖重写的测试用例如下：

（4）分支（判定）—条件覆盖

如果能同时满足分支（判定）覆盖和条件覆盖就更好了，而分支（判定）—条件覆盖就能做到，采用分支（判定）—条件覆盖重写的测试用例如下：

（5）条件组合覆盖

条件组合覆盖考虑的是覆盖每个分支（判定）中每个条件的每种组合，采用条件覆盖重写的测试用例如下：

下面对这4条测试用例进行详细解释：

若a&&b为true，那么a=true，b=true。

若a&&b为false，那么a=true，b=false；或a=false，b=true；或a=false，b=false。

若c&&d为true，那么c=true，d=true；或c=true，d=false；或c=false，d=true。

若c&&d为false，那么c=false，d=false。

（6）路径覆盖

路径覆盖的原则是覆盖所有路径，针对demo方法，共包含4条路径：

a&&b为true，同时c&&d为true。

a&&b为true，同时c&&d为false。

a&&b为false，同时c&&d为true。

a&&b为false，同时c&&d为false。

对应测试用例如下：

如何计算代码覆盖率呢？以路径覆盖为例，假如执行了Case 1，那么路径覆盖率为25%（即1/4×100%）。

关于代码覆盖的更多内容，参见本书第12章。

3．缺陷遗漏率

在软件质量的度量标准中，关于缺陷的不在少数，比如缺陷遗漏率、缺陷修复率、缺陷遗留率和严重缺陷率等。笔者见得最多的是缺陷遗漏率，正所谓“玉瓷之石，金刚试之”，软件质量好不好，用户说了算。当缺陷太多时，说明软件质量仍有很大的提升空间。

缺陷遗漏率=线上缺陷数/缺陷总数×100%

缺陷遗漏率不仅是软件质量的度量标准，也是测试人员考核的硬指标之一。

从软件质量的度量标准中无法看出自动化测试是如何提高质量的，下面举例说明。

假设某软件频繁地进行回归测试，测试人员已经身心疲惫，难以保证每次回归测试的质量，这时如果使用自动化测试代替测试人员进行回归测试，那么回归测试的质量就能得到很好的保证（机器是不知疲倦的），从而减少线上缺陷数，降低缺陷遗漏率。

1.2.2 提高测试效率

可能很多人认为：手工测试执行的用例由自动化测试代替，测试效率的提高显而易见。

但事实上不能如此片面地下结论，原因如下。

（1）自动化测试用例的编写和维护效率远低于手工测试用例

自动化测试用例一天只有几条的产出，而手工测试用例一天可以写几十条，甚至上百条。对于迭代频繁的产品，维护自动化测试用例将是测试人员的“噩梦”。

（2）自动化测试用例执行失败后需要人工分析

自动化测试用例虽然可以做断言，但执行结果仍然需要由测试人员进行人工分析，判断是自动化测试用例本身的问题还是真正的缺陷。

（3）自动化测试无法处理未知的场景

假设测试人员误删除了自动化测试用例在测试环境中创建的一条数据，那么这条自动化测试用例就会执行失败，从而增加人工分析的时间。而手工测试则不同，如果发现创建的数据被删除了，那么再创建一条即可。

从以上几点来看，自动化测试要想提高测试效率，需要做到以下几点。

①自动化测试建设初期需要投入更多的人力，否则自动化测试无法形成一定的体量，也就谈不上代替手工测试提高测试效率。

②产品迭代频率不能太快，否则自动化测试用例将难以跟上维护的节奏，几个迭代过后，自动化用例将不可用。

③自动化测试用例质量要过关，否则在执行完成后会出现大量的“误报”，即自动化测试用例本身的问题，并非真正的缺陷。

④由于自动化测试对执行环境要求非常苛刻，因此不能与手工测试环境混用。