第4章　軟件測試過程與管理

4．1　軟件測試過程

一、簡介

開發過程的質量決定了軟件的質量，測試過程的質量決定了軟件測試的質量和有效性。軟件測試過程的管理是保證測試過程質量、控制測試風險的重要活動。軟件測試遵循軟件工程的原理，有自己的生命周期。軟件測試的過程管理是測試成功的重要保證。

二、說明

（1）軟件的測試過程通常分為測試計劃、測試設計與開發、測試實施、測試評審與測試結論等階段。對各階段的任務、輸入和輸出都有明確的規定，有利于對整個測試過程進行質量控制和配置管理。

（2）軟件測試過程是一種遵循GB/T18905（ISO14598.5）中定義軟件評價過程的抽象的模型，是國際上共同遵守的軟件評測過程標準，是軟件測試過程管理的精髓。標準定義分析各類軟件產品的評測需求，規定、設計、實施、評審以及對評測做出結論所需的各種活動。

4．2　評價過程的特性

一、可重復性

由同一評價者按同一評價規格說明對同一產品進行重復地評價，應產生同一種可接受的結果。

二、可再現性

由不同評價者按同一評價規格說明對同一產品進行評價，應產生同一種可接受的結果。

三、公正性

評價應不偏向任何特殊的結果。

四、客觀性

評價結果應是客觀事實，即不帶有評價者的感情色彩或主觀意見。

4．3　評價過程

一、評價活動

評價過程由五個活動組成：

1．確立軟件評價需求

2．編制評價規格說明

根據請求者提供的評價需求和產品描述編制。

3．制定評價計劃

在評價規格說明的基礎上設計評價，需考慮要測軟件的部件和評價者建議的評價方法。

4．評價執行計劃

（1）按照評價計劃對產品及其部件進行檢查、建模、測量和評價；

（2）可以用軟件工具（通常由評價者提供）來實施；

（3）記錄評價者的執行動作，所得的結果被記入評價報告草案。

5．作評價結論

交付評價報告和評價者對評價產品所做的處理。

二、評價過程的輸入

請求者提供其需求，并作為評價需求的最初版本。

1．請求者提供的評價過程的輸入

（1）軟件的說明書；

（2）軟件的部件。

軟件的說明書標識的軟件產品以及供評價的部件。

2．評價者提供的評價過程的輸入

（1）預先確定的評價規格說明；

（2）評價方法；

（3）評價工具。

三、評價過程的輸出

在評價期間，評價者提供下列輸出產品：

1．評價記錄

評價記錄包括評價計劃和評價動作的記錄。

2．評價報告草案

評價報告草案包括評價需求，評價規格說明和綜合的評價結果。

3．經過評審的評價報告

四、評價過程文檔

評價需求、評價規格說明和評價計劃是評價過程的中間產品。評價記錄和評價報告是評價過程的最終產品。

1．評價需求

描述評價的目標，特別是描述了產品的質量需求。

2．評價規格說明

確定對軟件及其部件實行的所有分析和測量，標識要分析和測量的軟件部件。

3．評價計劃

描述評價規格，說明需實施的操作規程；描述評價需用到的方法和工具。

4．評價記錄

評價執行計劃時詳細記載的動作組成；記錄由評價者保留。

5．評價報告

執行測量和分析的結果，以及能被重復和重新評價的必要信息。評價報告首先作為評審草案來發布，其最終版本將交給請求者。

如圖4-1所示，圖中給出了軟件測試過程的概述，標識了各活動之間的信息流。

圖4-1　軟件測試過程

4．4　評價與生存周期的關系

評價軟件產品可以在任何軟件生存周期過程的范圍內進行。特別是，評價能在軟件獲取、供應、開發、運行或維護過程中進行。在軟件開發過程中可盡早決定是否執行軟件產品的評價，以保證軟件最大可能地滿足有關評價結果的需求，從而降低額外風險和未預料的成本。

當請求者也是軟件的開發者時，應及早與評價者聯系，討論提交一個產品用于評價，有助于開發者預見評價者可能提出的任何特殊的要求。可能有某些（或全部）評價動作必須在現場實施，為保證結果公正，這些動作仍受評價者的控制。對于大而復雜的軟件項目，在整個產品的開發期間，開發者與評價者應不斷密切合作，以減少評價過程的成本和時間。但這種合作應不降低評價者的公正性。

4．5　評價過程的要求

一、一般要求

1．組織和質量體系

為滿足評價結果的可重復性、可再現性、公正性及客觀性，評價者應立足于一個組織。該組織為使其活動達到充分的質量要求提供所有必要保證。為滿足該需求，評價組織可按照ISO/IEC17025中規定的要求建立質量管理體系。

2．評價請求者的職責

（1）為進行評價，對軟件產品確立必要的合法權利；

（2）為標識和描述產品提供必要的信息；

（3）闡述最初的評價需求，并與評價者協商，確定實際的評價需求，這些評價需求宜遵守相關的法規和標準；

（4）闡述對評價提交的信息的保密性需求；

（5）必要時在開發者和評價者之間起中介作用；

