运行集成测试的最佳实践是什么？

Question

我们有超过150个邮递员测试。它们是**集成测试**，它们针对实际的数据库和服务结构实例运行。他们失败的原因在于他们没有与不断融合的开发人员排在一起。

他们很高兴找到一些错误。它是在产品的每个新版本上运行的一组测试，用于在构建发布到测试团队手中之前验证构建是否可测试。我们使用纽曼从控制台运行它们。同时，我们希望改进我们的持续部署管道。

问题

1.Where我们应该持有/运行它们？是否有云工具来运行邮差API测试？

1. 我们应该如何使用/处理它们？ （后每一个承诺？报？）

2. 我们可以调用API邮递员测试，集成或烟雾测试？

Answer 1

我的冒烟测试的理解是，他们应该是在大小（150个测试似乎一见钟情太多）相对较小并且几乎“从不”（或不经常）失败。您只想为应用程序包含任务关键端点，并且测试应该执行得非常快。

烟雾测试的范围是通过测试简单的故障，例如（但不一定限于）是状态代码200（或别的东西）和（或）其他）而将发布/构建或安装标记为不可接受/是JSON格式的响应。

我不会依赖烟试验发现在一个特定的REST端点实际的错误，而是让事情正在运行的一般概述。

1.Where我们应该持有/运行它们？是否有云工具来运行邮差API测试？

使用版本控制来保存它们并使用Jenkins或其他CI工具来运行它们。

另外，你可能要登台或生产服务器上部署后运行冒烟测试。

邮差提供了一些支付工具，以及。

我们应该如何使用/方法呢？ （每次提交后？每天？）

他们应该是你的管道的一部分。快速失败！如果可能，在每次提交或构建后运行它们。如果由于白天不可靠的外部依赖造成这种情况不可行 - 例如 - 在晚上运行它们。

我们可以调用API邮递员测试，冒烟测试？

你可以打电话给他们任何你喜欢的！

的问题更像是：“什么是你究竟想达到什么目的？”。如果你的一些测试做得太多或者经常失败，那可能是因为它们更像集成测试。