《軟件測試基礎(chǔ)》課件-第10章

第10章軟件測試管理

10.1過程管理10.2需求管理10.3軟件配置管理10.4缺陷管理10.5風(fēng)險(xiǎn)管理10.6思考與習(xí)題

10.1過程管理

軟件測試過程管理在各個(gè)階段的具體內(nèi)容不同，在每個(gè)階段，測試任務(wù)都要經(jīng)過從計(jì)劃、設(shè)計(jì)、執(zhí)行到結(jié)果分析、總結(jié)等一系列相同步驟。

軟件測試過程管理主要集中在軟件測試項(xiàng)目啟動(dòng)、測試計(jì)劃制定、測試用例設(shè)計(jì)、測試執(zhí)行、測試結(jié)果審查和分析，以及如何開發(fā)或使用測試過程管理工具。10.1.1測試的組織

實(shí)施一個(gè)測試的首要步驟之一就是考慮測試中涉及到的人員的高級(jí)組織、他們之間的相互關(guān)系以及如何將測試過程集成到現(xiàn)有的業(yè)務(wù)管理結(jié)構(gòu)中。

圖10.1給出了測試過程組織的一種常見方法。圖10.1測試過程組織

1)測試主管

測試主管有權(quán)管理測試過程日常的組織，負(fù)責(zé)保證在給定的時(shí)間、資源和費(fèi)用的限制下設(shè)計(jì)測試項(xiàng)目產(chǎn)生滿足所需的質(zhì)量標(biāo)準(zhǔn)的產(chǎn)品。

測試主管在適當(dāng)?shù)臅r(shí)候也要負(fù)責(zé)與開發(fā)組進(jìn)行聯(lián)絡(luò)，保證他們遵循在過程中引用的單元測試和集成測試方法。測試主管還要同獨(dú)立測試觀察員聯(lián)系，接收有關(guān)沒有正確遵循測試過程的測試項(xiàng)目的報(bào)告。測試主管向公司內(nèi)的高級(jí)主管或領(lǐng)導(dǎo)報(bào)告，如質(zhì)量保證主管或信息技術(shù)領(lǐng)導(dǎo)。在大的公司中，尤其對(duì)于那些遵循規(guī)范的項(xiàng)目管理過程的公司中，測試主管可以向測試程序委員會(huì)報(bào)告，該委員會(huì)負(fù)責(zé)把握測試程序的項(xiàng)目管理的總體方向。

測試主管的職位可以是一個(gè)兼職的角色，可以由一個(gè)現(xiàn)有的高級(jí)主管或領(lǐng)導(dǎo)(如QA主管或IT領(lǐng)導(dǎo))兼任。在測試涉及的人員相對(duì)較少的小公司中尤其可能出現(xiàn)這種情況。

2)測試組組長

測試組組長有權(quán)運(yùn)作一個(gè)項(xiàng)目。其職責(zé)包括為測試分析員和測試者分配任務(wù)，按照預(yù)定的計(jì)劃監(jiān)控他們的工作進(jìn)度，建立和維護(hù)測試項(xiàng)目文件系統(tǒng)，保證產(chǎn)生測試項(xiàng)目相關(guān)材料順利完成。這些材料包括：測試計(jì)劃文檔、測試規(guī)范說明文檔。測試組組長負(fù)責(zé)完成這些文檔，也可以授權(quán)測試分析員來完成這些文檔。

測試組組長聽取一個(gè)或多個(gè)測試分析員和測試者的報(bào)告，并向測試主管匯報(bào)。測試組組長將和獨(dú)立測試觀察員聯(lián)系(如討論參加一個(gè)特定測試的可行性)，適當(dāng)?shù)臅r(shí)候還會(huì)和開發(fā)組組長聯(lián)系(完成測試項(xiàng)目的早期計(jì)劃和基本的測試設(shè)計(jì)，并確定AUT測試的有效性)。在驗(yàn)收測試時(shí)，測試組組長負(fù)責(zé)和用戶代表、操作代表聯(lián)系，以便有一個(gè)或多個(gè)用戶來執(zhí)行用戶和操作驗(yàn)收測試。

3)測試分析員

測試分析員負(fù)責(zé)設(shè)計(jì)和實(shí)現(xiàn)用于完成AUT測試的一個(gè)或多個(gè)測試腳本以及相關(guān)的測試用例。測試分析員也可以派去協(xié)助測試組組長生成測試規(guī)格說明文檔。

在調(diào)試測試用例的設(shè)計(jì)過程中，測試分析員需要分析AUT的需求規(guī)格說明，以便確定必須測試的特定需求。在這個(gè)過程中，測試分析員應(yīng)該優(yōu)先考慮測試用例，以反映被確認(rèn)的特性的重要性以及在正常使用AUT中導(dǎo)致失敗的特性的風(fēng)險(xiǎn)?？梢圆捎媒o每個(gè)測試用例賦一個(gè)高、中或低的值的方法來完成這一工作。這是一項(xiàng)重要的工作，因?yàn)檫@種方法可以幫助測試組組長在時(shí)間和資源有限的情況下集中測試的人力。在完成測試項(xiàng)目后，測試分析員負(fù)責(zé)備份和歸檔所有的測試文檔和材料。這些材料將提交給測試組組長進(jìn)行歸檔。測試分析員還負(fù)責(zé)完成一份測試總結(jié)報(bào)告，這份報(bào)告簡要介紹該測試項(xiàng)目中的關(guān)鍵點(diǎn)。

測試分析員要向測試組組長匯報(bào)，并在開始測試AUT之前和測試者聯(lián)系，向他們簡單介紹測試者的任務(wù)。

4)測試者

測試者主要負(fù)責(zé)執(zhí)行由測試分析員建立的測試腳本，并負(fù)責(zé)解釋測試用例結(jié)果并將結(jié)果記錄到文檔中。

在執(zhí)行測試腳本之前，測試者首先要建立和初始化測試環(huán)境，其中包括測試數(shù)據(jù)和測試硬件，以及其它支持測試所需的軟件(加模擬器和測試輔助程序)。

在測試執(zhí)行過程中，測試者負(fù)責(zé)填寫測試結(jié)果記錄表格，以便記錄執(zhí)行每個(gè)測試腳本時(shí)觀察到的結(jié)果。測試者使用測試腳本對(duì)預(yù)期結(jié)果進(jìn)行描述。

在完成測試以后，測試者還負(fù)責(zé)備份測試數(shù)據(jù)、模擬器或測試輔助程序以及測試中使用的硬件的說明。這些材料將提交給測試組組長歸檔。10.1.2測試計(jì)劃階段

測試計(jì)劃要針對(duì)測試目的來規(guī)定測試的任務(wù)、所需的各種資源和投入、人員角色的安排、預(yù)見可能出現(xiàn)的問題和風(fēng)險(xiǎn)，以指導(dǎo)測試的執(zhí)行，最終實(shí)現(xiàn)測試的目標(biāo)，保證軟件產(chǎn)品的質(zhì)量。

編寫測試計(jì)劃的目的是：

(1)為測試各項(xiàng)活動(dòng)制定一個(gè)現(xiàn)實(shí)可行的、綜合的計(jì)劃，包括每項(xiàng)測試活動(dòng)的對(duì)象、范圍、方法、進(jìn)度和預(yù)期結(jié)果。

(2)為項(xiàng)目實(shí)施建立一個(gè)組織模型，并定義測試項(xiàng)目中每個(gè)角色的責(zé)任和工作內(nèi)容。

(3)開發(fā)有效的測試模型，能正確地驗(yàn)證正在開發(fā)的軟件系統(tǒng)。

(4)確定測試所需要的時(shí)間和資源，以保證其可獲得性和有效性。

(5)確立每個(gè)測試階段測試完成以及測試成功的標(biāo)準(zhǔn)和要達(dá)到的目標(biāo)。

(6)識(shí)別出測試活動(dòng)中的各種風(fēng)險(xiǎn)，并消除可能存在的風(fēng)險(xiǎn)，降低那些不可能消除的風(fēng)險(xiǎn)所帶來的損失。

