測試用例

測試用例（Test Case）是將軟體測試的行為活動做一個科學化的組織歸納，目的是能夠將軟體測試的行為轉化成可管理的模式；同時測試用例也是將測試具體量化的方法之一，不同類別的軟體，測試用例是不同的。

測試用例的設計方法主要有黑盒測試法和白盒測試法。

黑盒測試也稱功能測試，黑盒測試著眼於程序外部結構，不考慮內部邏輯結構，主要針對軟體界面和軟體功能進行測試。

白盒測試又稱結構測試、透明盒測試、邏輯驅動測試或基於代碼的測試。白盒法全面了解程序內部邏輯結構、對所有邏輯路徑進行測試。

⒈指導測試的實施

測試用例主要適用於集成測試、系統測試和回歸測試。在實施測試時測試用例作為測試的標準，測試人員一定要按照測試用例嚴格按用例項目和測試步驟逐一實施測試。並對測試情況記錄在測試用例管理軟體中，以便自動生成測試結果文檔。

根據測試用例的測試等級，集成測試應測試那些用例，系統測試和回歸測試又該測試那些用例，在設計測試用例時都已作明確規定，實施測試時測試人員不能隨意作變動。

⒉規劃測試數據的準備

在我們的實踐中測試數據是與測試用例分離的。按照測試用例配套準備一組或若干組測試原始數據，以及標準測試結果。尤其像測試報表之類數據集的正確性，按照測試用例規劃準備測試數據是十分必須的。

除正常數據之外，還必須根據測試用例設計大量邊緣數據和錯誤數據。

⒊編寫測試腳本的"設計規格說明書"

為提高測試效率，軟體測試已大力發展自動測試。自動測試的中心任務是編寫測試腳本。如果說軟體工程中軟體編程必須有設計規格說明書，那麼測試腳本的設計規格說明書就是測試用例。

⒋評估測試結果的度量基準

完成測試實施后需要對測試結果進行評估，並且編製測試報告。判斷軟體測試是否完成、衡量測試質量需要一些量化的結果。例：測試覆蓋率是多少、測試合格率是多少、重要測試合格率是多少，等等。以前統計基準是軟體模塊或功能點，顯得過於粗糙。採用測試用例作度量基準更加準確、有效。

⒌分析缺陷的標準

通過收集缺陷，對比測試用例和缺陷資料庫，分析確證是漏測還是缺陷復現。漏測反映了測試用例的不完善，應立即補充相應測試用例，最終達到逐步完善軟體質量。而已有相應測試用例，則反映實施測試或變更處理存在問題。

軟體測試的重要性是毋庸置疑的。但如何以最少的人力、資源投入，在最短的時間內完成測試，發現軟體系統的缺陷，保證軟體的優良品質，則是軟體公司探索和追求的目標，每個軟體產品或軟體開發項目都需要有一套優秀的測試方案和測試方法。

影響軟體測試的因素很多，例如軟體本身的複雜程度、開發人員（包括分析、設計、編程和測試的人員）的素質、測試方法和技術的運用等。因為有些因素是客觀存在，無法避免的；有些因素則是波動的、不穩定的。例如開發隊伍是流動的，有經驗的開發人員走了，新人不斷補充進來；每個開發人員的工作也會受情緒影響，等等。有了測試用例，無論是誰來測試，參照測試用例實施，都能保障測試的質量，從而把人為因素降到最小。即便最初的測試用例考慮不周全，隨著測試的進行和軟體版本更新，也將日趨完善。

因此，測試用例的設計和編製是軟體測試活動中最重要的。測試用例是測試工作的指導，是軟體測試必須遵守的準則，更是軟體測試質量穩定的根本保障。

確定測試用例之所以很重要，原因有以下幾方面。

(1)測試用例構成了設計和制定測試過程的基礎。

(2)測試的“深度”與測試用例的數量成比例。由於每個測試用例反映不同的場景、條件或經由產品的事件流，因而，隨著測試用例數量的增加，測試人員對產品質量和測試流程也就越有信心。

(3)判斷測試是否完全的一個主要評測方法是基於需求的覆蓋，而這又是以確定、實施和/或執行的測試用例的數量為依據的。類似下面這樣的說明：“95%的關鍵測試用例已得以執行和驗證”，遠比“我們已完成95%的測試”更有意義。

