文章内容来源于《软件测试52讲》
1、单元测试
从广义上讲，单元测试阶段的“自动化”内涵不仅仅指测试用例执行的自动化，还应该包含以下五个方面：
1.1 用例框架代码生成的自动化
借助自动化，单元测试开发者可以把更多的精力放在测试逻辑的覆盖和测试数据的选择上，从而大幅提高单元测试用例的质量和开发效率。
TestNG 框架代码应该由自动化工具生成
1.2 部分测试输入数据的自动化生成
根据不同变量类型自动生成测试输入数据
比如，某个被测函数的原型是 void fun（int* p, short b），那么测试数据自动生成技术就会为输入参数 int* p 自动生成“空”和“非空”的两个指针 p，然后分别执行函数 void fun（int* p, short b），并观察函数的执行情况。
如果函数内部没有对空指针进行特殊处理，那么函数 fun 的调用必定会抛出异常，从而发现函数的设计缺陷。同样地，对于输入参数 short b 会自动生成超出 short 范围的 b，测试函数 fun 的行为。
1.3 自动桩代码的生成
比如，某个函数 A 的内部实现中调用了一个尚未实现的函数 B，为了对函数 A 的逻辑进行测试，那么就需要模拟一个函数 B，这个模拟的函数 B 实现就是所谓的桩代码。
自动桩代码的生成是指自动化工具可以对被测试代码进行扫描分析，自动为被测函数内部调用的其他函数生成可编程的桩代码，并提供基于测试用例的桩代码管理机制。此时，单元测试开发者只需重点关注桩代码内的具体逻辑实现，以及桩代码的返回值。
必要的时候，自动化工具还需要实现 “抽桩”，以适应后续的代码级集成测试的需求。
抽桩：在单元测试阶段，假如函数 A 内部调用的函数 B 是桩代码，那么在代码级集成测试阶段，我们希望函数 A 不再调用假的函数 B，而是调用真实的函数 B，这个用真实函数 B 代替原本桩代码函数 B 的操作
1.4 被测代码的自动化静态分析
静态分析主要指代码的静态扫描，目的是识别出违反编码规则或编码风格的代码行。通常这部分工作是结合项目具体的编码规则和编码风格，由自动化工具通过内建规则和用户自定义规则自动化完成的。目前比较常用的代码静态分析工具有 Sonar 和 Coverity 等。
严格意义上讲，静态分析不属于单元测试的范畴，但这部分工作一般是在单元测试阶段通过自动化工具完成的，所以也把它归入到了单元测试自动化的范畴。
1.5 测试覆盖率的自动统计与分析
单元测试用例执行结束后，自动化工具可以自动统计各种测试覆盖率，包括代码行覆盖率、分支覆盖率、MC/DC 覆盖率等。
这些自动统计的指标，可以衡量单元测试用例集合的充分性和完备性，并可以提供适当增补测试用例以提高测试覆盖率的依据。
2、代码级集成测试（现在互联网比较少用）
从测试用例设计和测试代码结构来看，代码级集成测试和单元测试非常相似，它们都是对被测试函数以不同的输入参数组合进行调用并验证结果，只不过代码级集成测试的关注点，更多的是软件模块之间的接口调用和数据传递。
与单元测试最大的区别：代码级集成测试中被测函数内部调用的其他函数必须是真实的，不允许使用桩代码代替，而单元测试中允许使用桩代码来模拟内部调用的其他函数。
3、Web Service 测试
Web Service 测试，主要是指 SOAP API 和 REST API 这两类 API 测试，最典型的是采用 SoapUI 或 Postman 等类似的工具。但这类测试工具基本都是界面操作手动发起 Request 并验证 Response，所以难以和 CI/CD 集成，于是就出现了 API 自动化测试框架。
3.1 采用API 自动化测试框架来开发测试用例
这些测试用例的表现形式就是代码
对于基于代码的 API 测试用例，通常包含三大步骤：
- 准备 API 调用时需要的测试数据；
- 准备 API 的调用参数并发起 API 的调用；
- 验证 API 调用的返回结果。
3.2 测试脚手架代码的自动化生成
生成的测试脚手架代码，通常包含了被测试 API 的调用、测试数据与脚本的分离，以及 Response 验证的空实现。
场景：如何设计测试用例的输入参数以及组合，以及在不同参数组合情况下 Response 的验证
（理由：不希望将精力浪费在代码层面如何组织测试用例、测试数据驱动如何实现等非测试业务上）
3.3 部分测试输入数据的自动生成
单元测试针对的参数是函数输入参数和函数内部输入
API 测试对应的是 API 的参数以及 API 调用的 Payload。
数据生成的原则同样遵循边界值原则。
3.4 Response 验证的自动化
对于 API 调用返回结果的验证，通常关注的点是返回状态码（status code）、Scheme 结构以及具体的字段值。
只有那些明确写了 assert 的字段才会被验证，但是通常不可能针对所有的字段都写 assert，这时就需要 Response 验证的自动化技术了
Response 验证自动化的核心思想是自动比较两次相同 API 调用的返回结果，并自动识别出有差异的字段值
比较过程可以通过规则配置去掉诸如时间戳、会话 ID（Session ID）等动态值。
3.5 基于 SoapUI 或者 Postman 的自动化脚本生成
转化成测试用例的 JSON 元文件
对于新的测试用例，还可以继续用 SoapUI 或者 Postman 做初步的测试验证，初步验证没有问题后，直接转换成符合 API 测试框架规范的测试用例。对于复杂的测试用例，也可以直接基于代码来实现，而且灵活性会更好。
4、GUI 测试
4.1 传统 Web 浏览器
业内主流的开源方案采用 Selenium
4.2 移动端原生应用（Native App）
通常采用主流的 Appium，它对 iOS 环境集成了 XCUITest，对 Android 环境集成了 UIAutomator 和 Espresso。
