前端自动化测试详解(上)

阅读数:799 2019 年 9 月 26 日 23:45

前端自动化测试详解(上)

1 前言

文章研究了四个问题:什么是自动化测试、为什么要自动化测试、什么项目适合自动化测试、自动化测试具体要怎么做。在寻找这四个问题答案的过程中,梳理了一套完整的前端自动化测试方案,包括:单元测试、接口测试、功能测试、基准测试。

2 什么是自动化测试

维基百科是这样定义的:

在软件测试中,测试自动化(英语:Test automation)是一种测试方法,使用特定的软件,去控制测试流程,并比较实际的结果与预期结果之间的差异。通过将测试自动化,可以让正式的测试过程中的必要测试,可以反复进行;通过这种方法,也可以将难以手动进行的测试,交由软件来做。

测试自动化的最大优势就是可以快速而且反复的进行测试。

总结一下:自动化测试指软件测试的自动化,让软件代替人工测试,可以快速、反复进行。

关于自动化测试有一个金字塔理论,把测试从上到下分为 UI(用户界面测试)/Service(服务测试) /Unit(单元测试 )。如图所示,越往金字塔底层,测试的效率越高,测试质量保障程度越高,测试的成本越低。怎么理解这句话呢?前端项目通常 UI 变化频繁,一旦发生变化,UI 测试用例就无法执行且难以维护,所以 UI 自动化测试的成本高,收益小;相比 UI 测试,Service 测试更加简单直接且变化不会很频繁;单元测试主要对公共函数、方法进行测试,测试用例复用度高且更能保证代码质量。

前端自动化测试详解(上)

测试金字塔

在接下来的问题中,我们所讨论的自动化测试,主要指四个方向:单元测试、接口测试、功能测试、基准测试。所谓单元,可以理解为一个函数、一个 react 组件;接口即 API,接口测试主要关注提供的接口是否可靠;功能可以理解为应用的 UI、功能是否符合预期;基准测试可以帮我们测试代码的性能。

3 实施自动化测试有什么好处

测试最重要的目的是验证代码正确性,确保项目质量。举个例子,某一天我写了一个逻辑复杂的函数,这个函数被很多地方调用,过了一个月之后,我可能忘记这里面的具体逻辑了,出于某种原因需要为这个函数增加一些功能,修改这个函数的代码,那我要怎么做才能保证修改代码后不影响其他的调用者呢,或者说,我要怎么做,才能快速的知道哪些地方受影响,哪些地方不受影响呢?答案就是实施自动化测试,跑测试用例。

如果不进行自动化测试,我们会如何验证代码的正确性?通常 FE 使用的方法是手动测试:console、alert、打断点、点点点。但手动测试是一次性的,如果下次有人对代码功能做了修改,我们不得不再次重复手动测试的工作,并且很难保证测试的全覆盖。但如果编写测试用例进行自动化测试,第一次写完的测试用例是可以重复使用的,一次编写,多次运行。如果测试用例写的完善、语义化,开发人员还可以通过看测试用例快速了解项目需求。实施自动化测试可以驱动开发人员在代码的设计中做更好的抽象,写可测试的代码,以测试公用方法为例,要确保被测试的方法无副作用,既对外部变量没有依赖,也不会改变全局原本的状态。

总结一下,实施自动化测试有四个好处:

  • 可以验证代码正确性,保证项目质量
  • 测试用例可以复用,一次编写,多次运行
  • 通过看测试用例可以快速了解需求
  • 驱动开发,指导设计,保证写的代码可测试

4 什么样的项目适合自动化测试

自动化测试如此优秀,那是不是所有项目都适合进行自动化测试?答案是否定的,因为有成本。在实施自动化测试之前需要对软件开发过程进行分析,基于投入产出来判断是否适合实施自动化测试。实施自动化测试的项目通常需要同时满足以下条件:

  • 需求变动不频繁
  • 项目周期足够长
  • 自动化测试脚本可重复使用
  • 代码规范可测试

如果需求变动过于频繁,维护测试脚本的成本太高;如果项目周期比较短,没有足够的时间去支持自动化测试的过程;如果测试脚本重复使用率低,耗费的精力大于创造的价值,不值得;如果代码不规范,可测试性差,那自动化测试实施起来会比较困难。

5 自动化测试怎么做

5.1 原始的测试方法

举个例子,现在有一个方法 sum

复制代码
1const sum = (a, b) => { return a + b }