（6）必要時向評價者提供對用于開發和操作使用軟件產品的計算機和其他設備；

（7）必要時對評價者提供必要的支持，包括培訓和走訪；

（8）必要時確保及時提供軟件、產品說明書和部件，包括文檔及其他資料；

（9）必要時告知評價者可能導致評價結果無效的原因。

3．評價者的職責

（1）檢查請求者對要評價執行的軟件產品是否有充分合法的權利；

（2）按規定對請求者提供信息保密承諾，包括評價的軟件、評價記錄和評價報告；

（3）提供有資格的和經過培訓的人員，以便實施評價；

（4）提供評價工具和技術；

（5）按照評價需求實施測試；

（6）保留評價期間影響評價結果的所有工作記錄；

（7）保證及時向請求者提交評價報告。

二、評價需求確立

1．評價需求確立的目的

評價需求確立的目的是描述評價目標。這些目標關系到軟件產品的預期用途和相關風險。可能要從幾種不同軟件用戶角度，如從軟件的需方、供方、開發者、操作者或維護者等出發。

2．評價需求分析

（1）組成

分析評價需求的活動由以下5個子活動組成：

①請求者提出評價需求建議；

②請求者說明評價覆蓋范圍；

③評價者分析評價原因和描述評價需求來響應請求者；

④評價者解釋評價的保密范圍和嚴格程度；

⑤評價者同意評價需求。

（2）需要考慮的問題

進行評價需求分析時，要考慮供評價的產品的應用領域和用途，還須考慮一些關鍵問題。在請求者的需求中，請求者應表明評價覆蓋范圍。同時評價者應保證評價非常嚴格的，足以提供軟件產品質量方面的真實證據。故請求者與評價者應對評價需求達成一致，作為繼續評價過程的前提條件。

3．評價需求內容

（1）評價需求應包含對評價產品應用領域的描述，以及產品用途的描述；

（2）評價需求應由GB/T16260中定義為“質量特性”的一系列質量需求組成，還可能用到一些子特性；

（3）評價需求中的每項需求，都應提供要評價軟件及部件的規格說明信息。

4．認可與報告

（1）評價需求應作為請求者與評價者聯合評審的結果而予以承認；

（2）評價需求應包括在評價報告和評價記錄中。

三、評價規格說明

1．評價規格說明的目的

定義評價范圍和供評價產品及各種部件執行的測量。評價規格說明應詳細到以此能確保評價的可重復性和可再現性。

2．評價規格說明編制

（1）組成

編制評價規格說明的活動由以下3個子活動組成：

①分析產品的描述；

②規定對產品及部件執行的測量；

③按照評價需求驗證編制的規格說明。

（2）產品說明分析

①提交產品說明的目的

a．以此定義評價的范圍，即標識出哪些作為軟件一部分的部件，以便了解接觸軟件的情況；

b．將供評價的產品部件的標識交給評價者，以便評價者了解其結構，并弄清提供的信息及如何訪問產品部件。

②產品說明資料應給清單中的部件、文檔提供的信息

產品說明資料應包含為評價而實際提交的產品部件清單、有關產品結構的基本原理和與產品有關的文檔清單。對列在清單中的每個部件和與產品有關的文檔，應提供如下信息：

a．部件性質的描述；

b．部件中用到的形式化信息；

c．有關部件規模的信息；

d．與其他部件的關系；

e．對評價者有用的產品部件信息。

評價者應檢查產品描述是否與上述提及的需求一致，并分析提供的原理及部件的說明，以便標識在評價需求中確定的各部件間的關系。

（3）測量規定

評價者應把評價需求分配給產品本身和產品描述中標識的各種部件，使評價需求被分解為數個子特性。對所供測試的不同部件，分解結果不同。然后，測試者應規定對產品和所選部件的特性、子特性及屬性進行評估的測量標準。測試規格說明書應明確對以下幾項進行說明：

①用于度量軟件或一組標識的部件的形式化的規格說明，以及評價報告中測量結果的表現形式的說明；

②引用的產品部件中規定將要驗證的軟件需求，以及引用驗證這些需求的規程的說明；

③在軟件需求文檔中被遺漏的，或需要更詳細解釋的軟件產品的需求規格說明，以及用來驗證這一需求的規程的說明。

對上述這些聲明，應引用要測量或驗證的部件的性質和所用的形式。

（4）評價規格說明驗證

①評價者應按照評價需求來驗證評價規格說明；

②評價者應按照評價需求檢查列在產品描述中的部件是否提供了評價執行的所有必要信息；

③評價者還應驗證規定的測量和驗證是否充分滿足評價需求所表示的評價目標。

3．評價規格說明的內容

（1）評價范圍，涉及在產品說明中標識的產品部件；

（2）評價執行所需的信息，在產品說明中列出的軟件部件及其他相關文檔之間的相互引用；

（3）要執行的測量和驗證的規格說明，以及對要評價的產品部件的引用；

（4）測量和驗證的規格說明與評價需求之間，與引用標準或所列的每個測量或驗證的理由之間的映射。

4．認可和報告

