还有一个是Bug Bash。在每个项目发布前的一段时间好能够组织全公司或者全team进行bug bash。每次bash时间一般在3个小时，现在这个方法越来越多的公司引入并成功找到产品隐藏的缺陷。这种活动可以看作为全员在做测试，结果对于ET的补充和总结很有帮助。

　　测试的KPI考评永远是一个难题，更加不用说在ET下考评。我在推荐一种自己总结的方法，将ET的每个活动都定成Task，其中高风险高优先的全部由测试leader主动分配给测试人员，低风险低优先的由团队成员自由领取执行或者创建新的Task执行。每个Task中都需要测试人员写明ET的目的，使用的方法，测试范围，时间等。终根据每个测试人员对于高低风险Task的完成数量，完成时间，完成质量加权之后进行相对应的考评。这样也很有说服性。

　　3、ET要写测试用例么？和ST的用例一样吗？回归测试怎么做？发现了bug之后应该怎么总结

　　笔者觉得ET的测试用例更加像一种思维导图，或者思维引导，并没有具体的形态。但是我们需要记录的是一种思维，并非一种特定的现象（如果某些功能测试步骤和测试结果一直不变，比如数据库的测试，比如一些对话框的测试，那么可以将他们列入ST的测试用例中，也可以在ET的思维导图中备注一下）ET所需要的其实是一种思维，引导测试应该从什么测试点入手，每个功能适合用什么切入点去测试。在第2点中我提到的Task中测试leader必须写清楚测试切入点，可能出现的问题点，这样一来降低了因为测试人员能力不同而导致的风险，二来同时也引导了新的测试人员，将经验很好的传达给了他们。

　　针对回归测试，可以通过回归在上一个周期中已发现的缺陷来达到相应的目的。另外你也可以建立ET的用例库，将高风险的缺陷或者测试点总结放在其中，然后作为回归测试来执行。

　　ET发现缺陷，缺陷首先你肯定需要在你的系统中进行记录，其次是要记录到你或者整个团队的一个库中。它是一种思路，一种经验，以便于引导下次测试该模块的测试人员。

　　4、进行ST和ET的权限，什么时机是执行ET好的时期呢

　　怎么权衡ST和ET，可能每个执行的测试人员都会纠结这个问题，以下我假设两个测试环境以及对应的方式你会明白了。

　　假设你的团队成员经验都不是很多，产品也还没有进入缺陷稳定的周期，同时也没有很完善的自动化辅助测试。那么你需要将高风险的功能点总结出来，然后组织团队进行测试用例的编写。那么这部分的功能是主要以ST为主，ET为辅的方式进行测试。而其余的功能你可以一半时间使用ST，一半时间使用ET。其思路是ST保证高风险功能点以及产品的各个基本功能点，产品经过ST之后不会产生高风险的问题。同时结合ET，让产品从用户体验、界面友好性等各个方面进行测试验证。

　　假设团队成员都已经非常有经验，产品也是处于稳定期。那么你可以使用ET为主，ST为辅的方式。同样的这样会加快团队使用ET的经验。ST同样是为了保证基本功能点以及一些固定数据的测试点，ET能够在短时间内更多的发现产品的缺陷。

　　任何一种方法都不会在马上见成效，很多测试会觉得ET没有成效。因为以上所有的策略都是基于风险能够评估之后制定出来的。而风险如何评估需要测试团队长期对于产品的一种了解，一种数据的积累分析而得出。而风险的高低在项目中又是不断变化的，所以我们必须在项目中灵活的进行ST和ET的安排，而不是完全根据计划按部班。什么时候是施行ET好的时期呢？根据项目实际情况，你认为合适的时期是合适的。ET也需要经验的积累，思维的积累，流程的改善等过程，只有经过了几个迭代周期的考验才会看得更加清楚，效果才会显著。

　　后来谈一下自动化测试和ET的关系。ET的思维，方法也同样能够运用在自动化的用例设计中。而自动化同样的也是能够让测试人员更好的进行ET的工具。举个例子来讲，如果需要测试一个功能的边界，需要在界面上大量的输入数据从而查看界面的显示。此时你有两种方法，人工的进行输入，又或者编写自动化脚本生成大量的输入数据。两种方法都是可行的，但自动化的方法能够让测试效率大大提升。这也是我们一直说测试其实是和时间战斗的一个主要原因。

　　探索是方法，探索是过程，探索是思维，探索也是一种精神。不过任何东西物极必反，所以不要盲目追求探索，不要盲目追求全覆盖测试，不要盲目追求完美的自动化，更加不要盲目追求别的企业的工程的流程等。所谓探索是为了在项目变化中更好的进行测试，这种变化只为了达到自己的测试目的，每个企业，每个测试人员面对的环境，产品都不同。什么是好的？能达到自己的测试目标，能够满足自己企业，自己眼前的测试需求，是好的。

　　后希望大家能够通过这篇文章更好的认识探索式测试，并运用到项目流程中去。

　　本文出自《测试人》第3期