关于不同测试阶段的测试场景

代码的基本特征和产生错误的原因（要做到代码功能逻辑正确，必须做到分类正确且完备没有遗漏，同事每个分类的逻辑处理正确）代码中的功能点相当于单元测试的等价类

单元测试用例（单元测试是一个包含输入数据和预计输出的集合）输入数据并不只是被测试函数的输入参数，以下为一些分类：

1. 被测函数的输入参数  
2. 被测函数内部需要读取的全局静态变量
3. 函数内部调用子函数获得的数据等等
...

预计输出并不只是被测函数的返回值，以下为一些分类：

1. 被测函数的返回值
2. 被测函数的输出参数
3. 被测函数中进行的文件更新
4. 被测函数中进行的数据库更新等等
...

驱动代码: 调用被测函数的代码，包含调用被测函数前的数据准备，调用被测函数和验证相关结果，驱动代码结构通常由单元测试框架决定。

桩代码: 指用来代替函数内部某个尚未实现的函数的代码，与真是代码相比，桩代码具有与原函数相同的原形，只是内部实现不同，桩代码只是起到隔离和补齐的作用，是被测代码能够独立编译，链接并独立运行，同时桩代码还有控制被测函数执行路径的作用，通常桩代码的验证(assert)逻辑出现在驱动代码中

Mock代码: 与桩代码类似，对于结果的验证通常出现在Mock代码中

指自动化工具对被测代码进行分析扫描，自动为被测函数内部调用的其他函数生成可编程的桩代码
- 抽桩：在代码集成测试阶段，希望不再调用桩代码而调用真实代码
1. 被测代码的自动化静态分析：主要指代码的静态扫描，目的是识别违反编码规则和编码风格的代码行，比较常见的工具有sonar和coverity。
2. 测试覆盖率的自动统计与分析

如单元测试最大的区别在于代码集成测试不允许使用桩代码web service测试

测试脚手架代码的自动化生成,如httprunner可以自动生成项目脚手架
部分测试数据的自动化生成,与单元测试的区别在于单元测试的输入数据是函数的参数组合，API测试对应的是API的参数和API调用的payload
response验证的自动化
基于测试工具(如postman)的自动化脚本生成:在使用测试工具测试时，在已经存在多个测试用例的情况下来基于代码实现API测试时，存在一个问题就在于，可以开发一个代码转换工具，自动将已有的测试用例(如JSON格式)转换为可执行代码，为后续CI/CD直接使用