这是《落叶》文集里第 288 片落叶，希望你能喜欢，不为别的，只为这份坚持。
【背景】
这是一个好思考，好提问的同学，在学习《颠覆你的 Python 接口自动化测试》课程的过程中提出的一个疑惑。
【你问】
接口自动化测试需不需要覆盖业务逻辑校验？
【我答】
不管是在这门课程的设计上，还是我们的实际工作中，“接口测试”和“接口自动化测试”都需要剥离开去看待，前者是测试类别或者说测试工作，而后者是辅助前者的一种技术手段，切记，不要混在一起去看待。
就接口测试本身来说，只有当参数完整性验证 + 接口返回码验证 + 业务逻辑正确性验证都做完了，才能说这个接口的测试完成了，没问题了。（注：这里暂不涉及接口的性能和安全性检验）
而接口自动化测试，简单点说，就是通过某种商业的、开源的、自研的工具替代手工接口测试的部分工作。
为什么要说是部分工作呢？因为我们要清楚地认识到很重要的两点：
第一、目前所有的自动化其实都是半自动化，不管是接口自动化、web 自动化，case 都是人工设计的，脚本也都是人工编写的，只有部分执行的工作才是机器做的，是这样的吧？
第二、既然是替代部分人工操作的工具，那我们就不得不去考虑它的开发成本和维护成本了，也就是常说的，做这个东西，性价比高不高？而且，后者往往会容易被忽略掉，以为工具或脚本写出来之后就一劳永逸了；
综合上述两点的考虑，我对接口自动化测试框架的产品需求有几个要求：
第一优先级：减少脚本开发中不必要的人工投入。
举个例子：一个接口所包含的参数类型基本都是已知的、固定的，每类参数的入参值，基本都由一组入参值构成，那我就要这个框架实现，我人工对于一个接口只要写一条用例，为每个参数选择好入参值的类型时，会自动生成所有的接口测试脚本，而不用人工复制、粘贴、再修改参数的入参值，假如一个参数的入参值有7个，那就要重复7次，多累啊，而且完全没有价值，还容易犯错。
第二优先级：执行结果的发送和查看。
当我启动了接口自动化的脚本之后，我不可能一直等着的，或者说我如果用于某种环境的定时巡检时，我也不需要每次执行结果都要查看，只有当执行结果有错误时，才需要邮件将执行结果发送给我，附上 Summary 和元数据报表即可。
第三优先级，才可能是对于业务逻辑的正确性判断，因为它可能需要检查很多东西，而且有些东西，可能还需要从数据库里取值来做比对，还有不同客户端之间的等待、依赖关系等等，所以最后我才会考虑去做这一部分功能，为什呢，就是因为性价比最低。
接口自动化测试工具，在以下几个方面相对比较实用：
第一、现网环境的巡检，巡检其实就是通过接口请求返回的 code，判断接口服务器是否 work well，如果返回异常，就报警，发邮件给运维或开发人员；
第二、集成开发阶段，就是当服务端接口开发完成时，可以用参数完整性校验来检验接口是否按照接口文档完成的，只有通过后，客户端开发才开始联调，这样效率会高不少；
所以，好的接口自动化测试框架，除了让 QA 使用起来，门槛低，人工干预少，重复性工作减少，还要是 web service、定时 Job 和分布式执行脚本的，因为便于开发、运维人员使用，他们也不需要在自己本机安装什么环境。
如果上述的框架开始运行，趋于稳定的时候，再去考虑业务逻辑校验功能都不迟，也就是多花点时间，设计一套升级维护成本小且准确率高的的方案而已。
《测试路上你问我答》里的 Q&A 80，如果是你要的，甚好！如果不是，你问，我答！
作者简介：14 年测试 + 11 年项目管理 + 11 年团队管理 = 一个测试老兵