1．測試策略的制定

測試策略描述當(dāng)前測試的目標(biāo)和所采用的測試方法。這個(gè)目標(biāo)不是上述測試計(jì)劃的目標(biāo)，而是針對(duì)某個(gè)應(yīng)用軟件系統(tǒng)或程序的。具體的測試任務(wù)要達(dá)到的預(yù)期結(jié)果，包括在規(guī)定的時(shí)間內(nèi)哪些測試內(nèi)容要完成，軟件產(chǎn)品的特性或質(zhì)量在哪些方面要得到確認(rèn)。測試策略還要描述測試不同階段(單元測試、集成測試、系統(tǒng)測試)的測試對(duì)象、范圍和方法以及每個(gè)階段內(nèi)所要進(jìn)行的測試類型(功能測試、性能測試、壓力測試等)。

2．測試計(jì)劃過程

測試計(jì)劃經(jīng)過計(jì)劃初期、起草、討論、審查等不同階段，最終生成。測試計(jì)劃過程如下所示：

(1)計(jì)劃初期是收集整體項(xiàng)目計(jì)劃、需求分析、功能設(shè)計(jì)、系統(tǒng)原型、用例報(bào)告等文檔或信息，理解用戶的真正需求，了解技術(shù)難點(diǎn)、弱點(diǎn)或新的技術(shù)，和其余項(xiàng)目相關(guān)人員交流，在各個(gè)主要方面達(dá)到一致的理解。

(2)測試計(jì)劃最關(guān)鍵的一步就是確定測試需求、測試層次。將軟件分解成單元，對(duì)各個(gè)單元寫成測試需求，測試需求也是測試設(shè)計(jì)和開發(fā)測試用例的基礎(chǔ)，是用來衡量測試覆蓋率的重要指標(biāo)。

(3)計(jì)劃起草。根據(jù)計(jì)劃初期所掌握的各種信息、知識(shí)，確定測試策略，設(shè)計(jì)測試方法，完成測試計(jì)劃的框架。

(4)內(nèi)部審查。在提供給其它部門討論之前，先在測試小組或部門內(nèi)部進(jìn)行審查。

(5)計(jì)劃討論和修改。召開有需求分析、設(shè)計(jì)、開發(fā)人員參加的計(jì)劃討論會(huì)議，測試組長將測試計(jì)劃設(shè)計(jì)的思想、策略做較詳細(xì)的介紹，并聽取大家對(duì)測試計(jì)劃中各個(gè)部分的意見，進(jìn)行討論交流。

(6)測試計(jì)劃的多方審查。項(xiàng)目中的每個(gè)人(即市場人員、開發(fā)人員、技術(shù)支持人員及測試人員)都應(yīng)當(dāng)參與審查。

(7)測試計(jì)劃的定稿和批準(zhǔn)。在計(jì)劃討論、審查的基礎(chǔ)上，綜合各方面的意見，就可以完成測試計(jì)劃書，然后報(bào)給測試經(jīng)理或QA經(jīng)理，得到批準(zhǔn)，方可執(zhí)行。

3．測試計(jì)劃的要點(diǎn)

軟件測試計(jì)劃的內(nèi)容主要包括：產(chǎn)品基本情況、測試需求說明、測試策略說明、測試資源配置、計(jì)劃表、問題跟蹤報(bào)告、測試計(jì)劃的評(píng)審、結(jié)果等。除了產(chǎn)品基本情況、測試需求說明、測試策略等，測試計(jì)劃的焦點(diǎn)集中在：

(1)計(jì)劃的目的：項(xiàng)目的范圍和目標(biāo)，各階段的測試范圍、技術(shù)約束和管理特點(diǎn)。

(2)項(xiàng)目估算：使用的歷史數(shù)據(jù)，使用的評(píng)估技術(shù)，工作量、成本、時(shí)間估算依據(jù)。

(3)風(fēng)險(xiǎn)計(jì)劃：測試可能存在的風(fēng)險(xiǎn)的分析、識(shí)別，以及風(fēng)險(xiǎn)的回避、監(jiān)控、管理。

(4)日程：項(xiàng)目工作分解結(jié)構(gòu)，并采用時(shí)限圖、甘特圖等方法制定時(shí)間/資源表。

(5)項(xiàng)目資源：人員、硬件和軟件等資源的組織和分配，人力資源是重點(diǎn)，日程安排是核心。

(6)跟蹤和控制機(jī)制：質(zhì)量保證和控制，變更管理和控制等。測試計(jì)劃書的內(nèi)容也可以按集成測試、系統(tǒng)測試、驗(yàn)收測試等階段去組織，為每一個(gè)階段制定一個(gè)計(jì)劃書，也可以為每個(gè)測試任務(wù)/目的(安全性測試、性能測試、可靠性測試等)制定特別的計(jì)劃書。

4．測試計(jì)劃的編寫內(nèi)容

測試計(jì)劃內(nèi)容有被測軟件的背景信息、測試目標(biāo)、測試步驟、測試數(shù)據(jù)整理以及評(píng)估準(zhǔn)則。它包括：

(1)測試環(huán)境。在不同的條件下進(jìn)行測試，所得到的結(jié)果是不同的。在測試計(jì)劃中測試環(huán)境指用戶使用環(huán)境或業(yè)務(wù)運(yùn)行環(huán)境。

(2)測試基本原理和策略。

(3)測試計(jì)劃階段劃分。

(4)測試計(jì)劃要點(diǎn)。

(5)功能描述和功能覆蓋說明。

(6)測試用例清單。說明每個(gè)測試用例所測試的內(nèi)容。

(7)測試開始準(zhǔn)則和退出準(zhǔn)則。

每個(gè)測試用例的序言至少包括下列信息：

(1)測試用例說明和用途。

(2)設(shè)置需求(輸入、輸出)。

(3)運(yùn)行測試用例的操作命令。

(4)正常和異常信息。

(5)編寫測試用例的作者。10.1.3軟件測試設(shè)計(jì)和開發(fā)

當(dāng)測試計(jì)劃完成之后，測試過程就要進(jìn)入軟件測試設(shè)計(jì)和開發(fā)階段。軟件測試設(shè)計(jì)是建立在測試計(jì)劃書的基礎(chǔ)上的。認(rèn)真理解測試計(jì)劃的測試大綱、測試內(nèi)容及測試的通過準(zhǔn)則，通過測試用例來完成測試內(nèi)容與程序邏輯的轉(zhuǎn)換，作為測試實(shí)施的依據(jù)，以實(shí)現(xiàn)所確定的測試目標(biāo)。軟件設(shè)計(jì)是將軟件需求轉(zhuǎn)換成為軟件表示的過程，主要描繪出系統(tǒng)結(jié)構(gòu)、詳細(xì)的處理過程和數(shù)據(jù)庫模式；軟件測試設(shè)計(jì)則是將測試需求轉(zhuǎn)換成測試用例的過程，它要描述測試環(huán)境、測試執(zhí)行的范圍、層次和用戶的使用場景以及測試輸入和預(yù)期的測試輸出等。所以軟件測試設(shè)計(jì)和開發(fā)是軟件測試過程中一個(gè)技術(shù)深、要求高的關(guān)鍵階段。軟件測試設(shè)計(jì)和開發(fā)的主要內(nèi)容有：

(1)制定測試的技術(shù)方案，確認(rèn)各個(gè)測試階段要采用的測試技術(shù)、測試環(huán)境和平臺(tái)，以及選擇什么樣的測試工具。系統(tǒng)測試中的安全性、可靠性、穩(wěn)定性、有效性等測試技術(shù)方案是這部分工作內(nèi)容的重點(diǎn)。

(2)設(shè)計(jì)測試用例。根據(jù)產(chǎn)品需求分析、系統(tǒng)設(shè)計(jì)等規(guī)格說明書，在測試技術(shù)選擇的方案基礎(chǔ)上，設(shè)計(jì)具體的測試用例。

