ET那些事儿

时至今日，业内已存在多种ET方法了，也都各有优劣。这其中有一些只适用于特定领域，例如bug bash ET和free style ET等。笔者在这里介绍由James Bach先生创建的一种结构化的ET，其中包括以下几个概念。

·        Session

一个session就是分配给一个ET的时间段，在特定的session内，测试人员可以使用类似于ET Reporter的工具对测试脚印进行记录，类似于dash，建议一个session内tester不要中断，但session的时间可以调整。

·        Charter

为一个ET session设定的目标，描述了一个session的测试范围和测试点。需要注意的是charter不是一个测试计划，不包含任何测试步骤，通常一句简短的描述就可以成为charter。例如“使用AUT不支持的locale”。

·        Scripted Testing

脚本测试，即根据test case进行的测试。前文已经提到，ST跟ET是有本质区别的。ST是比较“传统”的测试方法，依照之前设计好的用例，按步骤执行来判断是否达与预期结果相匹配。

 

以session为基础的ET中，时间框将事先确定好。可以是20、40、60分钟，甚至更长。Session根据内容又可以分为“STB”三个部分，测试人员可以使用类似于ET Reporter的工具来记录每项任务所进行的工作和花费的时间。

S = Setup

在session开始之前是否有需要配置其他前置条件？这些操作所需要的时间都会被认为是测试结果的一部分仪器记录下来，以方便日后的足迹分析。

T = Testing

这是实际花费在ET上的时间，结果可能是例如“en-nz”5分钟，“fi”5分钟。

B = Bug Investigation and Reporting

这是在研究以及报bug过程中，可能需要收集日志，截屏等所需要的时间。

PS. 在一个session内，tester应该保持专注，跟dev编写代码类似，尽量不被电话、会议、IM通讯工具、邮件、社交媒体之类的事件打扰。否则计时也将失去原本应有的意义。

 

首先，如何制定charter的scope呢？

charter或者叫scenario，简明地定义了一个ET进行探索的区域，用于指导测试人员进行探索。charter应该给测试者足够的空间去探索，但有不能太大，这样会让测试变得无从下手。同时又不能太过具体，阻碍了进一步的探索。因为一旦charter过于具体，它将变为一个实实在在的，脚本化的测试用例。一旦charter被创建，就可以来脑图的方式来细化它，或者如前文所述，用类似于ET Reporter的工具进行记录，最终生成一张脑图。

 

另外一个常见的 问题是，我们需要花多少时间在ET上为宜？

我的个人建议是，在一个测试cycle中，使用大约20%的时间进行ET即可。当然，这只是个人观点，在实际测试过程中，tester需要根据自身情况进行调整。

 

还有，何时开始执行ET？

这个要根据AUT的情况分开分析了，对于new feature来说，FC之后即可进入，如果你想测试的更加深入，那么在CC之后对代码进行走读探索也未尝不可。而对legacy的feature呢，tester可以随时开始，尤其是根据历史经验的bug“重灾区”或之前从未踏足过的“无人区”，需要重点照顾。

 

前文还提到了Group ET，这又是什么概念？

它需要是所有参与者在同一个房间，共享相同的环境。他们都在测试相同的功能，但不同的配置。（有点儿类似于A/B测试）这允许测试人员之间的开放沟通，允许讨论的结果，并协助其他人了解的功能，随时给对方一些启发。进行Group ET时，测试人员可以对AUT进行更发散，更广泛的测试和交流，在定点定时的基础上，往往能碰发出新的测试火花。甚至，有的团队还把group ET办成了竞赛的形式，看谁能在只能时间内更多的hack AUT，之后提供奖励。（不过奖品也许只是巧克力，甜甜圈之类的~~~）

 

相比Group ET来说，Individual ET在实际工作中已被更多的使用了。没有前置条件，每个独立的tester随时都可以在独占的环境中开始individual ET。

 

不少人都在问，什么样的人才适合做individual ET呢？他必须是expert么？

我的答案是yes，做individual ET的tester务必是该方面的的专家，或已经积累了不少经验和相关知识的资深测试人员，不是随便一个tester都能完成的。即便赶鸭子上架，结果我认为一定会让人大失所望。

 

至此，笔者已将自身过往的ET经验倾囊相授，希望对大家有所帮助，也欢迎对ET感兴趣的朋友继续ping我，大家一起讨论哦。