说说《探索性软件测试》这本书吧，阅读之后一些个人理解和思考，纯文字，不感兴趣可忽略。。。
第一章有这么一句话：从设计来说，有些软件的功能本身就存在功能逻辑上的错误或不友好，且产生的效果完全违背我们的初衷。
做软件测试工作，或许第一件要知道的事情就是：没有完美的设计和产品。
也许这也是软件测试这个行业产生以及发展至今的原因吧，即使软件设计、开发、测试流程不断在优化完善，但它依然存在缺陷！
软件缺陷来源于软件开发本身，主要原因是软件工程师没有理解、预见或测试到所有可以运行的环境。
或者换一句话来说：程序永远无法预防用户的各种操作而带来的损失。
软件应用的四个基本功能：接收输入、产生输出、存储数据、运行运算
那么，如何尽可能把缺陷排除在交付用户使用之前？主要有以下两点：
1、缺陷预防
这一点主要从软件开发人员角度来说：编写更好地设计规范、实施代码审核（code review）、代码静态分析、单元测试（unit testing）等等；
①代码审核：开发人员视角：如何实现这个功能——————盲点
测试人员视角：如何攻破这个功能
二者相辅相成，缺一不可
说到这里，想起一种软件研发模式：测试驱动开发（TDD：test-driven-development）
②静态代码分析：不需要实际运行代码程序，其主要包括分析程序源代码（source code）、目标代码（object code）、最终编译生成的二进制文件或程序。
③数据：软件需要IO数据，才能覆盖程序中各个代码路径、程序、功能；软件测试是个动态的过程，在不同环境运行软件，使用合理的测试数据，尝试多次不同的输入。
2、缺陷检测
软件测试工程师的工作，就是尽可能主动暴露、发现缺陷，并配合其他软件工程师解决缺陷；而测试人员的测试形式，一般有两种：利用工具进行自动化测试和手工测试。
①自动化测试
说起自动化测试，常见的类型有UI自动化、接口自动化以及单元自动化；业内对其的评价，也可以说各执己见，它的优点和缺点，都很明显。
优点：编写代码脚本执行测试用例，效率高，省却了大量的时间和人力成本
缺点：代码脚本维护成本较大、前期人力时间需要投入的成本大、需要比较稳定的环境等等，还有，如何确定自动化测试真的完成了应该完成的任务？是否输出了正确的结果？
②手工测试
这种类型的测试人员，可以说占软件测试从业人员的大多数，业内俗称点工（点点点），说来有点嘲讽，很多人觉得点点点没有技术含量，都是自嘲居多（虽然我也偶尔开玩笑
说自己专注点工多年^_^）。不过话说回来，点点点也有很多东西需要学习，如何分析需求、设计覆盖率足够高的用例，如何有效的执行用例发现缺陷、及时跟踪、和开发人员
沟通、定位缺陷、协助解决缺陷，以及足够大的脑洞，比较好的阅读理解以及文档编写能力，这些都很需要时间去钻研练习以及实践。
探索性软件测试
本书主要内容就是探索性测试这个方法，或者说，一种思维逻辑方式、方法论，更合适。
主要有两块内容，局部探索性测试和全局探索性测试。
探索性软件测试核心：强调个人自由与责任的测试方法，让测试人员借由不断学习来改善测试的规划与执行，同时在测试过程中同时改善测试的案例来达到不断互补优化。
大概总结了一下，其主要内容就是以下几个点：
①何时何人采用何种方法测试什么
②对需求的探索、了解、熟悉
③对工作流的不断探索
④测试案例的重用性、简洁有效性
④模块拆分、关注IO上下游、
⑤方法论、探索论、思考总结优化
探索性软件测试的三个目标：
①理解应用程序的工作逻辑和原理，接口，以及实现了哪些功能
②尽量了解熟悉软件的所有功能
③寻找缺陷
下面列举一些书中总结出的探索性测试方法：
指南测试法：城市的题图通常都会标注一些热门的旅游景点，测试这些热门的区域是非常重要的。不管在任何一次发布的过程中，核心功能是肯定要覆盖到的。指南测试要求测试人员严格
按照用户手册的建议执行操作，有可能是手册描述不到位或者核心功能并不像宣传的那样好。
卖点测试法：此方法是鼓励测试人员观看销售给客户演示的Demo，理解销售的角度哪些功能对客户来说是最大的卖点，他们未必就是核心功能，但值得测试人员把它们当核心功能来对待。
同时，也许刁钻的客户会提出各种质疑，这些质疑和稀奇古怪的问题也可以纳入测试人员的设计中。
地标测试法： 在旅游的时候，如果我们设计了要到访的地方，通常会在地图上插上旗子，这就是地标。但是没有人规定我们应该按照何种顺序去到访这些地标。不同的测试人员可能会选择
不同的顺序，有经验的测试人员会基于对软件产品架构和技术层面的理解，采取一些古怪的路径但更可能发现缺陷。
极限测试法：向软件提出难以回答的问题，比如最大可以发挥到什么程度，承受多少用户，承载多少数据。那个特性或功能会把软件逼到极限运作，哪些输入和数据会消耗软件最多的计算
能力？哪些输入可能绕过它的错误检测？
快递测试法：快递运送的货物，就好比软件里的数据，结果不同的地点转接，拆包装包最终到底目的地。所以快递测试专注的是数据，跟随它们走遍整个软件。
深夜测试法：城市灯火阑珊会在午夜过后逐渐安静下来，商场店铺纷纷打烊。但是软件不应该停止工作，软件测试人员有时应该刻意的关注在冷门时间段软件所做的附属工作，比如数据备份
归档、维护监控任务的运行等等。
博物馆测试法：这是针对软件的遗留代码，保留了些许年代的一些功能，找出它们来验证是否有出现失效。当初开发它们的时候，甚至可能缺乏文档，但这并不意味着它们应该被忽略。
深巷测试法：在每个城市，都有些地方并不吸引游客意味着不吸引人群，但作为测试人员来说，反而是这种最不可能被用到或者最不吸引用户的特性，容易潜藏着难以发现的Bug。
通宵测试法：繁华的都市总会有通宵热闹的地方，比如夜总会KTV之类的，它们从不中断。那么应用程序是否也能坚持到最后呢？当它面临持续不断的调用、输入、重读重写之类的操作，
如果运行时间足够长，就很可能会出问题，内存会需要回收、数据需要清空，永远不要关闭它，保持不间断的运行。（更多的时候会采用自动化或者机器人思想）
长路径测试法：把那个在应用程序埋藏最深的界面当做测试目标（离起始点最远的那个界面），观察经过的每一个界面
超模测试法：针对UI的表面测试，衡量软件的展现能力，像T型台的超模那样，不去关注她们幕后的辛酸痛苦劳累，跳出产品专家或测试的头衔，以普通观众的角度，去关注那些能看到的
界面展现，元素是否被正确绘制、是否难看、颜色风格是否一致、界面的切换变化是否表意清晰？
取消测试法：此方法的思想是启动了立即停止，特别是一些运行流程比较耗时的功能如备份还原或者搜索，在启动之后，立即取消。发散一点还可以变成，启动一个耗时操作，不停止立即
启动另外一个耗时操作，以此来检测应用程序的自我清除能力。
懒汉测试法：选择尽可能少的输入，能不输入尽量不输入，能不修改尽量不修改，观察应用程序是否能响应得出正确结果。
反叛测试法：你见过去酒吧不喝酒点果汁的么？反叛思想要求输入最不可能的数据，或者已知的而已输入，测试人员可以采用逆向思维、明知一些数据违反规则，却偏偏要采用这样的数据，
或者不按照正确的顺序来输入。
强迫症测试法：测试人员强迫软件一边又一边接受同样的数据，反复执行同样的操作，最重要的特点就是重复。此种思维方式，常常打破了开发人员设计代码的思路，他们预想着你会按步骤
操作，却不曾考虑过你反复的执行第一步应该如何处理。
最后，在本书的末尾篇章找到如下内容，算是寥有收获。
软件测试十戒律：
1.汝应用大量输入反复锤炼汝之应用程序
2.汝应贪图汝之邻居的应用程序
3.汝应亲自寻找睿智的预言家
4.汝不应崇拜无法重现的失效
5.汝应尊重汝的模型和自动化测试
6.汝应利用开发人员的过错与他们作对
7.汝应醉心于谋杀应用程序（庆祝蓝屏吧）
8.汝应保持安息日（指产品发布时刻）的圣洁
9.汝应贪图开发人员的源代码
具体内容链接：www.howtobreaksoftware.com(PS：需要收费)
相关链接：http://blog.csdn.net/andy572633/article/details/13004731
http://blog.csdn.net/andy572633/article/details/46941753