(3)設(shè)計(jì)測試用例特定的集合，滿足一些特定的測試目的和任務(wù)，即根據(jù)測試目標(biāo)、測試用例的特性和屬性(優(yōu)先級(jí)、層次、模塊等)來選擇不同的測試用例，構(gòu)成執(zhí)行某個(gè)特定測試任務(wù)的測試用例集合(組)，如基本測試用例組、專用測試用例組、性能測試用例組、其它測試用例組等。

(4)測試開發(fā)。根據(jù)所選擇的測試工具，將所有可以進(jìn)行自動(dòng)化測試的測試用例轉(zhuǎn)換為測試腳本的過程。

(5)測試環(huán)境的設(shè)計(jì)。根據(jù)所選擇的測試平臺(tái)以及測試用例所要求的特定環(huán)境，進(jìn)行服務(wù)器、網(wǎng)絡(luò)等測試環(huán)境的設(shè)計(jì)。

1.測試用例設(shè)計(jì)的方法和管理

軟件測試用例設(shè)計(jì)的方法有“白盒”測試和“黑盒”測試相對(duì)應(yīng)的設(shè)計(jì)方法。“黑盒”測試的用例設(shè)計(jì)，采用等價(jià)類劃分、因果圖法、邊值分析、用戶界面測試、配置測試、安裝選項(xiàng)驗(yàn)證等方法，適用于功能測試和驗(yàn)收測試?！鞍缀小睖y試的用例設(shè)計(jì)有以下方法：

(1)采用邏輯覆蓋(包括程序代碼的語句覆蓋、條件覆蓋、分支覆蓋)的結(jié)構(gòu)測試用例的設(shè)計(jì)方法。

(2)基于程序結(jié)構(gòu)的域測試用例設(shè)計(jì)方法。“域”是指程序的輸入空間，域測試正是在分析輸入空間的基礎(chǔ)上，完成域的分類、定義和驗(yàn)證，從而對(duì)各種不同的域選擇適當(dāng)?shù)臏y試點(diǎn)(用例)進(jìn)行測試。

(3)數(shù)據(jù)流測試用例設(shè)計(jì)的方法，是通過程序的控制流，從建立的數(shù)據(jù)目標(biāo)狀態(tài)的序列中發(fā)現(xiàn)異常的結(jié)構(gòu)測試方法。

(4)根據(jù)對(duì)象狀態(tài)或等待狀態(tài)變化來設(shè)計(jì)測試用例，也是比較常見的方法。

(5)基于程序錯(cuò)誤的變異來設(shè)計(jì)測試用例，可以有效地發(fā)現(xiàn)程序中某些特定的錯(cuò)誤。

(6)基于代數(shù)運(yùn)算符號(hào)的測試用例設(shè)計(jì)方法，受分支問題、二義性問題和大程序問題的困擾，使用較少。

2.測試開發(fā)

根據(jù)所選擇的測試工具腳本語言，編寫測試腳本，將所有可以進(jìn)行自動(dòng)化測試的測試用例轉(zhuǎn)化為測試腳本。其輸入就是基于測試需求的測試用例，輸出是測試腳本和與之相對(duì)應(yīng)的期望結(jié)果，這種期望結(jié)果一般存儲(chǔ)在數(shù)據(jù)庫中或特定的格式化文件中。

測試開發(fā)的步驟如下：

首先要設(shè)立測試腳本開發(fā)環(huán)境，安裝測試工具軟件，設(shè)置管理服務(wù)器和具有代理的客戶端，建立項(xiàng)目的共享路徑、目錄，并能連接到腳本存儲(chǔ)庫和被測軟件等。

然后執(zhí)行錄制測試的初始化過程、獨(dú)立模塊過程、導(dǎo)航過程和其它操作過程。結(jié)合已經(jīng)建立的測試用例，將錄制的測試腳本進(jìn)行組織、調(diào)試和修改，構(gòu)造成一個(gè)有效的測試腳本體系，并建立外部數(shù)據(jù)集合。10.1.4測試執(zhí)行階段

當(dāng)測試用例的設(shè)計(jì)和測試腳本的開發(fā)完成之后，就開始執(zhí)行測試。測試的執(zhí)行有手工測試和自動(dòng)化測試兩種。手工測試指在合適的測試環(huán)境上，按照測試用例的條件、步驟要求，準(zhǔn)備測試數(shù)據(jù)，對(duì)系統(tǒng)進(jìn)行操作，比較實(shí)際結(jié)果和測試用例所描述的期望結(jié)果，以確定系統(tǒng)是否正常運(yùn)行或正常表現(xiàn)。自動(dòng)化測試是通過測試工具，運(yùn)行測試腳本，并自動(dòng)記錄下測試結(jié)果。

針對(duì)每個(gè)測試階段(代碼審查、單元測試、集成測試、功能測試、系統(tǒng)測試、驗(yàn)收測試和安裝測試等)的結(jié)果進(jìn)行分析，保證每個(gè)階段的測試任務(wù)得到執(zhí)行，達(dá)到階段性目標(biāo)。10.1.5測試執(zhí)行結(jié)束和測試總結(jié)

測試執(zhí)行全部完成，并不意味著測試項(xiàng)目的結(jié)束。測試項(xiàng)目結(jié)束的階段性標(biāo)志是將測試報(bào)告或質(zhì)量報(bào)告發(fā)出去后，得到測試經(jīng)理或項(xiàng)目經(jīng)理的認(rèn)可。除了測試報(bào)告或質(zhì)量報(bào)告的寫作之外，還要對(duì)測試計(jì)劃、測試設(shè)計(jì)和測試執(zhí)行等進(jìn)行檢查、分析，完成項(xiàng)目的總結(jié)，編寫“測試總結(jié)報(bào)告”。10.1.6測試過程改進(jìn)

軟件測試過程改進(jìn)主要著眼于合理調(diào)整各項(xiàng)測試活動(dòng)的時(shí)序關(guān)系，優(yōu)化各項(xiàng)測試活動(dòng)的資源配置以及實(shí)現(xiàn)各項(xiàng)測試活動(dòng)效果的最優(yōu)化。在軟件測試過程中，過程改進(jìn)被賦予了舉足輕重的地位，在測試計(jì)劃、實(shí)施、檢查、改進(jìn)的循環(huán)中，過程改進(jìn)既是一次質(zhì)量活動(dòng)的終點(diǎn)，又是下次質(zhì)量活動(dòng)的原點(diǎn)，起著承上啟下的作用。

1．軟件測試過程改進(jìn)的概念

測試過程的改進(jìn)對(duì)象應(yīng)該包括三個(gè)方面：組織、技術(shù)和人員。測試過程改進(jìn)需要對(duì)組織給予特別關(guān)注，因?yàn)檫^程都是基于特定的組織架構(gòu)建設(shè)的，而且組織設(shè)置是否合理對(duì)過程的好壞有決定性的影響。軟件測試組織的不良架構(gòu)通常表現(xiàn)在：

(1)沒有恰當(dāng)?shù)慕巧粉欗?xiàng)目進(jìn)展。

(2)沒有恰當(dāng)?shù)慕巧M(jìn)行缺陷控制、變更和版本追蹤。

(3)項(xiàng)目在測試階段效率低下、過程混亂。

(4)只有測試經(jīng)理了解項(xiàng)目，項(xiàng)目成了個(gè)人的項(xiàng)目，而不是組織的項(xiàng)目。

(5)關(guān)心進(jìn)度，而忘記了項(xiàng)目的另外兩個(gè)要素—質(zhì)量和成本。

