共计 2171 个字符，预计需要花费 6 分钟才能阅读完成。
上一篇文章发布后，竟然收获到一些同学的注意，实在是意外之喜。不过我也发现，很多同学对 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. 有效
可以准确地描述 UI 的结构
可以尽量全面的模拟用户真实操作
覆盖多种操作系统、适配各种浏览器
2. 使用成本低
测试用例应该尽量简短，用最少的代码描述出 UI，完成交互。
测试用例应该和 DOM 实现解耦，用的尽量久，能不改就不改。
测试用例应该让所有人都学得会，写得通
3. 提高开发效率
应该提供方便易用的编写、测试环境，让用户可以轻松上手
需要能够和常见的 CI 系统集成
我厂的解决方案
最后回到我厂。
我们设计了一个全新的语言用来描述 UI，叫做 Navlang。我们可以用它描述各元素的相对位置，操作元素进行交互。
它是一个描述性语言，只包含很简单的逻辑——实际上 E2E 测试也不需要多复杂的逻辑，跑不通就是挂了，跑通了就没问题。这样一来，任何人，只要经过简单的培训，都可以写出正确的测试用例。（HTML 就是最好的例子。前端很多都是页面仔出身，比如我，相信大家对这类语言的易学易用都有所了解。）
因为是语言，所以它可以写成代码，可以被版本管理；因为是新的抽象，所以它不跟 DOM 实现耦合，可以被反复使用，几乎没有维护成本。（只有界面变化才需要修改测试用例，此时无论如何都要修改测试用例）
目前这个工具已经在我厂的开发体系中工作将近一年，为我厂产品的稳定做出了非常重大的贡献。
功能化之外，我们也在作产品化和商品化的努力。目前已经基本完成浏览器扩展功能，让普通用户可以通过浏览器扩展编写和运行测试。接下来，我们还会提供基于 Node.js 的测试工具框架，帮助大家将测试集成到现有的 CI 系统当中。
未来，这款产品会服务广大小型公司和小型团队，帮助大家提升 Web UI 测试的效率。
好了，敬请期待下周的 Navlang 介绍吧。
