常用軟件測試模型分析及優化

付帥 孫云杰

摘 要：隨著IT產業的快速發展，軟件測試的質量得到了企業和客戶的高度重視，軟件測試行業的前景也很光明。本文從軟件測試的基本概念開始，重點介紹軟件測試過程中涉及的幾個關鍵階段。

軟件測試過程包括測試要求分析，測試計劃準備，測試計劃開發，測試用例設計和測試環境。準備，測試數據準備，測試用例執行，錯誤跟進，回歸測試以及測試報告編寫和摘要。測試的每個階段基本上是PDCA循環體，也稱為Deming循環，它是質量改進模型。P（Plan）代表計劃，D（Do）代表執行，C（Check）代表檢查，A（Action）代表處理。通過PDCA循環來達到提高軟件測試質量的目的。

關鍵詞：基本概念 軟件測試過程 PDCA循環 軟件測試質量

1 軟件測試的基本概念

測試軟件是軟件生命周期中的重要階段，也是軟件質量保證的關鍵步驟。軟件測試是執行程序以發現軟件錯誤和缺陷，記錄問題并修復它們以確保軟件質量的過程。軟件測試可用于檢查系統是否滿足預期要求。

2 軟件測試的過程概述

測試人員應盡早參加軟件測試活動。軟件測試過程包括以下階段：

a）測試需求分析；b）測試計劃的編寫；c）測試方案的制定；d）測試用例的設計；e）測試環境的搭建；f）測試數據的準備；g）測試用例的執行；h）Bug的跟進及回歸；i）測試報告的總結及編寫。

以上幾個階段實質上就是一個PDCA循環體。首先，在分析軟件需求的前提下規劃和設計測試活動，然后根據既定計劃測試和記錄測試。檢查并分析測試結果以形成測試報告。因此形成了一個質量改進的閉環。從而達到提高軟件測試質量的目的。通過完整的軟件測試過程，您不僅可以發現軟件缺陷，還可以發現錯誤，分析錯誤，查找錯誤分布特征和規則。這反過來又幫助項目經理識別當前用于改進的軟件開發過程中的缺陷。

3 軟件測試過程

3.1 測試需求分析

a）測試需求分析的目的

1）分析確定測試范圍；2）分析確定處理分支；3）分析確定所需要的業務場景；4）分析確定各功能點對應的預期處理結果。

b）測試需求分析的依據

在軟件測試需求分析階段，我們需要根據“軟件需求規范”逐項分析系統的各種需求。這包括功能要求，性能要求，安全要求，易用性要求，兼容性要求和安裝要求。并列出需求列表清單，對需求進行剖析，拆分至詳細的子需求點。

c）測試需求分析的方法

1）拆分《需求規格說明書》

在測試需求分析階段，通過將“需求規范”拆分為需求跟蹤矩陣的形式，并對各種需求進行分類，如功能要求，性能要求，安全要求，易用性要求，兼容性要求，安裝要求等。重點對功能需求在分析時進行明確指出哪些是業務功能，哪些是輔助功能，哪些是數據約束、哪些是編輯約束等。

2）分析業務場景

通過對不同的業務場景進行業務分析，考慮實際業務場景的調用者，并繪制相應的業務流程圖，檢查是否可以遍歷所有業務場景并設計涵蓋所有業務場景的測試用例。

3.2 測試計劃的編寫及測試方案的制定

軟件測試計劃是測試過程的總體設計。通過收集項目和產品相關信息，分析測試范圍，測試風險以及估計測試用例，工作量，資源和時間。對測試中使用的策略，方法，環境，資源和時間表做出合理安排。

測試計劃的編寫遵循5W原則，即：

a）When：何時開始做，何時結束測試，有必要合理安排測試進度；

b）What：我們要做什么？要明確的羅列出來，便于明確我們的測試方向和重點，及后期劃分責任模塊，即確定測試范圍；

