软件测试之可测试性分析

软件测试之可测试性分析

在理想的情况下，软件工程师在设计计算机程序、系统或产品时应该考虑可测试性，这就使得负责测试的人能够更容易地设计有效的测试用例，但是，什么是“可测试性”呢？JamesBach②这样描述可测试性：

软件可测试性就是一个计算机程序能够被测试的容易程度。因为测试是如此的困难，因此，需要知道做些什么才能理顺测试过程。有时，程序员愿意去做对测试过程有帮助的事，而一个包括可能的设计点、特性等等的检查表对他们是很有用的。

肯定存在可用于在很多方面测度可测试性的度量，有时，可测试性被用来表示一个特定测试集覆盖产品的充分程度。在军方还用它来表示工具被检验和修复的容易程度。这两种意义都略不同于“软件可测试性” 。下面的检查表提供了一组可测试软件的特征：

可操作性。“运行得越好，被测试的效率越高。”

?系统的错误很少（错误加上测试过程中的分析和报告开销）。

?没有阻碍测试执行的错误。

?产品在功能阶段的演化（允许同时的开发和测试）。

可观察性。“你所看见的就是你所测试的。”

?每个输入有唯一的输出。

?系统状态和变量可见，或在运行中可查询。

?过去的系统状态和变量可见，或在运行中可查询（例如：事务日志）。

?所有影响输出的因素都可见。

?容易识别错误输出。

?通过自测机制自动侦测内部错误。

?自动报告内部错误。

?可获取源代码。

可控制性。“对软件的控制越好，测试越能够被自动执行与优化。”

?所有可能的输出都产生于某种输入组合。

?通过某种输入组合，所有的代码都可能被执行。

?测试工程师可直接控制软件和硬件的状态及变量。

?输入和输出格式保持一致且有结构。

?能够便利地对测试进行说明、自动化和再生。

可分解性。“通过控制测试范围，能够更快地分解问题，执行更灵巧的再测

?软件系统由独立模块构成。

?能够独立测试各软件模块。

简单性。“需要测试的内容越少，测试的速度越快。”

?功能简单性（例如：特性集是满足需求所需的最小集合）

?结构简单性（例如：将体系结构模块化以限制错误的繁殖）。

?代码简单性（例如：采用代码标准为检查和维护提供方便）。稳定性。“改变越少，对测试的破坏越小。

?软件的变化是不经常的。

?软件的变化是可控制的。

?软件的变化不影响已有的测试。

?软件失效后能得到良好恢复。

易理解性。“得到的信息越多，进行的测试越灵巧。”

?设计能够被很好地理解

?内部、外部和共享构件之间的依赖性能够被很好地理解。

?设计的改变被通知。

?可随时获取技术文档。

?技术文档组织合理。

?技术文档明确详细。

?技术文档精确性稳定。

软件工程师可运用James Bach 提出的这些属性来开发可测试的软件配置（即程序、数据和文档）。

但是关于测试本身呢？Kaner , Falk和Nguyen [ KAN93给出了“好”测试的一些属性：

1. 一个好的测试发现错误的可能性很高。为了达到这个目标，测试者必须理解软件，并尝试设想软件如何才能失败，理想，被探测的错误类别，例如，

在GUI（图形用户界面）中有一种潜在的错误，即错误识别鼠标位置。应该设计一个测试集来验证鼠标位置识别的错误。

2. 一个好的测试并不冗余。测试的时间和资源是有限的，没有必要构造一

个与其他测试用途完全相同的测试，每一个测试都应该有不同的用途（哪怕是细微的差异）。例如，软件SafeHom①中有一个模块被用来识别用户密码以决定是否启动系统，为了测试密码输入的错误，测试者设计了一系列的输入密码测试。在不同的测试中输入有效与无效密码（四个数字），然而，每一个有效/无效密码将检测一种不同错误模式，例如，一个将8080 作为有效密码的系统将不会接受非法密码1234，如果接收1234，将产生错误，另一个测试输入1235，与1234 的测试意图相同，因此是冗余的，然而，非法输入8081 或8180 就有些细微的差异，即对与有效密码相近但并

不相同的密码该进行测试。

3. 一个好的测试应该是“最佳品种” [KAN93]。

在一组目的相似的测试中，时间和资源的限制可能只影响其某个子集的执行，此时，应该使用最可能找到所有错误的测试。

4. 一个好的测试既不会太简单，也不会太复杂。虽然有时会将一组测试组合到一个测试用例中，其副作用可能屏蔽错误，通常，每一个测试应该独立执行。