Question

结束测试意味着从外部边界使用应用程序来验证它的行为。目前我只对一个可执行的文物做了书面测试。我该如何测试由安装在不同主机上的多个文物组成的系统?

我看到两种选择。

The tests set up the whole system and exercise it from the very outer edges.
Each artifact is end to end tested in isolation, relying on the test content to enforce the protocol between them.

难道只有其中之一能遵守吗?还是其中之一更愿意遵守呢?还是可以互换呢?如果可以互换,它们之间有什么利弊呢?

Answer 1

尽管我认为这取决于上下文,但我更倾向于第一种选择。

我希望我的测试能够尽可能接近于使用案例(BDD风格)(免责声明我滥用了术语使用案例 ) 。这些使用案例可能涉及多个应用和子系统。

示例: A后台办公室管理员可以从公共界面查看用户所做的交易。

这里,后台办公室行政界面和公共界面是不同的应用程序,但都包含在同一使用案例中。

映射您的问题的这些想法, 即您在不同的主机上安装了子系统, 我想说这取决于它是如何使用的, 从用户/ 行为者的角度。使用案例是否跨越多个子系统?

此外,系统被安装在多个主机上对测试来说可能并不重要。您可以在测试中用方法调用取代进程间通信, 并在测试期间将整个系统都放在同一程序内, 从而降低复杂性。测试中只能核查进程间通信, 以此补充这个测试。

<强>编辑:

我知道,我忘了把为什么我更喜欢测试整个系统。

您的资产是特性, 即行为, 而代码是一种责任。因此您喜欢测试行为, 而不是代码( BDD 样式) 。

如果您正在分别测试每个子系统, 您正在测试代码, 而不是特性。为什么? 当您将您的系统分成子系统时, 您基于某些技术原因这样做了。当您学习更多时, 您可能会发现选择的接缝是亚最佳的, 并且想要将一些责任从一个子系统转移到另一个子系统。同时您必须修改测试和生产代码, 让你没有安全网。这是测试实施细节的典型症状。

说到这里,这些测试太直率了,无法测试一切。所以在必要时,你还需要对细节进行补充测试。

Answer 2

在 any case 中,每个文物的端对端分别测试将非常不可分离。这将确保每个文物的声响。

此外,您可能还想测试人工制品的构成。这将在人工制品之间的相互作用中引起问题。我不知道您的情况, 但重要的是有一个测试环境, 即生产的副本。在测试环境中测试系统是一个好主意。您可能还想在生产环境中测试系统; 这也许可行, 也可能不可行。例如, 如果您的系统处理信用卡支付, 您可能想要避免生产系统的测试付款。

无论如何,单独测试每个系统比测试其构成更为重要。一旦您知道自己的文物在单独情况下声音良好, 截取交互测试会更容易得多。如果您只有整个系统的端对端测试, 则更难理解测试失败时哪里出错了。

友情链接