•  软件质量与软件测试 

    为了定量地论述软件测试的经济目的，本节首先剖析一下软件质量与软件测试的关系。随着人们对软件特性、软件测试与软件质量的认识的深化，尤其是对质量认识的深化，任何一个软件企业要使自已提供给用户的产品达到并保持稳定的质量水平，不仅要关注对软件产品在发布或交付之前进行严格的软件测试，而要从软件需求获取开始，对整个软件开发过程都要引入严格的质量管理，在每个开发阶段均要引入软件测试，并且这种质量管理不能停留在早期的质量检验型管理，而要转为全面的质量管理和第三方的质量认证或评估。

    显见，在 1983 年 IEEE 的软件测试定义 “ 使用人工或自动手段来运行或测定某个系统的过程，其目的在于检验它是否满足规定的需求或是弄清预期结果与实际结果之间的差别。 ” 中只是明确指出： 1) 软件测试是运行或测定某个系统的过程； 2) 软件测试的目的是为了检验软件系统是否满足需求。把测试视作检验的一种手段和活动。

    实际上，业界很早就从早期的狭义的软件测试概念和实施范围作了拓展。软件测试的对象不再限于可运行的程序代码，而拓展到质量管理中所涉及的在整个开发各阶段的输入、输出、过程和中间工作产品，测试活动也不限于对可运行代码的测试活动，而包括复查、走查、评审、验证等。事实上，软件整个开发过程，是一系列 “ 变换 ” 或 “ 处理和活动 ” 过程 P1 、 P2 、 … 、 Pn 所组成的半序序列 ( 参见图 —1) 。

    图－ 1 中 D0 是源头（用户需求）， D1 、 … 、 Dn-1 是诸中间 “ 变换 ” 过程的工作产品， Dn 为最终工作产品。显见，每个 “ 变换 ” 过程都有它的输入和输出，都可能导入这样或哪样的缺陷（ Bugs ），而且这种缺陷按缺陷扩大模型还会逐级扩大，尤其是在上游工作产品频繁出现更改时。不过这些中间工作产品大多只是以静态文档形态给出的。对它们的测试通常也只能采用 “ 静态测试 ” 方法，其中包括工程测试（非正式的内部评审）、正式测试（正式评审）、审核测试（验证、审计）和检查性测试（检测、确认）等。

    为此，为了保证最终工作产品的质量，必须关注对每一个中间 “ 变换 ” 过程以及它们输入和输出的质量的检测和评估，尽可能防止缺陷向下游传布和扩散。以下再通过一个 “ 变换 ” 过程来分析一下每个 “ 变换 ” 过程可能导入的质量隐患：

    显见，在每一个 “ 变换 ” 过程中导入缺陷途径是多种多样的，例如：

    上游工作产品中隐含的缺陷；

    规范、标准、 … 中隐含的缺陷；

    资源、工具引入的缺陷，其中主要是由 “ 变换 ” 过程的操作者（组、个人）引入的缺陷，因为据大量统计资料统计，即使一个有经验的程序员，在编码过程中，平均每写 7-10 行程序就会有引入 1 个缺陷。事实上，对每一过程的操作者，导入缺陷有诸多的客观的和主观的原因，其中包括对上游工作产品、规范、标准、 … 以及引用外部构件的理解上的差异，操作者对知识、经验和技能方面的欠缺和习惯性、过失性错误，以及团队沟通和版本管理、工具使用中差错和过失。

    由上可知，对 “ 变换 ” 过程 Pi 流向下游工作产品 Di 中所导入缺陷个数可用以下公式表示：

    N i =k i N i-1 +NS i +NR i …… (1)

    其中

    N i - 是 “ 变换 ” 过程 P i 的工作产品 D i 中所隐含缺陷数；

    k i - 是 “ 变换 ” 过程 P i 对上游工作产品 D i-1 中所隐含缺陷数的扩大系数 k i ，通常 k i 在 2 ～ 10 之间；

    NS i – 是由于 “ 变换 ” 过程 P i 的规范、标准、 … 缺陷所引入的缺陷数
 
    NR i – 是由于 “ 变换 ” 过程 P i 所用资源、工具、技术所引入的缺陷数，显见它与参与本 “ 变换 ” 过程 P i 的人员特性及状态有极大的相关性。

    这样就可从公式 (1) 导得，

    N 1 =k 1 N 0 +NS 1 +NR 1

    N 2 =k 2 N 1 +NS 2 +NR 2

    ……

    N n =k n N n-1 +NS n +NR n

    最终产品 Dn 中所包含的缺陷个数为

    N n = k 1 k 2 …k n N 0 +k 2 k 3 …k n NS 1 +k 2 k 3 …k n NR 1 +…+NS n +NR n … (2)

    显见，当 n=5 、 k1=k2=k3=k4=k5=3 时，在需求阶段引入了一个缺陷，而且未能尽早于以排除，那未最终经逐级扩大在最终产品中可产生 35 = 243 个缺陷。

    可是，一旦在某个环节导入缺陷后，有些是难以被显露的，即使通过软件测试被外显，被发现，有的也难以捕获到它。只有捕获到它，才能设法纠正它。不幸的是，有时即使找到了，而且也采取了补救措施，结果由于不良的补救措施又会引发新的缺陷。就象人从向上的自动扶梯一步一步往下走一样，可能你往下走了一步（排除了一个缺陷），结果自动扶梯又往上滚动好几步（又引发了多个缺陷），这样一来，推倒重来的事是常有的。

    现设在 Di 中每发现和修复一个缺陷的平均成本分别是 CTi 和 CRi ，如果诸缺陷都留到最终产品 Dn 才进行测试和排除，那末总的发现和修复成本为：

    C n =(k 1 k 2 …k n N 0 +k 2 k 3 …k n NS 1 +k 2 k 3 …k n NR 1 +…+NS n +NR n )×(CT n +CR n ) (3)

    所以，随着软件产品规模、复杂性增长，加上在启动项目时，一些需求往往是模糊的。一般的软件组织要化一半以上的精力来查找和修复错误。加上测试时间往往难以预计，没完没了的产品缺陷常常是造成超支和超期的主要原因。

    可是对最终用户来说最关心的当然还是最终软件产品的功能、可靠性、效率、易于使用、易于移植性。而对一个实际软件项目企业高层管理者说，他们自然更多注重总的质量和项目赢利，而不是某一特性，而要权衡质量（ Q ）、成本（ C ）、进度（ T ）。所以，对一个项目经理、软件工程组以及测试组来说，同样要重视软件测试的质量效益。