從軟件工程的角度來說，軟件開發(fā)主要分為需求分析、概要設計、詳細設計、編碼、測試、安裝及維護6個階段。軟件測試項目的過程管理絕不僅限于測試階段，因為軟件測試不能在代碼全部完成后才開始，而應在項目需求分析階段就開始審查需求分析文檔、產品規(guī)格說明書，在設計階段需要審查系統(tǒng)設計文檔、程序設計流程圖、數(shù)據(jù)流圖等，在代碼測試階段需要審查代碼，查看是否遵守代碼的變量定義規(guī)則、是否有足夠的注釋內容等。從軟件開發(fā)生命周期的角度來說，軟件測試項目的過程管理在各個階段的具體內容是不同的；但在每個階段，測試任務的最終完成都需要經過從計劃、設計、執(zhí)行到結果分析、總結等一系列步驟，這構成軟件測試的一個基本過程。

軟件測試項目的過程管理主要集中在軟件測試項目的啟動、測試計劃、測試用例設計、測試執(zhí)行、測試結果的審查和分析，以及如何開發(fā)或使用測試過程管理工具上。本篇主要是從管理的角度去討論如何組織、跟蹤和控制這些過程，而不是從測試技術的角度去討論如何設計和實現(xiàn)。測試過程管理的基本內容如下所述。

（1）測試項目啟動階段：首先需要確定項目負責人，即項目小組組長，項目組長確定以后，才可以組建整個測試小組，配合開發(fā)等部門開展工作；其次要參加有關項目計劃、分析和設計的會議，獲得必要的需求分析、系統(tǒng)設計文檔，以及相關產品/技術知識的培訓和轉移。

（2）測試計劃階段：確定測試范圍、測試策略和方法，對風險、日程表、資源等進行分析和估計。

（3）測試設計階段：制訂測試的技術方案，設計測試用例，選擇測試工具，編寫測試腳本等。測試用例設計需要做好各項準備再開始進行，最后還需要其他部門幫忙評審測試用例。

（4）測試執(zhí)行階段：搭建相關的測試環(huán)境，準備測試數(shù)據(jù)，執(zhí)行測試用例，對發(fā)現(xiàn)的軟件缺陷進行報告、分析、跟蹤等。測試執(zhí)行不涉及較高的技術性，但它是測試的基礎，直接關系到測試的可靠性、客觀性和準確性。

（5）測試結果的審查和分析階段：測試執(zhí)行結束后，需要對測試結果進行整體或綜合的分析，以確定軟件產品質量的當前狀態(tài)，為產品的改進或發(fā)布提供數(shù)據(jù)和依據(jù)。從管理上講，需要組織好測試結果的評審和分析會議，做好測試報告或質量報告的編寫和評審。

軟件測試的計劃階段

本篇將從測試項目實施和管理的角度，進一步討論軟件測試項目計劃的實施目標和標準、計劃階段的細分、測試項目計劃的要點和編制測試計劃的一些技巧等。

1.軟件測試項目計劃的目標

測試項目計劃的整體目標是確定測試任務、確定所需的各種資源和投入、預見可能出現(xiàn)的問題和風險，以指導測試的執(zhí)行，最終實現(xiàn)測試目標，保證軟件產品質量。制訂測試計劃需要達到的目標如下。

（1）為各項測試活動制訂切實可行的、綜合的計劃，包括每項測試活動的對象、范圍、方法、進度和預期結果。

（2）為項目實施建立一個組織模型，并定義測試項目中每個角色的責任和工作內容。

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

（4）確定測試所需要的時間和資源，以保證其可獲得性、有效性。

（5）確立每個測試階段測試完成及測試成功的標準、需要實現(xiàn)的目標。

（6）識別出測試活動中各種風險，并消除可能消除的風險，降低那些不可能消除的風險所帶來的損失。

2.軟件測試項目的標準

為保證測試可按計劃執(zhí)行，必須確認滿足何種外部條件測試才能開始，即需要在測試計劃中定義軟件測試項目的輸入標準，然后定義測試項目的輸出標準。

