如何解耦web应用程序GUI测试的DB依赖关系

Question

使用Selenium API进行WebApplication GUI测试是验证应用程序行为的伟大而重要的方法(当然只在特定程度上)。这里的主要问题是对其他应用程序也使用的其他资源的依赖。尽管应用程序(在测试中)部署在测试平台上，但其他被测试的应用程序也部署在测试平台上，并使用这些数据库。这里的结果是测试不能正常工作，因为应用程序会相互干扰，并操纵或删除它们所依赖的其他测试数据!

"企业"系统的体系结构不依赖于WebServices，使用WebServices，一个应用程序将能够从另一个应用程序域检索数据。相反，它们通过数据库链接通过自定义的读、写、执行权限紧密耦合，以便每个应用程序能够通过JPA和EJB检索所需的数据。

为了克服这个问题，我可以想到以下选项:

1. 我的最爱!对于每个应用程序，都存在一个独特的RESTful WebService，它作为DB和各自的WebApplication之间的层，以及依赖于应用程序的通信通道。

   • Pro: 最大的灵活性，因为它很容易在编译时用测试虚拟替换依赖
   • Con: 大量的初始工作，创建web服务，用rest服务代替直接访问数据库。以及虚拟实现的维护。

2. 第二种方法是通过执行逻辑顺序执行不同web应用程序的测试执行，该逻辑也在执行开始之前替换数据库(DB设置)。

   • Pro: 低努力，因为我只需要提供和维护一个数据库转储与常用的记录。
   • Con: 无法并行化。测试执行必须被安排。漫长的等待时间!

3. 在可维护性方面可能是最差的，但我也想提到这个选项，因为第二个选项可能会导致长时间的空闲时间。因此，对于每个web应用程序，都存在一个不同的测试执行环境，该环境提供所有依赖的数据库。数据库替换的工作原理与第二种方法相同。

   • Pro: 与第二种方法相同，加上高灵活性和无等待时间(调度)，因为每个应用程序都有其专用的测试执行环境。
   • Con:占用大量资源，导致测试系统混乱，这(可能)需要一个专门的系统管理员

Answer 1

我不太确定这个平台是如何工作的

这里的主要问题是对其他应用程序也使用的其他资源的依赖。尽管应用程序(在测试中)部署在测试平台上，但其他被测试的应用程序也部署在测试平台上，并使用这些数据库。

但是每个应用程序都应该有自己的DB和专用资源。即使您的集成测试依赖于其他SUT，这也不应该影响它的内部工作。毕竟这是一个黑匣子。同样适用于UI测试—为什么它们应该(显式地)关心SUT的DB中发生了什么?

，因为应用程序将相互干扰，并操纵或删除它们所依赖的其他测试数据!

恕我直言，您需要的是更好的测试夹具策略。以下是解释:

• 新鲜夹具

最低夹具

• 共享夹具

Answer 2

看来你已经有答案了。选项#3适用于大型数据库，因为很难"模拟"那么多数据。对于拥有数百万个条目的数据库，我一直在这样做，以确保我们的查询不会影响应用程序的性能。

选项#1显然是小型应用程序的最佳选择。这确实需要额外的努力，但在前端和后端之间有一个明确的分离是非常有价值的。