1.6 軟件測試流程

軟件測試工作通常要通過制訂測試計劃、測試設計、執行測試、測試總結幾個階段來完成。

1.6.1 測試計劃

測試計劃就是描述所有要完成的測試工作，包括被測試項目的背景、目標、范圍、方式、資源、進度安排、測試組織，以及與測試有關的風險等方面。

1．制訂測試計劃的目的

一個計劃一定是為了某種目的而產生的，對于軟件質量管理而言，制訂測試計劃的目的主要有以下幾點。

（1）使軟件測試工作各個階段目標更明確，測試工作可以有條不紊順利進行。

（2）促進項目組成員相互溝通，及時解決由于溝通不暢而引起的問題。

（3）預測在測試過程中可能出現風險并制訂合理規避風險措施。

（4）使軟件測試工作更易于管理。

2．制訂測試計劃的原則

制訂測試計劃是測試中最有挑戰性的一個工作，以下原則將有助于制訂測試計劃工作。

（1）制訂測試計劃應盡早開始。

（2）保持測試計劃的靈活性。

（3）保持測試計劃簡潔和易讀。

（4）盡量爭取多渠道測試計劃評審工作。

（5）計算測試計劃的投入成本。

3．面對的問題

制訂測試計劃時，測試人員可能面對以下問題，必須認真對待，并妥善予以處理。

（1）與開發者意見不一致，盡量達成一致，必要時企業高層需要介入。

（2）缺乏測試工具，在應用熟練的情況下，大型的項目測試工具的應用會在一定程度上減少測試周期，特別是在性能測試方面，測試工具的應用是非常必要的，大用戶量的并發操作，人工模擬困難巨大。

（3）培訓/溝通不夠，培訓工作很重要，有助于測試人員了解需求，了解系統實現的細節等。

（4）管理部門缺乏對測試工作的理解和支持，這是非常困難的事情，如果沒有管理部門的支持與理解，我們的測試工作就會阻力重重，處理方法還是要測試部門相關領導要多和管理部門相關領導溝通、交流，闡述測試的重要性，當然，測試人員也要通過自己的不懈努力來證明經過測試的產品和沒有測試的產品的具體差別，讓管理部門人員真正意識到測試的重要性。

（5）缺乏用戶的參與，測試的目的是為了要滿足客戶的需求。如果有客戶的參與，我們可以更加明確客戶的操作環境、操作方式等，這些對于我們后期能夠合理地設計測試用例都是大有裨益的。

（6）測試時間不足、工期短、資源少是測試部門經常要面臨的問題。這也需要和項目組合理確定測試時間，闡述測試時間和產品質量之間的關系以及測試的重點等內容，盡量多爭取較長的、合理的測試時間。

4．建議

制訂測試計劃時，由于各軟件公司的背景不同，測試計劃文檔也略有差異。實踐表明，制訂測試計劃時，使用正規化文檔通常比較好，本書的相關配套資源中提供了相關模板請大家借鑒參考。

1.6.2 測試設計

測試設計階段要設計測試用例和測試數據，要保證測試用例完全覆蓋測試需求。簡單地說，測試用例就是設計一個情況，軟件程序在這種情況下，必須能夠正常運行并且達到程序所設計的執行結果。如果程序在這種情況下不能正常運行，而且這種問題會重現出來，那就表示已經測出軟件有缺陷，這時候就必須將這個問題標示出來，并且輸入到問題跟蹤系統內，通知軟件開發人員。軟件開發人員接到通知后，將問題修改完成后，在下一個測試版本提交后，測試工程師取得新的測試版本，用同一個測試用例來測試這個問題，確保該問題被修復。在測試時，不可能進行窮舉測試，為了節省時間和資源，提高測試效率，必須要從龐大的測試用例中精心挑選出具有代表性的測試數據來進行測試。使用測試用例的好處主要體現在以下幾個方面。

（1）在開始實施測試之前設計好測試用例，可以避免盲目測試并提高測試效率。

（2）測試用例使軟件測試的實施重點更加突出、目的更加明確。

（3）在軟件版本更新后，只需修正少量的測試用例便可開展測試工作，降低工作強度，縮短項目周期。

（4）功能模塊的通用化和復用化使軟件易于開發，而測試用例的通用化和復用化則會使軟件測試易于開展，并隨著測試用例的不斷精化，其效率也不斷提高。

測試用例主要有如下幾種。

（1）功能測試用例（包含功能測試、健壯性測試、可靠性測試）。

（2）安全測試用例。

（3）用戶界面測試用例。

（4）安裝/反安裝測試用例。

（5）集成測試用例（包含接口測試）。

（6）性能測試用例（包含性能測試、負載測試、壓力測試、容量測試、并發測試、配置測試、可靠性測試、失敗測試）。

1.6.2.1 測試用例設計

測試設計階段最重要的是如何將測試需求分解，如何設計測試用例。

1．如何對測試需求進行分解

對測試需求進行分解需要反復檢查并理解各種信息，主要是和需求分析人員進行交流，必要的情況下也可以和用戶交流，理解用戶的真正需求是什么。

可以按照以下步驟執行。

（1）確定軟件提供的主要功能、性能測試項詳細內容。

（2）對每個功能進行分解，確定完成該功能所要進行的操作內容。

（3）確定數據的輸入和預期的輸出結果。

（4）確定會產生性能和壓力測試的重要指標，包括硬件資源的利用率，業務的響應時間，并發用戶數等重要內容。

