友情提示：如果本网页打开太慢或显示不完整，请尝试鼠标右键“刷新”本网页！
软件测试的艺术(中文清晰版)(PDF格式)-第3部分
快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部! 如果本书没有阅读完，想下次继续接着阅读，可使用上方 "收藏到我的浏览器" 功能 和 "加入书签" 功能！
接触和使用的电子设备都内置了一个“计算机”或者计算芯片，以及运行在其上
的软件系统。不妨回想一下在今天的社会中还在使用哪些不需要软件驱动的设备，
没错，锤子和手推车是，但是这些工具也大量使用在由软件控制和操作的车间中。
软件的普遍应用提升了测试的意义。今天的设备已经千百倍强于它们的“前辈”，
今天的“计算机”这个概念也变得越来越广泛和越来越难准确地定义。数字电视、
电话、游戏产品、汽车等都有一颗计算机的“心”以及运行其中的软件，以至于
在某些情况下它们自己本身也能够被看做是一台特别的计算机。
因此，现在的软件会潜在地影响到数以百万计的人，使他们更高效地完成工作，
反之也会给他们带来数不清的麻烦，导致工作或事业的损失。这并不是说今天的软件
比本书第1版发行时更重要，但可以肯定地说，今天的计算机（以及驱动它的软件）
无疑已影响到了更多的人、更多的行业。
就某些方面而言，软件测试变得更容易了，因为大量的软件和操作系统比以
往更加复杂，内部提供了很多已充分测试过的例程供应用程序集成，无须程序员
从头进行设计。例如，图形用户界面（GUI ）可以从开发语言的类库中建立起来，
同时，由于它们是经过充分调试和测试的预编程对象，将其作为自定义应用程序
的组成部分进行测试的要求就减少了许多。
另外，尽管市场上的测试书籍越来越多，甚至有过剩之嫌，似乎依旧有很多开
发人员对全面的测试并不那么欢迎。引入更优秀的开发工具、使用已经通过测试
…………………………………………………………Page 14……………………………………………………………
2 软件测试的艺术
的GUI （图形界面控件）控件、紧张的交付日期以及高度集成的便利开发环境会让
测试变得仅仅是让那些最基本的测试用例走走过场罢了。影响不大的bug 也许只不
过会让最终用户觉得使用不方便而已，然而严重的bug 则可能造成经济损失甚至是
人身伤害。本书所阐述的方法旨在帮助设计人员、开发工程师以及项目经理更好
地理解全面综合测试的意义所在，并提供行之有效的指南以帮助达成测试的目标。
所谓软件测试，就是一个过程或一系列过程，用来确认计算机代码完成了其
应该完成的功能，不执行其不该有的操作。软件应当是可预测且稳定的，不会给
用户带来意外惊奇。在本书中，我们将讨论多种方法来达到这个目标。
好了，在开始阅读本书之前，我们想让读者做一个小测验。我们要求设计一
组测试用例（特定的数据集合），适当地测试一个相当简单的程序。为此要为该程
序建立一组测试数据，程序须对数据进行正确处理以证明自身的成功。下面是对
该程序的描述：
这个程序从一个输入对话框中读取三个整数值，这三个整数值代表
了三角形三条边的长度。程序显示提示信息，指出该三角形是何种三角
形：不规则三角形、等腰三角形还是等边三角形。
注意，所谓不规则三角形是指三角形中任意两条边不相等，等腰三角形是指
有两条边相等，而等边三角形则是指三条边相等。另外，等腰三角形等边的对角
也相等（即任意三角形等边的对角也相等），等边三角形的所有内角都相等。
用你的测试用例集回答下列问题，借以对其进行评价。对每个回答“是”的答
案，可以得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 软件测试的艺术
而没发现任何错误。
我们可以类比一下病人看医生的情况，病人因为身体不舒服而去看医生。如
果医生对病人进行了一些检查和化验，却没有诊断出任何病因，我们就不会认为
这些检查和化验是“成功的”，因为病人支付了昂贵的检查和化验费用，而病状却
依然如故。病人会因此而质疑医生的诊断能力。但是，如果医生诊断出病人是胃
溃疡，那么这次检测就是“成功的”，医生可以开始进行相应的治疗。因此，医疗
行业会使用“成功的”或“不成功的”来表达诊断结果。我们当然可以类推到软
件测试中来，当我们开始测试某个程序时，它就好似我们的病人。
“软件测试就是证明软件不存在错误的过程”，这个定义会带来第二个问题。对
于几乎所有的程序而言，甚至是非常小的程序，这个目标实际上也是无法达到的。
另外，心理学研究表明，当人们开始一项工作时，如果已经知道它是不可行
的或无法实现时，人的表现就会相当糟糕。举例来说，如果要求人们在15分钟之
内完成星期日《纽约时报》里的纵横填字游戏，那么我们会观察到10分钟之后的
进展非常小，因为大多数人都会却步于这个现实，即这个任务似乎是不可能完成
的。但是如果要求在四个小时之内完成填字游戏，我们很可能有理由期望在最初
10分钟之内的进展会比前一种情况下的大。将软件测试定义为发现程序错误的过
程，使得测试是个可以完成的任务，从而克服了这个心理障碍。
诸如“软件测试就是证明‘软件做了其应该做的’的过程”此类的定义所带
来的第三个问题是，程序即使能够完成预定的功能，也仍然可能隐藏错误。也就
是说，当程序没有实现预期功能时，错误是清晰地显现出来的；如果程序做了其
不应该做的，这同样是一个错误。考虑一下第1章中的三角形测试程序。即使我们
证明了程序能够正确识别出不规则三角形、等腰三角形和等边三角形，但是在完
成了不应执行的任务后（例如将1，2 ，3说成是一个不规则三角形或将0 ，0 ，0说
成是一个等边三角形），程序仍然是错的。如果我们将软件测试视作发现错误的过
程，而不是将其视为证明“软件做了其应该做的”的过程，我们发现后一类�
快捷操作: 按键盘上方向键 ← 或 → 可快速上下翻页 按键盘上的 Enter 键可回到本书目录页 按键盘上方向键 ↑ 可回到本页顶部!
温馨提示： 温看小说的同时发表评论，说出自己的看法和其它小伙伴们分享也不错哦！发表书评还可以获得积分和经验奖励，认真写原创书评 被采纳为精评可以获得大量金币、积分和经验奖励哦！