（1）評價規格說明應作為請求者和測試者之間聯合評審的結果而予以認可；

（2）評價規格說明應包含在評價報告和評價記錄中，對評價需求的任何修改均應在評價記錄中予以報告。

四、評價設計

1．評價設計目的

評價設計應把評價者使用的測量規程編成文檔，以便評價執行規格說明中規定的測量。評價者應制定評價計劃來描述執行指定的評價時所需的資源和執行各種動作時對這些資源的分配。評價計劃應詳細到能確保用令人滿意的方式執行這些動作。

2．制定評價計劃

（1）組成

制定評價計劃的活動由以下3個子活動組成：

①把評價方法編成文檔，起草計劃；

②優化評價計劃；

③根據可用資源安排評價動作的進度。

（2）編制評價方法文檔和起草計劃

①概述

把規定的測量或驗證與要評價的各種產品部件的形式組合起來，以便把對部件實施的測量或驗證的詳細方法編成文檔。評價者應分析評價規格說明中規定的有關測量或驗證的技術約束條件。這些約束條件可能包括以下內容：

a．軟件部件所用的形式；

b．軟件部件說明的電子或書面形式；

c．預定義評價方法；

d．支持評價技術的工具的可用性；

e．軟件部件的規模。

②注意事項

評價規格說明中規定的每種測量或驗證，評價者都應把有關的評價方法編成文檔。當描述的評價方法是基于使用軟件工具的時候，應在評價計劃中標識該工具。該標識應至少包括工具的名稱、版本標識和其來源（如：供方）。對評價的產品執行程序時，也應說明運行環境以及實際工作中可用的條款。

（3）測量的優化

每個基本評價方法都計劃應用在供評價的各個軟件部件上，也會出現將不同的基本評價方法用于同一軟件部件的情況。應對評價計劃草案進行評審，以避免評價者的重復勞動，減少錯誤風險和降低計劃的評價者的工作量。

（4）安排評價動作的進度

安排評價動作的進度的注意事項：

①評價者安排計劃動作進度，應考慮人員、軟件工具、計算機等資源的可用性；

②應就軟件及部件的交付進度與請求者達成一致；

③應規定軟件部件的交付介質、形式以及拷貝數量；

④應標識評價過程中滿足的需求；

⑤當請求者不是軟件產品的開發者時，應標識評價者和開發者之間的關系；

⑥應規定開發者需要的支持（包括培訓、非正式的討論或辦公場所等）；

⑦必要時，應對開發和運行場所的訪問與所需資源一起規定。

（5）評價計劃的內容

評價計劃應由兩部分組成：評價方法文檔和評價者采取評價動作的時間表。評價計劃中某些評價方法的文檔可能包括對評價者個人材料的引用。在該情況下，評價者應能判斷該方法與相應評價規格說明元素的針對性，以及在應用該方法時，其自身的能力。

3．認可和報告

（1）評價計劃應作為請求者和評價者之間聯合評審的結果而予以認可。

（2）評價計劃應包含在評價記錄中。評價方法的文檔，對方法的引用，以及對要應用該評價方法的產品部件的標識都應在評價報告中體現。

五、評價執行

1．評價執行目的

評價執行目的是根據評價需求，按照評價規格說明中的規定和評價計劃，從對軟件產品的測量和驗證中獲得結果，執行這些動作并完成評價報告和評價記錄的草稿。

2．評價執行者的動作

（1）對評價執行者的要求

為了執行計劃的評價，評價者應做到以下幾點：

①管理請求者提供的產品部件；

②管理評價動作所產生的數據（包括報告和記錄）；

③管理評價執行動作的工具；

④管理在評價者的承諾之外執行的評價動作；

⑤管理使用特定評價技術所隱含的要求。

（2）內容

①軟件部件的管理

評價請求者應根據評價計劃中定義的進度向評價者交付軟件部件和與軟件相關的文檔。

評價者應登記全部軟件部件和軟件的相關文檔。在證實軟件的規模和復雜程度之后，應使用正式的配置管理。

軟件樣品登記的信息應至少包括：

a．部件或文檔的唯一標識符；

b．部件的名稱或文檔標題；

c．文檔的狀態（包括物理狀態或變異狀態）；

d．請求者提供樣品的版本、配置和日期信息；

e．接收的日期。

除非請求者有另外的許可，否則，評價者將保守全部產品部件和相關文檔的秘密。

②評價數據管理

評價執行動作通常是測量產品和其部件，獲得并解釋中間數據，將產生的結果記入測試報告。

中間數據的種類多種多樣。對中間數據的保密應與原來對部件和文檔的保密方法一樣。評價者應盡力防止這些數據被意外或惡意地修改。評價者應把所有中間數據記入評價記錄，以便依據它們進行解釋。同時，在解釋過程中所作的決定也應被記入評價記錄。

③工具使用的管理

評價執行動作需要使用工具軟件來收集原始數據，或解釋中間數據。

a．使用工具來評價執行動作時，應在評價報告中記錄對工具的引用。該引用應由工具的標識、供方和版本信息組成。