上述問題可從組織上找出原因。因此在測試過程改進(jìn)中可以先將測試從開發(fā)活動(dòng)中分離出來，把缺陷控制、版本管理和變更管理從項(xiàng)目管理中分離出來。此外，需要給測試經(jīng)理賦予明確的職責(zé)和目標(biāo)。技術(shù)的改進(jìn)包括對(duì)流程、方法和工具的改進(jìn)，它包括組織或者項(xiàng)目對(duì)流程進(jìn)行明確的定義，引入統(tǒng)一的管理方法，并使用標(biāo)準(zhǔn)的經(jīng)過組織認(rèn)可的工具和模板。人員的改進(jìn)主要是指對(duì)企業(yè)文化的改進(jìn)，它將促使建立高效率的團(tuán)隊(duì)和組織。由于測試過程改進(jìn)是一項(xiàng)長期的、沒有終點(diǎn)的活動(dòng)，而且要獲得改進(jìn)過程的收益也是長期的過程，因此在起步實(shí)施測試過程改進(jìn)時(shí)，要充分考慮戰(zhàn)略，并根據(jù)公司的戰(zhàn)略目標(biāo)確定測試部門的戰(zhàn)略，描繪遠(yuǎn)景。將測試過程改進(jìn)與公司戰(zhàn)略目標(biāo)相聯(lián)系，是改進(jìn)成功實(shí)施的必要條件，也是各公司在實(shí)施測試過程改進(jìn)中獲得的最佳實(shí)踐。

2.軟件測試過程改進(jìn)的具體方法

過程改進(jìn)在軟件測試過程中占有舉足輕重的位置，因此為了更好地保證軟件質(zhì)量，測試過程改進(jìn)是測試人員經(jīng)常要做的事情。下面列出了一些軟件測試過程改進(jìn)的具體方法：

(1)調(diào)整測試活動(dòng)的時(shí)序關(guān)系。在軟件測試過程的測試計(jì)劃中，不恰當(dāng)?shù)臏y試時(shí)序會(huì)引起誤工和測試進(jìn)度失控。例如，具體到某個(gè)工程實(shí)踐中，有些測試活動(dòng)是可以并行的，有些測試活動(dòng)是可以歸并完成的，有些測試活動(dòng)在時(shí)間上存在線性關(guān)系等。所有這些一定要區(qū)分清楚并且要做最優(yōu)化調(diào)整，否則會(huì)對(duì)測試進(jìn)度產(chǎn)生不必要的影響。

(2)優(yōu)化測試活動(dòng)資源配置。在軟件測試過程中，必然會(huì)涉及到人力、設(shè)備、場地、軟件環(huán)境與經(jīng)費(fèi)等資源。那么如何合理地調(diào)配各項(xiàng)資源給相關(guān)的測試活動(dòng)是非常值得斟酌的，否則會(huì)引起誤工和測試進(jìn)度的失控。在測試資源配置中最常見的是人力資源的調(diào)配，測試部門如果能深入了解員工的專長與興趣所在，在進(jìn)行人員分配時(shí)，根據(jù)各自的特點(diǎn)進(jìn)行分配，就能對(duì)測試活動(dòng)的開展起到事半功倍的效果。

(3)提高測試計(jì)劃的指導(dǎo)性。測試計(jì)劃的指導(dǎo)性是指測試計(jì)劃的執(zhí)行能力。在軟件測試過程中，很多時(shí)候?qū)嶋H的測試和測試計(jì)劃是脫節(jié)的，或者說很大程度上沒有按照測試計(jì)劃去執(zhí)行。測試計(jì)劃的完成不僅僅是起草測試大綱，而且是為了確保測試大綱中計(jì)劃的內(nèi)容能真正被執(zhí)行、真正用于指導(dǎo)測試工作，為了更好地完成測試活動(dòng)，保證軟件的質(zhì)量。

(4)確立合理的度量模型和標(biāo)準(zhǔn)。在測試過程改進(jìn)中，測試過程改進(jìn)小組應(yīng)根據(jù)企業(yè)與項(xiàng)目的實(shí)際情況制定適合自己公司的質(zhì)量度量模型和標(biāo)準(zhǔn)，做出符合自己公司發(fā)展策略的投入。但是質(zhì)量度量模型和標(biāo)準(zhǔn)的確立不是馬上就可以進(jìn)行的，而是測試過程改進(jìn)小組隨著測試過程的進(jìn)行不斷實(shí)踐、不斷總結(jié)、不斷改進(jìn)的。

(5)提高覆蓋率。覆蓋率越高，表明測試的質(zhì)量越高。覆蓋率包括內(nèi)容覆蓋和技術(shù)覆蓋。內(nèi)容覆蓋指的是起草測試計(jì)劃、設(shè)計(jì)測試用例、執(zhí)行測試用例和跟蹤軟件缺陷。內(nèi)容覆蓋率越高，就越能避免故障被遺漏的情況。技術(shù)覆蓋指一項(xiàng)技術(shù)指標(biāo)要盡可能地做到測試技術(shù)的覆蓋，采用科學(xué)的方法來驗(yàn)證某項(xiàng)指標(biāo)，可以更好地保證產(chǎn)品的質(zhì)量。

10.2需求管理

10.2.1需求管理概述

StandishGroup從1994年到2001年的CHAOSReports證實(shí)，導(dǎo)致項(xiàng)目失敗的最重要的原因與需求有關(guān)。2001年，StandishGroup的CHAOSReports報(bào)導(dǎo)了該公司的一項(xiàng)研究，該公司對(duì)多個(gè)項(xiàng)目作調(diào)查后發(fā)現(xiàn)，百分之七十四的項(xiàng)目是失敗的，即這些項(xiàng)目不能按時(shí)按預(yù)算完成。其中提到最多的導(dǎo)致項(xiàng)目失敗的原因就是“變更用戶需求”。10.2.2軟件測試中的需求分析

1．熟悉需求背景及商業(yè)目標(biāo)

(1)了解清楚項(xiàng)目發(fā)起的原因是為了解決用戶的什么問題。

(2)清楚當(dāng)前的解決方案是不是最優(yōu)的以及為什么會(huì)這樣做。

2．業(yè)務(wù)模型法

(1)考慮本項(xiàng)目與外部系統(tǒng)的交互，劃分系統(tǒng)邊界(除了本項(xiàng)目的需求中要求做的事情，其它的都可以是外部系統(tǒng)，本系統(tǒng)和外部系統(tǒng)之間的交互就是系統(tǒng)的邊界)。可以參考系統(tǒng)分析說明書。

(2)確定測試范圍和關(guān)注點(diǎn)。系統(tǒng)的邊界是測試的重點(diǎn)，特別需要關(guān)注邊界交互時(shí)的數(shù)據(jù)交互。

3．業(yè)務(wù)場景法

(1)考慮用例的調(diào)用者，考慮每一個(gè)用例提供的服務(wù)是供哪些外部用例或者系統(tǒng)調(diào)用，找出所有的調(diào)用者。調(diào)用的前提、約束都要考慮。每一個(gè)調(diào)用都可以考慮成一個(gè)大的業(yè)務(wù)流程。(一般和外部有交互的用例出錯(cuò)的概率比較大，需要重點(diǎn)關(guān)注。具體被哪些外部調(diào)用，每個(gè)產(chǎn)品線都需要自己整理添加。)

(2)考慮系統(tǒng)內(nèi)部各個(gè)用例之間的交互(有可能PD劃分用例的粒度不同，我們暫時(shí)考慮用戶一次提交并且系統(tǒng)的狀態(tài)及數(shù)據(jù)發(fā)生變化的功能是一個(gè)用例)，形成內(nèi)部業(yè)務(wù)流程圖。需要分析每個(gè)用例之間的約束關(guān)系、執(zhí)行條件，設(shè)計(jì)出各種業(yè)務(wù)流程圖。

4．功能分解法

(1)業(yè)務(wù)功能：與用戶實(shí)際業(yè)務(wù)直接相關(guān)的功能或細(xì)節(jié)。

(2)輔助功能：輔助完成業(yè)務(wù)功能的一些功能或細(xì)節(jié)，比如設(shè)置過濾條件。

(3)數(shù)據(jù)約束：主要用于控制在執(zhí)行功能時(shí)，數(shù)據(jù)的顯示范圍、數(shù)據(jù)之間的關(guān)系等。