（5）確定應用需要處理的數據量，根據業務情況預期未來2、3年內的數據擴展。

（6）確定需要的軟件和硬件配置。

……

2．如何設計測試用例

測試用例一般指對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略，需要指出的是，測試數據都是從龐大的可用測試數據中精心挑選出具有代表性的用例。測試用例是軟件測試系統化、工程化的產物，而測試用例的設計一直是軟件測試工作的重點和難點。

設計測試用例也就是設計針對特定功能或功能組合的測試方案，并編寫成文檔。測試用例應該體現軟件工程的思想和原則。

傳統的測試用例文檔編寫有兩種方式。

（1）一種是填寫操作步驟列表：將在軟件上進行的操作步驟一步一步詳細記錄下來，包括所有被操作的項目和相應的值。

（2）另一種是填寫測試矩陣：將被操作項作為矩陣中的一個字段，而矩陣中的一條條記錄則是這些字段的值。

評價測試用例的好壞有以下兩個標準。

（1）是否可以發現尚未發現的軟件缺陷。

（2）是否可以覆蓋全部的測試需求。

1.6.2.2 測試用例設計的方法

軟件測試設計的重要工作內容就是用例的設計，那么用例設計有哪些方法呢？接下來，就給大家介紹一下用例設計一些常用的方法。

1．等價類劃分方法

等價類劃分是一種典型的黑盒測試方法。使用這一方法時，完全不考慮程序的內部結構，只依據程序的規格說明來設計測試用例。由于不可能用所有可以輸入的數據來測試程序，而只能從全部可供輸入的數據中選擇一個進行測試。如何選擇適當的子集，使其盡可能多地發現錯誤，解決的辦法之一就是等價類劃分。

首先，把數目極多的輸入數據，包括有效的和無效的，劃分為若干等價類，而所謂等價類，是指某個輸入域的子集合。在該子集合中，各個輸入數據對于揭露程序中的錯誤都是等效的。并合理地假定：測試某等價類的代表值就等價于對這一類其他值的測試。因此，可以把全部輸入數據合理劃分為若干等價類，在每一個等價類中取一個數據作為測試的輸入條件，就可用少量代表性測試數據，取得較好的測試結果。

等價類的劃分有以下兩種不同的情況。

（1）有效等價類：是指符合《用戶需求規格說明書》的數據規范，合理地輸入數據集合。

（2）無效等價類：是指符合《用戶需求規格說明書》的數據規范，無效地輸入數據集合。

劃分等價類的原則如下。

（1）按區間劃分。

（2）按數值劃分。

（3）按數值集合劃分。

（4）按限制條件或規則劃分。

在確立了等價類之后，建立等價類表，列出所有劃分出的等價類，如表1-1所示。

表1-1 等價類劃分列表

再從劃分出的等價類中按以下原則選擇測試用例。

（1）為每一個等價類規定一個唯一的編號。

（2）設計一個新的測試用例，使其盡可能多地覆蓋尚未覆蓋的有效等價類。重復這一步驟，直到所有的有效等價類都被覆蓋為止。

（3）設計一個新的測試用例，使其僅覆蓋一個無效等價類，重復這一步驟，直到所有的無效等價類都被覆蓋為止。

這里給大家舉一個小例子，記得上小學一年級的時候，主要學習兩門功課：語文和數學，兩門功課單科滿分成績均為100分。期末考試的時候，老師會計算每個學生的總分，即總分=語文分數+數學分數。為了方便老師計算個人總成績，編寫如下C語言代碼：

        int sumscore(int maths, int chinese)
        {
            int sumdata;
            if (((maths>100) || (maths<0)) || ((chinese>100) || (chinese<0)))
            {
              printf("單科成績不能小于0或者大于100! ");
              return -1;
            }
            sumdata=maths+chinese;
            printf("%d", sumdata);
            return sumdata;
        }

我們現在根據“單科成績只能在0～100的兩個數字相加”的需求來設計測試用例，大家可以知道如果想把0～100的所有情況都測試到（僅包含正整數和零），我們需要101×101=10201個用例，顯然這種窮舉測試的情況是不可行的方法，因此我們嘗試用等價類劃分的方法來設計用例。

根據單科成績輸入的限制條件，可以將輸入區域劃分成3個等價類，如圖1-10所示。

從圖1-10中可以看到，我們將輸入區域分成了一個有效等價類（成績在0～100）和兩個無效等價類（成績<0）和（成績>100）。下面可以從每一個等價類中選擇一組具有代表性的數據來進行函數正確性的測試，詳細數據請參見表1-2。

圖1-10 單科成績等價類

表1-2 等價類劃分測試數據列表

細心的朋友們可能會發現一個問題，就是我們剛才等價類的劃分并不是很完善，我們只針對整型數據進行用例的設計，如果我們輸入的是空格、小數、字母等數據怎么辦？所以，測試用例的設計應該盡可能用少量的數據覆蓋盡可能多的情況，上面用例的設計我們更多地從輸入數據的范圍進行了考慮，沒有考慮如果參數的類型輸入不正確的情況。下面我們將先前沒有考慮進去的字母、空格等特殊字符也加入到測試數據列表中，形成比較完善的等價類劃分測試數據列表，詳細數據請參見表1-3。

表1-3 完善后的等價類劃分測試數據列表

2．邊界值分析法

