所以，作者在本文中着重从测试经济学的视角，以过程建模的方法，给出了业界普遍存在的六个误区，一个软件 “ 变换 ” 过程缺陷导入模型，一个测试和纠错的成本模型和软件测试成本最小化停止条件。
【关键字】 软件测试;测试经济学;测试管理;测试停止条件
引言：
[ 美 ] Grenford J. Myers 在 1978 年所著的《 The Art of Software Testing 》一书中，首先用一章的篇幅论述了程序测试的心理学和经济学问题。他认为要淡软件测试问题， “ 最为重要的却是经济学问题和心理学问题 ” 。并在列举了当时大多数人使用的完全错误的 “ 测试 ” 定义所导致的危害之后，给出了被业界普遍公认和引用的 “ 较为恰当的定义 ” ，即 “ 程序测试是为了发现错误而执行程序的过程 ” 。
Grenford J. Myers 所以把测试经济学问题和心理学问题看得如此之重，因为软件测试至今仍是由人为主体的一系列活动，而人类的活动却具有高度的目的性， 即可以说绝大多数的人类行为是由 “ 目标驱动 ” 的。一个正确的测试目的，可引发一系列为实现该目的的有效测试行为和结果;相反，一个不正确的测试目的，可引发一系列无效的或有害的测试行为和结果。
? 什么是软件测试
在谈到软件测试时，业界还是都引用 Grenford J. Myers 在《 The Art of Software Testing 》一书中表述的观点：
① 程序测试是为了发现错误而执行程序的过程;
② 测试是为了证明程序有错，而不是证明程序无错误;
③ 一个好的测试用例是在于它能发现至今未发现的错误;
④ 一个成功的测试是发现了至今未发现的错误的测试。
但是软件测试 决不等同于找 BUG 。 不幸的是，仅凭字面意思理解这些观点，认为发现错误似乎是软件测试的唯一目的，这样就可能会产生一些误导。认为查找不出错误的测试就是没有价值了;一些软件企业在制定对测试组(人员)的业绩考核标准时，简单地把捕捉到缺陷个数作为主要考核指标。然而事实并非如此简单。那些把寻找缺陷当作是软件测试的唯一目的的测试管理人员往往会陷入一个又一个测试管理误区。
以下列出是作者总结的六个值得业界重视的误区。
误区一：忽视对正常输入的测试。
软件缺陷最常见的地方是哪里?一般来说软件缺陷最为密集的地方就是当用户输入非正常输入组合时。一方面软件设计人员较容易忽略一些极难发生的情况，另一方面设计与开发人员往往会把更多的精力用在功能实现上，容错与错误处理往往是开发上的薄弱环节。所以当测试人员将测试目标订在缺陷数量上时，重点测试非正常输入显然就是最好的手段。
然而对于用户来说，真正影响使用的却是正常输入组合激发的缺陷。而这种缺陷，一个就已经太多了。
例如对于一个记事本软件，也许没有人会去注意为什么将字体大小设置到大于 49151 的正整数时，每个字会突然变成一个小点。也许很少人会去在乎若将字体大小设置到超过窗口高度时右方的滚动卷标不能滚动到一个能让你看到某一个字的下半截的位置。但若使用一般的剪贴功能会将一段话搞成乱码，那每一个用户就都会跳起来了。
误区二：忽视设计阶段的参与与评估
在多数企业里，软件的设计阶段往往没有软件测试人员的参与，甚至有些企业在编码几乎完成了才开始组织测试团队。原因无他，设计还没定型呢，怎么找缺陷哪?
事实上设计上的缺陷往往是耗用成本最高，也是最难在开发后期修复的缺陷。而一个软件的质量与它有多大的设计缺陷有着密不可分的联系。而有经验的测试人员的质量意识，安全意识，对用户需求的了解及分析能力，对于打造高品质的软件设计都有着不可忽视的作用。
同时对于技术可行性与用户需求之间的设计妥协，测试人员也必须要有充分的评估和理解。这样在最紧张的开发后期，才不会把大量的(测试及开发人员的)宝贵时间用于记录和处理那些已在设计阶段确定放弃的功能。
误区三：忽视测试计划与测试文档的建立及维护。
设计测试计划与建立测试文档常常会被看作是浪费时间。即使做了也只是为了交差，要么敷衍了事，要么找个范本一抄，略作修改便万事大吉。真正测试起来还是全靠灵感与直觉。
但软件测试的另一个重要目的是确认及评估一个软件是否能够符合用户的需求。而对软件质量的保证不能只是靠测试人员一开金口，而要靠详细的测试计划以及完整的测试结果来取得用户的信任。
误区四：忽视缺陷的分析，报告及跟踪。
找到缺陷本身并不能提高软件的质量。只有缺陷被正确修复了才能真正提高软件的质量。作为一个好的测试人员不仅仅要善于发现缺陷，同时还要善于描述缺陷的表现特征，并积极跟踪缺陷的处理过程，确保缺陷被正确诊断及修复。不负责任的缺陷报告常常会给软件开发人员带来很多不必要的麻烦甚至误导。这会严重影响开发人员对测试人员的信任与尊重。
误区五：错误的测试目标及测试终止条件。
没有缺陷的软件是不存在的。同时也没有方法可以知道一个软件中到底有多少个缺陷。一个简单的文本处理软件经过三个月的测试找到了 100 个缺陷，那说明这个软件总共有多少缺陷呢?也许是 101 个，你找到了 99% 的缺陷，也许是 10000 个你只找到 1% 的缺陷。又或连着两个星期只找到一两个缺陷，那么说是软件质量已达到较高水平了呢，还是你的测试方法走进了死胡同呢?谁也说不清。
误区六：不懂得合理调配使用测试人员的知识技能结构。
除去发现缺陷的洞察力外，好的测试人员还应该拥有很好的组织能力，准确的表达能力，严密的逻辑推理能力，以及对软件开发过程，软件使用对象，软件开发技术等的较深入地了解。同时具备所有素质的测试人员也许比凤毛麟角还要难找。所以在构建一个测试团队的时候就一定要合理搭配拥有各种能力的测试人员，并在使用的时候注意发挥各自的特长。如果让所有测试人员一心一意地找 BUG ，那不仅仅是压制了其他方面的人才，整个测试团队的实际绩效必然会大打折扣，甚至会影响到整个软件产品的顺利开发。
? 软件质量与软件测试
为了定量地论述软件测试的经济目的，本节首先剖析一下软件质量与软件测试的关系。随着人们对软件特性、软件测试与软件质量的认识的深化，尤其是对质量认识的深化，任何一个软件企业要使自已提供给用户的产品达到并保持稳定的质量水平，不仅要关注对软件产品在发布或交付之前进行严格的软件测试，而要从软件需求获取开始，对整个软件开发过程都要引入严格的质量管理，在每个开发阶段均要引入软件测试，并且这种质量管理不能停留在早期的质量检验型管理，而要转为全面的质量管理和第三方的质量认证或评估。
显见，在 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 )。所以，对一个项目经理、软件工程组以及测试组来说，同样要重视软件测试的质量效益。
? 软件测试的经济目的
事实上，作为软件开发企业来说，投入人力，资金搞软件测试的最终目的还是离不开经济效益。而对与测试项目的管理也不能离开这个大前提。软件测试的经济效益主要来自以下两个方面。一是满足用户需求，提高产品的竞争力，最终提高产品的销售量。二是尽早发现缺陷，降低售后服务成本。而软件测试的最终目的就是使它带来的经济效益最大化。
? 满足用户需求，提高产品的竞争力，最终提高产品的销售量。
一个学生编写程序可能是为了学习语言，算法，技巧等知识。一个科研人员编写程序可能是为了验证某个理论，计算某个结果，或实现某个算法。而一个软件企业生产一个软件则只有一个目的 – 盈利。同其他所有企业一样，要盈利，首先要把用户当作上帝。只有满足了用户的需求，并能使用户用的方便、用的放心，用户才会心甘情愿地掏钱。所以作为软件品质的最后把关者，软件测试要把用户的想法放在第一位。从设计测试计划到构造测试用例，从实际进行测试到跟踪缺陷处理，都要从用户的角度去考虑每一个问题。
首先，用户花钱购买软件实际上是购买软件的功能。所以软件测试首先要保证用户所需的功能都能正确而可靠地实现。在设计测试计划时应从用户实际可能使用本软件的基本流程或典型使用脚本出发，分析各个功能的重要性和相关性，再根据现有资源及时间构造和筛选测试用例。
其次，要想保住老用户、吸引新用户，产品的质量是关键。对于一个传统工业企业来说，一个产品的质量也许可以用一连串的行业指标来界定;而对软件企业来说，一个软件的质量是完全由用户来评价的。用户对软件质量的评价通常包含下列五个方面：
? 可靠性
? 安全性
? 性能
? 易用性
? 外观
因而软件测试也要针对这几个方面构造相应的测试用例。
? 尽早发现缺陷，降低后继质量成本
那么是不是说找缺陷就不重要了呢?当然不是。软件测试的另一个经济目标是尽早发现缺陷，降低修复及售后服务成本。显然，每一个已发布产品中的缺陷除了会影响产品及企业的声誉外，还会直接增加产品的售后服务成本。无论是派人到现场调试，或研发、发布补丁程序都要远比在发布前的修复成本昂贵数十倍，甚至数百倍。
事实上，许多统计资料表明，开发过程每前进一步，发现和修复一个缺陷的平均成本要提高 10 倍。在代码复查阶段，平均 1-2 分种能发现和修复一个缺陷，在初始测试阶段要 10-20 分钟。在集成测试时要花费 1 个小时或更多，在系统测试时要花 10-40 个小时。所以软件测试除了可以揭示和评估软件产品的可靠性之外的首要任务，就是要在开发过程中尽可能早地找到可能存在的各种缺陷，并找出最佳的解决方案。一旦在某一 “ 变换 ” 过程的工作产品成了次品，那末后继的所有 “ 变换 ” 过程的工作产品也永远是一个次品。
现在再来分析上节所导出的成本公式 (3)
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 )
再设定不再是把软件测试和修复都留到最后，而是前移到每个 “ 变换 ” 过程 Pi 后，且设定对每个中间工作产品的缺陷捕获率和缺陷修复率分别为 RTi 和 RRi ，那末整个软件产品的测试和缺陷修复总成本为：
CT = CT 1 +CT 2 +CT 3 +…+CT n
= N 0 ×RT 1 (CT 1 + RR 1 ×CR 1 )
+ (N 0 (1-RT 1 ×RR 1 )+NS 1 +NR 1 ))×RT 2 (CT 2 + RR 2 ×CR 2 )
+ (N 0 (1-RT 1 ×RR 1 )+NS 1 +NR 1 ))×((1-RT 2 ×RR 2 )+NS 3 +NR 3 ))RT 3 (CT 3 + RR 3 ×CR 3 )
+……
+ (N 0 (1-RT 1 ×RR 1 )+NS 1 +NR 1 ))×((1-RT 2 RR 2 )+NS 3 +NR 3 ))×…
×( (1-RT n-1 ×RR n-1 )+NS n +NR n )…))×RT n (CT n + RR n ×CR n ) …… (4)
由 (4) 可知，当
N 0 =NS 1 =NR 1 = NS 2 =NR 2 =…=NS n =NR n =0时，有
CT=0
显见，这就是人们期望的在每个 “ 变换 ” 过程 P i 中均实现最理想的 “ 零 ” 缺陷目标的结果。但是，这是不可能的，因为至今软件项目涉及的诸多的 “ 变换 ” 过程 P i 还是人工介入的，尤其是由多人或众多团队介入后，引入缺陷是难免的，所以，控制成本的中心任务之一就是如何预防和减少对每一 “ 变换 ” 过程 P i 所引入的缺陷数。现在再回到上节中的 “ 变换 ” 过程 P i 模型 -- 图- 2 ，即：
首先，在上游工作产品 D i-1 流入 “ 变换 ” 过程 P i 前，由该过程的操作者共同参与对 D i-1 评估或测试，尽量避免或减少经输入端导入和引发的缺陷数，其中导入的缺陷数是指上游工作产品 D i-1 自身中所含的缺陷数，而引发的缺陷数是指由于上游工作产品 D i-1 中所含的缺陷或因为该过程的操作者对上游工作产品 D i-1 理解上的差异而引发的。
其次，由于 S ：规范、标准、 … 的缺陷，如无完整、清晰的、可操作的文档化的东西，有些团队甚至只有非文挡化的约定，以至造成该 “ 变换 ” 是一种非稳定的过程，是因人而异的，这就使这种 “ 变换 ” 过程 Pi 所流向下游的工作产品 Di 必定是极不稳定的。
最后，来分析 R ：资源对过程质量的影响，其中虽然涉及到该过程所用的外部构件、工具、工作平台等，但这里重点要分析的是该过程的操作者 - 人。根据 [ 美 ]Watts S.Humphrey 在他的《 Introduction to the Personal Softwere Process 》，即 PSP 一书中指出：学生和工程师一般在设计阶段每小时引入 1~3 个缺陷，在编码阶段每小时引入 5~8 个缺陷。在代码复查阶段一般每小时发现 6~12 个缺陷，在测试阶段每小时排除 2~4 个缺陷。而经过 PSP 培训后，所引入的缺陷可减少 50% ，缺陷排除效率提高近 4 倍。又指出 Motorila 的工程师在学习了 PSP 后，第一次在测试时只发现 1 个缺陷。
实际上，排除一个缺陷的时间要比测试一个缺陷多 5 到 6 倍。当然，系统越复杂，排除缺陷的费用越高。以 Micrisoft NT 系统为例，共修复了 30000 个缺陷，测试一共花费了 250 个人 - 年，平均 16 个小时修复 1 个缺陷。
显然测试和排除缺陷不仅要耗费人工、花钱，而且还要拖延时间，所以对缺陷的测试和排除要综合考虑质量( Q )、时间进度( T )与成本( C )。保证工作质量的原则之一是每一次要开发出合格的产品。切忌一开始就匆忙进行设计、编码，首先要有一个好的、合格的需求，然后按需求特性确定一个适用的软件需求开发过程及每个 “ 变换 ” 过程 Pi 应遵循的规范、标准，在选择合适的开发团队、操作人员和其它资源后，还要进行上岗培训，它包括对上游工作产品进行 “ 变换 ” 应遵循的规范、标准及所选择的工具、构件等。随后再启动后继的变换过程及质量监测和控制点，以保证每一个变换过程都能产生更好的、完整的文档。以防止由于不清楚或不完整引入的缺陷。这些都是软件质量保证和测试策划过程必须与以关注的。
例如，以设计过程为例。一个有经验的工程师在进行设计时，经常在各个设计层次之间动态地进行切换： ① 首先要理解一定抽象层次上是如何工作的，然后才能在高层设计中放心用。 ② 如一个功能过去用过就可不考虑它的细节，否则要进行详细设计，甚至做一个原型加以验证后，才可放心地回到高层设计。 ③ 由于难以把设计阶段和实现阶段严格区分开来，所以要关注的是设计活动，即过程，而且除了要按照支持该过程的规范、标准，把该过程的最终结果完整地、正确地在设计文档中给予详细地表述，即评估、测试及后继的下游过程是可视化的，还要在给出最终设计文档前的活动中适当引入同行评审来过滤掉不良设计思路或碰撞出好的思路，这也是十分有效的。
现在我们再来考虑评估、测试活动的实际效益问题。事实上，软件工作产品中越复杂或所含的缺陷愈少，测试发现缺陷的效率越低，因此测试、修复缺陷的花费越大。加上软件产品中确切的缺陷数是无法知道的，无休止的测试也是不可取的。这就涉及到两个方面的问题 – ：第一是这些缺陷可能带来的损失到底有多大; 第二是这种缺陷被激发的可能性有多大。如果两个问题的答案都是 “ 极小 ” ，那么就根本不应当列入考虑之中。
? 何时应当停止测试
软件测试还有一个很重要的问题 – 何时应当停止测试?对于许多企业来说，终止测试的时间往往是随产品的预定发布时间或交付时间来定的。甚至有的地方产品发布或交付前一周还在写新功能。每一个测试人员都在叫测试时间不够，但又没有谁能说出到底多少时间才算够。
其实问题也很简单，一个合理的测试终止条件只能来源于一个清晰的测试目标。如果测试的目标是找到所有的缺陷，那么无论多少时间都是不够的。而要从测试的两个经济目标来看，合理的终止条件应当是由以下两点组成：
测试是为了保证软件的质量，而软件的质量标准是由用户来决定的。这个标准应当在软件开发初期由用户需求调查所得，如果每一需求项都列出了可测试的、被共同利益者认可的标准和写入测试计划之中的测试用例，这样软件测试结束的第一个必要条件就是所有在测试计划中所列出的测试项和标准(常见的有：必要及重要的功能通过测试，某种公认的认证测试用例包测试通过，连续无故障运行超过一定时间等)都被通过。
通常来说，早期找到并排除的缺陷越多，总的售后服务的成本就越少，但密集的测试就会导致测试成本的增高。而对测试来说，随着旧的缺陷不断地被找到并修复，软件的质量也就越来越好，后继的服务成本就越来越低，相应地，新缺陷也就越来越难找，即测试成本越来越难高。所以售后服务的成本和测试的成本大致可以用下图来表示：
由图- 4 可知，当找到并解决的缺陷占总缺陷的比例达到 T E 时，可终止测试。因为再要通过测试去发现一个缺陷成本比发布后再去维护的成本要高了。其实从企业利润的角度来看，就要使这两部分的成本之和最小。当然在实际情况下，这两条曲线是无法准确估计的。人们往往按拇指规则，即假设残留的缺陷数与最后一阶段排除的缺陷数相等，启用这样一个较为合理的中止条件 ： 当一段时间内(通常是一个星期)测试不出的新缺陷时，就可中止寻找缺陷了;或按本文提出的测试效益规则，即当找到的新缺陷的实际价值低于相同时间的测试运行费用、或测试成本与维护成本之和达最小值时、或经 3 至 5 倍企业同类软件开发项目的平均单位缺陷测试时间内测试不出的新缺陷时就可中止找缺陷了。
结尾
随着软件行业的进一步发展，对软件测试及软件测试管理的要求也越来越高，尤其是在当前发达国家渐渐兴起软件外包浪潮的关键时刻，谁能提供低价可靠的软件开发服务，谁就能抢先占领市场，而高效经济的软件测试则必然会成为软件企业竞争力的最大助益。
文章来源于领测软件测试网 https://www.ltesting.net/