(4)易用性需求：產(chǎn)品中必須提供便于功能操作使用的一些細(xì)節(jié)，比如快捷鍵就是典型的易用性需求。

(5)編輯約束：在功能執(zhí)行時(shí)，對(duì)輸入數(shù)據(jù)項(xiàng)目設(shè)定一些約束性條件，比如只能輸入數(shù)字。

(6)參數(shù)需求：在功能中，需要根據(jù)參數(shù)設(shè)置不同，進(jìn)行不同處理的細(xì)節(jié)。

(7)權(quán)限需求：這里的權(quán)限是指在功能的執(zhí)行過程中，根據(jù)不同的權(quán)限進(jìn)行不同的處理，不包括直接限制某個(gè)功能的權(quán)限。

(8)性能約束：執(zhí)行功能時(shí)，必須滿足的性能要求目前基本不涉及。

10.3軟件配置管理

10.3.1軟件配置管理概述

軟件配置管理(SoftwareConfigurationManagement，SCM)是一種標(biāo)識(shí)、組織和控制修改的技術(shù)。軟件配置管理應(yīng)用于整個(gè)軟件工程過程。

軟件配置管理是在貫穿整個(gè)軟件生命周期中建立和維護(hù)項(xiàng)目產(chǎn)品的完整性。它的基本目標(biāo)包括：

(1)軟件配置管理的各項(xiàng)工作是有計(jì)劃進(jìn)行的。

(2)被選擇的項(xiàng)目產(chǎn)品得到識(shí)別、控制并且可以被相關(guān)人員獲取。

(3)已識(shí)別出的項(xiàng)目產(chǎn)品的更改得到控制。

(4)使相關(guān)組別和個(gè)人及時(shí)了解軟件基準(zhǔn)的狀態(tài)和內(nèi)容。

為了達(dá)到上述目標(biāo)，如下的方針應(yīng)該得到貫徹執(zhí)行：

(1)技術(shù)部門經(jīng)理和具體項(xiàng)目主管應(yīng)該使用和遵循XSSC的OSSP中所描述的軟件配置管理的工作過程。

(2)施行軟件配置管理的職責(zé)應(yīng)被明確分配。相關(guān)人員得到軟件配置管理方面的培訓(xùn)。

(3)技術(shù)部門經(jīng)理和具體項(xiàng)目主管應(yīng)該明確他們?cè)谙嚓P(guān)項(xiàng)目中所擔(dān)負(fù)的軟件配置管理方面的責(zé)任。

(4)軟件配置管理工作應(yīng)該享有足夠的資金支持，這需要在客戶、技術(shù)部門經(jīng)理和具體項(xiàng)目主管之間協(xié)商。

(5)軟件配置管理應(yīng)該實(shí)施于如下產(chǎn)品：對(duì)外交付的軟件產(chǎn)品以及那些被選定的在項(xiàng)目中使用的支持類工具等。

(6)軟件配置的整體性在整個(gè)項(xiàng)目生命周期中得到控制。

(7)軟件質(zhì)量保證人員應(yīng)該定期審核各類軟件基準(zhǔn)以及軟件配置管理工作。

(8)軟件基準(zhǔn)的狀態(tài)和內(nèi)容能夠及時(shí)通知給相關(guān)組別和個(gè)人。10.3.2軟件配置管理角色職責(zé)

對(duì)于任何一個(gè)管理流程來說，保證該流程正常運(yùn)轉(zhuǎn)的前提條件就是要有明確的角色、職責(zé)和權(quán)限的定義。特別是在引入了軟件配置管理的工具之后，比較理想的狀態(tài)就是：組織內(nèi)的所有人員按照不同的角色要求，根據(jù)系統(tǒng)賦予的權(quán)限來執(zhí)行相應(yīng)的動(dòng)作。因此，在本文所介紹的這個(gè)軟件配置管理過程中主要涉及下列的角色和分工。

1)項(xiàng)目經(jīng)理

項(xiàng)目經(jīng)理(ProjectManager，PM)是整個(gè)軟件研發(fā)活動(dòng)的負(fù)責(zé)人，他根據(jù)軟件配置控制委員會(huì)的建議，批準(zhǔn)配置管理的各項(xiàng)活動(dòng)并控制它們的進(jìn)程。其具體職責(zé)為以下幾項(xiàng)：

(1)制定和修改項(xiàng)目的組織結(jié)構(gòu)和配置管理策略。

(2)批準(zhǔn)、發(fā)布配置管理計(jì)劃。

(3)決定項(xiàng)目起始基線和開發(fā)里程碑。

(4)接受并審閱配置控制委員會(huì)的報(bào)告。

2)配置控制委員會(huì)

(1)配置控制委員會(huì)(ConfigurationControlBoard，CCB)負(fù)責(zé)指導(dǎo)和控制配置管理的各項(xiàng)具體活動(dòng)的進(jìn)行，為項(xiàng)目經(jīng)理的決策提供建議。其具體職責(zé)為以下幾項(xiàng)：定制開發(fā)子系統(tǒng)；定制訪問控制；制定常用策略。

(2)建立、更改基線的設(shè)置，審核變更申請(qǐng)。

(3)根據(jù)配置管理員的報(bào)告決定相應(yīng)的對(duì)策。

3)配置管理員

配置管理員(ConfigurationManagementOfficer，CMO)根據(jù)配置管理計(jì)劃執(zhí)行各項(xiàng)管理任務(wù)，定期向CCB提交報(bào)告并列席CCB的例會(huì)。其具體職責(zé)為以下幾項(xiàng)：

(1)軟件配置管理工具的日常管理與維護(hù)。

(2)提交配置管理計(jì)劃。

(3)各配置項(xiàng)的管理與維護(hù)。

(4)執(zhí)行版本控制和變更控制方案。

(5)完成配置審計(jì)并提交報(bào)告。

(6)對(duì)開發(fā)人員進(jìn)行相關(guān)的培訓(xùn)。

(7)識(shí)別軟件開發(fā)過程中存在的問題并擬就解決方案。

4)系統(tǒng)集成員

系統(tǒng)集成員(SystemIntegrationOfficer，SIO)負(fù)責(zé)生成和管理項(xiàng)目的內(nèi)部和外部發(fā)布版本，其具體職責(zé)為以下幾項(xiàng)：

(1)集成修改。

(2)構(gòu)建系統(tǒng)。

(3)完成對(duì)版本的日常維護(hù)。

(4)建立外部發(fā)布版本。

5)開發(fā)人員

開發(fā)人員(Developer，DEV)的職責(zé)就是根據(jù)組織內(nèi)確定的軟件配置管理計(jì)劃和相關(guān)規(guī)定，按照軟件配置管理工具的使用模型來完成開發(fā)任務(wù)。10.3.3軟件配置管理過程描述

1．項(xiàng)目計(jì)劃階段

一個(gè)項(xiàng)目設(shè)立之初，PM首先需要制定整個(gè)項(xiàng)目的計(jì)劃，它是項(xiàng)目研發(fā)工作的基礎(chǔ)。在有了總體研發(fā)計(jì)劃之后，軟件配置管理的活動(dòng)就可以開展了。

在軟件配置管理計(jì)劃的制定過程中，它的主要流程如下：

(1)CCB根據(jù)項(xiàng)目的開發(fā)計(jì)劃確定各個(gè)里程碑和開發(fā)策略。

(2)CMO根據(jù)CCB的規(guī)劃，制定詳細(xì)的配置管理計(jì)劃，交CCB審核。

(3)CCB通過配置管理計(jì)劃后交項(xiàng)目經(jīng)理批準(zhǔn)，發(fā)布實(shí)施。

2．項(xiàng)目開發(fā)和維護(hù)階段

這一階段是項(xiàng)目研發(fā)的主要階段。在這一階段中，軟件配置管理活動(dòng)主要分為三個(gè)層面：

(1)主要由CMO完成的管理和維護(hù)工作。

(2)由SIO和DEV具體執(zhí)行軟件配置管理策略。

(3)變更流程。

