項目的進度管理是一門藝術(shù)，是一個動態(tài)的過程，需要不斷調(diào)度、協(xié)調(diào)，保證項目的均衡發(fā)展，實現(xiàn)項目整體的動態(tài)平衡。在項目進度的管理過程中，項目的實施與項目的計劃是互動的。

項目開始前的計劃對軟件的測試需求有一個大體的認識，但深度不夠，進度表可能只是一個時間上的框架，一定程度上是靠計劃制訂者的經(jīng)驗來把握的。隨著時間的推移、測試的不斷深入，相關人員對軟件會有進一步的認識，對很多問題都不再停留在比較粗的估算上，項目進度表會變得越來越詳細，越來越準確。

項目的進度管理主要通過里程碑、關鍵路徑的控制并借助工具來實現(xiàn)，同時需要把握好進度與質(zhì)量、成本的關系，以及充分了解進度的數(shù)量和質(zhì)量雙重特性。

軟件測試項目的里程碑和關鍵路徑

軟件測試項目的計劃書中都會有一個與軟件測試項目明確相關的日程進度表。關于如何對項目進行階段劃分、如何控制進度、如何控制風險等，目前存在一系列方法，其中最成熟的技術(shù)是里程碑管理和關鍵路徑的控制。

1.里程碑的定義和控制

一般來說，里程碑是項目中完成階段性工作的標志，即對一個過程性的任務用一個結(jié)論性的標志來描述明確的任務起止點，一系列的起止點就構(gòu)成引導整個項目進展的里程碑。一個里程碑標志著上一階段的結(jié)束以及下一階段的開始，即定義當前階段完成的標準和下個新階段啟動的條件或前提。里程碑的特征表述如下。

（1）里程碑有一定層次，即可在父里程碑下定義子里程碑。

（2）不同類型的項目，里程碑可能不同。

（3）在不同規(guī)模的項目中，里程碑的數(shù)量是不一致的。里程碑可以合并或分解。

在軟件測試周期中，建議定義六個父里程碑、十多個子里程碑，具體如下所示。

M1：需求分析和設計的審查

M11：市場/產(chǎn)品需求審查

M12：產(chǎn)品規(guī)格說明書審查

M13：產(chǎn)品和技術(shù)知識傳遞

M14：系統(tǒng)/程序設計審查

M2：測試計劃和設計

M21：測試計劃的制訂

M22：測試計劃的審查

M23：測試用例的設計

M24：測試用例的審查

M25：測試工具的設計和選擇

M26：測試腳本的開發(fā)

M3：代碼（包括單元測試）完成

M4：測試執(zhí)行

M41：集成測試完成

M42：功能測試完成

M43：系統(tǒng)測試完成

M44：驗收測試完成

M45：安裝測試完成

M5：代碼凍結(jié)

M6：測試結(jié)束

M61：為產(chǎn)品發(fā)布進行最后一輪測試

M62：編寫測試和質(zhì)量報告

你也可以調(diào)整子里程碑，并在子里程碑下定義更小的里程碑，即孫里程碑，如表1所示。

表1 軟件測試進度表示例

在一個里程碑到來之前，需要進行檢查，了解測試狀態(tài)以確定是否能在預期時間內(nèi)達到里程碑階段標準，若存在較大差距，則需要采取相應措施，爭取在預期時間內(nèi)達到里程碑的標準，即使不能，也需要盡量減小差距。每到一個里程碑，對實際完成情況必須嚴格檢查，查看是否符合已定義的標準，并且應及時對前一階段的測試工作進行總結(jié)；若有需要，則可對后續(xù)測試工作計劃進行調(diào)整，例如，增加資源，延長時間，以實現(xiàn)下一個里程碑的目標。

在項目管理進度跟蹤的過程中，給予里程碑事件足夠的重視，往往可以起到事半功倍的作用。保證里程碑事件的按時完成，整個項目的進度就有了初步保障。根據(jù)里程碑可較為容易地確定軟件測試進度表。

2.項目的關鍵路徑

