探索性
测试：
最近对ET测试比较感兴趣，因此找了一些资料研究了一下，正好部门也有关于ET测试的培训，从而不断加深了对ET测试的了解，更在实际的测试中得到了较好的应用。
对于ET测试，我的理解是在测试的时候，根据测试的输入和输出，在没有用例的情况下对部分场景和部分路径较深的功能进行验证。由于在项目初期，测试人员一般是根据UC来写
测试用例，即使UC写得非常的细，测试人员的测试用例一般也不会覆盖非常全面，原因是根据PRD或者UC，开发人员脑海中的产品和测试人员脑海中的产品虽然大致一样，但是在很多细节上还会存在差异。那么这部分空缺的测试场景或者测试功能就要通过ET测试来完成，当然也有对产品进行100%的ET测试，这就对测试人员的素质要求很高，特别是测试的经验、测试技巧以及联想的能力。测试经验是测试人员长期测试的积累，在对产品进行ET测试的时候，一般有经验的测试人员有很清楚的测试思路，或者根据以往测试的类似产品经验和技巧来进行测试，当然联想能力也非常重要，在测试某一个点时，发散的思维能力可以想到更多ET测试的case。
当一个产品出现在面前需要测试的时候，一般是根据用例来执行，但是当执行到某些用例的时候就会有一些异常的想法，所谓异常的想法就是没有包含在测试用例里面，但是很有必要去验证他的准确性。比如，在旺旺的自动回复功能中，自动回复内容和自动回复设置是在两个TAB中，分别对两个TAB进行测试，用例一般会覆盖到，但是两个TAB的功能联系起来的测试用例可能会遗漏，比如调换自动回复的内容顺序对自动回复设置的影响，这是一个比较细节的功能点，在使用ET测试的方法就很自然的想到这一点异常情况。
在ET测试的过程中，发现case很重要，个人总结了一下发现case的方法：首先，ST测试为主，ET测试为辅的方法以及ET测试在第二轮测试之后主干回归之前的时间点让测试人员在ET测试之前对产品有了全面深入的了解。虽然可以通过一边ET测试，一边了解产品，但个人认为对于初学ET的同学，在了解产品的基础上进行ET测试效果更好，效率更高；其次，在测试的过程中按照用例来跑，很容易形成思维定势，打破思维定势的很好方法就是在跑完一个功能点的用例之后，再回顾一下，利用发散思维的方式考虑有没有漏掉的点，这种思维也是建立在对产品的熟悉度的基础之上的；最后，在ET测试中的场景要补全到测试用例，以便在下次回归的时候不会再遗漏。
现在我们的测试一般都是以ST测试为主，因此ET测试有很大的发展空间，结合好ST测试为主，ET测试为辅，将会大大提高测试的覆盖率以及发现bug的概率。
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。
这边详细的说下Passive EAT的实现方式，之前使用工具录制测试人员做测试执行，在这个Session完成的时候，测试人员需要根据录制的Session测试设计新的测试用例和原来的测试结果。这个时候使用工具录制，一个好处就是测试人员完全可以自己做测试，且可以转移思维去报测试过程中发现的bug，真正的做测试执行，节约了大量时间，同样也会减少不能重现的bug率，可以看到这种方式在重现，记录和报告bug方面有很大的作用。
关于Active EAT方式，对于一个Session的测试执行肯定就是执行所有的自动化测试脚本，同样的在这个Session完成之际需要做些事情： 第一个测试人员和第二个测试需要互换角色（这样可以最大程度保证SUT的健壮性和稳定性）；做出一个以后用于回归测试的范围出来（考虑覆盖率，唯一性，独特性）；对于每一个完成的自动化测试脚本做一些更高级的描述。
自动化的ET相对与手工的ET来说，它到底有哪些优势呢：
● 第一个就是更容易的分析测试用例；
● 重现bug 方面更容易；
● 提高测试覆盖率（在session测试开始之前就可以run已经存在的自动化测试脚本）；
● 节省时间（当使用Passive EAT时，交叉测试方面可以减少很多时间）
● 提高更好的保证（让管理层或check方能够清楚的知道我们的测试活动）
这里面我们可以看到所谓的自动化的ET，就是将ET测试过程中的一些关键点保存起来再事后进行新的优化和完善。现在说的ET大部分情况下是手工的ET，充分发挥人在测试执行过程中的创造性，如果能让机器模拟人的思维过程，从系统给出的反应中又能快速想到的新的测试用例。
想象下未来的自动化的ET，能够先写一部分的ET自动化测试脚本，在运行这些脚本的时候，每个测试脚本中存在某个检查点能够时刻观察系统的输出，页面的显示情况，并记录下来，如果能够根据这些情况，自动产生新的测试脚本，那就更酷了。这样就让那些检查点模拟人的思维去思考这个输出是否合理，且在过程中的一些异常，某些数据的状态变化，并从中找到可疑点，并产生新的用例再次验证之前的假设或再次攻击最有可能出错的地方。这样我们测试工程师就可以run这些ET自动化测试脚本，然后等着接受大量bug的report了。如果真的可以实现这个，这个时候测试人员的价值又在哪里呢，我猜想应该是不断的完善和提供更多的高智能的检查点，让其具有更强的思维去产生更多和更好的测试脚本。
