如何发现和修复被常规软件测试忽略的关键软件缺陷？在《探索式软件测试》中，享誉业界的软件测试专家Ja rrlesWhittaker揭示了当下最严重、隐藏最深的软件错误的真正诱因，并介绍了如何利用功能强大的探索式测试技术来找到并纠正这些错误。
先后就职于谷歌、微软和其他顶端软件公司的james Whittaker，在软件测试的前沿阵地拥有近20年的丰富经验，他为传统的手工测试引入了可重复、规范、可传授和特别高效的新过程。Whittaker定义了针对单个测试人员的简单技术和针对大规模测试团队的复杂技术。他还引入了一个混合策略，将探索式概念引入传统脚本测试。在《探索式软件测试》中，可以体会到如何在恰当的时机使用这些方法，如何成功地充分应用这些方法。
简洁、诙谐和可行，《探索式软件测试》引入的这些技术已经经过上市软件的测试人员广泛应用，人们在实际测试过程中深受这些方法的启发，成功实现了预期目标。《探索式软件测试》是为测试人员、QA专家、开发人员、程序经理和架构师所写的。
《探索式软件测试》涉及以下重要问题：为什么自动化测试无法消除所有缺陷，如何才能让这些缺陷无处遁形？哪些技术可帮助我不断发现和消除致命错误？如何更高效地进行手工测试，增加些许轻松和愉悦的感觉？对于每个项目，如何确定高效的高级测试策略？在我无法进行全部测试时，哪些输入是必须测试的？哪些测试用例能提供最理想的特性覆盖率？在结合使用探索测试和传统脚本或场景测试时，如何才能获得理想效果？如何体现来自开发过程的反馈意见，代码更改吗？
谈论软件质量的方法有很多，感兴趣的听众也有很多。本书是为软件测试人员而写的，写的是一种我认为比其他任何缺陷都重要的特殊缺陷：即逃过所有各种检测手段而最终存在于发布产品中的缺陷。
任何一个软件公司发布的产品都有缺陷。缺陷是怎么引入的？为什么没有在代码审核、单元测试、静态分析或其他面向开发人员的活动中把它们找出来？为什么自动化测试没有找出它们？那些缺陷有些什么特质使其能逃过手工测试？
什么是找出产品缺陷的更好方法？
本书针对的正是最后一个问题。在第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章“软件测试的未来”中，我更进一步讨论在未来几年中，诸如虚拟化、可视化甚至电视游戏之类的技术将如何改变测试的面貌。附录包括我对测试职业生涯的看法，收集了我以前一些深受读者喜爱的文章（加入了一些新的注解），其中一些文章已经无法在其他地方看到了。
写这本书对我来说是一种享受，我希望你阅读本书也是一种享受。
“好书！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
“James是软件测试主题最出色的演讲者之一，读他的书就像聆听他的演讲。如果你希望增加测试知识并成为一个更优秀的测试人员，这本书就是为你而写的。”
——TCL集团公司主席和合伙人Stewart Noakes
“我从事探索性测试已经有段时间了，James的漫游测试法给我所使用的各种方法起了名字，定义了测试重点，更重要的是给了我实际的指导。这本书将会使探索式测试的教学和应用变得更方便。”
——iMeta Technologies公司高级测试顾问Rob Lambert
“我为这项工作感到非常激动，它概念新潮却又合情合理。连我这样的普通读者都能轻松地理解和使用，而不用首先去学习一些华而不实的过时理论。在阅读本书时，我也从不需要借助字典。测试领域长久以来就一直期盼着这样的创新之作，我由衷地认为本书在这方面走在行业最前沿。”
——Netjets公司QA部门经理Linda Wilkinson