软件测试的心理学和经济学【软件测试的艺术】

件测试是-项技术性工作，但同时也涉及经济学和人类心理学的些重要因素。

在理想情况下，我们会测试程序的所有可能执行情况。然而，在大多数情况下，这几乎是

不可能的。即使.个看起来非常简单的程序，其可能的输入与输出组合可达到数百种甚至数千

种，对所有的可能情况都设计测试用例是不切合实际的。对一个复杂的应用程序进行完全的测

试，将耗费大量的时间和人力资源，以致于在经济上是不可行的。

另外，要成功地测试一个软件应用程序，测试人员也需要有正确的态度(也许用“愿景

(vision)”这个词会更好-些)。在某些情况下，测试人员的态度可能比实际的测试过程本身还

要重要。因此，在深人探讨软件测试更加技术化的本质之前，我们先探讨一下软件测试的心理

学和经济学问题。

软件测试的心理学

测试执行得差，其中一个主要原因在于大多数的程序员一开始就把"测试"这个术语的定

义搞错了。他们可能会认为:

“软件测试就是证明软件不存在错误的过程。”

“软件测试的目的在于证明软件能够正确完成其预定的功能。

“软件测试就是建立一个‘ 软件做了其应该做的’信心的过程。"

这些定义都是本末倒置的。

每当测试一个程序时，总是想为程序增加一些价值。通过测试来增加程序的价值，是指测

试提高了程序的可靠性或质量。提高了程序的可靠性，是指找出并最终修改了程序的错误。

因此，不要只是为了证明程序能够正确运行而去测试程序,相反，应该一开始就假设程序

中隐藏着错误(这种假设对于几平所有的程序都成立),然后测试程序，发现尽可能多的错误。

那么，对于测试，更为合适的定义应该是:

“测试是为发现错误而执行程序的过程"。

虽然这看起来像是个微妙的文字游戏，但确实有重要的区别。理解软件测试的真正定义,

会对成功地进行软件测试有很大的影响。

人类行为总是倾向于具有高度目标性，确立一个正确的目标有着重要的心理学影响。如果

我们的目的是证明程序中不存在错误，那就会在潜意识中倾向于实现这个目标:也就是说，我

们会倾向于选择可能较少导致程序失效的测试数据。另一方面，如果我们的目标在于证明程序

中存在错误，我们设计的测试数据就有可能更多地发现问题。与前-种方法相比，后一种方法会更多地增加程序的价值。

这种对软件测试的定义，包含着无穷的内蕴，其中的很多都蕴袖在本各处。举例米说, .

它暗示了软件测试是一个破坏性的过程，其至是一个“施虐”的过程。这就说明为什么大多数

人都觉得它困难。这种定义可能是违反我们愿望的，所幸的是，我们大多数人总是对生活充满

建设性而不是破坏性的愿景。大多数人都本能地倾向于创造事物，面不是将事物破坏。这个定义还暗示了对1-个特定的程序，应该如何设计测试用例(测试数据),哪些人应该而哪些人义不应

该执行测试。

为增进对软件测试正确定义的理解，另一条途径是分析下对“成功的”和“不成功的"这两个词的使用。当项目经理在归纳测试用例的结果时，尤其会用到这两个闻。大多数的项H

经理将没发现错误的测试用例称为次“成功的测试”，而将发现了某个新错误的测试称为“不

成功的测试”.

这又是一次本木倒置。“不成功的"表示事情不遂人意或令人失望。我们认为，如果在测试

某段程序时发现了错误，而且这些错误是可以修复的，就将这次合理设计井得到有效执行的测试称作是“成功的"。如果本次测试可以最终确定再无其他可查出的错误，同样也被称作是“成功的”。所谓“不成功的”测试，仅指未能适当地对程序进行检查，在大多數情况下，未能找出错误的利试被认为是“不成功的“.这是内为认为软件中不包含错误的观点基本1:是不切实际的。

能发现新错误的测试用例不太可能被认为是“不成功的" ;相反，能发现错误就证明它是值得设计的。一个“不成功的"测试用例.会使程序输出正确的结果，但不能发现任何错误。

我们可以类比. 下辆人看医生的情况，病人因为身体不舒服而去看医生。如果医生对病人进行了.些实验检侧，却没有诊断出任何病因，我们就不会认为这些实验检测是“成功的”。之所以是“不成功的“检测，是因为病人支付了昂贵的实验检测费用，而病状却依然如故。病人

会因此而质疑医生的诊断能力。但是，如果实验检测诊断出病人是胃溃疡，那么这次检测就是

