近对ET测试比较感兴趣，因此找了一些资料研究了一下，正好部门也有关于ET测试的培训，从而不断加深了对ET测试的了解，更在实际的测试中得到了较好的应用。

　　对于ET测试，我的理解是在测试的时候，根据测试的输入和输出，在没有用例的情况下对部分场景和部分路径较深的功能进行验证。由于在项目初期，测试人员一般是根据UC来写测试用例，即使UC写得非常的细，测试人员的测试用例一般也不会覆盖非常全面，原因是根据PRD或者UC，开发人员脑海中的产品和测试人员脑海中的产品虽然大致一样，但是在很多细节上还会存在差异。那么这部分空缺的测试场景或者测试功能要通过ET测试来完成，当然也有对产品进行的ET测试，这对测试人员的素质要求很高，特别是测试的经验、测试技巧以及联想的能力。测试经验是测试人员长期测试的积累，在对产品进行ET测试的时候，一般有经验的测试人员有很清楚的测试思路，或者根据以往测试的类似产品经验和技巧来进行测试，当然联想能力也非常重要，在测试某一个点时，发散的思维能力可以想到更多ET测试的case。

　　当一个产品出现在面前需要测试的时候，一般是根据用例来执行，但是当执行到某些用例的时候会有一些异常的想法，所谓异常的想法是没有包含在测试用例里面，但是很有必要去验证他的准确性。比如，在旺旺的自动回复功能中，自动回复内容和自动回复设置是在两个TAB中，分别对两个TAB进行测试，用例一般会覆盖到，但是两个TAB的功能联系起来的测试用例可能会遗漏，比如调换自动回复的内容顺序对自动回复设置的影响，这是一个比较细节的功能点，在使用ET测试的方法很自然的想到这一点异常情况。

　　在ET测试的过程中，发现case很重要，个人总结了一下发现case的方法：首先，ST测试为主，ET测试为辅的方法以及ET测试在第二轮测试之后主干回归之前的时间点让测试人员在ET测试之前对产品有了全面深入的了解。虽然可以通过一边ET测试，一边了解产品，但个人认为对于初学ET的同学，在了解产品的基础上进行ET测试效果更好，效率更高；其次，在测试的过程中按照用例来跑，很容易形成思维定势，打破思维定势的很好方法是在跑完一个功能点的用例之后，再回顾一下，利用发散思维的方式考虑有没有漏掉的点，这种思维也是建立在对产品的熟悉度的基础之上的；后，在ET测试中的场景要补全到测试用例，以便在下次回归的时候不会再遗漏。

　　现在我们的测试一般都是以ST测试为主，因此ET测试有很大的发展空间，结合好ST测试为主，ET测试为辅，将会大大提高测试的覆盖率以及发现bug的概率。