tdd - 端到端测试整个系统的最佳实践

Question

端到端测试意味着从外部边界运行应用程序以验证其行为。到目前为止，我只对单个可执行工件进行了书面测试。我应该如何测试由部署在不同主机上的多个工件组成的系统？

我看到了两种选择。

是否有明确的理由只遵守其中之一，或者是首选其中之一，还是可以互换？如果可以互换，那么它们之间有哪些优缺点？

score 1 · Accepted Answer

尽管我认为这取决于上下文，但我更喜欢第一种选择。以下是我的随机想法：

我希望我的测试尽可能紧密地映射到用例（BDD 风格）（声明我误用了用例这个术语）。这些用例可能跨越多个应用程序和子系统。

示例：后台管理员可以从公共界面查看用户进行的交易。

在这里，后台管理界面和公共界面是不同的应用程序，但它们包含在同一个用例中。

将这些想法映射到您在不同主机上部署子系统的问题，我想说这取决于从用户/参与者的角度来看它的使用方式。用例是否跨越多个子系统？

此外，系统部署在多个主机上这一事实可能对测试并不重要。您可以在测试中将进程间通信替换为方法调用，并在测试期间将整个系统置于同一进程中，从而降低复杂性。用仅验证进程间通信的测试来补充这一点。

编辑：

我意识到我忘了包括为什么我更喜欢测试整个系统。

您的资产是特征，即行为，而代码是负债。因此，您想测试行为，而不是代码（BDD 样式）。

如果您分别测试每个子系统，那么您是在测试代码，而不是功能。为什么？当您将系统划分为子系统时，您这样做是基于一些技术原因。当您了解更多时，您可能会发现所选接缝不是最佳的，并且希望将一些责任从一个子系统转移到另一个子系统。而且你必须同时修改测试和生产代码，让你没有安全网。这是测试实现细节的典型症状。

也就是说，这类测试太生硬，无法测试所有内容。因此，在必要时，您还需要对细节进行补充测试。

score 1 · Accepted Answer

在任何情况下，对每个工件进行端到端的单独测试都是非常可取的。这将确保每个工件都是健全的。

此外，您可能想要测试工件的组合。这将在工件之间的交互中发现问题。我不知道您的情况，但是拥有一个作为生产副本的测试环境很重要。在测试环境中测试系统是一个非常好的主意。您可能还想在生产环境中测试系统；这可能可行或不可行。例如，如果您的系统处理信用卡付款，您可能希望避免在生产系统上进行测试付款。

无论如何，单独测试每个系统比测试组合更重要。一旦你知道你的工件是孤立的，捕捉交互测试就会容易得多。如果您只有整个系统的端到端测试，那么当测试失败时，要理解错误在哪里要困难得多。

2 回答 2