测试运行
利用 EVM 衡量测试工作的进度
James McCaffrey
在许多软件开发环境中，衡量测试工作进度的能力是整个软件测试工作中的一个重要组成部分。执行此项任务的一种项目管理方法称为“挣值管理”(EVM)。
EVM 是一项简单的量化方法，可以用于衡量任何类型项目（包括软件测试工作或整个工作的某个部分）的计划进度（也可以用于衡量预算进度）。EVM 源于 1962 年美国国防部一项名为 PERT/Cost 的计划。尽管 EVM 易于使用，并可以用于测试任何规模的测试工作，但根据我的经验，许多软件工程师都误认为 EVM 仅仅适用于大规模的软件开发工作。
在本月的“测试运行”专栏中，我将解释何为 EVM，从头到尾向您展示一个使用 EVM 衡量测试工作进度的示例，并介绍什么时候应当使用以及什么时候不应使用 EVM。
挣值管理准备
了解 EVM 的最好方法就是从头到尾看一个具体示例。EVM 的第一步是将所要监视的测试工作拆分为更小的任务。在标准项目管理术语中，这些更小的任务通常称为工作包，但在软件开发环境中，我们常常将它们简单地称为子任务。
首先我要强调一点，拆分软件测试工作（或项目）通常是 EVM 过程中最为困难的部分。
现在我们假定您将自己的测试工作拆分为五个子任务，标为 A-E，如图 1 所示。整个测试工作拆分之后所达到的详细程度（或称粒度）取决于许多因素。一般说来，在软件测试环境中，划分单个子任务往往应当保证每个子任务的完成时间约在 4-40 小时之间。
.jpg)
图 1 映射 EVM 子任务
图 1 中的拓扑结构图表明：必须先完成测试子任务 A，然后开始 B，而且必须在子任务 C 和 D 都完成之后才能开始子任务 E。
EVM 的下一步是估算在总体测试资源分配（或预算）中有多少与每个子任务相关联。这称为每个子任务的计划值 (PV)。
图 2 中的示例假定您的总测试预算为 350 个单位。PV 单位往往采用美元（或欧元、卢布等等）进行衡量。成本单位的绝对量并不重要，因此在我们的示例中，350 总计划值可以代表 350 美元，也可以代表 350,000 美元。除了美元等货币单位，PV 的单位也可以是能对成本进行衡量的任意单位。
图 2 子任务规划
| 子任务 | 计划值 | 持续时间（天） | 完成时间（天） |
| A | 50 | 1 | 1 |
| B | 60 | 2 | 3 |
| C | 90 | 3 | 6 |
| D | 80 | 1 | 4 |
| E | 70 | 2 | 8 |
没有什么神奇公式可以确定子任务 PV，但须注意，EVM 所产生的计划进度度量的准确度完全取决于最初 PV 度量的准确度。在图 2 中可以看到，子任务 A、B、C、D 和 E 的 PV 估值分别为 50、60、90、80 和 70。
在完成 PV 估算之后，EVM 的下一步是估算每个子任务需要花费多长时间，然后利用这些估算值来确定每个子任务的完成时间。在图 2 中，我确定（利用历史数据、以往经验或某种量化方法）子任务 A、B、C、D 和 E 估计分别需要花费 1、2、3、1 和 2 天。在本例中，时间单位为天，但您可以使用小时或周或任何度量单位，只要在整个 EVM 分析过程中保持统一便可。
我们从时间 = 0 开始，因此如果子任务 A 估计需要花费 1 天，那么它将在第 1 天完成。然后，子任务 B 将在第 1 天开始，并需要 2 天，因而在第 3 天结束。请注意，子任务 E 在子任务 C 和 D 全都完成之后才能开始，因而将会在第 6 天（C 和 D 完成时间二者当中的较大值）开始，从而将会在第 8 天结束。
在确定软件测试工作子任务，并估算它们的 PV、持续时间和完成时间之后，下一步就是创建累积 PV 表格。首先是创建一个类似于图 3 所示的表格。最左侧一列表示每个时间单位的结束时间（在本例中是第 1 天至第 8 天）。第二列是每天结束之时的累积 PV，该值可以根据之前的 PV 数据表格确定。
图 3 累积 PV 计划进度
| 天 | 累积 PV | 实际活动 | 累积 EV |
| 1 | 50 | A 已经开始（但尚未完成） | 0 |
| 2 | 50 | A 已经完成，B 已经开始 | 50 |
| 3 | 110 | B 已经完成，C 和 D 已经开始 | 110 |
| 4 | 190 | （无变化） | 110 |
| 5 | 190 | （无变化） | 110 |
| 6 | 280 | C 和 D 都已完成，E 已经开始 | 280 |
| 7 | 280 | （无变化） | 280 |
| 8 | 350 | E 已经完成 | 280 |
在第 1 天结束之时，子任务 A 应当完成，因而累积 PV 应为 50，即 A 的 PV。在第 2 天结束之时，没有新的子任务会完成，因而累积 PV 仍为 50。在第 3 天结束之时，子任务 B 应当完成，因而累积 PV 应为子任务 A 的 50 加上子任务 B 的 60，即 110。同理可以确定第 4 天至第 8 天结束之时的累积 PV。
衡量测试计划进度
假定测试工作的开展进度与图 3 表格中的第三列相吻合。这些活动代表实际情况，而不是预计情况。计划完成值（您的 PV）与实际完成值之差为挣值 (EV)。
因而，在第 1 天结束之时，子任务 A 已经开始，但未按计划完成。所以第 4 列中的累积 EV 为 0。在第 2 天结束之时，子任务 A 实际完成，因而挣得 50（A 的关联 PV），故将该值放入第 4 列。在第 3 天结束之时，子任务 B 完成，因而累积 EV 为 50 + 60 = 110。但在第 4 天结束之时，没有新的子任务完成，因而累积 EV 仍为 110。在第一天（或您所使用的任何时间单位）结束之时，您应更新累积 EV 列。
利用图 3 中的表格可以轻松查看测试工作计划进度。如果累积 EV 小于累积 PV，则表明落后于计划。如果累积 EV 恰好等于累积 PV，则表明与计划相吻合。但累积 EV 大于累积 PV，则表明超前于计划（顺便说说，这种情况并不一定总是好事情）。
EVM 通常使用两个具体度量指标来量化测试工作与计划的吻合程度。任一特定时间点的所谓进度偏差 (SV) 就是累积 EV 减去累积 PV。例如，在图 3 中，在第 4 天结束之时，SV = 110 – 190 = -80，表明测试工作落后于计划 80 个 PV 成本单位（通常是美元）。负值 SV 表示项目落后于计划，而正值 SV 表示项目超前于计划。
因为 SV 的绝对量取决于 PV 的单位，所以常常使用另外一个称为进度绩效指数 (SPI) 的度量指标，而不是 SV。SPI 就是累积 EV 除以 PV。在本例中，在第 4 天结束之时，SPI 是 110 / 190 = 0.58。
这可以解释为仅仅挣得 58% 的 PV，也就是说 42% 落后于计划 PV。
SPI 值小于 1.00 表示测试工作落后于计划，SPI 值等于 1.00 表示测试工作与计划完全吻合，而 SPI 值大于 1.00 表示测试工作超前于计划。
总结
在本专栏中可以看到，利用 EVM 监视软件测试工作计划进度十分简单。然而，与任何量化方法一样，结果是否能够令人满意取决于初始数据，在这里就是与每个测试工作子任务相关联的 PV。EVM 是一个动态活动，您应在测试工作开展的同时调整您的估算。
在本专栏的开始部分，我曾提到 EVM 可以用于衡量计划进度和预算进度。我在这里所介绍的衡量计划进度是衡量预算进度的一个前提条件。衡量预算进度要求您要在每个时间单位结束之时积极监视所花费的资源量。这通常要比衡量工作进度更加困难，因此利用 EVM 衡量预算进度常常仅用于大规模的软件项目，在以后的“测试运行”专栏中我们将会对此加以讨论。
我在这里所介绍的利用 EVM 衡量测试工作计划进度实际上是一种纸笔记录方法，十分适用于小规模项目以及在敏捷环境中开发的项目。在开发大规模的软件项目时，通常需要使用软件工具来管理包含成百上千个测试工作子任务的复杂局面。
James McCaffrey博士供职于 Volt Information Sciences, Inc.，在该公司他负责管理对华盛顿州雷蒙德市沃什湾 Microsoft 总部园区的软件工程师进行的技术培训。他参与过多项 Microsoft 产品的研发工作，包括 Internet Explorer 和 MSN Search。McCaffrey 博士是《.NET Test Automation Recipes》（Apress，2006）一书的作者，您可以通过以下地址与他联系：jammc@microsoft.com。
衷心感谢以下 Microsoft 技术专家对本文的审阅：James Oker