另外，如果时间充裕，那么进行交叉的ET也是非常有效率的一种方式。无论是新测试还是老测试，每个人都会有测试盲点。那么交叉测试既能够保证ET的覆盖面的同时也会给测试带来更多的想法，灵感。

　　在每个项目发布前的一段时间最好能够组织全公司或者全team进行bug bash。每次bash时间一般在3个小时。我以前公司每次都会做。这种活动可以看作为全员在做测试，相信这样一轮下来肯定会发现很多之前没有发现的问题。对于实施ET之后的项目也很有帮助。

　　3、ET要写测试用例么？怎么写？回归测试怎么做？发现了bug之后应该做什么处理。

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

　　回归测试的话，我觉得可以通过回归bug来达到相应的目的。或者也可以将高风险的功能归类总结出ST的TC，然后作为回归测试来执行。

　　ET发现bug之后我认为首先你需要报这个问题，其次就是要记录到你或者整个团队的思维导图这样一个库中。它是一种思路，以便于引导下次测试该模块的测试人员。

　　那么最后我来谈一下怎么权衡ST和ET，正如我之前提到的几点需要清楚的地方。那么下面举几个例子，我相信你就会明白。

　　假设你对于你的团队信心不是很大，并且对于产品本身的质量抱有一定的质疑。那么你需要将高风险的功能点总结出来，然后进行测试用例的编写。那么这部分的功能就是主要以ST为主，ET为辅的方式进行确保。而其余的功能你可以一半时间使用ST，一半时间使用ET。其思路就是ST保证高风险功能点以及产品的各个基本功能点，至少产品经过ST之后不会产生P1的问题。同时结合ET，让产品从UE、UI等各个ST可能无法覆盖到得方面进一步进行保证。

　　假设你对于你的团队和产品的态度还是有那么点信心的。那么你就可以使用ET为主，ST为辅的方式。同样的这样会加快团队使用ET的经验。ST同样是为了保证基本功能点以及一些固定数据的测试点，而更多时间的ET是能够在短时间内更多的发现产品的缺陷，从而达到测试的目的。

　　当然，你不用问我到底在项目中什么时候进行ET，进行ET之后效果貌似不明显等问题。为什么？因为以上所有的策略都是基于风险能够评估之后制定出来的。而风险如何评估，需要测试团队长期对于产品的一种了解，一种数据的积累分析而得出。而风险的高低在项目中又是不断变化的，所以我们必须在项目中灵活的进行ST和ET的安排，而不是说我们定好怎么样就是怎么样的。ET也需要经验的积累，思维的积累，流程的改善等过程，只有经过几个项目的考验那么才会看得更加清楚，效果才会显著。

　　最后希望大家能够更加理解ET，更好的运用ET，总结出来适合自己公司的ET方法。