软件测试笔记-单元测试

什么是单元测试

我，CS专业的的学习者、互联网某片盐碱地的准码农、IT民工、未来老板眼中的加班狗、同事眼中的摸鱼王、准秃子，经常被大姨问到这样一个问题：“我电脑坏了，你能修嘛？”

面对这种问题，考虑到大姨不能脱离显示器分辨电脑是否处于运行状态，我通常会放下手机抱起她闹人的大孙子，说：“我不会，找人来修吧。”

通常情况下，维修大哥只需要接通电源，咬着牙求过好评后就赶往下一家。但难免也会遇到比较棘手的问题。他需要逐个模块排查问题：电源是否正常工作、主板是否正常等。找到故障部位后，逐级排查，花费大量的时间和精力。

好在电脑的各个元器件都经过检查合格，并不会同时故障。这一点就很值得我们学习，组成代码的元器件——代码，也需要满足一定的标准。如何确定代码是否满足质量？这就是我们今天要讲的内容：单元测试。

单元测试是指，对软件中的最小可测试单元在与程序其他部分相隔离的情况下进行检查和验证的工作，这里的最小可测试单元通常是指函数或者类。

如何做好单元测试

单元测试的对象是代码，包括代码的特征和错误原因。作为代码的编写者，开发这段垃圾代码工程师通常是单元测试的最佳人选。单元测试是最严格的测试手段，可以用最小的成本保证代码的质量。

单元测试通常以自动化的方式执行，也可以帮助开发人员改善代码设计，调用这些方法/函数的过程中还可以构成函数的使用说明。

如何做好单元测试？

代码的基本特征与产生错误的原因

学习一门新语言时，我们总会先注意到它的条件分支、循环处理和函数调用这些最基本的逻辑控制。我们抛开业务逻辑，仅看代码结构，这部分是我们最好掌握也是不能不掌握的内容。代码所有这些结构都有同样的目的：数据分类。对分类的遗漏、分类的错误、以及分类时逻辑处理的错误都会产生缺陷。

所以，满足分类正确、完备，处理分类逻辑正确，是保障代码质量必须要做到的内容。

借鉴等价类划分的技巧，我们可以这样划分功能逻辑：
1. 正常输入的种类
2. 需要特殊处理的边界输入
3. 非法输入的可能性和处理方式
单元测试用例详解

什么是单元测试的设计用例？“输入数据”和“预计输出”的集合。上面说到的划分逻辑功能，挨个列出不就完事了吗？

错。
- 什么是完整的单元测试输入数据？
  - 被测试函数的输入参数；
  - 被测试函数内部需要读取的全局静态变量；
  - 被测试函数内部需要读取的成员变量；
  - 函数内部调用子函数获得的数据；
  - 函数内部调用子函数改写的数据；
  - 嵌入式系统中，在中断调用时改写的数据；
  - ……
- 什么是完整单元测试的输出数据？
  - 被测试函数的返回值；
  - 被测试函数的输出参数；
  - 被测试函数所改写的成员变量；
  - 被测试函数所改写的全局变量；
  - 被测试函数中进行的文件更新；
  - 被测试函数中进行的数据库更新；
  - 被测试函数中进行的消息队列更新；
  - ……
还有很重要的一点：我们要摆脱思维惯性。对于预计输出值，你必须严格根据代码的功能逻辑来设定，而不能通过阅读代码来推算预期输出。不要本末倒置。
驱动代码、桩代码、Mock代码

在单元测试中，这是最常出现的三个名词。驱动代码是用来调用被测函数的，桩代码和Mock代码用来代替被测函数调用的真实代码。三者逻辑关系如下：

驱动代码：驱动模块包括调用被测函数前的数据准备（调用前）、调用被测函数（调用中）以及验证结果（调用后）三个步骤。

用伪代码举个例子：

void funA()
{
    boolean funB_returnValue;
    
    funB_returnValue = funB();
    if(true == funB_returnValue)
    	{do Operation 1;}
    else if (false ==funB_returnValue)
    	{do Operation 2;}
}

单元测试阶段，函数B尚未实现。用一个假的函数B代替真正的函数B，这个假B就是~~（装？）~~桩函数。

当然，桩函数要覆盖全部的路径，需要控制不同测试用例的函数B的返回值。在这个例子里，桩函数需要有true和false两个返回值：

boolean funB()
{
    if(testcaseID == '1')
    {return true;}
    else if(testcaseID == '0')
    {return false;}
}

学到这里，我不禁发出了一个疑问：就这？桩代码？就这？

在学习代码逻辑时，我们会做类似工作。我们可以总结一下桩代码的作用：

隔离补齐：使被测代码能够独立编译、链接、运行；
控制被测函数执行路径。

当然，编写桩代码也有可靠的方法论可行，如下是三个原则：

桩函数要有与原函数相同的原型。保证测试代码正确链接到桩函数；
简单简单简单。桩函数是一个让你直呼“就这”的函数，只需保持原函数的声明，加一个空的实现。目的是通过编译，不然无法正确连接，不需要很复杂；
输出合适的数据。实现控制功能的桩函数是应用最广泛的，我们需要根据测试用例的需要，输出合适的数据作为被测函数的内部输入。这里我们依然可以用

Mock，模仿的。类似桩代码，Mock代码用来代替真实代码，起到隔离补齐的作用。二者的区别在于测试结果的不同：

Mock代码的关注点是它有没有被调用，被什么样的函数调用，被调次数，多个Mock函数的先后顺序。见名知意，Mock代码是原代码的冒牌货，我们在意的不是这个代码的内部逻辑，而是它作为替身，被调用时的各种信息。
stub，树桩。桩代码的作用就像是森林里的树桩，作为参照物引导我们不偏离正确的道路。与Mock不同，Stub的关注点是被测函数的执行路径，即代码内部的逻辑，而不是Stub如何被调用。

如果你想深入比较，可以参考马丁·福勒（Martin Fowler）的著名文章《Mock 代码不是桩代码》（Mocks Aren’t Stubs）。

实际项目如何展开单元测试？

测试范围：不是所有的代码都要进行单元测试，只有底层模块或者核心模块的测试中才会采用。不然测试浪费的时间成本会很高。
单元测试框架选型：Java 最常用的单元测试框架是 Junit 和 TestNG；C/C++ 最常用的单元测试框架是 CppTest 和 Parasoft C/C++test；之后还要对Stub和Mock的框架选型，主要依据是具体的技术栈。

通常，单元测试框架、桩代码 /Mock 代码的选型工作由开发架构师和测试架构师共同决定。
计算代码覆盖率。不同的语言会有不同的代码覆盖率统计工具，比如 Java 的 JaCoCo，JavaScript 的 Istanbul。以后会学。
自动化。把单元测试执行、代码覆盖率统计和持续集成流水线做集成，以确保每次代码递交，都会自动触发单元测试，并在单元测试执行过程中自动统计代码覆盖率，最后以“单元测试通过率”和“代码覆盖率”为标准来决定本次代码递交是否能够被接受。