软件测试52讲学习总结-05 | 你知道软件开发各阶段都有哪些自动化测试技术吗?

软件开发生命周期的各个阶段都有哪些类型的自动化测试技术。

最为熟悉的就是 GUI 自动化测试了。比如，早年的 C/S 架构，通常就是用自动化测试脚本打开被测应用，然后在界面上以自动化的方式执行一系列的操作；再比如，现今的 Web 站点测试，也是用自动化测试脚本打开浏览器，然后输入要访问的网址，之后用自动化脚本识别定位页面元素，并进行相应的操作。

因此，说到自动化测试时，第一反应很可能就是 GUI 自动化测试。

然而，在软件研发生命周期的各个阶段都有自动化测试技术的存在，并且对提升测试效率有着至关重要的作用。

下面从：单元测试、代码级集成测试、Web Service 测试和 GUI 测试阶段的自动化技术，更深入地理解“自动化测试”的内涵以及外延

一、单元测试阶段

从广义上讲，单元测试阶段的“自动化”内涵不仅仅指测试用例执行的自动化，还应该包含以下五个方面：

1、用例框架代码生成的自动化；

2、部分测试输入数据的自动化生成；

3、自动桩代码的生成；

4、被测代码的自动化静态分析；

5、测试覆盖率的自动统计与分析。

第一，用例框架代码生成的自动化

有些框架代码应该由自动化工具生成，而不是由开发者手工完成。

这样一来，单元测试开发者可以把更多的精力放在测试逻辑的覆盖和测试数据的选择上，从而大幅提高单元测试用例的质量和开发效率。

TestNG 框架代码应该由自动化工具生成

第二，部分测试输入数据的自动化生成

这部分是指，自动化工具能够根据不同变量类型自动生成测试输入数据。

自动化工具本身不可能明白代码逻辑，你可能很难理解它是如何根据需要测试的代码逻辑生成合适的输入数据，并且去判断预计的测试结果的。

那我给你举个例子，你就很容易明白了。

比如，某个被测函数的原型是 void fun（int* p, short b），那么测试数据自动生成技术就会为输入参数 int* p 自动生成“空”和“非空”的两个指针 p，然后分别执行函数 void fun（int* p, short b），并观察函数的执行情况。

如果函数内部没有对空指针进行特殊处理，那么函数 fun 的调用必定会抛出异常，从而发现函数的设计缺陷。同样地，对于输入参数 short b 会自动生成超出 short 范围的 b，测试函数 fun 的行为。

第三，自动桩代码的生成

简单地说，桩代码（stub code）是用来代替真实代码的临时代码

比如，某个函数 A 的内部实现中调用了一个尚未实现的函数 B，为了对函数 A 的逻辑进行测试，那么就需要模拟一个函数 B，这个模拟的函数 B 实现就是所谓的桩代码。

自动桩代码的生成是指自动化工具可以对被测试代码进行扫描分析，自动为被测函数内部调用的其他函数生成可编程的桩代码，并提供基于测试用例的桩代码管理机制。此时，单元测试开发者只需重点桩代码内的具体逻辑实现，以及桩代码的返回值。

必要的时候，自动化工具还需要实现 “抽桩”，以适应后续的代码级集成测试的需求。

那什么是“抽桩”呢？其实也很简单，在单元测试阶段，假如函数 A 内部调用的函数 B 是桩代码，那么在代码级集成测试阶段，我们希望函数 A 不再调用假的函数 B，而是调用真实的函数 B，这个用真实函数 B 代替原本桩代码函数 B 的操作，就称为“抽桩”。

第四，被测代码的自动化静态分析

静态分析主要指代码的静态扫描，目的是识别出违反编码规则或编码风格的代码行。通常这部分工作是结合项目具体的编码规则和编码风格，由自动化工具通过内建规则和用户自定义规则自动化完成的。

目前比较常用的代码静态分析工具有 Sonar 和 Coverity 等。

严格意义上讲，静态分析不属于单元测试的范畴，但这部分工作一般是在单元测试阶段通过自动化工具完成的，所以我也把它归入到了单元测试自动化的范畴。

第五，测试覆盖率的自动统计与分析

单元测试用例执行结束后，自动化工具可以自动统计各种测试覆盖率，包括代码行覆盖率、分支覆盖率、MC/DC 覆盖率等。这些自动统计的指标，可以帮你衡量单元测试用例集合的充分性和完备性，并可以为你提供适当增补测试用例以提高测试覆盖率的依据

二、代码级集成测试的自动化技术

