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

创作场景

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