用TestDirector7.6對迭代開發模型的流程管理

　　

　　

　　從開發模型可以看出在軟件項目實施過程中非常重要并且占項目實施時間最長的過程是迭代過程中的特性開發過程，而特性開發過程中的主線是需求，在特性開發過程中的設計、評審、編碼、版本集成、測試等活動都是圍繞著需求開展的。QA人員對迭代過程中特性開發過程的檢查也是以需求為主線進行的，QA人員通過檢查迭代過程中的需求點是否進行了需求分析、是否進行需求評審、是否進行了設計、是否進行設計評審、是否進行了編碼、是否進行了測試等來判斷項目組過程的實施是否滿足軟件項目實現的要求，是否有過程缺失，或過程實施流于形式。迭代過程中需求與需求的活動覆蓋關系可以通過以下這個矩陣體現：

　　

矩陣中的A、B、C、D、L、M表示相關的技術文檔或質量記錄。

　　通過上面的矩陣關系我們可以明白只要了解了需求與需求相關活動的覆蓋情況就可以掌握迭代過程的實施情況，并且對項目的進度控制也會起到一定的作用。而TD的最大優勢就是需求的覆蓋功能，即通過測試用例對需求的覆蓋以及bug與測試用例的關聯關系從而了解和控制需求實現情況。因此我們可以利用TD的這一優勢實現我們需要了解迭代過程中需求與需求相關活動覆蓋情況的要求，在一定程度上TD可以起到軟件項目實現過程控制的作用。

　　一、使用TD對軟件中心的過程進行管理

　　使用TD可以代替一些質量記錄和技術文檔如評審記錄、測試大綱等，而且TD有添加附件的功能，可以將相關文檔作為某個任務的附件進行評審和管理。

　　

　　requirement頁面中二、三級節點主要體現項目計劃中的里程碑事件。

　　1.1.2 TestDirector的requirement頁面所需的字段：

　　編號字段名字段說明一般使用的節點備注

　　1計劃開始時間手工填寫二、三級節點

　　2計劃完成時間 二、三級節點

　　3創建人自動生成(TD的錄入人) 是否需要

　　4責任人 手工填寫二、三、四級節點

　　5計劃類型計劃內計劃外二、三、四級節點主要用于需求點

　　6計劃版本號 手工填寫四級節點

　　7集成版本號 手工填寫 四級節點 第一次版本集成的版本號

　　8集成版本時間 根據“集成版本號”填寫自動生成 四級節點日志

　　9測試通過版本號 手工填寫 四級節點

　　10測試版本時間 根據“測試通過版本號”填寫自動生成四級節點日志

　　11變更版本號 手工填寫 四級節點 計劃變更

　　12變更版本時間 根據“變更版本號”填寫自動生成 四級節點日志

　　13交付版本號 手工填寫 四級節點

　　14交付版本時間 根據“交付版本時間”填寫自動生成 四級節點日志

　　

　　

　　注：QA是requirement analyse的縮寫，D是design的縮寫，C是code的縮寫，

　　EI是edition integration的縮寫，T是test的縮寫，TR是test review的縮寫

　　SI是software issuance 的縮寫，PD是product delivery的縮寫

　　每一個過程中的任務前面加一個英文縮寫前綴，是方便檢查需求與需求相關活動覆蓋情況用的。

　　1.2.2 TestDirector的testplan頁面所需的字段：

　　編號字段名字段說明一般使用的節點備注

　　計劃開始時間 手工填寫二、三、四級節點

　　計劃完成時間

　　二、三、四級節點

　　任務下達者自動生成(任務的創建者)

　　三、四級節點

　　任務接受者手工填寫

　　三、四級節點發郵件給任務接受者。

　　預計工作量手工填寫三、四級節點

　　實際工作量手工填寫三、四級節點

　　實際完成時間手工填寫二、三、四級節點二節點的實際完成時間應該是版本上線時間

　　任務接受否是三、四級節點

　　任務接受時間根據“任務接受”填寫“是”三、四級節點

　　評審類型評審復審代碼審核三、四級節點

　　評審組長手工填寫三、四級節點

　　評審方式

　　會議傳遞個人三、四級節點

　　提交評審未提交提交三、四級節點發郵件給項目經理 (或評審組長)