b．對所用工具的更詳細的引用信息應記錄在評價記錄中，包括工具配置的詳細信息和為得到相同的中間結果而重復評價動作所需的任何相關信息。

c．評價者應盡最大努力保證工具按照所期望的方式進行工作，保留在評價過程中承諾合法使用工具的記錄。

④現場評價

有時，不能在評價者假定的場所評價執行動作。這時，評價者應控制所有執行的評價動作，特別是應避免任何使評價結果無效的情況發生。評價者應盡最大努力保證評價結果和中間結果的保密性。

⑤特定評價技術的需求

當評價計劃要求評價產品的可執行程序時，應精確記錄評價的配置和評價的環境。當評價動作要求檢查文檔時，建議使用檢查表。

⑥評審和報告

在評價執行過程中會產生中間評價結果和最終評價結果。為達到最大的客觀性，每個評價動作應由不同的評價執行動作的評價者來檢查。應評審全部評價結果，其目的取決于所考慮的評價動作的實質。應至少有一個不直接涉及評價動作的人員參加評審。評審報告應包括在評價記錄中。一旦評審通過，應按評價規格說明中的規定，把評價結果記入到評價報告中。此外，當評價計劃也是這樣規定時，某些中間結果或解釋決定也應記入評價報告。

六、評價結論

1．評價結論的目的

評論結論的目的包括評價報告的評審和評價數據的處理。

2．評價報告的聯合評審

評價報告的草稿應交付給評價的請求者。應組織評價者和請求者之間的聯合評審。請求者應有機會對評價報告提出意見。之后，應把該評價報告交給請求者。

3．評價數據和文檔的處置

將評價報告正式交付給請求者之后，評價者應處理與評價有關的數據。可以根據數據的類型使用以下方法進行：

（1）供評價的文檔應歸還給請求者，或存檔一個規定的期限，或者以安全的方式銷毀。

（2）評價報告和評價記錄應存檔到一個規定的期限。

（3）所有其他數據應存檔一個規定的期限或以安全的方式銷毀。

當某些數據的規定存檔期限到期時，應將其再次保存一個規定的期限或以安全的方式銷毀。只要請求者明確表示同意，評價者就可以使用中間評價結果，以便研究評價技術和軟件的度量。

4．6　配置管理

一、概述

通常，軟件測試配置管理包括以下4個最基本的活動：

（1）配置項標識；

（2）配置項控制（變更控制）；

（3）配置狀態報告；

（4）配置審計。

二、配置項標識

（1）標識測試樣品、標準、工具、文檔（包括測試用例）、報告等配置項的名稱和類型；

（2）指出何時基準化配置項（置于基線控制之下）；

（3）標識各配置項的所有者及儲存位置。

三、配置項控制

1．規定測試基線

對每個基線必須描述以下內容：

（1）每個基線的項（包括文檔、樣品和工具）；

（2）與每個基線有關的評審、批準事項以及驗收標準。規定何時何人創立新的基線，如何創立。

2．確定變更控制委員會的人員組成、職能（包括變更授權、確認與批準）、工作程序

3．確定變更請求的處理程序和終止條件

4．確定變更請求的處理過程中各測試人員執行變更的職能和變更請求和所產生結果的對應機制

5．確定配置項提取和存入的控制機制與方式

四、配置狀態報告

（1）定義配置狀態報告形式、內容和提交方式；

（2）確認過程記錄和跟蹤問題報告，更改請求，更改次序等；

（3）確定測試報告提交的時間與方式。

五、配置審計

（1）確定審計執行人員和執行時機。

（2）確定審計的內容與方式。

（3）確定發現問題的處理方法。

配置管理是管理和調整變更的關鍵（如圖4-2所示），對一參與人員較多、變更較大的項目，其至關重要。軟件測試配置管理概念的實際操作十分復雜。其用于測試工具、用例，且對于測試過程中的所有文檔非常重要，也可用于測試樣本和數據。

圖4-2　配置管理原理圖

4．7　測試的組織與人員

一、概念

組織是指一個系統將材料、知識和方法組合起來，把各種不同的輸入轉換成有價值的輸出。組織結構是指用一定的模式對責任、權威和關系進行安排，直至通過這種結構發揮功能。

二、組織結構設計因素

測試組織結構的設計因素包括如下六個方面：

1．垂直還是平緩

垂直的組織結構是在首席管理者與低級測試人員之間設立了許多層次，平緩的垂直組織結構設立很少的幾個層次。平緩的組織結構的測試工作效率較高。

2．市場還是產品

組織結構的設置可以是面向不同的市場或不同的產品。

3．集中還是分散

組織可以是集中的，也可以是分散的。這對于測試組織是比較關鍵的，為保證測試的獨立性，一般測試組織要相對集中。

4．分級還是分散

可將組織按權力和級別一層層分級，也可分散排列開。在軟件開發小組內的測試常使用分散方式，測試小組在開發小組內，可以是專職測試人員，或者以測試角色的形式組成。

5．專業人員還是工作人員

測試組織應擁有一定比例的專業測試人員和工作人員。

6．功能還是項目

測試組織可以面向功能或項目。

