被识别的测试用例的数量 该数字经常是 1，但是每个场景有多个测试用例是可能的。应该包含每个测试用例的原因或目的。
定义的测试用例 测试用例与相关的文当工作一起产生。这包括到驱动需求的链接、测试方法、前置和后置条件、测试数据及可观察的结果。
实现的测试脚本 特定的初始条件，将应用程序导航到测试位置的指导，输入测试数据的顺序，观察结果的方法，结果值的设置。
执行的测试 至少已经执行一次测试脚本。
曾经通过的测试 先前测试执行已经通过了所有构建。可选择地，最近通过的时期。
通过的测试 测试执行通过了最近的迭代。
我们确定表 1 中每个场景和测试中所描述的每个检查点。不论完成或是没完成，它们的值都严格地报告为是或不是的值。我们合计每一层并将其表示为前一个层的某个百分比。目标是达到每一层的 100% 覆盖。总的结果相当粗略，但针对达到最高百分比的工作带来了提前测试工作的非常有意义的副加作用。
缺陷趋势
每个迭代将拥有一个开发包，一些新的特性或场景加入其中并且根据现有场景的缺陷也得到修复。当然有一个趋势，即实现新的而不修复老的，但是明智的项目经理将注意缺陷趋势并强调，至多一两个以缺陷形式的未解决的迭代工作的价值将保留。
无论如何，分辨缺陷无疑可以看作进展。与缺陷相关的量度也能够以有趣的方式得来，包括：
每个缺陷的工作、每行源代码的缺陷、每个模块或组件的缺陷、按照注入点的缺陷、按照时间的缺陷、按照状态的缺陷。
使用时间图表 —— 根据时间所有这些量度都可以画为图表趋势，例如，应该积极地调查表示修复缺陷工作稳定增长的趋势。
我们还能够通过余下的迭代的数量和平均的缺陷分辨工作来增加每个迭代的预期缺陷。这指示了显著的缺陷负担，包括在还没撰写的代码中没有发现的缺陷!这些是粗略的数字，但是是要求全部的完成百分比的重要基础。
对于测试人员的缺陷趋势
虽然上面的缺陷趋势不是具体到测试规程的，但是存在重要的缺陷量度来指导测试人员，包括每个找到的缺陷的测试工作、每个测试用例的缺陷、每个场景的缺陷，及每个迭代的缺陷。
这样的量度是有效的，不仅从历史的观察，还从预言能力上讲。例如，如果我们的测试揭示了一个突然的且出乎意料的缺陷密度，我们可能宣称该构建是不健全的，放弃测试，并让架构团队检查此构建。测试一个糟糕的构建以致精疲力尽，从中得不到一点好处。
MTBF
平均故障时间(mean time between failure，MTBF)是重要的“人造”量度 —— 也就是，我们不得不捏造定义，为了能够生成受控条件下的客观度量。MTBF 通常作为非功能需求出现。为了验证我们的系统，我们必须在实验室设置在测的应用程序，利用事件进行干扰，并且当不能适当处理事件时进行监测。我们将其记录为一个失败，并且继续测试或者(如果不幸的话)重新启动应用程序。我们能够以快于真实情况的节奏来生成事件流。这些手段的净效应是能够在几个星期内生成几年中才能度量出的 MTBF 数字。 因为明显的理由，可以将其认为是人造的量度。
这些量度证明测试人员应该看作是项目经理重要的数据来源。
文章来源于领测软件测试网 https://www.ltesting.net/
