什么是端到端训练测试

by Phong Huynh

由Phong Huynh

为什么端到端测试对您的团队很重要 (Why End-to-End Testing is Important for Your Team)

我们的团队如何通过4个简单的步骤实施端到端测试 (How our team implemented end to end testing in 4 easy steps)

At Hubba, our business needs are always evolving and the speed of development needs to catch up with it. One of the ways to keep the team moving forward without breaking everything is End-to-end (E2E) testing.

在Hubba ，我们的业务需求总是在不断发展，并且发展速度也需要跟上它。保持团队前进而不破坏一切的一种方法是端到端(E2E)测试。

Having a full test suite with E2E tests allows us to move quickly. It allows developers to push code without worrying about breaking things. It enables releases with extra confidence. And, it catches errors that are missed during manual regression testing.

拥有包含E2E测试的完整测试套件，使我们能够快速发展。它使开发人员无需担心会破坏代码就可以推送代码 。它使发布充满信心 。而且，它可以捕获手动回归测试期间遗漏的错误 。

什么是端到端测试？ (What is E2E Testing?)

End-to-end testing is where you test your whole application from start to finish. It involves assuring that all the integrated pieces of an application function and work together as expected.

端到端测试是您从头到尾测试整个应用程序的地方。它涉及确保应用程序的所有集成部分都能正常工作并按预期工作。

End-to-end tests simulate real user scenarios, essentially testing how a real user would use the application.

端到端测试模拟了真实的用户场景，从本质上测试了真实用户将如何使用该应用程序。

An example for Hubba’s case would be an E2E test case for a user sign up.

Hubba案例的一个示例是用户注册的E2E测试案例。

The test would involve:

该测试将涉及：

opening Hubba in a browser and searching for certain elements在浏览器中打开Hubba并搜索某些元素
performing a set of clicks and keyboard types执行一组点击和键盘类型
ensuring that a user is successfully created确保成功创建用户

你为什么要在乎？ (Why Should You Care?)

At Hubba, we strongly believe in test automation. We currently write unit tests and integration tests for our code.

在Hubba，我们坚信测试自动化。当前，我们为代码编写单元测试和集成测试。

These tests are used to:

这些测试用于：

specify our system指定我们的系统
prevent bugs and regression防止错误和回归
perform continuous integration进行持续整合

Furthermore, these tests run as frequently as possible to provide feedback and to ensure that our system remains clean.

此外，这些测试会尽可能频繁地运行以提供反馈并确保我们的系统保持清洁。

The motivation for an additional layer of E2E tests lies in the benefits of having a fully automated test suite. These benefits include increasing developer velocity, as well as other benefits previously mentioned.

进行另一层E2E测试的动机在于拥有全自动测试套件的好处。这些好处包括提高显影剂速度 ，以及前面提到的其他好处。

E2E tests allow us to cover sections of the application that unit tests and integration tests don’t cover. This is because unit tests and integration tests only take a small piece of the application and assess that piece in isolation.

E2E测试使我们能够涵盖应用程序中单元测试和集成测试未涵盖的部分。这是因为单元测试和集成测试仅占用应用程序的一小部分，并单独评估该部分。

Even if these pieces work well by themselves, you don’t necessarily know if they’ll work together as a whole. Having a suite of end-to-end tests on top of unit and integration tests allows us to test our entire application.

即使这些部分单独工作良好，您也不一定知道它们是否可以整体工作。在单元测试和集成测试之上拥有一套端到端测试，使我们能够测试整个应用程序。

The faster code fails, the less bugs we find in QA, the faster our QA cycles are -Edward Robinson

代码失败的速度越快，我们在质量检查中发现的错误越少，我们的质量检查周期就越快-Edward Robinson

This is a testing pyramid from Kent C. Dodd’s blog which is a combination of the pyramids from Martin Fowler’s blog and the Google Testing Blog.

这是来自Kent C. Dodd博客的测试金字塔，它是Martin Fowler博客和Google Testing Blog金字塔的结合。

The majority of your tests are at the bottom of the pyramid. As you move up the pyramid, the number of tests gets smaller. Going up the pyramid, tests get slower and more expensive to write, run, and maintain.

您的大部分测试都位于金字塔的底部。当您沿着金字塔向上移动时，测试数量会减少。在金字塔上，编写，运行和维护的测试变得越来越慢，而且成本更高。

We want to write a very little amount of end-to-end tests due to the fact that they are slow to run and are expected to change. This is especially important because as a startup we want to move fast.

由于它们运行缓慢且预计会发生变化，因此我们希望编写少量的端到端测试。这一点特别重要，因为作为一家初创公司，我们希望快速发展。

Google often suggests a 70/20/10 split: 70% unit tests, 20% integration tests, and 10% end-to-end tests. The exact mix will be different for each team, but in general, it should retain that pyramid shape. - Google Testing Blog

Google经常建议采用70/20/10的划分：70％的单元测试，20％的集成测试和10％的端到端测试。每个团队的确切组合将有所不同，但通常，它应保持金字塔形状。 -Google测试博客

4个入门步骤 (4 Steps to Get Started)

1.选择一个测试框架 (1. Choose a Testing Framework)

The first action we took to get started was to evaluate various E2E testing frameworks. Our evaluation does not include looking at all of a framework’s features, but more of a high-level impression. The main criteria was to pick a framework that was easy to set up and quick to get started.

我们开始采取的第一步措施是评估各种E2E测试框架。我们的评估不包括查看框架的所有功能，而是更多的高级印象。主要标准是选择一个易于设置且快速入门的框架。

We did a quick run through of the following frameworks: CasperJS, Protractor, Nightwatch, and Testcafe.

我们快速浏览了以下框架： CasperJS ， Protractor ， Nightwatch和Testcafe 。

