摘要：与单元测试不同，后者通常需要测试参数参数类型参数值参数数量返回值抛出错误等，目的在于保证特定函数能够在任何情况下都稳定可靠完成工作。单元测试假定只要所有函数都正常工作，那么整个产品就能正常工作。
上一篇文章发布后，竟然收获到一些同学的注意，实在是意外之喜。不过我也发现，很多同学对 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 介绍吧。
文章版权归作者所有，未经允许请勿转载,若此文章存在违规行为，您可以联系管理员删除。
转载请注明本文地址：https://www.ucloud.cn/yun/8944.html
摘要：进行测试之理论是目前很火的一个测试组件，内部绑定了之类的断言为了让代码代码更有说服力，减少提交测试错误，进行测试显然是非常有必要的。 cypress 进行 e2e 测试之理论 cypress 是目前 e2e 很火的一个测试组件，内部绑定了 macha、chai、chai-jquery 之类的断言,为了让代码代码更有说服力，减少提交测试错误，进行 e2e 测试显然是非常有必要的。 官网...
摘要：单元测试前端的单元测试目前有两个比较热的框架，一个是的方式，一个是。小伙伴们不用急，关于单元测试这块，我会找时间写博客的。首先前端的测试分为两种，一个是单元测试，另一个就是测试了。 因为公司项目要用vue框架，所以会用vue-cli来新建项目。用过vue的都知道，要全局安装vue以及脚手架vue-cli，然后执行vue init webpack projectname来新建vu...
摘要：约定我们假定要被测试的页面是这样的标题开始编写测试首先是导入。我们推荐使用的语法当然您也可以用方式第一件事是构造一个实例然后要转到要被测试的页面。 之前我曾经在《Rize - 一个可以让你简单、优雅地使用 puppeteer 的 Node.js 库》一文简单介绍过 Rize 这个库。当时仅仅是介绍这个库本身，关于如何使用，我没有给太多的指导。 这篇文章讲的是如何使用 Rize 来做 U...
摘要：约定我们假定要被测试的页面是这样的标题开始编写测试首先是导入。我们推荐使用的语法当然您也可以用方式第一件事是构造一个实例然后要转到要被测试的页面。 之前我曾经在《Rize - 一个可以让你简单、优雅地使用 puppeteer 的 Node.js 库》一文简单介绍过 Rize 这个库。当时仅仅是介绍这个库本身，关于如何使用，我没有给太多的指导。 这篇文章讲的是如何使用 Rize 来做 U...
摘要：约定我们假定要被测试的页面是这样的标题开始编写测试首先是导入。我们推荐使用的语法当然您也可以用方式第一件事是构造一个实例然后要转到要被测试的页面。 之前我曾经在《Rize - 一个可以让你简单、优雅地使用 puppeteer 的 Node.js 库》一文简单介绍过 Rize 这个库。当时仅仅是介绍这个库本身，关于如何使用，我没有给太多的指导。 这篇文章讲的是如何使用 Rize 来做 U...
阅读 1696·2021-11-24 09:39
阅读 3357·2021-09-28 09:36
阅读 3117·2021-09-06 15:10
阅读 3273·2019-08-30 15:44
阅读 1045·2019-08-30 15:43
阅读 1662·2019-08-30 14:20
阅读 2539·2019-08-30 12:51
阅读 1900·2019-08-30 11:04