每個項目可根據(jù)各項任務的工作量估計、資源條件限制和日程安排，事先確定一條關鍵路徑。關鍵路徑是一系列能確定計算出完成日期的任務構(gòu)成的日程安排線索。當關鍵路徑上的最后一個任務完成時，整個項目也隨之完成；關鍵路徑上的任何一項任務延遲，整個項目就會延期。為了確保項目如期完成，應密切關注關鍵路徑上的任務和為其分配的資源，上述要素將決定項目能否準時完成。

關鍵路徑法（Critical Path Method,CPM）是國際公認的項目進度管理辦法，其計算方法簡單，許多項目管理工具（如Microsoft Project）可自動計算關鍵路徑。隨著項目的實施，關鍵路徑可能由于當前關鍵路徑上的某些任務發(fā)生變化（延遲）而變化，從而產(chǎn)生新的關鍵路徑，因此，關鍵路徑也是動態(tài)可變的，但這種動態(tài)性需要控制在最小范圍內(nèi)。關鍵路徑的這種變化可能導致原來不在關鍵路徑上的任務成為關鍵路徑的必經(jīng)節(jié)點，因此，測試組長或項目經(jīng)理需要隨時關注項目進展，跟蹤項目的最新計劃，確保關鍵路徑上的任務及時完成。

軟件測試項目進度的特性及外在關系

任何一項工作，在最開始的時候較為容易看到工作推進的進度，例如，建造房子，從無到有變化非常明顯，但隨著時間的推移，房子框架搭建起來之后，所能觀察到的進度就越來越不明顯。軟件測試也是如此，在測試之初，缺陷較為容易發(fā)現(xiàn)，但測試的進展并不是按照缺陷數(shù)量來計算的，測試越進行到后期，缺陷就越難發(fā)現(xiàn)。因此，若要提高測試質(zhì)量，需要將嚴重的、關鍵的問題盡可能地在第一時間發(fā)現(xiàn)，如此才不至于在最后階段使開發(fā)人員對代碼進行大規(guī)模的修改。若大規(guī)模修改代碼，則無法保證測試的時間，最終會影響軟件的質(zhì)量。上述內(nèi)容就是測試項目進度的數(shù)量和質(zhì)量雙重特性，在關注進度的同時需要把握好這兩個特性，在注重速度的同時，還需要觀察前期的質(zhì)量。如圖1所示。

圖1表示一個為期10天的測試項目，在項目中測試工程師實際發(fā)現(xiàn)了60個缺陷，其缺陷數(shù)量的日期（橫坐標）分布呈漸漸回落之勢，即一開始發(fā)現(xiàn)的缺陷最多，隨著時間的推移，發(fā)現(xiàn)的缺陷越來越少，最后2～3天不再報告新的缺陷，而只是驗證已被修正的缺陷。在理想情況下，問題的難度也應呈降序排列，前期發(fā)現(xiàn)最不易解決的問題，因為在解決這些問題時，往往會產(chǎn)生新的缺陷，及早報告，有利于更好地解決問題。當然，在做具體項目時，不容易保證完全做到理想狀態(tài)，這與測試工程師本身的技能和經(jīng)驗有很大關系。

圖1 測試項目進度的特性圖

1.進度與質(zhì)量的關系

測試項目管理的基本原則是保證在不超預算并滿足軟件質(zhì)量的前提下，按進度完成項目。因此，進度與質(zhì)量存在一定程度上的矛盾關系：有時要想保證質(zhì)量，進度就必須放慢，使測試時間充足；有時要想保證進度，質(zhì)量就受到一定影響或存在比較大的風險。質(zhì)量與進度的關系應該是保證質(zhì)量為前提，然后考慮資源的調(diào)度和進度的調(diào)整。

首先，盡量利用歷史數(shù)據(jù)，參考以前完成過的項目來進行類比分析，以確定質(zhì)量和進度之間的制約關系，進而控制進度和管理質(zhì)量。

其次，可采用對進度管理計劃添加質(zhì)量參數(shù)的方法，即通過調(diào)整參數(shù)來調(diào)整進度和質(zhì)量的關系（此方法需要有一定量的歷史數(shù)據(jù)）。例如，從歷史數(shù)據(jù)中得知，若完成子項目的時間是5天，測試后遺留15個問題；若完成同樣子項目的時間是7天，測試后遺留12個問題；若完成該子項目的時間是8天，測試后遺留5個問題；……。

