3.3 接口测试的标准输入
测试工程师，尤其是做了多年业务测试的测试工程师，在开始接触接口测试时，无论研发工程师是否提供了接口文档，下面3种情形在日常工作中都是很常见的。
研发工程师提交测试的项目附带了一个几十页的Word文档，里面是一行行的访问地址和路由，面对这样的Word文档，测试工程师不知道如何开始验证。
研发工程师使用即时通信工具发送了一条长达几页的消息，里面包含各种嵌套的参数，测试工程师不知道这些参数都是干什么用的。
研发工程师口头指出需要测试的接口地址，之后什么都没有再多说，面对又长又复杂的接口地址，测试工程师束手无策。
对于上述情形，难道测试工程师就没有办法自行分析接口并完成测试吗？答案当然是否定的。但是，在开始解决上述问题之前，我们首先需要知道对于接口测试来说，什么样的输入才是理想的；之后我们再看看千奇百怪的接口测试提测项目又是什么样的；最后我们看看如何解决各种不理想的问题，从而回到接口测试的正轨。
3.3.1 理想的接口测试提测项目
理想的接口测试提测项目在提测过程中应该既包含前期参与的产品需求、原型设计，它们由产品经理提供；也应该包含接口文档、单元测试脚本，它们由研发工程师提供。为了开展接口测试，以上这些都是必须输入的内容，它们的作用如下。
产品需求描述了系统的业务逻辑，只有掌握了产品需求，测试工程师才能知道怎么设计测试用例。
原型设计更加直观地指明了系统的使用逻辑，对于测试用例的设计和系统的前期认知，原型设计是有辅助作用的。
接口文档详细描述了后端接口的访问方式和参数说明，只有掌握了这些，测试工程师才能开展接口测试用例的设计、测试脚本的准备和测试数据的构建。
单元测试脚本既是保障接口测试提测项目质量的重要因素，也是研发工程师自测的一种有效手段。
上述必须输入的内容并没有限制SUT（System Under Test，被测系统）的类型，SUT既可以是手机App，也可以是Web服务，甚至可以是微服务接口。因此，在接口测试阶段，理想的接口测试通常是从完美的接口文档开始的。研发工程师在设计和开发接口的过程中，需要不断维护和更新接口文档，接口文档中包含每一个接口的访问方式、访问路由、输入参数及返回参数的含义，此外还包含一个完整的例子。
接口文档既可能以Word文档形式存在，也可能以类似Swagger的工具形式存在。使用Swagger可以从代码中生成以Web服务形式存在的接口文档，这种接口文档能够随着代码的变更而同步进行变化，从而极大降低了研发工程师和测试工程师的沟通成本。
图3-16显示了使用Swagger生成的接口文档，从中可以看出，接口文档对接口的访问方式、访问路由及参数做了详细描述。
图3-16 使用Swagger生成的接口文档
因此，拿到接口文档后，我们就可以快速使用各种工具或代码来完成单个的接口测试任务了。与此同时，我们还可以通过进行一些参数设计和参数上下文传递来完成接口的流程测试。