三、獨立測試組織

測試組織是一種或一系列的資源，專門從事測試活動。只有不持偏見的人才能提供不持偏見的度量，測試度量軟件質量才真正有效，測試必須獨立進行。Bill Hetzel在《軟件測試指南大全》中指出獨立的測試組織的重要性，原因如下：

（1）沒有這樣的一個組織，建立系統就不會理想；

（2）有效的度量對于產品質量控制是十分重要的；

（2）測試協調需要全職、專門的人員投入。

四、測試組織管理者

測試管理是很困難的，測試組織的管理者必須具備以下能力：

（1）理解與評價軟件測試政策、標準、過程、工具、培訓和度量的能力；

（2）領導一個測試組織的能力，該組織必須堅強有力、獨立自主、辦事規范沒有偏見；

（3）吸引并留住杰出測試專業人才的能力；

（4）領導、溝通、支持和控制的能力；

（5）測試時間、質量和成本控制的能力。

五、集中管理的測試組織

結合組織的基本設計因素，可以構成許多不同的測試組織結構。在軟件企業中，與獨立測試有關的集中管理的一種測試組織形式，如圖4-3所示。

圖4-3　集中管理的測試組織

該方式的優點為，軟件立項后，由獨立的測試組織提供資源與軟件開發人員并肩作戰，與合作伙伴一塊行動，可減少軟件開發人員與測試人員合作時的不利因素。

六、選擇合理的組織方案

組織設計因素可以組成不同的組織方案，在實際中軟件開發機構和測試機構也都建立了不同結構的測試組織形式。選擇合理高效的測試組織結構方案的準則如下：

（1）提供軟件測試的快速決策能力；

（2）利于合作，尤其是產品開發與測試開發之間的合作；

（3）能夠獨立、規范、不帶偏見地運作并具有精干的人員配置；

（4）有利于協調測試與質量管理的關系；

（5）有利于滿足軟件測試過程管理要求；

（6）有利于為測試技術提供專有技術；

（7）充分利用現有測試資源，特別是人；

（8）對測試者的職業道德和事業產生積極的影響。

七、測試人員

1．測試人員的選擇

測試人員的能力包括以下幾項：

（1）一般能力

一般能力包括表達、交流、協調、管理、質量意識、過程方法、軟件工程等。

（2）測試技能及方法

測試技能及方法包括測試基本概念及方法、測試工具及環境、專業測試標準、工作成績評估等。

（3）測試規劃能力

測試規劃能力包括風險分析及防范、軟件放行/接收準則制定、測試目標及計劃、測試計劃和設計的評審方法等。

（4）測試執行能力

測試執行能力包括測試數據/腳本/用例、測試比較及分析、缺陷記錄及處理、自動化工具。

（5）測試分析、報告和改進能力

測試分析、報告和改進能力包括測試度量、統計技術、測試報告、過程監測及持續改進。

2．測試人員的激勵

（1）X理論＋Y理論

①X理論：胡蘿卜＋大棒——迫使人們工作。

②Y理論：經理的職能不是督促人們工作，而是使人們有可能工作。

（2）需要的層次（Maslow模型）

①生存需要——工作職位、工資獎金、休息時間；

②安全需要——公正待遇、應付工作的能力和信心；

③社會需要——團隊歸屬感，互相認同、理解和支持；

④自尊需要——具有受人尊重/賞識的能力或/和業績；

⑤自我實現需要——成為自己期望的人物。

（3）人員激勵的關鍵點

①管理者習慣用對自己有效的因素激勵測試人員，很可能發現無效；

②過多使用權力、資金或處罰手段很可能導致項目失敗；

③行業領先企業采取卓有成效的非貨幣形式的激勵措施；

④在項目進行過程中，而不僅是在項目結束時實施激勵措施；

⑤對人員的工作表現出真誠的興趣是對其最好的獎勵；

⑥獎勵應該在工作獲得認同后盡快兌現；

⑦激勵因素是因人而異、因時而異的。

已經滿足的需要很可能不再成為激勵因素。

（4）人員自我激勵

測試工作的快樂哲學：選擇積極的態度，把工作當作游戲，讓別人快樂，全身心投入工作。

注意測試工作的7條效率原則：主動思考，積極行動；一開始就牢記目標，不迷失方向；重要的事情放在首位（但常常把緊急的事情放在首位）：先理解人，后被人理解；尋求雙贏；互相合作，追求1＋1＞2；終生學習，自我更新，不斷進步。

3．測試職業發展

國際推薦的軟件測試職業發展計劃如下：

（1）1～2年，測試技能

①熟悉整個測試過程及產品業務領域，學習和掌握自動測試工具，學習測試自動化編程技術；

②開發和執行測試腳本，承擔系統測試實施任務；

③掌握編程語言、操作系統、網絡與數據庫方面的技能。

（2）3～4年，測試過程

①深入了解測試過程，掌握測試過程設計及改進，參與軟件工作產品的同行評審；

②進一步了解產品業務領域，改進測試自動化編程技術；

③能指導初級測試工程師；

④加強編程語言、操作系統、網絡與數據庫方面的技能。

