一、介紹

　　這是一篇英文的文獻，昨天把他翻譯出來了。覺得還是比較有用，所以決定在這裡把它貼出來。原文在：

　　http://www.stickyminds.com/sitewide.asp?ObjectId=10094&Function=DETAILBROWSE&ObjectType=ART&sqry=%2AZ%28SM%29%2AJ%28MIXED%29%2AR%28relevance%29%2AK%28simplesite%29%2AF%28Test%2Dbased+Project+Progress+Reporting%29%2A&sidx=0&sopp=10&sitewide.asp?sid=1&sqry=%2AZ%28SM%29%2AJ%28MIXED%29%2AR%28relevance%29%2AK%28simplesite%29%2AF%28Test%2Dbased+Project+Progress+Reporting%29%2A&sidx=0&sopp=10

　　二、摘要

　　面向交付的專案管理和測試驅動開發能夠結合在一起，能夠為客戶、開發成員和管理者提供客觀的更容易理解的方法來測量專案的進度。在這篇文章裡，john ferguson smart提供了一個學習用例來說明如何通過這種途徑進行工作。

　　三、名詞解析（自己新增的）

　　3.1 面向交付的專案管理是一種專案管理方法，測試驅動開發是一種開發方法。

　　3.2 面向交付的專案管理：就是本文說的，把任務分下去，總體任務代表一個總的交付，然後各個子任務代表子交付。專案根據各個交付任務來進行管理。

　　3.3  迭代的開發方法：就是先完成部分主要的功能，形成一個版本。然後再逐漸新增新的功能，形成新的版本。

　　3.4  測試用例（test case）：可以理解為就是測試用的程式和方法。每個測試用例對程式的某個功能進行測試，看是否實現了這個功能，有沒有bug。完備的測試用例就是對程式的各個功能和穩定性進行全面的測試。設計好的測試用例，才能全面而且儘可能快的完成程式的測試。

　　3.5 測試驅動開發：表示總的程式需要什麼功能，各個子模組需要什麼功能。指定好測試用例，程式完成了測試用例的功能，就表示開發完成了。將測試用例用於開發過程中，而不是說先把程式寫好了，最後再測試。

　　3.6 可交付性（deliverable）：可以理解為可以交付的工作產品，就是具備獨立功能的一段程式碼。

　　3.7 beta版本：beta版本就是

　　四、可交付性的定義

　　所有的工程專案，原則上都具有可交付性。如果採用迭代的開發途徑，為了制定一個迭代的、基於里程碑節點的交付方案，需要將主交付性可以分成多個小的子交付性。（比如一個應用程式可以分成多個模組、函式或者使用者開發實現）。

　　五、WBS和專案計劃

　　工作分解結構（WBS）是一個大家熟悉的而且非常有用的工具，用來將一個專案分解成容易管理的（也有人說可以消化的，或者可以咀嚼的）多個任務。在一定程度上，你分配WBS任務給單獨的開發組成員，（某些時候，是一小群開發成員），然後要求他們產生一個具體的可交付產品。

　　工作分解結構（WBS）往往是跟專案計劃緊密相連。這裡，對於工作分解結構（WBS），工作需要細化到每個任務對應一個可交付性的條款，然後分配到具體的小組成員。將具體的交付工作分給具體的小組成員，可以讓開發者將開發活動上聚焦在具體的、短期的目標上，同時也可以培養開發者的buy-in能力和責任感。

　　六、測試用例

　　自然，我們也為每個交付要寫一組測試用例。這些測試用例代表了每個模組可以被接受的標準。可以有很多方法來做測試計劃和測試用例。大部分會包含某種形式的，一系列的執行動作和步驟，伴隨著特定的結果。在我們的用例中，對於每一個可交付的模組，我們將對應的測試用例填到Excel電子表格中，並加註額外的資訊以便容易使用。下面就是Excel表格的表項。

　　● 一個獨一無二的測試用例號

　　● 顯示ID

　　● 顯示區域

　　● 執行的動作

　　● 期望的結果

　　● 得到的結果

　　　　→ 結果：通過，失敗，還沒有測試

　　　　→ 描述任何非期望的行為

　　　　→ 相關的缺陷追蹤問題

　　根據我們的經驗，一組好的測試用例能夠很完美的指示產品是否準備好交付。理想的情況，是測試用例和產品的功能定義一同交給開發者，儘管在實際中，測試用例一般要晚一點點。分析文件和測試用例為每一個模組提供了具體的有形的目標，使得開發者能夠關注於程式碼的編寫。

七、用測試來衡量進度

　　7.1 衡量測試結果

　　基於測試的進度報告能夠用一種容易理解的、客觀的觀點來審視專案進度。在我們的專案中，對每個模組需要報告下面的測試狀態：

　　● 全部的測試用例

　　● 通過的測試

　　● 失敗的測試

　　● 還未進行的測試

　　我們從下面三個主要方面來進行度量：

