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

Question

我已经阅读了很多有关e2e测试的内容，我无法理解的一件事是e2e测试应该有多“真实”。

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

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

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

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

Answer 1

我目前在一家大型知名公司的测试工具和框架团队工作。因此，虽然我不是专家，但这是我工作的一部分。我将专门讨论网络测试。对于 iOS 和 Android 等原生应用程序的测试有些不同，我对这些方面不是很熟悉。

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

通常 e2e/集成测试应该可以在开发和生产环境中运行。根据您的设置，您的开发环境可能正在使用生产数据库的一些半频繁更新的快照。在其他情况下，您的本地环境可能会访问实际的生产数据库。这两种方法各有利弊，但这在很大程度上取决于您的公司或项目的规模。例如，如果你在一家拥有专门团队的大公司，你可以看到每天有很多变化影响到生产数据库，而小团队则每周的生产数据库快照可能足以进行本地测试。i 在基础级别，所有集成测试都应该被视为真实的。在处理网络应用程序时，我们还必须考虑许多其他因素，例如不同的网络浏览器、网络活动/可用性等。

在本地运行集成测试应该或多或少地对你的开发服务器做同样的事情，他们将对登台和生产做同样的事情。除了让应用程序检测它是否在开发、登台或生产环境中运行以切换 URL 和各种凭据外，应用程序应该以完全相同的方式运行。

关于您关于身份验证的问题，答案是肯定的。让我们看 2 个显示不同考虑因素的示例。

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

现在是另一个极端。假设你的项目非常大。数以百万计的用户和数百名员工每天都在集体更改代码库和数据库。有各种各样的方法可以设置基础设施来处理各种工程任务。数据太多，数据库更改太频繁，无法使用本地快照。在这种规模下，您可能正在进行持续集成并在每次提交时运行测试。您希望这样做，以便传入的更改不会进入生产并导致重大问题。您可能正在针对不断更新的暂存数据库，或者甚至针对您的生产数据库本身运行本地开发环境。（尝试规划暂存数据库，因为它避免了许多其他问题。）

现在，只有一小组专门的测试用户开始成为问题。测试一直在运行，既是自动化的，也是由数十名工程师进行的，他们都在做自己的工作。由于暂存数据库可能是共享的，您很容易开始遇到奇怪的冲突，因为同一个测试用户正在做各种事情并开始导致测试失败。我见过的一个很好的解决方案是一种测试帐户结帐服务器。您创建了 100 个或 1000 个（或更多）测试用户帐户。当您的集成测试运行时，它们实际上会从服务器检出测试用户帐户。测试完成后，集成测试会清除他们对该用户所做的任何更改，并告诉结帐服务器该用户再次空闲。然后它会被某人/其他人随机检查，然后循环继续。

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

1. 您应该始终拥有与常规用户帐户完全相同的专用测试用户帐户，专门用于测试。
2. 根据团队和项目的规模，如果小一些专用帐户就可以了。如果在更大范围内工作，您需要更多的专用测试帐户，并且可能需要一个自动化服务，允许单独的测试运行以根据需要签出用户。
3. 测试应该总是自己清理。如果测试创建了一个存储在数据库中的 TODO。测试运行完成后，应从数据库中删除该 TODO。如果您对此不持保留态度，您最终会遇到数据不一致的错误和问题。上帝保佑这在生产中发生。
4. 只需要担心单元测试的模拟数据，除非你在一个非常好的和专门的工程环境中工作，在那里你有人致力于让数据库模拟始终保持最新。如果你能做到这一点，你的集成测试将非常快，你真的不必担心 db 的东西。但是如果没有专门的支持，它很难随着时间的推移保持这种状态。

Answer 2

我一直在阅读很多关于 e2e 测试的文章，但我无法理解的一件事是 e2e 测试应该是多么“真实”。

E2e 应该尽可能地模仿生产系统，更重要的是，您可以使用 e2e 自动化来重现任何生产问题，例如数据，

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

e2e 自动化必须与任何资源/数据库/datatsore/消息总线等一起工作，并与包括本地/远程或云平台在内的任何环境一起工作

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

只要应用程序凭据是应用程序配置的一部分，您就可以灵活地控制专用于测试的凭据。我强烈建议运行并行的全自动 e2e 专用基础设施，这不会危及或共享生产机密。

假设我有臭名昭著的 TODO 应用程序。我有一个让用户登录的测试。登录后，我想测试用户是否能够创建一个 TODO。此 TODO 保存在数据库中。

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

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

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

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

以下是一些有趣的读物：

• 数据测试策略
• ETL 部分 e2e 测试
• 实际的 e2e 测试示例
• 无服务器 e2e 实践示例