本文章是由機器翻譯。

測試回合

使用 EVM 測量測試工作進度

James McCaffrey

在許多軟體發展環境中，衡量測試工作進度的能力是整個軟體測試工作中的一個重要組成部分。執行此項任務的一種專案管理方法稱為“掙值管理”(EVM)。

EVM 是一項簡單的量化方法，可以用於衡量任何類型專案（包括軟體測試工作或整個工作的某個部分）的計畫進度（也可以用於衡量預算進度）。EVM 源于 1962 年美國國防部一項名為 PERT/Cost 的計畫。儘管 EVM 易於使用，並可以用於測試任何規模的測試工作，但根據我的經驗，許多軟體工程師都誤認為 EVM 僅僅適用于大規模的軟體發展工作。

在本月的“測試運行”專欄中，我將解釋何為 EVM，從頭到尾向您展示一個使用 EVM 衡量測試工作進度的示例，並介紹什麼時候應當使用以及什麼時候不應使用 EVM。

掙值管理準備

瞭解 EVM 的最好方法就是從頭到尾看一個具體示例。EVM 的第一步是將所要監視的測試工作拆分為更小的任務。在標準專案管理術語中，這些更小的任務通常稱為工作包，但在軟體發展環境中，我們常常將它們簡單地稱為子任務。

首先我要強調一點，拆分軟體測試工作（或專案）通常是 EVM 過程中最為困難的部分。

現在我們假定您將自己的測試工作拆分為五個子任務，標為 A-E，如圖 1 所示。整個測試工作拆分之後所達到的詳細程度（或稱細微性）取決於許多因素。一般說來，在軟體測試環境中，劃分單個子任務往往應當保證每個子任務的完成時間約在 4-40 小時之間。

圖 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 衡量測試工作計畫進度實際上是一種紙筆記錄方法，十分適用于小規模專案以及在敏捷環境中開發的專案。在開發大規模的軟體專案時，通常需要使用軟體工具來管理包含成百上千個測試工作子任務的複雜局面。

Dr. 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