(4)測試工作量與測試用例的數量成比例。根據全面且細化的測試用例，可以更準確地估計測試周期各連續階段的時間安排。

(5)測試設計和開發的類型以及所需的資源主要都受控於測試用例。

(6)測試用例通常根據它們所關聯的測試類型或測試需求來分類，而且將隨類型和需求進行相應的改變。最佳方案是為每個測試需求至少編製兩個測試用例：一個測試用例用於證明該需求已經滿足，通常稱作正面測試用例；另一個測試用例反映某個無法接受、反常或意外的條件或數據，用於論證只有在所需條件下才能夠滿足該需求，這個測試用例稱作負面測試用例。

著重介紹一些編製測試用例的具體做法。

編寫測試用例文檔應有文檔模板，須符合內部的規範要求。測試用例文檔將受制於測試用例管理軟體的約束。

軟體產品或軟體開發項目的測試用例一般以該產品的軟體模塊或子系統為單位，形成一個測試用例文檔，但並不是絕對的。

測試用例文檔由簡介和測試用例兩部分組成。簡介部分編製了測試目的、測試範圍、定義術語、參考文檔、概述等。測試用例部分逐一列示各測試用例。每個具體測試用例都將包括下列詳細信息：版本號、模塊名稱、用例編號、用例名稱、用例級別、預知條件、驗證步驟、期望結果（含判斷標準）、測試結果、測試時間、測試人員等。

我們早期的測試用例是按功能設置用例。後來引進了路徑分析法，按路徑設置用例。演變為按功能、路徑混合模式設置用例。

按功能測試是最簡捷的，按用例規約遍歷測試每一功能。

對於複雜操作的程序模塊，其各功能的實施是相互影響、緊密相關、環環相扣的，可以演變出數量繁多的變化。沒有嚴密的邏輯分析，產生遺漏是在所難免。路徑分析是一個很好的方法，其最大的優點是在於可以避免漏測試。

但路徑分析法也有局限性。在一個非常簡單字典維護模塊就存在十餘條路徑。一個複雜的模塊會有幾十到上百條路徑是不足為奇的。筆者以為這是路徑分析比較合適的使用規模。若一個子系統有十餘個或更多的模塊，這些模塊相互有關聯。再採用路徑分析法，其路徑數量成幾何級增長，達5位數或更多，就無法使用了。那麼子系統模塊間的測試路徑或測試用例還是要靠傳統方法來解決。這是按功能、路徑混合模式設置用例的由來。

測試用例可以分為基本事件、備選事件和異常事件。設計基本事件的用例，應該參照用例規約（或設計規格說明書），根據關聯的功能、操作按路徑分析法設計測試用例。而對孤立的功能則直接按功能設計測試用例。基本事件的測試用例應包含所有需要實現的需求功能，覆蓋率達100%。

設計備選事件和異常事件的用例，則要複雜和困難得多。例如，字典的代碼是唯一的，不允許重複。測試需要驗證：字典新增程序中已存在有關字典代碼的約束，若出現代碼重複必須報錯，並且報錯文字正確。往往在設計編碼階段形成的文檔對備選事件和異常事件分析描述不夠詳盡。而測試本身則要求驗證全部非基本事件，並同時盡量發現其中的軟體缺陷。

可以採用軟體測試常用的基該方法：等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、邏輯覆蓋法等設計測試用例。視軟體的不同性質採用不同的方法。如何靈活運用各種基該方法來設計完整的測試用例，並最終實現暴露隱藏的缺陷，全憑測試設計人員的豐富經驗和精心設計。

測試用例是一個文檔，是執行的最小實體。測試用例包括輸入、動作、時間和一個期望的結果，其目的是確定應用程序的某個特性是否可正常工作，並且達到程序所設計的結果，以便測試某個程序路徑或核實是否滿足某個特定需求般在進行測試用例設計前要全面了解被測試產品的功能、明確測試範圍(特別是要明確哪些是不需要測試的)、具備基本的測試技術與方法等。測試用例設計一般遵循以下原則:

(1)正確性。輸入用戶實際數據以驗證系統是否滿足需求規格說明書的要求；測試用例中的測試點應首先保證要至少覆蓋需求規格說明書中的各項功能，並且正常。

