前端自动化测试详解（上）

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.js2const 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.js2const 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 断言示例