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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

探索式测试有下面几个目标：
理解应用程序如何工作，它的接口看起来怎样，它实现了哪些功能。
强迫软件展示其全部能力。
找到缺陷。

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

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

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

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