《探索式软件测试》是一本由James A. Whittaker著作，清华大学出版社出版的230图书，本书定价：35.00元，页数：2010 年4月，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

　　《探索式软件测试》精选点评：

　　●学习探索式软件测试时读的第一本书，很详细，但我更喜欢另外一本《探索式测试实践之路》

　　●怎么说呢~有几个方法在没看书前做实习QE时自己总结出来过~有开阔了不少新视野~就是理论太重，话说的有点太专业，偏繁琐。。。不过是本好书，短期内吃不下，只能慢慢随用随消化了。。。

　　●为了让工作更精进又读了一遍，并且把重点都汇总成Word文档了。

　　●很有启发性

　　●力荐。相当好的一本软件测试书。入门必读。读过直接就可以上手工作了。

　　●看其中四五六三章即可，各种测试方法说的太简单了

　　●写给手工测试人员的，理论不错，但是写的有点啰嗦，干货不算很多。而且有点故意往理论上靠的感觉。 后面博客摘录部分感觉价值不太大。 14.08中

　　●讲的东西大概是一种基于目的而不是基于模块的测试，根据粗略的测试脚本，根据特定的目的，现有测试后有脚本，然后列举了一系列的方向，感觉讲的很玄学，例子有点不好理解。

　　●James 通过旅游的例子，生动的说明了探索式测试考虑的角度和覆盖的范围，可能因为文化的不同，对于理解起来还是比较晦涩的，但是思路清晰，内容目的性突出，可以做个了解。

　　●软件测试、QA必读的书

　　《探索式软件测试》读后感(一)：探索式软件测试更像是一种测试风格

　　看了3次算是对里面的内容有了一个比较仔细的理解、同时也写了几篇关于探索式软件测试的文章

　　《探索式软件测试》读后感(二)：看了两遍才算是大概理解了一些思想

　　之所以打了4星，是跟我对本书的理解程度有关的。看第一遍，仍然问题一堆，说不出学会了什么。看第二遍，很多问题才得到了解答，但也只能说是大概理解了一些思想。也许以后看第三遍，并且在实际工作中有了应用后会有更大收获吧。

　　作者的探索式测试方法是漫游测试（touring test），把对软件的测试过程比喻成在一个城市的旅游，城市中大大小小的景点就是你要发现的缺陷，不同的游览策略将指导你去往不同类型的景点。

　　这也就是本书的核心思想：测试工作的划分，应该根据测试意图（即你想发现哪一类缺陷）而不是根据应用程序的结构关系。

　　拿在北京旅游做例子，游览策略应该是这样的：地标建筑、古迹名胜、风景名胜、历史文化……而不是这样：海淀区、朝阳区、宣武区……

　　书中的大多数文字，也就是在讲解如何才能根据测试意图来执行测试。

　　具体的测试思路书中讲了很多，一定有一些方式是平时很少考虑到的。第六章有很多ET在微软实践的例子，需要好好体会。除了ET之外，作者关于测试工作本身和tester的很多思考和建议也非常值得细读品位。

　　----------------------------------------------------------------------------------

　　摘抄一些重要文字和我喜欢的一些内容

　　本书写的是一种我认为比其他任何缺陷都重要的特殊缺陷：即逃过所有各种检测手段而最终存在于发布产品中的缺陷。

　　很多现代手工测试实践都缺乏目的性，随机性强且重复性强。

　　使用探索式测试并不是说不写文档。测试结果、测试实例和测试文档都会在运行测试时创建。

　　如果一个测试用例很可能马上就失效，当初就根本没有必要去编写它。

　　探索式测试的缺点在于测试人员有可能在测试中没有重点，从而漫无目的地尝试各种情况来试图发现软件缺陷，这会浪费大量的时间。

　　这里要强调指导方法的重要性。探索式测试如果没有一个好的指导方法，就好像游客新到一座城市，然后盲目彷徨想碰巧找到景点一样。

　　从测试策略的角度来说，明确到底要测什么和怎么测试同样重要。

　　探索式测试试图把制订计划、进行测试、重新制订计划等多个过程有机的结合起来，每次只前进一小步，但这每一步都是由软件过去和当前的运行状况、软件在测试时表现出来的各种行为和软件运行时留下的种种蛛丝马迹来即时确定的。

　　探索式测试有下面几个目标：

　　理解应用程序如何工作，它的接口看起来怎样，它实现了哪些功能。

　　强迫软件展示其全部能力。

　　找到缺陷。

　　应该根据测试意图而不是根据被测应用程序的结构关系来划分。

　　静态场景测试和探索式测试并不冲突。场景可以代表探索式测试的一个绝佳起点，探索可以给场景加入宝贵的变化，否则场景将很有限。

