本书从软件测试的基础知识讲起，继而对软件测试技巧及软件测试管理等问题进行了深入的探讨。本书先介绍了测试目标、测试类型，说明如何报告和分析故障；而后介绍了问题跟踪系统的使用、测试用例的设计、设备测试，测试本地化、测试工具，以及测试计划和测试文档；最后介绍了测试项目及测试人员的管理。此外，本书最后的附录列出了400多个常见的软件错误，并对每个错误进行了简要说明，可供测试人员参考。
本书不仅适合软件测试人员和测试经理，也适合项目经理和程序员阅读，尤其适合作为软件测试岗位培训的教材。
无
本书介绍了如何在通常的业务条件下测试消费软件和商业软件，实在而且实用。我们曾经为硅谷中快速成长的著名软件公司测试软件，管理其测试人员。我们撰写本书的目的在于为员工提供培训和工作指南。
已经有很多很好的书在讲授有高可靠性要求的软件产品的测试方法。人命关天的和金融领域的应用程序，事先都得到了详细的定义和设计，质量保证和测试活动的经费充足，软件测试人员能够完全接触系统源代码，并有充分的时间阅读它们。在这样的前提下，这些书籍介绍了如何进行完整的软件测试工作。
计算行业的大多数人，包括个人计算机业的绝大部分人，都在努力开发有用且可靠的软件产品，但这些软件并不要求很高的可靠性。就像买车你可以选性能良好的经济型轿车或中档轿车一样，大多数的程序不必成为劳斯莱斯（而且大多数人是买不起劳斯莱斯的）。消费软件、普通商务软件、学术研究软件和个人软件的开发人员的测试预算相当有限，时间紧迫，人手短缺，然而很多程序却具有令人满意的质量。他们是如何做到的呢？本书介绍了其中的测试工作部分。
书不能解决全部问题有些书认为，如果一个软件项目没有得到“合理”的控制，书面规格说明始终没有完成且不是最新的，代码没有依据所谓流行的方法进行适当组织的话，那么必须要努力做到。这些书讲到的测试是建立在每个人都依据“规定”行事的基础之上的。
本书介绍的测试，假定的前提是你的同伴现在没有、将来也不会并且也没必要遵循这些规定。
消费软件项目通常的特点是，预算非常有限、人手非常少、交付时间非常紧迫而且不可能推迟、开发人员之间拥有共同的认识和承诺。
大型软件产品的质量掌握在那些负责设计、编程、测试、撰写文档的个人手上，每个人都很重要。无论是标准、规格说明、指导/协调委员会和变更控制都不能保证质量，软件公司也没有指望它们起到这样的作用。能够确保软件质量的，是个人追求卓越的承诺、熟练使用工具的技巧和协同工作的能力，而不是这些规定。
开发小组对所要创建的东西有了认识，对尽可能实现梦想达成了承诺，并且意识到不得不通过试验和错误来充实这些细节。当产品某一部分的所有细节工作都完成时，他们会形成一个只有一两个人能完全理解的工作说明。这个说明就是所谓的“规格说明”。“规格说明”并不是刻在石头上一成不变的，随后会被评审和修正，以便与系统其他部分保持一致。大多数的修正是根据软件测试人员的建议进行的。
在现实世界中，产品变更一般发生在开发阶段的后期。当你正开发一个公开发售的软件产品时，你的客户或潜在客户不一定会同意你的设计。如果竞争对手开发出更具吸引力的产品，你要马上作出反应。
由于没有时间实现，预想的功能往往被取消掉。代码重写也被搁置一边，即使是需要完成这些代码重写工作把勉勉强强提交的第一版本改得稍微专业一些。认真负责的程序员也许会自觉地，甚至是“偷偷地”完成这项工作。在项目的后期，他可能在没有通知其他任何人的情况下对软件包做了重要修改。这些努力是在每周40小时工作时间之外完成的，可能会极大地改进软件质量，但也可能使软件质量变得极其糟糕。不管结果如何，软件质量的改进是通过个人的积极性来实现的。
后期的变更是不可避免的。我们的目标是尽可能平稳地来处理这些必要的变更。我们不打算建立什么规章制度来抑制变更的产生。作为测试人员，你如果处理不好变更，就会有麻烦。解决之道不在于单纯抱怨或是竭力阻止它们。
本书的读者对象
本书的读者对象是从事软件测试且常常测试他人代码的人员。我们认为所选主题和讨论水平反映了读者感兴趣或对读者有益处的内容。因此我们摒弃某些学术性内容（如程序正确性证明），讨论通常在测试教科书中并未强调的内容。例如，我们经常谈论到人际关系和企业文化问题。连最初级的软件测试人员也必须评判他人的工作—这就是测试工作的根本。在将他们的判断与别人进行交流的过程中，测试人员容易受到指责（有时也是“罪有应得”）。他们工作的重要程度往往与其地位不相称，从而导致他们容易成为人际矛盾的靶子或替罪羊。我们没有办法解决其地位问题，但我们确实提出了一些建议来提高测试效率和避免某些陷阱。
我们也讨论项目管理问题。软件测试的估算、计划和时间安排很棘手，因为软件测试没有真正的终点，测试总是没完没了，如果不做就会有更多的风险。每个测试人员都必须明白这种平衡关系。他们需要安排时间来充分考虑这些因素。例如，某个测试人员可能为了更好地完成其他任务而推迟了重要的测试，但是，后来发现由于时间已用完，再也无法进行这些测试了。本打算将工作做得更好，却弄巧成拙。这种情况很常见，而且非常令人沮丧。因此，优先级和效率是本书主要关注的问题。
测试人员还要处理设计错误。按照糟糕的规格说明实现的程序，其质量必定是糟糕的。大多数有关软件可靠性和测试的书籍没有涉及用户界面，而将其作为人为因素分析员的工作范围。我们不同意这种观点。（我们之中就有一位人为因素分析专家，他也不赞同。）系统的可靠性取决于其各部分是如何协同工作的，包括使用它的人员在内。
作为测试人员，你的任务是发现并指出产品中存在的问题，为改进产品质量服务。无论问题的源头出在何处，关于人－机系统可靠性差的报告都是适当和重要的。你是少数几个能在产品发布前详细检验整个产品的人之一。还有哪些地方能产生这种反馈呢？
我们对用户界面问题的讨论并不能让你成为专家，你仍然会遗漏很多重要问题。你的一些设计建议可能是笨拙的，但你依然应该递交这些报告，它们很重要。其中一些报告将导致产品改进，除此之外，别无他法。
人命关天的软件
在某些条件下，编程人员或他们的经理如果违背标准化的方法是绝对不能接受的。核反应堆的控制程序必须文档齐备，并得到彻底地详细说明，仅在精确计算之后方可进行变更。如果发生了失误，测试文档将是非常重要的法律证据。像这样的项目，负担得起大批质量保证人员和巨大的测试预算。对于这种项目的质量保证人员，测试方面的其他书籍比本书更适合他们。
然而，即使在这些项目中，最后常会有一个验收测试过程。这些测试人员不属于开发队伍的核心，他们得到的预算非常少，他们的时间限期简直是不可能的。整个质量保证机构看不起他们的工作。他们接触产品的时间有限，无法采取“正确”的方式来进行“真正”的测试。如果你是在这种环境下工作，我们认为本书比其他经典教科书更适合你。
这是一本教科书吗
我们曾经面试并雇用了很多测试人员。但我们还没有见到在大学里学到了足够测试知识的计算机专业的毕业生。
1991年，美国计算机协会（Association for Computing Machinery，ACM）与IEEE计算机学会出版了《计算课程1991》（Computing Curricula 1991），在之后的十年中深刻影响了大学计算机学位课程的设计。但是，它给软件测试技术的必修时间少得可怜—四年学习期间只有几个小时而已。这一课程指导建议设立一个选修课程“高级软件工程”，其中包括关于软件测试的主题，但它没有提及是否开设一门以测试为主要内容的课程。
往后十年，我们也不能期望计算机专业的毕业生在大学中能学到足够的软件测试知识。
我们不知道为什么学校不去填补这个空白。我们认为，学过几门测试课程、同时又辅修了一些入门的编程和项目管理课程的理工科毕业生，应该能够很容易找到工作。测试人员的起薪也比较高。我们认为，大学教育应为这样的工作培养人才。
本书中所做的很多修订是为在校学生所做的，他们可能在头脑中从未形成对软件测试实验室的认识。对于那些尚未设置通用商业软件测试课程的院校，我们希望本书能对他们设置课程提供帮助。
如果你拥有理工科学位，我提醒你可以考虑从事测试工作。具备理工科教育背景并学过一些测试课程便能入门，但仅满足于此还不够。我们强烈建议你在适应了基本工作之后，最好在业余时间立即去修相关课程。
对本书结构的一些说明
这是一本培训教材。有的读者可能是初次接触测试这个领域，而有的读者可能已是有经验的测试人员，他们已经通过岗位培训掌握了工作知识，这是他们的第一本测试教材。本书的结构正是为服务于这些读者而设的。
本书分层次来介绍有关知识。同样的问题在本书的不同章节以不同难度、广度和深度进行阐释。例如，第1章和第7章都讨论了边界条件。第3章和第13章都在讨论项目时间基线，以及如何按项目时间基线来安排测试任务。我们不在一个地方讨论某个主题的方方面面，而是随着读者了解了更多的背景和来龙去脉，逐步展开讨论该领域核心问题的更多内容。
第一部分—基础知识
前五章从测试新手的角度介绍了测试领域的基础知识，每个人都应阅读这几章。
给测试新手的建议
如果你详细阅读了第1、2、4、5章，并浏览了第3章，你就会非常喜欢这本书。然后，如有可能，花几周时间实际做些测试，报告一些缺陷，并收集一些反馈信息，之后再继续读第6章和以后的内容。
给教师的建议
如果学生们没有工作经验，在继续第6章之前，布置一个小型的测试项目（大约10~20小时的工作）。例如，在即将发布的软件中寻找缺陷（这类软件产品中存在很多缺陷）。不要强行要求对缺陷进行分析，只要记录这些缺陷和设计建议，并模拟写出其中的一些反馈信息。在练习的最后，重温一下测试涉及的范围，并指出明显存在缺陷的地方，或未做的重要测试。
第二部分—专门的测试技巧
第5章到12章重点讨论专门的测试技巧或问题。你可以独立地阅读任意一章或按任意顺序阅读（但在第6章前一定要先读第5章）。这些章对所有测试人员都很有益。我们写作这几章时设定的难度要稍高一些，目标读者是写过测试计划并领导过小规模测试组，或正在接受培训以便担当该职位的人。然而，阅读过第1章到第5章的测试新手也应该能通读这些内容。
给测试新手的建议
第6章讨论如何处理由产品的开发和营销团队提交的问题报告，以及为有利于问题处理而进行的问题报告数据库设计。对于那些总是经历挫折，很难追踪和描述严重错误，只能放弃、忽略、误解或搁置问题报告的读者来说，他们会对第6章特别感兴趣。这也正是他们积极去了解问题报告是如何处理，以及怎样才能做得更好的时机。如果你觉得第6章很枯燥，可以简单地看看前面的几节，跳过“数据库的技术细节”之后的内容。
第8章是关于打印机测试的。有些程序要处理很多打印任务，我们有员工专门设计打印机测试，本章是根据我们要求其掌握的详细程度编写的。如果内容对你过细，或你的工作不涉及太多打印，仅了解全章的整体思路即可。认真体会设备无关错误、打印机（或调制解调器、终端或视频卡等）类别相关的错误、驱动器相关错误、设备相关错误之间的差异。如果你能领会到我们为何按顺序测试这些错误类型，你就掌握了该章的精髓。
给教师的建议
作为测试人员的面试官，我们很高兴看到我们面试的人做过的很多工作（如编写的程序、写过的测试计划或测试报告）。商业保密守则禁止大多数测试人员向外界展示他们以前的工作，所以好的工作范例在毕业后的几年中都非常有用。以下是学生为拿学分可能做的一些项目，可保留在他/她的档案中。
为商业软件中使用的高度结构化的数据输入界面建立边界表（见第7章和第12章）。很多支票打印程序、地址簿、联系人管理程序都是实用且便宜的数据库应用程序范例。对单个的边界条件究竟需要多少测试才够？对几个边界条件的组合又大概需要多少测试才合适？首先找出必须测试的特别组合。对剩下的部分，编写一个采用随机数产生器（见第7章）的简短程序来生成对边界组合的测试用例。与手工选择边界条件的每个组合相比，这种方法是更好，还是更糟？
明白软件是如何与其他设备打交道的学生，可以修改第8章的内容来作为调制解调器、鼠标、视频卡、声卡或其他设备的测试程序。项目应包含能在特定的、现有商业软件中运行的测试范例。
按照软件手册对现有商业软件进行测试（见第10章）。项目报告就是注解了的手册，以及对软件与手册之间每个差异的缺陷报告，要明显地反映出在软件中而不是手册中存在一个错误。
使用自动测试工具对现有商业软件进行测试（见第11章）。不同类型的测试用例的创建时间是多长？与手工测试所需的时间相比较情况如何？在测试用例不失效的情况下，程序能够做多大程度的变更？基于这些情况，学生如何使用测试工具—在何种环境下、做何种测试？
第三部分—管理测试项目和小组
最后的第12章到第15章是针对高级测试人员和测试经理的。第12章和第13章分别从测试计划范围（见第12章）或项目范围（见第13章）的角度来组织上述材料。第14章考虑的是不当测试的法律后果，第15章讨论对测试小组的管理。
对本书布局的一些说明
本书的结构是按层次组织的。我们作了一些努力，尽量使这种结构清晰明显。例如，不同层次的标题采用不同字体表示：
主标题
二级标题
三级标题
四级标题
我们也采用不同字体和特殊字符来标注一些信息：
Courier字体：表示从计算机键盘输入的文本，或者，在用于避免与周围文字发生混淆的内容时，表示计算机屏幕显示的文本或计算机打印的数据库表格内容。
小号的Courier大写字体：表示数据库字段名或程序变量名。
楷体字体：表示术语的第一次重要使用，周围段落定义了该术语，或者表示强调的要点概述。
<Key>：表示计算机键盘上按键的名字，如<Enter>和<Ctrl>。
最后，当引用本书其他章节时，使用节号，如“12.1.1节”。
本书的写作开始于1983年。这些年来，许多人就本书给予了我们帮助，对原稿和第一版（Kaner 1988）提出了批评意见。
我们特别感谢下列人士（按姓名字母顺序）：Elaine Andersson教授、Boris Beizer博士、Jim Brooks、Randy Delucchi，Mel Doweary，David Farmer、Larry Jones教授、Sharon Hafner、Mahmood Hahn、Ginny kaner、Sam kaner博士、John Lavelle、Larry Malcus博士、Ted Matsumara、Don Maxwell博士、Bruce Miller、Derick Miller、Rachel Miller、Peter Morse、Jane Stepak和Emmanuel Uren。
当然，作者对书中的所有错误负责。
(美)Cem Kaner,Jack Falk,Hung Q.Nguyen：Cem Kaner: Cem Kaner，技术及软件开发管理顾问，并在当地大学及几家软件公司中讲授软件测试课程。他还是律师，通常为个人开发者、小型开发服务公司及客户工作。他创建并主持着洛斯阿尔托斯软件测试研讨会（Los Altos Workshops on Software Testing）。Kaner在1976年开始使用计算机，当时他是一名人类实验心理学的研究生。1983年，他前往硅谷，作过程序员、人为因素分析师、用户界面设计人员、软件销售人员、团队开发咨询公司合伙人、技术撰稿人、软件测试技术小组负责人、软件测试经理、技术发布经理、软件开发经理，以及文档编制和软件测试主管。他还曾作为代理地方检察官以及作为加利福利亚地区消费者事务部门的调查员/调解人提供公益服务。他积极参与到影响软件质量法规的立法工作中，并且是《Bad Software: What to Do When Software Fails 》的资深作者（Wiley，1998）。Kaner拥有数学学士、哲学学士、法学博士以及心理学博士等多个学位，而且他通过了美国质量协会的质量工程认证。读者可以通过kaner@kaner.com与他联系，在www.kaner.com查阅其有关软件测试的著作，在www.badsoftware.com上查阅其有关软件消费者保护的著作。
Jack Falk: Jack Falk，软件质量管理及软件工程管理顾问。曾担任质量保证和工程服务主管；管理过多媒体软件产品的开发、软件开发运作及工程支持服务；还管理过手持设备操作系统软件、软件开发工具包（SDK）、娱乐、图形及财务应用软件的测试工作。另外，他还管理过若干重要零售商的配送和运作业务（在集团经理或主管级别）。Jack通过了美国质量协会的软件质量工程认证，在旧金山城市学院获得商业AA学位，并完成了大量的商业及软件开发课程。他是2级证券分析师，并持有不动产评估师的执照。他是圣克拉拉地区（Santa Clara Valley）软件质量协会副主席，还是洛斯阿尔托斯软件测试研讨会的积极参与者。读者可以通过jfalk@asqnet.org与其联系。
Hung Q.Nguyen: SoftGear技术公司（一家硅谷公司，其宗旨是帮助软件开发组织在资源缺乏、时间紧迫的夹缝中尽量交付高质量的产品。）的创始人、总裁和CEO。这家公司创建于1994年，在完成若干外包测试工程及测试项目、软件测试支持产品以及一系列实用的软件测试培训课程之后，成功达到其预期目标。Hung还开发了培训材料，并在大学和众多知名的美国及国际软件公司中向大众讲授软件测试课程。他曾在计算机软件及硬件行业供职，担任过工程、质量保证、测试、产品开发以及信息技术的管理职位，并作为测试人员和程序员做出过重大贡献。Hung拥有考格斯威尔工艺学院的质量保证科学学士学位，是美国质量协会（ASQ）认证的质量工程师、美国质量协会高级会员及旧金山分会认证主任。Hung与妻子Heather及两个孩子（Wendy和Denny）居住在加利福利亚的福斯特城（Foster City）。读者可以通过hungn@softgeartech.com与其联系，或者在www.softgeartech.com上了解SoftGear技术公司的更多信息及Hung的工作。
王峰 陈杰 喻琳：暂无简介
从计算机诞生起，软件问题就伴随其左右。层出不穷的软件故障以及由此带来的尴尬局面给软件产业敲响了警钟。在大量现实的不良后果面前，痛定思痛，人们开始重新认识软件测试：软件测试与软件开发对软件质量具有同等重要的意义。
近年来，有不少好书讲解有高可靠性要求的软件产品的测试方法，细致而专业，介绍了如何进行完整的软件测试工作。它们通常是针对重要行业（如军事、医疗、金融等）的应用系统，这些系统事先都进行了详细的定义和设计，质量保证和测试活动的经费充足，软件测试人员能够彻底接触系统源代码。而本书侧重于不会造成人命关天后果的消费软件、普通商业软件、学术研究软件和个人软件等，它们不要求很高的可靠性。
本书作为面向学生的教材，主要是为了提供培训和工作指南而撰写。书中介绍了如何在通常的业务条件下测试消费软件和商业软件，以生动的语言和实例说明如何在有限的测试预算、紧迫的时间进度以及缺乏足够人手的条件下进行有效测试，保证产品具有令人满意的质量。书中介绍的测试不要求读者按照某种特定的“规则”或“规定”行事，它更强调在测试活动中每个人的力量及相互间的协同合作，认为软件质量的保证在于参与测试的每个人追求卓越品质的承诺、熟练使用工具的技巧以及协同工作的能力，而不是死抠“规定”。书中指出，开发阶段形成的一系列规定（如规格说明）不是一成不变的东西，会随着测试工作的开展，根据产品功能及其他品质的修正而做出相应改变。测试人员的工作就是要在产品发生后期变更的有限时间内尽可能平稳地处理变更状况，以最大的个人积极性来改进产品质量，而不是刻板地建立规章制度来抑制变更的产生。
本书选择了反映出读者兴趣及对读者有益的主题，摒弃某些学术性内容（如程序正确性证明），讨论在一般教科书中并未强调的内容。例如，书中讨论了人际关系和企业文化，提出了一些建议来让测试人员避免陷入企业内部的政治漩涡中，从而提高工作效率；讨论了项目管理问题，指出软件测试估算、计划和时间安排的重要性，提出优先级和效率是做出权衡的重点考虑对象；探究了法律问题，指出测试人员应如何避免产生各类法律纠纷以便更好地完成工作。
本书的很多修订为在校学生而做，希望本书能够填补大学教育中有关测试知识课程的空白，使更多具备相当计算机软件测试知识的学生能够投入到这一领域中来。然而在此我们要指出“师傅领进门，修行在个人”，我们希望本书的读者不仅仅满足于本书的内容，要更系统地学习相关的大学计算机课程，才能拓展思维，更好地领会和实践。
本书以一个样例测试系列开始，引出测试活动的基础知识，继而对测试技巧、测试管理等问题进行了探讨。全书分为三部分。第一部分是基本原则：讲解测试目标和局限、测试类型，简要介绍常见的软件问题，并说明如何报告和分析故障，这是每位读者都应仔细阅读的部分。第二部分是特殊的测试技巧：问题跟踪系统的使用，测试用例的设计，设备测试，本地化测试，用户手册测试，有用的测试工具，以及测试过程中产生的测试计划和测试文档。读者可以根据自身知识水平选择相应章节阅读，或者按任意顺序阅读。最后一部分是测试项目和测试人员的管理：测试开发进程时间基线、法律问题和管理问题。这部分主要针对高级测试人员和测试经理。另外，本书在附录中分门别类地列出了400多个常见的软件错误，并对每个错误进行了简要说明，以备测试人员作为参考来查对被测软件的错误，还可以根据实际情况增删故障现象以形成自己的故障数据库。
本书由王峰、陈杰、喻琳翻译，全书由王峰统稿。鉴于译者水平有限，在翻译过程中难免出现失误和不足，请广大读者不吝赐教。
目录
第一部分 基础知识
第1章 一个样例测试系列 3
1.1 第一个测试周期 3
1.1.1 第1步：从一个显而易见的简单测试开始 3
1.1.2 第一次测试产生的问题报告 4
1.1.3 第2步：对还需要测试什么做一些记录 4
1.1.4 寻找边界条件 6
1.1.5 第3步：检查有效用例并观察发生了什么 7
1.1.6 第4步：做一些“快速的”测试 7
1.1.7 第5步：总结对程序及其问题的认识 9
1.1.8 第一个测试周期的总结 12
1.2 第二个测试周期 12
1.2.1 第1步：在进行任何测试之前应仔细评审对问题报告的反馈，以确定哪些需求必须满足，哪些无须满足 13
1.2.2 第2步：评审对不进行改正的问题的意见，它们可能暗示着进行进一步的测试 13
1.2.3 第3步：找出上次的记录，补充新记录，然后开始测试 14
1.3 后续测试周期中可能会发生的事情 15
第2章 测试的目标和局限 17
2.1 不可能完全测试一个程序 18
2.1.1 不可能测试到程序对任何可能输入的响应 18
2.1.2 不可能测试到程序每一条可能的执行路径 20
2.1.3 无法找出所有的设计错误 22
2.1.4 不能采用逻辑来证明程序的正确性 22
2.2 测试人员的目标是验证程序吗 22
2.2.1 无法验证程序运行正确 22
2.2.2 程序不能正确地运行 23
2.2.3 既然程序不能正确地工作，那么测试是不是个失败呢 23
2.2.4 测试人员不应该试图验证一个程序运行正确 23
2.3 那么，为什么要进行测试呢 24
2.3.1 测试一个程序的目的是为了发现它的问题 24
2.3.2 发现问题的目的是为了改正问题 25
第3章 测试的类型及其在软件开发过程中的地位 26
3.1 软件开发阶段综述 29
3.2 规划阶段 30
3.2.1 目标阐述 30
3.2.2 需求分析 31
3.2.3 功能定义 31
3.3 规划阶段进行的测试 31
3.3.1 产品对照评价 32
3.3.2 重点问题小组 32
3.3.3 任务分析 33
3.4 设计阶段 33
3.4.1 外部设计 33
3.4.2 内部设计 34
3.4.3 原型开发 35
3.5 设计阶段的测试 36
3.5.1 评审会议 37
3.5.2 伪代码分析 37
3.6 白盒代码测试是编码阶段的组成部分 38
3.6.1 结构测试与功能测试 39
3.6.2 路径测试：覆盖准则 39
3.6.3 增长测试与崩溃测试 41
3.6.4 自顶向下测试与自底向上测试 42
3.6.5 静态测试与动态测试 42
3.6.6 标准符合性 43
3.6.7 软件度量 43
3.6.8 刻意的错误：调试与变异 44
3.6.9 性能测试 45
3.7 回归测试 45
3.8 黑盒测试 46
3.8.1 常用的黑盒测试事件序列 46
3.8.2 功能测试和系统测试中需要进行的测试 49
3.9 维护 51
第4章 软件错误 54
4.1 质量 54
4.2 什么是软件错误 55
4.3 软件错误的分类 55
4.3.1 用户界面错误 55
4.3.2 错误处理 56
4.3.3 与边界相关的错误 56
4.3.4 计算错误 57
4.3.5 最初阶段与后续阶段 57
4.3.6 控制流错误 57
4.3.7 数据处理或解释中的错误 57
4.3.8 竞争条件 57
4.3.9 负载条件 58
4.3.10 硬件 58
4.3.11 源程序和版本控制 58
4.3.12 文档 58
4.3.13 测试中的错误 58
第5章 缺陷的报告与分析 59
5.1 即时填写问题报告 60
5.2 问题报告的内容 60
5.2.1 问题报告编号 60
5.2.2 程序名 60
5.2.3 版本标识：发布号和版本号 60
5.2.4 报告类型 62
5.2.5 严重性 62
5.2.6 附件 63
5.2.7 问题概要 63
5.2.8 问题能否重现 63
5.2.9 问题描述及如何重现 64
5.2.10 建议的改正措施 64
5.2.11 报告人 64
5.2.12 日期 64
5.2.13 功能域 64
5.2.14 承办人 65
5.2.15 注释 65
5.2.16 状态 65
5.2.17 优先级 65
5.2.18 处理状态与处理版本 66
5.2.19 签名 66
5.2.20 暂缓处理 66
5.3 问题报告的特点 67
5.3.1 书面的 67
5.3.2 已编号的 68
5.3.3 简单的 68
5.3.4 易于理解的 68
5.3.5 可重现的 68
5.3.6 易读的 68
5.3.7 不做判断的 69
5.4 重现缺陷的分析 69
5.4.1 找出最严重的后果 70
5.4.2 找出最简单和最常见的条件 70
5.4.3 找出产生相同问题的其他路径 71
5.4.4 找出相关的问题 71
5.5 可重现缺陷的分析技术 71
5.5.1 寻找最关键的步骤 71
5.5.2 最大程度地提高程序运行的可见性 72
5.5.3 一旦找出了关键步骤，就改变你的做法 73
5.5.4 查找后续错误 73
5.5.5 渐进地省略或改变步骤 73
5.5.6 在程序以前的版本中查找错误 74
5.5.7 查找配置依赖 74
5.6 让缺陷可重现 74
5.6.1 竞争条件 75
5.6.2 被遗忘的细节 75
5.6.3 用户的错误：所做的并非是以为做到的 75
5.6.4 缺陷造成的影响会导致其无法重现 75
5.6.5 缺陷是依赖于内存的 76
5.6.6 仅会在初次运行时出现的缺陷 76
5.6.7 因数据错误导致的缺陷 76
5.6.8 由于一些其他问题附带引起的缺陷 76
5.6.9 间断性硬件故障 77
5.6.10 缺陷依赖于时间 77
5.6.11 缺陷依赖于资源 77
5.6.12 缺陷由长期积累形成 77
5.6.13 代码中的特殊分支 78
5.6.14 有人动了你的计算机 78
第二部分 特殊的测试技巧
第6章 问题跟踪系统 81
6.1 问题跟踪系统的主要目标 84
6.2 问题跟踪系统的任务 84
6.3 问题跟踪概述 84
6.3.1 问题被上报 84
6.3.2 报告提交给项目经理 85
6.3.3 报告由项目经理转交给程序员 86
6.3.4 当问题已经改正 87
6.3.5 无法重现的问题 87
6.3.6 问题暂缓与申诉过程 88
6.3.7 未被处理的问题 89
6.3.8 项目状态报告 89
6.4 跟踪系统的使用者 90
6.4.1 主任测试员 90
6.4.2 其他测试人员 90
6.4.3 项目经理 90
6.4.4 程序员 92
6.4.5 产品经理 92
6.4.6 技术支持 92
6.4.7 文档编写人员 93
6.4.8 测试经理 93
6.4.9 高级经理 94
6.4.10 律师 97
6.5 数据库的技术细节 98
6.5.1 报告新的问题 98
6.5.2 每周状态报告 98
6.5.3 测试周期的结束 99
6.5.4 已处理的问题和未处理的问题 100
6.5.5 暂缓处理的问题 101
6.5.6 进展总结 101
6.5.7 开发结束时 102
6.5.8 为下一个发布版本重新打开暂缓处理的缺陷 103
6.5.9 跟踪补丁 104
6.6 关于问题报告的进一步思考 104
6.6.1 进行判断 104
6.6.2 相似的报告 106
6.6.3 允许不同的观点存在 107
6.6.4 内部细节 108
6.6.5 问题报告单的一些注意事项 109
6.7 术语表 109
第7章 测试用例设计 111
7.1 良好测试具备的特点 112
7.1.1 它有相当的可能找出软件错误 112
7.1.2 它不是冗余的 113
7.1.3 它是本类用例中最佳的选择 113
7.1.4 它既不过于复杂，又不过于简单 113
7.1.5 它使程序失效显而易见 113
7.2 等价类与边界值 113
7.2.1 等价类 113
7.2.2 找出等价类 114
7.2.3 等价类的边界 118
7.3 可见的状态转换 119
7.4 竞争条件与其他时间依赖关系 119
7.5 负载测试 120
7.6 错误猜测 121
7.7 函数等价测试：自动执行、敏感度分析与随机输入 121
7.7.1 函数等价测试的自动执行 121
7.7.2 敏感度分析 122
7.7.3 随机输入 123
7.7.4 通用等价测试 124
7.8 回归测试：检查缺陷是否有效改正 124
7.9 回归测试：标准测试库 125
7.10 执行测试 126
第8章 打印机及其他设备的测试 127
8.1 配置测试的一般性问题 128
8.2 打印机测试 130
8.2.1 打印机综述 130
8.2.2 打印机驱动策略 132
8.2.3 打印机测试的总体策略 133
8.2.4 打印机测试矩阵 137
8.2.5 保存、分享及重用你的打印机知识 140
8.2.6 自动测试的一些技巧 140
8.2.7 建立一个打印机测试实验室 145
第9章 本地化测试 148
9.1 基本的代码改变了吗 149
9.2 与熟悉当地语言的人一起工作 149
9.3 文本与代码相互独立吗 149
9.4 翻译文本的空间膨胀 150
9.5 字符集 150
9.6 键盘 151
9.7 文本过滤 151
9.8 载入、保存、导入和导出高ASCII字符和低ASCII字符 151
9.9 操作系统的语言 152
9.10 热键 152
9.11 翻译中的断章取义 152
9.12 错误信息辨识器 152
9.13 连词规则 152
9.14 拼写规则 152
9.15 排序规则 153
9.16 大小写转换 153
9.17 下划线规则 153
9.18 打印机 153
9.19 纸张尺寸 153
9.20 CPU与视频卡 153
9.21 鼠标 154
9.22 数据格式及设置选项 154
9.23 测量标准 154
9.24 与当地文化相抵触的图形 154
9.25 与当地文化相抵触的输出 154
9.26 欧洲产品的兼容性 154
9.27 内存可用性 155
9.28 图形用户界面能解决问题吗 155
9.29 自动测试 155
第10章 用户手册的测试 156
10.1 有效的文档 156
10.2 文档测试人员的目标 157
10.3 文档测试如何有助于提高软件可靠性 158
10.4 成为技术编辑 159
10.5 用户手册编制阶段一览 159
10.5.1 第一稿 160
10.5.2 第二稿 160
10.5.3 经修订的第二稿 161
10.5.4 b测试稿 162
10.5.5 制作阶段 162
10.5.6 后期制作阶段 163
10.6 在线帮助 164
第11章 测试工具 165
11.1 基本工具 165
11.2 自动验收测试与自动回归测试 167
11.2.1 回归测试用例的出处 168
11.2.2 为程序提供输入 168
11.2.3 捕获程序的输出 170
11.2.4 对输出的评价 170
11.2.5 自动验收测试 172
11.3 标准 172
11.4 半透明盒测试 174
11.4.1 插装代码以监视代码覆盖率 174
11.4.2 断言检查 175
11.4.3 内存有效性及占用检查 176
第12章 测试计划与测试文档 177
12.1 测试计划的总体目标：作为产品还是作为工具 178
12.1.1 作为产品的测试计划 178
12.1.2 作为工具的测试计划 178
12.2 测试计划和测试文档的具体目标 179
12.2.1 测试文档有助于测试技术任务的完成 179
12.2.2 测试文档增进了测试任务和测试过程之间的交流 181
12.2.3 测试文档提供了组织、安排以及管理测试项目的结构 182
12.3 测试计划文档中需要覆盖的测试类型 184
12.3.1 遗漏了什么样的白盒测试 184
12.3.2 重要的黑盒测试类型 185
12.4 开发测试计划文档的组成部分的策略 186
12.4.1 测试材料的演化开发 186
12.4.2 测试材料的初始开发 187
12.4.3 下一步集中于何处，在何处增加深度 188
12.4.4 增加测试计划深度的技巧 189
12.5 测试计划文档的组成部分 190
12.5.1 清单 191
12.5.2 表 195
12.5.3 大纲—功能清单 201
12.5.4 矩阵 205
12.6 测试材料的归档 209
12.6.1 谁会使用这种文档 209
12.6.2 测试文档的类型 213
12.7 结束时的思考 218
第三部分 测试项目和测试小组的管理
第13章 连接起来 221
13.1 软件开发权衡 223
13.2 软件开发模型 224
13.2.1 传统的瀑布方法 224
13.2.2 演化方法 225
13.2.3 开发模型对测试的建议 227
13.3 与质量相关的成本 229
13.4 开发时间基线 230
13.5 产品设计 233
13.5.1 产品设计期间的编程活动 233
13.5.2 产品设计期间的营销活动 233
13.5.3 产品设计期间的文档活动 233
13.5.4 产品设计期间的测试活动 234
13.6 分段编码：首要功能 237
13.6.1 首要功能之后的编程活动 237
13.6.2 首要功能之后的测试活动 237
13.7 准a测试阶段 238
13.7.1 准a测试阶段的编程活动 238
13.7.2 准a测试阶段的文档活动 238
13.7.3 准a测试阶段的测试活动 238
13.8 a测试阶段 239
13.8.1 a测试阶段后的编程活动 240
13.8.2 a测试阶段后的营销活动 240
13.8.3 a测试阶段后的文档活动 240
13.8.4 a测试阶段后的测试活动 240
13.8.5 测试的深度与广度的比较 244
13.8.6 关于测试周期的记录 246
13.9 预b测试阶段 247
13.10 b测试阶段 247
13.10.1 b测试阶段后的编程活动 248
13.10.2 b测试阶段后的营销活动 249
13.10.3 b测试阶段后的文档活动 249
13.10.4 b测试阶段后的测试活动 249
13.10.5 外部b测试 251
13.11 用户界面确定 253
13.11.1 用户界面确定后的编程活动 254
13.11.2 用户界面确定后的营销活动 254
13.11.3 用户界面确定后的文档活动 254
13.11.4 用户界面确定后的测试活动 254
13.12 预最终测试阶段 255
13.12.1 预最终测试期间的编程活动 255
13.12.2 预最终测试期间的文档活动 256
13.12.3 预最终测试期间的测试活动 256
13.12.4 估计产品的可靠性 257
13.13 最终的完整性测试 259
13.13.1 最终测试阶段的编程活动 259
13.13.2 最终测试阶段的测试活动 259
13.14 发布 260
13.15 项目总结 260
第14章 有缺陷软件的法律后果 262
14.1 违约 264
14.1.1 U.C.C与软件合同 264
14.1.2 违反保证 265
14.1.3 明确保证 266
14.1.4 适销性的暗示保证 267
14.1.5 特殊目的适当性的暗示保证 267
14.1.6 合同与瀑布模型的暗示保证 268
14.1.7 赔偿金 269
14.1.8 收缩性薄膜包装保证的不承担责任声明 270
14.2 侵权行为：涉及过错的诉讼 274
14.2.1 非法占有 274
14.2.2 过失 277
14.2.3 严格产品责任 288
14.2.4 渎职 289
14.2.5 欺诈 290
14.3 揭发 291
第15章 管理一个测试小组 293
15.1 测试小组的职责 295
15.1.1 质量控制组 295
15.1.2 质量保证组 296
15.1.3 测试服务组 297
15.1.4 开发服务组 298
15.1.5 建议 298
15.2 测试小组并不纯粹是件好事 298
15.3 另一种选择？独立测试机构 299
15.4 进度制定技巧 301
15.4.1 度量业绩和生产率 302
15.4.2 确定并估计每个任务 303
15.4.3 把项目分等级 304
15.4.4 把任务确定为与循环相对的固定任务 305
15.5 你的职员 306
15.5.1 雇用谁 307
15.5.2 士气 308
15.5.3 事业发展 309
附录 常见的软件错误 311
参考文献