人們從長期的測試工作經驗得知，大量的錯誤是發生在輸入或輸出范圍的邊界上，而不是在輸入范圍的內部。因此針對各種邊界情況設計測試用例，可以查出更多的錯誤。使用邊界值分析方法設計測試用例，首先應確定邊界情況。

選擇測試用例的原則如下。

（1）如果輸入條件規定了值的范圍，則應該取剛達到這個范圍的邊界值，以及剛剛超過這個范圍邊界的值作為測試輸入數據。

（2）如果輸入條件規定了值的個數，則用最大個數、最小個數、比最大個數多1個、比最小個數少1個的數作為測試數據。

（3）如果程序的規格說明給出的輸入域或輸出域是有序集合（如有序表、順序文件等），則應選取集合的第一個和最后一個元素作為測試用例。

（4）如果程序用了一個內部結構，應該選取這個內部數據結構的邊界值作為測試用例。

（5）分析規格說明，找出其他可能的邊界條件。

3．因果圖表法

因果圖方法最終生成的就是判定表。它適合于檢查程序輸入條件的各種組合情況。利用因果圖生成測試用例的基本步驟如下。

（1）分析軟件需求規格說明描述中哪些是原因，哪些是結果。原因是輸入條件或輸入條件的等價類，結果是輸出條件。

（2）分析軟件需求規格說明描述中的語義，找出原因與結果之間、原因與原因之間對應的關系，根據這些關系，畫出因果圖。

（3）標明約束條件。由于語法或環境的限制，有些原因和結果的組合情況是不可能出現的。為表明這些特定的情況，在因果圖上使用若干標準的符號標明約束條件。

（4）把因果圖轉換成判定表。

（5）為判定表中的每一列設計測試用例。

下面我們列出一些因果關系圖常用的表示符號，如圖1-11所示。

圖1-11 因果圖的基本符號

為了使大家對因果關系圖方法有一個清晰的了解，這里給大家舉一個例子：在一個應用系統中，系統要求能夠分類導入進貨和銷售的數據，對文件的命名有如下要求，文件名第一個字符必須為A（進貨）或B（銷售），第二個字符必須為數字。滿足則導入進貨、銷售接口文件信息到系統中。第一個字符不正確發出信息X12（“非進貨或銷售數據！”），第二個字符不正確發出信息X13（“單據信息不正確！”）。

（1）分析規范（如表1-4所示）。

表1-4 文件命名問題分析規范列表

（2）畫出因果圖（如圖1-12所示）。

圖1-12 文件命名問題因果圖

中間結點?是導出結果的進一步原因，考慮到原因1、2不可能同時為1，加上E約束。

（3）將因果圖轉換為判斷表（如表1-5所示）。

表1-5 文件命名問題判定表

從表1-5中可能發現組合情況1、2測試用例是空的，這是為什么呢？這是因為前面已經提到了原因，1、2不可能同時為1，所以條件1和條件2同時為1是沒有意義的（即第一個字符既為A又為B這種情況）。

4．判定表方法

判定表是分析和表達多邏輯條件下執行不同操作的情況的一種方法。判定表的優點是能夠將復雜的問題按照各種可能的情況全部列舉出來，簡明并避免遺漏。因此，利用判定表能夠設計出完整的測試用例集合。在一些數據處理問題當中，某些操作的實施依賴于多個邏輯條件的組合，即針對不同邏輯條件的組合值，分別執行不同的操作。判定表很適合于處理這類問題。

判定表通常由4個部分組成，如圖1-13所示。

圖1-13 判定表的4個組成部分

下面分別描述一下各個組成部分。

● 條件樁（Condition Stub）：列出問題的所有條件。通常認為列出的條件的次序無關緊要。

● 動作樁（Action Stub）：列出問題規定可能采取的操作。這些操作的排列順序沒有約束。

● 條件項（Condition Entry）：列出針對它左列條件的取值。在所有可能情況下的真假值。

● 動作項（Action Entry）：列出在條件項的各種取值情況下應該采取的動作。

這里給大家舉一個例子，某個貨運公司郵遞貨物的收費標準如下：如果收件地點在本省，則快件每千克5元，慢件每千克3元；如果收件地點在外省，則在20千克以內（包括20千克）快件每千克7元，慢件每千克5元，而超過20千克時，快件每千克9元，慢件每千克7元。

根據對上面問題的分析以后，我們可以得到條件取值分析表，如表1-6和表1-7所示。

表1-6 條件取值分析表

表1-7 判定表

（1）規則及規則合并。

規則：任何一個條件組合的特定取值及其相應要執行的操作稱為規則。在判定表中貫穿條件項和動作項的一列就是一條規則。顯然，判定表中列出多少組條件取值，也就有多少條規則，即條件項和動作項有多少列。

化簡：就是規則合并有兩條或多條規則具有相同的動作，并且其條件項之間存在著極為相似的關系。

兩規則動作項一樣，條件項類似，在1、2條件項分別取Y、N時，無論條件3取何值，都執行同一操作。即要執行的動作與條件3無關，于是可合并，這里我們用“－”表示與取值無關，如表1-8所示。

表1-8 化簡規則表

判定表的建立步驟如下（根據軟件規格說明）。

① 分析判定問題涉及幾個條件。

② 分析每個條件有幾個取值區間。

③ 畫出條件取值分析表，分析條件的各種可能組合。

④ 分析決策問題涉及幾個判定方案。

⑤ 畫出有條件組合的判定表。

