軟件測試用例的認識誤區及如何設計編寫和設計軟件測試用例
軟件測試用例是為了有效發現軟件缺陷而編寫的包含測試目的、測試步驟、期望測試結果的特定集合。正確認識和設計軟件測試用例可以提高軟件測試的有效性，便于測試質量的度量，增強測試過程的可管理性。
在實際軟件項目測試過程中，由于對軟件測試用例的作用和設計方法的理解不同，測試人員（特別是剛從事軟件測試的新人）對軟件測試用例存在不少錯誤的認識，給實際軟件測試帶來了負面影響，本文對這些認識誤區進行列舉和剖析。
誤區之一：測試輸入數據設計方法等同于測試用例設計方法
現在一些測試書籍和文章中講到軟件測試用例的設計方法，經常有這樣的表述：測試用例的設計方法包括：等價類、邊界值、因果圖、錯誤推測法、場景設計法等。這種表述是很片面的，這些方法只是軟件功能測試用例設計中如何確定測試輸入數據的方法，而不是測試用例設計的全部內容。
這種認識的不良影響可能會使不少人認為測試用例設計就是如何確定測試的輸入數據，從而掩蓋了測試用例設計內容的豐富性和技術的復雜性。如果測試用例設計人員把這種認識拿來要求自己，則害了自己；拿來教人，則害了別人；拿來指導測試，則害了測試團隊。聽起來似乎是“小題大做”，但是絕不是“危言聳聽”。
無疑，對于軟件功能測試和性能測試，確定測試的輸入數據很重要，它決定了測試的有效性和測試的效率。但是，測試用例中輸入數據的確定方法只是測試用例設計方法的一個子集，除了確定測試輸入數據之外，測試用例的設計還包括如何根據測試需求、設計規格說明等文檔確定測試用例的設計策略、設計用例的表示方法和組織管理形式等問題。
在設計測試用例時，需要綜合考慮被測軟件的功能、特性、組成元素、開發階段（里程碑）、測試用例組織方法（是否采用測試用例的數據庫管理）等內容。具體到設計每個測試用例而言，可以根據被測模塊的最小目標，確定測試用例的測試目標；根據用戶使用環境確定測試環境；根據被測軟件的復雜程度和測試用例執行人員的技能確定測試用例的步驟；根據軟件需求文檔和設計規格說明確定期望的測試用例執行結果。
誤區之二：強調測試用例設計得越詳細越好
在確定測試用例設計目標時，一些項目管理人員強調測試用例“越詳細越好”。具體表現在兩個方面：盡可能設計足夠多的設計用例，測試用例的數量閱讀越好；測試用例盡可能包括測試執行的詳細步驟，達到“任何一個人都可以根據測試用例執行測試”，追求測試用例越詳細越好。
這種做法和觀點最大的危害就是耗費了很多的測試用例設計時間和資源，可能等到測試用例設計、評審完成后，留給實際執行測試的時間所剩無幾了。因為當前軟件公司的項目團隊在規劃測試階段，分配給測試的時間和人力資源是有限的，而軟件項目的成功要堅持“質量、時間、成本”的最佳平衡，沒有足夠多的測試執行時間，就無法發現更多的軟件缺陷，測試質量更無從談起了。
編寫測試用例的根本目的是有效地找出軟件可能存在的缺陷，為了達到這個目的，需要分析被測試軟件的特征，運用有效的測試用例設計方法，盡量使用較少的測試用例，同時滿足合理的測試需求覆蓋，從而達到“少花時間多辦事”的效果。
測試用例中的測試步驟需要詳細到什么程度，主要取決于測試用例的“最終用戶”（即執行這些測試用例的人員），以及測試用例執行人員的技能和產品熟悉程度。如果編寫測試用例的人員也是測試用例執行人員，或者測試用例的執行人員深刻了解被測軟件，測試用例就沒有必要太詳細。而如果是測試新人執行測試用例，或者軟件測試外包給獨立的第三方公司，那么測試用例的執行步驟最好足夠詳細。
接下來教大家一下如何設計編寫和設計軟件測試用例
一、測試用例是軟件測試的核心
軟件測試的重要性是毋庸置疑的。但如何以最少的人力、資源投入，在最短的時間內完成測試，發現軟件系統的缺陷，保證軟件的優良品質，則是軟件公司探索和追求的目標。每個軟件產品或軟件開發項目都需要有一套優秀的測試方案和測試方法。
影響軟件測試的因素很多，例如軟件本身的復雜程度、開發人員（包括分析、設計、編程和測試的人員）的素質、測試方法和技術的運用等等。因為有些因素是客觀存在的，無法避免。有些因素則是波動的、不穩定的，例如開發隊伍是流動的，有經驗的走了，新人不斷補充進來；一個具體的人工作也受情緒等影響，等等。如何 保障軟件測試質量的穩定？有了測試用例，無論是誰來測試，參照測試用例實施，都能保障測試的質量�？梢园讶藶橐蛩氐挠绊憸p少到最小。即便最初的測試用例考慮不周全，隨著測試的進行和軟件版本更新，也將日趨完善。
因此測試用例的設計和編制是軟件測試活動中最重要的。測試用例是測試工作的指導，是軟件測試的必須遵守的準則，更是軟件測試質量穩定的根本保障。
二、什么叫測試用例
測試用例（Test Case）目前沒有經典的定義。比較通常的說法是：指對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略，內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，并形成文檔。
不同類別的軟件，測試用例是不同的。不同于諸如系統、工具、控制、游戲軟件，管理軟件的用戶需求更加不統一，變化更大、更快。筆者主要從事企業管理軟件的測試。因此我們的做法是把測試數據和測試腳本從測試用例中劃分出來。測試用例更趨于是針對軟件產品的功能、業務規則和業務處理所設計的測試方案。對軟件的 每個特定功能或運行操作路徑的測試構成了一個個測試用例。
三、編寫測試用例
著重介紹一些編寫測試用例的具體做法。
1、測試用例文檔
編寫測試用例文檔應有文檔模板，須符合內部的規范要求。測試用例文檔將受制于測試用例管理軟件的約束。
軟件產品或軟件開發項目的測試用例一般以該產品的軟件模塊或子系統為單位，形成一個測試用例文檔，但并不是絕對的。
測試用例文檔由簡介和測試用例兩部分組成。簡介部分編制了測試目的、測試范圍、定義術語、參考文檔、概述等。測試用例部分逐一列示各測試用例。每個具體測試用例都將包括下列詳細信息：用例編號、用例名稱、測試等級、入口準則、驗證步驟、期望結果（含判斷標準）、出口準則、注釋等。以上內容涵蓋了測試用例的 基本元素：測試索引，測試環境，測試輸入，測試操作，預期結果，評價標準。
2、測試用例的設置
我們早期的測試用例是按功能設置用例。后來引進了路徑分析法，按路徑設置用例。目前演變為按功能、路徑混合模式設置用例。
3、按功能測試是最簡捷的，按用例規約遍歷測試每一功能。
對于復雜操作的程序模塊，其各功能的實施是相互影響、緊密相關、環環相扣的，可以演變出數量繁多的變化。沒有嚴密的邏輯分析，產生遺漏是在所難免。路徑分析是一個很好的方法，其最大的優點是在于可以避免漏測試。
為提高測試效率，軟件測試已大力發展自動測試。自動測試的中心任務是編寫測試腳本。如果說軟件工程中軟件編程必須有設計規格說明書，那么測試腳本的設計規格說明書就是測試用例。
4、評估測試結果的度量基準
完成測試實施后需要對測試結果進行評估，并且編制測試報告。判斷軟件測試是否完成、衡量測試質量需要一些量化的結果。例：測試覆蓋率是多少、測試合格率是多少、重要測試合格率是多少，等等。以前統計基準是軟件模塊或功能點，顯得過于粗糙。采用測試用例作度量基準更加準確、有效。
5、分析缺陷的標準
通過收集缺陷，對比測試用例和缺陷數據庫，分析確證是漏測還是缺陷復現。漏測反映了測試用例的不完善，應立即補充相應測試用例，最終達到逐步完善軟件質量。而已有相應測試用例，則反映實施測試或變更處理存在問題。
五、相關問題
1、測試用例的評審
測試用例是軟件測試的準則，但它并不是一經編制完成就成為準則。測試用例在設計編制過程中要組織同級互查。完成編制后應組織專家評審，需獲得通過才可以使用。評審委員會可由項目負責人、測試、編程、分析設計等有關人員組成，也可邀請客戶代表參加。
2、測試用例的修改更新
測試用例在形成文檔后也還需要不斷完善。主要來自三方面的緣故：第一、在測試過程中發現設計測試用例時考慮不周，需要完善；第二、在軟件交付使用后反饋的軟件缺陷，而缺陷又是因測試用例存在漏洞造成；第三、軟件自身的新增功能以及軟件版本的更新，測試用例也必須配套修改更新。
一般小的修改完善可在原測試用例文檔上修改，但文檔要有更改記錄。軟件的版本升級更新，測試用例一般也應隨之編制升級更新版本。
3、測試用例的管理軟件
運用測試用例還需配備測試用例管理軟件。它的主要功能有三個：第一、能將測試用例文檔的關鍵內容，如編號、名稱等等自動導入管理數據庫，形成與測試用例文檔完全對應的記錄；第二、可供測試實施時及時輸入測試情況；第三、最終實現自動生成測試結果文檔，包含各測試度量值，測試覆蓋表和測試通過或不通過的測試 用例清單列表。
有了管理軟件，測試人員無論是編寫每日的測試工作日志、還是出軟件測試報告，都會變得輕而易舉。
文章來源于領測軟件測試網 http://www.anti-gravitydesign.com/
