Question

我已经阅读了很多有关e2e测试的内容，我不明白的是e2e测试应该有多“真实”。

不管我用于e2e测试的工具是什么，我都已经看到它们大部分时间都在本地，开发或alpha环境中使用。

如果我的应用程序具有身份验证，是否应该在数据库中创建一个具有有效凭据的“测试”用户？我应该在Alpha甚至生产环境中这样做吗？该测试用户还如何登录我的应用程序？

说我有臭名昭著的TODO应用程序。我有一个用于登录用户的测试。登录后，我想测试用户是否可以创建TODO。该待办事项保存在数据库中。

运行测试后，我应该运行一些方法来删除e2e测试期间创建的数据吗？还是应该在保存请求并模拟响应之前拦截该请求（这将是e2e测试的反模式）？

Answer 1

端到端测试涉及确保应用程序的集成组件按预期运行。整个应用程序都在真实的场景中进行了测试，例如与数据库，网络，硬件和其他应用程序进行通信

E2E测试是最抽象的一种测试。它测试集成组件的“流程”和“完整性”。作为测试，它或多或少是一个完整的黑盒，并且所有部件都应可互换。集成测试，检查代码组件是否可互换。 E2E在测试级别（nginx或Apache，PHP或Java？还是MySQL女士）上领先一步

E2E测试的定义也是业务需求的直接转换，并由需求工程流程或多或少地进行了预定义。

例如，

Gurkin是一种将用例转换为功能和场景的语言。示例：

Feature:  Login functionality of social networking site Facebook. 
Given:  I am a facebook user. 
When: I enter username as username. 
And I enter the password as the password 
Then I should be redirected to the home page of facebook

根据主题的复杂性，其自身的用例/功能可能由很少或很多句子组成。无论如何：它应该与您的应用程序完全独立。

如何处理测试取决于您，并且取决于您的应用程序：

您可能会遇到某些情况（注册用户？），或者想每天使用Cron清理数据库？

编写每个功能的测试也需要很高的性能。大多数情况下，您会针对演练（应用程序最重要的部分-资金来源）或功能（这些功能非常重要，但从未经过积极测试（Cookie信息，退订电子邮件，法律信息等））编写这些测试。）

Answer 2

我目前正在我们的测试工具和框架团队的一家大型知名公司工作。因此，尽管我不是专家，但这是我工作的一部分。我将专门讨论Web测试。对于iOS和Android等本机应用程序，测试有所不同，我对这些方面并不十分熟悉。

e2e（端对端）和集成测试之间的术语在某种程度上是可以互换的，而单元测试则具有更具体的定义。

通常，端到端/集成测试应可在开发和生产环境中运行。根据您的设置，您的开发环境可能正在使用生产数据库的一些半频繁更新的快照。在其他情况下，您的本地环境可能会达到实际的生产数据库。两种方法都有优点/缺点，但是很大程度上取决于您公司或项目的规模。例如，如果您在一家拥有专门团队的大公司中，则可以看到每天对生产数据库进行许多更改，而对于一个小型团队而言，每周的产品数据库快照可能足以在本地进行测试。一世在基础级别上，所有集成测试都应视为真实测试。在处理Web应用程序时，我们还必须考虑许多其他因素，例如不同的Web浏览器，网络活动/可用性等。因此，为api调用模拟数据将允许进行超快速测试，但又增加了另一层次的复杂性确保模拟与最新数据库保持同步。

在本地运行集成测试应该或多或少地对开发服务器执行与对登台和生产进行的相同操作。除了让应用程序检测其是否在开发，登台或生产环境中运行以切换URL和各种凭据外，应该期望该应用程序的行为完全相同。

关于身份验证的问题，答案是肯定的。让我们看两个显示不同注意事项的示例。

假设您的项目很小。您在生产环境中创建了一些真实帐户，并且您的数据库每周都会快照一次，以供您在本地开发环境中使用。您只需要根据需要与一个或多个这些用户一起运行集成测试。由于本地测试仅影响本地数据库，因此您无需担心所生成的数据，因为它不会影响生产。您团队中的其他工程师可以使用相同的用户，而不必担心。如果一位工程师对db模式，ORM等进行了一些更改，那么每个人都只会获得db快照的新副本并继续工作。

现在换个极端。假设您的项目很大。每天都有数以百万计的用户和数百名员工共同对代码库和数据库进行更改。建立基础结构的方式有很多种，可以处理各种工程任务。数据太多，并且数据库更改频繁，以致于无法使用本地快照。以这种规模，您可能正在进行持续集成，并在每次提交时运行测试。您想要这样做，以使传入的更改不会影响到生产并引起重大问题。您可能正在针对不断更新的登台数据库甚至是生产数据库本身运行本地开发环境。（尝试为暂存数据库进行规划，因为它避免了很多其他问题。）

现在，只有一小部分专用测试用户开始成为一个问题。测试一直在自动进行，并且由数十名工程师共同完成各自的工作。由于登台数据库可能是共享的，因此您可以轻松地开始产生奇怪的冲突，因为同一测试用户正在做各种事情，并开始导致测试失败。我看到的一个很好的解决方案是一种测试帐户结帐服务器。您创建了100个或1000个（或更多）测试用户帐户。在运行集成测试时，它们实际上是从服务器中签出测试用户帐户。测试完成后，集成测试将清除他们对该用户所做的任何更改，并告知结帐服务器该用户再次有空。然后它会被其他人/其他人随机签出，并且该循环继续进行。

