单元测试基础

什么是单元测试

单元测试，对软件在设计的最小单元中进行正确性检测的测试，将可能存在的错误在最小范围内发现并解决。

对于单元测试中单元的含义，一般来说，要根据实际情况去判定其具体含义，如C语言中单元指一个函数，Java里单元指一个类，图形化的软件中可以指一个窗口或一个菜单等。总的来说，单元就是人为规定的最小的被测功能模块。单元测试是在软件开发过程中要进行的最低级别的测试活动，软件的独立单元将在与程序的其他部分相隔离的情况下进行测试。当然，在具体的测试实现中，也可能对应的是多个程序文件中的一组函数。

单元具有一些基本属性，如明确的功能、规格定义、明确与其他部分的接口定义等，可以清晰的与同一程序的其它单元划分。

单元测试的目的

发现模块内部逻辑、语法、算法和功能错误。

单元测试主要是基于白盒测试：

  • 验证代码与设计相符度。
  • 发现设计和需求中存在错误。
  • 发现在编码过程中引入的错误。

单元测试关注的重点

独立路径

对于基本执行路径和循环进行测试，可能的错误有：

  • 不同数据类型的比较。
  • “差1错”，即可能多循环或少循环一次。
  • 错误或不可能的终止条件。
  • 不适当的修改了循环变量。

局部数据结构

单元的局部数据结构是最常见的错误来源，应设计测试用例以检查可能的错误：

  • 不一致的数据类型。
  • 检查不正确或不一致的数据类型。

错误处理

比较完善的单元设计要去能遇见出错的条件，并设置适当的错误处理，以便在程序出错时，能对错误重新做安排，保证期逻辑上的正确性：

  • 出错的描述难以理解。
  • 显示的错误与实际的错误不符。
  • 对错误条件的处理不正确。

边界条件

边界上出现错误是最常见的错误现象：

  • 取最大最小值发生错误。
  • 控制流中的大于、小于这些比较值常出现错误。

单元接口

接口实际上就是输入和输出对应关系的集合，要对单元进行动态测试无非就是给这个单元一个输入，然后检查输出是否和预期一致。

如果数据不能正常输入和输出，单元测试就无从谈起，因此需要对单元接口进行如下的测试：

  • 被测单元的输入、输出在个数、属性、顺序是否和详细设计中的描述一致。
  • 是否修改了只做输入用的形式参数。
  • 约束条件是否通过形式参数来传送。

单元测试环境

单元本身不是一个独立的程序，一个完整的可运行的软件系统有若干个单元组成，所以必须为每个单元测试开发驱动单元和桩单元。

  • 驱动单元（Driver）：所测函数的主程序，它接收测试数据，并把数据传递给所测试单元，最后再输出实际测试结果，当被测单元能完成相关单元时，也可以不需要驱动单元。
    • 接收测试数据，包含测试用例输入和预期输出。
    • 把测试用例输入传送给要测试的单元。
    • 将被测单元的实际输出和预期进行比较，得到测试结果。
    • 将测试结果输出到指定的位置。
  • 桩单元（Stub）：用来代替所测单元调用的子单元。
    • 桩单元的功能是从测试角度模拟被调用的单元。
    • 桩单元需要针对不同的输入，返回不同的期望值，模拟不同的功能。

驱动单元执行被测函数得到实际的测试结果，那被测函数可能有其他依赖的函数，我们就要使用桩函数替代被测函数依赖的函数，驱动单元的执行依赖桩函数的正确性。

在展开测试的时候，有相应的测试策略可以使用。

孤立的测试策略

不考虑每个模块与其他模块之间的关系，为每个模块设计桩模块和驱动模块，每个模块进行独立的单元测试。

优点是：

  • 该方法最简单，容易操作。
  • 可以达到很高的结构覆盖率。
  • 可以展开并行。
  • 该方法是纯粹的单元测试。

缺点是装函数和驱动函数工作量很大，效率不高。

自顶向下的单元测试策略

方法是先对最顶层的单元进行测试，把顶层所调用的单元做成装模块，其次对于第二层进行测试，使用上面已经测试的单元做驱动模块，如此类推直到测试完所有的模块。

优点是可以节省驱动函数的开发工作量，测试效率高。

缺点是随着被测单元的增加，测试过程变得越来越复杂，并且开发和维护成本将增加。

自底向上的单元测试策略

方法是先对模块调用层次图上最底层的模块进行单元测试，模拟调用该模块的模块做驱动模块，然胡再对上面一层做单元测试，用下面已被测试过的模块做桩模块，一次类推， 直到测试完所有的模块。

优点是可以节省桩函数的开发工作量，测试效率高。

缺点是不是纯粹的单元测试，底层函数的测试质量对上层函数的测试将产生很大的影响。

单元测试的四个阶段

单元测试计划阶段：完成单元测试设计。

单元测试设计阶段：完成单元测试方案。

单元测试实现阶段：完成单元测试用例、规程、脚本及数据文件。

单元测试执行阶段：执行单元测试用例，修改发现的问题并进行回归测试，提交单元测试报告。

单元测试基本原则

原则,1，对全新的代码或修改后的代码要进行单元测试：

  • 针对缺陷进行修改。
  • 代码优化。
  • 如果代码改动较小，需要进行回归测试，如果改动较大，则需要重新设计单元测试用例来进行测试。

原则2，单元测试根据单元测试计划和方案进行，排除测试随意性。

原则3，必须保证单元测试计划、方案、用例等经过评审。

原则4，当测试用例的测试结果与预期不符时，单元测试的执行人员需要如实记录实际的测试结果。处理方式：

  • 确认到底是预期结果错误还是实测结果错误。
  • 如果是预期结果错误，修改预期结果，更新测试用例文档。
  • 如果是实测结果错误，那就意味着软件有bug，需要进一步测试，为开发人员提供更有用的信息，帮助他们尽快定位解决这个问题，同时还有可能发现更多的bug。

原则5，只有当测试计划中的结束标准达到时，单元测试才能结束。

原则6，对被测单元需要达到一定的代码覆盖率要求。

单元测试方式

  • 代码级别测试，熟悉模块功能，内部逻辑与接口，编写测试用例。
    • 接口测试，确保接口实现正确，符合设计文档规范或者相关约定。
    • 数据结构测试，确保数据结构的设计正确合理。
    • 边界测试，对于边界值进行检测。
  • 模块功能测试，通过黑盒，对模块进行功能测试。
  • 其他测试，性能、规范等。

示例：

def div(x, y):
    """ 两数相除 """
    return x / y


if __name__ == '__main__':
    print(div(10, 5))
    print(div(10, 0))

例如，测试函数div的可用性，包括正常数据测试，还有在除法中，被除数能否为0进行测试。

常见单元测试工具

常见的应用于单元测试的工具有：

  • 代码静态分析工具：Logiscope、McCabeQA、CodeTest。
  • 代码检查工具：PC-LINT、CodeChk、Logiscope。
  • 测试脚本工具：TCL、Python、Perl。
  • 覆盖率测试工具：Logiscope、PureCoverage、TrueCoverage、McCabeTest、CodeTest。
  • 内存检测工具：Punify、BoundsCheck、CodeTest。
  • 转为单元测试设计的工具：RTRT、Cantata、AdaTest。
posted @ 2019-11-27 21:05  天之坚毅  阅读(479)  评论(0)  编辑  收藏  举报