（1）測試的輸入標準如下。

① 整體項目計劃框架：需要在框架清晰的情況下制訂測試計劃。

② 需求規(guī)格說明書：只有將用戶具體的、實際的需求了解透徹，才能制定準確的測試需求和測試范圍。

③ 技術知識或業(yè)務知識：技術的變化或新技術的引入需要事先準備，包括人員的培訓。

④ 標準環(huán)境：符合用戶使用環(huán)境或業(yè)務運行環(huán)境的需求。

⑤ 設計文檔：設計文檔是設計軟件測試用例的重要參考資料，幫助測試人員了解系統(tǒng)的薄弱環(huán)節(jié)、關鍵點等。

⑥ 足夠的資源：包括人力資源、時間資源，硬件資源、軟件資源和其他環(huán)境資源。

⑦ 人員組織結構：項目經理、測試組長、小組成員等的責任及相互關系已確定。

（2）測試的輸出標準如下。

① 測試執(zhí)行標準。

② 缺陷描述和處理標準。

③ 文檔標準和模板。

④ 測試分析、質量評估標準等。

3.測試實施策略的制定

測試策略描述當前測試項目的目標和所采用的測試方法。此目標不是上述測試計劃的目標，而是針對某個應用軟件系統(tǒng)或程序等具體的測試項目要達到的預期結果，包括在規(guī)定的時間內需要完成的測試內容、軟件產品的特性或質量得到確認的方面。

測試策略還需要描述測試不同階段（單元測試、集成測試、系統(tǒng)測試等）的測試對象、范圍和方法以及每個階段內所需要進行的測試類型（功能測試、性能測試、壓力測試等）。

在制定測試策略前，需要確定測試策略項。測試策略制定需要考慮的內容如下。

（1）需要使用的測試技術和工具。例如，60%用 Rational Robot自動測試，40%采用手工測試。

（2）測試完成標準，用于計劃和實施測試及通報測試結果。例如，95%以上的測試用例通過并且P1、P2級別的缺陷全部解決。

（3）影響資源分配的特殊考慮。例如，有些測試必須在極冷或極熱的環(huán)境下進行，有些測試必須在周末進行，有些測試必須通過遠程環(huán)境執(zhí)行。

在確認測試方法時，需要根據(jù)實際情況，結合測試方法的特點來選擇合適的方法。下面介紹兩種常用的劃分方法。

根據(jù)是否需要執(zhí)行被測軟件來劃分，分為靜態(tài)測試和動態(tài)測試。靜態(tài)測試包括產品規(guī)格說明書、程序代碼的審查等，在工作中容易被忽視，在測試策略上應說明如何加強這些環(huán)節(jié)。

根據(jù)是否針對系統(tǒng)的內部結構和具體實現(xiàn)算法來劃分，分為白盒測試和黑盒測試。如何將白盒測試和黑盒測試有機地結合起來，也是編寫測試策略時需要處理的問題之一。盡管用戶更傾向于基于產品規(guī)格說明的功能測試，但白盒測試可以發(fā)現(xiàn)潛在的邏輯錯誤，而這種錯誤往往是功能測試無法發(fā)現(xiàn)的。

綜上所述，可能需要在“基于測試技術的測試策略”和“基于測試方案的綜合測試策略”之間進行選擇。

4.測試項目計劃階段的細分

測試項目的計劃需要經過計劃初期、起草、討論、評審等不同階段，才能制訂完成，并不能一氣呵成。并且不同的測試階段（單元測試、集成測試、系統(tǒng)測試、驗收測試等）或不同的測試類型（安全性測試、性能測試、可靠性測試等）都可能需要有具體的測試計劃。

（1）計劃初期要收集整體項目計劃、需求分析、功能設計、系統(tǒng)原型、用戶用例（User Case）等文檔或信息，理解用戶的真正需求，了解技術難點和弱點或新的技術，與其他項目相關人員進行交流，確保在各個主要方面理解一致。

（2）測試計劃最關鍵的步驟是確定測試需求、測試層次。要將軟件分解成一個個的單元，對各個單元編寫測試需求。測試需求也是測試設計和開發(fā)測試用例的基礎，并且是用來衡量測試覆蓋率的重要指標。

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