代码级集成测试是指将已经开发完成的软件模块放在一起测试。

代码级集成测试与单元测试最大的区别只是，代码级集成测试中被测函数内部调用的其他函数必须是真实的，不允许使用桩代码代替，而单元测试中允许使用桩代码来模拟内部调用的其他函数。

现在的软件企业，尤其是互联网企业，基本不会去做代码级集成测试，

三、Web Service 测试的自动化技术

Web Service 测试，主要是指 SOAP API 和 REST API 这两类 API 测试，最典型的是采用 SoapUI 或 Postman 等类似的工具。但这类测试工具基本都是界面操作手动发起 Request 并验证 Response，所以难以和 CI/CD 集成，于是就出现了 API 自动化测试框架。

对于基于代码的 API 测试用例，

通常包含三大步骤：

1、准备 API 调用时需要的测试数据；

2、准备 API 的调用参数并发起 API 的调用；

3、验证 API 调用的返回结果。

目前最流行的 API 自动测试框架是 REST Assured，它可以方便地发起 Restful API 调用并验证返回结果。

同样地，Web Service 测试“自动化”的内涵不仅仅包括 API 测试用例执行的自动化，还包括以下四个方面：

1、测试脚手架代码的自动化生成；

和单元测试阶段的用例框架代码自动生成一个道理，你在开发 API 测试的过程中更关心的是，如何设计测试用例的输入参数以及组合，以及在不同参数组合情况下 Response 的验证，而你不希望将精力浪费在代码层面如何组织测试用例、测试数据驱动如何实现等非测试业务上。

这时，测试脚手架代码的自动生成技术就派上用场了。它生成的测试脚手架代码，通常包含了被测试 API 的调用、测试数据与脚本的分离，以及 Response 验证的空实现

2、部分测试输入数据的自动生成；

这一点和单元测试的测试输入数据的自动化生成也很类似，唯一不同的是，单元测试针对的参数是函数输入参数和函数内部输入，而 API 测试对应的是 API 的参数以及 API 调用的 Payload。数据生成的原则同样遵循边界值原则。

3、Response 验证的自动化；

对于 API 调用返回结果的验证，通常的点是返回状态码（status code）、Scheme 结构以及具体的字段值。

如果你写过这种类型的测试用例，那你就会知道字段值的验证相当麻烦，只有那些你明确写了 assert 的字段才会被验证，但是通常你不可能针对所有的字段都写 assert，这时就需要 Response 验证的自动化技术了。

Response 验证自动化的核心思想是自动比较两次相同 API 调用的返回结果，并自动识别出有差异的字段值，比较过程可以通过规则配置去掉诸如时间戳、会话 ID（Session ID）等动态值。

4、基于 SoapUI 或者 Postman 的自动化脚本生成。

你在使用 SoapUI 或者 Postman 等工具进行 Web Service 测试时，已经在这些工具里面积累了很多测试用例。那么，在引入了基于代码实现的 API 测试框架之后，就意味着需要把这些测试用例都用代码的方式重写一遍，而这额外的工作量是很难被接受的。

因此，开发一个自动化代码转换生成工具。

这个工具的输入是 SoapUI 或者 Postman 的测试用例元数据（即测试用例的 JSON 元文件），输出是符合 API 测试框架规范的基于代码实现的测试用例。这样一来，原本的测试用例积累可以直接转换成在 CI/CD 上可以直接接入的自动化测试用例。

对于新的测试用例，还可以继续用 SoapUI 或者 Postman 做初步的测试验证，初步验证没有问题后，直接转换成符合 API 测试框架规范的测试用例。对于复杂的测试用例，也可以直接基于代码来实现，而且灵活性会更好。

四、GUI 测试的自动化技术

GUI 测试的自动化技术可能是最熟悉的，也是发展时间最长、应用最广的自动化测试技术。它的核心思想是，基于页面元素识别技术，对页面元素进行自动化操作，以模拟实际终端用户的行为并验证软件功能的正确性。

目前，GUI 自动化测试主要分为两大方向，传统 Web 浏览器和移动端原生应用（Native App）的 GUI 自动化。

虽然二者采用的具体技术差别很大，但是用例设计的思路类似。

对于传统 Web 浏览器的 GUI 自动化测试，业内主流的开源方案采用 Selenium，商业方案采用 Micro Focus 的 UFT（前身是 HP 的 QTP）；

对于移动端原生应用，通常采用主流的 Appium，它对 iOS 环境集成了 XCUITest，对 Android 环境集成了 UIAutomator 和 Espresso。