（3）4～5年，測試組織工作

①管理1～3名測試工程師，擔任任務估算、管理及進度控制；

②進一步培養在軟件項目管理及支持工具方面的技能。

（4）5～6年，技術管理

①管理4～8名測試工程師，提高任務估算、管理及進度控制能力，完成測試規劃并制定測試計劃；

②研究測試的技術手段，保持使用項目管理及支持工具的技能；

③用大量時間為其他測試工程師提供技術及過程方面的指導；

④開始與客戶打交道并做演示推介。

（5）6～12年，測試管理

①管理8名以上測試工程師，負責一個或多個項目的測試工作；

②與客戶打交道并做演示推介；

③保持使用項目管理及支持工具的技能。

4．人員的培訓

（1）軟件測試培訓內容分類

①測試基礎知識和技能培訓；

②測試設計培訓、測試工具培訓；

③測試對象——軟件產品培訓；

④測試過程培訓；

⑤測試管理培訓。

（2）制定測試人員培訓計劃

①是測試計劃的一個重要組成部分；

②需要管理層的重視，在時間和資源上予以保證；

③認真調查和分析測試人員的培訓需求；

④將培訓活動安排在測試任務開始前；

⑤“邊干邊學”模式很可能犧牲質量和效率；

⑥軟件測試實習活動在整個培訓中占較大比例；

⑦鼓勵合作學習，團隊演練；

⑧對培訓效果要及時評價，發現不足要進行改進。

4．8　軟件測試風險分析

一、軟件測試與商業風險

軟件測試是一種用來盡可能降低軟件風險的控制措施，是檢測軟件開發是否符合計劃，是否達到預期的結果的測試。如果檢測表明軟件的實現沒有按照計劃執行或與預期目標不符，就要采取必要的改進行動。軟件測試人員必須明白他們的任務之一就是通過測試來評估產品的商業風險，并將結果報告給公司管理者。

二、軟件風險的定義

軟件風險是指開發不成功引起損失的可能性，這種不成功事件會導致公司商業上的失敗。

三、軟件風險分析

風險分析是一個對潛在問題識別和評估的過程，即對測試的對象進行優先級劃分。

1．風險分析的組成部分

（1）發生的可能性——發生問題的可能性有多大；

（2）影響嚴重性——如果問題發生了會有什么后果。

2．風險分析的組成步驟

（1）首先列出潛在問題；

（2）然后對標識的每個潛在問題發生的可能性和影響嚴重性賦值，進行風險測定；

（3）測試人員根據測試分析結果的排列，關注潛在問題，設計與選擇測試用例。

3．風險分析采用的方法

（1）表格分析法

通用風險分析表包括以下幾項內容：

①風險標識（ID）——表示風險事件的唯一標識；

②風險問題——問題發生現象的簡要描述；

③發生的可能性——可能性值從1（低）～10（高）；

④影響的嚴重性——嚴重性值從1（低）～10（高）；

⑤風險預測值——發生可能性和影響嚴重性的乘積；

⑥風險優先級——風險預測值從高到低的排序。

軟件風險分析表如表4-1所示。

表4-1　軟件風險分析表

可能性與嚴重性的乘積產生的風險預測值，決定了風險優先級的排序。預測值越高，優先級別越高，針對該問題的測試就越重要。根據表4-1的計算結果風險問題的排列為B、A、D、C、E。在風險計算過程中，可能出現具有相同預測值的情況，有的測試機構可以通過將可能性和嚴重性分別加權計算來進行進一步的分析。

（2）風險矩陣

測試人員可根據需要對風險潛在問題的可能性和嚴重性采用高（1）、中（2）、低（3）三個等級來表示，形成一個二維風險矩陣，而風險優先級可用二者值之和表示。這樣，可能存在五個風險等級（即6、5、4、3、2，如圖4-4所示）。

圖4-4　軟件風險分析矩陣

總之，風險優先級是由軟件潛在問題影響的嚴重性決定的，是個相對值，而潛在問題的影響嚴重性是根據問題的可能性來評定的。如圖4-4所示，風險優先級的確定是使用可能性和嚴重性等級值相加，但是如果使用兩者值相乘，將會擴大有風險的區域。

4．風險分析的目的

軟件風險分析的目的是確定測試對象、測試優先級以及測試的深度。有時還包括確定可忽略的測試對象。在測試計劃階段，可以用風險分析的結果來確定軟件測試的優先級。對各測試項和測試用例賦予優先級代碼，將測試分為高、中和低的優先級類型，這樣可以在有限的資源和時間條件下，合理安排測試的覆蓋度與深度。

5．工作組成

軟件風險分析工作應由各部門的專家組成，通常包括：項目經理、開發人員、測試人員、用戶、客戶以及銷售人員。

6．注意事項

（1）對所有的軟件項目都應進行風險分析。如果軟件本身的缺陷與錯誤能夠導致災難性后果，那么這樣的軟件稱為安全性重要軟件，它在開發過程的各個階段都應進行安全性分析。

