软件可测性系列3

软件可测性系列3(Testability)

Overview

• 1.为什么软件可测性很重要
• 2.可控性和可见性
• 3.偶然不可测性
• 4.白盒可测性
• 5.黑盒可测性

偶然不可测性

这些舞动的仓鼠是不是很有趣? 如果你不得不测试一些代码，而这些代码的稳定性和可控性让你感觉像转呼啦圈一样，你就不会觉得有趣了。

为了发现一枚bug，测试人员必须:

• 1、到达有缺陷的代码
• 2、触发这个bug
• 3、将错误的结果传递到一个可观察的界面上
• 4、错误的结果必须能被观察到
• 5、错误的结果必须被承认是缺陷

少了这些条件的任意一个都意味着一项测试在执行暴露bug的这项任务时失败了。 Jeff Voas在他精彩的可测性分析中提供了一个权威的例子，说明了即算简单的代码也很难被测试。

偶然性正确

对这个细微的功能进行穷尽测试是可能的:总共只有65,536种可能的输入j,所以在一个循环里面嵌套进它,并产生所有的值是简单而快速的。

但是其中有多少测试将会暴露bug?只有6个测试用例会产生错误的结果:-30001,-30000,-1,0,29999以及30000.所有的其他65,530个输入运行都不会有任何失败,这个bug不会被暴露.有多少开发人员会打算进行穷尽测试?这些bug很容易被遗漏。

所以即使很微不足道的程序也会限制可测性,甚至(掩盖)细微的bug.为什么会这样?只是执行带bug的代码,不一定总是能导致可观测的失败(技术术语是"偶然性正确").

是否记得2000年的计算机千年虫?系统已经正常运行了数十年,当运行到1999年12月31号之后,突然失败了。这是一类bug的例子,只有在一些特定的数据值才会产生错误的结果——那种情况下,当年字段从99进位截断到00.许多系统理解00为1900(不是2000)从而导致许多系统的失败。

复杂度

复杂难懂也会降低可测性。针对这个的技术定义有很多种,但是在我的演讲中,我想以视觉的和听觉的作为复杂性的象征。作为视觉感受我喜欢Jackson Pollock的《秋颂》: 

对于复杂性我们能做些什么?基本的复杂度即函数和特性的实现独立化程度.简单的堆叠,越来越多。但是这个"更多"目前来说为解决应用的问题是有必要,就难以被避免.

偶然的复杂性经常能被避免,然而一般是粗心的业余开发过程或者自私的本地优化造成的结果。实际上，这太常见了，它有它自己的反抗模式:大泥团.当然,这自然就降低了可测性，并且掩盖了很多的bug.

其他降低可测性的方面实例:

• 不确定的依赖
• 竞态条件
• 消息延迟
• 非同步的更新共用的未受保护的数据

舞动的仓鼠是一个很好的视觉比喻——可爱但是非常不稳定.为了避免构建一个会产生不稳定性负面影响的系统,第4部分将讲解,怎样利用白盒技术提高可测性。

原文链接:http://robertvbinder.com/software-testability-part-3-white-box-complexity/