关闭

单元测试应该测试什么?——Right-BICEP

6058人阅读 评论(0) 收藏 举报

 

单元测试应该测试什么?——Right-BICEP


Right——结果是否正确?

B——是否所有的边界条件都是正确的?

I——能查一下反响关联吗?

C——能用其它手段交叉检查一下吗?

E——你是否可以强制错误条件发生?

P——是否满足性能要求?


结果是否正确

这个最简单不过了,就是看程序运行之后的结构和文档是否一致。当然可能很多的时候一个方法没有很完整的文档描述它,那至少也应该有简单的文字描述,否则没有判断是否正确的依据了。一个原则是:对于验证被测方法是否正确的这件事情,如果某些做法能够使它变得更加容易,那么就采纳它吧。


边界条件CORRECT


很多臭虫都会集中在边界附近,所以应该多注意。


一致性(Conformance)——值是否符合预期的格式?


很多时候,传递给方法的值或者方法运行后产生的值必须符合某种特定的格式。必须考虑的是,如果数据不能像期望的那样符合格式要求,将会出现什么情况。


有序性(Ordering)——一组值是该有序的,还是该无序的?


应该考虑数据顺序,或者是在一个很大的数据集合中某一数据的位置。


区间性(Range)——值是否在一个合理的最大值和最小值的范围之内?


对于一个变量,它所属类型的取值范围可能比需要的或想要的更加宽广。比如,人的年龄、角度等。


引用、耦合性(Reference)——代码是否引用了一些不受代码本身直接控制的外部因素?


如果对于类的状态、其它对象的状态,或者全局应用程序的状态,需要作一些假设,那么就需要对代码进行测试,保证其在假设未满足的情况下运行良好。前置条件和后置条件都必须检测。


前置条件(preconditions):系统必须处于什么状态下,该方法才能运行。当前置条件不能满足的情况下程序是否能够正确运行。


后置条件(postconditions):方法运行之后将会有哪些状态发生。程序的返回结构必须检查,伴随产生的副作用也必须检查。


存在性(Existence)——值是否存在(要小心null0、“”、有时可能还需要注意空格字符串)?


存在性的问题很容易出现在方法的参数上,也经常出现在方法要用到的类的属性上。特别是引用类型,要特别注意。当遇到null等值时,采取什么策略需要及早考虑。应该形成一贯的处理策略,形成风格。可以考虑抛出异常,并且Message描述问题应尽量细致明确。


基数性(Cardinality)——是否恰好有足够的值?


对基数性问题的认识我目前还不是很透彻。


时间性,绝对的或者相当的(Time)——所有事情是否都是按顺序发生的?是否在正确的时间?是否及时?


测试边界是最有价值的工作,因为bug通常会集中在这里。边界测试需要考虑的主要问题:


完全伪造或者不一致的输入数据。

格式错误的数据。

空值或者不完整的值,如00.0, “”, null之类的。

一些与意料中的合理值相去甚远的数值。

如果是传入一系列数据,要考虑是否允许重复,考虑值是否应该有特定顺序,顺序是否可能有错误等。


检查反向关联

对于一些方法,我们可以使用反向的逻辑关系来验证它们。要注意的是,当你同时编写了原方法和它的方向测试时,一些bug可能会被在两个函数中都出现的错误所掩盖。在可能的情况下,应该使用不同的原理来编写反向测试。


使用其他手段来实现交叉检查

通常解决一个问题会有多种手段,如果你选择了其中一个方法,那么就可以用其它的方法来检验它。另一种方法就是:使用类本身不同组成部分的数据,并且确信它们能“合起来”。


强制产生错误条件

应当能够通过强制引发错误,来测试你的代码是如何处理所有这些真实世界中的问题的。

下面是一些我们能想到的环境方面的因素:

内存耗光

磁盘用满

时钟出问题

网络不可用或者有问题

系统过载

受限的调色板

显示分辨率过高或者过低


性能特性

一个检查起来会很有益处的部分是性能特性,而不是性能本身。


参考文章:

使用NUnit进行浮点数测试准则

“用NUnit测试异常另有妙法!! ”

“NUnit断言大全”
0
0

查看评论
* 以上用户言论只代表其个人观点,不代表CSDN网站的观点或立场
    个人资料
    • 访问:175380次
    • 积分:2797
    • 等级:
    • 排名:第12808名
    • 原创:100篇
    • 转载:3篇
    • 译文:0篇
    • 评论:23条
    最新评论