⑥ 決定各種條件組合的決策方案，即填寫判定規則。

⑦ 合并化簡判定表，即相同決策方案所對應的各個條件組合是否存在無須判定的條件。

（2）判定表的優點和缺點。

優點：它能把復雜的問題按各種可能的情況一一列舉出來，簡明而易于理解，也可避免遺漏，如表1-9所示。

表1-9 化簡后的判定表

缺點：不能表達重復執行的動作，例如，循環結構。

B. Beizer指出了適合使用判定表設計測試用例的條件：

● 規格說明以判定表形式給出，或很容易轉換成判定表；

● 條件的排列順序不會也不影響執行哪些操作；

● 規則的排列順序不會也不影響執行哪些操作；

● 每當某一規則的條件已經滿足，并確定要執行的操作后，不必檢驗別的規則；

● 如果某一規則得到滿足要執行多個操作，這些操作的執行順序無關緊要。

B. Beizer提出這5個必要條件的目的是為了使操作的執行完全依賴于條件的組合。其實對于某些不滿足這幾條的判定表，同樣可以借以設計測試用例，只不過尚需增加其他的測試用例罷了。

5．錯誤推測法

有時候，為了發現一些問題，需要個人開發、測試以及其他方面的經驗積累才能夠發現缺陷。有很多朋友可能發現，一般用人單位都希望同等價位招聘一名有測試工作經驗的人，而不愿意招聘一名應屆畢業生。原因不僅僅是工作過的同志了解測試工作的流程，作為招聘單位可能考慮更多的是，已工作的朋友在測試方面積累了豐富的經驗，將會為公司的軟件測試缺陷的定位提供良好的條件。有經驗的人靠直覺和經驗來推測程序中可能存在的各種錯誤，從而有針對性地編寫檢查這些錯誤的例子，這就是錯誤推測法。錯誤推測法的基本想法是：列舉出程序中所有可能有的錯誤和容易發生錯誤的特殊情況，根據它們選擇測試用例。

作者曾經在對一個人事信息管理性能測試的時候，發現內存泄露明顯，在使用LoadRunner做性能測試的時候，50個虛擬用戶并發的情況下，應用系統會出現內存被耗盡，最后宕機的情況發生。依照以前的開發經驗，作者認為有以下幾種原因都會導致內存泄露情況的發生：

（1）代碼編寫時，申請了內存，使用完成以后，沒有釋放申請的內存；

（2）變量使用完成后，沒有清空這些變量的內容，也將會導致內存泄露；

（3）建立數據庫連接、網絡連接、文件操作等使用完成后，沒有斷開使用的連接。

上面幾種情況都將會出現內存泄露。作者把內存泄露現象以及出現內存泄露的原因信息提供給了開發人員，研發人員通過對代碼的審查，很快就發現在顯示人員的照片時，申請了內存，使用完成后，沒有釋放，就是這個原因直接導致宕機情況的發生。

綜上所述，對于測試工作來講，軟件開發、軟件測試、操作系統、應用服務器、數據庫以及網絡等方面的經驗，都會對您發現系統中的缺陷、定位問題產生的原因、解決問題提供一種思路。

6．場景法

現在的軟件幾乎都是用事件觸發來控制流程的，事件觸發時的情景便形成了場景，而同一事件不同的觸發順序和處理結果就形成事件流。這種在軟件設計方面的思想也可以引入軟件測試中，可以比較生動地描繪出事件觸發時的情景，有利于測試設計者設計測試用例，同時使測試用例更容易理解和執行。用例場景用來描述流經用例的路徑，從用例開始到結束遍歷這條路徑上所有基本流和備選流。

如圖1-14所示，圖中經過用例的每條路徑都用基本流和備選流來表示，直線表示基本流，是經過用例的最簡單的路徑。備選流用曲線表示，一個備選流可能從基本流開始，在某個特定條件下執行，然后重新加入基本流中（如備選流1和3）；也可能起源于另一個備選流（如備選流2），或者終止用例而不再重新加入到某個流（如備選流2和4）。

圖1-14 基本流和備選流

為了使大家對場景設計方法能夠有一個較深入的了解，這里給大家舉一個銀行ATM機提款操作的例子。下面是銀行ATM機操作業務的流程示意圖，如圖1-15所示。

圖1-15 ATM機相關操作流程示意圖

根據上面的流程示意圖，我們以銀行的客戶提款為例結合用例設計的方法，設計出如下場景，如表1-10所示。

表1-10 ATM機器提款場景法用例

注：T代表True（真）, F代表False（假）, N/A代表Not Applicable（不適合）。

用例的設計不僅僅是簡單地把要做的事情描述出來，通常還需要把每一個場景的測試數據也設計出來，這樣再進入測試執行階段就可以按部就班，做到心中有數了。下面就是針對前面的場景用例而設計出來的數據，如表1-11所示。

表1-11 ATM機器提款場景法用例數據

當然，除了上面講的這些常用的用例設計方法以外，還有正交試驗等設計方法。在實際測試中，往往是綜合使用各種方法才能有效地提高測試效率和測試覆蓋率，這就需要認真掌握這些方法的原理、認真研讀需求規格說明書，了解客戶的需求，積累更多的測試經驗，以便有效地提高測試水平。

以下是各種測試方法選擇的綜合策略，可供讀者在實際應用過程中參考。

（1）首先進行等價類劃分，包括輸入條件和輸出條件的等價劃分，將無限測試變成有限測試，這是減少工作量和提高測試效率最有效的方法。

