《软件测试的艺术毕业论文》由会员分享，可在线阅读，更多相关《软件测试的艺术毕业论文（58页珍藏版）》请在金锄头文库上搜索。
1、软件测试的艺术毕业论文第1章一次自评价测试子本书25年前首次出版以来，软件测试变得比以前容易得多，也困难德多。软件测试何以变得更困难?原因在于大量编程语言，操作系统以及硬件平台的出现。在20世纪70年代只有相当少的人使用计算机，而今天在商业界和教育界，如果不使用计算机，几乎没有人能完成日常工作。况且，计算机本身的功能也比以前增强了数百倍。因此，我们现在编写的软件会潜在地影响到数以百万计的人，使他们更高地完成工作，反之也会给他们带来数不清的麻烦，导致工作或事业的损失。这并不是说今天的软件比本书第一版发行是更重要，但可以肯定地说，今天的计算机以驱动它的软件无疑已影响到了更多的人、更多的行业。就某些
2、方面而言，软件测试变得容易了，因为大量的软件和操作系统比以往更加复杂，内部提供了很多已充分的例程供应程序集成，无须程序员从头进行设计。例如，图形用户界面（GUI）可以从开发语言的类库中建立起来，同时，由于它们是经过充分调试和测试的可编程对象，将其作为用户应用程序测组成部分进行测试 的要求就减少了许多。所谓软件测试就是一个过程或一系列过程，用来确认计算机代码完成了其应该完成的功能，不执行其不该有的操作。软件应当是可预测且稳定的，不会给用户带来意外的惊奇。在本书中，我们将讨论多种方法来达到这个目标。好了，在开始阅读本书之前，我们想让读者做一个小测验。我们要求设计一组测试用例（特定的数据集合），使当
3、地测试一个相当简单的程序。为此要为该程序建立一组测试数据，程序须对数据进行正确处理以证明自身的成功。下面是对程序的描述：这个程序从一个输入对话框中读取三个整数数值。这三个整数数值代表了三角形三边的长度。程序显示提示信息，指出该三角形究竟是不规则三角形、等腰三角形还是等边三角形。注意，所谓不规则三角形是指三角形任意两条边不相等，等腰三角形是指有两条边相等，而等边三角形则是指三条边相等。另外，等腰三角形等边的对角也相等（即任意三角形等边的对角也相等），等边三角形的所有内角都相等。用你的测试用例集回答下列问题，借以对其进行评价。对每个回答“是”的答案，可以得1分：1. 是否有这样的测试用例，代表了一
4、个有效的不规则三角形？（注意，如1，2，3，和2，5，10这样的测试用例并不能确保“是”的答案，因为具备这样边长的三角形不存在。）2. 是否有这样的测试用例，代表一个有效的等边三角形？3. 是否有这样的测试用例，代表一个有效的等腰三角形？（注意如2，2，4的测试用例无效，因为这不是一个有效的三角形。）4. 是否至少有三个这样的测试用例，代表有效的等腰三角形，从而可以测试到两等边的所有三种可能情况（如3，3，4；3，4，3；4，3，3）？5. 是否有这样的测试用例，某边的长度等于0？6. 是否有这样的测试用例，某边的长度为负数？7. 是否有这样的测试用例，三个整数皆大于0.其中两个整数之和等于第
5、三个？（也就是说，如果程序判断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. 是否至少有一个这样的测试用例，输入的边长为非整数（如1.5，3.5，5.5）？13. 是否
6、至少有一个这样的测试用例，输入的边长个数不对（如仅输入了两个而不是三个整数）？14. 对于每一个测试用例，除了定义输入值之外，是否定义了程序针对该输入值的预期输出值？当然，测试用例即使满足了上述条件，也不能确保能查处所有可能的错误。但是，由于问题1至问题13代表了该程序不同版本中已经实际出现的错误，对该程序的充分测试至少应该能够暴露这些错误。开始关注自己的得分之前，请考虑以下情况：以我们的经验来看，高水平的专业程序员平均得分仅7.8（满分14）。如果读者的得分更高，那么祝贺你。如果没那么高，我们将尽力帮助你。这个测验说明，即使测试这样一个小的程序，也不是件容易的事。如果确实是这样，那么想象一下
7、测试一个十万行代码的空中交通管理系统，一个编译器，甚至一个普通的工资管理程序的难度。随着面向对象编程语言（如Java、C+）的出现，测试也变得更加困难。举例来说，为测试这些语言开发出来的应用程序，测试用例必须要找出与对象实例或内存管理有关的错误。从上面这个例子来看，完全地测试一个复杂的、实际运行的程序视乎是 不太可能的。情况并非如此！尽管充分的测试的难度令人望而生畏，但这是软件开发中一项非常必须的任务，也是可以实现的一部分工作，通过本书我们可以认识到这一点。第2章软件测试的心理学和经济学软件测试是一项技术性工作，但同时也涉及经济学和人类心里学的一些重要因素。在理想情况下，我们会测试程序的所有可
8、能情况。然而，在大多数情况下，这几乎是不可能的。即使一个看起来非常简单的程序，其可能输入与输出组合可达到数百种甚至数千种，对多有的可能情况都设计测试用例是不切实际的。对一个复杂的应用程序进行完全的测试，将耗费大量的时间和人力资源，以至于经济上是不可能的。另外，要成功地测试一个软件应用程序，测试人员也需要有正确的态度（也许用“愿景（vision）”这个词会更好一些）。在某些情况下，测试人员的态度可能比实际的测试过程本是还要重要。因此，在深入探讨软件测试更加技术化的本质之前，我们先探讨一下软件测试的心理学和经济学问题。2.1软件测试的心理学测试执行的差，其中一个重要原因在于大多数的程序员一开始就
9、把“测试”这个术语的定义搞错了。他们可能会认为：“软件测试就是证明软件不存在错误的过程。”“软件测试的目的在于证明软件能够正确完成其预定的功能。”“软件测试就是建立一个软件做了其应该做的信心的过程。”这些定义都是本末倒置的。每当测试一个程序时，总是想为程序增加一些价值。通过测试来增加程序的价值，是指测试提高了程序的可靠性后质量。提高了程序的可靠性，是指找出并最终修改了程序的错误。因此，不要只是为了证明程序能够正确运行而去测试程序；相反，应该一开始就假设程序中隐藏着错误（这种假设对于几乎所有的程序都成立），然而测试程序，发现尽可能多的错误。那么，对于测试，更为适合的定义应该是：“测试是为发现错误
10、而执行程序的过程”。虽然这看起来像是个微妙的文字游戏，但确实有重要的区别。理解软件测试的真正定义，会对成功地进行软件测试有很大的影响。人类行为总是倾向于具有高度目标性，确定一个正确的目标有着重要的心理学影响。如果我们的目的是证明程序中不存在错误，那就会潜在意识中倾向于实现这个目标； 也就是说，我们会倾向于选择可能较少导致程序失效的测试数据。另一方面，如果我们的目标在于证明程序中存在错误，我们设计的测试数就有可能更多地发现问题。与前一种方法相比，后一种方法会更多的增加程序的价值。这种对软件测试的定义，包含着无穷的内涵，其中的很多都蕴含在本书各处。举例来说，它暗示了软件测试是一个破坏性的过程，甚至
11、是一个“施虐”的过程，这就是说明为什么大多数人都觉得它困难，这种定义可能是违反我们愿望的；所幸的是，我们大多数人总是对生活充满建设性而不是破坏性的愿景。大多数人都本能地倾向于创造事物，而不是将事物破坏。这个定义还暗示了对于一个特定的程序，应该如何设计测试用例（测试数据），哪些人硬挨而哪些人又不应该执行测试。为增进对软件测试正确定义的理解，另一条途径是分析一下对“成功的”和“不成功的”这两个问题的使用。当项目经理归纳测试用例的结果时，尤其会用到这两个词。大多数的醒目经理没发现错误的测试用例称为一次“成功测试”，而将发现了某个错误的测试称为“不成功的测试”。这不仅是一次本末倒置。“不成功的”表示事
12、情不遂人意或令人失望。我们认为，如果测试某段程序时发现了错误，而且这些错误是可以修复的，就将这次合理设计并得到有效的测试称作是“成功的”。如果本次测试可以最终确定再无其他可查处的错误，同样也被称为是“成功的”。所谓“不成功的”测试，仅指未能适当地对程序检查，在大多数情况下，未能找出错误的测试被认为是“不成功的”。这是因为认为软件中不包含错误的观点基本上是不切实际的。能发现新错误的测试用例不太可能被认为是“不成功的”；相反能发现错误就证明它是值得设计的。一个“不成功的”测试用例，会使程序输出正确的结果，但不能发现人恶化错误。我们可以类比一下病人看医生的情况，病人因为身体不舒服而去看医生。如果医生
13、对病人进行了一些实验检测，却没有诊断出任何病因，我们就不会认为这些实验检测是“成功的”。之所以是“不成功的”检测，是因为病人支付了昂贵的实验检测费用，而病状却依然如故。病人会因此而质疑医生的诊断能力。但是，如果实验检测诊断出病人是胃溃疡，那么这次检测就是“成功的”，医生可以开始进行适当的治疗。因此，医疗行业会使用“成功的”或“不成功的”来表达适当的意思。我们当然可以类推到软件测试中来，当我们开始测试某个程序是，它就是好似我们的病人。“软件测试就是证明软件不存在错误的过程”，这个定义会带来第二个问题。对于几乎所有的程序而言，甚至是非常小的程序，这个目标实际上也就是无法达到的。另外，心理学研究表明
14、，当人们开始一项工作是，如果已经知道他说不可行的或无法实现时，人的表现就会相当糟糕。举例来说，如果要求人们在15分钟之内完成星期日纽约时报里的纵横填字游戏，那么我们会观察到10分钟之后的进展非常小，因为大多数人都会却步于这个现实，即这个任务似乎是不可能完成的。但是如果要求在四个小时之内完成填字游戏，恶魔很可能有理由期望最初10分钟之内的进展会比前一种情况下的大。将软件测试定义为发现程序错误的过程，即使测试是个可以完成的任务，从而克服了这个心理障碍。诸如“软件测试就是证明软件做了其应该做的的过程”此类的定义所带来的第三个问题是，程序即使完成预定的功能，也仍然可能隐藏错误。也也就是说，当程序没有实
15、现预期功能是，错误是清晰地显示出来的；如果做了其不该做的，这同样是一个错误。考虑一下第1章的三角形测试程序。即使我们证明了程序能够识别出不规则三角形，等腰三角形和等边三角形，但是在完成了不该执行的任务后（例如将1，2，3说成是一个不规则三角形后将0，0，0说成是一个等边三角形），程序仍然是错的。如果我们将软件测试视作发现错误的过程，而不是将其视为证明“软件做了其应该做的”的过程，我们发现后一类错误的可能性会大很多。总结一下，软件测试更适合被视为试图发现程序中错误（假设其存在）的破坏性东东过程。一个成功的测试用例，通过诱发程序发生错误，可以在这个方向上促进软件质量的改进。当然，最终我们还是要通过
16、软件测试来建立某种程度的信心：软件做了其该做的，未做其不该做的。但是通过对错误的不断研究是实现这个目的的最佳途径。有人可能会声称“本人的程序完美无缺”（不存在错误），针对这种的情况建立起信心的最好办法就是尽量反驳他，即努力发现不完美之处，而不是确认程序在某些输入情况下能够正确地工作。2.2 软件测试的经济学给出了软件测试的适当定义之后，下一步就是确定软件测试是否能够发现“所以”的错误。我们将证明答案是否定的，即使是规模很小的程序。一般说来，要发现程序中的所以错误也是不切实际的，常常也是不可能的。这个基本的问题反过来暗示出软件的经济学问题，测试人员对被测试的期望，以及测试用例的设计方式。为了应对测试经济学的挑战，应该开始测试之前建立某些策略。黑盒测试和白