　　成功的漫游测试会刻意揭示某一类型的缺陷。

　　附录：

　　无论你曾有过什么样的实践经验，只有在你必须教授某一学科时，你才能真正掌握它。

　　《探索式软件测试》读后感(三)：内容不错，但是……

　　发现自己一直没写书评。总体来讲，这本书，内容很棒很详尽，是本值得看的好书。但严格来讲，个人认为书中内容很难讲就是探索式软件测试（简称为ET，Exploratory Testing）。

　　业内广泛认为ET这个词是由Cem Kaner最早提出的，根据他的说法：ET是一种软件测试的风格（style），强调测试人员的自由权利和责任心，通过同时进行测试相关学习、测试设计、测试执行和测试结果解析这四种相互支持的活动，不断地优化其自身工作的价值。

　　本书的作者，将探索一座城市比喻为测试一个系统，基于此来解释探索式软件测试。例如地标建筑，可以看做是该系统、该软件的主打功能，或者宣传重点；而风景名胜，则可以看做是该系统过去备受好评的那些消费者最爱功能；而地图，我们则可以看做是一份官方的需求文档；当然，还有很多可供查阅的民间游记，这则颇像是工作中的现行测试计划、测试用例或过往测试执行的测试报告等等。

　　从此角度出发来看的话，那么本书的重点都侧重在讲，在开始探索之前，应该如何规划、计划这趟旅程。而这其中，未知的部分，并不多。

　　Michael Bolton曾撰写过一篇著名的文章“Testing vs. Checking”，文中提出观点认为testing和checking是不同的，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等。

　　《探索式软件测试》读后感(四)：读《探索式软件测试》

　　一

　　《探索式软件测试》这本书，是 James Whittaker 在 2010 年写的，至今已经 9 年了，之前网上有不少人推荐过这本书，但是一直没机会看，最近终于找时间给看完了。

　　通读全书后，我的感觉是，书中思考问题的方式，和我已知的有太大的区别，以至于看的稍微快点就会很懵逼，但是仔细和我们已知的方法进行对应的话，其实是可以关联起来的。

　　总得来说，James 把手工测试的一些方法，假借旅游的名义，设计了一套漫游测试的理念，重点是这些理念所引发出来的不同角度的测试点的关注，所以和国内流行的等价类、边界值等等各种测试用例设计方法是一个目的，但是角度不同。

　　二

　　书中一共分 8 个正式的章节，3 个附录。

　　书中第 1 章用了 4 个曾经发生过的关于软件质量的例子，让我们理解什么是软件缺陷，并对软件缺陷造成的影响有简单的了解。

　　第 2 章介绍了软件缺陷的根源，以及各种缺陷预防和检测的策略，并引申出后面要讲的重点内容「探索式测试」。

　　第 3 章根据软件的各种属性，分别从输入、状态、代码路径、用户数据和执行环境这 5 个部分提出了对应的测试关注点，以及怎么考虑到这些关注点，角度总结的很不错，详细内容建议粗读，吸取里面的精髓即可。

　　第 4、5、6 章是真正的使用漫游测试的概念，把旅游中可能出现的场景同我们的软件测试点进行关联，从而让我们有一套完整的去考虑手工测试覆盖率的方法论，虽然有点晦涩，但还是推荐详细读一下第 4 章，并把里面的内容同我们现在的做法结合起来看看。

　　第 7 章总结了漫游与测试中的五个棘手问题，不得不佩服 James 的总结提炼能力，每个问题都总结的很到位，我们可以看看是否和我们当前工作中碰到的问题类似，如果是，James 刚好提供了漫游测试的解决方案。

　　第 8 章软件测试的未来，这个话题就像惯例一样的存在，当然，相对于在《Google 软件测试之道》里面的预测，这次的内容我认为简单看看就行了。

　　接着是附录，重点推荐下附录1，里面通过上山、巅峰和下山的比喻，详尽的描述了成功的软件测试职业生涯的完整面貌，一定要反复多读几遍，细嚼慢咽。

　　附录 2、3 是 James 博客的摘录，除了几篇需要精读外，大部分都可以做个了解即可。

　　三

　　针对本书的阅读人群，我的建议是：

　　1.有 3-5 年测试经验的测试工程师：3 年左右的测试工程师正处在一个爬坡期，甚至对一部分人来说是转型期，这时候看这些内容，可以提供一些新的灵感。

　　2.测试管理者：总得来说，书里面还是偏方法论多一些，管理者可以先学习吸收，然后结合自己业务的实际情况进行消化和落地。