　　● 一個模組當所有的測試用例都由QA執行過，並測試成功，這個模組就算完成了。QA包括內部測試組和使用者測試人員。

　　● 測試一個模組需要的測試用例的數目反映了模組的複雜度。雖然不總是這樣，但常常如此。

　　● 開發是迭代的：新版本被頻繁的交付，測試也需要不停的進行，而不是僅僅在專案的最後才進行測試。

　　在這些條件下，各個模組的全部進度都可以通過各個模組的測試用例通過的數目來衡量。如果你能可靠的在特定的時間點（里程碑節點），獲得各個模組通過的測試用例數、失敗的測試用例數和未測試的用例數，就可以把它製成如圖一所示的表格。

圖一：測試狀態表

　　7.2 模組進度狀態

　　我從不相信一個開發者說他的一個模組快要完成了。在我的書中，只有所有的測試用例都通過了，一個模組才算完成了。然而，有些被普遍接受的原則認為，如果一個程式，85%的測試用例通過了，就可以進行beta版測試了。儘管你理論上認為必須100%的測試用例通過，才能說產品準備好了，但是我們的使用者通常會接受產品，儘管產品還存在一些不嚴重的問題，並且這些問題在將來能夠被修補。因此，我們把模組的“預產品”狀態定義為至少95%的測試用例通過並且沒有嚴重的問題。最後，我把模組開發過程的階段劃分原則制定出來。

　　我們劃分成五個狀態來表示五個開發階段，通過測試成功的測試用例的數目來客觀的衡量。

　　● 計劃階段：還沒有開始編碼

　　● 開發階段：開始編碼

　　● beta版本階段：85%測試用例通過。

　　● 預產品階段：95%的測試用例通過，沒有發現嚴重的問題

　　● 產品準備好階段：100%的測試用例通過

　　一旦你有了測試用例通過的百分數，你就對模組的開發進度和穩定性有了一個很好的評價。我們將這些資料用圖形來表示，寫在每週的進度報告中。

　　可以將進度表示成紫色的條圖，用來指示模組的工作進展。這能夠鼓勵開發者自發主動的清楚工作的進度。如圖2所示。

圖2 進度顏色條碼圖

　八、基於測試的進度總覽

　　我們從更高的層次上，通過測試用過的資料來看專案的進度。如圖四所示。這圖對外行人很容易看懂，在專案的進展報告中，放在在執行總結情況這部分特別有用。

圖3 基於測試的專案進展總覽圖

　　九、缺陷資料

　　我們使用的迭代的開發週期，提供了方便的追蹤缺陷資料的基礎。（譯者注：因為迭代是週期性的提交版本，可以週期性的對每個版本測試，發現版本的缺陷）。我們一般一到兩週會提交一個面向使用者交付的版本，每週或者幾天就會提交一個內部版本。新版本的整潔性比增加的模組數目或者修正的bug數目更重要。然而，QA人員在接受一個新版本之前，必須對上一個版本進行一個合理長的時間測試。交付的日期就必須一起商量決定。在期望的交付日期前，我們要考慮交付是否可行（能否修正嚴重的問題），要考慮哪些新模組以及哪些bug能夠對使用者宣告。

　　為了實現這個，我們把缺陷資料放在缺陷資料庫，從資料庫中提取出缺陷資料來衡量產品的質量可可靠性。全域性缺陷狀態圖表示了各個缺陷狀態（open, to-be-deployed,pending validation等）的缺陷數目。

　　我們對每次交付，都要衡量缺陷的狀態——記錄公開的問題數目和總的問題數。這對於交付規劃是非常重要的。

　　十、歷史資料

　　對於跟蹤隨時間變化的測試的結果也是很重要。它能告訴你軟體的可交付性和穩定性的速度（多長時間可以產生一個交付版本，多長時間可以達到某種穩定程度）。如圖6和圖7所示。

圖6 歷史資料：隨時間的測試完整性

圖7 歷史資料：隨時間的測試完整性

　　十一、這個方法不能做的

　　（譯者注：這個方法指基於測試的專案進度管理）

　　這種方法不完備，也不是要取代傳統的專案進度跟蹤和彙報。這種方法的特別之處在於它是純粹面向交付的。因此它能夠幸運的忽略哪些諸如延時、開銷、資源消耗、關鍵途徑等等術語。這些術語能夠而且應該被諸如Gantt圖，PERT圖等代替。實際上，這種方法能夠給上層管理人員、小組成員和專案投資人等一個專案進度的直觀表示方法。基於測試的交付狀態是一個重要的而且容易理解的專案彙報方式。但是延遲、花費和麵向任務的觀點同樣重要。

　　十二、對這種方法的評價（自己新增的評論）

　　測試用例的設計非常重要，要完備，系統。要有機制對測試用例的優先順序進行設定，哪些優先順序高，先實現；哪些沒那麼重要，後實現。 對各個測試用例要歸屬各個版本，哪個版本應該實現哪些測試用例。要設計好。