測試用例

出自 MBA智库百科(https://wiki.mbalib.com/)

測試用例（Test Case）

　　測試用例是指為某個特殊目標而編製的一組測試輸入、執行條件以及預期結果，以便測試某個程式路徑或核實是否滿足某個特定需求。

　　測試用例是將軟體測試的行為活動做一個科學化的組織歸納，目的是能夠將軟體測試的行為轉化成可管理的模式；同時測試用例也是將測試具體量化的方法之一，不同類別的軟體，測試用例是不同的。不同於諸如系統、工具、控制、游戲軟體，管理軟體的用戶需求更加不同的趨勢。

　　測試用例反映了要核實的需求。然而，核實這些需求可能通過不同的方式並由不同的測試員來實施。例如，執行軟體以便驗證它的功能和性能，這項操作可能由某個測試員採用自動測試技術來實現；電腦系統的關機步驟可通過手工測試和觀察來完成；不過，市場占有率和銷售數據（以及產品需求），只能通過評測產品和競爭銷售數據來完成。

　　既然可能無法（或不必負責）核實所有的需求，那麼是否能為測試挑選最適合或最關鍵的需求則關係到項目的成敗。選中要核實的需求將是對成本、風險和對該需求進行核實的必要性這三者權衡考慮的結果。

　　一般測試用例的編製包括：

　　1、測試用例文檔

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

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

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

　　2、測試用例的設置

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

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

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

　　3、設計測試用例

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

　　判斷測試是否完全的一個主要評測方法是基於需求的覆蓋，而這又是以確定、實施和/或執行的測試用例的數量為依據的。測試工作量與測試用例的數量成比例。根據全面且細化的測試用例，可以更準確地估計測試周期各連續階段的時間安排。測試設計和開發的類型以及所需的資源主要都受控於測試用例。

　　測試用例通常根據它們所關聯關係的測試類型或測試需求來分類，而且將隨類型和需求進行相應地改變。最佳方案是為每個測試需求至少編製兩個測試用例：

　　1、一個測試用例用於證明該需求已經滿足，通常稱作正面測試用例；

　　2、一個測試用例反映某個無法接受、反常或意外的條件或數據，用於論證只有在所需條件下才能夠滿足該需求，這個測試用例稱作負面測試用例。

　　影響軟體測試的因素很多，例如軟體本身的複雜程度、開發人員（包括分析、設計、編程和測試的人員）的素質、測試方法和技術的運用等等。因為有些因素是客觀存在的，無法避免。有些因素則是波動的、不穩定的。而測試用例是參照測試用例實施，能保障測試的質量。因此測試用例的設計和編製是軟體測試活動中最重要的。測試用例是測試工作的指導，是軟體測試的必須遵守的準則。更是軟體測試質量穩定的根本保障。

　　1、指導測試的實施

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

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

　　2、規劃測試數據的準備

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

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

　　3、編寫測試腳本的“設計規格說明書”

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

　　4、評估測試結果的度量基準

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

　　5、分析缺陷的標準

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

　　1、測試用例的評審

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

　　2、測試用例的修改更新

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

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

　　3、測試用例的管理軟體

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