　　不建议初学者关注，一方面，概念上确实挺晦涩的，没有一定基础，看完肯定会懵逼，另一方面，书中内容较集中于手工探索式测试范围的提升，初学者建议先关注基本的测试用例设计方法，以及如何保证基本的测试覆盖率。

　　另外，针对各章节的阅读方法，我的建议是：

　　1.精读：第 2、4、7 章以及附录1，附录 2 中的《软件戒律》和《恢复对软件行业的尊重》，还有附录 3 中的《测试人员评估》和《再议手工测试与自动化测试》。

　　第 2、4、7 章节内容是本书的重点，提到的附录内容是 James 思考过程中的代表性产物，特别是附录 1，很多人奉为经典。

　　2.粗读：第 3、5、6 章以及附录 2 和附录 3 的其他内容。

　　第 3、5、6 章都是对第 4 章的完善和补充，建议优先把第 4 章搞定，再酌情回顾 3、5、6 章节，附录 2 和 3 的其他内容都是 James 博客的摘录，可以酌情了解下他的思维方式和理论体系。

　　3.略读：第 1、8 章。

　　这部分不是本书的重点，只能算一个好的引入和结尾，权作了解更多的信息。

　　以上，不知道你是否了解过探索式软件测试的方法，是否看过 James 关于《经营成功的测试职业生涯》的阐述，看过的同学有什么见解？欢迎留言说说你的想法。

　　当然，如果你认可我的观点，请帮忙转发 + 点个「在看」让更多人看到，谢谢。

　　《探索式软件测试》读后感(五)：探索式软件测试读后感

　　一.写在前面的话：探索的乐趣

　　某日清晨，阳光明媚，我娃吃饱喝足后，伸出小手挥舞，试探着想去触碰身边的玩具，小手晃晃悠悠，距离玩具忽远忽近，终于碰到了，小娃咧开嘴开心的大笑。继而第二次，第三次，越来越熟练。

　　探索性测试也是如此，我们在未知的软件世界中跌跌撞撞，不断探索。探索性测试试图把制定计划，进行测试，重新制定计划等多个过程有机结合起来，每次只前进一小步，但这每一步都是由软件过去和当前的运行状态和软件运行时留下的蛛丝马迹来即时确定的。在不断探索之中，我们不断了解被测的应用程序，并且体会到探索的乐趣。

　　二.手工测试

　　1.缺陷存在的原因？

　　开发人员的态度：如何才能实现需求；而测试人员的态度：如何才能攻破功能

　　程序不在真实环境中跑起来，很多缺陷不会触发：流程不会遍历，输入和状态会不断变化

　　2.手工测试的缺点

　　自动化测试的缺点：很多不确定因素和场景会导致自动化测试失效，需要人脑介入（待考究）

　　手工测试的缺点：慢，没有规律，不可反复使用，问题无法复现，测试人员周期性疲惫

　　手工测试的优点：真实场景

　　3.探索性测试的意义：

　　具有明确目的，但又要给测试人员一定空间

　　三.局部探索式测试

　　1.测试的正确态度：

　　欣赏软件测试的高度复杂性和艰巨性，承认无论怎么做都是不够的，我们的目标是保证所有重要的任务都完成了。

　　2.探索性测试人员的五个决策：

　　输入，状态，代码路径，用户数据，执行环境

　　测试就是有所变，有所不变

　　3.如何测试输入：

　　1）各个输入之间会相互影响

　　2）输入顺序的变化

　　3）合法和非法输入:测试人员要清楚自己是想深入测试正常工作流程，还是想办法让他失效。

　　开发人员都不喜欢编写错误处理代码

　　4）输入筛选器如何测试：

　　（a）合法非法输入是否正确

　　（b）是否可以绕过屏蔽器：是否可以让输入值进入系统

　　5）错误信息反应开发人员编程时候的想法，要仔细阅读

　　6）如果弹出“发生了一个错误”的空泛提示，测试人员可以反复测试同一函数，或是稍微修改，可能导致程序彻底失效

　　7）非常规输入：ctrl，alt，esc间以及他们与其他字符的组合

　　每一个操作系统，编程语言，浏览器，运行环境都由保留词，比如windows的LPT1，COM1，AUX等

　　8）默认输入：不输入任何值；默认值；删掉默认值，留下空白字段；默认值附近的值，比默认值大一小一，删掉默认字符串的几个字符

　　9）用输出来指导输入：将主要输出结果罗列起来，确定哪些输入会引发这些输出，这样保证所有场景都被测试过了；

　　第一次针对输入产生某种响应时，软件处于默认状态，结果第一次产生；第二次输入时，很多变量还是上次运行时被设置的值，两个结果中很可能有一个失败；

