確定測試用例之所以很重要，原因有以下幾方面。 1、測試用例構成了設計和制定測試過程的基礎。 2、測試的“深度”與測試用例的數量成比例。由于每個測試用例反映不同的場景、條件或經由產品的事件流，因而，隨著測試用例數量的增加，您對產品質量和測試流程也就越有信心。 3、判斷測試是否完全的一個主要評測方法是基于需求的覆蓋，而這又是以確定、實施和/或執行的測試用例的數量為依據的。類似下面這樣的說明：“95 % 的關鍵測試用例已得以執行和驗證”，遠比“我們已完成 95 % 的測試”更有意義。 4、測試工作量與測試用例的數量成比例。根據全面且細化的測試用例，可以更準確地估計測試周期各連續階段的時間安排。 5、測試設計和開發的類型以及所需的資源主要都受控于測試用例。 6、測試用例通常根據它們所關聯關系的測試類型或測試需求來分類，而且將隨類型和需求進行相應地改變。最佳方案是為每個測試需求至少編制兩個測試用例：
一個測試用例用于證明該需求已經滿足，通常稱作正面測試用例； 另一個測試用例反映某個無法接受、反�；蛞馔獾臈l件或數據，用于論證只有在所需條件下才能夠滿足該需求，這個測試用例稱作負面測試用例。
一、測試用例是軟件測試的核心
軟件測試的重要性是毋庸置疑的。但如何以最少的人力、資源投入，在最短的時間內完成測試，發現軟件系統的缺陷，保證軟件的優良品質，則是軟件公司探索和追求的目標。每個軟件產品或軟件開發項目都需要有一套優秀的測試方案和測試方法。
影響軟件測試的因素很多，例如軟件本身的復雜程度、開發人員（包括分析、設計、編程和測試的人員）的素質、測試方法和技術的運用等等。因為有些因素是客觀存在的，無法避免。有些因素則是波動的、不穩定的，例如開發隊伍是流動的，有經驗的走了，新人不斷補充進來；一個具體的人工作也受情緒等影響，等等。如何保障軟件測試質量的穩定？有了測試用例，無論是誰來測試，參照測試用例實施，都能保障測試的質量�？梢园讶藶橐蛩氐挠绊憸p少到最小。即便最初的測試用例考慮不周全，隨著測試的進行和軟件版本更新，也將日趨完善。
因此測試用例的設計和編制是軟件測試活動中最重要的。測試用例是測試工作的指導，是軟件測試的必須遵守的準則。更是軟件測試質量穩定的根本保障。
二、編制測試用例
著重介紹一些編制測試用例的具體做法。
1、測試用例文檔
編寫測試用例文檔應有文檔模板，須符合內部的規范要求。測試用例文檔將受制于測試用例管理軟件的約束。
軟件產品或軟件開發項目的測試用例一般以該產品的軟件模塊或子系統為單位，形成一個測試用例文檔，但并不是絕對的。
測試用例文檔由簡介和測試用例兩部分組成。簡介部分編制了測試目的、測試范圍、定義術語、參考文檔、概述等。測試用例部分逐一列示各測試用例。每個具體測試用例都將包括下列詳細信息：用例編號、用例名稱、測試等級、入口準則、驗證步驟、期望結果（含判斷標準）、出口準則、注釋等。以上內容涵蓋了測試用例的基本元素：測試索引，測試環境，測試輸入，測試操作，預期結果，評價標準。
2、測試用例的設置
我們早期的測試用例是按功能設置用例。后來引進了路徑分析法，按路徑設置用例。目前演變為按功能、路徑混合模式設置用例。
按功能測試是最簡捷的，按用例規約遍歷測試每一功能。
對于復雜操作的程序模塊，其各功能的實施是相互影響、緊密相關、環環相扣的，可以演變出數量繁多的變化。沒有嚴密的邏輯分析，產生遺漏是在所難免。路徑分析是一個很好的方法，其最大的優點是在于可以避免漏測試。
但路徑分析法也有局限性。在一個非常簡單字典維護模塊就存在十余條路徑。一個復雜的模塊會有幾十到上百條路徑是不足為奇的。筆者以為這是路徑分析比較合適的使用規模。若一個子系統有十余個或更多的模塊，這些模塊相互有關聯。再采用路徑分析法，其路徑數量成幾何級增長，達5位數或更多，就無法使用了。那么子系統模塊間的測試路徑或測試用例還是要靠傳統方法來解決。這是按功能、路徑混合模式設置用例的由來。
3、設計測試用例
測試用例可以分為基本事件、備選事件和異常事件。設計基本事件的用例，應該參照用例規約（或設計規格說明書），根據關聯的功能、操作按路徑分析法設計測試用例。而對孤立的功能則直接按功能設計測試用例�；臼录臏y試用例應包含所有需要實現的需求功能，覆蓋率達100%。
設計備選事件和異常事件的用例，則要復雜和困難得多。例如，字典的代碼是唯一的，不允許重復。測試需要驗證：字典新增程序中已存在有關字典代碼的約束，若出現代碼重復必須報錯，并且報錯文字正確。往往在設計編碼階段形成的文檔對備選事件和異常事件分析描述不夠詳盡。而測試本身則要求驗證全部非基本事件，并同時盡量發現其中的軟件缺陷。
可以采用軟件測試常用的基本方法：等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、邏輯覆蓋法等設計測試用例。視軟件的不同性質采用不同的方法。如何靈活運用各種基本方法來設計完整的測試用例，并最終實現暴露隱藏的缺陷，全憑測試設計人員的豐富經驗和精心設計。
三、測試用例在軟件測試中的作用
1、指導測試的實施
測試用例主要適用于集成測試、系統測試和回歸測試。在實施測試時測試用例作為測試的標準，測試人員一定要按照測試用例嚴格按用例項目和測試步驟逐一實施測試。并對測試情況記錄在測試用例管理軟件中，以便自動生成測試結果文檔。
根據測試用例的測試等級，集成測試應測試那些用例，系統測試和回歸測試又該測試那些用例，在設計測試用例時都已作明確規定，實施測試時測試人員不能隨意作變動。
2、規劃測試數據的準備
在我們的實踐中測試數據是與測試用例分離的。按照測試用例配套準備一組或若干組測試原始數據，以及標準測試結果。尤其象測試報表之類數據集的正確性，按照測試用例規劃準備測試數據是十分必須的。
除正常數據之外，還必須根據測試用例設計大量邊緣數據和錯誤數據。
3、編寫測試腳本的"設計規格說明書"
為提高測試效率，軟件測試已大力發展自動測試。自動測試的中心任務是編寫測試腳本。如果說軟件工程中軟件編程必須有設計規格說明書，那么測試腳本的設計規格說明書就是測試用例。
4、評估測試結果的度量基準
完成測試實施后需要對測試結果進行評估，并且編制測試報告。判斷軟件測試是否完成、衡量測試質量需要一些量化的結果。例：測試覆蓋率是多少、測試合格率是多少、重要測試合格率是多少，等等。以前統計基準是軟件模塊或功能點，顯得過于粗糙。采用測試用例作度量基準更加準確、有效。
5、分析缺陷的標準
通過收集缺陷，對比測試用例和缺陷數據庫，分析確證是漏測還是缺陷復現。漏測反映了測試用例的不完善，應立即補充相應測試用例，最終達到逐步完善軟件質量。而已有相應測試
用例，則反映實施測試或變更處理存在問題。
四、相關問題
1、測試用例的評審
測試用例是軟件測試的準則，但它并不是一經編制完成就成為準則。測試用例在設計編制過程中要組織同級互查。完成編制后應組織專家評審，需獲得通過才可以使用。評審委員會可由項目負責人、測試、編程、分析設計等有關人員組成，也可邀請客戶代表參加。
2、測試用例的修改更新
測試用例在形成文檔后也還需要不斷完善。主要來自三方面的緣故：第一、在測試過程中發現設計測試用例時考慮不周，需要完善；第二、在軟件交付使用后反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成；第三、軟件自身的新增功能以及軟件版本的更新，測試用例也必須配套修改更新。
一般小的修改完善可在原測試用例文檔上修改，但文檔要有更改記錄。軟件的版本升級更新，測試用例一般也應隨之編制升級更新版本。
3、測試用例的管理軟件
運用測試用例還需配備測試用例管理軟件。它的主要功能有三個：第一、能將測試用例文檔的關鍵內容，如編號、名稱等等自動導入管理數據庫，形成與測試用例文檔完全對應的記錄；第二、可供測試實施時及時輸入測試情況；第三、最終實現自動生成測試結果文檔，包含各測試度量值，測試覆蓋表和測試通過或不通過的測試用例清單列表。
有了管理軟件，測試人員無論是編寫每日的測試工作日志、還是出軟件測試報告，都會變得輕而易舉。
什么是軟件測試用例預演
測試用例預演是一種非正式的測試用例執行方法，概括說來，這種方法是無需通過測試用例的真正執行(靜態或是動態執行)，而只需要開發人員和測試人員之間的口頭交流，就能發現被測系統中存在的問題。設想一下，無需動手(測試執行)，通過以口代手(開發和測試人員之間的口頭交流)，就能實現我們的目標(發現缺陷)，這不是高手過招是什么?
測試用例預演的一般步驟是：
測試工程師與開發工程師以某種方式坐在一起，進入交流狀態，這個過程中需要盡可能避免干擾，比較好的時機是坐在一起進餐的時候;
測試工程師根據測試用例進行提問，甚至可以臨時擴展測試用例，但要注意三點：
1). 不要偏離測試用例太遠，以免偏離實際的業務;
2).可以考慮一些在測試用例中沒有明確寫明的異常情況處理;
3).提問的方式是“如果我這么操作，你的系統會如何反應?”;
開發工程師根據測試工程師的問題，做出應答，對每個問題都只需要回答系統的響應即可，不需要描述具體的實現方法;
測試工程師仔細聆聽開發工程師的回答，需要對開發工程師的答復敏銳反應，不放過任何一個開發人員的遲疑，對拿不準的問題應該記錄并需要馬上驗證;
雙方繼續預演直到預期的預演時間結束或是有一方感到疲倦;
記錄預演過程中發現的問題到缺陷跟蹤庫。
當然，要說明的是，參與交流的開發和測試工程師不是比武雙方，真正的敵人只有一個：系統的缺陷，這點務必要牢記，以免弄錯了對手，傷了和氣。
測試用例預演不是一種復雜的方法，但根據我的經驗，要想在實際工作中應用這種方法并取得較好的效果，必須了解這種方法的適用范圍，遵循一定的使用方法，并需要注意一定的技巧。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