（4）在將測試計劃提供給其他部門討論之前，要預先在測試小組/部門內部進行審查。

（5）召開有需求分析、設計、開發(fā)人員參加的計劃討論會議，測試組長對測試計劃的思想、策略做較為詳細的介紹，并聽取在場人員對測試計劃中各個部分的意見，進行討論交流。

（6）項目中的每個人都應當參與測試計劃的評審，包括市場、開發(fā)、支持、技術寫作及測試人員。計劃的審查是必不可少的，出自于一個測試工程師的定義不一定是完整或準確的。此外，測試工程師很難評估自己的測試計劃，就像開發(fā)者很難測試自己的代碼一樣。每一個計劃審查者都可能根據(jù)其經驗及專長提出修改建議，有時還能提供測試工程師在組織產品定義時沒有掌握的信息。

（7）在計劃討論、評審的基礎上，綜合各方面的意見，即可完成測試計劃書，然后上報給測試經理或項目經理。得到批準，方可執(zhí)行。

測試計劃不僅服務于軟件產品當前版本，而且還是下個版本的測試設計的主要信息來源。在進行新版本測試時，可以在原有的軟件測試計劃書上做修改，但需要經過嚴格審查。

5.測試項目計劃的要點

軟件測試計劃內容主要包括產品基本情況、測試需求說明、測試策略和記錄、測試資源配置、計劃表、問題跟蹤報告、測試計劃的評審結果等。除了產品基本情況、測試需求說明、測試策略等，測試計劃的焦點主要集中在以下幾個方面。

（1）目標和范圍：產品特性、質量目標，各階段的測試對象、目標、范圍和限制。

（2）項目估算：根據(jù)歷史數(shù)據(jù)，采用恰當?shù)脑u估技術，對測試工作量、所需資源（人力、時間、軟硬件環(huán)境）做出合理估算。

（3）風險計劃：測試可能存在的風險分析、識別，以及風險的回避、監(jiān)控和管理。

（4）日程：獲取項目工作分解結構，并采用時限圖、甘特圖等制定時間/資源表。

（5）項目資源：人員、時間、硬件和軟件等資源的組織和分配，人力資源是重點，且與日程安排聯(lián)系密切。

（6）跟蹤和控制機制：質量保證和控制，變化管理和控制等。

測試計劃書的內容也可按單元測試、集成測試、系統(tǒng)測試、驗收測試等階段去組織，為每個階段制訂一個計劃書，也可為每個測試類型（安全性測試、性能測試、可靠性測試等）制訂特殊的計劃書。

同時，可為上述測試計劃書的每項內容制訂一個具體實施的計劃。例如，對每個階段的測試重點、范圍、所采用的方法、測試用例設計的思想、提交的內容等進行細化，供測試項目組的內部成員使用。一些重要的項目中會形成一系列的計劃書，如測試范圍/風險分析報告、測試標準工作計劃、資源和培訓計劃、風險管理計劃、測試實施計劃、質量保證計劃等。

6.編制測試項目計劃的技巧

在計劃書中，有些內容僅作為項目參考，如測試項目的背景、所采用的技術方法等；但有些內容則可看作一種結論或承諾，必須要實施或必須達到目標，如測試小組結構和組成、測試項目的里程碑、面向解決方案的交付內容、項目標準、質量標準、相關分析報告等。

若要做好測試計劃，測試設計人員需要仔細閱讀相關資料，包括用戶需求規(guī)格說明書、設計文檔、使用說明書等，全面熟悉系統(tǒng)，并對軟件測試方法和項目管理技術有深刻的理解。此外還有一些技巧，具體如下所述。

（1）確定測試項目的任務，清楚測試范圍和測試目標，例如，提交什么樣的測試結果。

（2）讓所有合適的相關人員參與測試項目的計劃制訂，尤其是在測試計劃早期。

（3）對測試的各階段所需要的時間、人力及其他資源進行預估，盡量做到客觀、準確、留有余地。