（2）在任何情況下都必須使用邊界值分析方法，經驗表明，用這種方法設計出的測試用例發現程序錯誤的能力最強。

（3）可以用錯誤推測法追加一些測試用例，這需要依靠測試工程師的智慧和經驗。

（4）對照程序邏輯，檢查已設計出的測試用例的邏輯覆蓋程度，如果沒有達到要求的覆蓋標準，應當再補充足夠的測試用例。

（5）如果程序的功能說明中含有輸入條件的組合情況，則一開始就可選用因果圖法和判定表驅動法。

（6）對于參數配置類的軟件，要用正交實驗法選擇較少的組合方式達到最佳效果（請關注正交實驗法的讀者自行查找相關資料進行學習）。

（7）功能圖法也是很好的測試用例設計方法，我們可以通過不同時期條件的有效性設計不同的測試數據。

（8）對于業務流清晰的系統，可以利用場景法貫穿整個測試案例過程，在案例中綜合使用各種測試方法。

性能測試用例在測試設計階段也是一項重要的工作，本書重點是講解性能測試工具LoadRunner的應用，在后續章節對性能測試用例的設計有詳細地描述，請大家參看。

1.6.3 測試執行

用例設計完成之后，通常進行需求、研發、測試、質控人員舉行一輪或者多輪對用例的評審工作，評審主要是大家針對設計的用例，考查是否能夠覆蓋用戶的需求。如果用例評審不通過，則需要測試人員對用例進行修改完善、用例補充等工作，直到用例評審通過為止。

測試執行階段可以劃分為兩個子階段，前一個階段的目的非常清楚，就是發現缺陷，督促大家找出缺陷。測試用例的執行，應該是幫助我們更快地發現缺陷，而不是成為“發現缺陷”的障礙—使發現缺陷的能力降低。從理論上說，如果缺陷都找出來了，質量也就有保證了。所以在這一階段，就是盡可能發現缺陷，這樣不僅對開發團隊也非常有利，能盡早地修正大部分缺陷；對測試有利，測試效率高，后面的回歸測試也會穩定，信心更充分。在代碼凍結或產品發布前的稍后的子階段，目的是減少風險，增加測試的覆蓋度，這時測試的效率會低一些，以損失部分測試效率、獲得更高質量的收益。

1．缺陷管理

測試階段是測試人員和研發人員溝通最頻繁的一個階段。在軟件測試過程中，測試人員發現缺陷以后，通常會提交到缺陷管理工具中，常見的缺陷管理工具包括開源免費的測試工具BugZilla、Mantis、JIRA、BugFree等；商業的測試工具有HP TestDirector (QualityCenter)、IBM Rational ClearQuest、Compuware TrackRecord等。測試管理工具能讓測試人員、開發人員或其他的IT人員通過一個中央數據倉庫，在不同地方就能交互測試信息。一般缺陷管理工具都是測試管理工具的一個重要組成部分，它們都能夠將測試過程流水化—從測試需求管理，到測試計劃；測試日程安排，測試執行到出錯后的錯誤跟蹤—僅在一個基于瀏覽器的應用中便可完成，而不需要每個客戶端都安裝一套客戶端程序，使用簡便。

缺陷提交以后，在大型軟件企業或者非常規范企業，測試人員提交缺陷以后，測試負責任人或測試主管首先看一下這個缺陷是不是一個缺陷，如果是缺陷提交給研發的項目經理，研發項目經理將缺陷再分派給具體的研發人員。研發將缺陷修改完成以后，形成一個新的版本，提交給測試組，測試人員對新提交的版本進行問題的驗證—這個過程也叫回歸測試。如果測試人員經驗證所有缺陷均得到修復，則關閉缺陷，那么這個版本就可以作為發布的版本。但是，更多的時候大家可能會遇到對缺陷研發、測試人員之間存在著爭議的情況—測試人員認為這個缺陷應該修改，而研發人員認為這個缺陷不需要修改，這時需要質控、研發、測試等相關人員坐到一起，大家對缺陷進行評審來決定缺陷是否需要修改，或者對缺陷是否進行降級處理等，待達到產品的準出條件以后（準出條件舉例，如嚴重等級為中等級別的缺陷不能超過2個），就可以發行產品了。當然，缺陷的處理流程，不同企業對缺陷的處理流程也是各不相同的，這里給大家介紹一下最普遍的缺陷處理流程，如圖1-16所示。

圖1-16 缺陷處理流程

下面簡單給大家介紹一下。

（1）測試人員發現并提交一個Bug，此時Bug的狀態為新建（New）狀態。

（2）測試負責人、測試主管確認是一個Bug以后，將Bug的狀態置為打開（Open）狀態，研發經理針對提交的Bug指定研發人員對Bug進行修復，研發人員接受以后，Bug的狀態變為已分配（Assigned）狀態。

（3）研發人員修改該Bug以后，將Bug的變為已修復（Fixed），待系統Bug修復完成以后，形成一個新的版本提交給測試人員。

（4）測試人員對新版本進行回歸測試，如果該Bug確實已經修正，則將Bug的狀態修改為已關閉（Closed）狀態，如果沒有修正，則需要讓開發人員繼續修改該Bug。

