计算机软件测试(原书第2版)
基本信息
- 作者: (美)Cem Kaner,Jack Falk,Hung QuocNguyen [作译者介绍]
- 译者: 王峰 陈杰 喻琳
- 丛书名: 软件工程技术丛书
- 出版社:机械工业出版社
- ISBN:7111142462
- 上架时间:2004-5-26
- 出版日期:2004 年5月
- 开本:16开
- 页码:397
- 版次:1-1
- 所属分类:
计算机 > 软件工程及软件方法学 > 软件质量、软件测试及维护
教材 > 研究生/本科/专科教材 > 工学 > 计算机
编辑推荐
本书作为面向学生的教材;主要是为了提供培训和工作指南而撰写。书中介绍了如何在通常的业务条件下测试消费软件和商业软件;以生动的语言和实例说明如何在有限的测试预算、紧迫的时间进度以及缺乏足够人手的条件下进行有效测试,保证产品具有令人满意的质量。书中介绍的测试不要求读者按照某种特定的“规则”或“规定”行事;它更强调在测试活动中每个人的力量及相互间的协同合作,认为软件质量的保证在于参与测试的每个人追求卓越品质的承诺、熟练使用工具的技巧以及协同工作的能力,而不是死抠“规定”。书中指出,开发阶段形成的一系列规定(如规格说明)不是一成不变的东西,会随着测试工作的开展,根据产品功能及其他品质的修正而做出相应改变。测试人员的工作就是要在产品发生后期变更的有限时间内尽可能平稳地处理变更状况,以最大的个人积极性来改进产品质量,而不是刻板地建立规章制度来抑制变更的产生。
本书选择了反映出读者兴趣及对读者有益的主题,摒弃某些学术性内容(如程序正确性证明),讨论在一般教科书中并未强调的内容。例如,书中讨论了人际关系和企业文化,提出了一些建议来让测试人员避免陷入企业内部的政治漩涡中,从而提高工作效率;讨论了项目管理问题,指出软件测试估算、计划和时间安排的重要性,提出优先级和效率是做出权衡的重点考虑对象;探究了法律问题,指出测试人员应如何避免产生各类法律纠纷以便更好地完成工作。
内容简介回到顶部↑
书籍
计算机书籍
[style type="text/css"] [!-- .unnamed1 { font-size: 14px; line-height: normal} --] [/style] 本书从软件测试的基础知识讲起,继而对软件测试技巧及软件测试管理等问题进行了深入的探讨。本书先介绍了测试目标、测试类型,说明如何报告和分析故障;而后介绍了问题跟踪系统的使用、测试用例的设计、设备测试,测试本地化、测试工具,以及测试计划和测试文档;最后介绍了测试项目及测试人员的管理。此外,本书最后的附录列出了400多个常见的软件错误,并对每个错误进行了简要说明,可供测试人员参考。
本书不仅适合软件测试人员和测试经理,也适合项目经理和程序员阅读,尤其适合作为软件测试岗位培训的教材。
本书讲述如何在现实世界的环境下测试计算机软件,作者都曾在知名的硅谷软件公司中担任过测试经理或软件开发经理。现今,成功的商业软件公司已经学会了在严格的时间及预算限制下研发出高质量产品的方法,而本书诠释了这些成功的软件公司所采用的软件测试技术和方法。
本书面向的读者:
●测试人员和测试经理。
●项目经理——掌握时间基线、研究深度以及使测试人员保持其责任心的沟通技能。
●程序员——获得洞察代码中错误根源的能力,了解软件测试的必要性和内容。
●学生——软件开发人员初级岗位的培训。
[font color="#000000"]本书的写作目标是使读者学会:[/font][font color="#ff0000"]
[font color="#000000"]●如何快速发现重要缺陷。
●如何清晰描述软件错误。
●如何以最少的篇幅创建测试计划。
●如何设计和使用缺陷跟踪系统。
●判断在产品开发过程中哪个阶段适合进行测试。
●如何测试要翻译成其他语言的产品。
●如何测试与设备(如打印机)的兼容性。
●判断哪些法规适用于软件质量保障。[/font][/font]
[font color="#ff0000"][b]特别推荐: [/b][/font]
计算机书籍
[style type="text/css"] [!-- .unnamed1 { font-size: 14px; line-height: normal} --] [/style] 本书从软件测试的基础知识讲起,继而对软件测试技巧及软件测试管理等问题进行了深入的探讨。本书先介绍了测试目标、测试类型,说明如何报告和分析故障;而后介绍了问题跟踪系统的使用、测试用例的设计、设备测试,测试本地化、测试工具,以及测试计划和测试文档;最后介绍了测试项目及测试人员的管理。此外,本书最后的附录列出了400多个常见的软件错误,并对每个错误进行了简要说明,可供测试人员参考。
本书不仅适合软件测试人员和测试经理,也适合项目经理和程序员阅读,尤其适合作为软件测试岗位培训的教材。
本书讲述如何在现实世界的环境下测试计算机软件,作者都曾在知名的硅谷软件公司中担任过测试经理或软件开发经理。现今,成功的商业软件公司已经学会了在严格的时间及预算限制下研发出高质量产品的方法,而本书诠释了这些成功的软件公司所采用的软件测试技术和方法。
本书面向的读者:
●测试人员和测试经理。
●项目经理——掌握时间基线、研究深度以及使测试人员保持其责任心的沟通技能。
●程序员——获得洞察代码中错误根源的能力,了解软件测试的必要性和内容。
●学生——软件开发人员初级岗位的培训。
[font color="#000000"]本书的写作目标是使读者学会:[/font][font color="#ff0000"]
[font color="#000000"]●如何快速发现重要缺陷。
●如何清晰描述软件错误。
●如何以最少的篇幅创建测试计划。
●如何设计和使用缺陷跟踪系统。
●判断在产品开发过程中哪个阶段适合进行测试。
●如何测试要翻译成其他语言的产品。
●如何测试与设备(如打印机)的兼容性。
●判断哪些法规适用于软件质量保障。[/font][/font]
[font color="#ff0000"][b]特别推荐: [/b][/font]
作译者回到顶部↑
本书提供作译者介绍
Cem Kaner
技术及软件开发管理顾问,并在当地大学及几家软件公司中讲授软件测试课程。他还是律师,通常为个人开发者、小型开发服务公司及客户工作。他创建并主持着洛斯阿尔托斯软件测试研讨会(Los Altos Workshops on Software Testing)。Kaner在1976年开始使用计算机,当时他是一名人类实验心理学的研究生。1983年,他前往硅谷,作过程序员、人为因素分析师、用户界面设计人员、软件销售人员、团队开发咨询公司合伙人、技术撰稿人、软件测试技术小组负责人、软件测试经理、技术发布经理、软件开发经.. << 查看详细
技术及软件开发管理顾问,并在当地大学及几家软件公司中讲授软件测试课程。他还是律师,通常为个人开发者、小型开发服务公司及客户工作。他创建并主持着洛斯阿尔托斯软件测试研讨会(Los Altos Workshops on Software Testing)。Kaner在1976年开始使用计算机,当时他是一名人类实验心理学的研究生。1983年,他前往硅谷,作过程序员、人为因素分析师、用户界面设计人员、软件销售人员、团队开发咨询公司合伙人、技术撰稿人、软件测试技术小组负责人、软件测试经理、技术发布经理、软件开发经.. << 查看详细
目录回到顶部↑
译者序
前言
关于本书结构和布局的说明
作者简介
第一部分 基础知识
第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章 一个样例测试系列 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
译者序回到顶部↑
从计算机诞生起,软件问题就伴随其左右。层出不穷的软件故障以及由此带来的尴尬局面给软件产业敲响了警钟。在大量现实的不良后果面前,痛定思痛,人们开始重新认识软件测试:软件测试与软件开发对软件质量具有同等重要的意义。
近年来,有不少好书讲解有高可靠性要求的软件产品的测试方法,细致而专业,介绍了如何进行完整的软件测试工作。它们通常是针对重要行业(如军事、医疗、金融等)的应用系统,这些系统事先都进行了详细的定义和设计,质量保证和测试活动的经费充足,软件测试人员能够彻底接触系统源代码。而本书侧重于不会造成人命关天后果的消费软件、普通商业软件、学术研究软件和个人软件等,它们不要求很高的可靠性。
本书作为面向学生的教材,主要是为了提供培训和工作指南而撰写。书中介绍了如何在通常的业务条件下测试消费软件和商业软件,以生动的语言和实例说明如何在有限的测试预算、紧迫的时间进度以及缺乏足够人手的条件下进行有效测试,保证产品具有令人满意的质量。书中介绍的测试不要求读者按照某种特定的“规则”或“规定”行事,它更强调在测试活动中每个人的力量及相互间的协同合作,认为软件质量的保证在于参与测试的每个人追求卓越品质的承诺、熟练使用工具的技巧以及协同工作的能力,而不是死抠“规定”。书中指出,开发阶段形成的一系列规定(如规格说明)不是一成不变的东西,会随着测试工作的开展,根据产品功能及其他品质的修正而做出相应改变。测试人员的工作就是要在产品发生后期变更的有限时间内尽可能平稳地处理变更状况,以最大的个人积极性来改进产品质量,而不是刻板地建立规章制度来抑制变更的产生。
本书选择了反映出读者兴趣及对读者有益的主题,摒弃某些学术性内容(如程序正确性证明),讨论在一般教科书中并未强调的内容。例如,书中讨论了人际关系和企业文化,提出了一些建议来让测试人员避免陷入企业内部的政治漩涡中,从而提高工作效率;讨论了项目管理问题,指出软件测试估算、计划和时间安排的重要性,提出优先级和效率是做出权衡的重点考虑对象;探究了法律问题,指出测试人员应如何避免产生各类法律纠纷以便更好地完成工作。
本书的很多修订为在校学生而做,希望本书能够填补大学教育中有关测试知识课程的空白,使更多具备相当计算机软件测试知识的学生能够投入到这一领域中来。然而在此我们要指出“师傅领进门,修行在个人”,我们希望本书的读者不仅仅满足于本书的内容,要更系统地学习相关的大学计算机课程,才能拓展思维,更好地领会和实践。
本书以一个样例测试系列开始,引出测试活动的基础知识,继而对测试技巧、测试管理等问题进行了探讨。全书分为三部分。第一部分是基本原则:讲解测试目标和局限、测试类型,简要介绍常见的软件问题,并说明如何报告和分析故障,这是每位读者都应仔细阅读的部分。第二部分是特殊的测试技巧:问题跟踪系统的使用,测试用例的设计,设备测试,本地化测试,用户手册测试,有用的测试工具,以及测试过程中产生的测试计划和测试文档。读者可以根据自身知识水平选择相应章节阅读,或者按任意顺序阅读。最后一部分是测试项目和测试人员的管理:测试开发进程时间基线、法律问题和管理问题。这部分主要针对高级测试人员和测试经理。另外,本书在附录中分门别类地列出了400多个常见的软件错误,并对每个错误进行了简要说明,以备测试人员作为参考来查对被测软件的错误,还可以根据实际情况增删故障现象以形成自己的故障数据库。
本书由王峰、陈杰、喻琳翻译,全书由王峰统稿。鉴于译者水平有限,在翻译过程中难免出现失误和不足,请广大读者不吝赐教。
近年来,有不少好书讲解有高可靠性要求的软件产品的测试方法,细致而专业,介绍了如何进行完整的软件测试工作。它们通常是针对重要行业(如军事、医疗、金融等)的应用系统,这些系统事先都进行了详细的定义和设计,质量保证和测试活动的经费充足,软件测试人员能够彻底接触系统源代码。而本书侧重于不会造成人命关天后果的消费软件、普通商业软件、学术研究软件和个人软件等,它们不要求很高的可靠性。
本书作为面向学生的教材,主要是为了提供培训和工作指南而撰写。书中介绍了如何在通常的业务条件下测试消费软件和商业软件,以生动的语言和实例说明如何在有限的测试预算、紧迫的时间进度以及缺乏足够人手的条件下进行有效测试,保证产品具有令人满意的质量。书中介绍的测试不要求读者按照某种特定的“规则”或“规定”行事,它更强调在测试活动中每个人的力量及相互间的协同合作,认为软件质量的保证在于参与测试的每个人追求卓越品质的承诺、熟练使用工具的技巧以及协同工作的能力,而不是死抠“规定”。书中指出,开发阶段形成的一系列规定(如规格说明)不是一成不变的东西,会随着测试工作的开展,根据产品功能及其他品质的修正而做出相应改变。测试人员的工作就是要在产品发生后期变更的有限时间内尽可能平稳地处理变更状况,以最大的个人积极性来改进产品质量,而不是刻板地建立规章制度来抑制变更的产生。
本书选择了反映出读者兴趣及对读者有益的主题,摒弃某些学术性内容(如程序正确性证明),讨论在一般教科书中并未强调的内容。例如,书中讨论了人际关系和企业文化,提出了一些建议来让测试人员避免陷入企业内部的政治漩涡中,从而提高工作效率;讨论了项目管理问题,指出软件测试估算、计划和时间安排的重要性,提出优先级和效率是做出权衡的重点考虑对象;探究了法律问题,指出测试人员应如何避免产生各类法律纠纷以便更好地完成工作。
本书的很多修订为在校学生而做,希望本书能够填补大学教育中有关测试知识课程的空白,使更多具备相当计算机软件测试知识的学生能够投入到这一领域中来。然而在此我们要指出“师傅领进门,修行在个人”,我们希望本书的读者不仅仅满足于本书的内容,要更系统地学习相关的大学计算机课程,才能拓展思维,更好地领会和实践。
本书以一个样例测试系列开始,引出测试活动的基础知识,继而对测试技巧、测试管理等问题进行了探讨。全书分为三部分。第一部分是基本原则:讲解测试目标和局限、测试类型,简要介绍常见的软件问题,并说明如何报告和分析故障,这是每位读者都应仔细阅读的部分。第二部分是特殊的测试技巧:问题跟踪系统的使用,测试用例的设计,设备测试,本地化测试,用户手册测试,有用的测试工具,以及测试过程中产生的测试计划和测试文档。读者可以根据自身知识水平选择相应章节阅读,或者按任意顺序阅读。最后一部分是测试项目和测试人员的管理:测试开发进程时间基线、法律问题和管理问题。这部分主要针对高级测试人员和测试经理。另外,本书在附录中分门别类地列出了400多个常见的软件错误,并对每个错误进行了简要说明,以备测试人员作为参考来查对被测软件的错误,还可以根据实际情况增删故障现象以形成自己的故障数据库。
本书由王峰、陈杰、喻琳翻译,全书由王峰统稿。鉴于译者水平有限,在翻译过程中难免出现失误和不足,请广大读者不吝赐教。
前言回到顶部↑
本书介绍了如何在通常的业务条件下测试消费软件和商业软件,实在而且实用。我们曾经为硅谷中快速成长的著名软件公司测试软件,管理其测试人员。我们撰写本书的目的在于为员工提供培训和工作指南。
已经有很多很好的书在讲授有高可靠性要求的软件产品的测试方法。人命关天的和金融领域的应用程序,事先都得到了详细的定义和设计,质量保证和测试活动的经费充足,软件测试人员能够完全接触系统源代码,并有充分的时间阅读它们。在这样的前提下,这些书籍介绍了如何进行完整的软件测试工作。
计算行业的大多数人,包括个人计算机业的绝大部分人,都在努力开发有用且可靠的软件产品,但这些软件并不要求很高的可靠性。就像买车你可以选性能良好的经济型轿车或中档轿车一样,大多数的程序不必成为劳斯莱斯(而且大多数人是买不起劳斯莱斯的)。消费软件、普通商务软件、学术研究软件和个人软件的开发人员的测试预算相当有限,时间紧迫,人手短缺,然而很多程序却具有令人满意的质量。他们是如何做到的呢?本书介绍了其中的测试工作部分。
书不能解决全部问题
有些书认为,如果一个软件项目没有得到“合理”的控制,书面规格说明始终没有完成且不是最新的,代码没有依据所谓流行的方法进行适当组织的话,那么必须要努力做到。这些书讲到的测试是建立在每个人都依据“规定”行事的基础之上的。
本书介绍的测试,假定的前提是你的同伴现在没有、将来也不会并且也没必要遵循这些规定。
消费软件项目通常的特点是,预算非常有限、人手非常少、交付时间非常紧迫而且不可能推迟、开发人员之间拥有共同的认识和承诺。
大型软件产品的质量掌握在那些负责设计、编程、测试、撰写文档的个人手上,每个人都很重要。无论是标准、规格说明、指导/协调委员会和变更控制都不能保证质量,软件公司也没有指望它们起到这样的作用。能够确保软件质量的,是个人追求卓越的承诺、熟练使用工具的技巧和协同工作的能力,而不是这些规定。
开发小组对所要创建的东西有了认识,对尽可能实现梦想达成了承诺,并且意识到不得不通过试验和错误来充实这些细节。当产品某一部分的所有细节工作都完成时,他们会形成一个只有一两个人能完全理解的工作说明。这个说明就是所谓的“规格说明”。“规格说明”并不是刻在石头上一成不变的,随后会被评审和修正,以便与系统其他部分保持一致。大多数的修正是根据软件测试人员的建议进行的。
在现实世界中,产品变更一般发生在开发阶段的后期。当你正开发一个公开发售的软件产品时,你的客户或潜在客户不一定会同意你的设计。如果竞争对手开发出更具吸引力的产品,你要马上作出反应。
由于没有时间实现,预想的功能往往被取消掉。代码重写也被搁置一边,即使是需要完成这些代码重写工作把勉勉强强提交的第一版本改得稍微专业一些。认真负责的程序员也许会自觉地,甚至是“偷偷地”完成这项工作。在项目的后期,他可能在没有通知其他任何人的情况下对软件包做了重要修改。这些努力是在每周40小时工作时间之外完成的,可能会极大地改进软件质量,但也可能使软件质量变得极其糟糕。不管结果如何,软件质量的改进是通过个人的积极性来实现的。
后期的变更是不可避免的。我们的目标是尽可能平稳地来处理这些必要的变更。我们不打算建立什么规章制度来抑制变更的产生。作为测试人员,你如果处理不好变更,就会有麻烦。解决之道不在于单纯抱怨或是竭力阻止它们。
本书的读者对象
本书的读者对象是从事软件测试且常常测试他人代码的人员。我们认为所选主题和讨论水平反映了读者感兴趣或对读者有益处的内容。因此我们摒弃某些学术性内容(如程序正确性证明),讨论通常在测试教科书中并未强调的内容。例如,我们经常谈论到人际关系和企业文化问题。连最初级的软件测试人员也必须评判他人的工作—这就是测试工作的根本。在将他们的判断与别人进行交流的过程中,测试人员容易受到指责(有时也是“罪有应得”)。他们工作的重要程度往往与其地位不相称,从而导致他们容易成为人际矛盾的靶子或替罪羊。我们没有办法解决其地位问题,但我们确实提出了一些建议来提高测试效率和避免某些陷阱。
我们也讨论项目管理问题。软件测试的估算、计划和时间安排很棘手,因为软件测试没有真正的终点,测试总是没完没了,如果不做就会有更多的风险。每个测试人员都必须明白这种平衡关系。他们需要安排时间来充分考虑这些因素。例如,某个测试人员可能为了更好地完成其他任务而推迟了重要的测试,但是,后来发现由于时间已用完,再也无法进行这些测试了。本打算将工作做得更好,却弄巧成拙。这种情况很常见,而且非常令人沮丧。因此,优先级和效率是本书主要关注的问题。
测试人员还要处理设计错误。按照糟糕的规格说明实现的程序,其质量必定是糟糕的。大多数有关软件可靠性和测试的书籍没有涉及用户界面,而将其作为人为因素分析员的工作范围。我们不同意这种观点。(我们之中就有一位人为因素分析专家,他也不赞同。)系统的可靠性取决于其各部分是如何协同工作的,包括使用它的人员在内。
作为测试人员,你的任务是发现并指出产品中存在的问题,为改进产品质量服务。无论问题的源头出在何处,关于人-机系统可靠性差的报告都是适当和重要的。你是少数几个能在产品发布前详细检验整个产品的人之一。还有哪些地方能产生这种反馈呢?
我们对用户界面问题的讨论并不能让你成为专家,你仍然会遗漏很多重要问题。你的一些设计建议可能是笨拙的,但你依然应该递交这些报告,它们很重要。其中一些报告将导致产品改进,除此之外,别无他法。
人命关天的软件
在某些条件下,编程人员或他们的经理如果违背标准化的方法是绝对不能接受的。核反应堆的控制程序必须文档齐备,并得到彻底地详细说明,仅在精确计算之后方可进行变更。如果发生了失误,测试文档将是非常重要的法律证据。像这样的项目,负担得起大批质量保证人员和巨大的测试预算。对于这种项目的质量保证人员,测试方面的其他书籍比本书更适合他们。
已经有很多很好的书在讲授有高可靠性要求的软件产品的测试方法。人命关天的和金融领域的应用程序,事先都得到了详细的定义和设计,质量保证和测试活动的经费充足,软件测试人员能够完全接触系统源代码,并有充分的时间阅读它们。在这样的前提下,这些书籍介绍了如何进行完整的软件测试工作。
计算行业的大多数人,包括个人计算机业的绝大部分人,都在努力开发有用且可靠的软件产品,但这些软件并不要求很高的可靠性。就像买车你可以选性能良好的经济型轿车或中档轿车一样,大多数的程序不必成为劳斯莱斯(而且大多数人是买不起劳斯莱斯的)。消费软件、普通商务软件、学术研究软件和个人软件的开发人员的测试预算相当有限,时间紧迫,人手短缺,然而很多程序却具有令人满意的质量。他们是如何做到的呢?本书介绍了其中的测试工作部分。
书不能解决全部问题
有些书认为,如果一个软件项目没有得到“合理”的控制,书面规格说明始终没有完成且不是最新的,代码没有依据所谓流行的方法进行适当组织的话,那么必须要努力做到。这些书讲到的测试是建立在每个人都依据“规定”行事的基础之上的。
本书介绍的测试,假定的前提是你的同伴现在没有、将来也不会并且也没必要遵循这些规定。
消费软件项目通常的特点是,预算非常有限、人手非常少、交付时间非常紧迫而且不可能推迟、开发人员之间拥有共同的认识和承诺。
大型软件产品的质量掌握在那些负责设计、编程、测试、撰写文档的个人手上,每个人都很重要。无论是标准、规格说明、指导/协调委员会和变更控制都不能保证质量,软件公司也没有指望它们起到这样的作用。能够确保软件质量的,是个人追求卓越的承诺、熟练使用工具的技巧和协同工作的能力,而不是这些规定。
开发小组对所要创建的东西有了认识,对尽可能实现梦想达成了承诺,并且意识到不得不通过试验和错误来充实这些细节。当产品某一部分的所有细节工作都完成时,他们会形成一个只有一两个人能完全理解的工作说明。这个说明就是所谓的“规格说明”。“规格说明”并不是刻在石头上一成不变的,随后会被评审和修正,以便与系统其他部分保持一致。大多数的修正是根据软件测试人员的建议进行的。
在现实世界中,产品变更一般发生在开发阶段的后期。当你正开发一个公开发售的软件产品时,你的客户或潜在客户不一定会同意你的设计。如果竞争对手开发出更具吸引力的产品,你要马上作出反应。
由于没有时间实现,预想的功能往往被取消掉。代码重写也被搁置一边,即使是需要完成这些代码重写工作把勉勉强强提交的第一版本改得稍微专业一些。认真负责的程序员也许会自觉地,甚至是“偷偷地”完成这项工作。在项目的后期,他可能在没有通知其他任何人的情况下对软件包做了重要修改。这些努力是在每周40小时工作时间之外完成的,可能会极大地改进软件质量,但也可能使软件质量变得极其糟糕。不管结果如何,软件质量的改进是通过个人的积极性来实现的。
后期的变更是不可避免的。我们的目标是尽可能平稳地来处理这些必要的变更。我们不打算建立什么规章制度来抑制变更的产生。作为测试人员,你如果处理不好变更,就会有麻烦。解决之道不在于单纯抱怨或是竭力阻止它们。
本书的读者对象
本书的读者对象是从事软件测试且常常测试他人代码的人员。我们认为所选主题和讨论水平反映了读者感兴趣或对读者有益处的内容。因此我们摒弃某些学术性内容(如程序正确性证明),讨论通常在测试教科书中并未强调的内容。例如,我们经常谈论到人际关系和企业文化问题。连最初级的软件测试人员也必须评判他人的工作—这就是测试工作的根本。在将他们的判断与别人进行交流的过程中,测试人员容易受到指责(有时也是“罪有应得”)。他们工作的重要程度往往与其地位不相称,从而导致他们容易成为人际矛盾的靶子或替罪羊。我们没有办法解决其地位问题,但我们确实提出了一些建议来提高测试效率和避免某些陷阱。
我们也讨论项目管理问题。软件测试的估算、计划和时间安排很棘手,因为软件测试没有真正的终点,测试总是没完没了,如果不做就会有更多的风险。每个测试人员都必须明白这种平衡关系。他们需要安排时间来充分考虑这些因素。例如,某个测试人员可能为了更好地完成其他任务而推迟了重要的测试,但是,后来发现由于时间已用完,再也无法进行这些测试了。本打算将工作做得更好,却弄巧成拙。这种情况很常见,而且非常令人沮丧。因此,优先级和效率是本书主要关注的问题。
测试人员还要处理设计错误。按照糟糕的规格说明实现的程序,其质量必定是糟糕的。大多数有关软件可靠性和测试的书籍没有涉及用户界面,而将其作为人为因素分析员的工作范围。我们不同意这种观点。(我们之中就有一位人为因素分析专家,他也不赞同。)系统的可靠性取决于其各部分是如何协同工作的,包括使用它的人员在内。
作为测试人员,你的任务是发现并指出产品中存在的问题,为改进产品质量服务。无论问题的源头出在何处,关于人-机系统可靠性差的报告都是适当和重要的。你是少数几个能在产品发布前详细检验整个产品的人之一。还有哪些地方能产生这种反馈呢?
我们对用户界面问题的讨论并不能让你成为专家,你仍然会遗漏很多重要问题。你的一些设计建议可能是笨拙的,但你依然应该递交这些报告,它们很重要。其中一些报告将导致产品改进,除此之外,别无他法。
人命关天的软件
在某些条件下,编程人员或他们的经理如果违背标准化的方法是绝对不能接受的。核反应堆的控制程序必须文档齐备,并得到彻底地详细说明,仅在精确计算之后方可进行变更。如果发生了失误,测试文档将是非常重要的法律证据。像这样的项目,负担得起大批质量保证人员和巨大的测试预算。对于这种项目的质量保证人员,测试方面的其他书籍比本书更适合他们。








点击看大图





加载中...

