按键盘上方向键 ← 或 → 可快速上下翻页，按键盘上的 Enter 键可回到本书目录页，按键盘上方向键 ↑ 可回到本页顶部！
————未阅读完？加入书签已便下次继续阅读！
用户带来意外惊奇。在本书中，我们将讨论多种方法来达到这个目标。
好了，在开始阅读本书之前，我们想让读者做一个小测验。我们要求设计一
组测试用例（特定的数据集合），适当地测试一个相当简单的程序。为此要为该程
序建立一组测试数据，程序须对数据进行正确处理以证明自身的成功。下面是对
该程序的描述：
这个程序从一个输入对话框中读取三个整数值，这三个整数值代表
了三角形三条边的长度。程序显示提示信息，指出该三角形是何种三角
形：不规则三角形、等腰三角形还是等边三角形。
注意，所谓不规则三角形是指三角形中任意两条边不相等，等腰三角形是指
有两条边相等，而等边三角形则是指三条边相等。另外，等腰三角形等边的对角
也相等（即任意三角形等边的对角也相等），等边三角形的所有内角都相等。
用你的测试用例集回答下列问题，借以对其进行评价。对每个回答“是”的答
案，可以得1分：
1。 是否有这样的测试用例，代表了一个有效的不规则三角形？（注意，如1、
2 、3和2 、5 、10这样的测试用例并不能确保“是”的答案，因为具备这样
边长的三角形不存在。）
2。 是否有这样的测试用例，代表一个有效的等边三角形？
3。 是否有这样的测试用例，代表一个有效的等腰三角形？（注意，如2 、2 、4
的测试用例无效，因为这不是一个有效的三角形。）
4。 是否至少有三个这样的测试用例，代表有效的等腰三角形，从而可以测试
到两等边的所有三种可能情况（如3 、3 、4 ；3 、4 、3 ；4 、3 、3 ）？
5。 是否有这样的测试用例，某边的长度等于0 ？
…………………………………………………………Page 15……………………………………………………………
第1章 一次自评价测试 3
6。 是否有这样的测试用例，某边的长度为负数？
7。 是否有这样的测试用例，三个整数皆大于0 ，其中两个整数之和等于第三
个？（也就是说，如果程序判断1、2 、3表示一个不规则三角形，它可能就
包含一个缺陷。）
8。 是否至少有三个第7类的测试用例，列举了一边等于另外两边之和的全部可
能情况（如1、2 、3 ；1、3 、2 ；3 、1、2 ）？
9。 是否有这样的测试用例，三个整数皆大于0 ，其中两个整数之和小于第三个
整数（如1、2 、4 ；12、15、30 ）？
10。 是否至少有三个第9类的测试用例，列举了一边大于另外两边之和的全部
可能情况（如1、2 、4 ；1、4 、2 ；4 、1、2 ）？
11。 是否有这样的测试用例，三边长度皆为0 （0 ，0 ，0 ）？
12。 是否至少有一个这样的测试用例，输入的边长为非整数值（如2。5、3。5、5。5）？
13。 是否至少有一个这样的测试用例，输入的边长个数不对（如仅输入了两
个而不是三个整数）？
14。 对于每一个测试用例，除了定义输入值之外，是否定义了程序针对该输入值
的预期输出值？
当然，测试用例集即使满足了上述条件，也不能确保能查找出所有可能的错
误。但是，由于问题1至问题13代表了该程序不同版本中已经实际出现的错误，对
该程序进行的充分测试至少应该能够暴露这些错误。
开始关注自己的得分之前，请考虑以下情况：以我们的经验来看，高水平的
专业程序员平均得分仅7。8 （满分14）。如果读者的得分更高，那么祝贺你。如果
没有那么高，我们将尽力帮助你。
这个测验说明，即使测试这样一个小的程序，也不是件容易的事。因此，想
象一下测试一个十万行代码的空中交通管制系统、一个编译器，甚至一个普通的
工资管理程序的难度。随着面向对象编程语言（如Java 、C＋＋ ）的出现，测试也变
得更加困难。举例来说，为测试这些语言开发出来的应用程序，测试用例必须要
找出与对象实例或内存管理有关的错误。
从上面这个例子来看，完全地测试一个复杂的、实际运行的程序似乎是不太可能
的。情况并非如此！尽管充分测试的难度令人望而生畏，但这是软件开发中一项非常
必需的任务，也是可以实现的一部分工作，通过本书我们可以认识到这一点。
…………………………………………………………Page 16……………………………………………………………
第2 章
Chapter 2
软件测试的心理学和经济学
软件测试是一项技术性工作，但同时也涉及经济学和人类心理学的一些重要因素。
在理想情况下，我们会测试程序的所有可能执行情况，而在大多数情况下，
这几乎是不可能的。即使一个看起来非常简单的程序，其可能的输入与输出组合
可达到数百种甚至数千种，对所有的可能情况都设计测试用例是不切合实际的。
对一个复杂的应用程序进行完全的测试，将耗费大量的时间和人力资源，这样在
经济上是不可行的。
另外，要成功地测试一个软件应用程序，测试人员也需要有正确的态度（也
许用“愿景”（vision ）这个词会更好一些）。在某些情况下，测试人员的态度可能
比实际的测试过程本身还要重要。因此，在深入探讨软件测试的本质之前（指技
术层面），我们先探讨一下软件测试的心理学和经济学问题。
2。1 软件测试的心理学
测试执行得差，其中一个主要原因在于大多数的程序员一开始就把“测试”
这个术语的定义搞错了。他们可能会认为：
“软件测试就是证明软件不存在错误的过程。”
“软件测试的目的在于证明软件能够正确完成其预定的功能。”
“软件测试就是建立一个‘软件做了其应该做的’信心的过程。”
这些定义都是本末倒置的。
每当测试一个程序时，应当想到要为程序增加一些价值。通过测试来增加程
序的价值，是指测试提高了程序的可靠性或质量。提高了程序的可靠性，是指找
出并最终修改了程序的错误。
…………………………………………………………Page 17……………………………………………………………
第2章 软件测试的心理学和经济学 5
因此，不要只是为了证明程序能够正确运行而去测试程序；相反，应该一开
始就假设程序中隐藏着错误（这种假设对于几乎所有的程序都成立），然后测试程
序，发现尽可能多的错误。
那么，对于测试，更为合适的定义应该是：
“测试是为发现错误而执行程序的过程”。
虽然这看起来像是个微妙的文字游戏，但确实有重要的区别。理解软件测试
的真正定义，会对成功地进行软件测试有很大的影响。
人类行为总是倾向于具有高度目标性，确立一个正确的目标有着重要的心理
学影响。如果我们的目的是证明程序中不存在错误，那就会在潜意识中倾向于实
现这个目标；也就是说，我们会倾向于选择可能较少导致程序失效的测试数据。
另一方面，如果我们的目标在于证明程序中存在错误，我们设计的测试数据就有
可能更多地发现问题。与前一种方法相比，后一种方法会更多地增加程序的价值。
这种对软件测试的定义，包含着无穷的内蕴，其中的很多都蕴涵在本书各处。
举例来说，它暗示了软件测试是一个破坏性的过程，甚至是一个“施虐”的过程，
这就说明为什么大多数人都觉得它困难。这种定义可能是违反我们愿望的；所幸
的是，我们大多数人总是对生活充满建设性而不是破坏性的愿景。大多数人都本
能地倾向于创造事物，而不是将事物破坏。这个定义还暗示了对于一个特定的程序，
应该如何设计测试用例（测试数据）、哪些人应该而哪些人又不应该执行测试。
为增进对软件测试正确定义的理解，另一条途径是分析一下对“成功的”和
“不成功的”这两个词的使用。当项目经理在归纳测试用例的结果时，尤其会用到
这两个词。大多数的项目经理将没发现错误的测试用例称为一次“成功的测试”，
而将发现了某个新错误的测试称为“不成功的测试”。
这又是一次本末倒置。“不成功的”表示事情不遂人意或令人失望。我们认为，
如果在测试某段程序时发现了错误，而且这些错误是可以修复的，就将这次合理
设计并得到有效执行的测试称做是“成功的”。如果本次测试可以最终确定再无其
他可查出的错误，同样也被称做是“成功的”。所谓“不成功的”测试，仅指未能
适当地对程序进行检查，在大多数情况下，未能找出错误的测试被认为是“不成
功的”，这是因为认为软件中不包含错误的观点基本上是不切实际的。
能发现新错误的测试用例不太可能被认为是“不成功的”，也就是说，能发现
错误就证明它是值得设计的。“不成功的”测试用例，会看到程序输出正确的结果
…………………………………………………………Page 18……………………………………………………………
6 软件测试的艺术
而没发现任何错误。
我们可以类比一下病人看医生的情况，病人因为身体不舒服而去看医生。如
果医生对病人进行了一些检查和化验，却没有诊断出任何病因，我们就不会认为
这些检查和化验是“成功的”，因为病人支付了昂贵的检查和化验费用，而病状却
依然如故。病人会因此而质疑医生的诊断能力。但是，如果医生诊断出病人是胃
溃疡，那么这次检测就是“成功的”，医生可以开始进行相应的治疗。因此，医疗
行业会使用“成功的”或“不成功的”来表达诊断结果。我们当然可以类推到软
件测试中来，当我们开始测试某个程序时，它就好似我们的病人。
“软件测试就是证明软件不存在错误的过程”，这个定义会带来第二个问题。对
于几乎所有的程序而言，甚至是非常小的程序，这个目标实际上也是无法达到的。
另外，心理学研究表明，当人们开始一项工作时，如果已经知道它是不可行
的或无法实