因此，与您的问题直接相关的要点：

您应该始终拥有专用的测试用户帐户，该帐户与常规用户帐户完全相同，只是专用于测试。
取决于团队和项目的规模，如果很小，可以使用几个专用帐户。如果工作规模更大，则需要更多专用的测试帐户，并且可能需要一种自动化服务，该服务允许单个测试运行以根据需要签出用户。
测试应始终在清理之后进行。如果测试创建的TODO被存储在数据库中。当测试完成运行时，应从数据库中删除该TODO。如果您对此不太满意，最终将遇到错误和数据不一致的问题。上帝禁止这种情况在生产中发生。
只担心为单元测试模拟数据，除非您在一个非常好的专用工程环境中工作，在该环境中，有人致力于使数据库模拟始终保持最新状态。如果您能够做到这一点，那么集成测试将非常快，并且您不必真正担心数据库方面的问题。但是，如果没有专门的支持，很难随着时间的推移保持这种状态。

Answer 3

我已经阅读了很多有关e2e测试的内容，我不明白的是e2e测试应该有多“真实”。

E2e应该尽可能模拟生产系统，此外，您还可以使用e2e自动化来重现任何生产问题，例如数据，

不管我用于e2e测试的工具是什么，我都已经看到它们大部分时间都在本地，开发或alpha环境中使用。

e2e自动化必须与任何资源/数据库/数据库存储/消息总线等以及包括本地/远程或云平台在内的任何Enironmet一起使用

如果我的应用程序具有身份验证，是否应该在数据库中创建一个具有有效凭据的“测试”用户？我应该在Alpha甚至生产环境中这样做吗？该测试用户还如何登录我的应用程序？

只要应用程序凭据是应用程序配置的一部分，您就可以灵活地控制专用于测试的凭据。我强烈建议您运行并行的全自动e2e专用基础架构，该基础架构不应损害或共享生产秘密。

说我有臭名昭著的TODO应用程序。我有一个用于登录用户的测试。登录后，我想测试用户是否可以创建TODO。该待办事项保存在数据库中。

通过e2e测试，您有兴趣识别所有应用程序输入（例如UI交互或REST / HTTP请求），配置文件以及带有验证规则的输出。其中包括UI更改，生成的日志/消息，数据库/数据库更改。

运行测试后，我应该运行一些方法来删除e2e测试期间创建的数据吗？还是应该在保存请求并模拟响应之前拦截该请求（这将是e2e测试的反模式）？

作为e2e测试的一部分，您需要注意设置初始应用程序状态以及每个用例的状态（如果适用）。使用e2e测试时，您想测试所有应用程序行为，因此在这里没有太多地方可以进行模拟。运行测试后，您可以销毁所有应用程序资源，服务清除数据库。我认为这是可选步骤，因为设置应用程序或用例状态可解决资源/数据库准备工作。

如果您没有正确的工具集和良好的数据组织策略，那么最终的e2e测试可能会具有挑战性，尤其是随着时间的流逝，您将针对中小型应用程序进行数百次用例测试。除此之外，您还需要e2e测试工具，该工具可与以任何语言（java，javascript golang，您可以命名）编写的多堆栈应用程序一起使用，并支持包括localbox，docker，kubernetess，无服务器云在内的任何平台的自动化。

以下是一些证明性的读物：

Answer 4

这是我们的测试工作方式。这种程度的努力在许多组织中可能并不可行，但我确实认为效果很好。相对于您的原始问题，我认为，在可能的情况下，请在模拟过程中使用真实事物，例如，使用下面概述的真实数据库。

基本体系结构

Sql Server数据库
C＃中间件
角形前端

已安装完整CI / CD。 CI在docker容器中运行。每次推送都会运行整个测试策略（UAT测试除外）。

中间件

单元测试：
- 类级别的测试。
- 数据库连接指向内存中的实现。
- 依赖类使用NSubstitute模拟。
集成测试：
- 我们的基本服务库具有测试配置基础结构，该基础结构允许进行模拟：
  - 其他外部http服务。
  - 内部服务。
  - 身份验证对象（用户，令牌等）。
  - 通过依赖关系注入通过接口的其他任何实体。
- 数据库
  - 运行测试的docker容器引用了另一个包含用于Linux的SqlServer的容器（mcr.microsoft.com/mssql/server:2017-latest-ubuntu）。
  - 因此，测试针对的是真实数据库。
  - 该服务拥有一个脚本列表，无论它从哪里开始（不仅在CI中），它都会根据需要执行。因此，在每次CI运行期间，它将播放整个历史记录。但是，这非常快，因为数据库开始为空。
    - 此测试策略中的漏洞是性能测试。
  - 测试配置初始化将连接字符串设置为此本地数据库。
- 真实服务启动，配置用于测试。

前端

通过角度工具+业力进行标准的角度单位/组件测试。

端到端

赛普拉斯是使用的框架。
中间件和前端都已启动。从此处开始的中间件与上述中间件测试下的集成测试以相同的方式（相同的入口点）进行配置。
有些对外部服务的呼叫发生在我们的直接控制范围之外。我们使用柏树钩子来防止发生这些呼叫。

UAT测试

产品所有者在发布之前进行的手动测试。

e2e测试是否应将数据持久保存在真实数据库中？

4 个答案: