ET Reporter

上文书提到面对ET的几大问题，包括如何进行记录？一旦记录下来，跟ST的区别又是什么？以及即便面对ET的结果，如何判断feature是否被充分覆盖等。

先来说说结果记录，这可是一定要有的，但用什么工具呢？小贴纸，notepad之类原则上其实都是ok的，目的不都是记录下自己探索过的足迹和脚印嘛。但同时考虑到还需要给日后的自己和其他同事作reference，那么简单的贴纸和txt由于不易于管理和分析，就显得不合时宜了。在这里，本文会介绍一种解决记录测试路径的工具ET Reporter（当前仍在内部使用，未开源），供大家参考。

 

ET Reporter本身部署在企业内的私有云环境，客户端无需安装配置，只要tester拥有企业内管理测试用例系统的账号即可（例如本例中的HPQC）。登录时选择对应的project和test set id，创建charter（可以认为是测试点），ET的记录活动就可以开始了。

 

本例中作者模拟输入了一些简单的note

·        Loginwith non-ASCII user

·        Non-ASCIIpwd

·        Username’sboundary

以及对应的concern

·        Loginfail?

·        Supportnon-ASCII pwd?

·        Bytesor chars?

 

Timer栏中的时间是自动记录的，tester只需要指明当前ET处在setup抑或charter testing即可。一旦在ET过程中发现了bug，可以点击右下角的Reportan ETR Bug或link一个已存在bug id。

一个ET dash结束后，点击确定提交，所有ET的相关脚印即可存储到test case的管理系统，即本例中的QC。

当我们拥有了些许这样的ET result之后，ET是否就演变为了ST呢？我个人的答案是肯定的，虽然ET展现出来的形式更多是脑图，而ST更多的是结构化步骤。随着ET的推进，tester经验的逐渐完备，之前的new feature转变为了legacy，积累起来的ET结果也都可以转变为详细的test step和对应的expect result， 以及下一步的automation script。而ET tester又将再一次的对软件中更陌生、更具挑战的领域开始新的探索。

另外关于ET的一些测试流程，何时开始进行ET？什么样的tester又适合来做ET呢？我将在下文中继续和大家一起探讨。