如何证明 sum 方法的正确性?我们通常会使用如下代码进行测试

复制代码
1// test/util.test.js
2const sum = (a, b) => { return a + b }
3if(sum(1,1)===2){
4 console.log('sum(1,1)===2, 测试结果符合预期,方法正确')
5}else{
6 console.log('sum(1,1)===2, 测试结果不符合预期,方法出错')
7}

执行测试代码后控制台输出结果如下

前端自动化测试详解(上)

符合预期的输出

测试结果正确。假设现在把 sum 方法改为 +1

复制代码
1const sum = (a, b) => { return a + b + 1 }

执行测试代码后控制台输出结果如下

前端自动化测试详解(上)

不符合预期的输出

这个输出虽然显示了方法出错的提示,但是对结果正确与错误没有做明显的区分,测试结论不够直观,我们把测试代码修改一下

复制代码
1// test/util.test.js
2const sum = (a, b) => { return a + b + 1 }
3if (sum(1, 1) === 2) {
4 console.log(' sum(1,1)===2, 测试结果符合预期,方法正确')
5} else {
6 throw new Error('sum(1,1)===2, 测试结果不符合预期,方法出错')
7}

这段代码执行后,一旦方法执行的结果不符合预期就主动抛出错误

前端自动化测试详解(上)

不符合预期时抛错

这样就能更直观的看出测试结论。我们进一步优化,使用 nodejs 提供的断言模块来书写测试用例

复制代码
1const sum = (a, b) => { return a + b + 1 }
2const assert = require('assert')
3assert.equal(sum(1, 1), 2)

执行测试代码后控制台结果如下

前端自动化测试详解(上)

assert 测试

输出信息与刚才的效果类似:执行结果不符合预期就主动抛出错误。使用 assert 达到了相同的效果,但代码量减小了,并且更加语义化。

5.2 使用测试框架

上面的方法可以帮助我们完成代码测试,那有没有更好的方式呢?我们开发项目时通常会选择使用框架和库,使用框架的好处是约束我们代码的风格,保证代码的可维护性和扩展性,使用工具库可以提高开发效率。同理,在实施自动化测试时我们也会选择使用测试框架和库。目前市面上比较流行的前端测试框架有 Mocha、QUnit、Jasmine、Jest 等,如下做个简单介绍

前端自动化测试详解(上)

常用的测试框架

框架可以为我们输出更加直观的测试报告,比如像下面这样,正确和错误的测试结果都给我们展示

前端自动化测试详解(上)

结构化的测试报告输出

还可以输出文档结构的测试报告,比如下面这样

前端自动化测试详解(上)

html 格式的文档输出

5.3 测试方案技术选型

本文讨论的自动化测试方案技术选型如下:

  • 测试框架:mocha
  • 断言库:chai
  • 测试报告:mochawesome
  • 测试覆盖率:Istanbul
  • 测试浏览器:chrome
  • 浏览器驱动:selenium-webdriver/chrome
  • 接口测试 http 请求断言:supertest
  • react 组件测试:enzyme
  • 基准测试:benchmark

选择 Mocha 是因为它:

  • 精简而灵活,扩展性强
  • 社区成熟用的人多
  • 各种测试用例在社区都能找到

下面我们通过一段测试用例来看一下 Mocha 有什么能力:

前端自动化测试详解(上)

Mocha 的能力

可以看到 Mocha 最核心的四项能力

  • 测试用例分组
  • 生命周期钩子
  • 兼容不同风格断言
  • 同步异步测试架构

代码中 describe 块称为“测试套件”,表示一组相关的测试,它是一个函数,第一个参数是测试套件的名称(“测试 sum 方法”),第二个参数是实际执行的函数,分组让测试用例代码结构化,易于维护。it 块称为 " 测试用例 ",表示一个单独的测试,是测试的最小单位。它也是一个函数,第一个参数是测试用例的名称(“1 加 1 应该等于 2”),第二个参数是实际执行的函数。

选择 chai 作为断言库是因为它提供了两种风格的断言:BDD 风格(行为驱动开发)和 TDD 风格(测试驱动开发),其中 BDD 风格更接近自然语言。使用它可以自由、灵活的与 Mocha 搭配,下图是 chai 官网展示的两种断言风格。

前端自动化测试详解(上)

chai 断言示例

评论

发布
用户头像
麻烦把文章代码格式化一下,比如会有两个行号。
2019 年 10 月 10 日 20:23
回复
没有更多了