（4）制定測試項目的輸入、輸出和質量標準，并和有關方面達成一致。

（5）建立變化處理的流程規(guī)則，識別出整個測試階段中內在的、不可避免的變化因素，并思考如何進行控制。

軟件測試的設計和開發(fā)階段

測試計劃完成后，測試過程即將進入軟件測試設計和開發(fā)階段。軟件測試設計建立在測試計劃書的基礎上，應認真理解測試計劃中的測試大綱、測試內容及測試的通過準則，以及通過測試用例來完成測試內容的典型的邏輯轉換，將其作為測試的實施依據(jù)，最終實現(xiàn)所確定的測試目標。軟件設計是將軟件需求轉換成軟件表示的過程，主要描繪出系統(tǒng)結構、詳細的處理過程和數(shù)據(jù)庫模式；軟件測試設計則是將測試需求轉換成測試用例，描述測試環(huán)境、測試執(zhí)行的范圍和層次、用戶的使用場景。因此軟件測試設計和開發(fā)是軟件測試過程中技術深、要求高的一個關鍵階段。

1.軟件測試設計和開發(fā)的主要內容

（1）制訂測試的技術方案。確認各個測試階段需要采用的測試技術、測試環(huán)境和平臺以及選擇測試工具。有關系統(tǒng)測試中的安全性、可靠性、穩(wěn)定性、有效性等的技術方案是這部分工作內容的重點。

（2）設計測試用例。根據(jù)產品需求分析、系統(tǒng)技術設計等規(guī)格文檔，在測試的技術方案基礎上設計具體的測試用例。

（3）設計特定的測試用例集合，滿足特定的一些測試目的和任務。即根據(jù)測試目標、測試用例的特性和屬性（優(yōu)先級、層次、模塊等），選擇不同的測試用例，構成執(zhí)行某個特定測試任務的測試用例集合（組），如基本測試用例組、例外測試用例組、性能測試用例組、完全測試用例組等。

（4）測試開發(fā)。根據(jù)所選擇的測試工具，將所有可進行自動化測試的測試用例轉換為自動化測試腳本的過程。

（5）測試環(huán)境的設計。根據(jù)所選擇的測試平臺及測試用例所要求的特定環(huán)境，進行服務器、網絡等測試環(huán)境的設計。

軟件測試設計中還需要考慮：所設計的測試技術方案是否可行、是否有效、是否能達到預期的測試目標；所設計的測試用例是否完整，邊界條件是否考慮，其覆蓋率能達到多高；所設計的測試環(huán)境是否和用戶的實際使用環(huán)境比較接近。

關鍵是做好測試設計前的知識傳遞，將設計/開發(fā)人員已掌握的技術、產品、設計等知識傳遞給測試人員；同時，需要做好測試用例的審查工作，不僅需要通過測試人員的審查，還需要通過設計/開發(fā)人員的審查。

2.測試用例設計的方法和管理

（1）測試用例設計方法

軟件測試用例設計有白盒測試和黑盒測試相對應的設計方法。黑盒測試的用例設計采用等價類劃分、因果圖、邊界值分析、用戶界面測試、配置測試、安裝選項驗證等方法，適用于功能測試和驗收測試。而白盒測試的用例設計有多種方法，具體如下所述。

① 采用邏輯覆蓋（包括程序代碼的語句覆蓋、條件覆蓋、分支覆蓋）的結構測試用例的設計方法。

② 基于程序結構的域測試用例設計方法，其中“域”是指程序的輸入空間。域測試是在分析輸入空間的基礎上，完成域的分類、定義和驗證，從而對各種不同的域選擇適當?shù)臏y試點（測試用例）進行測試。

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

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

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

⑥ 基于代數(shù)運算符號的測試用例設計方法。受分支問題、二義性問題和大程序問題的困擾，此方法使用較少。

（2）測試用例的屬性

測試用例需要經過創(chuàng)建、修改和不斷改善的過程，一個測試用例應具備的屬性如下。