c）Who：誰要參與這次項目的測試？具體負責哪個模塊的功能測試？主要負責任務是？都是在這個里面進行明確的責任劃分，即進行測試資源安排；

d）How：如何測試，確定我們的測試策略：它是否包括功能測試，性能測試，安全測試，安裝測試，可用性測試和兼容性測試，即確定測試策略；

e）Where：這個是說把文檔放在哪里，就明確指出我們的輸出文檔有哪些：比如說測試用例，Bug清單、測試報告等等文檔要存放的位置，作用就是規定輸出文檔以及輸出文檔的存放位置，即確定測試的輸出。

我們根據測試計劃編寫的5W原則可以進行編寫完整的測試計劃，測試計劃模板可如下所示：

1概述

1.1 測試項目簡介

1.2 測試范圍說明

2測試目標

3測試資源

3.1 軟件資源

3.2 硬件資源

3.3 測試工具

3.4 人力資源

4測試種類和測試標準

4.1 功能測試

4.2 性能測試

4.3 安裝測試

4.4 易用性測試

5測試要點

6測試時間和進度

7風險及對策

3.3 測試用例的設計

編寫測試用例可以使測試覆蓋更加全面，使測試工作井然有序，便于切換和通信。結構合理，案例覆蓋面廣，可執行，可重復。

測試用例一般包含的要素：用例編號，測試范圍描述，測試模塊描述，用例標題，前提條件，測試數據輸入，測試程序，測試用例優先級（致命，嚴重，一般，次要，推薦），預期結果，執行結果。

測試用例的常用方法如下所示：

a）等價類劃分法。等價類劃分方法是典型的黑盒測試方法。它對無法詳盡的輸入條件進行分類，并使用等價類中的測試條件作為查找系統缺陷的輸入代表。如果在這種輸入條件下也找不到系統缺陷，則與此等價的其他輸入也找不到系統缺陷，反之亦然。等價類考慮單個輸入字段的各種情況，避免輸入數據的不完整性和覆蓋的不穩定性，無論是盲目還是隨機。

b）邊界值。邊值分析方法是一種測試用例設計技術，它補充了等價類劃分方法。在測試期間，可以忽略邊界值的條件，并且在輸入或輸出范圍的邊界處發生軟件設計中的大量錯誤。而不是發生在輸入輸出范圍的內部。因此，為各種邊界條件設計測試用例可以識別更多的系統缺陷。

c）基本路徑分析法?；韭窂椒椒ㄊ窃O計白盒測試用例的一種方法，但它也可用于設計黑盒測試用例。重點是設計系統業務流程圖，確定流程分支，并根據覆蓋程序分支的原則選擇測試數據來設計測試用例。這樣設計的測試用例就覆蓋了主流程，但是對于一些存在循環的流程就很少考慮。

d）正交表法。正交表分析方法可以有效地減少設計測試用例的數量。正交表設計測試用例的步驟如下：

列出系統功能的影響因素，即系統功能輸入條件；

明確每個因素的輸入參數；

選擇合適的正交表來列出所有正交表值；

把變量的值映射到表中；

根據正交表分析，編寫測試用例。

e）因果圖。因果圖方法是通過圖形分析輸入的各種組合來設計測試用例的方法，并且適用于檢查程序輸入條件的各種條件的組合。設計因果關系測試用例的步驟如下：

分析所有可能的輸入和可能的輸出；

找出輸入和輸出之間的對應關系；

畫出因果圖；

把因果圖轉換成判定表；

根據判定表設計測試用例。

f）場景設計法。場景設計方法是Rational的RUP開發模型所倡導的測試用例設計思想。測試人員根據系統功能觸發事件，進行發散思維，考慮系統功能的主業務場景和擴展業務場景，并根據實際業務場景編寫測試用例。

g）異常分析法。主要是構造環境異常來看測試結果，比如網絡中斷，服務器宕機等。

