3.5.3 Postman的接口测试和持续集成
在使用Postman完成从单接口测试用例的设计到业务逻辑接口测试用例的设计之后，相信我们已经掌握了接口测试的思维以及具体的实现方法。到目前为止，我们还处在手动测试阶段，尽管和以前基于界面的业务测试相比已经有了很大区别，但距离自动化的接口测试仍有一定的差距。对此不用担心，因为这个差距只需要借助一个工具就可以消除。
1．持续集成、持续交付和持续部署
图3-28展示了持续集成（Continuous Integration，CI）、持续交付（Continuous Delivery，CD）和持续部署的关系。
持续集成是指在开发人员提交代码更新后，就立即对相应的系统进行构建和测试（此时最常出现的是单元测试），然后通过测试来确定新提交的代码和原有代码是否可以正确集成到一起（也就是集成到主干）。持续集成旨在快速发现问题，包括分支问题，从而防止分支严重偏离主干。持续集成能够实现高质量的快速迭代，目标是快速发现缺陷而非解决缺陷。
图3-28 持续集成、持续交付和持续部署的关系
持续交付是指定时或按需将被测系统的最新版本交付给测试人员或用户，以便进行评估、评审或测试，也就是按照一定的需求将最新版本的代码发布到测试环境中。持续交付其实可以看作持续集成的下一步。持续交付重点强调的是被测系统能够随时随地交付，这决定了任何新版的被测系统都可以按照一定的需求具备可交付性。
持续部署是指定时或按需将某一稳定版本发布到生产环境中，从而为最终用户提供服务。持续部署完成了软件从开发直到部署的全流程定义，并强调自动部署到生产环境中的流程，这决定了被测系统的可部署特性。持续部署可以看作持续交付的下一步。持续部署需要经历自动测试、构建、部署等环节才能完成。
2．Postman和持续集成
在持续集成中，有一个很重要的环节就是持续测试。可通过持续集成平台调取自动化测试，从而完成质量保障工作。我们已经完成了基于Postman的接口测试脚本，接下来如何将接口测试脚本赋能给持续集成平台呢？
此时就需要借助Newman这款工具，Newman相当于Shell环境下的Postman。在将基于Postman的接口测试脚本导出并推送到GitHub仓库之后，持续集成平台就可以通过拉取对应的接口测试脚本并借助Newman工具加以执行，来完成对持续集成平台的赋能了。
上面仅仅提供了思路，具体可通过持续集成平台Jenkins与Newman工具运行Postman脚本来完成。