　　寻找保存起来的输出结果，通常有些输出值会显示在屏幕上，或者存储在文件中，改动这些值或者文件大小类型，再测试。

　　4.状态：

　　1）状态的定义：软件状态是状态空间的一个点，它由所有内部数据结构的取值唯一决定

　　2）状态的分类：临时保存的变量，长期保存在数据库或者文件中的变量

　　3）如何测试软件状态： 输入和状态的关联相当密切

　　（a）如果多个输入是相关联的，他们应该放在一起测试

　　（b）通过观察某个输入对状态的累积程度，判定是否会发生溢出。可以重复使用相同或者不同的输入来检测这种副作用

　　5.代码路径

　　6.如何测试用户数据

　　使用真实的用户数据，长期测试，而不是不断删除老的数据，海量的用户数据可能会导致很多问题（自动化测试用例则会删除数据，这样不利于进行稳定性测试）

　　7.运行环境

　　1）什么是运行环境

　　软件使用的操作系统和当前配置，软件当前连接的网络情况等

　　2）如何测试运行环境

　　在《如何攻破软件》中有详细描述

　　四.全局探索测试

　　1.探索性测试的精髓和目标：

　　探索性测试时有的放矢的测试，它要理解应用程序如何工作，实现了哪些功能；它要证明软件确实实现了设计时所要求达到的功能，满族了功能上的所有需求；它要探索应用程序的各种极端情况从而发现潜在问题，并有目的的使故障数将为零

　　2.漫游测试的优点：

　　把软件划分成便于管理的小块，会带来很大的风险，单独测试某个特性可能会无法发现那些只有在特性互相集成时才能表现出来的缺陷

　　漫游测试根据测试意图而不是应用软件的结构关系来划分

　　漫游测试法帮助测试人员学会如何进行良好的测试设计，提醒他们思考，我应该测什么

　　随着测试的进展，测试人员可以根据测试情况的好坏决定使用或者放弃某种测试方法，将针对某类缺陷适用的测试方法总结成文档，用于知识传递

　　测试就像旅游，目的是在这次测试中尽全力，同时确保下次能汲取本次的经验教训，能够做的更好

　　3.漫游测试的区域划分

　　以下是互相重叠的几个应用程序区域，每个区域都有适合自己的方法

　　1）商业区：软件包装盒上的特性，是用户所要使用的软件特性和功能

　　2）历史区：遗留代码

　　3）旅游区：目的仅仅是为了到此一游

　　4）娱乐区：休闲娱乐，比如美化文本

　　5）旅馆区：次要和辅助功能

　　6）破旧区：

　　4.商业区的测试方法：

　　1）指南测试法：参考软件操作指南，按照它的输入和场景进行测试

　　2）卖点测试法：软件最能卖钱和销售人员大肆宣传的特性

　　3）地标测试法：比如在森林中穿行，根据指南测试法和卖点测试法，确定关键的软件特性作为地标，确定它们的先后顺序，然后从一个地标执行到另一个地标，直到访问了所有的地标（待下文继续分析）

　　4）极限测试法：

　　5）快递测试法：测试人员参与到数据生命周期的每个阶段（待下文继续分析）

　　6）深夜测试法：营业时间之后，开始备份文件，删除文件等

　　清晨测试法：测试软件的启动过程和脚本

　　7）遍历测试法：使用最短路径遍历用户接口，测试中不追求细节，只检查明显的错误。比如冒烟测试

　　5.历史区

　　6.旅游区：

　　7.娱乐区：

　　1）配角测试法：通常和主要特性一起显示在显示器上

　　2）混合测试法：将互相影响的几个特性放在一起测试

　　如何判断几个特性之间存在影响

　　（a）他们会处理同一个输入；

　　（b）他们会在用户界面上操作同一个区域，产生同一个输出；

　　（c）他们会修改共享的内存数据。

　　3）通宵测试法：永远不要关闭程序

　　8.旅馆区：

　　1）取消测试法：启动测试然后立即停止；启动测试，不要停止，开始另一个同样的操作。

　　2）懒汉测试法：接收程序所有的默认值，看程序是否能够达到预期的目的地

　　9.破旧区

　　五.混合探索式测试

　　探索性测试将结构化的思想和自由的探索结合起来，比起自动化测试来更加灵活，是蕴含着丰富策略的测试方法。

　　测试场景描述了基本功能，它就像地图，探索可以增加更多的变化，寻找不同的路径

　　1.怎么判断一个场景是有价值的

　　2.通过场景引入变化

　　3.通过漫游测试引入变化：使用不同的漫游测试方法