這三個(gè)層面是彼此之間既獨(dú)立又互相聯(lián)系的有機(jī)的整體。在這個(gè)軟件配置管理過程中，它的核心流程應(yīng)該是這樣的：

(1)?CCB設(shè)定研發(fā)活動(dòng)的初始基線。

(2)?CMO根據(jù)軟件配置管理規(guī)劃設(shè)立配置庫和工作空間，為執(zhí)行軟件配置管理做好準(zhǔn)備。

(3)開發(fā)人員按照統(tǒng)一的軟件配置管理策略，根據(jù)獲得的授權(quán)的資源進(jìn)行項(xiàng)目的研發(fā)工作。

(4)?SIO按照項(xiàng)目的進(jìn)度集成組內(nèi)開發(fā)人員的工作成果，并構(gòu)建系統(tǒng)，推進(jìn)版本的演進(jìn)。

(5)?CCB根據(jù)項(xiàng)目的進(jìn)展情況，審核各種變更請(qǐng)求，并適時(shí)地劃定新的基線，保證開發(fā)和維護(hù)工作的有序進(jìn)行。

這個(gè)流程就是如此循環(huán)往復(fù)，直到項(xiàng)目的結(jié)束。當(dāng)然，在上述的核心過程之外，還涉及其它一些相關(guān)的活動(dòng)和操作流程，下面按不同的角色分工予以列出，如圖10.2所示。圖10.2軟件配置管理基本流程10.3.4軟件配置管理的關(guān)鍵活動(dòng)

1．配置項(xiàng)(SoftwareConfigurationItem，SCI)識(shí)別

Pressman對(duì)于SCI給出了一個(gè)比較簡單的定義：“軟件過程的輸出信息可以分為三個(gè)主要類別：①計(jì)算機(jī)程序(源代碼和可執(zhí)行程序)。②描述計(jì)算機(jī)程序的文檔(針對(duì)技術(shù)開發(fā)者和用戶)。③數(shù)據(jù)(包含在程序內(nèi)部或外部)。這些項(xiàng)包含了所有在軟件過程中產(chǎn)生的信息，總稱為軟件配置項(xiàng)?！避浖拈_發(fā)過程是一個(gè)不斷變化著的過程，為了在不嚴(yán)重阻礙合理變化的情況下控制變化，軟件配置管理引入了“基線(BaseLine)”這一概念。IEEE對(duì)基線的定義是這樣的：“已經(jīng)正式通過復(fù)審核批準(zhǔn)的某規(guī)約或產(chǎn)品，它因此可作為進(jìn)一步開發(fā)的基礎(chǔ)，并且只能通過正式的變化控制過程改變?！?/p>

軟件的開發(fā)流程中把所有需加以控制的配置項(xiàng)分為基線配置項(xiàng)和非基線配置項(xiàng)兩類。

2．工作空間管理

在引入了軟件配置管理工具(如CVS、VSS等)之后，所有開發(fā)人員都會(huì)被要求把工作成果存放到由軟件配置管理工具所管理的配置庫中，或是直接工作在軟件配置管理工具提供的環(huán)境之下。所以為了讓每個(gè)開發(fā)人員和各個(gè)開發(fā)團(tuán)隊(duì)能更好地分工合作，同時(shí)又互不干擾，對(duì)工作空間的管理和維護(hù)也成為了軟件配置管理的一個(gè)重要的活動(dòng)。

一般來說，比較理想的情況是把整個(gè)配置庫視為一個(gè)統(tǒng)一的工作空間，然后再根據(jù)需要把它劃分為個(gè)人(私有)、團(tuán)隊(duì)(集成)和全組(公共)這三類工作空間(分支)，從而更好地支持將來可能出現(xiàn)的并行開發(fā)的需求。每個(gè)開發(fā)人員按照任務(wù)的要求，在不同的開發(fā)階段，工作在不同的工作空間上。例如：對(duì)于私有開發(fā)空間而言，開發(fā)人員根據(jù)任務(wù)分工獲得對(duì)相應(yīng)配置項(xiàng)的操作許可之后，即在自己的私有開發(fā)分支上工作，其所有工作成果體現(xiàn)為在該配置項(xiàng)的私有分支上的版本的推進(jìn)，除該開發(fā)人員外，其他人員均無權(quán)操作該私有空間中的元素；而集成分支對(duì)應(yīng)的是開發(fā)團(tuán)隊(duì)的公共空間，該開發(fā)團(tuán)隊(duì)擁有對(duì)該集成分支的讀寫權(quán)限，其他成員只有只讀權(quán)限，它的管理工作由SIO負(fù)責(zé)；至于公共工作空間，則是用于統(tǒng)一存放各個(gè)開發(fā)團(tuán)隊(duì)的階段性工作成果，它提供全組統(tǒng)一的標(biāo)準(zhǔn)版本，并作為整個(gè)組織的知識(shí)庫。

3．版本控制

版本控制是軟件配置管理的核心功能。所有置于配置庫中的元素都應(yīng)自動(dòng)予以版本的標(biāo)識(shí)，并保證版本命名的唯一性。版本在生成過程中，自動(dòng)依照設(shè)定的使用模型自動(dòng)分支、演進(jìn)。除了系統(tǒng)自動(dòng)記錄的版本信息以外，為了配合軟件開發(fā)流程的各個(gè)階段，還需要定義、收集一些元數(shù)據(jù)來記錄版本的輔助信息和規(guī)范開發(fā)流程，并對(duì)軟件過程的度量做好

準(zhǔn)備。

4．變更控制

基線與變更控制緊密相連，在對(duì)各個(gè)SCI做出了識(shí)別，并且利用工具對(duì)它們進(jìn)行了版本管理之后，如何保證它們?cè)趶?fù)雜多變的開發(fā)過程中真正地處于受控的狀態(tài)，并在任何情況下都能迅速地恢復(fù)到任一歷史狀態(tài)就成為了軟件配置管理的另一重要任務(wù)。因此，變更控制就是通過結(jié)合人的規(guī)程和自動(dòng)化工具，以提供一個(gè)變化控制的機(jī)制。

變更控制的對(duì)象主要指配置庫中的各基線配置項(xiàng)，變更管理的一般流程如下：

(1)(獲得)提出變更請(qǐng)求。

(2)由CCB審核并決定是否批準(zhǔn)。

(3)(被接受)修改請(qǐng)求分配人員，提取SCI，進(jìn)行修改。

(4)復(fù)審變化。

(5)提交修改后的SCI。

(6)建立測試基線并測試。

(7)重建軟件的適當(dāng)版本。

(8)復(fù)審(審計(jì))所有SCI的變化。

(9)發(fā)布新版本。

5．配置狀態(tài)報(bào)告

配置狀態(tài)報(bào)告就是根據(jù)配置項(xiàng)操作數(shù)據(jù)庫中的記錄來向管理者報(bào)告軟件開發(fā)活動(dòng)的進(jìn)展情況。這樣的報(bào)告應(yīng)該是定期進(jìn)行，并盡量通過CASE工具自動(dòng)生成，用數(shù)據(jù)庫中的客觀數(shù)據(jù)來真實(shí)反映各配置項(xiàng)的情況。

配置狀態(tài)報(bào)告應(yīng)根據(jù)報(bào)告著重反映當(dāng)前基線配置項(xiàng)的狀態(tài)，以作為對(duì)開發(fā)進(jìn)度報(bào)告的參照。同時(shí)也能從中根據(jù)開發(fā)人員對(duì)配置項(xiàng)的操作記錄來對(duì)開發(fā)團(tuán)隊(duì)的工作關(guān)系作一定的分析。

6．配置審計(jì)

配置審計(jì)的主要作用是作為變更控制的補(bǔ)充手段，來確保某一變更需求已被切實(shí)實(shí)現(xiàn)。在某些情況下，它被作為正式的技術(shù)復(fù)審的一部分，但當(dāng)軟件配置管理是一個(gè)正式的活動(dòng)時(shí)，該活動(dòng)由SQA人員單獨(dú)執(zhí)行。