當然，上面的流程還很不完善，在測試過程中還會遇到，新版本中仍然存在與上個版本相同的缺陷，此時就需要將Bug置為重新打開（Reopen）狀態，測試人員甲和測試人員乙提交相同Bug，此時就需要將Bug置為重復（Duplicated）狀態，還有研發人員認為這不是一個Bug，此時Bug被置為拒絕（Rejected）狀態等，這些情況在上面的流程中都沒有涉及，所以如果您對缺陷的流程非常關心的話，建議您參考其他的測試書籍，這里限于篇幅，不做過多介紹。

通常在提交一個Bug的時候，都需要輸入一些重要的信息，如圖1-17所示，包括缺陷的概要信息（Summary）、指派給某人（Assigned To）、缺陷發現者（Detected By）、缺陷發現的版本（Detected in Version）、缺陷發現日期（Detected on Date）、優先級（Priority）、Severity（嚴重等級）、項目名稱（Project）、模塊名稱（Subject）、狀態（Status）、描述（Description）等信息。

圖1-17 TestDirector提交一個新的Bug

下面簡要描述一下提交Bug時一些重要項的含義。

（1）缺陷概要是用簡明扼要的語言表述缺陷的實質性問題。

（2）描述是對概要信息的詳細表述，可以包括操作環境、操作步驟、測試數據等信息，這些內容將是您復現問題的重要依據。

（3）缺陷發現的版本是在測試的時候，那個版本的軟件中發現的該缺陷。

（4）項目名稱是您測試的產品或項目的名稱。

（5）模塊名稱是指產品或項目的具體的功能模塊名稱，如系統設置模塊、業務處理模塊等。

（6）狀態是指當前缺陷處于何種階段，如New、Open、Fixed、Closed等。

（7）優先級是處理該缺陷的優先等級，等級高的需要優先處理。

（8）嚴重等級是指該缺陷將對系統造成的影響程度，在TestDirector(QualityCenter)中主要包括Low（輕微）、Medium（中等）、High（高）、Urgent（嚴重）等。

2．測試執行

在軟件測試執行過程中，因為各個企業的背景不一樣，所以實施的手段也各不相同。有的企業非常規范，不僅進行常規的黑盒測試（功能性測試），還進行了白盒測試（如單元測試等），同時進行了系統性能方面的測試；有的企業則主要進行功能性測試和簡易的性能測試，這可能是目前國內軟件企業最普遍處理方式；有的企業則僅僅進行功能性的測試。

執行測試時應遵循以下步驟。

（1）設置測試環境，確保所需的全部構件（硬件、軟件、工具、數據等）都已實施并處于測試環境中。

（2）將測試環境初始化，以確保所有構件都處于正確的初始狀態，可以開始測試。

（3）執行測試過程。

測試的執行過程是非常重要，如果測試執行過程處理不得當將會引起軟件測試周期變長，測試不完全，人力、物力嚴重浪費等情況。測試執行階段是軟件測試人員與軟件開發人員之間溝通最密切的一個階段。軟件測試是否能夠按照計劃正常執行和開發人員、IT管理人員、需求人員等的密切配合分不開的。通常，開發人員構建一個版本并制作成一個安裝包以后，首先要先運行一下，看看系統的各個功能是否能夠正常工作，如果涉及硬件產品還要結合硬件產品進行測試，保證系統大的流程應該是可以運行通的，這也就是我們前面所說的冒煙測試。經過冒煙測試以后，如果沒有問題則把該包提交給測試部門進行測試，否則，研發人員需要定位問題產生的原因，修改代碼或設置，重新編譯、打包以及進行冒煙測試。如果測試部門拿到的是沒有經過冒煙測試的產品，則很有可能會出現前面講的資源浪費、耽誤測試進度等情況的發生。筆者管理的測試團隊有一次就因為研發人員因為工作任務繁忙，沒有對提交的軟、硬件結合產品進行冒煙測試，導致測試人員為定位問題而進行業務模塊、系統設置等多方面的測試工作，苦苦耗時達5個工作日之久，最后檢查到原因，是研發人員提供的硬件的端口是壞的，這個教訓很深刻。冒煙測試后的產品提交給測試部門以后，測試人員部署相應的環境，開始依據前期已經通過評審的功能、性能方面的測試用例。在執行用例的過程中，如果發現了缺陷，則提交到缺陷管理工具中，所有的功能、性能測試用例執行完成以后，宣告第一輪測試工作完成。開發人員需要對第一輪測試完成后，出現的缺陷進行修復工作，測試人員也需要在測試過程中修改、完善、補充用例的工作，通常，每輪測試完成以后，測試人員都會給出一個測試的報告，指出當前存在缺陷的嚴重等級數目，重要的缺陷，缺陷的列表等數據提供給項目經理、研發經理等，目的是讓項目組的相關負責人清楚當前系統中存在的主要問題，及時把問題解決掉。等到研發人員對第一輪的缺陷修復完成后，重新編譯、打包、冒煙測試，提交給測試部門，測試人員進行第二輪測試，測試人員此時需要進行回歸測試，驗證上一輪的問題是否已經修復，是不是還有新的問題產生等。如此往復，經過幾輪的測試以后，依據項目計劃、測試計劃以及缺陷的情況等來決定是否終止測試。

1.6.4 測試總結

測試執行完成以后，我們需要對測試的整個活動進行總結。測試總結工作是非常有意義的一件事情，它不僅能夠對本次測試活動進行分析，也能夠為以后測試同類產品提供重要的依據。

