赤裸裸的现实数据表明哪怕项目的自动化系统做的再好，最终问题中的大多数还是得通过手工测试发现，对于更加敏捷的移动端测试，很有必要丰富测试方法与测试理论，而探索式测试就很适合敏捷式测试。

　　1． 缺陷预防和缺陷检测

　　测试人员更多的都是在关注缺陷检测上，主要任务也确实是缺陷检测上。读完此书的最大感想之一就是缺陷预防的重要性，尽管缺陷预防工作一般都是由开发人员完成。

　　尽量减少错误并提高软件质量，主要有两大类技术：缺陷预防和缺陷检测

　　缺陷预防工作的重要性：

　　一份预防往往等价于十份治疗！

　　软件和人的身体健康是一样的，当检测出有毛病了，就已经晚了，此时要付出的代价往往大的多，而若能好好地做好预防工作，效率绝对会大大提高。而现实中并不是每个开发团队都会很好地去做缺陷预防工作。

　　缺陷预防包括编写更好的设计规范、实施代码审核制度、运行代码静态分析工具、运行单元测试（往往是自动化单元测试）。对于android应用开发团队，可以以Jenkins+PMD+lint完成自动化静态代码分析，以推动代码规范的实施，进一步地进行单元测试，不断提高代码质量！

　　软件项目和足球挺像的，没有哪个防守做得好的球队是仅靠后卫的，而是需要整个团队协同工作，丢球反抢、前场就得开始逼抢！

　　2． 程序员引入的缺陷和运行环境导致的缺陷

　　软件缺陷的根源:程序员引入的缺陷和运行环境导致的缺陷

　　对于android应用的测试也是非常的明显，常常在某个手机型号上一切正常，往生只有安装到某一特定手机型号时问题才能重现，因此只保证检测出程序员引入的缺陷还远远不够，即需要做好足够的兼容性测试。

　　数据：当数据量积累到一定程度，软件出现故障了！除了系统本身的兼容性问题外，运行环境还包括测试时的数据与正式线上数据不一致导致发布到线上才能检测出一些特定问题，因此应该尽量在测试环境编造与线上尽可能一致的数据，且运行尽可能长的时间。

　　软件状态：虽然两次输入的数据完全相同，但测试结果可能完全不同，第一次我们测试的是软件处于一个未被初始化的状态时如何产生输出，而第二次测试的则是当软件处于一个已被初始化的状态时如何产生输出的。

　　新的环境：那些老代码或者接受重新修改，或者是没被改动就放到新环境中运行，很容易发生失效的情况。对于android应用，就意味着如果android新发布了个系统，应用能否继续在这个系统上正常就需要重新测试衡量了，此时常常那些老代码就无法正常运行了。应用中有做修改的代码能否在旧的android系统上运行也需要重新测试衡量了。

　　3． 关于测试用例

　　对于测试用例的看法思维上算改变很大了，之前的想法是希望尽可能的把用例写详细，越详细越好！但对于移动端的测试，对于迭代迅速、需求变更迅速的情况下真心有必要写得很详细吗！在这种情况下许多用例很快就失效了，且维护麻烦、成本高。

　　探索式测试一书中有这么个观点：如果一个测试用例很可能马上就失效，当初就根本没有必要去维护编写它。

　　探索式测试是测试脚本可以规定得很细，也可以只含有一些粗线条的描述，测试人员需要学习随机应变的本领，掌握面对各种选择时如何可以进行合理的判断。即编写用例时可以大致描述出步骤场景，对于具体的输入则可以充分发挥探索式测试的优势，以更发散更具有创造性的去思考怎样的输入或怎样的操作更可以让软件失效。将有组织有目标的旅游就和自由风格漫无目的的闲逛紧密地结合起来。