18、软件模块构建变更测量与故障分析

软件模块构建变更测量与故障分析

1. 软件构建过程中的模块变更与故障引入

在软件系统的开发过程中，会经历一系列的顺序构建。在这个过程中，故障会被识别出来，并且代码会被修改以消除这些已识别的故障。然而，引入新代码和最初的代码生成一样，都是容易产生故障的过程。在软件的演化过程中，很可能会引入新的故障。

代码的变更并不总是仅仅为了修复故障。在代码的演化过程中，一些变更代表着功能增强、设计修改，或者是为了响应不断变化的需求。这些增量式的代码增强也可能会导致更多故障的引入。因此，随着系统经历一系列的构建，每个被修改的程序模块的故障指数（FI）也必然会发生变化。FI的变化率可以作为故障引入率的一个很好的指标。

一旦确定了故障引入率，就有可能估计在开发过程中任何时刻系统中剩余的故障数量。由于我们使用FI的变化来衡量故障引入率，因此可以在模块级别（模块可以是一个过程、函数或方法）估计剩余故障的数量。这些信息对于软件开发经理来说非常有用，他们可以据此估计移除剩余故障所需的资源，不仅可以估计剩余故障的数量，还可以将故障检测和移除资源集中在那些估计剩余故障浓度最高的软件部分。

不过，这只是问题的一部分。一旦软件在实际环境中运行，我们还需要确定其可靠性。估计的剩余故障数量是一个静态的指标，必须将其转化为对系统动态行为的估计。

软件测试的一般概念是，故障移除率通常会超过故障引入率。在大多数情况下，这可能是正确的。但有些变更比其他变更更为重大，在这些更实质性的变更周期中，系统中实际的故障数量很可能会增加。因此，假设软件测试会单调地减少系统中的故障数量是错误的。只有当软件开发过程足够好，能够确保每次代码变更时移除的故障多于引入的故障时，这种情况才会发生。故障移除率相对容