h）錯誤猜測法。虛假猜測旨在通過根據經驗和直覺猜測程序中可能發生的各種錯誤來針對測試用例。

3.4 測試環境的搭建與維護

測試環境是完成軟件測試所必需的計算機硬件，軟件，網絡設備和歷史數據的通用術語。那就是測試環境=軟件+硬件+網絡+數據準備+測試工具。

在設置測試環境時，請嘗試考慮測試環境與正式環境之間的差異，并確保測試環境的穩定性。它有助于順利執行測試用例，并在測試環境中及時再現軟件缺陷。

如何搭建和維護穩定的測試環境呢？一般我們和開發人員進行溝通，根據測試計劃中提供的軟件和硬件資源，借鑒開發人員搭建的本地環境和其他類似環境的說明文檔，即可進行搭建和維護測試環境。

3.5 測試用例的執行

測試要求的分析，測試計劃和測試用例的準備，測試環境的構建和維護都準備好用于測試執行。測試用例的執行是測試過程的一項重要活動。在進行測試時，我們應該注意以下幾點：a）選擇合理的測試用例；b）測試的分工及資源的利用；c）在測試執行時，建議大家要先進行冒煙測試，即先進行整個業務流程的驗證，再進行細節的驗證；d）在執行測試時，及時記錄bug；e）如果在進行測試時測試用例覆蓋率不足，則需要及時補充；f）我們將進行多輪循環測試，直到滿足測試要求。

3.6 bug的跟進及回歸

在執行測試的過程中，如果發現測試用例失敗，我們將及時記錄錯誤。那么我們如何記錄高質量的bug呢？記錄bug時，我們應該包括問題范圍、問題錯誤行為描述、問題發現的版本、問題出現的環境、問題預期行為的描述和問題的重現步驟和問題截圖等。我們可以把 bug錄入缺陷管理系統，比如 bugfree等，在管理工具中，我們指派給相應的開發人員，待開發人員解決問題更新狀態后，我們再進行驗證，直至問題關閉。

因軟件底層架構設計等因素，等大多數問題關閉后，可能由于開發人員修改一個微小的問題，而導致影響其他功能的正常使用，故當我們進行完一輪測試后，我們還要進行多輪循環測試驗證，即回歸測試，直至滿足測試要求。

3.7 測試報告的總結及編寫

測試執行完成后，我們可以通過記錄的 bug和跟進的 bug狀態及分布情況，對 bug進行各維度匯總分析，確定軟件缺陷的規律，并幫助項目經理了解軟件開發過程中的缺陷以進行改進。

3.7.1軟件測試報告的編寫

我們可以從bug的總體數量，bug分類，bug類型分布，bug模塊分布，bug狀態分布，bug的趨勢等維度進行分析軟件問題。進而幫助我們編寫軟件測試報告。軟件測試報告的內容包括以下內容：

a）測試項目簡介；b）測試目標及范圍；c）測試過程；d）測試情況分析；e）測試總結。

3.7.2軟件測試總結

軟件測試摘要包括軟件資源消耗的摘要和軟件測試經驗的摘要。

a）軟件資源消耗情況：包括投入了多少測試人員，用了多長時間，執行了多少測試用例，覆蓋了多少功能模塊等；

b）軟件測試經驗：包括成功的測試經驗和失敗的教訓，比如哪些測試用例設計得比較好，覆蓋比較全面，采用的哪些測試策略比較好等。

4 結束語

軟件測試過程應該是一個完整的PDCA循環體。我們不會再執行完最后一個測試用例就戛然而止了，我們還會進行多輪的回歸驗證，直至滿足軟件測試的要求。PDCA循環是一個自我完善和改進的全閉環模型，對于質量的不斷提高和改進非常有效。

參考文獻：

[1] 陳能技.軟件測試技術大全：測試基礎 流行工具 項目實戰（第二版）[M].北京：人民郵電出版社.2011.