单元测试中 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》

单元测试中 Right-BICEP 和 CORRECT

时间: 2024-10-10 05:58:25

单元测试中 Right-BICEP 和 CORRECT的相关文章

使用Ninject+Moq在单元测试中抽象数据访问层

一.测试方法的业务逻辑时,通常都需要从数据库读取测试数据,但是每次初始化数据库数据都很麻烦,也会影响到其它业务对数据的访问,怎样抽象数据访问层呢?就是用Moq去模拟数据访问的逻辑 二.步骤如下 2.1 定义数据访问接口和实现 public interface IDBAccess { List<string> GetList(string request); } public class DBAccessImp : IDBAccess { public List<string> Ge

Java中单元测试中:@BeforeClass,@Before,@Test,@After,@AfterClass中的问题详解

在Junit4中还有的测试注解有:  @BeforeClass ,@Before,@Test,@After,@AfterClass 1.其中:@BeforeClass,@AfterClass是Junit4中新添加进去的 2.如果Run as --->Junit Test,运行含有@Test注释的方法是,那么所有注解方法都将被执行,所含的执行顺序是: @BeforeClass ,@Before,@Test,@After,@AfterClass 3.在JUnit4中,如果测试类继承了TestCase

Java 单元测试中的多线程无故退出

问题发现 最近在复习多线程相关知识,结果一动手就出现了问题,问题是这样的,在单元测试中使用多线程测试,发现只要子线程在睡眠一段时间,程序就退出了,毫无征兆!!!! 看看我的代码(请不要拘泥这段代码带来的并发问题):  public class ThreadTest{       class MyThread implements Runnable{                   private int count = 0 ;                   public void ru

在单元测试中使用 Microsoft.VisualStudio.TestTools.UnitTesting 成员

单元测试框架支持在 Visual Studio 中进行单元测试. 对单元测试进行编码时,请使用 Microsoft.VisualStudio.TestPlatform.UnitTestFramework 命名空间中的类和成员. 当您从头开始编写了单元测试或要改进由测试的代码生成的单元测试时,您便可以使用这些类和成员. 元素组 为了帮助提供对单元测试框架的更为清晰的概述,本节将 UnitTesting 命名空间的元素分为相关的功能组. 说明 使用特性元素(其名称以字符串 Attribute 结尾)

单元测试中如何配置log4net

按道理来说,单元测试中基本没有对于日志的需求,这是由于单元测试的定位来决定的. 因为单元测试的思想就是针对的都是小段代码的测试,逻辑明确,如果测试运行不通过,简单调试一下,就能很容易地排查问题.但是单元测试也是一个简便好用的的启动器.总不能调试任何代码,都要我启动一个Windows或者Web项目吧,这样太笨重了,而且项目越大,启动时间越长.在把单元测试用作启动器的情况下,就会有需求使用log4net. 进入正题 如何在一个单元测试项目中,配置log4net: 1. 添加log4net配置文件 这

单元测试中测试用例的设计方法

单元测试中测试用例的设计方法 1. 用于语句覆盖的基路径法 基路径法保证设计出的测试用例,使程序的每一个可执行语句至少执行一次,即实现语句覆盖.基路径法是理论与应用脱节的典型,基本上没有应用价值,读者稍作了解即可,不必理解和掌握. 基路径法步骤如下: 1)画出程序的控制流图 控制流图是描述程序控制流的一种图示方法,主要由结点和边构成,边代表控制流的方向,节点代表控制流的汇聚处,边和结点圈定的空间叫做区域,下面是控制流图的基本元素: 以下代码: void Sort(int iRecordNum,

Robolectric 单元测试中使用 Ressource

单元测试类中: @RunWith(RobolectricGradleTestRunner.class) @Config(constants=BuildConfig.class, sdk = 21) 获取 context: RuntimeEnvironment.application build.gradle 中: 若使用 multidextestCompile 'org.robolectric:shadows-multidex:3.0' 否则testCompile 'org.robolectri

VS单元测试中Assert类的用法

首先说介绍一下,Assert类所在的命名空间为Microsoft.VisualStudio.TestTools.UnitTesting 在工程文件中只要引用Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll就可以使用了, 在这里我举例说明Assert里面的一些主要的静态成员. 1.             AreEqual:方法被重载了N多次,主要功能是判断两个值是否相等:如果两个值不相等,则测试失败. 2.            

在MS单元测试中引发期望异常

首先准备一个引发异常的方法. 1 public static void ThrowException() 2 { 3 throw new ArgumentException(); 4 } 然后在单元测试项目中,写下测试方法. [TestMethod] [ExpectedException(typeof(ArgumentException))]// 构造函数中为期望引发的异常. public void ThrowExceptionTest() { Program.ThrowException();