js自动化测试基础

js自动化测试基础

虽然在平时的工作经验中,可以感觉前端作为GUI为主的开发,受到团队质疑测试成本、工期紧张、而且UI和需求容易频繁变动、以及bug影响通常不大,导致推进自动化测试不太容易。不过随着持续的发展,我们可以看到前端项目越来越复杂,公共模块越老越多,所以未来对这部分项目的自动化测试肯定是一个趋势。在这里讲讲我的一些故事。

情景还原

bugzhang刚刚工作的时候,是在一家迭代飞速的初创公司,刚去没多久就被交代了一个非常重要的模块更新,虽然公司大牛很多,但大牛写的代码也和大牛本身会的一样难懂,加上我那时候是个小小白,所有当时面对复杂项目一脸懵逼。最终梳理业务很久,梳理通业务后,开发完了模块,但又不敢上线,生怕改出影响别的部分的逻辑出来。

从那时候起,我才明白自动化测试不是没有意义滴,不是用来吹PPT的,而是确实可以提升项目质量、增加维护性、代码可读性的好东西。

什么是自动化测试

测试分为非自动化测试,也就是手工测试,俗称“点点点”,以及自动化测试。大多数情况下,我们编写的前端代码都是开发手工自测,又或是提测后由专门的测试人员手工测试。而自动化测试实际上是运行一段测试代码,去验证目标代码是否满足某个期望。

自动化测试有什么好处

最大的目的是,及时发现错误,提高代码质量和开发效率,避免存在 BUG 的代码发布上线造成损失。此外,因为自动化测试会写出运行的期望结果,所以阅读自动化测试的代码可以进一步熟悉业务,增加项目的可读性。

测试类型知多少

前端自动化测试主要分为 4 种:单元测试(Unit Test)、端对端测试(E2E Test)、集成测试(Integration Test)、UI 测试(UI Test)。
一般的建议是测试金字塔:上边四种测试的比例越占越低

单元测试

单元测试是最容易实现的:代码中多个组件共用的工具类库、多个组件共用的子组件等。
「通常情况下,在公共函数/组件中一定要有单元测试来保证代码能够正常工作。单元测试也应该是项目中数量最多、覆盖率最高的。」
能进行单元测试的函数/组件,一定是低耦合的,这也从一定程度上保证了我们的代码质量。

端对端测试

我们已经介绍过单元测试了,凭借着快照库和DOM抓取,对API的mock等操作,单元测试也可以达到对DOM状态的判断以及样式的断言,所以我们为什么还需要端到端测试呢?这就是黑盒与白盒的区别,白盒更注重数据的流动,黑盒更注重结果的展示,也就是一个是注重过程,一个注重结果。侧重点的不同所带来的展示效果也会相应的出现偏差。
「端到端测试给我最直观的反馈在于它更像是一个自动化的测试脚本,去自动点击一个真实浏览器环境中的页面,再通过直接抓取页面上的DOM来断言是否符合预期,这是最接近用户的测试方式。」
所以我认为从一定程度而言端到端测试对于一个产品的发布起到了至关重要的作用,这直接关系到了DOM给用户带来的视觉上的交互。

集成测试

集成测试通常被应用在:耦合度较高的函数/组件、经过二次封装的函数/组件、多个函数/组件组合而成的函数/组件等。
集成测试的目的在于,测试经过单元测试后的各个模块组合在一起是否能正常工作。会对组合之后的代码整体暴露在外接口进行测试,查看组合后的代码工作是否符合预期。
「集成测试是安全感较高的测试,能很大程度提升开发者的信心,集成测试用例设计合理且测试都通过能够很大程度保证产品符合预期。」

UI测试

UI自动化测试是前端专有的测试,UI测试容易和端对端测试混为一谈,实际双方有区别:
UI 测试(UI Test)只是对于前端的测试,是脱离真实后端环境的,仅仅只是将前端放在真实环境中运行,而后端和数据都应该使用 Mock 的。
端到端测试(E2E Test)则是将整个应用放到真实的环境中运行,包括数据在内也是需要使用真实的。
UI 自动化测试目前无论研究进展还是推行情况都比较低,而且成本高,主要依靠手工测。

哪些项目适合自动化测试

自动化测试开发成本高,这是推进最难的一个原因,加上本身开发迭代忙,所以对做自动化测试的项目一定是要有所取舍的,我觉得需要做自动化测试的主要分两类:

  • 第一类是公共模块类的项目,这部分项目影响广泛,迭代必须百分之百保证质量。
  • 第二类是业务复杂而且长期迭代的项目,这部分项目很容易随着开发人员的离职转岗等流失,导致维护性变低,但本身业务复杂重要,如果有自动化测试来保证质量,可以大幅提升项目健康度。

而对于普通的项目而言,我觉得可以在部分公共方法、模块,以及外部依赖多变的部分模块中做自动化,覆盖度低但重要内容覆盖到,是一种在成本和质量上做的一种折中方案。