① 測試用例的優(yōu)先次序。優(yōu)先級越高，被執(zhí)行的時間越早，執(zhí)行的次數(shù)越多。由優(yōu)先級最高的測試用例組構成基本驗證測試（Basic Verification Test,BVT），每次構建軟件包時，都會被執(zhí)行一遍。

② 測試用例的目標性。有的測試用例為主要功能而設計，有的測試用例為次要功能而設計，有的測試用例為系統(tǒng)的負載而設計，有的測試用例則為一些特殊場合而設計。

③ 測試用例所屬的范圍及其所屬的組件或模塊。這種屬性被用來管理測試用例。

④ 測試用例的關聯(lián)性。測試用例一般和軟件產品特性相聯(lián)系，多數(shù)情況下用于驗證產品的某個功能。這種屬性可被用于驗證被修改的軟件缺陷，或對軟件產品緊急補丁包的測試。

⑤ 測試用例的階段性。測試用例屬于單元測試、集成測試、系統(tǒng)測試、驗收測試中的某一個階段。對每個階段構造一個測試用例的集合并執(zhí)行，容易計算出該階段的測試覆蓋率。

⑥ 測試用例的狀態(tài)性。若測試用例當前無效，則被置于非激活狀態(tài)，不會被運行，只有被激活的測試用例才被運行。

⑦ 測試用例的時效性。針對同樣功能，可能所用的測試用例不同，因為不同的產品版本在產品功能、特性等方面的要求不同。

⑧ 所有者、日期等屬性。測試用例的屬性還包括創(chuàng)建人、創(chuàng)建時間、修改人、修改時間。

根據(jù)上述屬性，再結合測試用例的編號、標題、描述（前置條件、操作步驟、期望結果）等，即可對測試用例進行基于數(shù)據(jù)庫方式的良好管理。

（3）測試用例的審查

測試用例設計完成后，需要經過非正式和正式的審查，兩種審查方式具體如下所述。

① 非正式的審查：一般在測試小組內部進行，同測試組人員互相檢查或讓資深人員、測試組長幫助審查。

② 正式的審查：一般通過正式 E-mail 將已設計好的測試用例發(fā)送給相應的系統(tǒng)分析、設計人員和程序員，讓其先通讀一遍，將發(fā)現(xiàn)的問題記錄下來。然后由測試組長或項目經理召開一個測試用例評審會，由測試設計人員先對測試用例的設計思想、方法、思路等進行說明，然后系統(tǒng)分析、設計人員和程序員提出問題，測試人員做出回答，必要時進行討論。

評審完的測試用例經修改后，即可直接用于手工測試或用于測試腳本的開發(fā)。

3.測試開發(fā)

使用所選擇的測試工具腳本語言（如Rational SQABasic）編寫測試腳本，將所有可進行自動化測試的測試用例轉化為測試腳本。其輸入是基于測試需求的測試用例，輸出是測試腳本和與之相對應的期望結果，這種期望結果一般存儲在數(shù)據(jù)庫中或特定格式的文件中。

（1）測試開發(fā)的步驟：首先要搭建測試腳本開發(fā)環(huán)境，安裝測試工具軟件，設置管理服務器和具有代理的客戶端池，建立項目的共享路徑、目錄，并能連接到腳本存儲庫和被測軟件等；然后執(zhí)行錄制測試腳本初始化過程、獨立模塊過程、導航過程和其他操作過程，結合已經建立的測試用例，對錄制的測試腳本進行組織、調試和修改，構成一個有效的測試腳本體系，并建立外部數(shù)據(jù)集合。

（2）由于被測系統(tǒng)處在不完善階段，在運行測試腳本的過程中容易中斷，因此在測試腳本開發(fā)時，需要將此類錯誤處理好，并及時記錄當時的狀態(tài)，而且要求可以繼續(xù)執(zhí)行下去。解決上述問題的辦法有很多，例如，跳轉到別的測試過程、調用一個能夠清除錯誤的過程等。

