3.5 接口测试的关键逻辑
简单来说，Postman就是一款HTTP客户端工具。但Postman只是我们完成任务的手段，接口测试用例的设计和实现过程才是本书的重点。因此，大家完全不必因为掌握了Postman工具而觉得下面的内容晦涩难懂。
3.5.1 明确被测系统
为了便于讲解，作者专门制作了一个名为Battle的小型系统，这是一个理想的被测系统，读者可从GitHub（搜索“crisschan/Battle.git”）下载这个系统的详细代码。
Battle系统是一款采用回合制的游戏，可通过接口测试的方法和服务器发生交互，模拟两个角色进行决斗，最后得出到底谁是赢家。详细的说明和代码都在GitHub上，读者可以自行查看。除单个接口的说明以外，剩下的就是业务逻辑了。Battle系统的业务逻辑如下：进入系统后，选择武器，接下来就可以和选择的敌人决斗了。
3.5.2 开始接口测试
在开始业务流程接口测试之前，我们需要先通过接口测试的方法测试每一个接口，既要保证接口的正确性，也要保证接口业务逻辑的正确性。这里所说的“正确性”，指的是“正确接收合法的Request入参，并正确拒绝非法的Request入参”。
1．单接口测试
单接口测试的重点，其实就是保证一个接口的正确性和健壮性。也就是说，单接口测试既要保证这个接口可以按照需求正确处理传入的参数，并给出正确的返回结果；也要保证能够按照需求，正确地拒绝传入不正确的参数，并给出正确的拒绝性返回结果。下面以Battle系统为例进行单接口测试。
启动Postman后，可以看到Postman的UI结构很简单。为了检测Postman的首页访问接口，我们需要设定HTTP请求的访问方式为GET，并设定URL为http://127.0.0.1:12356/。单击Send按钮后，在界面底部的Body部分查看首页访问接口返回的说明性文本信息，如图3-25所示。
图3-25 Postman的首页访问接口
对于采用GET访问方式的接口，我们在前面已经完成了测试工作。接下来，我们测试另一个接口——登录接口，访问方式是POST，参数是username和password。这两个参数都不可以为空，并且都不可以超过10个字符。如果username和password参数的值相同，就正确进入系统并返回说明性文本，否则拒绝登录。正因为如此，我们需要多检查一项内容——请求参数的设计。使用边界值法来设计请求参数，如表3-2所示。
表3-2 设计的请求参数（一）
在获取请求参数后，剩下的工作就需要借助Postman来完成了。选择POST访问方式，输入登录接口的URL，并在请求的body信息中输入“username=criss&password=criss”，然后单击Send按钮，响应的body信息中将返回对应的内容，如图3-26所示。
图3-26 借助Postman工具访问登录接口
使用上面介绍的方法，依次完成剩余两个接口的测试用例的设计和执行，如此便完成了所有单个接口的测试工作。
到目前为止，我们仅仅完成了接口测试的一半工作，另一半工作则是按照系统的业务逻辑进行如下验证：正确的流程可以完成处理，不正确的流程可以拒绝处理。
2．业务流程接口测试
业务流程接口测试旨在保障通过进行多个接口的串联操作来完成原有需求中提出的业务逻辑。回顾一下，Battle系统的业务逻辑如下：进入系统后，选择武器，接下来就可以和选择的敌人决斗了。
仅仅根据业务逻辑，我们还无法完成业务流程接口测试。我们还需要对业务逻辑做进一步的分析和细化。
正确登录系统后，选择武器，与敌人决斗，杀死敌人。
正确登录系统后，选择武器，与敌人决斗，被敌人杀死。
正确登录系统后，选择武器，与敌人决斗，最后与敌人同归于尽。
正确登录系统后，选择武器，没有选择敌人，自尽而死。
正确登录系统后，选择的武器未提供，选择敌人，自尽而死。
正确登录系统后，选择武器，选择的敌人不出战（但不再返回到提示列表），自尽而死。
针对上述业务逻辑设计请求参数，如表3-3所示。
表3-3 设计的请求参数（二）
接下来，我们就可以利用Postman，将参数手动传递给下一个接口，从而进行业务流程接口测试了。按照上面介绍的方法，使用Postman完成其他5个业务逻辑的接口测试工作，如图3-27所示。
图3-27 使用Postman进行业务流程接口测试
现在已经有5个业务流程接口测试用例了，通过观察上面的业务测试（业务流程接口测试的简称），我们发现少了很多异常状况，如正确登录、拒绝登录等，这些业务测试中的反向用例都尚未进行验证。
这就是接口测试和业务测试在设计测试与执行测试过程中的不同之处。在接口测试中，我们可通过单接口测试完成对全部异常状态的覆盖；但在业务测试中，我们更关心业务流和数据流的关系，而不是如何使用业务流的方法覆盖更多的代码逻辑异常，这也是分层测试中有必要在单元测试和界面测试之间加入一层接口测试的主要原因。
通过单接口测试，我们可以更接近单元测试；而通过业务测试，我们可以更接近界面所要承载的交互过程中的业务流验证，这也是现在很多人提倡将测试模型从原来的金字塔模型向菱形模型转变的重要依据。在完成上述一系列测试后，我们就掌握了接口测试的思维：首先从单个接口的测试开始，以保障每个接口的正确性和健壮性；然后通过单个接口的测试完成多个接口业务逻辑的串联，并从业务流的角度完成对业务逻辑正确性的验证。
