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