项目必备技术之单元测试

1.什么是单元测试？

• 单元测试是指对软件中最小可测试单元进行检查和验证，通常而言，一个单元测试是用于判断每个特定条件（或场景）下某个特定函数的行为，单元测试是由开发者编写的。执行单元测试就是为了证明编写的功能代码与我们期望保持一致。
• 引申概念：方法级测试
  • 针对每一个单独的小方法，在与程序其他部分相隔离得情况下进行测试，输入参数，校验出参数是否合乎预期，因此，不测数据库操作，不测网络连接，不测依赖调用，以上场景全部mock掉。

2.测试的流程

• 自顶向下
  

• 自底向上
  

3.为什么要进行单元测试？

• 主要原因在于“左移”问题的发现与修复
• 越早发现问题越好
  
• 其中蓝色的曲线是软件研发生命周期过程中缺陷的引入情况，从图中我们可以看到，缺陷在最初的编码阶段是引入最多的
• 黄色的实线是传统的开发模式下问题的修复和发现情况，可以看到很多缺陷其实是后期阶段才能发现的
• 紫色的曲线是缺陷修复的成本，修复的成本却是随着软件生命周期的推进指数级上升
• 所以针对这种普遍存在的行业痛点，采用左移的方式，从一开始就避免缺陷和相关问题的引入，可以极大程度的保障软件质量，减少缺陷修复成本，同时加速交付流程。

4.我们能从单元测试中得到什么？

• 测试更加充分
• bug修复代价最少
• 代码自review
• 代码功能更具易用性
• 回归测试
• 快速定位bug

5.白盒测试技术

6.动态单元测试技术

• 语句覆盖：

  • 程序中每条语句至少被执行一次
  • 特点：可以很直观的从源代码中测到测试用例，无须细分每条判定表达式
  • 缺点：隐式逻辑分支无法测试

• 判定覆盖：

  • 每个判定至少有一次为真值，有一次为假值，即：程序中的每个分支至少执行一次，每个判断的取真、取假至少执行一次
  • 特点：覆盖强度几乎增大一倍，测试用例简单
  • 缺点：关注焦点是表达式逻辑值，而不是其中的每个条件，可能会遗漏部分测试路径

• 条件覆盖：

  • 设计足够多的测试用例，使得判定中的每个条件获得各种可能的结果，即每个条件至少有一次为真值，有一次为假值
  • 特点：相对于判定覆盖，增加了对符合判定情况的测试，增加了测试路径
  • 缺点：需要足够多的测试用例，条件覆盖并不能保证判定覆盖，测试用例低效

• 判定/条件覆盖

  • 设计足够多的测试用例，使得判定中每个条件的所有可能结果至少出现一次，每个判定本身所有可能结果也至少出现一次
  • 特点：满足判定覆盖准则和条件覆盖准则，弥补了二者的不足
  • 缺点：未考虑条件的组合情况，容易漏，会忽略条件中取或的情况

• 组合覆盖：

  • 使得每个判定条件结果的所有可能组合至少出现一次
  • 特点：多重条件覆盖准则满足判定覆盖、条件覆盖和判定/条件覆盖准则
  • 缺点：线性的增加了测试用例的数量，也不能保证所有路径被测试

• 路径覆盖：

  • 覆盖程序中所有可能的路径
  • 特点：可以对程序进行彻底的测试，比前面五种的覆盖面都要更加广
  • 缺点：需要设计大量、复杂的测试用例，使得工作量呈指数级增长，特殊路径无法测试

7.动态单元测试技术方法应用分布场景