-
測試用例
鎖定
測試用例(Test Case)是指對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略。其內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，最終形成文檔。簡單地認為，測試用例是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，用於核實是否滿足某個特定軟件需求。
[1]
測試用例主要包含四個內容：用例標題，前置條件，測試步驟和預期結果。用例標題主要描述測試某項功能；前置條件是指用例標題需要滿足該條件；測試步驟主要描述用例的操作步驟；預期結果指的是符合預期（開發規格書、需求文檔、用户需求等）需求。
很多人都以為測試用例包含實際結果，其實是錯誤的想法。測試用例不包含實際結果，測試用例產生於測試之前，只有測試時，才會有實際結果，所以實際結果是不可能與測試用例同步產生。實際結果存在於BUG文檔，BUG文檔是根據測試用例測試完後生成的報告文檔。
- 中文名
- 測試用例
- 外文名
- Test Case
- 別 名
- 用例
- 作 用
- 測試輸入、執行條件以及預期結果
- 類 型
- 測試程序
測試用例簡介
測試用例
測試用例作用
⒈指導測試的實施
測試用例主要適用於集成測試、系統測試和迴歸測試。在實施測試時測試用例作為測試的標準，測試人員一定要按照測試用例嚴格按用例項目和測試步驟逐一實施測試。並對測試情況記錄在測試用例管理軟件中，以便自動生成測試結果文檔。
[2]
⒉規劃測試數據的準備
⒊編寫測試腳本的"設計規格説明書"
⒋評估測試結果的度量基準
完成測試實施後需要對測試結果進行評估，並且編制測試報告。判斷軟件測試是否完成、衡量測試質量需要一些量化的結果。例：測試覆蓋率是多少、測試合格率是多少、重要測試合格率是多少，等等。以前統計基準是軟件模塊或功能點，顯得過於粗糙。採用測試用例作度量基準更加準確、有效。
[2]
⒌分析缺陷的標準
通過收集缺陷，對比測試用例和缺陷數據庫，分析確證是漏測還是缺陷復現。漏測反映了測試用例的不完善，應立即補充相應測試用例，最終達到逐步完善軟件質量。而已有相應測試用例，則反映實施測試或變更處理存在問題。
[2]
測試用例重要性
軟件測試的重要性是毋庸置疑的。但如何以最少的人力、資源投入，在最短的時間內完成測試，發現軟件系統的缺陷，保證軟件的優良品質，則是軟件公司探索和追求的目標，每個軟件產品或軟件開發項目都需要有一套優秀的測試方案和測試方法。
[2]
影響軟件測試的因素很多，例如軟件本身的複雜程度、開發人員（包括分析、設計、編程和測試的人員）的素質、測試方法和技術的運用等。因為有些因素是客觀存在，無法避免的；有些因素則是波動的、不穩定的。例如開發隊伍是流動的，有經驗的開發人員走了，新人不斷補充進來；每個開發人員的工作也會受情緒影響，等等。有了測試用例，無論是誰來測試，參照測試用例實施，都能保障測試的質量，從而把人為因素小。即便最初的測試用例考慮不周全，隨着測試的進行和軟件版本更新，也將日趨完善。
[2]
(3)判斷測試是否完全的一個主要評測方法是基於需求的覆蓋，而這又是以確定、實施和/或執行的測試用例的數量為依據的。類似下面這樣的説明：“95%的關鍵測試用例已得以執行和驗證”，遠比“我們已完成95%的測試”更有意義。
[2]
(6)測試用例通常根據它們所關聯的測試類型或測試需求來分類，而且將隨類型和需求進行相應的改變。最佳方案是為每個測試需求至少編制兩個測試用例：一個測試用例用於證明該需求已經滿足，通常稱作正面測試用例；另一個測試用例反映某個無法接受、反常或意外的條件或數據，用於論證只有在所需條件下才能夠滿足該需求，這個測試用例稱作負面測試用例。
[2]
測試用例編制測試用例
測試用例測試用例文檔
測試用例文檔由簡介和測試用例兩部分組成。簡介部分編制了測試目的、測試範圍、定義術語、參考文檔、概述等。測試用例部分逐一列示各測試用例。每個具體測試用例都將包括下列詳細信息：版本號、模塊名稱、用例編號、用例名稱、用例級別、預知條件、驗證步驟、期望結果（含判斷標準）、測試結果、測試時間、測試人員等。
[2]
測試用例測試用例的設置
對於複雜操作的程序模塊，其各功能的實施是相互影響、緊密相關、環環相扣的，可以演變出數量繁多的變化。沒有嚴密的邏輯分析，產生遺漏是在所難免。路徑分析是一個很好的方法，其最大的優點是在於可以避免漏測試。
[2]
但路徑分析法也有侷限性。在一個非常簡單字典維護模塊就存在十餘條路徑。一個複雜的模塊會有幾十到上百條路徑是不足為奇的。筆者以為這是路徑分析比較合適的使用規模。若一個子系統有十餘個或更多的模塊，這些模塊相互有關聯。再採用路徑分析法，其路徑數量成幾何級增長，達5位數或更多，就無法使用了。那麼子系統模塊間的測試路徑或測試用例還是要靠傳統方法來解決。這是按功能、路徑混合模式設置用例的由來。
[2]
測試用例設計測試用例
測試用例可以分為基本事件、備選事件和異常事件。設計基本事件的用例，應該參照用例規約（或設計規格説明書），根據關聯的功能、操作按路徑分析法設計測試用例。而對孤立的功能則直接按功能設計測試用例。基本事件的測試用例應包含所有需要實現的需求功能，覆蓋率達100%。
[2]
設計備選事件和異常事件的用例，則要複雜和困難得多。例如，字典的代碼是唯 一的，不允許重複。測試需要驗證：字典新增程序中已存在有關字典代碼的約束，若出現代碼重複必須報錯，並且報錯文字正確。往往在設計編碼階段形成的文檔對備選事件和異常事件分析描述不夠詳盡。而測試本身則要求驗證全部非基本事件，並同時儘量發現其中的軟件缺陷。
[2]
可以採用軟件測試常用的基該方法：等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、邏輯覆蓋法等設計測試用例。視軟件的不同性質採用不同的方法。如何靈活運用各種基該方法來設計完整的測試用例，並最終實現暴露隱藏的缺陷，全憑測試設計人員的豐富經驗和精心設計。
[2]
測試用例測試用例設計
測試用例設計原則
測試用例是一個文檔，是執行的最小實體。測試用例包括輸入、動作、時間和一個期望的結果，其目的是確定應用程序的某個特性是否可正常工作，並且達到程序所設計的結果，以便測試某個程序路徑或核實是否滿足某個特定需求般在進行測試用例設計前要全面瞭解被測試產品的功能、明確測試範圍(特別是要明確哪些是不需要測試的)、具備基本的測試技術與方法等。測試用例設計一般遵循以下原則:
[3]
測試用例設計方法
1、白盒法
白盒法又稱結構化方法(結構測試)或邏輯覆蓋法，其基本思想是把程序看作是路徑的集合。這樣，對程序的測試便轉化為對程序中某些路徑的測試，要設法讓被測程序的“各處”均被執行到，使潛伏在程序每個角落的錯誤均有機會暴露出來。因此，白盒法實際上是一種選擇通過指定路徑的輸入數據的分析方法。
[4]
2、測試覆蓋率
此外，還有諸如路徑覆蓋(程序中每條路徑至少執行一次)、基本路徑覆蓋(循環次數只考慮小於等於一次所組成的程序路徑，每條基本路徑至少執行一次)等。為了獲取測試覆蓋率(不論是哪一種覆蓋率)需要有測試工具的幫助，且需要花費人力與機時去做測試工作(設計測試用例、輸入測試數據、進行統計計算等)。
[4]
3、黑盒法
黑盒法又稱為功能測試，是根據軟件需求説明書上羅列的各項功能、性能指標，來構造測試用例的輸入數據，實際執行被測軟件，分析執行過程的行為與執行結果以便檢查出被測軟件的錯誤。在黑盒法測試中，測試者可以完全不關心程序的內部結構。可見，白盒法是一種邏輯驅動方法，而黑盒法是一種功能驅動方法。黑盒法是最常用的測試方法。
[4]
測試用例相關問題
⒈測試用例的評審
測試用例是軟件測試的準則，但它並不是一經編制完成就成為準則。測試用例在設計編制過程中要組織同級互查。完成編制後應組織專家評審，需獲得通過才可以使用。評審委員會可由項目負責人、測試、編程、分析設計等有關人員組成，也可邀請客户代表參加。
[2]
⒉測試用例的修改更新
測試用例在形成文檔後也還需要不斷完善。主要來自三方面的緣故：第一、在測試過程中發現設計測試用例時考慮不周，需要完善；第二、在軟件交付使用後反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成；第三、軟件自身的新增功能以及軟件版本的更新，測試用例也必須配套修改更新。
[2]
⒊測試用例的管理軟件
