有效软件测试
[绝版]基本信息
- 原书名: Effective Software Testing
- 原出版社: Addison Wesley/Pearson
- 作者: [美]Elfriede Dustin [作译者介绍]
- 译者: 新语
- 丛书名: 软件工程实践丛书
- 出版社:清华大学出版社
- ISBN:730206945X
- 上架时间:2003-8-29
- 出版日期:2003 年8月
- 开本:16开
- 页码:200
- 版次:1-1
- 所属分类:
计算机 > 软件工程及软件方法学 > 软件质量、软件测试及维护
教材 > 研究生/本科/专科教材 > 工学 > 计算机
教材 > 计算机教材 > 本科/研究生 > 计算机专业教材 > 计算机专业课程 > 软件工程
内容简介回到顶部↑
[b][font color="#ff0000"]原版进口[/font][/b] [a href="http://www.china-pub.com/computers/common/info.asp?id=13403" target="_blank"]effective
software testing: 50 ways to improve your software testing[/a]
本书分为10个部分,每一部分自成体系,详细系统地讲述了50条最好的软件测试实践经验,这10个部分大致和软件生命周期的各个阶段相对应。本书的内容涵盖了从有关过程和管理的内容到技术方面的话题。
书中内容并不局限于任何特定的技术和应用程序平台。
本书适用于质量保证人员、软件测试人员、测试组长和测试经理等阅读,也可供项目经理和软件开发人员参考。
本书分为10个部分,每一部分自成体系,详细系统地讲述了50条最好的软件测试实践经验,这10个部分大致和软件生命周期的各个阶段相对应。本书的内容涵盖了从有关过程和管理的内容到技术方面的话题。
书中内容并不局限于任何特定的技术和应用程序平台。
本书适用于质量保证人员、软件测试人员、测试组长和测试经理等阅读,也可供项目经理和软件开发人员参考。
作译者回到顶部↑
本书提供作译者介绍
Elfriede Dustin是软件质量和测试领域世界一流的权威之一。她是《自动化软件测试》(Automated Software Testing)和《高质量的Web系统》Quality Web Systems) 这两本著作的第一著者,是软件工程和测试实践领域公认的专家,她帮助许多公司定义并实现了QA和测试过程。
.. << 查看详细
.. << 查看详细
目录回到顶部↑
第1章 需求阶段
第1条:测试人员及早介入
第2条:验证需求
第3条:需求就绪后马上设计测试过程
第4条:确保需求变化的传达
第5条:注意在现存系统上进行开发和测试
第2章 编制测试计划
第6条:了解手头的任务和相关的测试目标
第7条:考虑风险
第8条:根据功能优先级安排测试工作
第9条:牢记软件方面的问题
第10条:获得有效的测试数据
第11条:规划测试环境
第12条:估计测试准备和执行所需的时间
第3章 测试组
第13条:定义角色和职责
第14条:测试技巧、行业知识和经验三者缺一不可
第15条:评估测试人员的有效性
第4章 系统构架
第16条:了解系统构架和基本组件
第1条:测试人员及早介入
第2条:验证需求
第3条:需求就绪后马上设计测试过程
第4条:确保需求变化的传达
第5条:注意在现存系统上进行开发和测试
第2章 编制测试计划
第6条:了解手头的任务和相关的测试目标
第7条:考虑风险
第8条:根据功能优先级安排测试工作
第9条:牢记软件方面的问题
第10条:获得有效的测试数据
第11条:规划测试环境
第12条:估计测试准备和执行所需的时间
第3章 测试组
第13条:定义角色和职责
第14条:测试技巧、行业知识和经验三者缺一不可
第15条:评估测试人员的有效性
第4章 系统构架
第16条:了解系统构架和基本组件
译者序回到顶部↑
我曾经在国内一家知名的软件企业工作了8年,在此期间一直是核心项目组的成员之一。我们负责开发一个专业性很强、技术含量很高的产品,这一点和本书中提到的财务系统有些接近。虽然我并没有真正从事过软件测试工作,但是作为一名开发人员,经常需要和测试人员打交道,所以我有机会感受到了测试工作乃至整个软件工程环境的变化。
这家企业的软件工程环境的发展大体可以分为3个阶段:精英软件工程环境我刚进入这家公司时,计算机工业在中国处于超高速发展期,这个行业的待遇和福利相对较高。而且当时计算机还没有现在这么普及,计算机行业对于普通的大学毕业生来说充满了神秘感和吸引力。
我们公司的前身是一所国内著名大学的校办产业,创业者基本上都是这所学校的职工。当时有相当部分的员工一个人有两个身份,既是公司的职员,又是学校内某个部门的职工。因此在项目开发中不可避免地继承了一些学校办事的风格,例如:重技术、轻管理。
我刚进公司的时候,企业仍然保持着强劲的上升势头,虽然规模不大,但是效益很好。职工的进取心也很强。
当时我们公司的主要用户是一些大客户,这些大客户的共性很强(从后来的结果来看,他们对产品的功能需求非常片面,所以对开发人员和测试人员的行业知识要求不高)。并且当时卖方市场的竞争不激烈,用户对产品质量的要求也不是太高。
由于以上的大环境、小环境和其他一些因素,当时的软件工程环境有以下一些突出特点:
● 人员素质很高。无论是开发人员还是测试人员大都是名牌大学的优秀毕业生。
● 开发人员和测试人员都不是行业专家。
● 校园文化对企业文化影响至深,现代企业制度不完善,制度的执行也缺乏力度。
当时负责我们项目测试工作的测试人员一共有3位,个个都是以一当十的强人。虽然他们缺乏基本的行业背景,对计算机技术也缺乏了解,但是由于他们的素质很高,学习能力很强,再加上当时对行业知识和计算机技术的要求不高,所以他们很快就掌握了测试工作所需的各种知识和技术。
虽然当时制度有漏洞,但是由于企业的小环境很好,职工大都责任感很强,所以不完善的制度并没有过多地影响开发、测试工作。
测试人员的高素质特别体现在当他们再次从事同一产品的后续版本的测试工作时,尽管他们并没有正式的渠道了解软件技术、软件结构,但是通过与开发人员的非正式交流和经验,他们已经能够猜到哪些部分容易出问题,并且一旦某个问题暴露了以后,他们立刻会想到哪些地方也可能出现类似的问题。因此测试效率比较高。
从现在的观点来看,当时的软件工程环境的最大问题是非"结构化"的。但是职工出色的个人能力和敬业精神在很大程度上弥补了制度上的不足。标准化的软件工程环境
随着时间的推移,企业的扩张,第一代测试人员由于种种原因,有的走上了领导岗位,有的转向其他性质的工作(可能是厌倦了测试工作吧),公司迎来了第二批测试人员。要求也不是那么高了,他们的专业素质和个人素质与第一代测试人员相比有所下降。由于这些人毕业时间较晚,所以他们的知识结构和第一代职工有一定的差异,但对软件工程有了比较系统的认识。
企业为了发展,需要拓展产品的生存空间。与此同时,国外的产品开始进入国内市场,市场竞争日趋激烈。我们的产品在新市场上遇到了挫折,用户不再总是唱颂歌,而是开始有了不少的抱怨。在这种背景下,我们公司出现了第一次有关软件工程环境的激烈争论,争论的主题是:谁应该为软件产品的质量负责?
整个事件的导火索是在一次产品会议中,一位技术骨干对测试负责人说:"产品的质量出了问题,全部是测试部门的责任。"而测试负责人显然对软件工程的理论有一定的了解,所以当然对这个在软件工程领域中常见的错误观点给予了猛烈的反驳。会议以后,争论的方式改成了邮件,并且相继有多人加入了讨论的行列。在争论渐渐平息之后,公司开发部门的总负责人认为这个讨论很好,于是把经过多人多次回复的邮件转发给所有开发人员和测试人员,当时邮件的总长度可能已经超过了一万字。
此时企业的规模几乎达到了顶峰,在经营上也开始出现了一些不好的苗头:经过了多年的高速发展,增长的速度已经放缓,员工创业的激情逐渐消退;市场竞争开始加剧,公司的利润率开始下降。各种内忧外患使得公司高层忧心忡忡,他们迫切地想找到一条企业发展的长久之计。与此同时,国家开始推广现代企业制度,并且在政策上给予了强有力的支持。最终公司高层决定实施IS09000标准。
IS09000的实施在客观上极大地提高了测试部门的地位,系统测试的重要程度也达到了一个前所未有的高度。产品的测试报告可以决定一个项目的命运,可以一票否决一个产品的发行。
此阶段软件工程环境的特点是:
● 初步建立了标准化的软件工程环境。
这家企业的软件工程环境的发展大体可以分为3个阶段:精英软件工程环境我刚进入这家公司时,计算机工业在中国处于超高速发展期,这个行业的待遇和福利相对较高。而且当时计算机还没有现在这么普及,计算机行业对于普通的大学毕业生来说充满了神秘感和吸引力。
我们公司的前身是一所国内著名大学的校办产业,创业者基本上都是这所学校的职工。当时有相当部分的员工一个人有两个身份,既是公司的职员,又是学校内某个部门的职工。因此在项目开发中不可避免地继承了一些学校办事的风格,例如:重技术、轻管理。
我刚进公司的时候,企业仍然保持着强劲的上升势头,虽然规模不大,但是效益很好。职工的进取心也很强。
当时我们公司的主要用户是一些大客户,这些大客户的共性很强(从后来的结果来看,他们对产品的功能需求非常片面,所以对开发人员和测试人员的行业知识要求不高)。并且当时卖方市场的竞争不激烈,用户对产品质量的要求也不是太高。
由于以上的大环境、小环境和其他一些因素,当时的软件工程环境有以下一些突出特点:
● 人员素质很高。无论是开发人员还是测试人员大都是名牌大学的优秀毕业生。
● 开发人员和测试人员都不是行业专家。
● 校园文化对企业文化影响至深,现代企业制度不完善,制度的执行也缺乏力度。
当时负责我们项目测试工作的测试人员一共有3位,个个都是以一当十的强人。虽然他们缺乏基本的行业背景,对计算机技术也缺乏了解,但是由于他们的素质很高,学习能力很强,再加上当时对行业知识和计算机技术的要求不高,所以他们很快就掌握了测试工作所需的各种知识和技术。
虽然当时制度有漏洞,但是由于企业的小环境很好,职工大都责任感很强,所以不完善的制度并没有过多地影响开发、测试工作。
测试人员的高素质特别体现在当他们再次从事同一产品的后续版本的测试工作时,尽管他们并没有正式的渠道了解软件技术、软件结构,但是通过与开发人员的非正式交流和经验,他们已经能够猜到哪些部分容易出问题,并且一旦某个问题暴露了以后,他们立刻会想到哪些地方也可能出现类似的问题。因此测试效率比较高。
从现在的观点来看,当时的软件工程环境的最大问题是非"结构化"的。但是职工出色的个人能力和敬业精神在很大程度上弥补了制度上的不足。标准化的软件工程环境
随着时间的推移,企业的扩张,第一代测试人员由于种种原因,有的走上了领导岗位,有的转向其他性质的工作(可能是厌倦了测试工作吧),公司迎来了第二批测试人员。要求也不是那么高了,他们的专业素质和个人素质与第一代测试人员相比有所下降。由于这些人毕业时间较晚,所以他们的知识结构和第一代职工有一定的差异,但对软件工程有了比较系统的认识。
企业为了发展,需要拓展产品的生存空间。与此同时,国外的产品开始进入国内市场,市场竞争日趋激烈。我们的产品在新市场上遇到了挫折,用户不再总是唱颂歌,而是开始有了不少的抱怨。在这种背景下,我们公司出现了第一次有关软件工程环境的激烈争论,争论的主题是:谁应该为软件产品的质量负责?
整个事件的导火索是在一次产品会议中,一位技术骨干对测试负责人说:"产品的质量出了问题,全部是测试部门的责任。"而测试负责人显然对软件工程的理论有一定的了解,所以当然对这个在软件工程领域中常见的错误观点给予了猛烈的反驳。会议以后,争论的方式改成了邮件,并且相继有多人加入了讨论的行列。在争论渐渐平息之后,公司开发部门的总负责人认为这个讨论很好,于是把经过多人多次回复的邮件转发给所有开发人员和测试人员,当时邮件的总长度可能已经超过了一万字。
此时企业的规模几乎达到了顶峰,在经营上也开始出现了一些不好的苗头:经过了多年的高速发展,增长的速度已经放缓,员工创业的激情逐渐消退;市场竞争开始加剧,公司的利润率开始下降。各种内忧外患使得公司高层忧心忡忡,他们迫切地想找到一条企业发展的长久之计。与此同时,国家开始推广现代企业制度,并且在政策上给予了强有力的支持。最终公司高层决定实施IS09000标准。
IS09000的实施在客观上极大地提高了测试部门的地位,系统测试的重要程度也达到了一个前所未有的高度。产品的测试报告可以决定一个项目的命运,可以一票否决一个产品的发行。
此阶段软件工程环境的特点是:
● 初步建立了标准化的软件工程环境。
前言回到顶部↑
在大多数软件开发组织中,测试工作是应用程序的最后一道"质量关",它允许或者拒绝应用程序从理想的软件工程环境进入真实的现实世界。伴随着这个角色的是巨大的责任;应用程序的成功、甚至可能是组织成功的赌注全部押在软件产品的质量上。
众多小规模的测试任务必须由测试组来完成和管理,事实上,由于测试任务的数量过多,所以测试工作关注的只是测试一个应用软件的功能,很少顾及测试工作需要的外围工作。获得合适的测试数据、应用程序需求和构架的可测试性、适当的测试过程标准和文档,以及硬件和设备等诸如此类的问题即便不是没有考虑,也往往会到项目生命周期的后期才予以考虑。对于规模较大的项目,单纯使用测试脚本和测试工具是不够的,大多数有经验的软件测试人员都会认同这一点。
一般情况下,我们只有通过具体实践才能熟知使测试工作从头到尾都获得成功所需要的各个环节的有关知识。在项目生命周期中,如果某些任务完成得早,那么测试工作的效率就会高得多,这是一条有价值的经验。当然,在我们意识到这一点时,当前的项目通常已不可能从这条经验中获益了。
本书提供了一些实践经验和关键理念,组织可以利用这些实践和理念成功地实现有效的测试工作。本书的目的是为读者提供各种经过精心挑选的技术和建议,软件从业人员能够直接用它们来改进产品,同时也能避免损失惨重的过失和疏忽。本书详述了50条最好的软件测试实践,分为10部分进行讲述,这10部分大致和软件生命周期的各个阶段相对应。这种结构本身就阐述了软件测试工作中一个关键理念;为了获得最大的有效性,测试工作必须完全融入软件开发过程。我们必须避免把测试工作当成"项目流程"中一个独立的步骤(在软件开发周期的最后阶段),这是一个很常见的错误。
本书的内容涵盖了从有关过程和管理的内容(例如:管理变化的需求和测试组的构成)到技术方面的话题(例如:提升系统可测试性的方法和把单元测试融入开发过程)。虽然在需要的地方本书中也出现了一些伪代码,但是本书的内容并不局限于任何特定的技术和应用程序平台。
但是,还有很多测试工作以外的因素也会强烈地影响项目的成败,认识到这一点非常重要。虽然包含测试工作在内的完整软件开发过程会确保与软件工程有关的工作成功,但是所有项目还要处理有关商业用例、预算、时间表和组织文化方面的问题。在某些情况下,这些问题会和高效的工程环境的需要发生冲突。应用本书中的建议的前提是:为了测试工作的成功,组织能够适应测试工作的需要,并且为这些需要提供支持。
本书的组织结构
本书由50个独立的条目组成,它们覆盖了10个重要的方面。这些经过挑选的最优实践出现的顺序和系统开发生命周期的各个阶段的先后顺序一致。
读者可以了条接一条、一章接一章地顺序阅读本书。当需要获得或者了解有关一个特殊问题的信息时,也可以直接跳到特定的条目。虽然在每一章中会引用其他章节或者其他书籍的内容,它们会有助于向读者提供更多的信息,但是每一章的内容基本上是自成体系的。
第1章描述了测试工作在需求阶段需要考虑的问题。在需求阶段,包括测试组代表在内的所有涉众必须参与需求工作,并且必须收到需求变更通知,这是非常重要的。此外,对于任何大型项目来说,基于需求开发测试用例都是一个最基本的理念。测试组参与此阶段工作的重要性怎么强调都不过分,只有在这个阶段才能获得对系统和它的需求的全面理解。
第2章描述了测试规划活动,其中包括:对测试工作目标的了解方法,确定测试策略的方法,以及有关数据、环境和软件本身需要考虑的问题。在软件生命周期中,规划工作必须及早开始,这是因为我们需要为成功地实施测试工作预留时间。及早规划使得我们可以对测试进度和预算进行估计,并且使之获得批准和加入整个软件开发计划。我们必须不断地监控这些估计,并且和实际情况进行比较,这样就可以根据需要对它们进行修正,并且实现预期的目标。
第3章主要讨论测试组的人员构成。所有成功的测试工作的核心是执行它的人。一个成功的测试组需要同时具备技术和行业两方面的知识,还要有结构化和简明的角色与职责划分。为了确保测试工作成功完成,在整个测试过程中,必须不断地评估每个测试组成员的有效性。
第4章讨论了有关测试系统构架方面的考虑。为了保证系统本身是可以测试的、能够进行灰箱测试和有效进行缺陷诊断,考虑这些因素是非常重要的,但是它们经常被忽视。
第5章详细描述了如何有效地设计和开发测试过程,其中包括在测试创建和文档化方面需要考虑的问题,还讨论了最有效的测试技术。随着时间的推移和系统开发迭代的继续,需求和设计会不断精化,因此测试过程也要不断精化,它们需要加入新的和修改后的需求以及系统功能。
第6章讨论了在整个测试策略中,开发人员进行单元测试所扮演的角色。在实现阶段中,单元测试会显著地提高软件质量。如果全面地执行了单元测试,以后的测试阶段会更成功。但是,基于对问题的了解的、随意的单元测试和基于系统需求的、结构化的、可重复的单元测试是有区别的。
第7章讲解了有关自动测试工具的问题,其中包括:在项目中使用恰当的工具类型、有关定制开发还是购买的决定和为组织选择恰当的工具需要考虑的因素。本章描述了多种类型的测试工具,它们可以用于开发生命周期的各个阶段。此外,本章还讲到了开发定制工具方面的问题。
第8章讨论了为自动测试选择最佳实践方面的问题。本章描述了如何正确地运用记录/回放工具、自制测试工具和回归测试。
第9章提供了测试一个应用软件非功能性方面的信息。如果满足了应用程序的非功能性需求(包括性能、安全性、可使用性、兼容性和并发性测试),那么会提升应用程序的整体质量。
第10章提供了测试执行的管理策略,其中包括:追踪测试过程执行和缺陷生命周期的正确方法以及收集用于估计测试进程的度量。
本书面向的读者
众多小规模的测试任务必须由测试组来完成和管理,事实上,由于测试任务的数量过多,所以测试工作关注的只是测试一个应用软件的功能,很少顾及测试工作需要的外围工作。获得合适的测试数据、应用程序需求和构架的可测试性、适当的测试过程标准和文档,以及硬件和设备等诸如此类的问题即便不是没有考虑,也往往会到项目生命周期的后期才予以考虑。对于规模较大的项目,单纯使用测试脚本和测试工具是不够的,大多数有经验的软件测试人员都会认同这一点。
一般情况下,我们只有通过具体实践才能熟知使测试工作从头到尾都获得成功所需要的各个环节的有关知识。在项目生命周期中,如果某些任务完成得早,那么测试工作的效率就会高得多,这是一条有价值的经验。当然,在我们意识到这一点时,当前的项目通常已不可能从这条经验中获益了。
本书提供了一些实践经验和关键理念,组织可以利用这些实践和理念成功地实现有效的测试工作。本书的目的是为读者提供各种经过精心挑选的技术和建议,软件从业人员能够直接用它们来改进产品,同时也能避免损失惨重的过失和疏忽。本书详述了50条最好的软件测试实践,分为10部分进行讲述,这10部分大致和软件生命周期的各个阶段相对应。这种结构本身就阐述了软件测试工作中一个关键理念;为了获得最大的有效性,测试工作必须完全融入软件开发过程。我们必须避免把测试工作当成"项目流程"中一个独立的步骤(在软件开发周期的最后阶段),这是一个很常见的错误。
本书的内容涵盖了从有关过程和管理的内容(例如:管理变化的需求和测试组的构成)到技术方面的话题(例如:提升系统可测试性的方法和把单元测试融入开发过程)。虽然在需要的地方本书中也出现了一些伪代码,但是本书的内容并不局限于任何特定的技术和应用程序平台。
但是,还有很多测试工作以外的因素也会强烈地影响项目的成败,认识到这一点非常重要。虽然包含测试工作在内的完整软件开发过程会确保与软件工程有关的工作成功,但是所有项目还要处理有关商业用例、预算、时间表和组织文化方面的问题。在某些情况下,这些问题会和高效的工程环境的需要发生冲突。应用本书中的建议的前提是:为了测试工作的成功,组织能够适应测试工作的需要,并且为这些需要提供支持。
本书的组织结构
本书由50个独立的条目组成,它们覆盖了10个重要的方面。这些经过挑选的最优实践出现的顺序和系统开发生命周期的各个阶段的先后顺序一致。
读者可以了条接一条、一章接一章地顺序阅读本书。当需要获得或者了解有关一个特殊问题的信息时,也可以直接跳到特定的条目。虽然在每一章中会引用其他章节或者其他书籍的内容,它们会有助于向读者提供更多的信息,但是每一章的内容基本上是自成体系的。
第1章描述了测试工作在需求阶段需要考虑的问题。在需求阶段,包括测试组代表在内的所有涉众必须参与需求工作,并且必须收到需求变更通知,这是非常重要的。此外,对于任何大型项目来说,基于需求开发测试用例都是一个最基本的理念。测试组参与此阶段工作的重要性怎么强调都不过分,只有在这个阶段才能获得对系统和它的需求的全面理解。
第2章描述了测试规划活动,其中包括:对测试工作目标的了解方法,确定测试策略的方法,以及有关数据、环境和软件本身需要考虑的问题。在软件生命周期中,规划工作必须及早开始,这是因为我们需要为成功地实施测试工作预留时间。及早规划使得我们可以对测试进度和预算进行估计,并且使之获得批准和加入整个软件开发计划。我们必须不断地监控这些估计,并且和实际情况进行比较,这样就可以根据需要对它们进行修正,并且实现预期的目标。
第3章主要讨论测试组的人员构成。所有成功的测试工作的核心是执行它的人。一个成功的测试组需要同时具备技术和行业两方面的知识,还要有结构化和简明的角色与职责划分。为了确保测试工作成功完成,在整个测试过程中,必须不断地评估每个测试组成员的有效性。
第4章讨论了有关测试系统构架方面的考虑。为了保证系统本身是可以测试的、能够进行灰箱测试和有效进行缺陷诊断,考虑这些因素是非常重要的,但是它们经常被忽视。
第5章详细描述了如何有效地设计和开发测试过程,其中包括在测试创建和文档化方面需要考虑的问题,还讨论了最有效的测试技术。随着时间的推移和系统开发迭代的继续,需求和设计会不断精化,因此测试过程也要不断精化,它们需要加入新的和修改后的需求以及系统功能。
第6章讨论了在整个测试策略中,开发人员进行单元测试所扮演的角色。在实现阶段中,单元测试会显著地提高软件质量。如果全面地执行了单元测试,以后的测试阶段会更成功。但是,基于对问题的了解的、随意的单元测试和基于系统需求的、结构化的、可重复的单元测试是有区别的。
第7章讲解了有关自动测试工具的问题,其中包括:在项目中使用恰当的工具类型、有关定制开发还是购买的决定和为组织选择恰当的工具需要考虑的因素。本章描述了多种类型的测试工具,它们可以用于开发生命周期的各个阶段。此外,本章还讲到了开发定制工具方面的问题。
第8章讨论了为自动测试选择最佳实践方面的问题。本章描述了如何正确地运用记录/回放工具、自制测试工具和回归测试。
第9章提供了测试一个应用软件非功能性方面的信息。如果满足了应用程序的非功能性需求(包括性能、安全性、可使用性、兼容性和并发性测试),那么会提升应用程序的整体质量。
第10章提供了测试执行的管理策略,其中包括:追踪测试过程执行和缺陷生命周期的正确方法以及收集用于估计测试进程的度量。
本书面向的读者








点击看大图





加载中...