隨著數(shù)據(jù)的不斷增多，采用二維坐標圖，即可得到一些離散的點（不考慮資源的差異），并形成一條曲線，如圖2所示。管理者可考慮項目允許的質(zhì)量范圍，對照圖中的數(shù)據(jù)，找出相應的參數(shù)；根據(jù)得到的參數(shù)，確定一個合適的進度計劃。

圖2 通過參數(shù)調(diào)整進度和質(zhì)量的關系

2.進度與成本的關系

在項目管理水平不夠高的情況下，經(jīng)常出現(xiàn)進度拖延，成本（人力資源×時間）居高不下的情況，此時需要提高測試項目中進度與成本關系的控制水平。軟件測試項目受規(guī)格說明書修改、設計修改、代碼修改等影響比較大，一旦在某些地方進行簡單修改，可能開發(fā)只要花很少的時間人力資源，但測試由于得不到足夠信息或過多采用黑盒測試方法，成本會大幅上升。

另外需要注意的一點是要對學習曲線有深刻的認識。在軟件開發(fā)過程中，學習曲線可以起到很大的作用，通常情況下，在開發(fā)與上一個相似或同類型的新軟件時，會比上一次節(jié)省15%～20%的時間。

軟件測試項目進度的管理方法和工具

軟件測試管理中最重要、最基本的是測試進度跟蹤。眾所周知，在進度壓力之下，通常被壓縮的是測試時間，這導致隨著時間的推移，實際的進度與最初制訂的計劃相差越來越遠。而若有了正式的度量方法，上述情況就不容易出現(xiàn)，因為在其出現(xiàn)之前相關人員就有可能采取行動解決問題。下面介紹兩種測試項目進度的管理方法，分別是測試進度S曲線法和缺陷跟蹤曲線法。缺陷跟蹤又可分為新發(fā)現(xiàn)缺陷跟蹤法和累計缺陷跟蹤法，其中累計缺陷跟蹤法更好。常用的缺陷跟蹤曲線法是NOB（Number of Open Bug，打開的缺陷數(shù)）曲線法。

1.測試進度S曲線法

測試進度S曲線法通過將計劃中的進度、嘗試的進度與實際的進度三者進行對比來實現(xiàn)，其采用的基本數(shù)據(jù)主要是測試用例或測試點的數(shù)量，這些數(shù)據(jù)需要按周統(tǒng)計，每周統(tǒng)計一次，并將統(tǒng)計數(shù)據(jù)反映在圖表中。“S”代表隨著時間的推移，積累的數(shù)據(jù)形成的曲線越來越像S形。一般的測試過程包含三個階段，初始階段、緊張階段和成熟階段，第一和第三個階段所執(zhí)行的測試數(shù)量（強度）遠小于中間的第二個階段，由此導致曲線的形狀像一個扁扁的S。

x軸代表時間，y軸代表當前累計的測試用例或測試點數(shù)量，如圖3所示。

圖3 計劃中的、嘗試的與實際進度曲線圖

圖3包含了如下信息。

（1）趨勢曲線（上方實線）代表計劃中的測試用例數(shù)量，該曲線是在形成測試計劃后，在實際測試執(zhí)行之前繪制的。

（2）測試開始時，圖上只有計劃曲線。此后，每周添加兩條柱狀數(shù)據(jù)，淺色柱狀數(shù)據(jù)代表當前周累計嘗試執(zhí)行的測試用例數(shù)，深色柱狀數(shù)據(jù)為當前周累計實際執(zhí)行的測試用例數(shù)。

（3）在測試快速增長期（緊張階段），嘗試執(zhí)行的測試用例數(shù)略低于計劃用例數(shù)，實際執(zhí)行的用例數(shù)略高于嘗試執(zhí)行的用例數(shù)，此情況是經(jīng)常出現(xiàn)的。

由于測試用例的重要程度不同，因此，在實際測試中經(jīng)常會給測試用例加上權(quán)重。加權(quán)歸一化使S曲線更加準確地反映測試進度（如此y軸數(shù)據(jù)就是測試用例的加權(quán)數(shù)量），加權(quán)后的測試用例通常被稱為測試點。

