之前讲了些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。