一、介紹
這是一篇英文的文獻，昨天把他翻譯出來了。覺得還是比較有用，所以決定在這里把它貼出來。原文在：
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
二、摘要
面向交付的項目管理和測試驅(qū)動開發(fā)能夠結(jié)合在一起，能夠為客戶、開發(fā)成員和管理者提供客觀的更容易理解的方法來測量項目的進度。在這篇文章里，john ferguson smart提供了一個學(xué)習用例來說明如何通過這種途徑進行工作。
三、名詞解析（自己添加的）
3.1 面向交付的項目管理是一種項目管理方法，測試驅(qū)動開發(fā)是一種開發(fā)方法。
3.2 面向交付的項目管理：就是本文說的，把任務(wù)分下去，總體任務(wù)代表一個總的交付，然后各個子任務(wù)代表子交付。項目根據(jù)各個交付任務(wù)來進行管理。
3.3 迭代的開發(fā)方法：就是先完成部分主要的功能，形成一個版本。然后再逐漸添加新的功能，形成新的版本。
3.4 測試用例（test case）：可以理解為就是測試用的程序和方法。每個測試用例對程序的某個功能進行測試，看是否實現(xiàn)了這個功能，有沒有bug。完備的測試用例就是對程序的各個功能和穩(wěn)定性進行全面的測試。設(shè)計好的測試用例，才能全面而且盡可能快的完成程序的測試。
3.5 測試驅(qū)動開發(fā)：表示總的程序需要什么功能，各個子模塊需要什么功能。指定好測試用例，程序完成了測試用例的功能，就表示開發(fā)完成了。將測試用例用于開發(fā)過程中，而不是說先把程序?qū)懞昧?，最后再測試。
3.6 可交付性（deliverable）：可以理解為可以交付的工作產(chǎn)品，就是具備獨立功能的一段代碼。
3.7 beta版本：beta版本就是軟件開發(fā)的一個階段，一般這個階段，程序已經(jīng)可以完成大部分的功能，也比較穩(wěn)定了。一般beta版本開發(fā)出來以后，就會提供給用戶或者內(nèi)部人員免費使用，然后根據(jù)使用發(fā)現(xiàn)的bug，進行修正。
四、可交付性的定義
所有的工程項目，原則上都具有可交付性。如果采用迭代的開發(fā)途徑，為了制定一個迭代的、基于里程碑節(jié)點的交付方案，需要將主交付性可以分成多個小的子交付性。（比如一個應(yīng)用程序可以分成多個模塊、函數(shù)或者用戶開發(fā)實現(xiàn)）。
五、WBS和項目計劃
工作分解結(jié)構(gòu)（WBS）是一個大家熟悉的而且非常有用的工具，用來將一個項目分解成容易管理的（也有人說可以消化的，或者可以咀嚼的）多個任務(wù)。在一定程度上，你分配WBS任務(wù)給單獨的開發(fā)組成員，（某些時候，是一小群開發(fā)成員），然后要求他們產(chǎn)生一個具體的可交付產(chǎn)品。
工作分解結(jié)構(gòu)（WBS）往往是跟項目計劃緊密相連。這里，對于工作分解結(jié)構(gòu)（WBS），工作需要細化到每個任務(wù)對應(yīng)一個可交付性的條款，然后分配到具體的小組成員。將具體的交付工作分給具體的小組成員，可以讓開發(fā)者將開發(fā)活動上聚焦在具體的、短期的目標上，同時也可以培養(yǎng)開發(fā)者的buy-in能力和責任感。
六、測試用例
自然，我們也為每個交付要寫一組測試用例。這些測試用例代表了每個模塊可以被接受的標準。可以有很多方法來做測試計劃和測試用例。大部分會包含某種形式的，一系列的執(zhí)行動作和步驟，伴隨著特定的結(jié)果。在我們的用例中，對于每一個可交付的模塊，我們將對應(yīng)的測試用例填到Excel電子表格中，并加注額外的信息以便容易使用。下面就是Excel表格的表項。
● 一個獨一無二的測試用例號
● 顯示ID
● 顯示區(qū)域
● 執(zhí)行的動作
● 期望的結(jié)果
● 得到的結(jié)果
→ 結(jié)果：通過，失敗，還沒有測試
→ 描述任何非期望的行為
→ 相關(guān)的缺陷追蹤問題
根據(jù)我們的經(jīng)驗，一組好的測試用例能夠很完美的指示產(chǎn)品是否準備好交付。理想的情況，是測試用例和產(chǎn)品的功能定義一同交給開發(fā)者，盡管在實際中，測試用例一般要晚一點點。分析文檔和測試用例為每一個模塊提供了具體的有形的目標，使得開發(fā)者能夠關(guān)注于代碼的編寫。
七、用測試來衡量進度
7.1 衡量測試結(jié)果
基于測試的進度報告能夠用一種容易理解的、客觀的觀點來審視項目進度。在我們的項目中，對每個模塊需要報告下面的測試狀態(tài)：
● 全部的測試用例
● 通過的測試
● 失敗的測試
● 還未進行的測試
我們從下面三個主要方面來進行度量：
● 一個模塊當所有的測試用例都由QA執(zhí)行過，并測試成功，這個模塊就算完成了。QA包括內(nèi)部測試組和用戶測試人員。
● 測試一個模塊需要的測試用例的數(shù)目反映了模塊的復(fù)雜度。雖然不總是這樣，但常常如此。
● 開發(fā)是迭代的：新版本被頻繁的交付，測試也需要不停的進行，而不是僅僅在項目的最后才進行測試。
在這些條件下，各個模塊的全部進度都可以通過各個模塊的測試用例通過的數(shù)目來衡量。如果你能可靠的在特定的時間點（里程碑節(jié)點），獲得各個模塊通過的測試用例數(shù)、失敗的測試用例數(shù)和未測試的用例數(shù)，就可以把它制成如圖一所示的表格。
圖一：測試狀態(tài)表
7.2 模塊進度狀態(tài)
我從不相信一個開發(fā)者說他的一個模塊快要完成了。在我的書中，只有所有的測試用例都通過了，一個模塊才算完成了。然而，有些被普遍接受的原則認為，如果一個程序，85%的測試用例通過了，就可以進行beta版測試了。盡管你理論上認為必須100%的測試用例通過，才能說產(chǎn)品準備好了，但是我們的用戶通常會接受產(chǎn)品，盡管產(chǎn)品還存在一些不嚴重的問題，并且這些問題在將來能夠被修補。因此，我們把模塊的“預(yù)產(chǎn)品”狀態(tài)定義為至少95%的測試用例通過并且沒有嚴重的問題。最后，我把模塊開發(fā)過程的階段劃分原則制定出來。
我們劃分成五個狀態(tài)來表示五個開發(fā)階段，通過測試成功的測試用例的數(shù)目來客觀的衡量。
● 計劃階段：還沒有開始編碼
● 開發(fā)階段：開始編碼
● beta版本階段：85%測試用例通過。
● 預(yù)產(chǎn)品階段：95%的測試用例通過，沒有發(fā)現(xiàn)嚴重的問題
● 產(chǎn)品準備好階段：100%的測試用例通過
一旦你有了測試用例通過的百分數(shù)，你就對模塊的開發(fā)進度和穩(wěn)定性有了一個很好的評價。我們將這些數(shù)據(jù)用圖形來表示，寫在每周的進度報告中。
可以將進度表示成紫色的條圖，用來指示模塊的工作進展。這能夠鼓勵開發(fā)者自發(fā)主動的清楚工作的進度。如圖2所示。
圖2 進度顏色條碼圖
八、基于測試的進度總覽
我們從更高的層次上，通過測試用過的數(shù)據(jù)來看項目的進度。如圖四所示。這圖對外行人很容易看懂，在項目的進展報告中，放在在執(zhí)行總結(jié)情況這部分特別有用。
圖3 基于測試的項目進展總覽圖
九、缺陷數(shù)據(jù)
我們使用的迭代的開發(fā)周期，提供了方便的追蹤缺陷數(shù)據(jù)的基礎(chǔ)。（譯者注：因為迭代是周期性的提交版本，可以周期性的對每個版本測試，發(fā)現(xiàn)版本的缺陷）。我們一般一到兩周會提交一個面向用戶交付的版本，每周或者幾天就會提交一個內(nèi)部版本。新版本的整潔性比增加的模塊數(shù)目或者修正的bug數(shù)目更重要。然而，QA人員在接受一個新版本之前，必須對上一個版本進行一個合理長的時間測試。交付的日期就必須一起商量決定。在期望的交付日期前，我們要考慮交付是否可行（能否修正嚴重的問題），要考慮哪些新模塊以及哪些bug能夠?qū)τ脩袈暶鳌?/p>
為了實現(xiàn)這個，我們把缺陷數(shù)據(jù)放在缺陷數(shù)據(jù)庫，從數(shù)據(jù)庫中提取出缺陷數(shù)據(jù)來衡量產(chǎn)品的質(zhì)量可可靠性。全局缺陷狀態(tài)圖表示了各個缺陷狀態(tài)（open, to-be-deployed,pending validation等）的缺陷數(shù)目。
我們對每次交付，都要衡量缺陷的狀態(tài)——記錄公開的問題數(shù)目和總的問題數(shù)。這對于交付規(guī)劃是非常重要的。
十、歷史數(shù)據(jù)
對于跟蹤隨時間變化的測試的結(jié)果也是很重要。它能告訴你軟件的可交付性和穩(wěn)定性的速度（多長時間可以產(chǎn)生一個交付版本，多長時間可以達到某種穩(wěn)定程度）。如圖6和圖7所示。
圖6 歷史數(shù)據(jù)：隨時間的測試完整性
圖7 歷史數(shù)據(jù)：隨時間的測試完整性
十一、這個方法不能做的
（譯者注：這個方法指基于測試的項目進度管理）
這種方法不完備，也不是要取代傳統(tǒng)的項目進度跟蹤和匯報。這種方法的特別之處在于它是純粹面向交付的。因此它能夠幸運的忽略哪些諸如延時、開銷、資源消耗、關(guān)鍵途徑等等術(shù)語。這些術(shù)語能夠而且應(yīng)該被諸如Gantt圖，PERT圖等代替。實際上，這種方法能夠給上層管理人員、小組成員和項目投資人等一個項目進度的直觀表示方法?；跍y試的交付狀態(tài)是一個重要的而且容易理解的項目匯報方式。但是延遲、花費和面向任務(wù)的觀點同樣重要。
十二、對這種方法的評價（自己添加的評論）
測試用例的設(shè)計非常重要，要完備，系統(tǒng)。要有機制對測試用例的優(yōu)先級進行設(shè)定，哪些優(yōu)先級高，先實現(xiàn)；哪些沒那么重要，后實現(xiàn)。 對各個測試用例要歸屬各個版本，哪個版本應(yīng)該實現(xiàn)哪些測試用例。要設(shè)計好。