通常，一份測試總結報告中會包括如下內容：系統的概述、編寫目的、參考資料、測試環境、差異、測試充分性評價、殘留缺陷、缺陷統計、缺陷分析、測試活動總結、測試結論等方面。

1．編寫測試總結報告的目的

測試總結的目的是總結測試活動的結果，并根據這些結果對測試進行評價。這種報告是測試人員對測試工作進行總結，并識別出軟件的局限性和發生失效的可能性。在測試執行階段的末期，應該為每個測試計劃準備一份相應的測試總結報告。本質上講，測試總結報告是測試計劃的擴展，起著對測試計劃“封閉回路”的作用。

2．重要項說明

● 編寫目的：主要說明編寫這份文檔的目的，指出預期的讀者。

● 參考資料：主要列出編寫本文檔時參考的文件、資料、技術標準以及他們的作者、標題、編號、發布日期和出版單位，說明能夠得到這些文件資料的來源。對于每個測試項，如果存在測試計劃、測試設計說明、測試規程說明、測試項傳遞報告、測試日志和測試事件報告等文件，則可以引用它們。一般參考資料可以用列表形式給出，參考表1-12。

表1-12 參考資料列表

● 系統概述：主要歸納對測試項的評價，指明被測試項及其版本/修訂級別，測試項概述，如項目/產品的名稱、版本以及測試項內容等。可以參考表1-13。

● 產品名稱：人事代理系統。

● 產品版本：V2.0.0。

測試項信息如表1-13所示。

表1-13 測試項列表

● 測試環境：指出測試活動發生的環境（包括軟件、硬件、網絡環境等），您可以參考下面形式。

本次測試的測試環境如下。

軟件環境。

操作系統：xx。

服務器端：Windows XP Professional+ SP2/ Windows 2000 Server+SP4。

客戶端：Windows XP Professional+SP2。

數據庫：SQL Server 2000。

Web應用：Tomcat-5.5.9。

瀏覽器：Microsoft Internet Explorer 6.0+SP2。

硬件環境。

CPU:Intel (R) Pentium (R) 4 CPU 3.00GHz。

內存：1GB以上。

硬盤：80GB。

網卡：100M以太網。

● 差異：報告測試項與它們的設計說明之間的差別，并指出與測試計劃、測試設計說明或測試規程說明中描述或涉及的測試間的差別，說明產生差別的原因。

● 測試充分性評價：根據測試計劃規定的充分性準則（如果存在的話）對測試過程作充分性評價。指出未被充分測試的特性或特性組合，并說明理由。測試的評測主要方法包括覆蓋評測和質量評測。測試覆蓋評測是對測試完全程度的評測，它建立在測試覆蓋基礎上，測試覆蓋是由測試需求和測試用例的覆蓋或已執行代碼的覆蓋表示的。質量評測是對測試對象的可靠性、穩定性以及性能的評測。質量建立在對測試結果的評估和對測試過程中確定的缺陷及缺陷修復的分析基礎上。

3．覆蓋評測

覆蓋評測指標是用來度量軟件測試的完全程度的，所以可以將覆蓋用做測試有效性的一個度量。最常用的覆蓋評測是基于需求的測試覆蓋和基于代碼的測試覆蓋，它們分別是指針對需求（基于需求的）或代碼的設計/實施標準（基于代碼的）而言的完全程度評測。

（1）基于需求的測試覆蓋。

基于需求的測試覆蓋在測試過程中要評測多次，并在測試過程中，每一個測試階段結束時給出測試覆蓋的度量。例如，計劃的測試覆蓋、已實施的測試覆蓋、已執行成功的測試覆蓋等。

（2）基于代碼的測試覆蓋。

如果您所在的單位做白盒測試，則需要考慮基于代碼的測試覆蓋。基于代碼的測試覆蓋評測是測試過程中已經執行的代碼的多少，與之相對應的是將要執行測試的剩余代碼的多少。許多測試專家認為，一個測試小組在測試工作中所要做的最為重要的事情之一就是度量代碼的覆蓋情況。很明顯，在軟件測試工作中，進行基于代碼的測試覆蓋評測這項工作極有意義，因為任何未經測試的代碼都是一個潛在的不利因素。

但是，僅僅憑借執行了所有的代碼，并不能為軟件質量提供保證。也就是說，即使所有的代碼都在測試中得到執行，并不能擔保代碼是按照客戶需求和設計的要求去做了。

4．質量評測

測試覆蓋的評測提供了對測試完全程度的評價，而在測試過程中對已發現缺陷的評測提供了最佳的軟件質量指標。

常用的測試有效性度量是圍繞缺陷分析來構造的。缺陷分析就是分析缺陷在與缺陷相關聯的一個或者多個參數值上的分布。缺陷分析提供了一個軟件可靠性指標，這些分析為揭示軟件可靠性的缺陷趨勢或缺陷分布提供了判斷依據。

對于缺陷分析，常用的主要缺陷參數有以下4個。

● 狀態：缺陷的當前狀態（打開的、正在修復的或關閉的等）。

● 優先級：表示修復缺陷的重要程度和應該何時修復。

● 嚴重性：表示軟件缺陷的惡劣程度，反映其對產品和用戶的影響等。

● 起源：導致缺陷的原因及其位置，或排除該缺陷需要修復的構件。

缺陷分析通常用以下3類形式的度量提供缺陷評測。

（1）缺陷發現率。

缺陷發現率是將發現的缺陷數量作為時間的函數來評測，即創建缺陷趨勢圖，請大家參見圖1-18。

