![软件测试：经验与教训[图书]](http://images.china-pub.com/ebook10000-15000/14718/zcover.jpg)
（已有16条评价）
基本信息
- 原书名：Lessons Learned in Software Testing
- 原出版社： John Wiley & sons,Inc.
- 作者： （美）Cem Kaner,James Bach,Bret Pettichord
- 译者： 韩柯
- 丛书名： 软件工程技术丛书/测试系列
- 出版社：机械工业出版社
- ISBN：9787111129752
- 上架时间：2003-10-29
- 出版日期：2004 年1月
- 开本：16开
- 页码：234
- 版次：1-1
- 所属分类：计算机 > 软件工程及软件方法学 > 软件质量、软件测试及维护
编辑推荐
作者结合自己丰富的软件测试实验经验，大胆地对软件测试界很多人多年来鼓吹的所谓实践、关键活动、甚至国际标准进行了深刻的反思，令人信服地提出了自己的观点，对一些关键问题做了哲学思考，内容涉及与软件测试有关的各个方面，很适合有一定实际经验的软件测试、项目管理、软件开发、软件工程等方面的工程技术人员阅读。
内容简介
书籍
计算机书籍
本书汇总了293条来自软件测试界顶尖专家的经验与建议，阐述了如何做好测试工作、如何管理测试，以及如何澄清有关软件测试的常见误解，读者可直接将这些建议用于自己的测试项目工作中。这些经验中的每一条都是与软件测试有关的一个观点，观点后面是针对运用该测试经验的方法、时机和原因的解释或例子。
本书还提供了有关如何将本书提供的经验有选择性地运用到读者实际项目环境中的建议，在所有关键问题上所积累的经验，以及基于多年的测试经验总结出的有用实践和问题评估方法。
优秀的软件测试团队不是天生的，而是造就的，是通过大量艰苦工作和有效沟通造就的。在这个过程中，有很多陷阱，这些陷阱会使精心制订的计划出现偏差，使项目不能按进度完成。
本书的三位作者具有多年的测试经验，知道成功的测试都需要什么。在这本革命性的新书中，他们汇总了293条测试经验建议，阐述了如何做好测试工作，如何管理测试，以及如何澄清有关软件测试的常见误解。读者可直接将这些经验用于自己的测试工作中。这些经验中的每一条都是与软件测试有关的一个观点，后面是对运用这条经验的方法、时机和原因的解释或例子。
为了满足不同层次的软件测试员、开发人员和管理人员的需要，本书还提供以下内容：
◆ 根据世界顶级软件测试专家多年的测试经验总结出的有用实践和问题评估方法。
◆ 在所有关键问题上积累的经验，包括测试设计、测试自动化、测试管理、测试策略和错误报告。
◆ 如何将本书提供的经验有选择性地运用到实际项目环境中的建议。
计算机书籍
本书汇总了293条来自软件测试界顶尖专家的经验与建议，阐述了如何做好测试工作、如何管理测试，以及如何澄清有关软件测试的常见误解，读者可直接将这些建议用于自己的测试项目工作中。这些经验中的每一条都是与软件测试有关的一个观点，观点后面是针对运用该测试经验的方法、时机和原因的解释或例子。
本书还提供了有关如何将本书提供的经验有选择性地运用到读者实际项目环境中的建议，在所有关键问题上所积累的经验，以及基于多年的测试经验总结出的有用实践和问题评估方法。
优秀的软件测试团队不是天生的，而是造就的，是通过大量艰苦工作和有效沟通造就的。在这个过程中，有很多陷阱，这些陷阱会使精心制订的计划出现偏差，使项目不能按进度完成。
本书的三位作者具有多年的测试经验，知道成功的测试都需要什么。在这本革命性的新书中，他们汇总了293条测试经验建议，阐述了如何做好测试工作，如何管理测试，以及如何澄清有关软件测试的常见误解。读者可直接将这些经验用于自己的测试工作中。这些经验中的每一条都是与软件测试有关的一个观点，后面是对运用这条经验的方法、时机和原因的解释或例子。
为了满足不同层次的软件测试员、开发人员和管理人员的需要，本书还提供以下内容：
◆ 根据世界顶级软件测试专家多年的测试经验总结出的有用实践和问题评估方法。
◆ 在所有关键问题上积累的经验，包括测试设计、测试自动化、测试管理、测试策略和错误报告。
◆ 如何将本书提供的经验有选择性地运用到实际项目环境中的建议。
作译者
Cem Kaner是美国佛罗里达技术学院的教授，同时为软件开发界提供技术和管理等方面的咨询工作。他
是世界级的测试技术权威，《Testing Computer Software》(中文版即将由机械工业出版社出版)和《Bad
Software》这两本书的第一作者。
James Bach是Satisfice公司创始人和首席顾问，这是一家软件测试和质量保证公司。他具有在顶级硅谷
公司(例如苹果和Borland公司)从事软件开发的经验，这使他在“足够好的”质量、基于风险的测试、探索
测试和其他对技能和判断能力要求很高的技术等方面拥有丰富经验。他还是软件测试实验室的首席科学家。
Bret Pettichord是独立顾问，并为www．testinghotlist．com编辑很流行的“软件测试活动表”。他经常演讲并发表文章，并且还是测试自动化Austin研讨会的创始人。
是世界级的测试技术权威，《Testing Computer Software》(中文版即将由机械工业出版社出版)和《Bad
Software》这两本书的第一作者。
James Bach是Satisfice公司创始人和首席顾问，这是一家软件测试和质量保证公司。他具有在顶级硅谷
公司(例如苹果和Borland公司)从事软件开发的经验，这使他在“足够好的”质量、基于风险的测试、探索
测试和其他对技能和判断能力要求很高的技术等方面拥有丰富经验。他还是软件测试实验室的首席科学家。
Bret Pettichord是独立顾问，并为www．testinghotlist．com编辑很流行的“软件测试活动表”。他经常演讲并发表文章，并且还是测试自动化Austin研讨会的创始人。
目录
译者序
序
前言
致谢
第1章 测试员的角色 1
经验1：测试员是项目的前灯 1
经验2：测试员的使命决定要做
的一切 2
经验3：测试员为很多客户服务 3
经验4：测试员发现的信息会
“打扰”客户 4
经验5：迅速找出重要程序问题 4
经验6：跟着程序员走 5
经验7：询问一切，但不一定外露 5
经验8：测试员关注失效，客户才能
关注成功 5
经验9：不会发现所有程序问题 6
经验10：当心“完备的”测试 6
经验11：通过测试不能保证质量 7
经验12：永远别做看门人 7
序
前言
致谢
第1章 测试员的角色 1
经验1：测试员是项目的前灯 1
经验2：测试员的使命决定要做
的一切 2
经验3：测试员为很多客户服务 3
经验4：测试员发现的信息会
“打扰”客户 4
经验5：迅速找出重要程序问题 4
经验6：跟着程序员走 5
经验7：询问一切，但不一定外露 5
经验8：测试员关注失效，客户才能
关注成功 5
经验9：不会发现所有程序问题 6
经验10：当心“完备的”测试 6
经验11：通过测试不能保证质量 7
经验12：永远别做看门人 7
译者序
应该承认，这是一本很吸引人的书。它的精彩之处在于它使各类软件测试人员，甚至是与测试人员打交道的人，都能得到很好的启发；在于它能够引导读者对自己在实际工作中的得与失做比较全面的思考，重新审视过去很多深信不疑的软件测试规则；在于它直接面对令大家感到困惑的问题，从更实际的角度进行诠释。
作者结合自己丰富的软件测试实践经验，大胆地对软件测试界很多人多年来鼓吹的所谓最佳实践、关键活动、甚至国际标准进行了深刻的反思，令人信服地提出了自己的观点，对一些关键问题做了哲学思考，内容涉及与软件测试有关的各个方面，很适合有一定实际经验的软件测试、项目管理、软件开发、软件工程等方面的工程技术人员阅读。
在翻译过程中，我们力求忠实原文。但由于译者的知识水平和实际工作经验有限，不当之处在所难免，恳请读者批评指正。参加本书翻译、审校和其他辅助工作的还有：原小铃、李津津、王威、屈健、黄惠菊、韩文臣、朱军、杜蔚轩、解冀海、付程、孟海军、耿民、王强等。
译 者
作者结合自己丰富的软件测试实践经验，大胆地对软件测试界很多人多年来鼓吹的所谓最佳实践、关键活动、甚至国际标准进行了深刻的反思，令人信服地提出了自己的观点，对一些关键问题做了哲学思考，内容涉及与软件测试有关的各个方面，很适合有一定实际经验的软件测试、项目管理、软件开发、软件工程等方面的工程技术人员阅读。
在翻译过程中，我们力求忠实原文。但由于译者的知识水平和实际工作经验有限，不当之处在所难免，恳请读者批评指正。参加本书翻译、审校和其他辅助工作的还有：原小铃、李津津、王威、屈健、黄惠菊、韩文臣、朱军、杜蔚轩、解冀海、付程、孟海军、耿民、王强等。
译 者
前言
提出软件工程知识体系（Software Engineering Body of Knowledge，SWEBOK）的目标是为颁发政府执照、规范软件工程师以及开设软件工程大学课程提供一种恰当的基础。SWEBOK文件声称以大部分人的意见为基础，希望这样的文件能够包容这个领域已经积累的知识和智慧（已经积累的经验教训）。
有关探索式测试，SWEBOK只有如下的叙述：
也许，最广泛采用的手段还仍然是专门定制的测试，即依靠测试员的技能和直觉（“探索”测试），依靠测试员在类似工程上积累的经验所导出的测试。虽然人们建议采用更系统化的方法，但是专门定制测试方法对于确定形式化手段不能轻易“捕获”的特殊测试用例还是很有用的（但是只有当这些测试员都是真正专家的时候）。此外还必须指出，这种手段的有效性会有大幅度的变动（SWEBOK 0.95，2001，第5~9页）。
SWEBOK怎样看待这种在测试领域中被最广泛地采用的手段呢？它丝毫没有涉及这种手段的使用方法，只是说应该由真正专家进行探索，建议使用其他方法，认为其他形式化的手段会使有效性更加稳定。
哈！
我们并不打算向读者正式描述反映测试领域大多数人观点的所谓知识体系，但是我们确实要大量谈论这个领域中最常见的实践。本书不是要排斥探索式测试，而是要站在使用探索法（以及很多其他方法）在现实条件下达到最佳测试效果的人员立场上，来描述测试应该是怎样的。
欢迎阅读本书
本书是我们实际软件开发经验的总结。我们几个人加起来已经有了50~60年的开发经验（当然这要看怎样计算了），其间，我们既看到了大量出色的工作，也看到了大量不那么出色的工作。
本书并不打算讨论软件工程在更有规则、更受控的环境中怎样运用，而是要讨论我们所要面对的现实世界。
在我们的世界中，软件开发团队常常要在时间很紧张的情况下工作，要在探索该做什么的同时，探索该怎样做。所使用的方法，有时比较正式，有时就不那么正式。这取决于千差万别的实际环境。
我们采用的是软件测试中的语境驱动法（context-driven approach）。我们认为在某些环境中很有效的方法，在另外一些环境中就没有效果。我们不谈论最佳实践，而是谈论最适合当前特定环境的实践。本书的最后要讨论语境驱动法，但是从本质上看，语境驱动的测试要从“谁”、“什么时候”、“哪里”、“为什么”和“如果这样会出现什么”五个方面，来研究测试的“内涵”（手段、工具、策略等）。
我们的目标是将所选择的实践与当前具体环境匹配起来，以取得理想的测试效果。我们不认为通过接管项目，或通过跺着脚告诉项目经理（或执行经理）“真正的专业人士”该怎样管理项目，就能够取得理想的测试效果；不认为通过强迫程序员，或通过奉承他们，就能够取得理想的测试效果；不认为通过填写数以千计的小卡片（或对应的电子记录），或通过在没有必要的过程上浪费其他所有人的时间，就能够干好测试工作。
我们并没有严格的条条框框，也没有理想化的有关测试的灵丹妙药。
这种灵丹妙药根本就不存在！
我们认为好的测试包括要求具有很高技能的技术工作（搜索缺陷）和准确、有说服力的沟通。
技艺高超的搜索毕竟也是一种探索。有无限多的测试工作要做，但是只有少量时间，只能完成其中很小一部分测试。要完成的每个测试，要写的每份文档，要参加的每个会议，都要占用可能会发现关键缺陷的测试时间。面对这种限制，我们要优化测试过程，以便充分利用不断积累的产品及产品市场、产品应用和产品弱点等方面的知识。我们今天所学的知识，会在明天更好的测试中体现出来。即使：
?产品被相当完备地描述。
?规格说明准确地反映了需求文档。
?需求文档准确地表达了产品项目相关人员的实际需要。
（读者是否确实见过具备所有这些条件的项目），我们在测试这样的产品时，仍然会学到很多这种产品的测试方法。具体地说，当发现错误时，我们知道这组程序员会犯怎样的错误。规格说明告诉我们，程序如果编写正确，应该怎样完成功能，但是不会告诉我们预期会出现的错误，也不会说明应该如何设计测试以发现这些错误。对于这件关键工作，我们要从头至尾地在一个项目中逐渐改进，一个项目一个项目地逐渐改进。
有关探索式测试，SWEBOK只有如下的叙述：
也许，最广泛采用的手段还仍然是专门定制的测试，即依靠测试员的技能和直觉（“探索”测试），依靠测试员在类似工程上积累的经验所导出的测试。虽然人们建议采用更系统化的方法，但是专门定制测试方法对于确定形式化手段不能轻易“捕获”的特殊测试用例还是很有用的（但是只有当这些测试员都是真正专家的时候）。此外还必须指出，这种手段的有效性会有大幅度的变动（SWEBOK 0.95，2001，第5~9页）。
SWEBOK怎样看待这种在测试领域中被最广泛地采用的手段呢？它丝毫没有涉及这种手段的使用方法，只是说应该由真正专家进行探索，建议使用其他方法，认为其他形式化的手段会使有效性更加稳定。
哈！
我们并不打算向读者正式描述反映测试领域大多数人观点的所谓知识体系，但是我们确实要大量谈论这个领域中最常见的实践。本书不是要排斥探索式测试，而是要站在使用探索法（以及很多其他方法）在现实条件下达到最佳测试效果的人员立场上，来描述测试应该是怎样的。
欢迎阅读本书
本书是我们实际软件开发经验的总结。我们几个人加起来已经有了50~60年的开发经验（当然这要看怎样计算了），其间，我们既看到了大量出色的工作，也看到了大量不那么出色的工作。
本书并不打算讨论软件工程在更有规则、更受控的环境中怎样运用，而是要讨论我们所要面对的现实世界。
在我们的世界中，软件开发团队常常要在时间很紧张的情况下工作，要在探索该做什么的同时，探索该怎样做。所使用的方法，有时比较正式，有时就不那么正式。这取决于千差万别的实际环境。
我们采用的是软件测试中的语境驱动法（context-driven approach）。我们认为在某些环境中很有效的方法，在另外一些环境中就没有效果。我们不谈论最佳实践，而是谈论最适合当前特定环境的实践。本书的最后要讨论语境驱动法，但是从本质上看，语境驱动的测试要从“谁”、“什么时候”、“哪里”、“为什么”和“如果这样会出现什么”五个方面，来研究测试的“内涵”（手段、工具、策略等）。
我们的目标是将所选择的实践与当前具体环境匹配起来，以取得理想的测试效果。我们不认为通过接管项目，或通过跺着脚告诉项目经理（或执行经理）“真正的专业人士”该怎样管理项目，就能够取得理想的测试效果；不认为通过强迫程序员，或通过奉承他们，就能够取得理想的测试效果；不认为通过填写数以千计的小卡片（或对应的电子记录），或通过在没有必要的过程上浪费其他所有人的时间，就能够干好测试工作。
我们并没有严格的条条框框，也没有理想化的有关测试的灵丹妙药。
这种灵丹妙药根本就不存在！
我们认为好的测试包括要求具有很高技能的技术工作（搜索缺陷）和准确、有说服力的沟通。
技艺高超的搜索毕竟也是一种探索。有无限多的测试工作要做，但是只有少量时间，只能完成其中很小一部分测试。要完成的每个测试，要写的每份文档，要参加的每个会议，都要占用可能会发现关键缺陷的测试时间。面对这种限制，我们要优化测试过程，以便充分利用不断积累的产品及产品市场、产品应用和产品弱点等方面的知识。我们今天所学的知识，会在明天更好的测试中体现出来。即使：
?产品被相当完备地描述。
?规格说明准确地反映了需求文档。
?需求文档准确地表达了产品项目相关人员的实际需要。
（读者是否确实见过具备所有这些条件的项目），我们在测试这样的产品时，仍然会学到很多这种产品的测试方法。具体地说，当发现错误时，我们知道这组程序员会犯怎样的错误。规格说明告诉我们，程序如果编写正确，应该怎样完成功能，但是不会告诉我们预期会出现的错误，也不会说明应该如何设计测试以发现这些错误。对于这件关键工作，我们要从头至尾地在一个项目中逐渐改进，一个项目一个项目地逐渐改进。
序言
请想像自己拿着一瓶50年的陈年波尔多红葡萄酒。这里有一种品味的方法，虽然这并不是惟一的方法，但是有多年饮用波尔多经验的人大都会发现，有些经验有助于更好地享用波尔多。以下就给出几条经验：
经验1：不要直接用瓶子喝。如果没有玻璃杯，也没有其他可用的容器，可把少量波尔多倒在自己的手掌中吸吮。在吸吮的同时，应该嗅一嗅波尔多的芳香，让波尔多在舌头上来回流动，不要一口咽下。
经验2：不要整瓶喝下去。如果喝波尔多是为了解渴，那么还是请把波尔多放下，而喝一大杯水吧。每次饮用少量的波尔多，会使整瓶波尔多带来的享受达到极致。
经验3：不要污染波尔多。如果有人建议尝试一下用橙汁、海水和波尔多勾兑的鸡尾酒，那么请礼貌地拒绝他，带着绚烂的微笑说：“可是我想享用的是一杯波尔多。”
经验4：不要独贪波尔多。把波尔多藏起来，就意味着再也不能享受一边与朋友轻松地闲谈，一边品味波尔多的乐趣。波尔多最好还是与喜欢来一杯的朋友共享。请记住，他们可能也会有一瓶波尔多。
读者手中拿的并不是一瓶波尔多，而是本书，这是一本有关软件测试的非常有价值的专著。它通过作者多年经验的酿造，已经至善至纯。波尔多是你味觉感官的朋友，而本书则是你头脑的朋友。我想读者还会发现其他值得注意的差别。我已经体验了本书，并总结出以下经验，希望这些经验能够帮助读者通过本书得到最大收益。
经验1：不要直接用瓶子喝。阅读本书时要带上自己的容器。也就是说，带上自己所有的软件开发和测试经验。如果读者从来没有参加过正式的软件开发工作，则本书对你可能度数太高了。它会使你头晕，在一段时间内浑身无力。如果读者有一定的经验，则可以结合自己项目背景，享用本书的内容。
经验2：不要整瓶喝下去。不要一口气把它读完。读上一两条经验，合上书，想想你对Kaner、Bach和Pettichord的话有何反应。读者会发现，他们把自己的方法叫作“语境驱动”的测试。只有读者才会知道自己工作的背景，必须靠自己确定本书所给出的经验在哪些方面适合自己的具体工作。
经验3：不要污染波尔多。有人要为本书的293条经验加上标题，并制成表。但愿读者没有这种想法。本书的核心是每条经验的解释。还要当心有人会立即尝试把本书内容ISO化或CMM化。我现在可以看到“使用这本书将达到CMM第293级”这样的文章标题。哈！正如作者所说：“……我们不相信‘最佳实践’，我们相信在一定条件下，一些实践比另一些更有用。”这些话代表了达到软件测试大师级专家境界的思想精华。
经验4：不要独贪波尔多。如果有什么书要和同事一起读的话，本书就是。买上一箱，送给搞测试或管理测试员的人每人一本。一次有选择性地读上几条经验，然后聚在一起边讨论，边喝咖啡、吃午餐，甚至享用波尔多！阅读、反思、享受。来，干杯！
Tim Lister
美国纽约市
大西洋系统协会
2001年8月17日
lister@acm.org
经验1：不要直接用瓶子喝。如果没有玻璃杯，也没有其他可用的容器，可把少量波尔多倒在自己的手掌中吸吮。在吸吮的同时，应该嗅一嗅波尔多的芳香，让波尔多在舌头上来回流动，不要一口咽下。
经验2：不要整瓶喝下去。如果喝波尔多是为了解渴，那么还是请把波尔多放下，而喝一大杯水吧。每次饮用少量的波尔多，会使整瓶波尔多带来的享受达到极致。
经验3：不要污染波尔多。如果有人建议尝试一下用橙汁、海水和波尔多勾兑的鸡尾酒，那么请礼貌地拒绝他，带着绚烂的微笑说：“可是我想享用的是一杯波尔多。”
经验4：不要独贪波尔多。把波尔多藏起来，就意味着再也不能享受一边与朋友轻松地闲谈，一边品味波尔多的乐趣。波尔多最好还是与喜欢来一杯的朋友共享。请记住，他们可能也会有一瓶波尔多。
读者手中拿的并不是一瓶波尔多，而是本书，这是一本有关软件测试的非常有价值的专著。它通过作者多年经验的酿造，已经至善至纯。波尔多是你味觉感官的朋友，而本书则是你头脑的朋友。我想读者还会发现其他值得注意的差别。我已经体验了本书，并总结出以下经验，希望这些经验能够帮助读者通过本书得到最大收益。
经验1：不要直接用瓶子喝。阅读本书时要带上自己的容器。也就是说，带上自己所有的软件开发和测试经验。如果读者从来没有参加过正式的软件开发工作，则本书对你可能度数太高了。它会使你头晕，在一段时间内浑身无力。如果读者有一定的经验，则可以结合自己项目背景，享用本书的内容。
经验2：不要整瓶喝下去。不要一口气把它读完。读上一两条经验，合上书，想想你对Kaner、Bach和Pettichord的话有何反应。读者会发现，他们把自己的方法叫作“语境驱动”的测试。只有读者才会知道自己工作的背景，必须靠自己确定本书所给出的经验在哪些方面适合自己的具体工作。
经验3：不要污染波尔多。有人要为本书的293条经验加上标题，并制成表。但愿读者没有这种想法。本书的核心是每条经验的解释。还要当心有人会立即尝试把本书内容ISO化或CMM化。我现在可以看到“使用这本书将达到CMM第293级”这样的文章标题。哈！正如作者所说：“……我们不相信‘最佳实践’，我们相信在一定条件下，一些实践比另一些更有用。”这些话代表了达到软件测试大师级专家境界的思想精华。
经验4：不要独贪波尔多。如果有什么书要和同事一起读的话，本书就是。买上一箱，送给搞测试或管理测试员的人每人一本。一次有选择性地读上几条经验，然后聚在一起边讨论，边喝咖啡、吃午餐，甚至享用波尔多！阅读、反思、享受。来，干杯！
Tim Lister
美国纽约市
大西洋系统协会
2001年8月17日
lister@acm.org
