开始第一个接口测试
在拿到一个 SIT 环境的时候，你首先就要进行接口测试，这是因为单元测试不是由测试工 程师来完成的，而是由开发工程师编写、并由持续集成系统自动完成执行的。如果开发工程师没有给我们任何有价值的文档，那么要开始接口测试，你可以通过工具辅 助、分析问题、询问解惑这三个步骤来完成。
具体的工作模式如上图所示：
1. 借助一些工具的辅助来完成接口分析；
2. 通过工具截获一些接口信息；
3. 通过分析接口的访问方式、参数等信息整理出一些问题，和研发工程师沟通这些问题， 将一些不知道的参数含义、参数取值范围等问题问清楚：
都询问些什么呢？我认为主要有三点。
1. 参数的含义以及来源。你要搞清楚每一个参数的含义，同时，你也要知道这个参数的赋值是从哪里来的，是从其他页面的返回值中得到 的？还是 JS 生成的？如果是其他页面或者接口返回的，那么，是哪一个接口返回的哪个 字段？这样，当你开始做接口测试的时候，你就知道去哪里拿到这个参数的赋值了。如 果是另一个接口的返回字段，那么，你还需要维护一份返回该参数接口的接口信息文 档，以便于自己下一次创建对应的参数，如果不可以创建，那么你就要知道这个参数的 生成规则，也要知道如何手动构造它。
2. 参数的作用域。参数的作用域指的是这个参数在这个接口中是做什么用的，它在哪一个 访问周期里是一直存在的，它是否导致了业务逻辑分支等。比如说，这个参数是用来验 证用户权限吗？它的验证算法是什么？之所以要搞清楚这些内容，是为了你在做接口测 试的时候，可以设计更小的参数来覆盖更多的业务逻辑，这是测试用例去除冗余的 一个很好的方法。
3. 返回值的含义。针对上面一大串的返回 JSON，你要搞清楚在返回值中，每一个 JSON 的 Key 所对应的含义，这样，当你需要和这个接口产生交互的时候，就可以快速地拿到 对应参数的含义，完成业务逻辑上下文的参数串联了。
通过这三步的循环，你就可以完成对 SIT 系统接口信息的完善和维护，最终得到一份完整 的、接口测试需要的输入—接口文档；
然而，即使我们按照上述三个步骤完成了全部单个接口的分析，也并不能马上开始进行接口 测试。这是因为，一个测试的业务逻辑是由多个接口的串行完成的，而多个接口的串行逻辑 是由业务逻辑规定的，因此，多个接口之间并不是随意组合的，而是按照业务逻辑、通过数据传递来完成的；
所以，要想使用接口测试完成业务逻辑，你就要制作一个流程中所有接口的接口信息表，同 时，还要理清每一个流程的数据流程，数据流程驱动了业务流处理，这样，才能开始业务逻 辑的接口测试。
