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