探索性测试详解
1. 测试文档(计划和设计和用例)必须非常详细和明确
2. 测试设计和测试用例对于开发的文档的依赖非常大
3. 测试执行的时候对于测试用例的依赖非常大
4. 测试执行的时候对于需求变更的应对力较差
我们可以把有以上特点的测试方法叫Scripted based testing(简称ST)，显然我们目前就是这种测试方法，由于这个方法有些缺点，从而产生了一个新的测试方法：ET。
下面我们对于ET和ST进行了一些简单的比较：
在这里我们可以看到一点就是ET似乎就是弥补ST的一些缺点，理智的人就会想到能不能ST和ET结合起来。这样带来的效果是不是更好呢?
我们认为大部分的项目的最佳组合地方是在中间，也就是我们可以采用ST的优点和ET的优点进行组合。但这里要说明的是ET是Context-Driven School的代表作，其强调的就是没有最佳实践，任何项目都有自己的特点，根据特有的特点制定最佳的测试方法组合策略。
对于上面的模型图，可以看到有如下的特点：
最左边就是Pure Scripted，也就是完全的按照测试用例来执行测试;而且测试用例非常详细。
最右边是Freestyle ET，也就是自由式的ET，没有任何测试文档;不需要记录任何东西(bug除外);测试执行之前不需要任何准备。
可以看到上面的两种方式都是不成熟的，而且都是不常见的，有点走极端。我们自己做项目过程中不可能完全走Pure Scripted或Freestyle ET。这里比较好的办法就是混合ST和ET，并在不同的项目当中采取不同的混合策略来进行比较完善的测试方法的策略。在大部分的项目过程中，组合ST和ET会带来意想不到的效果，
目前我们所有的项目都是ST为主导的，偶尔会在测试执行的时候会去发散性的去测试一些东西，但这个完全建立在经验和时间和功能等众多因素上。为了更好的混合ST和ET，我们考虑尽量减少文档的编写时间，提高更多的在测试执行时创造性的发挥，更加的体现在测试执行过程中持续性学习产品带来的思维扩展性。
这里介绍下混合ST和ET时，需要用到的几个关键性的因素：
Vague Scripted：比较模糊的测试用例，一般不是很详细，这里可以理解为有一些测试用例(但没有一些比较详细的预期结果)，也会有一些步骤(但会预留有一些其他详细的步骤而不是必须要做的)。
Fragmentary test cases：使用一句话或几个词语制定测试用例。
Charters：ET过程中使用到的一个非常清晰地任务列表，指出了要测试什么，怎么测试(强调策略，不是详细测试步骤)，要寻找什么样的bug，有哪些风险，要去检查什么文档等。
Roles：ET过程中给测试人员一个独立的角色去测试产品的一部分。由他们自己掌控进度和质量。
这里主要说明了ET和ST的一些方式上的不同，至于ET的定义这里就不说了，下次介绍下ET在什么情况下适合做，ET做的好不好与哪些因素有关系。大家想要了解什么或者有什么问题，都可以留言。
----------------------------------------------------
上一次我们说到了ST和ET的一些区别，大家对于ST都非常熟悉了，那么既然ET存在测试领域，肯定有其应有的价值，下面说下这几个问题：ET的优势和缺点和影响因素，最后说下一个优秀的ET测试人员应具备什么样的能力。
ET作为一个比较现代的测试方法，肯定有其非常重要的优势：
它可以鼓励测试人员的创造性
它增加了发现新的或者难以发现的bug
它允许我们有更多的时间去测试感兴趣的和比较复杂的用例
它可以更有效率的驱使测试人员在一个很短的时间内找到更多的bug和对AUT做一个快速的评估
它显示了一个产品是如何被使用的
它具有非常好的适应性，灵活性，多样性
它比ST更有乐趣
它可以促使测试人员快速的学习一个产品
它可以check其他测试人员的测试工作
它可以很好的应用在敏捷测试项目
它允许我们不用花很多时间在编写那些简单和繁琐的测试用例
同样，ET也有一些非常不好的缺点：
它在测试管理上的局限性使得ET过程很难去协调和控制
它在bug的重复利用或重现上提供非常有限的支持
它对于测试人员的测试技能和行业知识依赖比较大
当与ST进行组合时，会有重复测试的风险
它不能完全保证最重要的bug已经被发现了
它不合适于安全测试，性能测试，或其他高级的有专业的测试类型
它只能在AUT完全可用的情况下才开始
很难的去定义ET的生产率
无法对测试思路进行自动化
我们知道了某些情况下ET比较合适，那么就像之前说过的一样，ET没有最佳实践，ET在项目中做的好与不好，都会受很多情况制约，这些情况都会或多或少影响着ET实践的数据产出，下面列出了比较重要的制约因素：
这个项目的测试的具体任务(一般和测试类型和产品本来的特点)
这个测试人员的角色(lead或SDET或STE)
具体的测试人员(技能，天赋，擅长点)
可用的测试工具和测试机器
可用的时间
可用的测试数据和文档
从其他的人员获得的帮助
当前的测试策略
同一个产品已经经过测试后的状态
其实我们可以总结影响ET的基本因素为：时间，测试人员，产品，任务。我们还可以分析下ET过程中的几个关键的因素，其实也就是一个优秀的ET测试人员所具备的基本能力：
测试设计：一个优秀的测试设计师，一般有如下几个能力：首先是分析这个产品;评估产品的所有的风险;使用现有的工具去分析或记录;测试设计技术的熟练使用。
细心观察：一个优秀的ET测试人员必须比一般的人甚至是做ST的测试人员更具有细心观察细节的能力。ET测试人员必须去观察一切看似不正常或有疑问的地方，他还要能仔细的在推论和其他一些的假设中辨别出真理何在。
批判性思考：一个优秀的ET测试人员能够快速的评审和解释他们的思考逻辑，并能在独立思考中需找错误。这在重现bug的时候非常重要。
丰富的想法：一个优秀的ET测试人员能够比一般人产生更多且更好的想法。但通过什么来产生这么多且好的idea呢?这个也是ET的核心了，目前ET的牛人们创立了一个叫Heuristics的方法，这个方法比较抽象且实践过程在国内几乎空白，后续讨论下。
丰富的资源：一个优秀的ET测试人员能够构建一个集测试工具，信息资源，测试数据，同仁的一个储存室。这样在测试的时候，可以很快的应用这些资源。
下次说说ET怎么样在我们的项目中使用起来，什么时候使用ET，还有如何更好的管理ET而不让ET失控，如何去衡量ET测试人员的工作量。大家想要了解什么或者有什么问题，都可以留言。
--------------------------------------------------
现在对于探索性测试，大家很多的看法都存在一点误区，都认为探索性测试不会控制和管理测试进度，大家在网上可以找到很多关于探索性测试的介绍，很少介绍到探索性测试应用在项目过程中式任何管理的，没有涉及到核心，那么很多人都关心这个ET到底在项目中怎么来做呢?还有一个就是之前说了ET(探索性测试，后续统称为ET)很难去控制和管理整个进度，那到底有没有什么好的办法去管理ET呢?下面我们就去看看国外是怎么做的吧。
首先要说的是这些问题在ET发展过程中，ET的那些大师们已经想好了怎么在项目实践过程中应用ET，也有一些比较成熟的解决办法。
1.1 实践中ST和ET的使用模型
这里需要说明的是怎么应用ET在项目过程中，可以从不同的维度去考虑：
一个是ET和ST的结合方式，和测试人员具体做ET还是ST或都做无关
另一个是team的组成方式，从测试的专业性角度去分隔开ET tester和ST tester
看下面的模型更易理解：
(备注：ST就是Scripted based Testing, 就是我们目前所做的基于测试用例进行测试的测试方法; Tester A是专门做ST Team的ST测试人员，Tester B是专门做ET Team的ET测试人员)
从模型的演变过程可以看到，其实我们最终目标是没有ST tester和ET tester之分的，所有人都是标准的ET tester。国外ET的大师们确实带了好几个ET team，在项目测试过程中已经达到了模型四的境界，可想ET是可以主导整个项目测试的，其进度控制和质量管理都在实践中有了自己方法。
1.2 ET team的管理方式
在ET team里面又存在2个不同的管理方式：Delegation和Participation，这个区分的角度是从ET team lead在整个项目ET过程中的作用来看的。
Delegation：
(1) Test lead指定需要测试的charters, 不参与具体测试任务
(2) ET tester完成这些charters并且report back
(3) 对于一些问题和测试报告召开定期会议
Participation：
(1) Test lead在项目测试过程中与ET tester一样，参与某些测试任务
(2) Lead可以实时的根据测试质量情况制定最后的测试策略
(3) Lead可以持续的了解他所想要的了解的team的任何情况
这里还可以让大家知道的是相比较单个人进行ET测试，在一个ET team中大家工作在一起，在同一时间对于同一个SUT(Software Under Test)进行ET，经常会出现很多更好的测试idea。 所有还有一种组合ET team的方式是让测试人员组成一对且让他们在同一台计算机上进行测试。另一种就是其中一个测试人员进行测试，傍边有多个测试人员观察且做记录，通过问测试执行人员不同的问题产出更多的测试idea，这里有一个好处就是测试执行人员不必担心发现的bug难以重现，因为傍边的测试人员会做记录和分析，这样测试执行人员可以不必分心去继续自己的测试。还有一个好处就是如果一旦这个测试人员思维过于开阔，去测试很多非当前需要测试的模块时，傍边的测试人员可以给予及时提醒。但其缺点就是更多资源消耗在同一个功能模块上，成本上有待商榷。
1.3 ET过程中的任务
下面我们说说具体的ET tester是怎么完成这些Charters的，还有怎么管理和控制他们完成的这些Charters。Charter的定义：ET过程中使用到的一个非常清晰地任务列表，指出了要测试什么，怎么测试(强调策略，不是详细测试步骤)，要寻找什么样的bug，有哪些风险，要去检查什么文档等。
在测试执行之前，ET lead和Senior ET tester参与制定所有的charters，并根据实际情况从charters中分离出所有需要测试的sessions(一个基本的测试工作单元，一般对应1-2个UC)。这里我们可以看到ET tester所有进行的ET是基于session的，那么我们使用的管理方法就叫Session-Based Test Management(Jon Bach的首创)。
这里需要说下制定这些session的一些基本的原则：
(1) 这些Session必须是chartered(与测试任务绑定的)
(2) 这些Session必须是uninterrupted(独立的功能，且执行时不受外界的干扰)
(3) 这些Session必须是reviewable(其Session sheet可以被第三方review)
(4) 每个Session一般不超过90 min, 其大致范围从45 min(short session)到120 min(Long session)
首先我们来分解下ET过程中，大概花的时间的分配：
(Opportunity 指的是Opportunity testing，就是执行其他的session的功能)
这里每个ET tester完成一个Session过后，必须记录session sheet，下面是主要的因素：
(1) Session Charter (charter名称，和session名称)
(2) Tester name(s)
(3) Data and time started
(4) TBS metrics (包括3个方面的effort统计：测试设计和执行，bug分析和报告，session setup)
(5) Data files
(6) Test notes(ET 过程中的随时记录的一些东西，比如test ideas, risk list 等)
(7) Issues(ET 过程中的问题和疑惑)
(8) Bugs
1.4 ET中管理Session
下面我们继续ET在项目中的管理(这里说的是上述的模型三或四)，大致如下在：
Lead针对SUT做出Charters和Sessions
Lead针对所有sessions和资源来做出Test plan和测试策略(包含对SUT的攻击策略)
设计阶段ET tester对于自己负责的sessions进行test idea development
设计阶段ET tester还需要对自己负责的session所对应的oracles(可以准确任务这个问题是个bug的所有信息,包括文档) 进行梳理
测试执行的时候ET tester根据之前的test idea list来进行测试，根据SUT本身的response并采用Heuristics的方法产出更多的test idea(这部分的test idea 不是必要记录下来)
测试执行的时候每个测试人员填写自己的session sheet
Lead每天汇总每个测试人员的session sheet
利用自己开发的工具支持分析所有的sessions的执行情况
根据分析结果得到测试进度的具体执行情况和质量情况
这里的工具会提供足够多的数据来支撑我们的测试进度是否在合理的范围内，是否存在哪些风险，哪些测试人员在Non-session中花了时间过多等等。由于产出的metrix提供足够的信息去控制整个ET进度，我们当然还需要了解未来的计划安排，所以metrix里面会有个item叫To DO Sessions来表明我们未完成的session数量。 还可以帮我们更加的评估我们ET中的生产率，同时也可以评估我们ET tester的快速学习能力。
至于这个管理和进度控制的方式是否可行呢?本人有幸采用了Freestyle ET的方式和这个管理方式来实践了XX项目, 实践遇到的问题很多，总结也很多，其中最大的问题也就是我们需要花大力气解决的就是如何开展每个session的测试工作，也就是之前说的那个Heuristics的方法快速的产生更多的更好的test idea。 另外一个就是TL是如何更好的对于SUT进行Charters和Sessions的划分并安排合理的资源去跟踪。
--------------------------------
之前讲了些ET在项目时间过程中是如果来管理的，那么ET tester在拿到自己的任务的时候，自己是怎么来进行ET的呢?
这里我们先考虑2个状态，一个是ET tester的状态，哪些状态呢?
(1)这个ET tester的测试经验怎么样，丰富还是欠缺?
(2)这个ET tester 对AUT的行业经验怎么样，熟悉还是了解?
(3)这个ET tester对AUT本身的功能需求了解怎么样，熟悉还是了解?
不管上面的状态怎么样，在压力下，ET tester采用正确的方法进行ET，往往会取得好的效果的。
那么我们就来分析下ET的一些思维变化吧：
首先这个ET tester要非常清楚自己的状态，也就是自己所拥有的Knowledge，具体包括这些：
(1) 该产品的知识
(2) 测试技术相关的知识
(3) 该产品所在的行业知识
(4) 基本的计算机基本知识
为啥要去check这些知识呢?这样为了方便我们在做ET的时候，能够快速和有方法的确定发现的问题是否是个Bug。
国外有很多这方面的总结，怎么去找到这些证据去确定发现的问题是不是个Bug，这些东西就叫Oracle，使用这个方法来找到：the HICCUPPS(F) heuristic：
(1) History: 目前所做的产品的版本是否与过去的版本是一致的。
(2) Image：这个产品是否与项目组织所想要的image是一致的。
(3) Comparable Products:这个产品是否与相类似的产品是一致的。
(4) Claims：这个产品是否与重要的人所说的那样是一致的。
(5) User’s Expectations: 这个产品是否与用户所想要的是一致的。
(6) Product:这个产品的每个元素是否与同个产品里面的可比较的元素一致。
(7) Purpose: 这个产品是否与其目的(明确的或含糊的)一致。
(8) Statues: 这个产品是否与可适用的法律一致。
(9) Familiarity: 这个产品与任何通用的问题的形式是不一致的。
尽管我们有很多方式去壮大我们的oracles，但这需要很多成本的，所以我们在做ET 过程中，会遇到：
(1)没有oracle可以使我们提前确定这肯定是个正确或错误的结果。
(2)没有一个单独的oracle可以说明某个功能在所有时间或所有情况下都是正确工作的。
(3)有些功能看上去是正常工作的，但事实上在某些情况下会失败而且会使得所有的oracles都是不对的。
可以看到我们在积累我们的oracles时，肯定会遇到很多oracle问题，我们该如何来解决呢?
(1)忽略这个问题(也许这个信息的价值从成本角度考虑不值得)
(2)简单化这个问题(需要可测试性，从需求源头开始)
(3)转移这个问题(并列测试，从类似问题下手)
这里面很多人都可以看到那就是我们怎么去做测试，怎么快速的产出test idea。
ET的特点是我们做测试的时候，没有测试用例指导，学习SUT，和测试设计和测试执行在同一段时间内完成。那怎么去做测试执行呢?我们拿到开发提交的系统后，Lead分配给我们的任务后，该从哪里下手呢?
ET大师James Bach说过，执行ET就像对一个人进行面试一样，那这样就少不了要问问题，该怎么问问题?通过面试者的回答怎样快速提出更好的问题?显然这里面也需要一定的能力，包括如下：
(1)提出有用的问题
(2)观察什么事情在发生
(3)描述自己能够感觉到的东西
(4)对于自己的所知进行批判性的思考
(5)组织和管理业务上的规则
(6)能够设计假设和进行试验
(7)尽管已经知道了仍然进行思考
(8)分析其他人的思考方式
(9)根据因果关系进行推导
好了，现在ET tester都对自己的knowledge有所了解了，接下来就是对于自己的任务，哪个UC,哪个模块进行分析了，怎么分析，分析啥呢?
(1)风险
(2)覆盖率
(3)Oracles
(4)资源或限制
(5)价值或成本
(6)Bugs
这些分析都做好了，那我们就可以开始进行测试了，也就是对我们的SUT进行试验，就像“question<—>answer”的循环一样。
那我们是怎么来进行试验的，具体包括如下几个过程：
(1)配置
—安装产品
—为测试执行准备测试数据和工具
—确认产品是个足够干净的起始状态
—根据自己的任务准备一个有激发性的问题
(2)操作
—通过问题对产品进行试探性的输入来使用这个产品
—使用正确的数据和正确的业务顺序来完成正确功能的练习
(3)观察
—收集关于这个产品是如何工作(正确或错误的输入)的信息来评价产品是否如此工作
(4)评估
—应用之前得到的oracles来发现bugs
之前也说过了，我们的ET是学习和测试设计和测试执行是同一时间完成的，那么我们的测试就是Testing to learn。这边有几个步骤：
(1)形成一个关于产品功能的模型
(2)去了解这个产品是想实现什么样的功能
(3)列出那些你需要测试的产品的因素
(4)查看那些一致性的关系且尝试多个不一样的oracle
(5)产生测试数据
(6)考虑其可测试性和尝试不同的有用的工具
(7)尝试多种不同的方法去试验
(8)报告你所发现的bug
ET tester在试验的过程中，如果遇到比较困惑的问题该怎么呢?
(1)简化自己的测试用例
(2)保存当时的状态
(3)不断重复执行自己的action
(4)返回到一个已确认过的状态
(5)优先使用OFAT方式(一次只考虑一个因素)
(6)做出精确的观察
之前也说到了我们需要用Heurisitcs来产生更多更好的test idea。其实对于Heurisitcs来说，有如下几种类型：
(1)Guideword Heurisitcs：一些词语或标签能使ET tester看到自己的knowledge并且根据自己的经验分析一些新的东西
(2)Trigger Heurisitcs:一些存在于事件或条件中的想法能帮助ET tester认为现在可以采用另外一种方式来进行试验，就像思维的闹钟提醒一样
(3)Subtitle Heurisitcs:能帮助ET tester重构想法并想到更多的选择点，或在一个谈话中找到其中的假设
(4)Heurisitcs Model:能帮助ET tester控制和管理和挖掘更多的想法和实体
我们做ET测试过程中，下一个test idea是不可预知的，完全依赖本次测试用例的执行情况来判定，那么就存在对于一个小的疑惑问题是进行深入挖掘还是跳出其循环呢，这种过程在ET过程中很常见，称之为Plunge in and Quit Heurisitc，下面是详细解释：
一旦我们决定去测试一些看似比较复杂或有困难的地方，就直接Plunge in;但如果我们非常困惑或感觉自己完全被Block了，就Quit。
这样就意味着我们可以开始任何测试却没有要求一定要成功完成并得到结果，也就是我们不需要一个完整的计划，当然我们循环着Plunge in and Quit，就会产出一个新的计划。
同样的可以解释我们在ET测试过程中，存在分支是非常好的，也就是说不停地产生新的分支(test idea)，而不是一条直线走到底。所以在ET测试过程中，尽量的让自己走更多的分支，因为我们根本不知道走另外一个分支后，会发生什么事情，但凡事都有个度，我们需要定期的去check我们现在测试的东西是否与我们被分配到的任务是否一致。防止过多的时间花在之前说过的Opportunity testing上。
之前讲了些ET在项目时间过程中是怎么来使用Heuristics，这期要说下ET过程在总体上的思考和怎么样来考虑覆盖率的问题。
回到之前所说的，当我们拿到自己的任务的时候，知道了自己需要测试哪些模块，就需要一个策略去进行ET测试，我们可以考虑如下：
学习这个产品：
—–思考这个产品存在一些重要的潜在的问题
—–思考怎么去探索这个产品才能找到这些问题
——一般情况下，思考怎么去探索这个产品，思考的方式有这些：
充分利用自己现有的资源：
—-包括：用户，文档信息，开发人员关系，同事，设备和工具，计划等
使用一些不同的技术的混合体：
—-包括：功能测试，域测试，压力测试，流程测试，场景测试，用户测试，风险测试，自动化测试，声明测试
利用自己实际能够做的东西：
—-包括：自己擅长的，最容易暴露问题的，自己的时间和精力
另外在做ET过程中，需要不断的变化我们的测试思路去攻击SUT，但一般我们会采用哪些方法或思路去变化我们的test idea呢?
微小的行为：其他的人或不用心的人改变了一点点思路，可能会产生新的test idea。
随机性：能够让你从那些有选择性的偏见中走出来
数据交换：同样的操作，在不同的数据库中，或不同的输入，会得到很不同的结果。
平台替换：推测类似的平台，但却不支持某种操作
时间/并发变化：同样的操作，改变依赖其发生的时间周期或并发的事件时，会得到很不同的结果。
场景变化：同样的功能，当我们在一个不同的流程或上下文环境下，会出现截然不同的操作方式。
状态污染: 一个复杂的系统，一般会有很多隐藏的变量，通过改变某些操作的顺序，级数，类型，会加快程序状态污染，从而发现隐藏问题。
敏感度和期望值：不同的测试人员可能对不同的因素，会有不同的敏感，且有看到不同的区域。同一个测试人员在不同的时间可看到不同的东西。
为了在复杂的系统中快速发现未期望的问题/持续使用才会出现难懂的问题，更多的问题，我们必须De-Focus：
1.从一个不同的状态开始(没有必要清除状态)
2.优先进行复杂且有条件的action
3.从模型的变化中产生test idea
4.质疑我们的试验流程和工具
5.试着去观察每个东西
6.宁愿使我们的测试很难通过，也不能太顾忌问题的重现难易程度
下面从一个模型中来说明怎么开始ET测试，选择一个有用的，有趣的，容易开始的点：
这里还是需要详细说明下：Knowledge，Analysis，Experiment，Testing Story.
Knowledge: Product Story; Technical Knowledge; Domain Knowledge; General knowledge.
Analysis: Risk; Coverage; Oracles; Resources/Constraints; Value/Cost; Bugs .
Experiment: Configure; Operate; Observe; Evaluate.
Testing Story: Test Plan/Report; Work Products; Status.
上面说了很多，之前也说过，但细心地就可以发现，我们还没说Coverage这个关键东西。在ET实践过程中，同样在理论形成过程中，Coverage永远是一个很大的问题，很多人都说ET最不能保证的就是Coverage，所以不敢轻易去尝试。那么ET在Coverage是不是就是这样不靠谱呢?事实上，不管你采用ST还是ET，对于Coverage都是很难完全保证的，但我们可以在Coverage上做些努力，下面说下ET在Coverage上是怎么考虑的。
我们说的Coverage一般就是Product coverage，同样也是这个被测产品的一部分。那么对于Product coverage又包括哪些方面的coverage：
第一个就是Structure，也就是产品的一个因素，对于这个Structural Coverage，我们到底是测试什么呢?我们到底要cover什么呢?我们要测试的就是这个产品时怎么构成的，我们要cover的就是构成这个产品的部分。我们以打印机产品为例，看看Structural Coverage到底要考虑什么：
——打印需要用到的文件
——实现打印功能的代码模块
——在这个模块里面的代码语句
——在这个模块里面的代码分支
可以看到这个时候我们关注的是产品的内部结构。
第二个就是Function，也是产品的一个因素，对于这个Functional Coverage，我们到底是测试什么呢?我们到底要cover什么呢?我们要测试的就是这个产品能够做什么?我们要cover的就是这个产品做得什么样。同样以打印机产品为例，看看Functional Coverage到底要考虑什么：
——打印，页设置，打印预览
——打印range，打印复制，zoom
——打印所有的，当前页，或指定的range
可以看到这个时候我们关注的是产品的功能。
第三个就是Data，也是产品的一个因素，对于这个Data Coverage，我们到底是测试什么呢?我们到底要cover什么呢?我们要测试的就是这个产品能够对数据能够做什么?我们要cover的就是这个产品能够处理什么样的数据。同样以打印机产品为例，看看Data Coverage到底要考虑什么：
——打印文档的类型
——文档里面的元素，文档的大小和结构
——关于怎么打印的数据(比如zoom factor; no. of copies)
可以看到这个时候我们关注的是产品使用过程中不同的数据处理。
第四个就是Platform，也是产品的一个因素，对于这个Platform Coverage，我们到底是测试什么呢?我们到底要cover什么呢?我们要测试的就是这个产品依赖什么才能使用?我们要cover的就是这个产品怎么处理不同的依赖的。同样以打印机产品为例，看看Platform Coverage到底要考虑什么：
——打印机，Spoolers，network behavior
——计算机
——操作系统
——打印机驱动程序/设备
可以看到这个时候我们关注的是产品使用过程中不同的环境和依赖。
第五个就是Operation，也是产品的一个因素，对于这个Operations Coverage，我们到底是测试什么呢?我们到底要cover什么呢?我们要测试的就是这个产品怎么使用的?我们要cover的就是这个产品使用的步骤是否合理/正确。同样以打印机产品为例，看看Operations Coverage到底要考虑什么：
——默认情况下使用
——真实环境下使用
——真实的场景下使用
——复杂的流程下使用
可以看到这个时候我们关注的是产品使用的场景(包括稳定性，可用性，安全性，可扩展性，性能，可安装性，兼容性，可测性，维护性，本地性等)。
第六个就是Time，也是产品的一个因素，对于这个Time Coverage，我们到底是测试什么呢?我们到底要cover什么呢?我们要测试的就是这个产品在什么时间情况下会受影响?我们要cover的就是这个产品在不同的时间下会表现什么样。同样以打印机产品为例，看看Time Coverage到底要考虑什么：
——尝试在不同的网络或端口的速度使用
——一个文档打印完，紧接着打印另一个文档，或隔很长时间再打印
——尝试与时间相关的限制，比如使用spooling, buffering, timeouts
——尝试hourly，daily，月底，或年底打印报告
——尝试从不同的2个工作站同时打印
可以看到这个时候我们关注的是产品使用的时候是否受时间影响。
最后说下，ET强调的是尽量的简化写文档的时间，但我们还是需要一些文档的支持的，以便管理层跟踪和做出正确的决定。ET的文档包括如下2大块：
通用的文档：Testing Heuristics;Risk Category
项目相关的文档：Coverage Model;Risk Model;Test Strategy Reference;Schedule;Issues;Bugs;Status Dashboard
这里我们可以看到ET所做文档确实不多，这就需要我们在ET过程中，准确实时的Taking Notes，主要包括这些：
Coverage (测试了哪些，覆盖了哪些点)
Oracles (测试过程中，发现或依赖的oracle)
Procedures(只要关键的流程就可以)
Test Ideas(关键的测试思路以及check point)
Bugs/Risks (发现的问题以及风险)
Issues/Questions/Anomalies
-----------------------------------------
之前我们说了很多ET的过程以及怎么去做ET，也说过ET和ST的关系，是怎么来用在我们的项目过程中的，但很多人对于ET能发现的bug类型有很大的好奇，认为ET能发现什么样的bug，是不是很严重，是不是很难发现，是不是效率很高，这次我们就来说说，ET和ST之间的生产率比较。
首先说明的是这个生产率比较是某个大学的研究成果，有一些基本的条件，比如实验者，选择的实验的产品，实验者的经验等等。这里不详细说明这个，也不说明过程(其中遇到很多的挑战)，只说下结果，让大家了解下。
说一个关键的条件(对于bug，研究方之前就分开了已知和未知bug)总体过程：
| Phase | Group 1 | Group 2 |
| Preparation | 对于feature A写测试用例 | 对于feature B写测试用例 |
| Testing Session 1 | 对于feature A做ST | 对于feature A做ET |
| Testing Session 2 | 对于feature B做ET | 对于feature B做ST |
对于Testing Session 再说明下：
| Phase | 时间 | 描述 |
| Session Setup | 15 min | 看产品的介绍和指导书或做些基本准备工作 |
| Functional Testing | 90 min | 专注于ET或ST和报bug |
| bug report | 10 min | 对于所报bug和log写report |
(1) 发现的bug总数
| Testing approach | Feature set | Bug 总数 |
| ET | A | 44 |
| B | 41 | |
| Total | 85 | |
| ST | A | 43 |
| B | 39 | |
| Total | 82 |
这里面的结论是：对于已知bug(研究者故意注入在产品中的bug)来说，使用ET或ST方法在发现bug总数上没有区别;但ET却可以发现更多的未知bug。
(2) Bug发现难度，类型和严重程度
| Mode | ET | ST | ET/ST | Bug 总数 |
| 0=easiest123=hardest | 120 | 93 | 129% | 213 |
| 327 | 320 | 102% | 647 | |
| 89 | 75 | 119% | 164 | |
| 20 | 15 | 133% | 35 | |
| Total | 556 | 503 | 111% | 1059 |
这里的结论是：ET发现更多的bug在各种发现难度上，相比较ST而言。
Bug类型：
| Type | ET | ST | ET/ST | Bug 总数 |
| Documentation | 8 | 4 | 200% | 12 |
| GUI | 70 | 49 | 143% | 119 |
| Inconsistency | 5 | 3 | 167% | 8 |
| Missing function | 98 | 96 | 102% | 194 |
| Performance | 39 | 41 | 95% | 80 |
| Technical defect | 54 | 66 | 82% | 120 |
| Usability | 19 | 5 | 380% | 24 |
| Wrong function | 263 | 239 | 110% | 502 |
| Total | 556 | 503 | 111% | 1059 |
这里的结论是：ET在GUI和Usability这2个类型上ET有比较大的优势，但在Technical defect上，ST比ET要好一些。
Bug严重程度：
| Severity | ET | ST | ET/ST | Bug 总数 |
| Negligible | 23 | 14 | 164% | 37 |
| Minor | 98 | 74 | 132% | 172 |
| Normal | 231 | 203 | 114% | 434 |
| Severe | 153 | 160 | 96% | 313 |
| Critical | 51 | 52 | 98% | 103 |
| Total | 556 | 503 | 111% | 1059 |
这里的结论是：ET在严重程度较小的上面有比较大的优势，其他无较大差别。
(3) 错误bug的报告
| Testing approach | Feature set | 平均Bug 数 |
| ET | A | 1.396 |
| B | 1.191 | |
| Total | 1.291 | |
| ST | A | 1.564 |
| B | 1.867 | |
| Total | 1.767 |
这里的结论是：相比较ST而言，ET报告了较少的错误bug。
看到了如上的结果，我想我们很多人都会有很多问题，研究者也想到了以下问题：
问题一：已经写好了的测试用例是怎样影响发现bug的数量呢?
之前说的条件，还有个重要的条件，细心的人肯定可以看出，那就是做ST的那些实验者花了7个小时用在编写测试用例上面了，而做ET的实验者根本没有花时间在这上面，这可以看出，当没有时间写测试用例的时候，ET明显更高效。
问题二：已经写好了的测试用例是怎样影响发现bug的类型呢?
我们已经从3个维度(严重程度，类型，发现难度)来说明了，认为测试人员不需要测试用例就可以发现很多User interface和Usability 相关的问题，但考虑到严重程度，测试人员不需要测试用例会发现严重程度较低的问题。
尽管我们得到了这些结果，但仍然有其局限性，实验者的测试经验会影响其测试用例的质量和做ET测试执行时候的质量。
以上我们可以看到仅仅关注与测试设计技术并不能覆盖很多重要的方面，而这些方面只有在手工测试执行的时候发现的。还有一个方面就是ET方法更能提高测试人员在测试执行的时候的创造性和能力。
本人使用Freestyle ET方法实践了2个项目，其数据还是比较匹配上面的结果的，只是个人认为在Wrong function 的bug类型上面ET反而会发现较少的bug，而不是更多。还有就是误报bug 这方面，个人认为ET之后会产出很多疑问而并非是bug，只是嫌疑bug，而需要与相关的人进行确认，这样就会减少误报率(详见ET项目实践结果分析)。
参考Juha ltkonen, Mika V. Mantyla and Casper Lassenius 《Defect Detection Efficiency: Test Case Based vs. Exploratory Testing》
-------------------------------------
大家都喜欢在实践中看看效果，那么现在大家都理解了ET了，就很希望在一个项目过程中来实践ET，实践的具体流程是什么呢?需要考虑什么异常情况呢?接下来就说说ET实践的总体流程(这个流程是非常官方且标准的ET实践流程，曾由James Bach 写给微软做windows产品兼容性测试任务的官方证据)：
这个流程大体上包括3个部分：
—-Working with Functions
—-Testing Functionality and Stability
—-Test Procedure
这里面就说下前面2个大点：
1.1 Working with Functions
这个流程是围绕着功能来组织的。所谓功能就是一个软件所要假定要做的事情。这就包括任何显示的，改变内部或外部数据的，或影响环境的任何结果。当然功能一般都包含子功能。比如：在微软word里面”打印”功能就包含”复制几份”和”页面范围设置”2个子功能.
由于我们需要测试所有东西，就必须通过制定基本风险的决策来简单化哪些功能需要花费多少精力。我们把所有的功能分为2大类：主要的，贡献性的。大部分情况，我们需要记录和测试主要的功能。至于这些功能该怎么样的分类和组合是根据情况来定的。你也许会认为一组贡献性的功能可以作为一个单独的主要功能，或一个单独的主要的功能能够分解为主要的和贡献性的子功能。
如果可能的话，我们想去测试所有的主要功能，但可能没有足够的时间去做。这种情况，需要对你将测试的和不会测试的主要功能做一个文档的记录。
如果只看用户反映的话，就很难识别出一些功能。有些功能是与操作系统，其他程序，或修改文件进行直接交互，而这些在显示上并不能直接看到效果。需要重视那些重要的且有可能是部分隐藏的功能。
如下定义功能的分类的方式：
| 定义 | 说明 |
| 主要的功能：从一个普通用户看来，一些比较重要的功能，而且它的不易操作性和危害都使得这个产品的目的没有达到 | 一个功能是否是主要的与这个产品的目的以及对于这个目的来说，这个功能是否是必须的有关 |
| 贡献性的功能：这些功能使得这个产品更加有实用性，但不是主要功能，能使用户更兴奋的功能 | 就像主要的功能的辅助功能，类似于增值服务类型的，从可用性角度会发现一些 |
1.2 Testing Functionality and Stability
我们测试大部分是测试功能性和稳定性的问题，那我们就必须有通过测试的标准，如下是定义的标准：
| 定义 | 通过标准 | 失败标准 |
| 功能性 (产品提供的功能的有效性) | 每个主要的功能其操作的结果与其目的都是一致的，其输出的结果的正确性都经过测试的。 | 至少有一个主要功能与产品的目的不一致 |
| 对于正常使用任何不正确的行为并没有严重损害用户的利益 | 对于正常使用任何不正确的行为严重损害用户的利益 | |
| 稳定性 (持续性的提供功能的能力，且没有失败) | 产品没有毁坏系统或平台 | 产品毁坏其系统或平台 |
| 产品没有挂掉，毁坏，或数据丢失 | 产品挂掉，毁坏，或数据丢失 | |
| 测试过程中，没有主要的功能存在不易操作性或失效 | 测试过程中，存在主要的功能存在不易操作性或失效 |
Test Coverage
测试覆盖率就是将要测试什么?如下的测试覆盖率是需要的：
在时间允许下合理的测试所有的主要的功能。让lead知道有哪些主要的功能没有时间测试或没有能力测试?我们可以对一个有趣的贡献性的功能进行测试。也有可能在探索和测试主要功能时接触更多的贡献性的功能。
选择一些潜在的不稳定因素进行测试和选择一些有可能触发不稳定的功能的数据进行测试。一般情况下，选择5到10个。Lead会决定对于这个功能性和稳定性的测试需要多长时间，一般是花80%的时间在主要的功能上，10%在贡献性的功能上，10%在不稳定的方面。
Sources and Oracles
我们在做ET过程中，是怎么知道这个产品就是应该这样做的呢?我们是怎么知道它什么时候不该这样处理的呢?这里如果我们需要回答很好的话，并使得lead满意，必须考虑下面2个方面：
Sources：就是做ET过程中需要的信息的来源。有时是你自己的灵感或经验。但更多的是我们已经了解了相关的产品文档。而且大部分情况，我们需要经常与相关人员确认该产品的目的和功能。
Oracles：就是做ET过程中确定所看到的产品的行为是否正确的策略。也就是回答：你怎么知道它就是这样工作的?’
一般使用下面几个方式去确定Oracles(ET的过程分析里面也讲过):
与目的一致：功能的行为与产品的目的是一致的。
与产品本身一致：这个功能的行为与这个产品的相关的功能或功能实现方式是一致的。
与历史一致：现在的功能的行为与以前的功能行为是一致的。
与相比较的产品一致：这个功能的行为与相比较的产品的类似功能的行为是一致的。
Task Sheets
这个流程包括5个任务，而且每个任务都包含下面5个元素：
任务描述，Heuristics，结果，任务完成标准，FAQ
我们在做任何一个任务的时候，肯定会遇到很多问题，而且有些问题必须反馈给lead，一般如下情况需要反馈给lead，并咨询他如何处理这些问题：
—-当你遇到一个问题会阻碍你完成一个或多个测试任务的时候。
—-当你对于这个产品的复杂度感到困惑的时候。
—-当你在限定的时间内因为不能很好的了解系统而不能很好的进行测试的时候。
—-当你遇到一个问题有可能会严重影响到产品的功能性或稳定性的时候。
—-当你认为由于这个产品的复杂度而需要比原先分配的还要多的时间进行测试的时候。
-------------------------------------------------
这次我们说下第3大块的流程，那就是Test Procedure，这里面有5大任务：
(1) 确定产品的目的
(2) 确定产品功能
(3) 确定潜在不稳定的地方
(4) 测试每个功能且记录问题
(5) 设计和记录一个持续性的验证测试
| 产出 | 退出标准 |
| 目的陈述功能列表潜在的不稳定和有挑战性数据的列表产品错误和注意点 持续性验证测试 |
每个任务都完成了每个问题或疑惑都被测试经理解决了或接受了每个人员的产出都被测试经理接受了有足够的信息可证明这个产品在功能性和稳定性上通过验收 |
1.1 Identify the purpose of the product
评审这个产品并确定这个产品需要提供的基本服务，如果可以的话，定义这个产品的使用者。写一段话简单说明下这个产品的目的和目标用户。
一些在目的陈述中用到的潜在的目的动词
创建，编辑
查看，分析，报告
打印
解决，计算
管理，控制
通信，交互
提供数据，提供介入，搜索
支持，保护，维护
清除，解决，使其完善
读，过滤，转移，转变
一些在目的陈述中对用户的能力的讨论
特殊技能，知识，能力，或无能
解决问题的能力
期望或需要
限制 (谁不会是这个产品的使用者)
| 产出 | 退出标准 |
| 目的陈述问题/争论点 | 像上述那样完成任务这个”目的陈述”必须都是经过需求方的确认从这个产品的目的中选择对于用户来说的最重要的方面 |
常见的问题:
为啥这个任务很重要?
如果没有对这个产品的目的有所了解，就不能很好的区分主要的和贡献性的功能。由于测试的大部分精力用在主要的功能上，所以这些区别是非常关键的。而我们不需要长篇大论，只要这个目的陈述里包含足够的信息来让我们跟踪重要的可作为主要的功能就可以了。
该怎样来写这个目的陈述呢?
如果需求方提供了这个产品说明包含了用户的调研，那我们可以从这个开始先过一遍，写这个过程中，可以使用动词+名称的形式，比如’编辑简单文本文件’ 或 ‘一个用户无合法性的授权产生合法性的文档’。而且如果这个产品有些目的需要一些特殊的属性(相对于一般用户)，一定要在目的陈述中写清楚。而这些目的动词可以从之前说过的目的动词库中取(也可以丰富动词库)，这也可以帮助我们注意到一些容易忘记的一些产品目的。
怎样区别目的和功能呢?
目的是和用户的需求相关的。功能是和这个产品所提供或产生的一些具体的东西相关的。
有时候一个功能的目的和这个功能的名称是一样的，比如’打印’:打印就是这个打印功能的目的。大多数时候，一个功能都提供了一个可以确定的更通用的目标。比如：一个文字处理器的目的就不是查找和替代文本;其实查找和替代就是编辑文本的一部分而已。编辑才是真正的目的。另外一方面，如果一个产品具有’ 超级搜索和替代’，那搜索和替代功能就可以是这个产品的目的。
1.2 Identify functions
首先走遍整个产品并发现产品在做什么。
对于所有的主要的功能做一个概要。
记录一些有趣的或次要的贡献性的功能。
对于我们不知道怎么去分类的或者觉得自己不能测试的任何功能，把它告诉测试经理。
一些查找出功能的途径：
查看下在线帮助
查看下需求方的调查问卷
查看组成这个产品的所有程序
查看产品所有菜单
查看所有的窗口
查看工具栏
查看所有对话框和小工具
右击查看所有数据对象，接口定义，窗口方框
双击查看所有数据对象，接口定义，窗口方框
查看产品所有为功能状态转换的选项设置
查看只有特殊的输入才能触发的功能
查看浸透在其他功能中的错误处理和恢复功能
功能分类:
主要的功能
贡献性的功能
| 产出 | 退出标准 |
| 功能列表问题/争论点 | 像上述那样完成任务每个定义的主要的功能对于产品目的完成都是必须的已经合理的包含了贡献性的功能 |
常见的问题
1. 为啥这个任务重要呢?
对这些功能的罗列，我们可以对将要测试的功能做一个概要。当完成测试的时候，这个概要可以作为我们理解这个产品和测试范围的一个标记。这个功能概要对于测试经理或需求方来说都是一个很重要的记录，并且可以作为参考，防止他们(包括将来被其他的测试人员咨询)问我们做了什么，没有做什么。
2. 如果完全不知道哪些是主要的功能该怎么办?
报告给测试经理，不要随意的选择。测试经理会和需求方沟通，确定相关文档，或者会建议你去做什么。
3. 该以什么样的格式来记录这些功能呢?
要简单。使用2-3级的概要记录。有时一个功能并没有官方的名称或标记。也可以列出一些原始功能组。
如果要定义贡献性的功能，将它和主要的功能做清晰的区别。
例如：如下是一个关于微软书签的功能概要：
笔记…..
新增当前文章
删除
转到
评注
搜索所有…..
关于文章….
文章内容包括文字….
查找媒体
所有媒体
视频
图像
动漫
高级搜索
书籍
媒体
文章
1.3 Identify areas of potential instability
在探索这个产品的时候，注意到有些功能很有可能威胁这个产品的稳定标准。选择5-10个功能或功能组特别实施不稳定性测试。我们也许会选择贡献性的功能，如果它们特别容易失败，但主要的功能的不稳定才是我们最关注的。确认那些会引起产品不稳定的功能该如何测试。考虑超大的，复杂的或者有挑战性的输入。用列表将我们选择的那些不稳定的地方列出来，并且写出一些在测试他们的过程中使用到的数据或策略。
一些潜在的不稳定的因素:
与其他产品进行交互的功能
那些会消耗大量内存的功能
那些与操作系统交互特别紧密的功能
那些非一般复杂的功能
那些需要改变一些操作参数配置的功能
那些需要改变操作系统配置的功能
那些获取错误的和从错误中恢复的功能
那些替代了基本的操作系统功能的功能
那些涉及了多线程工作的功能
那些同时操作多个文件的功能
那些需要从网络上打开文件的功能
关于挑战性的数据的一些想法:
文档：大的文档;同时打开许多文档;或文档中包含许多不同的对象
记录：长的记录;很大数量的记录;或复杂的记录
列表：长的列表;空的列表;多列的列表
字段：输入大量字符，非常大的值
变化：新增和删除一些东西;编辑但没有保存或编辑
负载：使大量进程同时运行;大量进行批处理;在很短时间做很多事
无推断：在窗口随意点击;随意输入字符;输入无期望的值
异常和恢复：多次破坏进程;取消操作;使用错误数据触发错误处理
| 产出 | 退出标准 |
| 潜在的不稳定功能和挑战性数据列表问题/争论点 | 像上述那样完成任务这里每个定义的都是我们将要测试或已经测试的对于定义好的不稳定功能，可以说明原因和来源 |
常见的问题：
1. 为啥这个任务重要呢?
我们可以关注最有可能出现不稳定的地方并进行测试，这是个不错的想法。而且有时候我们使用到的输入数据也很有可能触发不稳定。
2. 什么是不稳定性?
任何威胁稳定性标准的行为都是产品的不稳定性。常见的不稳定就是系统挂了。而功能失败和不稳定最基本的区别：就是后者功能有时候可以正常工作，但有时候又不能。这个功能是不可靠的，但又不是完全不可操作的。当一个功能在某些方式下可以正确工作，但又有不好的方面(破坏其他功能或产品)，这就叫不稳定。
3. 我们该怎么知道这里有潜在的不稳定呢?
我们不可能非常确定的知道。我们需要用到的是使用基本的线索去探索。我们在探索性的使用这个产品的时候，会有些感觉哪里会可能有潜在的不稳定。这是我们可以快速的测试来验证我们最初的猜疑. 假设我们怀疑某个特殊的功能存在不稳定的因素，因为这个功能非常复杂而且看起来会消耗大量的内存。这时我们可以通过查看可见的输入和输出的复杂度和操作行为的变化来验证其功能的复杂度。一旦我们确定了这个功能可能会不稳定，我们可以对这个功能进行覆盖和加压测试。一旦是测试稳定性，就可以不要使用普通的输入参数。
参考自James Bach 的《General Functionality and Stability Test Procedures》
---------------------------------
前面说到了很多流程性的指导，也说了ET和ST的生产率的比较，但实际的情况到底怎么样呢，这里大概说下ET的实践结果分析：
ET实践项目：XX1项目
ET实践时间段：09/12/15—09/12/21
ET实践人：季哥
此ET实践结果分析包括如下几个部分：
简要说明什么是ET
ET测试的范围
为何要做ET
什么时候开始做ET
怎样做ET
做ET时注意什么
ET产出了什么
ET发现了什么样的bug
1. What1：什么是ET?
这里的ET定义就是实践与XX1项目的定义：就是在完全不熟悉项目业务需求的基础上，采用边学产品知识，边测试，通过一些手段来操作产品，使其暴漏出一些隐含的问题。其测试执行思路与测试设计思路是同时进行的。一个很明显的Freestyle ET方式。
2. What2: ET测试了什么?
由于大部分项目存在一些共性，ET测试的范围一般是主要的功能的实现，再加上主要的功能中隐含的一些潜在的风险，例如超长输入引出的系统错误等。具体可参见ET实践流程。
3. Why：为啥要做ET?
至于做ET实践的原因多方面：
———目前项目测试人员的功能测试手段太单一
———目前第3轮测试发现的bug率以及投资回报率很低
———为了质疑目前测试部3轮测试的流程规范
———国外已经有了比较成熟的ET理论和实践经验
———创新并实践前段时间ET的理论学习
4. When：什么时候开始做ET?
根据ET测试的方式和目的以及时间安排，可看出ET并不是为了发现主要功能的流程问题。所以特别需要在相对稳定的系统上做ET，这里有两个好处：一是由于ET测试人员没有项目测试人员对需求了解深入，对于主要功能的流程问题没有项目测试人员发现那么及时以及深入。二是在稳定的系统上做ET，有益于发现项目测试人员的盲点，以及发挥测试的极限测试手段，同时也有益于ET测试产出的效果。所以在XX1项目ET实践过程中，是在第二轮测试的最后一天开始 ET。一般是在安全测试通过后。因为安全测试的bug修复后会引发比较多的页面bug，此在一定程度上影响ET发现较严重的bug数量。
5. How：怎么做ET?
根据国外ET实践理念，采用Session来进行测试范围的确定(具体请看ET的管理)，下面是简单的一些说明：
第一步: 大概花1-2个小时时间看PRD和原型。
第二步: 大概花1-2个小时时间确定下有哪些主要的功能模块和贡献性的功能模块。
第三步： 与项目组测试人员沟通哪个功能模块发现bug最多，哪个功能模块发现bug最少，哪个模块存在风险比较大。
第四步：根据前几步情况和参加ET的时间段来确定有多少个Session，并指出每个Session大概花多长时间。一般是1.5-2个小时。就淘宝而言，一个Session大概是2-3个UC的情况。
第五步：制定ET测试计划，包含所有Session的名称和测试时间以及缓冲情况。
第六步：根据ET测试计划，边学习产品需求，边测试。发现问题立马记录问题描述。最后发送ET测试报告。
第七步：与项目组测试人员沟通ET的效果以及该产品存在的风险，从用户易用性角度给该产品总体评价，同时跟踪确认bug的fix情况。
6. Strategy：ET测试的时候怎么考虑?
在做ET过程中，有一个基本的原则就是以最少的学习时间来获取最大的学习成果，也就是在ET过程中，由于系统是个相对稳定的系统，其主要功能的流程问题已经不存在了，这时ET测试人员需要以最少的时间去了解一个产品的某个需求，然后去发现这这个需求的隐含的问题。这里一定要注意不要花很长时间去了解某个复杂业务的具体过程，然后去测试，这样时间投资回报率会比较低。
这就需要ET测试人员在很短的时间内需要判断这个需求需要花多少时间去测试，大概会隐藏什么问题。然后发现一个可挖掘的需求，去多尝试操作去测试，直至发现问题。这些在XX1项目实践过。
ET过程中，尽量去关注一些很细节的部分，多使用一些极限测试的手段，比如超长字符，非法字符，异步编辑等。
ET过程中，如果被一个需求的特殊性卡住，也就是ET测试人员尝试了很多次都没有成功进入下一个操作流程，则这时需要立马与项目组对应测试成员沟通，寻求帮助。也许该成员的一句话就可以搞定这个问题。在XX1项目实践过程中确实遇到过这种情况。
ET过程中，发现一个疑似问题，立马记录其问题描述，等每天的ET测试时间完成后，与该Session的项目组测试人员沟通这些疑似问题是否为bug，并邮件报告每天测试的Session的bug描述以及优先级。
ET过程中，需要ET测试人员全神贯注的进行边学习产品，边测试。在一个Session测试过程中，不能受到其他的干扰，完全沉浸在测试和破坏这个产品的紧张之中，由于需要不断的变化测试思路去挑战正在测试的功能。
7. Result：ET产出了什么?
对于ET的核心价值就是花最少的时间得到最大的回报。该项目实践ET测试的数据如下：
这里功能未实现的bug类型里面主要大部分是一些页面的按钮或链接功能失效。
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测试的效率和知识沉淀的传承是很不利的。
----------------------------------------
原文转自：http://www.ltesting.net
原文转自：http://www.ltesting.net/ceshi/ceshijishu/csgl/et/2012/0621/205157.html