单元测试(自顶向下，自底向上，静态测试)

转载：https://blog.csdn.net/xiadanying/article/details/91421219

单元测试的定义

• 单元(Unit)指一个可独立运行的代码段，独立运行指这个工作不受前一次或接下来的程序运行的结果影响。
• 单元测试的内容包括对最小单元进行功能、性能、接口和设计约束等正确性检验，主要- 测试其在语法、格式和逻辑上的错误。
• 单元测试概念
  • 单元测试是对软件基本组成单元进行的测试。
  • 单元测试是从程序内部结构出发来进行测试的，多采用白盒测试的技术。
  • 单元测试是软件测试过程中进行的最低级别的测试活动，测试进行得越早越好。
  • 测试工作主要由程序开发人员进行自测和互测，同时还需要单独的测试角色，来进行测试和评审。
• 单元测试的目的
  • 能更准确更全面地查找错误，提高软件质量
    • 单元测试
    • 集成测试
  • 单元测试能够大量削减开发时间和节约成本
    • 修复成本随着阶段成倍数的增加
• 单元测试的过程
  • 制定测试计划
    • 单元测试准备
    • 制定单元测试策略
    • 单元测试日程计划
  • 单元测试设计
  • 测试执行
  • 测试评估

单元测试的内容

模块接口测试

• 对通过被测模块的数据流进行测试，检查进出模块的数据是否正确。
• Checklist（Checklist —检查表）
  • 调用本模块的输入参数是否正确；
  • 本模块调用子模块时输入给子模块的参数是否正确；
  • 全局量的定义在各模块中是否一致；
  • 外部输入、输出。

模块局部数据结构测试

• 检查局部数据结构能否保持完整性。
• Checklist
  • 不正确或不一致的数据类型说明
  • 变量无初值
  • 变量初始化或默认值有错
  • 不正确的变量名或从来未被使用过
  • 出现上溢或下溢和地址异常

模块边界条件测试

• 检查临界数据是否正确处理
• Checklist
  • 普通合法数据是否正确处理
  • 普通非法数据是否正确处理
  • 边界内最接近边界的(合法)数据是否正确处理
  • 边界外最接近边界的(非法)数据是否正确处理

模块独立执行路径测试

• 对模块中重要的执行路径进行测试。检查由于计算错误、判定错误、控制流错误导致的程序错误。
• Checklist
  • 运算符优先级
  • 混合类型计算
  • 精度不够
  • 表达式的不正确符号
  • 循环变量的使用错误

模块内部错误处理测试

• 检查内部错误处理设施是否有效。
• Checklist
  • 输出的出错信息难以理解
  • 记录的错误与实际不相符
  • 程序定义的出错处理前系统已介入
  • 异常处理不当
  • 未提供足够的定位出错信息

单元测试的环境

• 基本单元本身不是一个独立的程序，自己不能运行，要靠其它部分来调用和驱动。
  
• 驱动模块(driver)
  • 被测基本单元的主程序，它接收测试数据，并把数据传送给被测单元，最后输出实测结果。
• 桩模块(stub) ──存根模块
  • 用来代替被测基本单元调用的其他基本单元。
• 驱动模块的设计比桩模块简单
  

单元测试策略

自顶向下的单元测试

• 方法
  • 先对最顶层的基本单元进行测试，把所有调用的单元做成桩模块。然后再对第二层的基本单元进行测试，使用上面已测试的单元做驱动模块。依此类推直到测试完所有基本单元。
• 优点
  • 在集成测试前提供早期的集成途径。在执行上和详细设计的顺序一致。不需要开发驱动模块。
• 缺点
  • 随着测试的进行，测试过程越来越复杂，开发和维护成本增加。
• 总结
  • 比孤立单元测试的成本高很多，不是单元测试的一个好的选择。

自底向上的单元测试