(2)全面性。覆蓋所有的需求功能項；設計的用例除對測試點本身的測試外，還需考慮用戶實際使用的情況、與其他部分關聯使用的情況、非正常情況(不合理、非法、越界以及極限輸入數據)操作和環境設置等。

(3)連貫性。用例組織有條理、主次分明，尤其體現在業務測試用例上；用例執行粒度盡量保持每個用例都有測點，不能同時覆蓋很多功能點，否則執行起來牽連太大，所以每個用例間保持連貫性很重要。

(4)可判定性。測試執行結果的正確性是可判定的，每一個測試用例都有相應的期望結果。

(5)可操作性。測試用例中要寫清楚測試的操作步驟，以及與不同的操作步驟相對應的測試結果。

1、白盒法

白盒法又稱結構化方法(結構測試)或邏輯覆蓋法，其基本思想是把程序看作是路徑的集合。這樣，對程序的測試便轉化為對程序中某些路徑的測試，要設法讓被測程序的“各處”均被執行到，使潛伏在程序每個角落的錯誤均有機會暴露出來。因此，白盒法實際上是一種選擇通過指定路徑的輸入數據的分析方法。

2、測試覆蓋率

採用白盒法可以用測試覆蓋率作為測試徹底度的定量衡量標準。常用的覆蓋率有:

(1)語句覆蓋：要求設計足夠的測試數據，使程序的每條語句都至少執行一次。

(2)判定覆蓋(分支覆蓋):使程序中的每個判定至少出現一次“真值”和一次假值”，即程序中的每個判定(分支)都至少要經過一次。

(3)條件覆蓋：使判定中每個條件的所有可能的結果至少出現一次，並且使每條語句至少執行一次。

(4)判定條件覆蓋：使判定覆蓋和條件覆蓋同時得到滿足。

(5)多重條件覆蓋：又稱條件的組合覆蓋，是使程序中每個判定中的條件的各種組合都至少取到一次，並且每條語句至少執行一次。

此外，還有諸如路徑覆蓋(程序中每條路徑至少執行一次)、基本路徑覆蓋(循環次數只考慮小於等於一次所組成的程序路徑，每條基本路徑至少執行一次)等。為了獲取測試覆蓋率(不論是哪一種覆蓋率)需要有測試工具的幫助，且需要花費人力與機時去做測試工作(設計測試用例、輸入測試數據、進行統計計算等。

3、黑盒法

黑盒法又稱為功能測試，是根據軟體需求說明書上羅列的各項功能、性能指標，來構造測試用例的輸入數據，實際執行被測軟體，分析執行過程的行為與執行結果以便檢查出被測軟體的錯誤。在黑盒法測試中，測試者可以完全不關心程序的內部結構。可見，白盒法是一種邏輯驅動方法，而黑盒法是一種功能驅動方法。黑盒法是最常用的測試方法。

⒈測試用例的評審

測試用例是軟體測試的準則，但它並不是一經編製完成就成為準則。測試用例在設計編製過程中要組織同級互查。完成編製后應組織專家評審，需獲得通過才可以使用。評審委員會可由項目負責人、測試、編程、分析設計等有關人員組成，也可邀請客戶代表參加。

⒉測試用例的修改更新

測試用例在形成文檔后也還需要不斷完善。主要來自三方面的緣故：第一、在測試過程中發現設計測試用例時考慮不周，需要完善；第二、在軟體交付使用后反饋的軟體缺陷，而缺陷又是因測試用例存在漏洞造成；第三、軟體自身的新增功能以及軟體版本的更新，測試用例也必須配套修改更新。

一般小的修改完善可在原測試用例文檔上修改，但文檔要有更改記錄。軟體的版本升級更新，測試用例一般也應隨之編製升級更新版本。

⒊測試用例的管理軟體

運用測試用例還需配備測試用例管理軟體。它的主要功能有三個：第一、能將測試用例文檔的關鍵內容，如編號、名稱等等自動導入管理資料庫，形成與測試用例文檔完全對應的記錄；第二、可供測試實施時及時輸入測試情況；第三、最終實現自動生成測試結果文檔，包含各測試度量值，測試覆蓋表和測試通過或不通過的測試用例清單列表。

有了管理軟體，測試人員無論是編寫每日的測試工作日誌、還是出軟體測試報告，都會變得輕而易舉。