理论 | 测试用例的那一回事

前言

最近，团队对测试用例十分的注重，因此，下面是我对测试用例的一些解析。

首先，我们需要知道：为什么需要测试用例？

理由很简单，就是为了在测试用例的辅助下，编写出高质量，可维护代码。

问题

正如因为地震的爆发，才会有地震仪的诞生。 测试用例的诞生，也必然有其需要解决的问题：

当我们在开发，我们往往会有以下的问题：

需求和开发脱节

当一份需求来了， 开发人员往往不能百分百的理解需求的内容（抛弃产品自己变更需求的可能性。。），这往往会让开发人员开发出的功能会有跟需求有所差别，这会带来额外的工作量

开发和测试脱节

什么是开发和测试脱节，说的是，当开发人员按照自己的想法开发完了一个需求。然后测试人员也按照自己的想法去测试这个需求，然后由于双方的分歧，导致测试认为开发有bug，开发认为测试是sb.

那么如何解决上面的问题呢？

答案就是 选择一种软件敏捷开发模式

敏捷开发模式

目前比较流行的开发模式有两种： TDD 和 BDD

TDD （Test Driven Development 测试驱动开发）

1、测试来驱动开发

2、其重点偏向开发

3、测试用例是在约束开发者，使开发者的目标明确，设计出满足需求的系统

BDD （Behaviour Driven Development 行为驱动开发）

1、基于TDD发展，保持测试先行的理念

2、其重点偏向设计

3、在测试代码中用一种自然通用语言的方式把系统的行为描述出来

4、将系统的设计和测试用例结合起来，进而驱动开发工作

两种方式各有其特点，我们通常选择的是BDD的方式

测试工具

为了，方便我们编写测试用例，我们需要使用一些可靠工具,以下是我认为比较好的前端测试用例工具。

Mocha 摩卡

Mocha（发音"摩卡"）诞生于2011年，是现在最流行的JavaScript测试框架之一，在浏览器和Node环境都可以使用。 通过Mocha， 我们可以安装基于mocha的规范,轻松的编写测试用例和管理测试用例。

Mocha测试脚本如何编写

对于mocha, 一个测试用例必定包含 describe和 it，来实现一个测试用例的具体模版 describe块 称为"测试套件"（test suite），表示一组相关的测试。 it块 称为"测试用例"（test case），表示一个单独的测试，是测试的最小单位

以上的是同步情况的测试用例

若我们需要测试异步代码时，只需要在每个it的回调中，增加done的参数，具体如下 

Should JS 苏德 断言库

所有的测试用例（it块）都应该含有断言。 断言功能由断言库来实现，Mocha本身不带断言库，所以必须先引入断言库。 因此，我们在上面的测试用例添加断言：如下 

Nock 诺克 HTTP响应mock工具

有时，我们可能需要模拟HTTP请求的响应数据 是否有工具可以简化呢？那就是Nock啦， Nock使用起来十分方便,API都十分简单名利

通过nock,直接模拟请求结果，这样我们就可以不考虑cgi的状态，而专注于model的逻辑测试

Istanbul 伊斯坦布尔 代码覆盖率检验工具

测试用例写好了, 怎么验证是否写得好？ Istanbul是可以给出测试用例的代码覆盖率检验的工具

如下面我们使用istanbul,可以看到我们的util.test.js的覆盖率情况 

然后，如果想知道具体覆盖率情况，可以通过打开生成的报文去查看，如下面可以知道，哪些部分测试用例没有覆盖到 

mochawesome

万事俱备？NO NO NO! 我们还需要更好的视觉体验 通过使用mochawesome工具，在当命令行运行 mocha 是增加 “ --reporter mochawesome ”参数，将测试用例运行情况转成更为直观的测试报文，如下：

补充

懂得如何编写测试用例，但仍需要有一套比较明确的编写规范和，编写教程，才能让项目的测试用例生生不息，持之以恒带来功效、

扫码下方二维码，

随时关注更多前端干货文章！

▼

微信：IMWebTech