（3）測試開發(fā)常見的問題：測試開發(fā)很亂，與測試需求或測試策略沒有對應性；測試過程不可重用；測試過程被作為一個編程任務來執(zhí)行，導致腳本可移植性差。應在腳本的結構、模塊化、參數(shù)傳遞、基礎函數(shù)（庫）等方面做好設計，從而避免上述問題。

軟件測試的執(zhí)行階段

1.軟件測試執(zhí)行階段的管理難點

測試用例的設計和測試腳本的開發(fā)完成后，即開始執(zhí)行測試。測試執(zhí)行階段分為手工測試和自動化測試。

手工測試：在合適的測試環(huán)境下，按照測試用例的條件、步驟要求，準備測試數(shù)據(jù)，對系統(tǒng)進行操作，比較實際結果和測試用例所描述的預期結果，以確定系統(tǒng)是否真正實現(xiàn)了所需功能。

自動化測試：通過自動化測試工具，運行測試腳本，得到測試結果。

自動化測試的管理相對比較容易，測試工具會百分之百地執(zhí)行測試腳本，并自動記錄測試結果。而對手工測試的管理相對要復雜得多，在整個測試執(zhí)行階段中，管理上會碰到一系列問題。

（1）如何確保測試環(huán)境滿足測試用例所描述的要求？

（2）如何保證每個測試人員清楚自己的測試任務？

（3）如何保證每個測試用例得到百分之百的執(zhí)行？

（4）如何保證所報告的缺陷正確、描述清楚、沒有漏掉信息？

（5）如何在驗證缺陷和對新功能的測試之間尋找平衡？

（6）如何跟蹤缺陷處理的進度，使嚴重的缺陷及時得到解決？

（7）如何確保正確的測試環(huán)境？需要專人（OA實驗室管理人員、測試組長等）進行檢查。

2.測試階段目標的檢查

測試階段目標的檢查需要對每個測試階段（單元測試、集成測試、確認測試、系統(tǒng)測試和驗收測試等）的結果進行分析，保證每個階段的測試任務得到執(zhí)行，達到階段性的目標。

（1）單元測試：目的在于檢查每個程序單元是否正確實現(xiàn)詳細設計說明中的模塊功能、性能、接口和設計約束等，發(fā)現(xiàn)各模塊內部可能存在的各種錯誤。

（2）集成測試：主要目標是發(fā)現(xiàn)與接口有關的問題。不管是外部接口還是內部參數(shù)的傳遞，都需要抓住關鍵模塊，關鍵模塊應盡早測試，并將自頂向下、自底向上兩種測試策略相結合，對各個模塊嚴格執(zhí)行。由于涉及系統(tǒng)不同的模塊、不同的層次或不同的部門，容易造成一些漏洞、疏忽，需要根據(jù)設計文檔多提問題、集體審查。

（3）確認測試：主要目的是表明軟件是可以正常工作的，并且確保軟件的所有功能和性能以及其他特性與用戶的要求一致。只有通過了確認測試的軟件才具備進入系統(tǒng)測試階段的資格。

（4）系統(tǒng)測試：目標是保證系統(tǒng)在實際的環(huán)境中能夠穩(wěn)定、可靠地運行。包括恢復性測試、安全性測試、強度測試和性能測試等。系統(tǒng)測試技術要求高，占用資源比較多，因此應設計完備，并準備充分。

（5）驗收測試：驗收測試既可是非正式的測試，也可是正式的、有計劃的測試。一個軟件產品可能擁有眾多用戶，不可能由每個用戶驗收，此時應多采用稱為α、β測試的過程。α測試是指軟件開發(fā)公司組織內部人員模擬各類用戶對即將發(fā)布的軟件產品（稱為α版本）進行測試，嘗試發(fā)現(xiàn)錯誤并修正。α 測試的關鍵在于盡可能逼真地模擬實際運行環(huán)境和用戶可能的操作方式。經過α測試調整的軟件產品，稱為β版本。緊隨其后的β測試是指組織公司外部的典型用戶試用β版本，并要求用戶報告異常情況、提出批評意見，然后再對β版本進行修改和完善。

3.測試用例執(zhí)行的跟蹤

