赤裸裸的现实数据表明哪怕项目的自动化系统做的再好，最终问题中的大多数还是得通过手工测试发现，对于更加敏捷的移动端测试，很有必要丰富测试方法与测试理论，而探索式测试就很适合敏捷式测试。
1． 缺陷预防和缺陷检测
测试人员更多的都是在关注缺陷检测上，主要任务也确实是缺陷检测上。读完此书的最大感想之一就是缺陷预防的重要性，尽管缺陷预防工作一般都是由开发人员完成。
尽量减少错误并提高软件质量，主要有两大类技术：缺陷预防和缺陷检测
缺陷预防工作的重要性：
一份预防往往等价于十份治疗！
软件和人的身体健康是一样的，当检测出有毛病了，就已经晚了，此时要付出的代价往往大的多，而若能好好地做好预防工作，效率绝对会大大提高。而现实中并不是每个开发团队都会很好地去做缺陷预防工作。
缺陷预防包括编写更好的设计规范、实施代码审核制度、运行代码静态分析工具、运行单元测试（往往是自动化单元测试）。对于android应用开发团队，可以以Jenkins+PMD+lint完成自动化静态代码分析，以推动代码规范的实施，进一步地进行单元测试，不断提高代码质量！
软件项目和足球挺像的，没有哪个防守做得好的球队是仅靠后卫的，而是需要整个团队协同工作，丢球反抢、前场就得开始逼抢！
2． 程序员引入的缺陷和运行环境导致的缺陷
软件缺陷的根源:程序员引入的缺陷和运行环境导致的缺陷
对于android应用的测试也是非常的明显，常常在某个手机型号上一切正常，往生只有安装到某一特定手机型号时问题才能重现，因此只保证检测出程序员引入的缺陷还远远不够，即需要做好足够的兼容性测试。
数据：当数据量积累到一定程度，软件出现故障了！除了系统本身的兼容性问题外，运行环境还包括测试时的数据与正式线上数据不一致导致发布到线上才能检测出一些特定问题，因此应该尽量在测试环境编造与线上尽可能一致的数据，且运行尽可能长的时间。
软件状态：虽然两次输入的数据完全相同，但测试结果可能完全不同，第一次我们测试的是软件处于一个未被初始化的状态时如何产生输出，而第二次测试的则是当软件处于一个已被初始化的状态时如何产生输出的。
新的环境：那些老代码或者接受重新修改，或者是没被改动就放到新环境中运行，很容易发生失效的情况。对于android应用，就意味着如果android新发布了个系统，应用能否继续在这个系统上正常就需要重新测试衡量了，此时常常那些老代码就无法正常运行了。应用中有做修改的代码能否在旧的android系统上运行也需要重新测试衡量了。
3． 关于测试用例
对于测试用例的看法思维上算改变很大了，之前的想法是希望尽可能的把用例写详细，越详细越好！但对于移动端的测试，对于迭代迅速、需求变更迅速的情况下真心有必要写得很详细吗！在这种情况下许多用例很快就失效了，且维护麻烦、成本高。
探索式测试一书中有这么个观点：如果一个测试用例很可能马上就失效，当初就根本没有必要去维护编写它。
探索式测试是测试脚本可以规定得很细，也可以只含有一些粗线条的描述，测试人员需要学习随机应变的本领，掌握面对各种选择时如何可以进行合理的判断。即编写用例时可以大致描述出步骤场景，对于具体的输入则可以充分发挥探索式测试的优势，以更发散更具有创造性的去思考怎样的输入或怎样的操作更可以让软件失效。将有组织有目标的旅游就和自由风格漫无目的的闲逛紧密地结合起来。
4． 关于测试人员的价值
阅读本书一个很大的改变就是关于测试人员的价值观念的转变。
对于测试人员的评估，原文：真正的评估并不在于衡量找到软件缺陷的数量，而在于改正这些缺陷后软件质量得到改善的程序，评估测试人员时不要用软件缺陷的数量、软件缺陷的严重性、测试用例的多少、自动化测试的代码量、回归测试套件的数目以及任何具体的指标来衡量可以通过观察测试人员究竟提高了多少开发人员的工作绩效，将此作为评估测试人员绩效的依据随着开发人员素质的提高，最终同时达到软件缺陷数量下降和生产效率提高的目的，这远远超过了只注重发现并清除软件缺陷的简单方式。
非常赞同这个观点：授人以鱼不如授人以渔，要想真正提高软件质量，最根本的办法就是提高开发人员的编码水平，而编码水平提高后对软件质量产生的提高将是持久性的，反过来也说明了推动团队完善代码审核制度、静态代码检测、单元测试等缺陷预防工作的重要性，只有这样才能不断提高团队的开发水平、提高代码质量、提高软件质量，达到良性循环！
当然了，文章所说的评估方法不按各种指标现实中估计很难~通过观察提高了多少开发人员的工作绩效也不靠谱，因为这其中有太多因素变量。
测试人员应该常常想想使命或理想，软件是有魔力的，但这伟大的魔力常常因为缺陷而造严重的后果，为了将来某一天软件能完全正确工作而孜孜不倦地奋斗着！
5.其他
a.大多数开发人员不喜欢编写错误处理代码，测试人员必须重视对这些地方的测试，尽量想办法或者通过查看开发人员编写的错误处理代码，测试时想办法使软件运行错误处理代码。
b.发布出去的版本在用户手里还是会出现各种各样的问题，因此需要尽可能多的模拟覆盖真实用户的使用场景。
c.缺陷常常是扎堆的，某一模块出现缺陷时，应该更加仔细地测试这一模块及其附近模块，且一个好的缺陷往往隐藏着一个更大的缺陷，应该深入探索。
d.尽你最大的努力注意并记住软件采取的动作次序，同时记住应用程序的响应，如果应用常常崩溃，那么打开DDMS时时监控日志吧。
e.保证当前的测试项目获得成功的同时，应该学习你应该做些什么以便下一个测试项目更加容易，持续进步。
6．探索式测试方法
商业区测试类型
指南测试法：要求测试人员通过阅读用户手册并严格遵照手册的建议执行操作
卖点测试法：找到那些最能卖钱的特性，应该观摩那些销售演示
地标测试法：选择一个地标，到达目标后，再选择另一个地标
极限测试法：向软件提出很多难以回答的问题
快递测试法：测试人员专注于数据，确认那些被存储起来的输入数据，并跟随它们走遍软件
深夜测试法：对于应用程序自动做的事情有时可以强制去让他执行
遍历测试法：选择一个目标，使用可以发现的最短路径来访问目标包含的所有对象
历史区测试类型
恶邻测试法：缺陷通常扎堆，某个代码区域缺陷多，可以对邻近功能使用遍历测试法进行测试
博物馆测试法：
那些老代码或者接受重新修改，或者是没被改动就放到新环境中运行，很容易发生失效的情况
上一版测试法：必须运行先前版本上支持的所有场景和测试用例
娱乐区测试类型
配角测试法：越紧邻那些主要功能，越容易被人注意，这些特性不能忽视
深巷测试法：应该测试该使用情况中排在最下面的几项特性
通宵测试法：软件能多长时间运行而不崩溃，将软件一直处于开启状态
旅游区测试类型
收藏家测试法：收集软件的输出，确保能观察到软件能生成的任何一个输出
长路径测试法：到达目的地前尽量多地在应用程序中穿行
超模测试法：只是测试界面，测试中注意观察界面上的各种元素
测一送一测试法：同时打开同一文件或者让它们同时在网络上传输数据
芬格兰酒吧测试法：有些功能很难找到，需要花大量的时间深入了解待测的应用程序
旅馆区测试类型
取消测试法：可以对任何提供取消选项的功能或者需要较长时间才能完成的功能做同样的操作
懒汉测试法：测试人员做尽量少的实际工全，接受所有默认值，保持表单为空等
破旧区测试类型
破坏测试法：强迫软件做一些操作，掌握软件成功完成操作必须使用的资源，在不同程度上移除那些资源或限制用那些资源
反判测试法：要求输入最不可能的数据，或者已知的恶意输入
强迫症测试法：一遍又一遍地输入同样的数据