即使是非重要軟件，在項目的初期進行風險分析，有助于識別潛在的問題。這些問題可能會引發嚴重的后果，因此項目經理和開發人員在開發中要特別注意，以便預防風險。

（3）測試人員可利用風險分析的結果選擇最關鍵的測試，大部分的測試資源應該用在控制最高級別的商業風險上，而最低級別的商業風險應該占用盡可能少的測試資源。只有這樣，軟件測試人員才能制定合理的策略，控制軟件開發的風險。

四、軟件測試風險

1．概念

軟件測試風險是指軟件測試過程出現的或潛在的問題，造成的原因主要是測試計劃的不充分、測試方法有誤或測試過程的偏離，導致測試的補充以及結果的不準確。測試的不成功導致軟件交付潛藏著問題，一旦在運行時爆發，將會帶來很大的商業風險。

2．測試計劃的風險

（1）概念

測試計劃的風險一般指測試進度滯后或出現非計劃事件，即針對計劃好的測試工作造成消極影響的所有因素，對于計劃風險分析的工作是制定計劃風險發生時應采取的應急措施。一些常見的計劃風險包括：交付日期、測試需求、測試范圍、測試資源、人員的能力、測試預算、測試環境、測試支持、劣質組件、測試工具等。

（2）交付日期

交付日期的風險是主要風險之一。測試未按計劃完成，發布日期推遲，影響對客戶提交產品的承諾，管理的可信度和公司的信譽都要受到考驗，同時也受到競爭對手的威脅。交付日期的滯后，也可能是已經耗盡了所有的資源。

（3）計劃風險分析的工作重點

計劃風險分析的工作重點應放在提前制定應急措施來應對風險發生。當測試計劃風險發生時，可能采用的應急措施有：縮小范圍、增加資源、減少過程等措施。

例如：用戶在軟件開發接近尾聲時，提出重要需求變動。

①應急措施1：增加資源。請求用戶團隊為測試工作提供更多的用戶支持；

②應急措施2：縮小范圍。決定在進行后續發布中實現較低優先級的特性；

③應急措施3：減少質量過程。在風險分析過程中確定某些風險級別低的特征測試或少測試。

上述列舉的應急措施涉及到有關方面的妥協：如果沒有測試計劃風險分析和應急措施處理風險，開發者和測試人員采取的措施比較匆忙，不利于將風險的損失控制到最小。因此，軟件風險分析和測試計劃風險分析與應急措施相輔相成。綜上所述，計劃風險、軟件風險、重點測試、不測試，甚至整個軟件的測試與應急措施都是圍繞“用風險來確定測試工作優先級”原則來構造的。

4．9　軟件測試的成本管理

一、測試費用有效性

測試費用的有效性，可以用測試費用—質量曲線（如圖4-5所示）來表示。隨著測試費用的增加，發現的缺陷也會越多，兩線相交的地方是過多測試開始的地方，這時，排除缺陷的測試費用超過了缺陷給系統造成的損失費用。

圖4-5　測試費用質量曲線

二、測試成本控制

測試的成本控制目標是使測試開發成本、測試實施成本和測試維護成本最小化。在軟件產品開發過程中，作為產品發布每一新版本而進行的重復性的測試所需的成本是主要考慮的問題。測試實施成本組成部分包括：測試準備成本、測試執行成本和測試結束成本。

1．測試準備成本控制

測試準備成本控制的目標是使時間消耗總量、勞動力總量，尤其是準備工作所需的熟練勞動力總量最小化。準備工作一般包括：硬件配置、軟件配置、測試環境建立，以及測試環境的確定等。

2．測試執行成本控制

測試執行成本控制的目標是使總執行時間和所需的測試專用設備盡可能地減少。執行時間要求操作和用戶進行手工操作執行測試的時間應盡量減少，同時對勞動力和所需的技能也盡量減少。如需重新測試，不同選擇會有不同的成本控制效果，重新測試的決策是在成本與風險的矛盾中進行的。

（1）完全重新測試

將測試全部重新執行一遍，將風險降至最低，但加大了測試執行的成本。

（2）部分重新測試

有選擇地重新執行部分測試，能減少執行成本，但加大了風險。對部分重新測試進行合理選擇，將風險降至最低，而成本會很高，必須將其與測試執行成本進行比較，權衡利弊。利用測試自動化，進行重新測試，其成本效益較好。部分重新測試選擇方法有以下兩種：

①對由于程序變化而受到影響的每一部分進行重新測試。

②對與變化有密切和直接關系的部分進行重新測試。

注意：第一種辦法風險要小，而第二種是一種主觀制定的辦法，是建立在對軟件產品十分了解的基礎上的。一般地，選擇重新測試的策略建立在軟件測試錯誤的多少（即軟件風險的大小）與測試的時間、人力、資源投入成本的大小之間的折衷基礎上。

3．測試結束成本控制

進行測試結果分析和測試報告編制、測試環境的清除與恢復原環境所需的成本，使所需的時間和熟練勞動力總量減少到最低限度。

4．降低測試實施成本

（1）測試環境應建立在固定的測試專用硬軟件及網絡環境中，盡可能使用軟件和測試環境配置自動化。

