回归测试的话，我觉得可以通过回归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方法。