探索式软件测试
点击看大图基本信息
- 原书名： Exploratory Software Testing: Tips, Tricks, Tours, and Techniques to Guide Test Design
- 原出版社： Addison-Wesley Professional
- 作者： (美)James A. Whittaker [作译者介绍]
- 译者： 方敏 张胜 钟颂东 郭艳春
- 出版社：清华大学出版社
- ISBN：9787302223849
- 上架时间：2010-5-12
- 出版日期：2010 年4月
- 开本：16开
- 页码：230
- 版次：1-1
- 所属分类：
计算机 > 软件工程及软件方法学 > 软件质量、软件测试及维护
编辑推荐
相约James Whittaker和微软资深测试团队，分享软件测试艺术和智慧
软件测试专家James Whittaker新著
妙趣横生，网罗测试技术、提示和秘笈
独辟蹊径，巧用隐喻解释软件测试艺术
真知灼见，准确、精辟地揭示测试玄机
内容简介回到顶部↑
谈论软件质量的方法有很多，感兴趣的听众也有很多。本书是为软件测试人员而写的，写的是一种我认为比其他任何缺陷都重要的特殊缺陷：即逃过所有各种检测手段而最终存在于发布产品中的缺陷。
任何一个软件公司发布的产品都有缺陷。缺陷是怎么引入的？为什么没有在代码审核、单元测试、静态分析或其他面向开发人员的活动中把它们找出来？为什么自动化测试没有找出它们？那些缺陷有些什么特质使其能逃过手工测试？
什么是找出产品缺陷的最好方法？
本书针对的正是最后一个问题。在第2章“手工测试”中，我提出了一个观点：因为用户是在使用软件过程中找到这些缺陷的，所以我们的测试人员也应该通过使用软件来找到它们。无论使用自动化测试和单元测试，还是其他一些手段，都难以接触到这些缺陷。无论测试人员怎么实现自动化测试，即使全部都自动化，这些缺陷还是会处处作怪，并在产品中屡屡重现从而伤害最终用户。
问题在于很多现代化手工测试实践都缺乏目的性，随机性强且重复性强。有些人可能还会加上一条：手工测试无聊透顶。本书试图为手工测试流程提供一些指导、技术和规划。
在第3章“局部探索式测试法”中，针对测试人员在运行任何一个测试用例时都需要做出很多细微的战术层面决定，我给出了详尽的指导建议。测试人员必须决定对于某个特定的输入字段应该使用什么输入值，或者给应用程序使用的文件提供什么数据。在测试过程中，必须做出许多这样的小决定。在缺乏指导的情况下，这些决定常常是未经分析且不是最优化的。在向一个文本框内输入一个数时，选择整数4难道就胜过整数400么？应该用长度为32字节的字符串还是长度为256字节的字符串？选择一个而不选另一个是有一定道理的，这一切都取决于处理该输入的软件的具体情况。鉴于测试人员每天都要做出数百次这样的小决定，在这里提供有效的指导建议显得至关重要。
在第4章“全局探索式测试法”中，针对测试人员在编制测试计划和测试用例设计时需要考虑哪些广泛的战略性问题，我也给出了一些指导建议。这些技术都基于“漫游测试”（tour）概念，如同一个导游带领旅游团队参观大都市中一系列著名景点一样，这种漫游测试法指出的路线可以指导测试人员如何探索软件的方方面面。这里的探索并不一定是随机的或者漫无目的的。本书所记录的方法已经成为微软和谷歌的许多测试人员日常工作的一部分。诸如“地标测试法”（landmark tour）和“极限测试法”（intellectual’s tour）等词汇已经列入了手工测试人员的标准词汇表中。测试技术以前确实被称作“漫游”，但是用整个旅游业来隐喻软件测试，并在测试实际发布的应用程序时，大规模使用这些隐喻的名称，还属于本书的一个创举。
全局探索式测试法对于制定完整的测试策略给出了指导建议。例如，如何创建一组特性覆盖率（feature coverage）较高的测试用例？如何确定是否要在一个单独的测试用例中使用多个特性？如何创建一个完整的测试用例套件（test case suite），从而使软件尽可能地满负荷工作以便能找到更多重要的缺陷？这些都是设计测试用例和保证测试套件质量时必须解决的重大问题。
在第5章“混合探索测试技术”中，通过把探索式测试和传统的脚本或基于场景的测试技术相结合，进一步扩展了漫游的概念。我们将讨论如何修改各种端到端场景（end-to-end scenario）、测试脚本（test script）或用户故事（user story），来创造更多的变化情况，以激发传统静态测试技术查找缺陷的潜力。
在第6章“探索式测试的实际应用”中，来自微软不同产品组的五位客串作者提供了他们使用漫游技术后得到的经验报告。这些作者和他们的团队在真实的开发环境中，把漫游方法应用在真实的软件上。他们记录了各自是如何使用漫游、修改漫游甚至创建自己的漫游的。这些内容来自于使用漫游法测试重要的关键软件产品的测试人员，属于真正的第一手资料。
最后，我用两章内容总结前面各章所讨论的内容。在第7章“漫游测试的棘手问题”中，描述了我认为的测试中最困难的几个问题，以及如何将那些具有高度针对性的探索式测试方法融入一个更广泛的解决方案中。在第8章“软件测试的未来”中，我更进一步讨论在未来几年中，诸如虚拟化、可视化甚至电视游戏之类的技术将如何改变测试的面貌。附录包括我对测试职业生涯的看法，收集了我以前一些深受读者喜爱的文章（加入了一些新的注解），其中一些文章已经无法在其他地方看到了。
写这本书对我来说是一种享受，我希望你阅读本书也是一种享受。
任何一个软件公司发布的产品都有缺陷。缺陷是怎么引入的？为什么没有在代码审核、单元测试、静态分析或其他面向开发人员的活动中把它们找出来？为什么自动化测试没有找出它们？那些缺陷有些什么特质使其能逃过手工测试？
什么是找出产品缺陷的最好方法？
本书针对的正是最后一个问题。在第2章“手工测试”中，我提出了一个观点：因为用户是在使用软件过程中找到这些缺陷的，所以我们的测试人员也应该通过使用软件来找到它们。无论使用自动化测试和单元测试，还是其他一些手段，都难以接触到这些缺陷。无论测试人员怎么实现自动化测试，即使全部都自动化，这些缺陷还是会处处作怪，并在产品中屡屡重现从而伤害最终用户。
问题在于很多现代化手工测试实践都缺乏目的性，随机性强且重复性强。有些人可能还会加上一条：手工测试无聊透顶。本书试图为手工测试流程提供一些指导、技术和规划。
在第3章“局部探索式测试法”中，针对测试人员在运行任何一个测试用例时都需要做出很多细微的战术层面决定，我给出了详尽的指导建议。测试人员必须决定对于某个特定的输入字段应该使用什么输入值，或者给应用程序使用的文件提供什么数据。在测试过程中，必须做出许多这样的小决定。在缺乏指导的情况下，这些决定常常是未经分析且不是最优化的。在向一个文本框内输入一个数时，选择整数4难道就胜过整数400么？应该用长度为32字节的字符串还是长度为256字节的字符串？选择一个而不选另一个是有一定道理的，这一切都取决于处理该输入的软件的具体情况。鉴于测试人员每天都要做出数百次这样的小决定，在这里提供有效的指导建议显得至关重要。
在第4章“全局探索式测试法”中，针对测试人员在编制测试计划和测试用例设计时需要考虑哪些广泛的战略性问题，我也给出了一些指导建议。这些技术都基于“漫游测试”（tour）概念，如同一个导游带领旅游团队参观大都市中一系列著名景点一样，这种漫游测试法指出的路线可以指导测试人员如何探索软件的方方面面。这里的探索并不一定是随机的或者漫无目的的。本书所记录的方法已经成为微软和谷歌的许多测试人员日常工作的一部分。诸如“地标测试法”（landmark tour）和“极限测试法”（intellectual’s tour）等词汇已经列入了手工测试人员的标准词汇表中。测试技术以前确实被称作“漫游”，但是用整个旅游业来隐喻软件测试，并在测试实际发布的应用程序时，大规模使用这些隐喻的名称，还属于本书的一个创举。
全局探索式测试法对于制定完整的测试策略给出了指导建议。例如，如何创建一组特性覆盖率（feature coverage）较高的测试用例？如何确定是否要在一个单独的测试用例中使用多个特性？如何创建一个完整的测试用例套件（test case suite），从而使软件尽可能地满负荷工作以便能找到更多重要的缺陷？这些都是设计测试用例和保证测试套件质量时必须解决的重大问题。
在第5章“混合探索测试技术”中，通过把探索式测试和传统的脚本或基于场景的测试技术相结合，进一步扩展了漫游的概念。我们将讨论如何修改各种端到端场景（end-to-end scenario）、测试脚本（test script）或用户故事（user story），来创造更多的变化情况，以激发传统静态测试技术查找缺陷的潜力。
在第6章“探索式测试的实际应用”中，来自微软不同产品组的五位客串作者提供了他们使用漫游技术后得到的经验报告。这些作者和他们的团队在真实的开发环境中，把漫游方法应用在真实的软件上。他们记录了各自是如何使用漫游、修改漫游甚至创建自己的漫游的。这些内容来自于使用漫游法测试重要的关键软件产品的测试人员，属于真正的第一手资料。
最后，我用两章内容总结前面各章所讨论的内容。在第7章“漫游测试的棘手问题”中，描述了我认为的测试中最困难的几个问题，以及如何将那些具有高度针对性的探索式测试方法融入一个更广泛的解决方案中。在第8章“软件测试的未来”中，我更进一步讨论在未来几年中，诸如虚拟化、可视化甚至电视游戏之类的技术将如何改变测试的面貌。附录包括我对测试职业生涯的看法，收集了我以前一些深受读者喜爱的文章（加入了一些新的注解），其中一些文章已经无法在其他地方看到了。
写这本书对我来说是一种享受，我希望你阅读本书也是一种享受。
作译者回到顶部↑
本书提供作译者介绍
詹姆斯·惠特克（James Whittaker）的全部职业生涯都致力于软件测试，在该学科的许多方面都留下了他的印记。他是基于模型的测试领域的先驱，他在田纳西大学的博士学位论文是该主题的标准参考资料。他在错误注入（error injection）方面的工作，创造了备受欢迎的运行时错误注入工具Holodeck。他是软件安全和渗透测试（penetration testing）的早期创导者。作为教师和演讲者，他也为人们称道，他曾在国际会议上赢得过多个最佳论文和最佳演讲奖。在佛罗里达技术学院担任教授期间，他的软件测试课程吸引.. << 查看详细
目录回到顶部↑
第1章软件质量 1
软件的魔力 1
软件失效 4
小结 9
练习题 9
第2章手工测试 11
软件缺陷的根源 11
缺陷预防和检测 12
缺陷预防 12
缺陷检测 13
手工测试 15
手工测试中使用脚本 16
探索式测试 16
小结 21
练习题 21
第3章局部探索式测试法 23
想不想测试软件？ 23
测试就是有所变，有所不变 25
用户输入 26
状态 36
软件的魔力 1
软件失效 4
小结 9
练习题 9
第2章手工测试 11
软件缺陷的根源 11
缺陷预防和检测 12
缺陷预防 12
缺陷检测 13
手工测试 15
手工测试中使用脚本 16
探索式测试 16
小结 21
练习题 21
第3章局部探索式测试法 23
想不想测试软件？ 23
测试就是有所变，有所不变 25
用户输入 26
状态 36
前言回到顶部↑
“用户购买功能的同时也在忍受缺陷。”
——史考特·沃兹沃思(Scott Wadsworth)
任何一个使用过电脑的人都知道软件故障。从最初的第一个程序到最新的现代应用程序，软件从来没有完美过。
将来这一切也多半不会改变。不只是软件开发错综复杂和开发人员容易犯错的天性，还有硬件、操作系统、运行时环境、驱动程序、平台、数据库等不断变化，这些加在一起使软件开发任务成为全人类最让人称奇的专业技能之一。
不过，仅仅令人称奇是不够的，正如本书第1章指出的那样，这个世界还要求软件拥有高质量。
显然，关心质量不只是软件测试人员的事。我们应该用正确的方式构建软件，将可靠性、安全性和高性能等作为系统设计的一部分来考虑，而不是到开发末期才想起它们。然而，说到理解软件缺陷的本质，测试人员总是站在前沿。如果没有测试人员在测试的最前沿发挥他们的洞察力、技术以及应变措施，使这样的可能性变为现实，软件质量的全面解决方案差不多算是“镜中花，水中月”。
谈论软件质量的方法有很多，感兴趣的听众也有很多。本书是为软件测试人员而写的，写的是一种我认为比其他任何缺陷都重要的特殊缺陷：即逃过所有各种检测手段而最终存在于发布产品中的缺陷。
任何一个软件公司发布的产品都有缺陷。缺陷是怎么引入的？为什么没有在代码审核、单元测试、静态分析或其他面向开发人员的活动中把它们找出来？为什么自动化测试没有找出它们？那些缺陷有些什么特质使其能逃过手工测试？
什么是找出产品缺陷的最好方法？
本书针对的正是最后一个问题。在第2章“手工测试”中，我提出了一个观点：因为用户是在使用软件过程中找到这些缺陷的，所以我们的测试人员也应该通过使用软件来找到它们。无论使用自动化测试和单元测试，还是其他一些手段，都难以接触到这些缺陷。无论测试人员怎么实现自动化测试，即使全部都自动化，这些缺陷还是会处处作怪，并在产品中屡屡重现从而伤害最终用户。
问题在于很多现代化手工测试实践都缺乏目的性，随机性强且重复性强。有些人可能还会加上一条：手工测试无聊透顶。本书试图为手工测试流程提供一些指导、技术和规划。
在第3章“局部探索式测试法”中，针对测试人员在运行任何一个测试用例时都需要做出很多细微的战术层面决定，我给出了详尽的指导建议。测试人员必须决定对于某个特定的输入字段应该使用什么输入值，或者给应用程序使用的文件提供什么数据。在测试过程中，必须做出许多这样的小决定。在缺乏指导的情况下，这些决定常常是未经分析且不是最优化的。在向一个文本框内输入一个数时，选择整数4难道就胜过整数400么？应该用长度为32字节的字符串还是长度为256字节的字符串？选择一个而不选另一个是有一定道理的，这一切都取决于处理该输入的软件的具体情况。鉴于测试人员每天都要做出数百次这样的小决定，在这里提供有效的指导建议显得至关重要。
在第4章“全局探索式测试法”中，针对测试人员在编制测试计划和测试用例设计时需要考虑哪些广泛的战略性问题，我也给出了一些指导建议。这些技术都基于“漫游测试”(tour)概念，如同一个导游带领旅游团队参观大都市中一系列著名景点一样，这种漫游测试法指出的路线可以指导测试人员如何探索软件的方方面面。这里的探索并不一定是随机的或者漫无目的的。本书所记录的方法已经成为微软和谷歌的许多测试人员日常工作的一部分。诸如“地标测试法”(landmark tour)和“极限测试法”(intellectual’s tour)等词汇已经列入了手工测试人员的标准词汇表中。测试技术以前确实被称作“漫游”，但是用整个旅游业来隐喻软件测试，并在测试实际发布的应用程序时，大规模使用这些隐喻的名称，还属于本书的一个创举。
全局探索式测试法对于制定完整的测试策略给出了指导建议。例如，如何创建一组特性覆盖率(feature coverage)较高的测试用例？如何确定是否要在一个单独的测试用例中使用多个特性？如何创建一个完整的测试用例套件(test case suite)，从而使软件尽可能地满负荷工作以便能找到更多重要的缺陷？这些都是设计测试用例和保证测试套件质量时必须解决的重大问题。
在第5章“混合探索测试技术”中，通过把探索式测试和传统的脚本或基于场景的测试技术相结合，进一步扩展了漫游的概念。我们将讨论如何修改各种端到端场景(end-to-end scenario)、测试脚本(test script)或用户故事(user story)，来创造更多的变化情况，以激发传统静态测试技术查找缺陷的潜力。
在第6章“探索式测试的实际应用”中，来自微软不同产品组的五位客串作者提供了他们使用漫游技术后得到的经验报告。这些作者和他们的团队在真实的开发环境中，把漫游方法应用在真实的软件上。他们记录了各自是如何使用漫游、修改漫游甚至创建自己的漫游的。这些内容来自于使用漫游法测试重要的关键软件产品的测试人员，属于真正的第一手资料。
最后，我用两章内容总结前面各章所讨论的内容。在第7章“漫游测试的棘手问题”中，描述了我认为的测试中最困难的几个问题，以及如何将那些具有高度针对性的探索式测试方法融入一个更广泛的解决方案中。在第8章“软件测试的未来”中，我更进一步讨论在未来几年中，诸如虚拟化、可视化甚至电视游戏之类的技术将如何改变测试的面貌。附录包括我对测试职业生涯的看法，收集了我以前一些深受读者喜爱的文章(加入了一些新的注解)，其中一些文章已经无法在其他地方看到了。
写这本书对我来说是一种享受，我希望你阅读本书也是一种享受。
——史考特·沃兹沃思(Scott Wadsworth)
任何一个使用过电脑的人都知道软件故障。从最初的第一个程序到最新的现代应用程序，软件从来没有完美过。
将来这一切也多半不会改变。不只是软件开发错综复杂和开发人员容易犯错的天性，还有硬件、操作系统、运行时环境、驱动程序、平台、数据库等不断变化，这些加在一起使软件开发任务成为全人类最让人称奇的专业技能之一。
不过，仅仅令人称奇是不够的，正如本书第1章指出的那样，这个世界还要求软件拥有高质量。
显然，关心质量不只是软件测试人员的事。我们应该用正确的方式构建软件，将可靠性、安全性和高性能等作为系统设计的一部分来考虑，而不是到开发末期才想起它们。然而，说到理解软件缺陷的本质，测试人员总是站在前沿。如果没有测试人员在测试的最前沿发挥他们的洞察力、技术以及应变措施，使这样的可能性变为现实，软件质量的全面解决方案差不多算是“镜中花，水中月”。
谈论软件质量的方法有很多，感兴趣的听众也有很多。本书是为软件测试人员而写的，写的是一种我认为比其他任何缺陷都重要的特殊缺陷：即逃过所有各种检测手段而最终存在于发布产品中的缺陷。
任何一个软件公司发布的产品都有缺陷。缺陷是怎么引入的？为什么没有在代码审核、单元测试、静态分析或其他面向开发人员的活动中把它们找出来？为什么自动化测试没有找出它们？那些缺陷有些什么特质使其能逃过手工测试？
什么是找出产品缺陷的最好方法？
本书针对的正是最后一个问题。在第2章“手工测试”中，我提出了一个观点：因为用户是在使用软件过程中找到这些缺陷的，所以我们的测试人员也应该通过使用软件来找到它们。无论使用自动化测试和单元测试，还是其他一些手段，都难以接触到这些缺陷。无论测试人员怎么实现自动化测试，即使全部都自动化，这些缺陷还是会处处作怪，并在产品中屡屡重现从而伤害最终用户。
问题在于很多现代化手工测试实践都缺乏目的性，随机性强且重复性强。有些人可能还会加上一条：手工测试无聊透顶。本书试图为手工测试流程提供一些指导、技术和规划。
在第3章“局部探索式测试法”中，针对测试人员在运行任何一个测试用例时都需要做出很多细微的战术层面决定，我给出了详尽的指导建议。测试人员必须决定对于某个特定的输入字段应该使用什么输入值，或者给应用程序使用的文件提供什么数据。在测试过程中，必须做出许多这样的小决定。在缺乏指导的情况下，这些决定常常是未经分析且不是最优化的。在向一个文本框内输入一个数时，选择整数4难道就胜过整数400么？应该用长度为32字节的字符串还是长度为256字节的字符串？选择一个而不选另一个是有一定道理的，这一切都取决于处理该输入的软件的具体情况。鉴于测试人员每天都要做出数百次这样的小决定，在这里提供有效的指导建议显得至关重要。
在第4章“全局探索式测试法”中，针对测试人员在编制测试计划和测试用例设计时需要考虑哪些广泛的战略性问题，我也给出了一些指导建议。这些技术都基于“漫游测试”(tour)概念，如同一个导游带领旅游团队参观大都市中一系列著名景点一样，这种漫游测试法指出的路线可以指导测试人员如何探索软件的方方面面。这里的探索并不一定是随机的或者漫无目的的。本书所记录的方法已经成为微软和谷歌的许多测试人员日常工作的一部分。诸如“地标测试法”(landmark tour)和“极限测试法”(intellectual’s tour)等词汇已经列入了手工测试人员的标准词汇表中。测试技术以前确实被称作“漫游”，但是用整个旅游业来隐喻软件测试，并在测试实际发布的应用程序时，大规模使用这些隐喻的名称，还属于本书的一个创举。
全局探索式测试法对于制定完整的测试策略给出了指导建议。例如，如何创建一组特性覆盖率(feature coverage)较高的测试用例？如何确定是否要在一个单独的测试用例中使用多个特性？如何创建一个完整的测试用例套件(test case suite)，从而使软件尽可能地满负荷工作以便能找到更多重要的缺陷？这些都是设计测试用例和保证测试套件质量时必须解决的重大问题。
在第5章“混合探索测试技术”中，通过把探索式测试和传统的脚本或基于场景的测试技术相结合，进一步扩展了漫游的概念。我们将讨论如何修改各种端到端场景(end-to-end scenario)、测试脚本(test script)或用户故事(user story)，来创造更多的变化情况，以激发传统静态测试技术查找缺陷的潜力。
在第6章“探索式测试的实际应用”中，来自微软不同产品组的五位客串作者提供了他们使用漫游技术后得到的经验报告。这些作者和他们的团队在真实的开发环境中，把漫游方法应用在真实的软件上。他们记录了各自是如何使用漫游、修改漫游甚至创建自己的漫游的。这些内容来自于使用漫游法测试重要的关键软件产品的测试人员，属于真正的第一手资料。
最后，我用两章内容总结前面各章所讨论的内容。在第7章“漫游测试的棘手问题”中，描述了我认为的测试中最困难的几个问题，以及如何将那些具有高度针对性的探索式测试方法融入一个更广泛的解决方案中。在第8章“软件测试的未来”中，我更进一步讨论在未来几年中，诸如虚拟化、可视化甚至电视游戏之类的技术将如何改变测试的面貌。附录包括我对测试职业生涯的看法，收集了我以前一些深受读者喜爱的文章(加入了一些新的注解)，其中一些文章已经无法在其他地方看到了。
写这本书对我来说是一种享受，我希望你阅读本书也是一种享受。
序言回到顶部↑
我第一次见到詹姆斯·惠特克(James Whittaker)是在几年前，当时他是佛罗里达技术学院(Florida Institute of Technology)的教授。他当时是访问了雷德蒙(Redmond)的微软公司园区，向一个测试工程师小组演讲他钟爱的课题——软件测试。从第一次见面起，我就明显地感受到James风趣的谈话风格和渊博的软件测试知识。多年的教学生涯使他很容易与那些好学者打成一片。
詹姆斯在2006年加入微软公司，在过去的三年中，我有机会和詹姆斯在一起工作很长时间，对他有了更深的了解。我可以高兴地告诉大家，他的幽默和善于与测试人员交流的能力继续在他的教学和交流方面起着关键性的作用。每一次我想找他谈话，几乎都看到他在与某个测试工程师或一个测试团队进行交流或正在鼓励他们。虽然我们在微软从来没有在同一个团队里工作过，但曾经有过很多机会在一起为跨公司的倡议而工作，共同负责为公司的新员工做演讲。(当然了，我所谓的“共同”意味着詹姆斯写演讲稿，而我剽窃他的幽默。)他在微软公司工作期间，我们真正进行的长时间交流还是发生在微软的足球场上。我们在过去三年里，大概一起度过了一百多个小时，把球传过来踢过去，同时还切磋和交流各种改进软件测试和开发的想法。
詹姆斯最重要的特点是，一旦有了新想法，他总想去检验并证明它。(哪个伟大的软件测试大师不这样？)他如此成功的原因是，他不怕失败，也敢于承认一些想法不成熟。也许我的测试本能使我比普通的测试人员更多疑，但是说起来，我还是觉得很高兴在过去的几年里，我曾经驳倒过詹姆斯的很多“伟大的想法”。詹姆斯教导他的学生时经常使用如下名言：“大多数伟大想法的背后是一片埋葬着不成熟想法的墓地。”这句话不无道理，一个成功的创新者必须谦虚谨慎。
由于我在微软公司的角色，我有机会看到无数充满创意的新点子，也亲历了很多点子。其中很多是富有潜力的优秀发明，但是由于发明者没能具体实现他的想法而最终失败了。随着詹姆斯和我更多的会面以及相互讨论测试想法，我有机会观察到他如何把几个想法有条不紊地开发成实际有用的创新成果。这些创新成果被真实的微软测试人员所采用。他为测试人员设计的“提示显示”(Tester’Heads Up Display)技术就是其中一个例子。这些想法最初在足球场上酝酿，在实践中优化，最终产生实际的用途——凭借这项技术，测试人员在工作时可以获得并使用实时测试数据。由于这项发明，微软公司为詹姆斯颁发了大奖，Visual Studio更有意要把这个概念用在其测试产品的未来版本上。
我亲身见证了詹姆斯设计出“漫游”这个隐喻(metaphor)来指导软件测试。他也许不是第一个谈论漫游的人，但他是我知道的第一个完整设计出漫游隐喻的人，他随后还指导了几十个测试团队将其成功地应用在真实的软件(非常复杂的软件)。他的漫游路径已从几条增加到几十条。他不断地开发和优化这些概念，直到它们变得完善。虽然詹姆斯提出的有些漫游并不成功，但是不用担心，詹姆斯敢于放弃那些想法，所以在这里就不再提及它们了。这本书里包括了软件测试漫游秘笈的全部工作。这些秘笈被检验过，修改过，然后再次被检验过。詹姆斯擅长以讲故事的方式来描述概念，这种能力在本书中表现得淋漓尽致。所以当我阅读这本优秀的软件测试书时，有时甚至不禁忘记它竟然是一本讲测试的书。虽然我弄不清在测试行为中使用隐喻为何会让漫游测试法变得这么有效，但是漫游技术在现实世界中表现得如此之好，我再怎么夸奖也不过分。这个概念太重要了，以致于微软已把“漫游测试法”加入专为新入职测试人员提供的技术培训课程。
如果你有兴趣提高自己的技能或者提高整个团队的技能，这本书会很有帮助。本书不仅生动有趣，更是一本可以常备手边供随时参考翻阅的手册。
微软卓越测试部门总监 阿伦·培智(Alan Page)
詹姆斯在2006年加入微软公司，在过去的三年中，我有机会和詹姆斯在一起工作很长时间，对他有了更深的了解。我可以高兴地告诉大家，他的幽默和善于与测试人员交流的能力继续在他的教学和交流方面起着关键性的作用。每一次我想找他谈话，几乎都看到他在与某个测试工程师或一个测试团队进行交流或正在鼓励他们。虽然我们在微软从来没有在同一个团队里工作过，但曾经有过很多机会在一起为跨公司的倡议而工作，共同负责为公司的新员工做演讲。(当然了，我所谓的“共同”意味着詹姆斯写演讲稿，而我剽窃他的幽默。)他在微软公司工作期间，我们真正进行的长时间交流还是发生在微软的足球场上。我们在过去三年里，大概一起度过了一百多个小时，把球传过来踢过去，同时还切磋和交流各种改进软件测试和开发的想法。
詹姆斯最重要的特点是，一旦有了新想法，他总想去检验并证明它。(哪个伟大的软件测试大师不这样？)他如此成功的原因是，他不怕失败，也敢于承认一些想法不成熟。也许我的测试本能使我比普通的测试人员更多疑，但是说起来，我还是觉得很高兴在过去的几年里，我曾经驳倒过詹姆斯的很多“伟大的想法”。詹姆斯教导他的学生时经常使用如下名言：“大多数伟大想法的背后是一片埋葬着不成熟想法的墓地。”这句话不无道理，一个成功的创新者必须谦虚谨慎。
由于我在微软公司的角色，我有机会看到无数充满创意的新点子，也亲历了很多点子。其中很多是富有潜力的优秀发明，但是由于发明者没能具体实现他的想法而最终失败了。随着詹姆斯和我更多的会面以及相互讨论测试想法，我有机会观察到他如何把几个想法有条不紊地开发成实际有用的创新成果。这些创新成果被真实的微软测试人员所采用。他为测试人员设计的“提示显示”(Tester’Heads Up Display)技术就是其中一个例子。这些想法最初在足球场上酝酿，在实践中优化，最终产生实际的用途——凭借这项技术，测试人员在工作时可以获得并使用实时测试数据。由于这项发明，微软公司为詹姆斯颁发了大奖，Visual Studio更有意要把这个概念用在其测试产品的未来版本上。
我亲身见证了詹姆斯设计出“漫游”这个隐喻(metaphor)来指导软件测试。他也许不是第一个谈论漫游的人，但他是我知道的第一个完整设计出漫游隐喻的人，他随后还指导了几十个测试团队将其成功地应用在真实的软件(非常复杂的软件)。他的漫游路径已从几条增加到几十条。他不断地开发和优化这些概念，直到它们变得完善。虽然詹姆斯提出的有些漫游并不成功，但是不用担心，詹姆斯敢于放弃那些想法，所以在这里就不再提及它们了。这本书里包括了软件测试漫游秘笈的全部工作。这些秘笈被检验过，修改过，然后再次被检验过。詹姆斯擅长以讲故事的方式来描述概念，这种能力在本书中表现得淋漓尽致。所以当我阅读这本优秀的软件测试书时，有时甚至不禁忘记它竟然是一本讲测试的书。虽然我弄不清在测试行为中使用隐喻为何会让漫游测试法变得这么有效，但是漫游技术在现实世界中表现得如此之好，我再怎么夸奖也不过分。这个概念太重要了，以致于微软已把“漫游测试法”加入专为新入职测试人员提供的技术培训课程。
如果你有兴趣提高自己的技能或者提高整个团队的技能，这本书会很有帮助。本书不仅生动有趣，更是一本可以常备手边供随时参考翻阅的手册。
微软卓越测试部门总监 阿伦·培智(Alan Page)
媒体评论回到顶部↑
“好书！Whittaker讲述的概念有创意、巧妙、令人印象深刻。他真正懂得如何鼓励工程师们以不同的角度考虑软件测试。”
——谷歌公司测试工程总监Patrick Copeland
“James把美妙的手工测试方法学提升到了极致。漫游不仅概念正确，而且实际应用得很好，我们已经在所有测试人员的内部培训课程中分享了漫游的概念。如果你想把手工测试过程带到21世纪，请阅读这本书吧。”
——微软公司卓越测试总监Alan Page
“1990年，我开始与James在IBM一起共事。他早在当时就鼓励测试人员和开发人员大胆创新。通过这本书，他把对软件质量的热情提升到了全新的高度。请阅读这本书吧，见证你自己成为一个更好的测试工程师。James是这方面的权威，这个星球上的软件测试工程师和开发工程师，无论他们是真正关心软件质量，或者只是想在自己的日常工作中增加更多的乐趣，都应该阅读这本书。”
——Cisco Systems公司高级工程主管Kaushal K. Agrawal
“James Whittaker 是测试领域中一位真正有远见的人士。Utest和我们的QA专业全球社区经常向James咨询以获得他的灵感、他对测试未来趋势的解读和他的各种测试理念。现在，他终于为大家写出了这本书，我们这个行业会由于这本书而变得更有智慧。”
——uTest公司CEO和合伙人Doron Reuveni
“只有像James Whittaker这样的人才会把旅游和软件测试以小说的形式结合起来，也只有James才能把它做到这么天衣无缝。漫游方法不仅提供了令人难忘的有效思考模式，还把适当的结构和组织与广泛的探索和创造结合在一起。bug们，小心啦！”
——谷歌公司Alberto Savoia
——谷歌公司测试工程总监Patrick Copeland
“James把美妙的手工测试方法学提升到了极致。漫游不仅概念正确，而且实际应用得很好，我们已经在所有测试人员的内部培训课程中分享了漫游的概念。如果你想把手工测试过程带到21世纪，请阅读这本书吧。”
——微软公司卓越测试总监Alan Page
“1990年，我开始与James在IBM一起共事。他早在当时就鼓励测试人员和开发人员大胆创新。通过这本书，他把对软件质量的热情提升到了全新的高度。请阅读这本书吧，见证你自己成为一个更好的测试工程师。James是这方面的权威，这个星球上的软件测试工程师和开发工程师，无论他们是真正关心软件质量，或者只是想在自己的日常工作中增加更多的乐趣，都应该阅读这本书。”
——Cisco Systems公司高级工程主管Kaushal K. Agrawal
“James Whittaker 是测试领域中一位真正有远见的人士。Utest和我们的QA专业全球社区经常向James咨询以获得他的灵感、他对测试未来趋势的解读和他的各种测试理念。现在，他终于为大家写出了这本书，我们这个行业会由于这本书而变得更有智慧。”
——uTest公司CEO和合伙人Doron Reuveni
“只有像James Whittaker这样的人才会把旅游和软件测试以小说的形式结合起来，也只有James才能把它做到这么天衣无缝。漫游方法不仅提供了令人难忘的有效思考模式，还把适当的结构和组织与广泛的探索和创造结合在一起。bug们，小心啦！”
——谷歌公司Alberto Savoia
评论交流
共有5人开贴评论 5人参与评论 4人参与打分 查看
评价等级：
发表于：2010-5-16 22:23:00
当软件测试的热点渐渐转向测试自动化，当越来越多的测试人员谈论白盒测试、QTP、LoadRunner和编程时，测试专家James Whittaker旗帜鲜明地捍卫手工测试（manual testing），探讨如何用探索式测试（exploratory testing）来应对严峻的现实挑战。
作者以“漫游”为隐喻，提出了以漫游测试（touring testing）为核心的探索式测试方法。第3章“局部探索式测试法”介绍了如何测试软件的局部：一个组件或模块。第4章“全局探索式测试法”介绍了如何测试软件的功用（capacity）：以测试意图为核心，将应用程序的多个特性和功能组合起来进行测试。这一章是全书的核心，作者提出一系列漫游测试方法，并组成了方法谱系（catalog）。作者为每一种方法起了独特的名字，并分门别类的讨论，其效果类似于Martin Fowler在《重构》（http://www.china-pub.com/196671）中对重构手法的组织。第5章分享了5个微软测试团队对于漫游测试的技术报告，以生动的笔触、丰富的素材证明了积极的手工测试依然是软件测试不可或缺的关键。
在第8章，作者对未来的软件测试进行了展望，非常有启发性。有些内容看似天马行空，实际上已经渐渐出现在现实的软件测试中。例如，Visual Studio 2010中代码覆盖率与测试用例的映射、手工测试的全程“录像”（作者曾经是Visual Studio 2010 Test Edition的架构师，相信他为此贡献良多）、正在出现的基于云计算的测试服务商。
书的最后1/3是作者的博客汇编。许多文章颇具见底，其中一篇引用了Tony Hoare爵士的名句，颇令人深思：软件测试的真正价值并不体现在代码中找出了多少缺陷，而是发现设计和编程人员解决问题方法上的局限、思路中的狭隘和技能方面的不足。这也许在暗示，是作者的持续思考和反复实践，使他能够提出漫游测试这种切合软件测试本质的方法吧。
清华出版社引进了许多好书，但是制作水平还是有待提高（只要将此书对比中文版的《重构》便知不足）。须知，对于真正的好书，精美的制作能够同时提高售价和销量。
作者以“漫游”为隐喻，提出了以漫游测试（touring testing）为核心的探索式测试方法。第3章“局部探索式测试法”介绍了如何测试软件的局部：一个组件或模块。第4章“全局探索式测试法”介绍了如何测试软件的功用（capacity）：以测试意图为核心，将应用程序的多个特性和功能组合起来进行测试。这一章是全书的核心，作者提出一系列漫游测试方法，并组成了方法谱系（catalog）。作者为每一种方法起了独特的名字，并分门别类的讨论，其效果类似于Martin Fowler在《重构》（http://www.china-pub.com/196671）中对重构手法的组织。第5章分享了5个微软测试团队对于漫游测试的技术报告，以生动的笔触、丰富的素材证明了积极的手工测试依然是软件测试不可或缺的关键。
在第8章，作者对未来的软件测试进行了展望，非常有启发性。有些内容看似天马行空，实际上已经渐渐出现在现实的软件测试中。例如，Visual Studio 2010中代码覆盖率与测试用例的映射、手工测试的全程“录像”（作者曾经是Visual Studio 2010 Test Edition的架构师，相信他为此贡献良多）、正在出现的基于云计算的测试服务商。
书的最后1/3是作者的博客汇编。许多文章颇具见底，其中一篇引用了Tony Hoare爵士的名句，颇令人深思：软件测试的真正价值并不体现在代码中找出了多少缺陷，而是发现设计和编程人员解决问题方法上的局限、思路中的狭隘和技能方面的不足。这也许在暗示，是作者的持续思考和反复实践，使他能够提出漫游测试这种切合软件测试本质的方法吧。
清华出版社引进了许多好书，但是制作水平还是有待提高（只要将此书对比中文版的《重构》便知不足）。须知，对于真正的好书，精美的制作能够同时提高售价和销量。
发表于：2010-9-15 16:49:00
谢谢大家的捧场，也非常高兴大家能喜欢这本令人醍醐灌顶的好书，也是展现软件测试未来愿景的预言书。
1. 对于这本书，小编也受到不少启发。透过James的视绝，测试原来可以如此有趣。
2. 这本书的翻译，也堪称上乘。这些文字借助于译者精湛的翻译技巧和优美的表达，活灵活现地展示了探索式软件测试之美，之趣。
3. 关于制作。对于能在思想层面引发读者思考的书，小编的考虑是一定要采用价格稍微高于普通纸张的轻型纸，其目的在于便于携带和有效缓解阅读疲劳。轻型纸的特点是轻、略微发黄（从医学角度来，这种颜色因为接近于自然光线，有利于减轻视觉疲劳，从而达到视力保护的效果）。
当然啦，这是小编的个人考虑，如果有不同的看法，也恳请大家提出来，帮助我们改进。
1. 对于这本书，小编也受到不少启发。透过James的视绝，测试原来可以如此有趣。
2. 这本书的翻译，也堪称上乘。这些文字借助于译者精湛的翻译技巧和优美的表达，活灵活现地展示了探索式软件测试之美，之趣。
3. 关于制作。对于能在思想层面引发读者思考的书，小编的考虑是一定要采用价格稍微高于普通纸张的轻型纸，其目的在于便于携带和有效缓解阅读疲劳。轻型纸的特点是轻、略微发黄（从医学角度来，这种颜色因为接近于自然光线，有利于减轻视觉疲劳，从而达到视力保护的效果）。
当然啦，这是小编的个人考虑，如果有不同的看法，也恳请大家提出来，帮助我们改进。
加载中...| 我要写评论 |
| 查看所有评论交流(共5条) |