10.4缺陷管理

10.4.1缺陷跟蹤管理系統(tǒng)概述

缺陷跟蹤管理系統(tǒng)(DefectTrackingSystem)是用于集中管理軟件測試過程中發(fā)現(xiàn)的缺陷的數(shù)據(jù)庫程序，可以通過添加、修改、排序、查尋、存儲(chǔ)操作來管理軟件缺陷。

1)缺陷跟蹤管理系統(tǒng)的作用

(1)便于缺陷的查找和跟蹤。對(duì)于大中型軟件的測試過程而言，報(bào)告的缺陷總數(shù)可能多達(dá)成千上萬個(gè)，如果沒有缺陷跟蹤管理系統(tǒng)的支持，要求查找某個(gè)錯(cuò)誤，其難度和效率可想而知。

(2)便于協(xié)同工作。缺陷跟蹤管理系統(tǒng)可以作為測試人員、開發(fā)人員、項(xiàng)目負(fù)責(zé)人、缺陷評(píng)審人員協(xié)同工作的平臺(tái)。

(3)保證測試工作的有效性。避免測試人員重復(fù)報(bào)錯(cuò)，同時(shí)也便于及時(shí)掌握各缺陷的當(dāng)前狀態(tài)，進(jìn)而完成對(duì)應(yīng)狀態(tài)的測試工作。

(4)便于跟蹤和監(jiān)控錯(cuò)誤的處理過程和方法?？梢苑奖愕貦z查處理方法是否正確，跟蹤處理者的姓名和處理時(shí)間，作為工作量的統(tǒng)計(jì)和業(yè)績考核的參考。

2)缺陷跟蹤管理系統(tǒng)的實(shí)現(xiàn)原理

缺陷跟蹤管理系統(tǒng)在實(shí)現(xiàn)技術(shù)層面上看是一個(gè)數(shù)據(jù)庫應(yīng)用程序。它包括前臺(tái)用戶界面、后臺(tái)缺陷數(shù)據(jù)庫以及中間數(shù)據(jù)處理層。

這類系統(tǒng)的用戶界面所顯示的信息一般應(yīng)根據(jù)用戶的角色不同(測試人員、開發(fā)人員、項(xiàng)目負(fù)責(zé)人、缺陷評(píng)審員等)而略有差異，因?yàn)楦鱾€(gè)角色使用該系統(tǒng)完成的任務(wù)各不相同，如測試人員用于報(bào)告缺陷或確認(rèn)缺陷是否可以關(guān)閉，開發(fā)人員用于了解哪些缺陷需要他去處理以及缺陷經(jīng)過處理后是否被關(guān)閉，而項(xiàng)目負(fù)責(zé)人需要及時(shí)了解當(dāng)前有哪些新的缺陷，哪些必須及時(shí)修正等等。另外，不同角色所擁有的數(shù)據(jù)操作權(quán)限也不盡相同。例如開發(fā)人員無權(quán)通過其用戶界面往數(shù)據(jù)庫中填寫新的缺陷信息，也無權(quán)關(guān)閉某個(gè)已知缺陷；而測試人員無權(quán)決定分配誰去修正某個(gè)已知缺陷，無權(quán)決定是否要修正某個(gè)缺陷。10.4.2軟件缺陷內(nèi)容

軟件缺陷包括如下內(nèi)容：

(1)可追蹤信息。如給每個(gè)缺陷分配一個(gè)缺陷編號(hào)，則每個(gè)編號(hào)必須是唯一的，可以根據(jù)該編號(hào)搜索、查看該缺陷的處理情況。

(2)缺陷的基本信息。通常缺陷的基本信息包括缺陷狀態(tài)、缺陷標(biāo)題、缺陷嚴(yán)重程度、缺陷緊急程度、缺陷提交人、缺陷提交日期、缺陷所屬、缺陷解決人、缺陷解決時(shí)間、缺陷解決結(jié)果、缺陷處理人、缺陷處理最終時(shí)間、缺陷處理結(jié)果、缺陷確認(rèn)人、缺陷確認(rèn)時(shí)間、缺陷確認(rèn)結(jié)果等等。

(3)缺陷的詳細(xì)描述，即對(duì)缺陷的特征應(yīng)做詳細(xì)的描述。例如程序代碼中的錯(cuò)誤，應(yīng)詳細(xì)描述錯(cuò)誤發(fā)生的軟硬件環(huán)境、相關(guān)輸入輸出數(shù)據(jù)、出錯(cuò)時(shí)程序的狀態(tài)等等，以方便編碼人員進(jìn)行錯(cuò)誤復(fù)現(xiàn)和錯(cuò)誤定位。又如設(shè)計(jì)規(guī)格說明中的錯(cuò)誤，應(yīng)指明它與高層軟件開發(fā)文檔(如需求規(guī)格說明)中哪些條款相違背，為什么判為違背，都需要描述清楚，以方便設(shè)計(jì)人員進(jìn)一步核實(shí)。

(4)必要的附件。有時(shí)，某些缺陷可能無法用語言文字表達(dá)清楚，如用戶界面出現(xiàn)的一些缺陷，光用語言文字難以表述清楚。這時(shí)，就需要借助于屏幕拷貝等方式來進(jìn)一步描述缺陷。10.4.3軟件跟蹤缺陷處理的一般流程

軟件跟蹤管理確保每個(gè)被發(fā)現(xiàn)的缺陷都能被解決。解決可能是指缺陷被修正，也可能是指項(xiàng)目組成員達(dá)成一致的處理意見(如不作處理)。

軟件跟蹤缺陷處理的流程如圖10.3所示。圖10.3缺陷處理流程

10.5風(fēng)險(xiǎn)管理

10.5.1風(fēng)險(xiǎn)管理概述

近幾年來軟件開發(fā)技術(shù)、工具都有了很大的進(jìn)步，但是軟件項(xiàng)目開發(fā)超時(shí)、超支，甚至不能滿足用戶需求而根本沒有得到實(shí)際使用的情況仍然比比皆是。軟件項(xiàng)目開發(fā)和管理中一直存在著種種不確定性，嚴(yán)重影響著項(xiàng)目的順利完成和提交。但這些軟件風(fēng)險(xiǎn)并未得到充分的重視和系統(tǒng)的研究。直到20世紀(jì)80年代，Boehm比較詳細(xì)地對(duì)軟件開發(fā)中的風(fēng)險(xiǎn)進(jìn)行了論述,并提出軟件風(fēng)險(xiǎn)管理的方法。Boehm認(rèn)為,軟件風(fēng)險(xiǎn)管理指的是“試圖以一種可行的原則和實(shí)踐，規(guī)范化地控制影響項(xiàng)目成功的風(fēng)險(xiǎn)”，其目的是“辨識(shí)、描述和消除風(fēng)險(xiǎn)因素，以免它們威脅軟件的成功運(yùn)作”。10.5.2軟件項(xiàng)目風(fēng)險(xiǎn)管理

風(fēng)險(xiǎn)管理涉及的主要過程包括風(fēng)險(xiǎn)識(shí)別、風(fēng)險(xiǎn)量化、風(fēng)險(xiǎn)應(yīng)對(duì)計(jì)劃制定和風(fēng)險(xiǎn)監(jiān)控，如圖10.4所示。風(fēng)險(xiǎn)識(shí)別在項(xiàng)目的開始時(shí)就要進(jìn)行，并在項(xiàng)目執(zhí)行中不斷進(jìn)行。就是說，在項(xiàng)目的整個(gè)生命周期內(nèi)，風(fēng)險(xiǎn)識(shí)別是一個(gè)連續(xù)的過程。圖10.4風(fēng)險(xiǎn)管理過程10.5.3軟件項(xiàng)目中的風(fēng)險(xiǎn)

軟件項(xiàng)目的風(fēng)險(xiǎn)無非體現(xiàn)在以下四個(gè)方面：需求、技術(shù)、成本和進(jìn)度。IT項(xiàng)目開發(fā)中常見的風(fēng)險(xiǎn)有如下幾類：