• 方法
  • 先对最底层的基本单元进行测试，模拟调用该单元的单元做驱动模块。然后再对上面一层进行测试，用下面已被测试过的单元做桩模块。依此类推，直到测试完所有单元。
• 优点
  • 在集成测试前提供系统早期的集成途径。不需要开发桩模块。
• 缺点
  • 随着测试的进行，测试过程越来越复杂。
• 总结
  • 比较合理的单元测试策略，但测试周期较长。

孤立单元测试

• 方法
  • 不考虑每个单元与其它单元之间的关系，为每个单元设计桩模块或驱动模块。每个模块进行独立的单元测试。
• 优点
  • 简单、容易操作，可达到高的结构覆盖率。
• 缺点
  • 不提供一种系统早期的集成途径。
• 总结
  • 最好的单元测试策略。

单元测试的难点

• 到底要测试到什么程度
  • 草草了事/过犹不及/何处是平衡点
  • 确定测试的标准之一：覆盖率
• 大量的测试代码和测试用例
  • 生成、共享、管理、标注很麻烦
  • 尽量使用测试工具
    • 测试过程中工具用的最多的地方
    • 单元测试（JUint）、后期的回归测试（TestingWhiz）、负载测试（WebLoad、QALoad）、缺陷管理（bugfree、禅道）、功能测试（WinRunner ）

主要单元测试方法

• 人工静态分析
• 自动静态分析
• 自动动态测试
• 人工动态测试

单元测试输入

• 《软件需求规格说明书》
• 《软件详细设计说明书》
• 《软件编码与单元测试工作任务书》
• 《软件集成测试计划》
• 《软件集成测试方案》
• 用户文档

单元测试的输出

• 《单元测试计划》
• 《单元测试方案》
• 《需求跟踪说明书》或需求跟踪记录
• 代码静态检查记录
• 《正规检视报告》
• 问题记录
• 问题跟踪和解决记录
• 软件代码开发版本
• 《单元测试报告》
• 《软件编码与单元测试任务总结报告》

单元测试重点内容

• 白盒测试
  • 语句覆盖测试
  • 判定覆盖测试
  • 条件覆盖测试
  • 判定—条件覆盖测试
  • 条件组合测试
  • 路径覆盖测试
• 黑盒测试
  • 等价类划分方法
  • 边界值分析方法
  • 错误推测方法
• 静态测试
  • 代码走查
  • 代码审查
  • 代码评审

静态测试

代码走查

非正式的一种交叉检查，自己的代码由他人来检查。

• 定义
  • 采用讲解、讨论和模拟运行的方式进行的查找错误的活动。
• 注意
  • 引导小组成员在走查前通读设计和编码。
  • 限时，避免跑题。
  • 发现问题适当记录，避免现场修改。
  • 检查要点是代码是否符合标准和规范，是否有逻辑错误

代码审查

正式的，以会议的形式展开，由大家根据缺陷检查表共同审核代码的质量。

• 定义
  • 采用讲解、提问方式进行，一般有正式的计划、流程和结果。主要方法采用缺陷检查表。
• 注意
  • 以会议形式，制定会议目标、流程和规则，结束后要编写报告。
  • 按缺陷检查表逐项检查。
  • 发现问题适当记录，避免现场修改。
  • 发现重大缺陷，改正后会议需要重开。
  • 检查要点是缺陷检查表，所以该表要根据项目不同不断积累完善。

代码评审

在审查会后进行，审查小组根据记录和报告进行评估代码检查。

• 定义
  • 通常在审查会后进行，审查小组根据记录和报告进行评估。
• 注意
  • 充分审查了所规定的代码，并且全部编码准则被遵守。
  • 审查中发现的错误已全部修改。

静态测试检查内容

检查是否符合编程规范

• 可靠性
• 可读性和维护性、移植性
• 企业实施怎样的编码规范，取决于很多因素。
  • 编程采用的语言
  • 项目的规范化程度
  • 行业