測試用例執(zhí)行直接關系到測試的效率、結果，不僅需要做到測試效率高，而且需要保證結果正確、準確、完整等。其管理關鍵是提高測試人員素質和責任心，樹立良好的質量文化意識，其次需要通過一定的跟蹤手段從某些方面保證測試執(zhí)行的質量。

（1）測試效率的跟蹤比較容易，按照測試任務和測試周期，可得到期望的曲線，然后每天檢查測試結果，了解是否按預期進度進行。

（2）測試結果的跟蹤比較困難，應將每個人的執(zhí)行測試情況記錄好，即清楚每個測試用例的執(zhí)行人員，一旦某個缺陷被遺漏，可以追溯到具體責任人。

4.缺陷的跟蹤和管理

缺陷的跟蹤和管理一般由數(shù)據(jù)庫系統(tǒng)來執(zhí)行，但數(shù)據(jù)庫系統(tǒng)也是依賴于一定的規(guī)則和流程工作的。管理思路如下所述。

（1）設計好每個缺陷應包含的信息條目、狀態(tài)分類等。

（2）通過系統(tǒng)自動發(fā)送郵件給相應的開發(fā)人員和測試人員，使任何缺陷都不被遺漏，并能得到及時處理。

（3）通過日報、周報等各類項目報告來跟蹤目前缺陷狀態(tài)。

（4）在各個大小里程碑之前，召開相關人員的會議，對缺陷進行會審。

（5）通過歷史曲線、統(tǒng)計曲線等進行分析，預測未來情況。

5.和項目組外部人員的溝通

為了使測試進展順利，與項目組外部人員保持良好溝通是非常有必要的，這樣，測試碰到的問題比較容易解決，測試中發(fā)現(xiàn)的缺陷處理效率也會提高。

（1）下面列舉一些有利于溝通的技巧。

① 通過一種合適的、可接受的方式指出對方的問題，盡量做到對事不對人。

② 每周召開一次不同部門一起參加的會議。

③ 建立大項目的郵件組，包含各部門主要人員的郵件地址。

④ 在同一個大項目組的開發(fā)、測試人員的日報、周報等需要互相抄送。

⑤ 適當開展一些類似于聚餐的活動，改善組員關系，增進各方面人員的相互了解。

（2）人員間的基本通信方式主要有以下5種。

① 正式非個人方式。例如，正式審查會議。

② 正式個人之間交流。例如，成員之間的正式討論，有電子郵件跟蹤或文字記載，并包含所做出的結論，方便后期跟蹤、審查。

③ 非正式個人之間交流。例如，個人之間通過電話、即時消息系統(tǒng)的自由交流。

④ 內部公共論壇。大家就某個主題發(fā)表自己看法，提相關問題或回答相關問題。

⑤ 成員網絡。例如，成員與小組之外或公司之外有經驗的相關人員進行交流。

6.測試執(zhí)行結束

測試執(zhí)行全部完成，并不意味著測試項目的結束。測試項目結束的階段性標志是將測試報告或質量報告發(fā)送出去，并得到測試經理或項目經理的認可。除了測試報告或質量報告的寫作之外，還要對測試計劃、設計和執(zhí)行等進行檢查、分析，完成項目的總結。

關于測試報告或質量報告的寫作，主要簡單介紹對測試執(zhí)行結束前后的管理。

（1）審查測試全過程：在原來跟蹤的基礎上，需要對測試項目進行全過程、全方位的審視，檢查測試計劃、測試用例是否得到執(zhí)行，檢查測試是否有漏洞。

（2）對當前狀態(tài)的審查：包括產品缺陷和過程中未解決的各類問題。對產品目前存在的缺陷進行逐個分析，了解對產品質量的影響程度，從而決定產品的測試能否告一段落。

（3）結束標志：根據(jù)上述兩項的審查進行評估，若所有測試內容完成、測試的覆蓋率達到要求以及產品質量達到已定義的標準，即可定稿測試報告，并發(fā)送出去。

（4）項目總結：通過對項目中的問題進行分析，找出流程、技術或管理中所存在的問題根源，避免重蹈覆轍，并獲得項目成功經驗。