前言
最近在研究E2E自动化测试,发现市面上关于自动化测试的介绍乏善可陈,因此本文将从概念介绍,技术选型,方案落地三个方面来聊聊UI自动化测试。
概念介绍
自动化测试的组成
最初由麦克科恩 (Mike Cohn) (敏捷开发的创始人之一)
在他的著作《Succeeding with Agile》一书中提出了测试金字塔这个概念。
从上图可以看出,整个金字塔模型由三层组成:
- 单元测试(Unit Tests)
- 服务测试(Service Tests)
- UI测试(UI Tests)
整个金字塔模型代表着越上层的测试集成度越高,执行速度越慢,越下层的测试隔离性越好,执行越快越轻量。
从测试金字塔中可以得到适合自己的经验法则:
-
构建不同粒度的测试
-
越高层次的测试应该越少,制定合理的测试策略
为了保持测试金字塔测形状,一个快速、可维护、覆盖范围合理的测试组合应该是这样的:
- 大量小而快的单元测试
- 全面的接口测试
- 少量的UI测试
都说业内最佳实践看Google,Google的自动化测试分层比例是:
- 单元测试(70%)
- 接口测试(20%)
- UI测试(10%)
UI测试 VS E2E测试
-
UI测试(User Interface Test)
用户界面测试
-
E2E测试(End-to-end Test)
端到端测试,模拟用户真实使用场景的测试
测试金字塔的顶层(UI测试)并非这里字面意义上的“UI测试”,这一点比较有误导性,对于现代前端应用,UI测试侧重产品的UI交互是否正确,模拟后端进行测试也可以,放在单元测试里去做也可以。
而E2E测试,是需要模拟用户真实场景的测试,检查整个系统是否以正确的方式运作。
所以广义上的“UI测试”(测试金字塔的UI Tests)可以认为是E2E测试。
什么场景适合
- 需求稳定,不会频繁变更
- UI界面稳定,变动少
- 项目周期长
- 大量的回归测试
技术选型
目前市面上常见的几种E2E测试方案有
- 基于WebDriver:Selenium,Appium
- 基于CDP:Puppeteer,Playwright
- Inject Script:Cypress
接下来,我们将从不同方案的实现原