ET是否能够代替ST

　　这个问题也许是大多数最关心的问题，其实前面几篇blog也表达了我的个人的观点，但我这边想说的更尖锐一点，讨论未来ET的发展和ST有什么关系，真正了解ST和ET的定义的人，应该可以感觉这个问题就像问自动化测试是否能代替手工测试一样，我想绝大部分人都可以说未来不管测试行业怎么发展，自动化测试不可能代替手工测试。但这样比喻，又有一点疑问，那就是自动化测试不可能代替手工测试的主要原因和ET不能代替ST是完全不一样的。 我们可以想到自动化所有的测试用例受到的制约非常复杂，有一个代价和成本太高，还有一个就是技术要求高。但ET如果在未来会代替ST，并不会受到这方面的制约，可以看到如果我们可以多实践和掌握那两大模型，我们完全在ET中来代替ST。但这里只能说存在一部分人的能力达到标准，这些人所做的项目完全可以使用ET，但并非适用所有人。

　　这里面说ET代替ST，并不是说不采用ST的某些方式在ET中，比如我们ET测试之前完全可以做test idea list，类似于测试设计，这一点和完全意义上的ET似乎有点矛盾，下面说下如果想让ET来代替ST，ET的发展需要做些什么。

　　首先需要就是引用ST的测试设计技术，让ET tester真正的知道怎么去做测试设计，在测试执行之前做到心中有数，但ET真正的魅力是在测试执行时的表现。假设未来我们有一个非常炫的技术： 测试人员的专有提示显示（测试人员在测试执行的时候，光标移到什么位置，比如某个用户接口控件，会弹出个提示显示，里面有属性，源代码，代码改动量，输入数据的状态等，就像打魔兽世界游戏时的迷你世界地图显示一样），那简直是酷极了的事情。

　　其次需要的是综合所有ST的经验，之前ST所写的那些测试用例，那些好的用例，好的测试思路，都是需要我们去积累的。假设未来我们有一个真正全面的测试百科（有大部分所有重用和共用的功能的所有的测试用例和测试思路，如果可以的话，还包括自动化测试用例），但测试人员有了这些，我们越少的减少写用例的时间，就越来越远离ST，真正的发挥在测试过程中ET的作用。

　　之前也提到过ET和ST组合的模型，现在ET业界的大师，大部分认为ET可以作为ST的一个有力的辅助，起到一个推波助澜的作用，有则好，无也OK。 有的话，做得好则好，做得不好，一般也OK。这边说下，似乎ET的大师们，在推ET的过程中，强烈限制自动化测试的作用，将人的思维以及创造性放大，还有就是强烈BS测试用例写的非常详细和维护。其实说白了，ET的发展依靠于我们如何更多的抽象出方法，并能让新人很快的接受，真正的使其门槛降低，减少经验的限制。

　　畅想下未来，我们不需要做任何测试设计，也不需要写测试用例，我们完全在需求的本身质量上，根据强大的测试百科，就可以自动生成适合项目需求的所有的测试用例和测试思路；且在ET测试执行的时候，能根据系统的反馈，执行的代码，数据的状态等多个维度下想到下一个更好的测试用例，不断的攻击SUT。真正的把ET发挥到极致，在任何特定的情况下，都能找到对应的ET测试方法的指导，并自动产生测试用例。让测试变得越来越有趣，越来越有技术含量，越来越提高SUT的覆盖率。

　　ET是否能够自动化

　　这个问题提出来大家也许觉得不可思议吧，如果能够正确理解ET的概念，能够记得ET的核心的人，都认为ET几乎不可能做到自动化，ET的特点是学习，和测试设计和测试执行同时Action，那么这边说下国外是怎么考虑自动化的ET的。

　　自动化的ET就是利用把在Session中做测试时使用一种自动化的方法去进行bug重现，回归测试，bug证据收集。一种方式就是使用第三方工具录制测试人员做测试执行且分析日志文件，甚至用于将来的回归测试。这种方式叫做Passive EAT。另一种就是使用KDT的自动化工具去自动化某个session的测试执行。比较适于pair testing，一个测试人员负责创建自动化测试脚本，另一个测试人员执行脚本，记住这些自动化脚本也是在测试执行和测试设计和学习产品的产物，这种方式叫做Active EAT。