关于 E2E 测试

上一篇文章发布后，居然收获到一些同窗的注意，实在是意外之喜。不过我也发现，不少同窗对 E2E 测试不够了解，正好我厂的产品也没作到能做为商用版发布的程度，因此这篇再来聊聊 E2E 测试吧。

本文的测试均指自动化测试。

E2E，是“End to End”的缩写，能够翻译成“端到端”测试。它模仿用户，从某个入口开始，逐步执行操做，直到完成某项工做。与单元测试不一样，后者一般须要测试参数、参数类型、参数值、参数数量、返回值、抛出错误等，目的在于保证特定函数可以在任何状况下都稳定可靠完成工做。单元测试假定只要全部函数都正常工做，那么整个产品就能正常工做。

相对来讲，E2E 测试并无那么强调要覆盖所有使用场景，它关注的是 一个完整的操做链是否可以完成。对于 Web 前端来讲，还关注 界面布局、内容信息是否符合预期。

好比，登录界面的 E2E 测试，关注用户是否可以正常输入，正常登陆；登录失败的话，是否可以正确显示错误信息。至于输入不合法的内容是否处理，没有很大的关系。

Web 前端 E2E 测试的现状

Web 前端 E2E 自动化测试开展得很差。在我从业的这十几年里，大部分产品的前端 E2E 测试都交给测试人员手工完成。咱们稍稍分析一下，大概有三个缘由：

1. 测试环境很差搭

单元测试也好、接口测试也好，测试环境都很容易搭建。然而 Web 前端测试若是想达到目的，须要完整的桌面操做系统和浏览器环境，这种面向普通用户的软件对自动化工具并不友好。对系统要求也比较高，很难整合到开发测试工具链档中。

解决方案固然是有的，目前最流行的应该是 Selenium WebDriver。不过对于小公司、小团队来讲，在并不丰富的资料中摸着石头过河实在不够经济，并且，还有接下来的两个问题。

2. 测试很差写。

目前的 Web 前端 E2E 测试工具局限于 XPath 技术栈。你们用选择器查找 DOM 节点，校验其属性和内容，接着进行交互。这样作致使一个必而后果：写测试的人员对页面的 DOM 结构必须了如指掌，才能用准确目标元素。

同时，在这个技术环境下写就的测试用例，一旦 DOM 结构出现变化，就要大规模的修改，甚至重写。工做量很大，并且存在一些不稳定因素。跟某团队 Leader 聊天，他就很担忧漫长的迭代过程当中，DOM 结构变化致使测试用例失效，继而引起项目排期混乱。

结果，Web 前端 E2E 测试用例的只能由前端用 JS 写，工做量大，维护负担重，且存在一些风险。你们都不肯意写。

3. 有些东西很差测

随着用户对产品的要求水涨船高，页面逻辑愈来愈复杂，功能愈加依赖 Ajax，甚至和后端完全分离，成为单页应用（SPA）。这类产品与传统的静态页服务不一样，咱们无法侦听 DOMReady 事件，也就难以找到合适的时间点启动测试。

早些时候，咱们只能依靠 setInterval() 轮询。现在，经过 Puppeteer 或者浏览器扩展均可以监听网络链接，能够根据当前保持的链接数来判断请求是否完成。

不过这些作法仍然存在不小的实施难度。

4. 预期收益通常

我跟不少技术老大聊过。你们的回答都是：没写，没空，招测试。在加班成为常态的今天，在“看获得”的工做以外，再去作这些“看不到”的工做，实在有些吃力不讨好。另外一方面，测试写得少，覆盖率跟不上，仍是得招测试，人工测试。

恶行循环就此产生：不想写致使没测试；那就招测试人员；有了专职测试我还写什么测试……因此你们都不写测试了。

对于中等以上规模的技术团队，招几个测试也还行。对于整个公司就只有几我的的创业团队来讲，大多数时候只能裸奔……

更好的 Web 前端 E2E 测试工具

行文至此，结论就很明显了：咱们须要全新的、更高级的 Web 前端 E2E 测试工具。这个工具须要同时知足：

1. 有效

1. 能够准确地描述 UI 的结构
2. 能够尽可能全面的模拟用户真实操做
3. 覆盖多种操做系统、适配各类浏览器

2. 使用成本低

1. 测试用例应该尽可能简短，用最少的代码描述出 UI，完成交互。
2. 测试用例应该和 DOM 实现解耦，用的尽可能久，能不改就不改。
3. 测试用例应该让全部人都学得会，写得通

3. 提升开发效率

1. 应该提供方便易用的编写、测试环境，让用户能够轻松上手
2. 须要可以和常见的 CI 系统集成

我厂的解决方案

最后回到我厂。

咱们设计了一个全新的语言用来描述 UI，叫作 Navlang。咱们能够用它描述各元素的相对位置，操做元素进行交互。

它是一个描述性语言，只包含很简单的逻辑——实际上 E2E 测试也不须要多复杂的逻辑，跑不通就是挂了，跑通了就没问题。这样一来，任何人，只要通过简单的培训，均可以写出正确的测试用例。（HTML 就是最好的例子。前端不少都是页面仔出身，好比我，相信你们对这类语言的易学易用都有所了解。）

由于是语言，因此它能够写成代码，能够被版本管理；由于是新的抽象，因此它不跟 DOM 实现耦合，能够被反复使用，几乎没有维护成本。（只有界面变化才须要修改测试用例，此时不管如何都要修改测试用例）

目前这个工具已经在我厂的开发体系中工做将近一年，为我厂产品的稳定作出了很是重大的贡献。

功能化以外，咱们也在做产品化和商品化的努力。目前已经基本完成浏览器扩展功能，让普通用户能够经过浏览器扩展编写和运行测试。接下来，咱们还会提供基于 Node.js 的测试工具框架，帮助你们将测试集成到现有的 CI 系统当中。

将来，这款产品会服务广大小型公司和小型团队，帮助你们提高 Web UI 测试的效率。

好了，敬请期待下周的 Navlang 介绍吧。