我们有超过 150 个邮递员测试。它们是**集成测试**，它们针对实际数据库和服务结构实例运行。他们失败了，因为他们没有与不时合并到整合的发展保持一致。
他们很高兴发现一些错误。它是在产品的每个新构建上运行的一组测试，以在构建发布到测试团队手中之前验证构建是否可测试。我们正在使用 Newman 从控制台运行它们。同时，我们希望改进我们的持续部署管道。
问题
1.我们应该在哪里持有/运行它们？是否有运行邮递员 API 测试的云工具？
我们应该如何使用/接近它们？ （每次提交后？每天？）
我们可以将邮递员 API 测试称为集成测试或冒烟测试吗？
【问题讨论】：
标签： api postman azure-service-fabric newman
我对冒烟测试的理解是，它们的规模应该相对较小（150 次测试乍一看似乎太多了）并且实际上“从不”（或不太经常）失败。您只想为您的应用程序包含关键任务端点，并且测试应该执行得非常快。
冒烟测试的范围是通过测试简单的故障将发布/构建或安装标记为不可接受/失败，例如（但不一定限于）状态代码 200（或其他）并且是JSON 格式的响应。
我不会依赖冒烟测试来查找特定 REST 端点中的实际错误，而是要大致了解事情正在运行。
1.我们应该在哪里持有/运行它们？是否有运行邮递员 API 测试的云工具？
使用版本控制来保存它们并使用 Jenkins 或其他 CI 工具来运行它们。
此外，您可能希望在部署到暂存服务器或生产服务器后运行冒烟测试。
Postman 也提供一些付费工具。
我们应该如何使用/接近它们？ （每次提交后？每天？）
它们应该是您管道的一部分。快速失败！在每次提交或构建后尽可能可靠地运行它们。如果由于白天不可靠的外部依赖关系而无法做到这一点 - 例如 - 在晚上运行它们。
我们可以将邮递员 API 测试称为冒烟测试吗？
你可以随意称呼他们！
这个问题更像是：“你到底想达到什么目标？”。如果您的某些测试做得太多或经常失败，可能是因为它们更像是集成测试。
【讨论】：