8.Analyze：ET发现什么样的bug
对于ET测试发现的bug类型做一些个人分析，相信很多人对于这个比较感兴趣：
第一：一般情况下，ET测试的目的不是为了发现正常流程下的主要功能bug，特别是Freestyle ET 方式实践的时间点
第二：ET测试过程中，会变化测试手段去测试，更多的是用户测试和极限测试和交叉测试，也就会发现很多这些手段产生的bug
第三：ET测试过程中，使用的一些测试手段决定了发现的bug类型，常用的测试手段有：边界值测试，极限测试，用户测试，菜单浏览，域测试，组合测试。
第四：ET测试过程中，需要在学习业务的同时，不断的变化上述的测试手段去测试。
第五：从产出上来看，使用了极少时间去进行ET测试产生的bug率是比较高的(平均每个小时产生3.5个bug)。对于项目组测试人员来说，其单位时间内产生的bug率应该是比较低的。因为其投入包括熟悉需求；测试设计，3轮测试执行等。具体官方数据个人不是很清楚。可参照XX1项目某测试人员的数据：投入时间267个小时，发现124个bug；则平均每个小时产生0.47个bug。(注意：该数据不是直接判断标准)
时隔5个月之久，本人又实践了一个项目，根据之前的实践经验，对于XX2项目进行两天的ET测试，产出的结果也就是bug产出的类型和数量与第一次项目实践并无大区别，这里就不列出具体数据，但还是有一些其他的心得，也就是在做ET实践时印象较深的地方：
(1)如果该产品的用户体验较差(或是使用过程中无很清楚的提示操作去引导用户去使用该功能或产品)，这样在时间非常有限的ET测试过程中，会遇到较多困惑。
(2)同样如果该产品流程非常复杂，且需要非常大的数据准备，这样在时间非常有限的ET测试过程中，测试内容比较有限，且大量的时间花在数据准备上，会减弱ET的创造性。
(3)ET测试过程中，由于处在测试执行的后期阶段，对于主要功能的问题几乎不存在，这里使用ET发现的bug的严重程度和类型会有所变化，也就是说发现一些bug(个人经验的不同会有所不同)不是需求的bug，而是程序本身的bug。比如某个查询项，正常情况下，用户输入4位数字进行查询，结果正确；但如果输入20个数字，进行查询，会出现系统错误。也就是我们测试不仅仅要保证正常输入得到的结果正确，更要保证非法或异常输入程序也能进行合理的处理。
(4)ET测试处在项目测试后期，不是为了发现bug而去测试，而是更多的去探索和使用该产品，因为ET tester本身不知道接下来要去测试什么，更不知道这样测试能否发现bug，同样也不会刻意去发现高难度或很严重的bug。ET tester只会根据自己看到的产品的Response来进行测试，至于能够发现什么类型的bug不必刻意追寻，否则会影响测试的高度注意力。
(5)ET测试完成后，如果Bug较少的话(原因很多)，无法很全面的说明提高了测试覆盖率，由于test idea的产生和执行都是同时执行的，而且并没有刻意去记录这些测试用例，但会记录一下Notes和疑惑。这方面对于ET测试的效率和知识沉淀的传承是很不利的。
相关链接：