一旦有一個嚴格的計劃曲線放在項目組面前，它將成為奮斗的動力，整個小組都將關注計劃、嘗試與實際之間的偏差。因此，嚴格的評估是S曲線成功的基本保證，例如，人力是否足夠，測試用例之間是否存在相關性。一般而言，計劃或者嘗試數(shù)與實際執(zhí)行數(shù)之間存在15%～20%的偏差就需要啟動應急行動進行彌補。

一旦計劃曲線被設定，任何對計劃的變更都必須經(jīng)過審查。一般而言，最初的計劃應作為基準，即使計劃有變更，基準也留作參考。該曲線與后來的計劃曲線對比顯現(xiàn)的不同之處需要有詳盡的理由作為說明，同時這也是今后制訂計劃的經(jīng)驗來源之一。

2.測試進度NOB曲線法

測試所發(fā)現(xiàn)的軟件缺陷數(shù)量，會在一定程度上代表軟件的質(zhì)量，通過對它的跟蹤來控制進度也是一種比較現(xiàn)實的方法，受到測試過程管理人員的高度重視。NOB曲線法主要收集當前所有打開的（激活的）缺陷數(shù)，也可將嚴重級別高的缺陷分離出來進行控制，從而形成 NOB 曲線。NOB曲線在一定程度上反映了軟件的質(zhì)量和測試的進度。

在 NOB 曲線法中，最重要的是確定基線數(shù)據(jù)或典型數(shù)據(jù)，即為測試進度設計一套計劃曲線或理想曲線。至少在跟蹤開始時，需將項目進度關鍵點（里程碑）預期的NOB 限制等級設置好，以及確定 NOB達到高峰的時間、NOB在測試產(chǎn)品發(fā)布前能否降到足夠低。較為理想的模式是，相對于先前發(fā)布的版本或基線，NOB曲線的高峰出現(xiàn)得更早，且在發(fā)布前降到足夠低并穩(wěn)定下來。需要提醒的是，在這種度量方法中僅注意數(shù)量是不夠的，為了盡早達到系統(tǒng)的穩(wěn)定，缺陷的類型和優(yōu)先級都是必須關注的。

盡管 NOB應該一直都被控制在合理的范圍內(nèi)，但當功能測試的進展是最主要的開發(fā)事件時，應關注測試的有效性和測試的執(zhí)行，并在最大程度上鼓勵缺陷的發(fā)現(xiàn)。過早地關注NOB減少，將導致目標沖突，導致潛在的缺陷遺漏或缺陷發(fā)現(xiàn)的延遲。因此，在測試緊張階段，主要應關注阻礙測試進展的那些關鍵缺陷的修復。當然，在測試接近完成時，就應強烈關注 NOB的減少，因為 NOB曲線的后半部分尤為重要，與質(zhì)量問題密切相關。如圖4所示。

圖4 NOB進度曲線示意圖

Myers 有一個著名的關于軟件測試的反直覺原則：在測試中發(fā)現(xiàn)缺陷多的地方，還將發(fā)現(xiàn)更多的缺陷。此現(xiàn)象產(chǎn)生的原因是，若測試效率沒有被顯著改善，則在修復缺陷時，將引入更多的缺陷。對這種度量方法的詮釋如下。

（1）若缺陷發(fā)生率與先前發(fā)布的版本（或模板）相同或更低，應考慮當前版本的測試是否低效或根本未起到任何作用。若不是，則質(zhì)量的前景還是較為樂觀的；若是，則需要進行額外的測試。除了需要對當前的項目采取措施，還需要對開發(fā)和測試的過程進行改善。

（2）若缺陷發(fā)生率比先前發(fā)布的版本（或模板）更高，則應考慮是否為提高測試效率做了計劃，并實際已做到顯著提高測試效率。若沒有，則質(zhì)量將得不到保證；若有，質(zhì)量將得到保證或可以說質(zhì)量的前景是很樂觀的。

上述度量法經(jīng)常用于特定測試中缺陷的度量，如功能測試、產(chǎn)品級測試、系統(tǒng)集成測試。

