首页 > 代码库 > 单元测试中 Right-BICEP 和 CORRECT

单元测试中 Right-BICEP 和 CORRECT

My Blog:http://www.outflush.com/


在单元测试中,有6个总结出的值得测试的方面,这6个方面统称为 Right-BICEP,通过这6个方面的指导,可以较完全的测试出代码中的bug。本文就是简单的介绍 Right-BICEP 到底指的哪6个方面,以及其中边界测试中的 CORRECT 助记短语。


  • Right – Are the results right? 结果是否正确?
  • B – are all the boundary conditions correct? 所有边界条件都是正确的么?
  • I – can you check the inverse relationships? 能否检查一下反向关联?
  • C – can you cross-check results using other means? 能够使用其他手段交叉检查一下结果?
  • E – can you force error conditions to happen? 是否可以强制错误条件产生?
  • P – are performance characteristics within bounds? 是否满足性能要求?

Right Result

对于测试而言,最首要的任务就是查看所期望的结果是否正确。


Boundary Conditions 边界条件

代码中的bug大多出现在边界条件附近。

一些需要考虑的边界条件:

  • 完全伪造或者不一致的输入数据
  • 格式错误的数据
  • 空值或不完整的值
  • 一些与意料中的合理值相去甚远的值
  • 要求一个无重复值的序列,但是传入一个有重复值的序列
  • 要求一个有序许刘,但是传入一个无需序列
  • 事件到达的次序是错误的,或碰巧和期望的次序不一致

边界条件助记短语 CORRECT

  • Conformance(一致性):值是否和预期一致。可以理解为当输入并不是预期的标准数据时,被测试方法是否可以正确输出预期结果(或抛出异常)。
  • Ordering(顺序性):值是否像应该的那样是无序或有序的。
  • Range(区间性):值是否位于合理的最小值和最大值之间。
  • Reference(依赖性):代码是否引用了一些不在代码本身控制范围之内的外部资源,当这些外部资源存在或不存在、满足或不满足时,代码是否可以产生相应的预期结果。
  • Existence(存在性):值是否存在(是否为null、0、在一个集合中)。测试方法是否可以处理值不存在的情况。
  • Cardinatity(基数性):是否恰好有足够的值。这里的基数指的是计数,测试方法是否可以正确计数,并检查最后的计数值。
  • Time(相对或绝对时间性):所有事情的发生是否是有序的、是否在正确的时刻、是否恰好及时。与时间相关问题有:相对时间(时间上的顺序)、绝对时间(消耗的时间和钟表上的时间)、并发问题。例如:方法调用的时间顺序、代码超时、不同的本地时间、多线程同步等。
  • 注意:在考虑边界条件时,需要同时考虑方法的传入参数以及其内部数据。


Inverse Relationships 检查反向关联

即使用反向的逻辑关系验证某些方法。

比如检查一个计算平方根的函数,可以通过对其结果进行平方来检查。但是要注意的是,应该使用不同与被测试方法的原理来编写反向测试,因为如果原理错误可能会使得测试与被测试方法都包含bug。


Cross-Check 使用其他手段交叉检查结果

通过其他经过验证的途径来测试当前被测试方法的结果是否正确

例如被测试方法存在多个备用算法,这时选择被测试方法没有使用的,并且已经经过验证的算法在测试方法中使用,最后比较测试算法和被测试方法的结果是否一致。

另外也可以通过一些数据从侧面验证被测试方法结果是否正确,例如图书馆中借出的书籍数和在库的书籍数的总和是不变的,这时便可以使用交叉检查,即使用一种数量检查另一种数量。


Force Error 强制产生错误

通过强制引发一些现实中的错误来测试代码是如何处理这些错误,这些现实错误可能是:内存耗光、硬盘用满、时钟错误、断网等。


Performance 性能特性

即测试在数据量逐渐增加的时候,性能曲线是否能达到预期(稳定)。


参考资料:《单元测试之道Java版:使用JUnit》