这篇文章大家一定要动手操作哦，不然我超凶的哦
首先回顾上一篇文章关键问题
工具辅助。借助一些工具的辅助来完成接口分析。
分析问题。通过分析接口的访问方式、参数等信息整理出要解决问题。
询问解惑。针对问题和研发工程师进行沟通，把一些不知道的参数含义、参数取值范围等问题沟通清楚。
https://github.com/crisschan/Battle
首先，明确SUT的流程业务：进入系统，选择武器，然后和选择的敌人决斗；
其次，选择的辅助工具为Postman；
然后，设计测试用例。
正确登录系统后，选择武器，与敌人决斗，杀死了敌人；
正确登录系统后，选择武器，与敌人决斗，被敌人杀死；正确登录系统后，选择武器，与敌人决斗，两个人同归于尽；
正确登录系统，选择武器，没有选择敌人，自尽而死；
正确登录系统，选择一个未提供的武器编号，选择一个敌人，自尽而死；
正确登录系统，选择武器，选择一个未出战的敌人（不在返回提示列表中），自尽而死。
从实例了解接口测试开始
首先，打开 Postman，你可以看到它的 UI 结构很简单，为了可以检测首页接口，你需要设定 HTTP 的访问方式为 GET，URL 是
http://127.0.0.1:12356/，点击发送按钮后，就可以在工具下面的 Body 部分看到接口返回的说明性文本内容了，这个内容是“please inputyour username(your english name) and password(your english name)”。
在获取了参数后，下面你就要借助 Postman 这个工具，选择 Post 访问方式，输入登录接口的 URL，在 Request 的 Body 中输入username=criss&password=criss 的参数，然后点击发送，接下来，你就会在Response 的 Body 中对应返回内容。如下图所示：
业务流程接口测试业务流程接口测试，主要是保障通过多个接口的串联操作可以完成原来需求中提出的业务逻辑，这也是它主要关注的内容。在前面，我已经告诉过你这个系统的主要业务逻辑：“进入系统后，选择武器，然后和你选择的敌人决斗。”
依据上面这种业务逻辑描述，还不能完成业务流程的接口测试，我们需要对其做进一步的分析和细化。依据这个业务需求，至少有下面这几个业务流程：
正确登录系统后，选择武器，与敌人决斗，杀死了敌人；
正确登录系统后，选择武器，与敌人决斗，被敌人杀死；正确登录系统后，选择武器，与敌人决斗，两个人同归于尽；
正确登录系统，选择武器，没有选择敌人，自尽而死；
正确登录系统，选择一个未提供的武器编号，选择一个敌人，自尽而死；
正确登录系统，选择武器，选择一个未出战的敌人（不在返回提示列表中），自尽而死。
那么针对这些业务流程，我们设计的参数如下：
继续按照上面的流程，用 Postman 将上述流程完成，你就完成自己的接口测试了。如下图：
但是通过观察上面的业务流测试，你会不会感觉与你自己平时手动写的业务测试相比，好像少了点什么？
没错，它和业务测试的测试用例相比，确实少了很多异常状况，比如正确登录、正拒绝登录、正确登陆选择的装备参数是字符串等等，这一系的业务流中的反向用例都没有进行验证。
这也是接口测试和业务测试在设计测试和执行测试过程中的差异点，在接口测试中，我们通过单个接口测试完成了全部异常状态的覆盖；而在业务流程中，我们更需要关心业务流和数据流的关系，并不需要再过度关心如何用业务流的方法覆盖更多的代码逻辑异常，这也是分层测试中为什么在单元测试和界面测试之间要加入一层接口测试的主要原因之一。
通过单接口测试，可以更加接近于单元测试；通过业务流的接口测试，可以更加接近于界面所承载的交互中的业务流验证，这也是为什么现在很多人在提倡将测试模型由原来的金字塔形往菱形转变的依据之一了。而完成了这一系列流程，其实你也就掌握了接口测试的思维：先从单个接口的测试开始，保障单个接口的正确性和健壮性，然后通过单个接口的测试完成多个接口的业务逻辑串联，站在业务逻辑的角度完成业务逻辑的正确性检测。
通过 Postman 这个工具完成从单接口测试用例的设计到业务逻辑接口测试用例的设计，你就已经掌握了接口测试的思维以及具体的实现方法。但是到目前为止，你还处在手动测试的阶段，虽然已经和以前基于界面的业务测经有了很大区别，但是距离自动化的接口测试还有一定的差距。
不过不用担心，因为这个差距仅仅是一个工具的距离。我相信你一定听说过持续集成，在持续集成中，有一个很重要的环节就是要持续测试，通过持续集成平台调取自动化测试，完成质量保障工作。现在你已经有了 Postman，已经完成了基于 Postman 的接口测试脚本，那么如何将其赋能给持续集成平台呢？
这里我们要借助 Newman 这款工具，它就是 shell 下的 Postman，我们将 Postman 的业务逻辑接口测试脚本导出后，push 到本地的 Git 仓库中，持续集成平台就可以通过 pull 对应的接口测试脚本，然后通过 Newman 执行，这样就可以完成持续集成平台的赋能了。
在这里只提供给一个思路，具体的完成方式，可以通过学习持续集成平台 Jenkins 和 Newman 运行 Postman 脚本完成对应的内容。
总结
一定要动手操作！动手操作！动手操作！