　　提交評審時間根據“提交評審”變成“提交”自動生成三、四級節點

　　Description 手工填寫 三、四級節點

　　Expected Result手工填寫三、四級節點

　　1.2.3 Test plan與Requirement的覆蓋關系：

　　1、 requirement中項目計劃過程、軟件發布、產品交付，這些過程或活動是與test plan中項目計劃、軟件發布、產品交付是一對一的覆蓋。

　　2、 requirement中迭代開發過程中的需求點至少被每一個以QR_、D_、C_、EI_、T_前綴的任務覆蓋，即多對一的覆蓋。如下圖：

　　

　　3、 Test plan中的需求分析、設計過程、軟件實現過程、版本集成、測試過程(前綴為TR_)、軟件發布、產品交付中的任務與requirement中迭代開發過程中的需求點的覆蓋關系也可以是一對多的關系。如圖

　　

　　通過以上的覆蓋關系可以很快地查找到項目過程中有哪些過程缺失，有哪些技術文檔和質量記錄缺失，并且可以比較快的統計出過程的缺失率和技術文檔和質量記錄缺失率，還可以方便項目負責人對項目過程和進度的控制。

　　1.3 TestDirector中test lab的設計

　　1.3.1 test lab的命名規則分以下兩種：

　　1、 項目代碼 + _ + requirement頁面中第二級節點名稱(項目計劃過程、軟件發布過程、產品交付過程)

　　2、 項目代碼 + _ + 迭代版本號 + _ + TestDirector的testplan頁面中第三級節點名稱(需求分析、設計過程、程序實現過程、版本集成過程、測試過程)

　　將test plan中的任務加入到對應的test lab中進行運行。

　　1.3.2 在test lab中運行任務所表示的意義如下：

　　1、 項目計劃過程、需求分析、設計過程在test lab中任務的運行表示對這些過程中的相關技術文檔進行評審，一般是由評審組長和評審記錄員執行。與這些test lab含義相同的還有程序實現過程中的代碼復審和測試過程中的測試用例等文檔的評審(有TR_前綴的任務)。

　　2、 版本集成、軟件發布過程、產品交付過程在test lab中任務的運行表示這些過程的完成情況。一般由項目經理和集成人員執行。

　　3、 程序實現過程(不包含代碼復審)在test lab中任務的運行結果表示開發人員對所編寫的代碼進行調試和單元測試的情況，集成人員可以通過運行結果決定是否集成。一般由軟件開發人員執行。

　　4、 測試過程在test lab中測試用例的運行結果表示對產品測試的結果，一般由測試人員執行。

　　1.3.3 TestDirector的test lab頁面所需的字段：

　　編號字段名字段說明備注

　　執行人

　　自動生成

　　執行時間自動生成

　　任務狀態(status)手工填寫(pass、failde、no run等)

　　結果(Actual)手工填寫記錄過程實際操作的情況和相關信息。

　　1.4 TestDirector中defects的操作情況

　　Defects中存在的問題一般都是評審和測試產生的問題，這些問題可以按產品bug管理流程的要求進行管理和操作。

　　二、使用TestDirector7.6的好處

　　1、 TestDirector7.6的使用在一定程度上可以方便QA人員和相關負責人對項目過程和進度的了解和控制，可以較快的發現過程和相關文檔的缺失情況，并且幫助可以QA人員和相關負責人了解某一需求點在某一時間處于什么過程中。

　　2、 TestDirector7.6中有些字段的數據可以根據需要自動生成，這樣可以保證數據的真實性。如通過一些自動產生的時間字段可以知道哪些過程是按流程進行的，哪些過程是后來補做的。

　　3、 TestDirector7.6的使用有利于度量工作的開展。TestDirector7.6中可以根據需要增加字段，這樣有利于數據的采集和統計分析，并且該工具本身也有統計功能。如使用TestDirector7.6可以較快的統計出過程的缺失率和技術文檔和質量記錄缺失率、以及各種評審方式所占的比例等。

　　4、 TestDirector7.6的使用可以減少QA人員的過程檢查時間，這樣即使QA人員和測試人員是同一個人，工作量也不會很大，開發組提交測試進行軟件測試，沒有軟件測試時可以做過程檢查，這樣既對產品質量進行了檢查，也對過程質量進行了檢查。