E2E测试

什么是E2E测试

End-to-End testing

端到端测试

from 百度:

端到端测试是一种软件测试方法，它从头到尾验证整个软件及其与外部接口的集成。
端到端测试的目的是测试整个软件的依赖性、数据完整性以及与其他系统、接口和数据库等的通信，
以模拟完整的生产场景。

我的理解:

在接近用户实际使用的场景和环境下，将整个系统作为一个整体来验证。
对系统的多个完整流程进行测试，从流程的开始执行到结束，以确保系统能符合期望的工作。
这些流程如用户登录， 在电子商务网站上购买一件产品的完整流程（从搜索到支付完成）等。

不同类型的E2E测试

1. 手动测试
在测试环境或终端环境中，进行手动测试，测试一个完整的功能或流程。最常见的测试。 易创建、执行、学习成本低；但重复执行的人力成本高、人为出错风险高。

2. 用代码测试
用代码编写测试用例\脚本进行测试。也是本次分享主要想说的。下文中说的E2E测试也都指这一种测试。

3. 低代码测试
这种测试不要求编写或只需写少量测试代码，可以通过录屏、拖拽流程、设定期望等手段创建测试流程。

这种仅需拖拉拽实现自动化测试的工具由于其优点，一般都比较贵，有些工具也有免费版本，如TestCraft，但这种解决方案也有一定局限性，有些用代码测试能实现的复杂测试场景还不能实现，对于复杂流程+熟练用户的场景，拖拉拽的效率未必比写代码（脚本）高。
目前这类测试工具可能更适用于一些比较简单的流程、功能。
这里暂不深入讨论。

一些流行框架用的什么E2E库

Angular

(ng e2e)[https://angular.io/cli/e2e]

Vue

文档中建议框架： cypress.io, Nightwatch.js(源码中使用), Puppeteer, (TestCafe)[https://testcafe.io/]

React

cypress.io, Puppeteer + jest

E2E测试的特点（优缺点）

优点：

测试结果直接反映系统工作情况（也就更有价值） – 模拟真实用户使用场景，测试结果更贴近用户实际场景，更容易发现用户实际使用过程中会遇到的问题。更容易发现系统多个模块间集成后才会发生的问题，更容易发现环境导致的问题（软硬件、网络、配置等）
可自动重复执行，节约手动执行的时间，降低人手操作的失误概率

缺点：

实现和变更的成本很高
容易被过度使用
执行成本高，除了执行本身耗时外，还有执行的准备工作也很耗时（需要部署、准备实际运行环境， 如浏览器、服务器、数据、硬件、网络等所有所需的依赖，但通过自动化的CI/CD可以降低该成本）
从E2E测试中发现错误的根源问题难度较大，因为E2E测试包含了几乎所有因素（前后端代码、服务器状态、网络、浏览器版本、数据库等等），如果没有其他测试辅助，测试结果跟手动测试几乎相同，需要开发人员从测试结果自行分析判断出错的原因。
对测试环境的状态有影响（如新增删除数据、导致新的操作记录等）

特点：

因为维护的成本和复杂度，E2E测试一般需要先被明确定义目标、边界，一般可用于覆盖其他测试无法覆盖到的空白，或作为其他测试的延申或扩展。

测试金字塔 （划重点）

因为E2E测试的特点，如果单单依赖E2E测试来完成自动化测试明显是不明智的，高昂的维护成本会让我们与最主要的目标：“省时间”背道而驰。 所以
这里我们需要引入测试金字塔的概念。

这是一个比较大的内容，这里只简单讲一下。 先上图：

我的理解：

测试金字塔是一种在自动化测试中，对多种类型测试如何搭配的建议(可以理解为一种测试策略的建议)，以此来达到高质量、高可靠性且较低成本等目标。

如图所示，在金字塔中，越接近底部的测试开发成本越低、执行速度越快，越接近问题的原因（往往也对解决问题帮助越大）。 

所以测试金字塔建议尽可能多写靠近底部的测试，越往上的测试类型写的用例越少。

然而很多项目的测试的现实情况是倒金字塔或沙漏型：

我们项目可以用E2E做什么？ 项目中i发生得比较多得问题

我们面临的问题，缺少单元测试，但是又希望通过E2E快速带来一些价值。

冒烟测试

from 百度:

这一术语源自硬件行业。对一个硬件或硬件组件进行更改或修复后，直接给设备加电。如果没有冒烟，则该组件就通过了测试。在软件中，“冒烟测试”这一术语描述的是在将代码更改嵌入到产品的源树中之前对这些更改进行验证的过程。在检查了代码后，冒烟测试是确定和修复软件缺陷的最经济有效的方法。冒烟测试设计用于确认代码中的更改会按预期运行，且不会破坏整个版本的稳定性。

简单理解：

一种成本非常低的测试，在改动后对系统的关键流程进行简单测试，用于查看变更后系统是否能基本工作。看系统会不会爆炸。不会则表示测试通过。如打开页面是否有内容显示； 提交一个很简单的表单是否能成功等等。

怎么用E2E测试

一般使用E2E测试可以遵循以下几个步骤：

计划 -> 设计 -> 执行 -> 结果分析

计划： 首先确定是否需要E2E测试（可以参考测试金字塔），确定哪些功能和部分需要
设计： 为需要E2E的功能、流程设计和编写测试用例
执行： 执行用例并得到成功或失败的结果
结果分析： 对执行失败的用例进行分析查错

设计测试用例

因为我们要用E2E工具来做冒烟测试，冒烟测试只需要进行很简单的测试保证系统能基本工作即可，或者能保证跑完一个或多个系统的关键流程里的乐观流程（happy flow)即可，什么异常情况都不需要覆盖。所以设计的用例也会相对简单。 而公司的项目代码当然是不能往外放的，所以咱们借百度来练练手。

首先，我们都知道百度最基本也最关键的功能是搜索，那么我们可以为这个功能设计一些简单的冒烟测试，可以设计如下用例：

首页有搜索按钮
在文本框输入一个词语，并点击搜索按钮，页面能跳转到结果页
结果页包含符合条件的结果
点击其中一条结果能打开对应的链接

10. 选定一个工具作为例子

cypress

https://github.com/cypress-io/cypress
https://docs.cypress.io/

我们需要用cypress做到的事情：（其实其他E2E工具也能做到）

可以打开浏览器并执行测试
可自动多次重复执行
有足够API可以执行所需的动作 – 自身提供了丰富的API操作浏览器，断言部分基于mocha和chai
可对错误结果进行记录 – 可录视频、生成截图，也有辅助调试相关的功能

API文档： https://docs.cypress.io/api/

11. 结束语

可能大家觉得这结束得很突然。不过由于设计的用例非常简单，实现也很简单，照着文档简单写一下就出来了，而本文主要是记录自己对概念的学习过程，具体用哪个工具实现什么用例反而不是最重要的了。所以这里就不上具体用例的代码了。

参考资料

https://www.freecodecamp.org/news/end-to-end-testing-tutorial/
https://www.perfecto.io/blog/comprehensive-guide-end-end-e2e-testing
https://dev.to/jamesgeorge007/let-s-write-e2e-tests-for-a-react-application-with-cypress-4a8i
https://rexben.medium.com/end-to-end-testing-in-react-with-puppeteer-and-jest-6a0b1b8cff6b
https://baike.baidu.com/item/冒烟测试/2166486
https://insights.thoughtworks.cn/practical-test-pyramid/
https://blog.csdn.net/qq_39300332/article/details/82557315