1)需求風(fēng)險(xiǎn)

(1)需求已經(jīng)成為項(xiàng)目基準(zhǔn)，但需求還在繼續(xù)變化；

(2)需求定義欠佳，而進(jìn)一步的定義會(huì)擴(kuò)展項(xiàng)目范疇；

(3)添加額外的需求；

(4)產(chǎn)品定義含混的部分比預(yù)期需要更多的時(shí)間；

(5)在做需求時(shí)客戶參與不夠；

(6)缺少有效的需求變化管理過程。

2)計(jì)劃編制風(fēng)險(xiǎn)

(1)計(jì)劃、資源和產(chǎn)品定義全憑客戶或上層領(lǐng)導(dǎo)口頭指令，并且不完全一致；

(2)計(jì)劃是優(yōu)化的，是“最佳狀態(tài)”，但計(jì)劃不現(xiàn)實(shí)，只能算是“期望狀態(tài)”；

(3)計(jì)劃基于使用特定的小組成員，而那個(gè)特定的小組成員其實(shí)指望不上；

(4)產(chǎn)品規(guī)模(代碼行數(shù)、功能點(diǎn)、與前一產(chǎn)品規(guī)模的百分比)比估計(jì)的要大；

(5)完成目標(biāo)日期提前，但沒有相應(yīng)地調(diào)整產(chǎn)品范圍或可用資源；

(6)涉足不熟悉的產(chǎn)品領(lǐng)域，花費(fèi)在設(shè)計(jì)和實(shí)現(xiàn)上的時(shí)間比預(yù)期的要多。

3)組織和管理風(fēng)險(xiǎn)

(1)僅由管理層或市場人員進(jìn)行技術(shù)決策，導(dǎo)致計(jì)劃進(jìn)度緩慢，計(jì)劃時(shí)間延長；

(2)低效的項(xiàng)目組結(jié)構(gòu)降低生產(chǎn)率；

(3)管理層審查決策的周期比預(yù)期的時(shí)間長；

(4)預(yù)算削減，打亂項(xiàng)目計(jì)劃；

(5)管理層作出了打擊項(xiàng)目組積極性的決定；

(6)缺乏必要的規(guī)范，導(dǎo)致工作失誤與重復(fù)工作；

(7)非技術(shù)的第三方的工作(預(yù)算批準(zhǔn)、設(shè)備采購批準(zhǔn)、法律方面的審查、安全保證等)時(shí)間比預(yù)期的延長。

4)人員風(fēng)險(xiǎn)

(1)作為先決條件的任務(wù)(如培訓(xùn)及其它項(xiàng)目)不能按時(shí)完成；

(2)開發(fā)人員和管理層之間關(guān)系不佳，導(dǎo)致決策緩慢，影響全局；

(3)缺乏激勵(lì)措施，士氣低下，降低了生產(chǎn)能力；

(4)某些人員需要更多的時(shí)間適應(yīng)還不熟悉的軟件工具和環(huán)境；

(5)項(xiàng)目后期加入新的開發(fā)人員，需進(jìn)行培訓(xùn)并逐漸與現(xiàn)有成員溝通，從而使現(xiàn)有成員的工作效率降低；

(6)由于項(xiàng)目組成員之間發(fā)生沖突，導(dǎo)致溝通不暢、設(shè)計(jì)欠佳、接口出現(xiàn)錯(cuò)誤和額外的重復(fù)工作；

(7)不適應(yīng)工作的成員沒有調(diào)離項(xiàng)目組，影響了項(xiàng)目組其他成員的積極性；

(8)沒有找到項(xiàng)目急需的具有特定技能的人。

5)開發(fā)環(huán)境風(fēng)險(xiǎn)

(1)設(shè)施未及時(shí)到位；

(2)設(shè)施雖到位，但不配套，如沒有電話、網(wǎng)線、辦公用品等；

(3)設(shè)施擁擠、雜亂或者破損；

(4)開發(fā)工具未及時(shí)到位；

(5)開發(fā)工具不如期望的那樣有效，開發(fā)人員需要時(shí)間創(chuàng)建工作環(huán)境或者切換新的工具；

(6)新的開發(fā)工具的學(xué)習(xí)期比預(yù)期的長，內(nèi)容繁多。

6)客戶風(fēng)險(xiǎn)

(1)客戶對(duì)于最后交付的產(chǎn)品不滿意，要求重新設(shè)計(jì)和重做；

(2)客戶的意見未被采納，造成產(chǎn)品最終無法滿足用戶要求必須重做；

(3)客戶對(duì)規(guī)劃、原型和規(guī)格的審核決策周期比預(yù)期的要長；

(4)客戶沒有或不能參與規(guī)劃、原型和規(guī)格階段的審核，導(dǎo)致需求不穩(wěn)定和產(chǎn)品生產(chǎn)周期的變更；

(5)客戶答復(fù)的時(shí)間(如回答或澄清與需求相關(guān)問題的時(shí)間)比預(yù)期長；

(6)客戶提供的組件質(zhì)量欠佳，導(dǎo)致額外的測試、設(shè)計(jì)和集成工作，以及額外的客戶關(guān)系管理工作。

7)產(chǎn)品風(fēng)險(xiǎn)

(1)矯正質(zhì)量低下的不可接受的產(chǎn)品，需要比預(yù)期更多的測試、設(shè)計(jì)和實(shí)現(xiàn)工作；

(2)開發(fā)額外的不需要的功能，延長了計(jì)劃進(jìn)度；

(3)嚴(yán)格要求與現(xiàn)有系統(tǒng)兼容，需要進(jìn)行比預(yù)期更多的測試、設(shè)計(jì)和實(shí)現(xiàn)工作；

(4)要求與其它系統(tǒng)或不受本項(xiàng)目組控制的系統(tǒng)相連，導(dǎo)致無法預(yù)料的設(shè)計(jì)、實(shí)現(xiàn)和測試工作；

(5)在不熟悉或未經(jīng)檢驗(yàn)的軟件和硬件環(huán)境中運(yùn)行所產(chǎn)生的未預(yù)料到的問題；

(6)開發(fā)一種全新的模塊將比預(yù)期花費(fèi)更長的時(shí)間；

(7)依賴正在開發(fā)中的技術(shù)將延長計(jì)劃進(jìn)度。

8)設(shè)計(jì)和實(shí)現(xiàn)風(fēng)險(xiǎn)

(1)設(shè)計(jì)質(zhì)量低下，導(dǎo)致重復(fù)設(shè)計(jì)；

(2)一些必要的功能無法使用現(xiàn)有的代碼和庫實(shí)現(xiàn)，開發(fā)人員必須使用新的庫或者自行開發(fā)新的功能；

(3)代碼和庫質(zhì)量低下，導(dǎo)致需要進(jìn)行額外的測試，修正錯(cuò)誤或重新制作；

(4)過高估計(jì)了增強(qiáng)型工具對(duì)計(jì)劃進(jìn)度的節(jié)省量；

(5)分別開發(fā)的模塊無法有效集成，需要重新設(shè)計(jì)或制作。

9)過程風(fēng)險(xiǎn)

(1)大量的紙面工作導(dǎo)致進(jìn)程比預(yù)期的慢；

(2)前期的質(zhì)量保證行為不真實(shí)，導(dǎo)致后期的重復(fù)工作；

(3)太不正規(guī)(缺乏對(duì)軟件開發(fā)策略和標(biāo)準(zhǔn)的遵循)，導(dǎo)致溝通不足，質(zhì)量欠佳，甚至需要重新開發(fā)；

(4)過于正規(guī)(教條地堅(jiān)持軟件開發(fā)策略和標(biāo)準(zhǔn))，導(dǎo)致過多耗時(shí)于無用的工作；

(5)向管理層撰寫進(jìn)程報(bào)告占用開發(fā)人員的時(shí)間比預(yù)期的多；

(6)風(fēng)險(xiǎn)管理粗心，導(dǎo)致未能發(fā)現(xiàn)重