5.软件开发各阶段都需要哪些自动化测试技术

• 单元测试的自动化技术

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

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

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

自动化工具盒能够根据不同变量类型自动生成测试输入数据。
比如，对于一个函数它的参数是指针，那么测试数据自动生成技术就会为输入参数自动生成“空”和“非空”两个指针。

3. 自动桩代码的生成

桩代码是用来代替真实代码的临时代码。
自动化工具可以对被测试代码进行扫分析，自动为被测函数内部调用的其他函数生成可编程的桩代码，并提供基于测试用例的桩代码，并提供基于测试用例的桩代码管理机制。单元测试开发者只需要关注代码内的具体逻辑实现，以及桩代码的返回值。
必要的时候，自动化工具还需要实现“抽桩”，以适应后续的代码级集成测试的需求。
抽桩：在单元测试阶段，假如函数A内部调用的函数B是桩代码，那么在代码级集成测试阶段，我们希望函数A不再调用假的函数B，而是调用真实的函数B。这个用真实函数B代替原本桩代码函数B的操作，就是“抽桩”。

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

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

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

单元测试用例执行结束后，自动化工具可以自动统计各种测试覆盖率，包括代码覆盖率、分支覆盖率、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验证的自动化技术了。
该技术的核心思想就是自动化两次相同API调用返回结果，并自动识别出有差异的字段值，比较过程可以通过规则配置去掉诸如时间戳、会发ID等动态值。

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

在使用SoapUI或者Postman等工具进行Web Service测试时，已经在这些工具里面积累了很多测试用例。那么，在引入了基于代码实现的API测试框架之后，就意味着需要把这些测试用例都用代码的方式重写一遍，而这个额外的工作量是很难被接受的。
所以，可以开发一个自动化代码转换生成工具，这个工具的输入时SoapUI或者Postman的测试用例元数据（即测试用例的JSON元文件），输出是符合API测试框架规范的基于代码，这样原本的测试用例积累可以直接转换成在CI/CD上可以直接接入的自动化测试用例。
对于新的测试用例，还可以继续用SoapUI或者Postman做初步的测试验证，初步验证没有问题后。直接转换成符合API测试框架规范的测试用例。对于复杂的测试用例，也可以直接基于代码实现，而且灵活性会更好。

• GUI测试的自动化技术
  它的核心思想是，基于页面元素识别技术，对页面元素进行自动化操作，以模拟实际终端用户的行为并验证软件功能的正确性。
  目前，GUI自动化测试主要分为两大方向，传统Web浏览器和移动端原生应用的GUI自动化。虽然二者采用色具体技术差别很大，但是用例设计的思路类似。

对于传统Web浏览器的GUI自动化测试，业内主流的开源方案采用Selenium，商业方案采用Micro Focus的UFT（前身是HP的QTP）
对于移动端原生应用，通常采用主流Appium，它对iOS环境集成了XCUITest，对Abdroid环境集成了UIAutomator和Espresso
。