We made the decision to go with TestCafe because of the easy installation and launch. It is fairly new but getting popular. Most noteworthy, it is easy to set up because it doesn’t require WebDriver.

由于易于安装和启动，我们决定选择TestCafe。这是相当新的东西，但越来越受欢迎。最值得注意的是，它很容易设置，因为它不需要WebDriver。

Due to the fact that WebDriver wasn’t required, there was no need to install and maintain additional products and browser plugins. Tests can be run right after npm install. This allowed us to quickly write a proof of concept/prototype that gets us up and running.

由于不需要WebDriver，因此无需安装和维护其他产品和浏览器插件。测试可以在npm安装后立即运行。这使我们能够快速编写概念/原型证明，从而使我们起步并运行。

TestCafe uses async/await and ES2017 code for the tests files. It also has an implicit auto-waits mechanism which means TestCafe automatically waits for XHR requests and page loads. So you don’t need to take care of it in your code.

TestCafe对测试文件使用async / await和ES2017代码。它还具有隐式自动等待机制，这意味着TestCafe自动等待XHR请求和页面加载。因此，您无需在代码中进行处理。

Pure Node.js - TestCafe is built on top of Node.js and doesn’t use Selenium or need plugins to run tests in real browsers. It integrates and works great with modern development tools.纯Node.js-TestCafe建立在Node.js之上，不使用Selenium或不需要插件即可在真实的浏览器中运行测试。它与现代开发工具集成在一起并可以很好地工作。
No additional setup or configuration - TestCafe is all set to run tests right after npm install.

无需其他设置或配置-TestCafe都设置为在npm install后立即运行测试。
Complete test harness - With a single launch command, TestCafe starts the browsers, runs tests, gathers results and generates reports.完整的测试工具-通过一个启动命令，TestCafe即可启动浏览器，运行测试，收集结果并生成报告。

2.选择重要的测试 (2. Pick the Important Tests)

The second step was to determine the core test cases we would write for our application.

第二步是确定我们将为应用程序编写的核心测试用例。

One of our pain points revolves around QA regression testing. Our quality assurance (QA) cycle consists of manual testing that includes a regression test at the end.

我们的痛点之一是围绕QA回归测试。我们的质量保证(QA)周期包括手动测试，最后包括回归测试。

These regression tests is a manual process that take a long time and can potentially miss things due to human error.

这些回归测试是一个手动过程，需要花费很长时间，并且可能由于人为错误而丢失某些内容。

We decided on writing test cases related to those regression tests. For Hubba, this included basic - but important functionality like user sign up/login, and creating a product.

我们决定编写与这些回归测试相关的测试用例。对于Hubba，这包括基本但重要的功能，例如用户注册/登录和创建产品。

The initial batch of test cases:

首批测试用例：

Brand/Buyer/Influencer sign up品牌/买方/影响者注册
Login登录
Create a product创建一个产品

3.集成到CI / CD管道 (3. Integrate into a CI/CD Pipeline)

The next step was to integrate this into a Continuous Integration and Continuous Deployment, or CI/CD pipeline. The goal of adding E2E tests to our pipeline is to catch any errors or failing tests before code is shipped to production.

下一步是将其集成到持续集成和持续部署或CI / CD管道中。在我们的管道中添加端到端测试的目的是在代码交付生产之前捕获任何错误或失败的测试。

We thought of two different ways of integrating this into our system.

我们考虑了将其集成到系统中的两种不同方式。

Running the tests every time new code gets pushed to the project.每次将新代码推送到项目中时，都要运行测试。
Running the tests periodically.定期运行测试。

We decided on running our E2E tests on a periodical nightly/weekly basis versus executing the tests on every code change as part of the CD pipeline. The reason for this is because E2E tests are slow to run.

我们决定定期/每晚进行E2E测试，而不是对CD管道中的每个代码更改都执行测试。这样做的原因是因为E2E测试运行缓慢。

We don’t want these tests to slow down our pipeline since it will delay our process and cycle and affect pull requests, merges, and deployments to different environments.

我们不希望这些测试减慢我们的流程，因为这会延迟我们的流程和周期，并影响拉取请求，合并以及在不同环境中的部署。

We wanted a set of core E2E tests we can run on a regular basis that lets us know if anything is off or broken. This is why we decided on running these tests on a nightly basis via a Jenkins cron job.

我们想要一套可以定期运行的核心E2E测试，让我们知道是否有任何故障或损坏。这就是为什么我们决定通过Jenkins cron作业每晚进行这些测试的原因。

4.创建概念/原型证明 (4. Create a Proof of Concept/Prototype)

The last step was to create a proof of concept or prototype to show the E2E tests running and then incorporate them into our system.

最后一步是创建概念证明或原型，以显示正在运行的E2E测试，然后将其合并到我们的系统中。

We also had to decide to either completely integrate the E2E tests into our current code base or to have a one-off project that is separate from the main code base.

我们还必须决定将E2E测试完全集成到我们当前的代码库中，或者要有一个与主代码库分开的一次性项目。

For the initial prototype, we went with having a new repository isolated from our main code base and running our tests in the staging environment.

对于最初的原型，我们将新的存储库与主要代码库隔离开来，并在登台环境中运行测试。

In conclusion, while E2E tests are very expensive to maintain, we believe that they are highly valuable as they are an excellent analogue to user behavior which helps us test basic user functionality on Hubba.

总而言之，尽管E2E测试的维护成本非常高，但我们认为它们具有很高的价值，因为它们是用户行为的出色模拟，可以帮助我们在Hubba上测试基本的用户功能。

翻译自: https://www.freecodecamp.org/news/why-end-to-end-testing-is-important-for-your-team-cb7eb0ec1504/