圖1-18 缺陷趨勢圖

（2）缺陷潛伏期。

測試有效性的另外一個有用的度量是缺陷潛伏期，通常也稱為階段潛伏期。缺陷潛伏期是一種特殊類型的缺陷分布度量。在實際測試工作中，發現缺陷的時間越晚，這個缺陷所帶來的損害就越大，修復這個缺陷所耗費的成本就越多。圖1-19顯示了一個項目的缺陷潛伏期的度量。

圖1-19 缺陷潛伏期的度量

（3）缺陷密度。

軟件缺陷密度是一種以平均值估算法來計算出軟件缺陷分布的密度值。程序代碼通常是以千行為單位的，軟件缺陷密度是用下面公式計算的：

軟件缺陷密度=軟件缺陷數量/代碼行或功能點的數量

圖1-20所示為一個項目的各個模塊中每千行代碼的缺陷密度分布圖。

圖1-20 各個模塊中每千行代碼的缺陷密度

但是，在實際評測中，缺陷密度這種度量方法是極不完善的，度量本身是不充分的。這里邊存在的主要問題是：所有的缺陷并不都是均等構造的。各個軟件缺陷的惡劣程度及其對產品和用戶影響的嚴重程度，以及修復缺陷的重要程度有很大差別，有必要對缺陷進行“分級、加權”處理，給出軟件缺陷在各嚴重性級別或優先級上的分布作為補充度量，這樣將使這種評測更加充分，更有實際應用價值。因為在測試工作中，大多數的缺陷都記錄了它的嚴重程度的等級和優先級，所以這個問題通常都能夠很好解決。例如，圖1-21所示的缺陷分布圖表示軟件缺陷在各優先級上所應體現的分布方式。

圖1-21 各優先級上軟件缺陷分布圖

上面講了一些關于覆蓋評測和質量評測內容，下面結合以前做過的項目給大家舉一些測試充分性評價方面的示例。

（1）本次測試嚴格按照軟件系統測試規范執行測試任務。

（2）在測試進行過程中，滿足執行測試的前置條件，測試計劃、測試用例準備齊全，并經過內部評審認可，需求覆蓋度達到100%，滿足測試準入條件。

（3）測試過程嚴格按照測試計劃實施，測試用例的執行覆蓋度達100%，同時，測試過程中根據實際系統的運行方式，對測試用例和數據進行了修改和補充。

（4）測試過程中進行了必要的回歸測試和交叉測試。

……

結果概述：總結測試的結果，指出各測試項的測試情況，描述測試用例的執行通過情況，給出最后一次的測試版本號，這里給大家一個示例參考。

（1）本次測試進行了功能測試的檢查。最后一次的測試基線為：Build_HHR(α) V2.0.0.014。

（2）功能測試執行情況詳見表1-14，缺陷描述詳見TD。

表1-14 測試用例執行情況

殘留缺陷摘要：簡要羅列未被修改的殘留缺陷，并附有未修復意見。

缺陷統計：對隸屬于各個測試項的缺陷進行統計，通常都需要統計一下兩項數據，有的測試部門還有統計其他一些數據信息，請大家根據需要進行選擇添加。

各模塊下不同解決方案的缺陷統計如表1-15所示。

表1-15 各模塊下不同解決方案的缺陷統計表

各模塊下不同嚴重級別的缺陷統計如表1-16所示。

表1-16 各模塊下不同嚴重級別缺陷所占百分比

缺陷分析：對有效缺陷進行缺陷分布分析、缺陷趨勢分析，以及缺陷齡期分析。

通常都會對以下數據進行分析。

● 模塊：缺陷分布：如表1-17所示。

表1-17 模塊缺陷分布

由表1-17可知，模塊“預約”“電子檔案”“批量導入”和“檔案錄入”占的缺陷相對比較多，主要是異常處理、邏輯控制以及界面易用性問題。

● 缺陷趨勢圖：如圖1-22所示。

圖1-22 缺陷趨勢圖

由圖1-22可知：

（1）整個測試活動持續11天，隨著測試時間的推移，新提交的缺陷數減少；

（2）整個測試共提交有效缺陷42個，所有缺陷均已解決、已關閉。

活動總結：總結主要的測試活動和事件。總結資源消耗數據，如人員的總體水平，總機時和每項主要測試活動所花費的時間。同時與《測試計劃》中活動進度安排進行比對，如表1-18所示。

表1-18 測試活動時間表

根據《測試計劃》中計劃的測試時間和實際測試執行時間進行比對，可得表1-19。

由表1-19可知，計劃時間比執行時間偏差較大，主要原因為安排兩個測試人員執行測試，但是由于另外一名測試人員配合其他產品的測試相關工作，所以計劃時間長于實際測試時間。

表1-19 計劃時間和執行時間比對表

測試結論：對每個測試項進行總的評價。本評價必須以測試結果和項的通過準則為依據。說明該項軟件的開發是否已達到預定目標。計算代碼缺陷率和產品缺陷率。

例如：

（1）經測試驗證，系統完成需求所要求的全部功能，測試項中各功能的實現與需求描述一致；

（2）測試結果滿足測試退出準則；

（3）整個系統在設計結束后定義功能點96個，測試發現的有效缺陷為42個，按功能點對缺陷數進行計算可得，代碼缺陷率=42/96=0.4375個/FP（代碼缺陷率=有效缺陷/FP總數）。