《探索式软件测试》书评

《探索式软件测试》书评

英 文 书 评“好书！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

内容不错，但是……

发现自己一直没写书评。总体来讲，这本书，内容很棒很详尽，是本值得看的好书。但严格来讲，个人认为书中内容很难讲就是探索式软件测试（简称为ET，Exploratory Testing）。业内广泛认为ET这个词是由Cem Kaner最早提出的，根据他的说法：ET是一种软件测试的风格（style），强调测试人员的自由权利和责任心，通过同时进行测试相关学习、测试设计、测试执行和测试结果解析这四种相互支持的活动，不断地优化其自身工作的价值。- 参考一：http://en.wikipedia.org/wiki/Exploratory_testing- 参考二：http://www.kaner.com/pdfs/QAIExploring.pdf （第36页）本书的作者，将探索一座城市比喻为测试一个系统，基于此来解释探索式软件测试。例如地标建筑，可以看做是该系统、该软件的主打功能，或者宣传重点；而风景名胜，则可以看做是该系统过去备受好评的那些消费者最爱功能；而地图，我们则可以看做是一份官方的需求文档；当然，还有很多可供查阅的民间游记，这则颇像是工作中的现行测试计划、测试用例或过往测试执行的测试报告等等。从此角度出发来看的话，那么本书的重点都侧重在讲，在开始探索之前，应该如何规划、计划这趟旅程。而这其中，未知的部分，并不多。Michael Bolton曾撰写过一篇著名的文章“Testing vs. Checking”，文中提出观点认为testing和checking是不同的，checking是为了确认已知事物的表现是否吻合预期，而测试则是为了找到新信息。- 参考：http://www.developsense.com/blog/2009/08/testing-vs-checking/- 详细：Checking is something that we do with the motivation of confirming existing beliefs. Checking is a process of confirmation, verification, and validation.- 详细：Testing is something that we do with the motivation of finding new information. Testing is a process of exploration, discovery, investigation, and learning.参照如上的这些观点来看的话，我认为这本《探索式软件测试》可以成为一本非常好的测试设计指南，但是，我很难认可它是一本真正在讲解“探索式软件测试”的书，因为它并未将其重心放在如何同步地进行学习、设计、执行和解析这四件事，而是如何规划自己的测试活动。==========徐毅：独立敏捷顾问，经验丰富的国内知名敏捷及精益教练，专注于敏捷软件开发、Scrum、敏捷转型、敏捷测试、测试自动化、robotframework等。

探索式软件测试更像是一种测试风格

看了3次算是对里面的内容有了一个比较仔细的理解、同时也写了几篇关于探索式软件测试的文章 http://www.hiadmin.org/testing/exploratory-type/探索式软件测试的四个类型http://www.hiadmin.org/testing/exploratory-testing/探索式软件测试:基本概念介绍 http://www.hiadmin.org/testing/exploratory-software-testing/什么是探索式软件测试

看了两遍才算是大概理解了一些思想

之所以打了4星，是跟我对本书的理解程度有关的。看第一遍，仍然问题一堆，说不出学会了什么。看第二遍，很多问题才得到了解答，但也只能说是大概理解了一些思想。也许以后看第三遍，并且在实际工作中有了应用后会有更大收获吧。作者的探索式测试方法是漫游测试（touring test），把对软件的测试过程比喻成在一个城市的旅游，城市中大大小小的景点就是你要发现的缺陷，不同的游览策略将指导你去往不同类型的景点。这也就是本书的核心思想：测试工作的划分，应该根据测试意图（即你想发现哪一类缺陷）而不是根据应用程序的结构关系。拿在北京旅游做例子，游览策略应该是这样的：地标建筑、古迹名胜、风景名胜、历史文化……而不是这样：海淀区、朝阳区、宣武区……书中的大多数文字，也就是在讲解如何才能根据测试意图来执行测试。具体的测试思路书中讲了很多，一定有一些方式是平时很少考虑到的。第六章有很多ET在微软实践的例子，需要好好体会。除了ET之外，作者关于测试工作本身和tester的很多思考和建议也非常值得细读品位。----------------------------------------------------------------------------------摘抄一些重要文字和我喜欢的一些内容本书写的是一种我认为比其他任何缺陷都重要的特殊缺陷：即逃过所有各种检测手段而最终存在于发布产品中的缺陷。很多现代手工测试实践都缺乏目的性，随机性强且重复性强。使用探索式测试并不是说不写文档。测试结果、测试实例和测试文档都会在运行测试时创建。如果一个测试用例很可能马上就失效，当初就根本没有必要去编写它。探索式测试的缺点在于测试人员有可能在测试中没有重点，从而漫无目的地尝试各种情况来试图发现软件缺陷，这会浪费大量的时间。这里要强调指导方法的重要性。探索式测试如果没有一个好的指导方法，就好像游客新到一座城市，然后盲目彷徨想碰巧找到景点一样。从测试策略的角度来说，明确到底要测什么和怎么测试同样重要。探索式测试试图把制订计划、进行测试、重新制订计划等多个过程有机的结合起来，每次只前进一小步，但这每一步都是由软件过去和当前的运行状况、软件在测试时表现出来的各种行为和软件运行时留下的种种蛛丝马迹来即时确定的。探索式测试有下面几个目标：理解应用程序如何工作，它的接口看起来怎样，它实现了哪些功能。强迫软件展示其全部能力。找到缺陷。应该根据测试意图而不是根据被测应用程序的结构关系来划分。静态场景测试和探索式测试并不冲突。场景可以代表探索式测试的一个绝佳起点，探索可以给场景加入宝贵的变化，否则场景将很有限。成功的漫游测试会刻意揭示某一类型的缺陷。附录：无论你曾有过什么样的实践经验，只有在你必须教授某一学科时，你才能真正掌握它。