3.測試進度管理工具

“工欲善其事，必先利其器”。要做好項目管理，首先需要一個可規(guī)劃、跟蹤、控制和改進項目管理的工具。微軟公司推出的 Microsoft Project 就是一個常用的、專業(yè)的項目管理工具，提供了項目管理所需的基本功能，可細致地反映項目進行的整個過程，便于跟蹤項目的進展、項目的分工等。它把一個任務劃分為比較基準計劃（原始計劃）、當前計劃、實際計劃和待執(zhí)行計劃（剩余計劃或未完成計劃）4個階段進行管理。

（1）比較基準計劃（原始計劃）：此處的計劃數(shù)據(jù)記錄了最初制訂項目計劃時項目的狀態(tài)。由于項目一旦開始運作執(zhí)行，項目計劃總是處于動態(tài)變化中，因此為了評價計劃的實施情況或計劃本身設計的問題，需要隨時可獲得原始計劃數(shù)據(jù)。Microsoft Project把最初編制的計劃作為“比較基準”存儲起來，在項目調(diào)整過程中始終保持不變。

（2）當前計劃（正在進行）：項目啟動后，由于主觀或客觀的原因，計劃總是處在變化中，因此，需要反映項目實際執(zhí)行情況的計劃。由于當前計劃是根據(jù)實際已經(jīng)發(fā)生的計劃和任務間的制約關系計算的，因此對于項目計劃的管理和預測都具有現(xiàn)實指導意義。

（3）實際計劃（已完成的）：指那些未完成但已開始實施，或已全部完成的任務計劃。已實際執(zhí)行的計劃在項目管理中的重要性有兩點：一，它是計算項目產(chǎn)值的依據(jù)；二，它也是規(guī)劃和預測當前和未來計劃的基本信息。

（4）待執(zhí)行計劃（未完成的）：項目組不僅需要考慮已完成的任務量，還必須知道剩余的需要完成的工作量，即待執(zhí)行計劃。若一個任務已經(jīng)開始但還未做完，系統(tǒng)將根據(jù)任務完成情況自動計算剩余工作量，并重新測算工期和成本。

對于時刻處在變化之中的項目計劃來說，人工統(tǒng)計資源在整個項目中的分布是一件非常煩瑣的事情，Microsoft Project提供的“資源使用狀態(tài)”視圖，逐個列出資源承擔的任務和在每個任務上工作的日期、人數(shù)、工作量、費用，以及累計工作量和累計費用等，從多角度以豐富的圖表來描述測試進度。

（1）網(wǎng)絡圖：以描述任務關系為重點，可選擇任意5種任務信息進行顯示。通過選擇不同類別的信息，可建立基本信息網(wǎng)絡圖、基線網(wǎng)絡圖、跟蹤網(wǎng)絡圖、費用網(wǎng)絡圖等。

（2）橫道圖：以表述任務時間關系為重點，顯示出工序的關系線，即每個任務的開始、結(jié)束時間，而且能夠顯示任務的緊前和緊后工序。橫道圖可將每個任務的基線計劃、當前計劃、實際計劃、完成百分比、時差同時顯示出來，便于進行綜合分析。

（3）資源圖：以反映資源使用狀況為重點，為資源分析和跟蹤提供了8種圖形，即資源需求曲線圖、資源工作量圖、資源累計工作量圖、超分配工作量圖、資源已經(jīng)分配的百分數(shù)圖、資源當前可用工作量圖、成本圖、累計費用圖等。

（4）Microsoft Project內(nèi)置了多種篩選器，幫助建立各種文字報告，內(nèi)容覆蓋面廣，可直接使用。

（5）項目摘要報告：項目匯總報告。

（6）任務報告：未開始的、正在進行的、已經(jīng)完成的、推遲開始的、馬上開始的、進度拖后的等各種任務報告，還包括關鍵任務的、使用某種資源的、超出預算的、本周/月/季的等各種任務報告及任務基本信息報告。

（7）資源報告：預算報告；超強度分配、超出預算等資源報告；資源工作安排報告；工作量報告；周/月/季/年現(xiàn)金流報告；資源基本信息報告。