（已有6条评价）基本信息
- 原书名：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
书摘
已经有很多文章阐述了漫无目的的生活会带来哪些坏处，但盲目的测试和现代测试实践中的无目标性，导致了这样一个问题。软件测试不是简单地拿起来就做的事情。它要求有计划、有准备、有策略和有多变的战术，这是成功进行软件测试的前提。但是，太多的软件企业因偏爱“想干就干”而忽略适当的准备。测试工作非常重要，所以决不能如此随便地对待它。
我在佛罗里达理工学院担任教授的时候，我教过软件测试课程。有一个学期，注册这门课的学生多得超乎我的想象。我决定做一个试验，想把少数随意选择这门功课的学生吓走。在开学的第一天，我在计算机房上课，我指导学生们确定要测试的应用程序，两人为一个测试小组。我没有给学生们完成这个测试任务提供进一步的指导。作为鼓励，我答应他们，如果我对他们采用的技术留下深刻的印象，他们就会被留在我的班上。如果他们不能满足要求，我就认为他们自动放弃（我不是有意要赶他们走，但是这种要求达到了我想要的效果）。
我在实验室里走来走去，无形中对学生们产生了压力，有时我会与一组学生攀谈，要求他们解释如何找到软件错误。每当我提出这样的问题，就会得到类似的答案，如“不太清楚，我们只希望它会出错。”最后，一些聪明的学生意识到这种回答并不奏效，他们在随后的回答中渐渐地开始包含一些策略。事实上，我清楚地记得有两个学生说“我们将要对所有的文本输入框输入较长的字符串，希望能够找到一些不检查字符串长度的地方。”①我当即接受他们成为我的第一组学生，并鼓励他们继续做下去。
太好了！虽然这不是最好的或者最重要的策略，但它至少是一种策略，有助于减少测试的无目标性。软件测试人员运行测试程序时，经常缺乏策略或没有指定明确的目标。在他们进行手工测试时，他们漫无目的地测试应用程序。在他们实现测试自动化时，仅仅由于他们熟悉怎样编写测试自动化，就去这么做了，而不考虑这样的自动化是否能发现有价值的缺陷，是否经得起时间的考验，是否值得付出维护费用。
……
我在佛罗里达理工学院担任教授的时候，我教过软件测试课程。有一个学期，注册这门课的学生多得超乎我的想象。我决定做一个试验，想把少数随意选择这门功课的学生吓走。在开学的第一天，我在计算机房上课，我指导学生们确定要测试的应用程序，两人为一个测试小组。我没有给学生们完成这个测试任务提供进一步的指导。作为鼓励，我答应他们，如果我对他们采用的技术留下深刻的印象，他们就会被留在我的班上。如果他们不能满足要求，我就认为他们自动放弃（我不是有意要赶他们走，但是这种要求达到了我想要的效果）。
我在实验室里走来走去，无形中对学生们产生了压力，有时我会与一组学生攀谈，要求他们解释如何找到软件错误。每当我提出这样的问题，就会得到类似的答案，如“不太清楚，我们只希望它会出错。”最后，一些聪明的学生意识到这种回答并不奏效，他们在随后的回答中渐渐地开始包含一些策略。事实上，我清楚地记得有两个学生说“我们将要对所有的文本输入框输入较长的字符串，希望能够找到一些不检查字符串长度的地方。”①我当即接受他们成为我的第一组学生，并鼓励他们继续做下去。
太好了！虽然这不是最好的或者最重要的策略，但它至少是一种策略，有助于减少测试的无目标性。软件测试人员运行测试程序时，经常缺乏策略或没有指定明确的目标。在他们进行手工测试时，他们漫无目的地测试应用程序。在他们实现测试自动化时，仅仅由于他们熟悉怎样编写测试自动化，就去这么做了，而不考虑这样的自动化是否能发现有价值的缺陷，是否经得起时间的考验，是否值得付出维护费用。
……
