3．询问解惑
对于此次访问的Cookie中的参数，从语义上讲，我们既不知道这些参数是用来干什么的，也不知道它们起什么作用。
为此，我们拿着接口信息表，找到相应的研发工程师，向他们询问接口信息表中深灰色背景部分的参数。对于其中的每一个参数，都要详细询问以下3点内容，并保证自己已经真的理解这些内容。
参数的含义及来源。我们要搞清楚每一个参数的含义，也就是这个参数对应的实际自然语言的名称。可以记录每一个参数的中文语义，这有助于记住这个参数是用来干什么的。另外，我们还要知道参数的赋值是从哪里来的，是从其他页面或接口返回的，还是由JavaScript生成的。如果参数是从其他页面或接口返回的，那么还要知道是由哪个页面或接口返回的哪个字段。这样当我们进行接口测试时，就知道应从哪里得到参数的赋值了。如果参数是另一个接口的返回字段，那就需要维护一份接口信息表，以便下次创建对应的参数。如果不允许创建参数，那么我们还需要知道参数的生成规则，以便需要时能够手动构造参数。
参数的作用域。参数的作用域涉及的问题包括参数在接口中是用来干什么的，参数在哪一个访问周期中一直存在，参数是否导致业务逻辑分支等。比如，参数是用来验证用户权限的吗？参数的验证算法是什么？之所以要搞清楚这些问题，是为了让我们在进行接口测试时，能够设计更小的参数组合以覆盖更多的业务逻辑，这是对测试用例去冗余的一种好方法。
返回值的含义。对于接口的返回值，我们要理解JSON中每一个键对应的含义，这样当需要与接口产生交互时，就可以快速搞清楚对应参数的含义，从而完成业务逻辑上下文的串联。
总的来说，请求和响应的全部参数对于接口测试而言都是必要的输入项，因此我们有必要花费精力完善并留存它们。至此，我们已经借助工具并通过分析问题明确了未知参数，还通过询问研发工程师理解了未知参数的中文含义、作用域以及对应的返回参数的中文含义。即使面对没有接口文档的提测项目，相信我们也能收集到明确且足够的信息。
接下来，我们就可以利用这些信息，完成业务逻辑的接口测试。
3.3.4 串联多个接口
在质量保障过程中，测试的主要任务是保障SUT业务逻辑的正确性。但是，仅仅进行单一接口的测试通常很难保障SUT业务逻辑的正确性，因此在大部分测试场景中，我们需要串联多个接口才能完成保障SUT业务逻辑正确性的任务。
然而，即使我们已经按照之前介绍的3个步骤完成对全部单个接口的分析，也并不能马上开始进行测试，这是因为测试的业务逻辑是通过串联多个接口完成的，而多个接口的串联逻辑是由业务逻辑规定的。因此，多个接口之间并非随意组合，而是需要按照业务逻辑并通过数据传递来完成多个接口的串联。
这其实就和拼图游戏一样。假设有一些拼图碎片，这些拼图碎片可以拼到一起，不会出现明显的不适合情形。但是，要想真正完成拼图任务，就不仅需要考虑拼图碎片是不是可以拼到一起，还要考虑在将这些拼图碎片拼到一起后，得到的图形与正确图形是否一致。
前面我们整理好的、各个单一接口的接口信息表就相当于拼图游戏里的拼图碎片，业务逻辑相当于拼图后的最终图形，其中的参数则相当于拼图碎片的缺口和每一个拼图碎片上的图形。
因此，为了使用接口测试完成业务逻辑，我们不仅需要制作整个流程中所有接口的接口信息表，还要弄清楚每一个数据流程，数据流程负责驱动业务流的处理，如此才能开始业务逻辑的接口测试。