（2）測試實施盡可能采用自動化的測試工具，減少手工輔助測試。

（3）若測試執行需要人工，最好是請初級技術人員，而不是測試工程師，測試工程師一般是作為測試項目經理。

（4）測試結束編制測試報告時，測試結果與預期結果的比較采用自動化方法，以降低分析比較成本。

（5）測試自動化的方法主要有：使用測試工具；測試用例的自動化執行；測試文檔編制的模板自動化生成。

5．降低測試維護成本

降低測試維護成本，同軟件開發過程，加強軟件測試的配置管理，所有測試的軟件樣品、測試文檔（測試計劃、測試說明、測試用例、測試記錄、測試報告）都應置于配置管理系統控制之下。

（1）降低測試維護工作成本主要考慮的因素

①對于測試中出現的偏差要增加測試。

②采用漸進式測試以適應新變化的測試。

③定期檢查維護所有測試用例，以獲得測試效果的連續性。

（2）重要措施

保持測試用例效果的連續性是重要的措施，有以下幾個方面：

①每個測試用例都是可執行的，即被測產品，功能上不應有任何變化。

②基于需求和功能的測試都應是適合的，若產品需求和功能發生較小的變化，不應使測試用例無效。

③每個測試用例不斷增加使用價值，即每個測試用例不應是完全冗余的，連續使用應是成本效益高的。

三、質量成本

1．質量成本要素

（1）一致性成本（Costof Conformance）

一致性成本指用于保證軟件質量的支出，包括預防成本（preventioncost）和測試預算，如測試計劃、測試開發、測試實施費用。測試預算被稱為審查費（appraisalcost）

（2）非一致性成本（Costof Nonconformance）

非一致成本由出現的軟件錯誤和測試過程故障（如延期、劣質的測試發布）引起。這些問題會導致測試返工、補測、延遲。追加測試時間和資金就是一種由于內部故障引起的非一致成本。還包括外部故障（軟件遺留錯誤影響客戶）引起部分。這些成本還包括技術支持小組預算，錯誤修正花費、產品收回、賠償和銷售成本。

注意：通常，外部故障非一致成本要大于一致性成本與內部故障非一致成本之和。

即

2．質量成本計算

質量成本＝一致性成本＋非一致性成本

即

四、缺陷探測率（DDP）

缺陷探測率DDP是另一個衡量測試工作效率的軟件質量成本的指標。

1．參數

（1）Bugs tester：測試者發現的錯誤數。

（2）Bugs customer：客戶發現并反饋技術支持人員進行修復的錯誤數。

2．注意

缺陷探測率越高，即測試者發現的錯誤越多，發布后客戶發現的錯誤就越少，降低了外部故障不一致成本，達到了節約總成本的目的，可獲得較高的測試投資回報率（ROI）。故缺陷探測率是衡量測試投資回報的一個重要指標。

五、測試投資回報舉例

1．案例介紹

假設對一開發的客戶管理軟件CRM進行測試。質量預防方面的一致性成本只考慮軟件測試的投資，把發布前后發現及修改的錯誤看成非一致性成本，假設發現的錯誤為300個，故障成本已知，測試過程的估算如下。各階段花費在發現及修改錯誤的成本假設如下：

（1）在開發過程單元測試階段，軟件開發人員發現及修改一個錯誤需要50元。

（2）建立獨立的測試進行集成和系統測試，測試人員發現錯誤，開發人員修改后，測試人員再確認，一個錯誤需要300元。

（3）在產品發布后，由客戶發現，報告技術支持人員、相關開發人員修改，測試組再進行回歸測試，一個錯誤需要2000元。

2．各種情況

（1）第1種情況

開發單位未建立獨立測試隊伍，由開發人員進行測試，發現100個錯誤，而產品發布后客戶發現錯誤200個，只存在故障成本構成的總成本為405000元，缺陷探測率為33.30%。

（2）第2種情況

開發單位建立了獨立測試隊伍，進行手工測試。投資預算人員費用為60000元，測試環境使用費為8000元，測試投資（一致性成本）為68000元；除了開發過程中開發人員發現并修改100個錯誤外，測試過程中測試人員發現錯誤150個，而產品發布后客戶發現50個錯誤。總質量成本下降到218000元（如表4-2所示），手工測試總質量成本節約了187000元，即為利潤。投資回報率（ROI）為275%，缺陷探測率為83.3%。

表4-2　測試投資回報分析

（3）第3種情況

開發單位在獨立測試中，采用自動化測試工具，投資中增加10000元的工具使用費，測試投資為（一致性成本）78000元。由于使用測試工具，測試人員在測試中發現錯誤增加到190個，在產品發布后，客戶發現錯誤下降到10個。總質量成本下降到160000元，比未建立獨立測試前節約了245000元。投資回報率為314%，缺陷探測率為96.7%。

綜上所述，建立獨立的軟件測試隊伍，選擇好的測試方案，不但提高了軟件缺陷的探測率，有效地控制軟件的風險，提高軟件質量，而且降低了軟件的質量成本，測試的投資回報率也將隨著明顯提高。