软件测试之可测试性分析

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

因为测试是如此的困难，因此，需要知道做些什么才能理顺测试过程。

有时，程序员愿意去做对测试过程有帮助的事，而一个包括可能的设计点、特性等等的检查表对他们是很有用的。

肯定存在可用于在很多方面测度可测试性的度量，有时，可测试性被用来表示一个特定测试集覆盖产品的充分程度。

在军方还用它来表示工具被检验和修复的容易程度。

这两种意义都略不同于“软件可测试性” 。

下面的检查表提供了一组可测试软件的特征：
可操作性。

“运行得越好，被测试的效率越高。

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

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

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

可观察性。

“你所看见的就是你所测试的。

”
•每个输入有唯一的输出。

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

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

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

•容易识别错误输出。

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

•自动报告内部错误。

•可获取源代码。

可控制性。

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

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

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

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

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

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

可分解性。

“通过控制测试范围，能够更快地分解问题，执行更灵巧的再测
•软件系统由独立模块构成。

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

简单性。

“需要测试的内容越少，测试的速度越快。

”
•功能简单性（例如：特性集是满足需求所需的最小集合）
•结构简单性（例如：将体系结构模块化以限制错误的繁殖）。

•代码简单性（例如：采用代码标准为检查和维护提供方便）。

稳定性。

“改变越少，对测试的破坏越小。

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

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

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

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

易理解性。

“得到的信息越多，进行的测试越灵巧。

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

•设计的改变被通知。

•可随时获取技术文档。

•技术文档组织合理。

•技术文档明确详细。

•技术文档精确性稳定。

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

但是关于测试本身呢？Kaner , Falk和Nguyen [ KAN93给出了“好”测试的一些属性：
1. 一个好的测试发现错误的可能性很高。

为了达到这个目标，测试者必须理解软件，并尝试设想软件如何才能失败，理想，被探测的错误类别，例如，
在GUI（图形用户界面）中有一种潜在的错误，即错误识别鼠标位置。

应该设计一个测试集来验证鼠标位置识别的错误。

2. 一个好的测试并不冗余。

测试的时间和资源是有限的，没有必要构造一
个与其他测试用途完全相同的测试，每一个测试都应该有不同的用途（哪怕是细微的差异）。

例如，软件SafeHom①中有一个模块被用来识别用户密码以决定是否启动系统，为了测试密码输入的错误，测试者设计了一系列的输入密码测试。

在不同的测试中输入有效与无效密码（四个数字），然而，每一个有效/无效密码将检测一种不同错误模式，例如，一个将8080 作为有效密码的系统将不会接受非法密码1234，如果接收1234，将产生错误，另一个测试输入1235，与1234 的测试意图相同，因此是冗余的，然而，非法输入8081 或8180 就有些细微的差异，即对与有效密码相近但并
不相同的密码该进行测试。

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

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

4. 一个好的测试既不会太简单，也不会太复杂。

虽然有时会将一组测试组合到一个测试用例中，其副作用可能屏蔽错误，通常，每一个测试应该独立执行。