“成功的”，医生: 可以开始进行适当的治护。因此，医疗行业会使用“成功的” 或“不成功的”来表达适当的意思。我们当然可以类推到软件测试中来，当我们I开始测试某个程序时，它就好似我们的病人。

“软件测试就是证明软件不存在错误的过程"，这个定义会带来第:个问题。 对f几乎所有的程序而高，甚至是非常小的程序,这个目标实际上也是无法达到的。

别外，心理学研究表明，当人们开始一项工作时，如果匕经知道它是不可行的或无法实现时，人的表现就会相当糟糕。举例来说，如果要求人们在15分钟之内完成星期日《纽约时报》

里的纵横填字游戏、那么我们会观察到10分钟之后的进展非常小，因为大多数人都会却步于这

个现实，即这个任务似乎是不可能完成的。但是如果要求在四个小时之内完成填字游戏，我们!

很可能有理由期望任最初10分钟之内的进展会比前-种情况下的大。将软件测试定义为发现程

序错误的过程，使得测试是个可以完成的任务，从而克服了这个心理障碍。

诸如“软件测试就是证明软件做了 其应该做的"的过程”此类的定义所带来的第三个问

题是，程序即使能够完成预定的功能，也仍然可能隐藏错误。也就是说，当程序没有实现预期

功能时，错误是清晰地显现出来的:如果程序做了其不应该做的，这同样是一个错误。 考虑-下第1章中的三角形测试程序。即使我们证明了程序能够正确识别出不规则三角形、等腰三角形和等边三角形，但是在完成了不应执行的任务后(例如将1, 2, 3说成是一个不规则三角形或将0, 0, 0说成是一个等边三角形)，程序仍然是错的。如果我们|将软件测试视作发现错误的过程，而不是将其视为证明“软件做了其应该做的"的过程，我们发现后- -类错误的可能性会大很多。总结一下，软件测试更适宜被视为试图发现程序中错误(假设其存在)的破坏性的过程。一个成功的测试用例，通过诱发程序发生错误，可以在这个方向上促进软件质量的改进。当然， 最终我们还是要通过软件测试来建立某种程度的信心:软件做了其应该做的，未做其不应该儆 的。但是通过对错误的不断研究是实现这个目的的最佳途径。

有人可能会声称“本人的程序完美无缺”(不存在错误)，针对这种情况建立起信心的最好 办法就是尽量反驳他，即努力发现不完美之处，而不只是确认程序在某些输入情况下能够正确 地工作。

软件测试的经济学

给出了软件测试的适当定义之后，下一步就是确定软件测试是否能够发现“所有”的错误。 我们将证明答案是否定的，即使是规模很小的程序。-般说来，要发现程序中的所有错误也是 不切实际的，常常也是不可能的。这个基本的问题反过来暗示出软件测试的经济学问题、测试 人员对被测软件的期望，以及测试用例的设计方式。
为了应对测试经济学的挑战，应该在开始测试之前建立某些策略。黑盒测试和白盒测试是 两种最普遍的策略，我们将在下面两节中讨论。

黑盒测试

黑盒测试是一种重要的测试策略，又称为数据驱动的测试或输人/输出驱动的测试。使用这 种测试方法时，将程序视为一个黑盒子。测试目标与程序的内部机制和结构完全无关，而是将 重点集中放在发现程序不按其规范正确运行的环境条件。
在这种方法中，测试数据完全来源于软件规范(换句话说，不需要去了解程序的内部结构)。 如果想用这种方法来发现程序的所有错误，判定的标准就是“穷举输人测试”，将所有可能的输 入枭件都作为测试用例。为什么这样儆?比如说在三角形测试的程序中，试过了三个等边三角 形的测试用例，这不能确保正确地判断出所有的等边三角形。程序中可能包含对边长为3842,3842, 3842的特殊检查，并指出此三角形为不规则三角形。由于程序是个黑盒子,因此能够确 定此条语句存在的惟-方法，就是试验所有的输人情况。
要穷举测试这个三角形程序，可能需要为所有有效的三角形创建剥试用例，只要三角形边 长在开发语言允许的最大整数值范围内。这些测试用例本身就是天文数字，但这还决不是所谓 穷尽的:当程序指出一3，4, 5是一个不规则三角形或2, A, 2是-个等腰三角形时，问题就暴 露出来了。为了确保能够发现所有这样的错误，不仅得用所有有效的输人，而且还得用所有可 能的输人进行测试。因此，为了夯举测试一角形程序，实际上需要创建无限的测试用例，这当. 然是不可能的。
如果测试这个三角形程序都这么难的话，那么要穷举测试一个稍大些的程序的难度就更大。

文章截取自《软件测试的艺术》