首页 软件测试的艺术.pdf

软件测试的艺术.pdf

软件测试的艺术.pdf

上传者: 摇曳 2013-04-02 评分1 评论0 下载59 收藏0 阅读量449 暂无简介 简介 举报

简介:本文档为《软件测试的艺术pdf》,可适用于IT书籍领域,主题内容包含TheArtofSoftwareTestingSecondEditionGlenfordJMyersRevisedandUpdatedbyTomBa符等。

TheArtofSoftwareTestingSecondEditionGlenfordJMyersRevisedandUpdatedbyTomBadgettandToddMThomaswithCoreySandlerCopyrightbyWordAssociation,IncAllrightsreservedPublishedbyJohnWileySons,Inc,Hoboken,NewJerseyPublishedsimultaneouslyinCanada整理:丁兆杰,黄墀晖,黄米青,林嘉,马晓靖,王博,吴航,余华兵,俞培源v未经同意严禁以任何形式拷贝ii前言年GlenfordJMyers出版了一本现在仍被证明为经典的著作这就是本书的第版。本书经受住了时间的考验年来一直被列在出版商可供书目的清单中。这个事实本身就是对本书稳定、基础和珍贵品质的佐证。在同一时期本书第版的几位合著者共出版了余本著作大多数都是关于计算机软件的。其中有一些很畅销再版了多次(例如CoreySandler的《FixYourOwnPC》自付印以来已出版到第版TomBadgett关于微软PowerPoint及其他Office组件的著作已经出版到第版以上)。然而这些作者的著作中没有哪一本书能够像本书一样持续数年之后仍畅销不衰。区别究竟在哪里呢?这些新书只涵盖了短期性的主题:操作系统、应用软件、安全性、通信技术及硬件配置。世纪年代和年代以来的计算机硬件与软件技术的飞速发展必然使得这些主题频繁地变功和更新。在此期间出版的有关软件测试的书籍已数以十计、甚至数以百计。这些书也对软件测试的主题进行了简要的探讨。然而本书为计算机界一个最为重要的主题提供了长期、基本的指南:如何确保所开发的所有软件做了其应该做的并且同样重要的是未做其不应该做的?本书第版中保留了同样的基本思想。我们更新了其中的例子以包含更为现代的编程语言。我们还研究了在Myers编著本书第版时尚无人了解的主题:Web编程、电子商务及极限编程与测试。但是我们不会忘记新的版本必须遵从其原著。因此新版本依然向读者展示GlenfordMyers全部的软件测试思想:这个思想体系以及过程将适用于当今乃至未来的软件和硬件平台。我们也希望本书能够顺应时代适用于当今的软件设计人员和开发人员掌握最新的软件测试思想及技术。iii引言在本书年第版出版的时侯有一条著名的经验即在一个典型的编程项目中软件测试或系统测试大约占用%的项目时间和超过%的总成本。年后的今天同样的经验仍然成立。现在出现了新的开发系统、具有内置工具的语言以及习惯于快速开发大量软件的程序员。但是在任何软件开发项目中测试依然扮演着重要角色。在这些事实面前读者可能会以为软件测试发展到现在不断完善已经成为一门精确的学科。然而实际情况并非如此。事实上与软件开发的任何其他方面相比人们对软件测试仍然知之甚少。而且软件测试并非热门课题本书首次出版时是这样.遗憾的是今天仍然如此。现在有很多关于软件测试的书籍和论文这意味着至少与本书首次出版时相比人们对软件测试这个主题有了更多的了解。但是测试依然是软件开发中的“黑色艺术”。这就有了更充足的理由来修订这本关于软件测试艺术的书同时我们还有其他一些动机。在不同的时期我们都听到一些教授和助教说”我们的学生毕业后进入了计算机界却丝毫不了解软件测试的基本知识而且在课堂上向学生介绍如何测试或调试其程序时我们也很少有建议可提供。”因此本书再版的目的与年时一样:填充专业程序员和计算机科学学生的知识空缺。正如书名所蕴涵的本书是对测试主题的实践探讨而不是理论研究连同了对新的语言和过程的探讨。尽管可以根据理论的脉络来讨论软件测试但本书旨在成为实用且“脚踏实地”的手册。因此很多与软件测试有关的主题如程序正确性的数学证明都被有意地排除在外了。本书第l章介绍了一个供自我评价的测试每位读者在继续阅读之前都须进行测试。它揭示出我们必须了解的有关软件测试的最为重要的实用信息即一系列心理和经济学问题这些问题在第章中进行了详细讨论。第章探讨的是不依赖计算机的代码走查或代码检查的重要概念。不同于大多数研究都将注意力集中在概念的过程和管理方面第章则是从技术上“如何发现错误”的集度来进行探讨。聪明的读者都会意识到在软件测试人员的技巧中最为重要的部分是掌握如何编写有未经同意严禁以任何形式拷贝iv效测试用例的知识.这正是第章的主题。本书第章和第章分别探讨了如何测试单个模块或子程序及测试更夫的对象而第章则介绍了一些程序调试的实用建议第章讨论了极限编程和极限测试的概念第章介绍了如何将本书其他章节中详细讨论的软件测试的知识运用到web编程包括电子商务系统中去。本书面向三类主要的读者。尽管我们希望本书中的内容对于专业程序员而言不完全是新的知识但它应增强专业人员对测试技术的了解。如果这些材料能使软件人员在某个程序中多发现一个错误那么本书创造的价值将远远超过书价本身。第二类读者是项目经理因为本书中包含了测试过程管理的最新的、实用的知识。第三类读者是计算机科学的学生我们的目的在于向学生们展示程序测试的问题并提供一系列有效的技术。我们建议将本书作为程序设计课程的补充教材让学生在学习阶段的早期就接触到软件测试的内容。GlenfordJMyersTomBadgettToddMThomasCoreySandler目录第章一个自我评价测试第章软件测试的心理学和经济学软件测试的心理学软件测试的经济学软件测试的原则小结第章代码检查、走查与评审检查与走查(InspectionsAndWalkthroughs)代码检查(CodeInspections)用于代码检查的错误列表代码走查(Walkthroughs)桌面检查(DeskChecking)同行评分(PeerRatings)小结第章测试用例的设计白盒测试(WhiteBoxTesting)错误猜测(ErrorGuessing)测试策略第章模块(单元)测试测试用例设计增量测试自顶向下测试与自底向上测试执行测试第章更高级别的测试功能测试(FunctionTesting)系统测试(SystemTesting)验收测试(AcceptanceTesting)安装测试(InstallationTesting)未经同意严禁以任何形式拷贝测试的计划与控制测试结束准则独立的测试机构第章调试(DEBUGGING)暴力法调试(DebuggingbyBruteForce)归纳法调试(DebuggingbyInduction)演绎法调试(DebuggingbyDeduction)回溯法调试(DebuggingbyBacktracking)测试法调试(DebuggingbyTesting)调试的原则第章极限测试极限编程基础极限测试:概念极限测试的应用小结词汇表软件测试的艺术未经同意严禁以任何形式拷贝第章一个自我评价测试自本书年前首次出版以来软件测试变得比以前容易得多也困难得多。软件测试何以变得更困难?原因在于大量编程语言、操作系统以及硬件平台的出现。在世纪年代只有相当少的人使用计算机而今天在商业界和教育界如果不使用计算机几乎没有人能完成日常工作。况且计算机本身的功能也比以前增强了数百倍。因此我们现在编写的软件会潜在地影响到数以百万计的人使他们更高效地完成工作反之也会给他们带来数不清的麻烦导致工作或事业的损失。这并不是说今天的软件比本书第一版发行时更重要但可以肯定地说今天的计算机以及驱动它的软件无疑已影响到了更多的人、更多的行业。就某些方面而言软件测试变得更容易了因为大量的软件和操作系统比以往更加复杂内部提供了很多已充分测试过的例程供应用程序集成无须程序员从头进行设计。例如图形用户界面(GUI)可以从开发语言的类库中建立起来同时由于它们是经过充分调试和测试的可编程对象将其作为用户应用程序的组成部分进行测试的要求就减少了许多。所谓软件测试就是一个过程或一系列过程.用来确认计算机代码完成了其应该完成的功能不执行其不该有的操作。软件应当是可预测且稳定的不会给用户带来意外惊奇。在本书中我们将讨论多种方法来达到这个目标。好了在开始阅读本书之前我们想让读者做一个小测验。我们要求设计一组测试用例(特定的数据集合)适当地测试一个相当简单的程序。为此要为该程序建立一组测试数据程序须对数据进行正确处理以证明自身的成功。下面是对程序的描述:这个程序从一个输入对话框中读取三个整数值。这三个整数值代表了三角形三边的长度。程序显示提示信息指出该三角形究竟是不规则三角第章一个自我评价测试未经同意严禁以任何形式拷贝形、等腰三角形还是等边三角形。注意所谓不规则三角形是指三角形中任意两条边不相等等腰三角形是指有两条边相等而等边三角形则是指三条边相等。另外等腰三角形等边的对角也相等(即任意三角形等边的对角也相等)等边三角形的所有内角都相等。用你的测试用例集回答下列问题借以对其进行评价。对每个回答“是”的答案可以得l分:.是否有这样的测试用例代表了二个有效的不规则三角形?(注意如和这样的测试用例并不能确保“是”的答案因为具备这样边长的三角形不存在。).是否有这样的测试用例代表一个有效的等边三角形?.是否有这样的测试用例代表一个有效的等腰三角形?(注意如的测试用例无效因为这不是一个有效的三角形。).是否能少有三个这样的测试用例代表有效的等腰三角形从而可以测试到两等边的所有三种可能情况?(如).是否有这样的测试用例某边的长度等于?.是否有这样的测试用例某边的长度为负数?.是否有这样的测试用例三个整数皆大于其中两个整数之和等于第三个?(也就是说如果程序判断l表示一个不规则二角形它可能就包含一个缺陷。).是否至少有三个第类的测试用例列举了一边等于另外两边之和的全部可能情况(如)?.是否有这样的测试用例三个整数皆大于其中两个整数之和小于第三个整数?(如).是否至少有三个第类的测试用例列举了一边大于另外两边之和的全部可能情况?(如).是否有这样的测试用例三边长度皆为()?.是否至少有一个这样的测试用例输入的边长为非整数值(如).是否至少有一个这样的测试用例输入的边长个数不对(如仅输入了两软件测试的艺术未经同意严禁以任何形式拷贝个而不是三个整数).对于每一个测试用例除了定义输入值之外是否定义了程序针对该输入值的预期输出值?当然测试用例集即使满足了上述条件也不能确保能查找出所有可能的错误。但是由于问题至问题代表了该程序不同版本中已经实际出现的错误对该程序进行的充分测试至少应该能够暴露这些错误。开始关注自己的得分之前请考虑以下情况:以我们的经验来看高水平的专业程序员平均得分仅(满分)。如果读者的得分更高那么祝贺你。如果没有那么高我们将尽力帮助你。这个测验说明即使测试这样一个小的程序也不是件容易的事。如果确实是这样那么想象一下测试一个十万行代码的空中交通管制系统、一个编译器甚至一个普通的工资管理程序的难度。随着面向对象编程语言(如Java、C)的出现测试也变得更加困难。举例来说为测试这些语言开发出来的应用程序测试用例必须要找出与对象实例或内存管理有关的错误。从上面这个例子来看完全地测试一个复杂的、实际运行的程序似乎是不太可能的。情况并非如此!尽管充分测试的难度令人望而生畏但这是软件开发中一项非常必需的任务也是可以实现的一部分工作通过本书我们可以认识到这一点。第章软件测试的心理学和经济学未经同意严禁以任何形式拷贝第章软件测试的心理学和经济学软件测试是一项技术性工作但同时也涉及经济学和人类心理学的一些重要因素。在理想情况下我们会测试程序的所有可能执行情况。然而在大多数情况下这几乎是不可能的即使一个看起来非常简单的程序其可能的输入与输出组合可达到数百种甚至数千种对所有的可能情况都设计测试用例是不切合实际的。对一个复杂的应用程序进行完全的测试将耗费大最的时间和人力资源以至于在经济上是不可行的。另外要成功地测试一个软件应用程序测试人员也需要有正确的态度(也许用“愿景(vision)”这个词会更好一些)。在某些情况下测试人员的态度可能比实际的测试过程本身还要重要。因此在深入探讨软件测试更加技术化的本质之前我们先探讨一下软件测试的心理学和经济学问题。软件测试的心理学测试执行得差其中一个主要原因在于大多数的程序员一开始就把“测试”这个术语的定义搞错了他们可能会认为:•“软件测试就是证明软件不存在错误的过程。”•“软件测试的目的在于证明软件能够正确完成其预定的功能。”•“软件测试就是建立一个‘软件做了其应该做的’信心的过程。”这些定义都是本末倒置的。每当测试一个程序时总是想为程序增加一些价值。通过测试来增加程序的价值是指测试提高了程序的可靠性或质量。提高了程序的可靠性是指找出并最终修改了程序的错误。因此不要只是为了证明程序能够正确运行而去测试程序相反应该一开始就假设程序中隐藏着错误(这种假设对于几乎所有的程序都成立)然后测试程序发现尽可能多的错误。那么对于测试更为合适的定义应该是:Administrator高亮Administrator高亮Administrator高亮Administrator高亮Administrator高亮Administrator高亮软件测试的艺术未经同意严禁以任何形式拷贝“测试是为发现错误而执行程序的过程”。虽然这看起来像是个微妙的文字游戏但确实有重要的区别。理解软件测试的真正定义会对成功地进行软件测试有很大的影响。人类行为总是倾向于具有高度目标性确立一个正确的目标有着重要的心理学影响。如果我们的目的是证明程序中不存在错误那就会在潜意识中倾向于实现这个目标也就是说我们会倾向于选择可能较少导致程序失效的测试数据。另一方面如果我们的目标在于证明程序中存在错误我们设计的测试数据就有可能更多地发现间题。与前一种方法相比后一种方法会更多地增加程序的价值。这种对软件测试的定义包含着无穷的内蕴其中的很多都蕴涵在本书各处。举例来说它暗示了软件测试是一个破坏性的过程甚至是一个“施虐”的过程达就说明为什么人多数人都觉得它困难。这种定义可能是违反我们愿望的所幸的是我们大多数人总是对生活充满建设性而不是破坏性的愿景。大多数人都本能地倾向于创造事物而不是将事物破坏。这个定义还暗示了对于一个特定的程序:应该如何设计测试用例(测试数据)、哪些人应该而哪些人又不应该执行测试。为增进对软件测试正确定义的理解另一条途径是分析一下对“成功的”和“不成功的”这两个词的使用当项目经理在归纳测试用例的结果时尤其会用到这两个词。大多数的项日经理将没发现错误的测试用例称为一次“成功的测试”而将发现了某个新错误的测试称为“不成功的测试”。这又是一次本末倒置。“不成功的”表示事情不遂人意或令人失望。我们认为如果在测试某段程序时发现了错误而且这些错误是可以修复的就将这次合理设计并得到有效执行的测试称作是“成功的”。如果本次测试可以最终确定再无其他可查出的错误同样也被称作是“成功的”。所谓“不成功的”测试仅指未能适当地对程序进行检查在大多数情况下未能找出错误的测试被认为是“不成功的”这是因为认为软件中不包含错误的观点基本上是不切实际的。能发现新错误的测试用例不太可能被认为是“不成功的”相反能发现错误就证明它是值得设计的。一个“不成功的”测试用例.会使程序输出正确的结果但不能发现任何错误。Administrator高亮第章软件测试的心理学和经济学未经同意严禁以任何形式拷贝我们可以类比一下病人看医生的情况病人因为身体不舒服而去看医生。如果医生对病人进行了某些实验检测却没有诊断出任何病因我们就不会认为这此实验检测是“成功的”。之所以是“不成功的”检侧是因为病人支付了昂贵的实验检测费用而病状却依然如故。病人会因此而质疑医生的诊断能力。但是如果实验检测诊断出病人是胃溃疡那么这次检测就是“成功的”医生可以开始进行适当的治疗。因此.医疗行业会使用“成功的”或“不成功的”来表达适当的意思。我们当然可以类推到软件测试中来当我们开始测试某个程序时它就好似我们的病人。“软件测试就是证明软件不存在错误的过程”这个定义会带来第二个问题。对于几乎所有的程序而言甚至是非常小的程序这个目标实际上也是无法达到的。另外心理学研究表明当人们开始一项工作时如果已经知道它是不可行的或无法实现时人的表现就会相当糟糕。举例来说如果要求人们在分钟之内完成星期日《纽约时报》里的纵横填字游戏那么我们会观察到l分钟之后的进展非常小因为大多数人都会却步于这个现实即这个任务似乎是不可能完成的。但是如果要求在四个小时之内完成填字游戏我们很可能有理由期望在最初分钟之内的进展会比前一种情况下的大。将软件测试定义为发现程序错误的过程使得测试是个可以完成的任务从而克服了这个心理障碍。诸如“软件测试就是证明‘软件做了其应该做的’的过程”此类的定义所带来的第三个问题是程序即使能够完成预定的功能也仍然可能隐藏错误。也就是说当程序没有实现预期功能时错误是清晰地显现出来的如果程序做了其不应该做的这同样是一个错误考虑一下第l章中的三角形测试程序。即使我们证明了程序能够正确识别出不规则三角形、等腰三角形和等边三角形但是在完成了不应执行的任务后(例如将说成是一个不规则三角形或将说成是一个等边三角形)程序仍然是错的。如果我们将软件测试视作发现错误的过程而不是将其视为证明“软件做了其应该做的”的过程我们发现后一类错误的可能性会大很多。总结一下软件测试更适合被视为试图发现程序中错误(假设其存在)的破坏性的过程。一个成功的测试用例通过诱发程序发生错误可以在这个方向上促进Administrator高亮软件测试的艺术未经同意严禁以任何形式拷贝软件质量的改进。当然最终我们还是要通过软件测试来建立某种程度的信心:软件做了其应该做的未做其不应该做的。但是通过对错误的不断研究是实现这个目的的最佳途径。有人可能会声称“本人的程序完美无缺”(不存在错误)针对这种情况建立起信心的最好办法就是尽量反驳他即努力发现不完美之处而不只是确认程序在某些输入情况下能够正确地工作。软件测试的经济学给出了软件测试的适当定义之后下一步就是确定软件测试是否能够发现“所有”的错误。我们将证明答案是否定的即使是规模很小的程序。一般说来要发现程序中的所有错误也是不切实际的常常也是不可能的。这个基本的问题反过来暗示出软件测试的经济学问题、测试人员对被测软件的期望以及测试用例的设计方式。为了应对测试经济学的挑战应该在开始测试之前建立某些策略。黑盒测试和白盒测试是两种最普遍的策略我们将在下面两节中讨论。黑盒测试黑盒测试是一种重要的测试策略又称为数据驱动的测试或输入输出驱动的测试。使用这种测试方法时将程序视为一个黑盒子。测试目标与程序的内部机制和结构完全无关而是将重点集中放在发现程序不按其规范正确运行的环境条件。在这种方法中测试数据完全来源于软件规范(换句话说不需要去了解程序的内部结构)。如果想用这种方法来发现程序的所有错误判定的标准就是“穷举输入测试”将所有可能的输入条件都作为测试用例。为什么这样做?比如说在三角形测试的程序中试过了三个等边三角形的测试用例。这不能确保正确地判断出所有的等边三角形。程序中可能包含对边长为的特殊检查并指出此三角形为不规则三角形。由于程序是个黑盒子因此能够确定此条语句存在的惟一方法就是试验所有的输入情况。要穷举测试这个三角形程序可能需要为所有有效的三角形创建测试用例只Administrator高亮Administrator高亮Administrator高亮Administrator高亮第章软件测试的心理学和经济学未经同意严禁以任何形式拷贝要三角形边长在开发语言允许的最大整数值范围内。这些测试用例本身就是天文数字但这还决不是所谓穷尽的当程序指出是一个不规则三角形或A是一个等腰三角形时问题就暴露出来了为了确保能够发现所有这样的错误不仅得用所有有效的输入而且还得用所有可能的输入进行测试。因此为了穷举测试三角形程序实际上需要创建无限的测试用例:这当然是不可能的。如果测试这个三角形程序都这么难的话那么要穷举测试一个稍大些的程序的难度就更大了设想一下如果要对一个C编译器进行黑盒穷举测试不仅要创建代表所有有效C程序的测试用例(实际上这又是个无穷数)还需要创建代表所有无效C程序的测试用例(无穷数)以确保编译器能够检测出它们是无效的。也就是说编译器必须进行测试确保其不会执行不应执行的操作如顺利地编译成功一个语法上不正确的程序。如果程序使用到数据存储如操作系统或数据库应用程序这个问题会变得尤为严重。举例来说在航班预定系统这样的数据库应用程序中诸如数据库查询、航班预约这样的事务处理需要随上次事务的执行情况而定因此不仅要测试所有有效的和无效的事务处理还要测试所有可能的事务处理顺序。上述讨论说明穷举输入测试是无法实现的这有两方面的含义一是我们无法测试一个程序以确保它是无错的二是软件测试中需要考虑的一个基本问题是软件测试的经济学。也就是说由于穷举测试是不可能的测试投人的目标在于通过有限的测试用例最大限度地提高发现的问题的数量以取得最好的测试效果。除了其他因素之外要实现这个目标还需要能够窥见软件的内部对程序作些合理但非无懈可击的假设(例如如果三角形程序将视为等边三角形那就有理由认为程序对也作同样判断)。这种思路将形成本书第章中测试用例设计策略的部分方法。白盒测试另一种测试策略称为白盒测试或称逻辑驱动的测试允许我们检查程序的内部结构。这种测试策略对程序的逻辑结构迸行检查从中获取测试数据(遗憾的是常常忽略了程序的规范)。Administrator高亮软件测试的艺术未经同意严禁以任何形式拷贝在这里我们的目标是针对达种测试策略建立起与黑盒测试中穷举输入测试相似的测试方法。也许有一个解决的办法即将程序中的每条语句至少执行一次。但是我们不难证明这还是远远不够的。这种方法通常称为穷举路径测试在本书第章中将进一步进行深入探讨在这里就不多加叙述。所谓穷举路径测试即如果使用测试用例执行了程序中所有可能的控制流路径那么程序有可能得到了完全测试。然而这个论断存在两个问题。首先程序中不同逻辑路径的数最可能达到天文数字。图所示的小程序显示了这一点。该图是一个控制流图每一个结点或圆圈都代表一个按顺序执行的语句段通常以一个分支语句结束。每一条边或弧线表示语句段之间的控制(分支)的转换。图描述的是一个有着~行语句的程序包含一个迭代次的DO循环。在DO循环体中包含一系列嵌套的IF语句。要确定不同逻辑路径的数量也相当于要确定从点a~点b之间所有不同路径的数量(假定程序中所有的判断语句都是相互独立的)。这个数量大约是即万亿是从…十计算而来是循环体内的路径数量。由于大多数的人难以对这个数字有一个直观的概念不妨设想一下:如果在每五分钟内可以编写、执行和确认一个测试用例那么需要大约亿年才能测试完所有的路径。假如可以快上倍每秒就完成一次测试也得用漫长的万年才能完成这项工作。第章软件测试的心理学和经济学未经同意严禁以任何形式拷贝图一个小型程序的控制流图当然在实际程序中判断并非都是彼此独立的这意味着可能实际执行的路径数量要稍微少一些。但是从另一方面来讲实际应用的程序要比图所描述的简单程序复杂得多。因此穷举路径测试就如同穷举输入测试非但不可能也是不切实际的。“穷举路径测试即完全的测试”论断存在的第二个问题是虽然我们可以测试到程序中的所有路径但是程序可能仍然存在着错误。这有三个原因。第一即使是穷举路径测试也决不能保证程序符合其设计规范。举例来说如果要编写一个升序排序程序但却错误地编成了一个降序排序程序那么穷举路径测试就没多大价值了程序仍然存在着一个缺陷:它是个错误的程序因为不符合设计的规范。第二程序可能会因为缺少某些路径而存在问题。穷举路径测试当然不能发现缺少了哪些必需路径。软件测试的艺术未经同意严禁以任何形式拷贝第三穷举路径测试可能不会暴露数据敏感错误。这样的例子有很多举一个简单的例子就能说明问题。假设在某个程序中要比较两个数值是否收敛也就是检查两个数值之间的差异是否小于某个既定的值。比如我们可能会这样编一条Java语言的IF语句:if(a–b<c)SystemOutprintln(“ab<c”)当然这条语句包含一个错误因为它可能将c与ab的绝对值进行比较。然而要找出这样的错误取决于a和b所取的值而仅仅执行程序中的每条路径并不一定能找出错误来。总之尽管穷举输入测试要强于穷举路径测试但两者都不是有效的方法因为这两种方法都不可行。那么也许存在别的方法将黑盒测试和白盒测试的要素结合起来形成一个合理但并不十分完美的测试策略。本书的第章将深入讨论这个话题。软件测试的原则让我们继续本章的话题基础即软件测试中大多数重要的问题都是心理学问题。我们可以归纳出一系列重要的测试指导原则这些原则看上去大多都是显而易见的但常常总是被我们忽视掉。表l总结了这些重要原则每条原则都将在下面的章节中详细介绍。表-软件测试的重要原则编号原则测试用例中一个必需部分是对预期输出或结果进行定义程序员应避免测试自己编写的程序编写软件的组织不应当测试自已编写的软件应当彻底检查每个测试的执行结果测试用例的编写不仅应当根据有效和预料到的输入情况而且也应当根据无效和未预料到的输入情况检查程序是否“未做其应该做的”仅是测试的一半测试的另一半是检查程是否“做了其不应该做的”应避免测试用例用后即弃除非软件本身就是个一次性的软件计划测试工作时不应默许假定不会发现错误程序某部分存在更多错误的可能性与该部分已发现错误的数量成正比软件测试是一项极富创造性极具智力的挑战性的工作Administrator高亮Administrator高亮第章软件测试的心理学和经济学未经同意严禁以任何形式拷贝原则l:测试用例中一个必需部分是对预期输出或结果的定义。这条显而易见的原则在软件测试中是最常犯的错误之一。同样这个问题也是基于人们的心理的。如果某个测试用例的预期结果事先没有得到定义由于“所见即所想”现象的存在。某个似是而非、实际上是错误的结果可能会被解释成正确的结论。换句话说尽管“软件测试是破坏性”的定义是合理的但人们在潜意识中仍然渴望看到正确的结果。克服这种倾向的一种方法、就是通过事先精确定义程序的预期输出鼓励人们对所有的输出进行仔细检查。因此一个测试用例必须包括两个部分:.对程序的输入数据的描述。.对程序在上述输入数据下的正确输出结果的精确描述。所谓“问题”可以归纳为一个或一组我们不能给出可信服的解释、看上去不太正常或不符合我们期望或预想的事实。应当明确的是在确定事物存在“问题”之前人们必须已经形成特定的认识。没有期望也就没有所谓的意外。原则:程序员应当避免测试自己编写的程序.任何作者都知道或应该知道亲自编辑或校对自己的作品确实是个不好的做法。作者清楚某段文字要说明的是什么实际表达出来的意思却南辕北辙而自己可能却意识不到。况且实际上也不会想在自己的作品中找出什么错误来。对程序员而言也存在相同的问题。如果我们对软件项目关注的重点发生变化就会产生另外一个问题。当程序员“建设性”地设计和编写完程序之后很难让他突然改变视角以一种“破坏性”的眼光来审查程序。正如许多房屋业主都知道的那样撕下屋里的墙纸(这是个破坏性的过程)并不容易如果这些墙纸又恰恰是业主第一个亲手贴的尤其令其沮丧不已。同样大多数程序员都不能有效地测试自己编写的程序因为他们无法改变思维方式来尽力暴露自己程序中的错误。另外程序员可能会下意识地避免找出错误来担心受到同事、上司、客户或正在开发的程序或系统的主管的惩罚。仅次于上面的心理学问题还有一个重要的问题:由干程序员错误地理解了疑难定义或规范导致程序中存在错误。如果情况是这样程序员可能会带着同样的Administrator高亮Administrator高亮软件测试的艺术未经同意严禁以任何形式拷贝误解来测试自己的程序。这并不意味着程序员测试自己的程序是不可能的。当然我们的言下之意是让其他人来测试程序会更加有效也会更容易测试成功。请注意我们的论据并不适合于“调试”(纠正已知的错误)。“调试”由程序的编写人员来完成会有效得多。原则:编写软件的组织不应当测试自己编写的软件.这里的论据与前面的论据相似。从很多方面来讲一个软件项目或编程组织是一个有机的机构具有与个体程序员相似的心理问题。而且在大多数情况下主要是根据其在给定时间、特定成本范围内开发软件的能力来衡量编程组织或项目经理。其中的一个原因是度量时间和成本目标比较容易而定量地衡量软件的可靠性则极其困难.即便是合理规划和实施的测试过程也可能被认为降低了完成进度和成本目标的可能性因此、编程组织难以客观地测试自己的软件。同样我们并不是说编程组织发现程序中的问题是不可能的事实上很多组织已经在某种程度上成功地做到了这一点。当然我们的言下之意是更经济的方法是由客观、独立的第三方来进行测试。原则:应当彻底检查每个测试的执行结果。这个原则可能是最显而易见的原则但也同样常常被忽视。我们见过大量的例子即便错误的症状在输出清单中可以清楚地看到但还是没有找出那些错误来。换言之在后续测试中发现的错误往往是前面的测试遗漏掉的。原则:测试用例的编写不仅应当根据有效和预期的输入情况而且也应当根据无效和未预料到的输入情况。在测试软件时有一个自然的倾向即将重点集中在有效和预期的输入情况上而忽略了无效和未预料到的情况。比如在本书第l章三角形程序的测试中总是出现这个倾向。例如很少有人会向程序输入以证明程序不会错误地将其解释为一个不规则三角形而不是一个无效三角形。此外在软件产品中突然暴露出来的许多Administrator高亮Administrator高亮Administrator高亮第章软件测试的心理学和经济学未经同意严禁以任何形式拷贝问题是当程序以某些新的或未预料到的方式运行时发现的。因此针对未预料到的和无效输入情况的测试用例似乎比针对有效输入情况的那些用例更能发现问题。原则:检查程序是否“未做其应该做的”仅是测试的一半测试的另一半是检查程序是否“做了其不应该做的”。这条原则是上条原则的必然结果。必须检查程序是否有我们不希望的负作用。比如某个工资管理程序即便可以生成正确的工资单但是如果也为非雇员生成工资单或者它覆盖掉了人员文件的第一条记录这样的程序仍然是不正确的程序。原则:应避免测试用例用后即弃除非软件本身就是一个一次性的软件。这个问题在采用交互式系统来测试软件时最常见。人们通常会坐在终端前匆忙地编写测试用例然后将这些用例交由程序执行。这样做的问题在于饱含我们宝贵投人的测试用例在测试结束后就消失了一旦软件需要重新测试(例如当改正了某个错误或作了某种改进后)又必须重新设计这些测试用例。情况往往是这样的由于重新设计测试用例需要投人大量的工作人们总是避免这样做。因此对该程序的重新测试极少会同上次一样严格。这就意味着如果对程序的更改导致了程序某个先前可以执行的部分发生了故障这个故障往往是不会被发现的保留测试用例当程序其他部件发生更动后重新执行这就是我们所谓的“回归测试”。原则:计划测试工作时不应默许假定不会发现错误。项目经理经常容易犯这个错误这也是使用了不正确的测试定义的一个迹象也就是说假定“测试是一个证明程序正确运行的过程”。我们再一次重申所谓测试就是为发现错误而执行程序的过程。原则:程序某部分存在更多错误的可能性与该部分已发现错误的数目成正比。这种现象如图所示。乍看上去这幅图似乎没有什么意义但很多程序都存在这种现象。例如假如某个程序由两个模块、类或子程序A和B组成模块A中已经发现了五个错误而模块B中仅仅找到了一处错误。如果模块A所经过的测试并不是故意设计得更为严格那么该原则告诉我们模块A与模块B相比存在更多错误的可能性要大。Administrator高亮Administrator高亮Administrator高亮Administrator高亮软件测试的艺术未经同意严禁以任何形式拷贝该原则的另一个说法是错误总是倾向于聚集存在而在一个具体的程序中某些部分要比其他部分更容易存在错误尽管没有人能够对这种现象给出很好的解释。这种现象之所以有用.是因为它给予了我们对软件测试过程的洞察或反馈。如果一个程序的某个部分远比其他部分更容易产生错误.那么这种现象告诉我们为了使测试获得更大的成效最好对这些容易存在错误的部分进行额外的测试。图残存错误与已知错误间令人惊奇的联系原则:软件测试是一项极富创造性、极具智力挑战性的工作。测试一个大型软件所需要的创造性很可能超过了开发该软件所需要的创造性.我们已经看到要充分地测试一个软件以确保所有错误都不存在是不可能的。本书后续章节讨论的技术使我们能够为某个软件设计出合理的测试用例集然而这些技术仍然需要大量的创造性。小结在阅读本书接下来的内容时请牢记以下三个重要的测试原则:•软件测试是为发现错误而执行程序的过程。•一个好的测试用例具有较高的发现某个尚未发现的错误的可能性。•一个成功的测试用例能够发现某个尚未发现的错误。

职业精品

分销渠道选择.ppt

辞职申请书(优质范文).doc

公司年检申请书doc.doc

厂家和经销商代理合同.doc

用户评论

0/200
    暂无评论
上传我的资料

精彩专题

相关资料换一换

资料评价:

/ 149
所需积分:0 立即下载

意见
反馈

返回
顶部