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，并咨询他如何处理这些问题：
—-当你遇到一个问题会阻碍你完成一个或多个测试任务的时候。
—-当你对于这个产品的复杂度感到困惑的时候。
—-当你在限定的时间内因为不能很好的了解系统而不能很好的进行测试的时候。
—-当你遇到一个问题有可能会严重影响到产品的功能性或稳定性的时候。
—-当你认为由于这个产品的复杂度而需要比原先分配的还要多的时间进行测试的时候。
相关链接：
