如何編寫測試用例及測試用例的編寫方法 軟件測試
如何編寫測試用例
測試工作也從簡單測試演變為包括：編制測試計劃、編寫測試用例、準備測試數據、編寫測試腳本、實施測試、測試評估等多項內容的正規測試。測試方式則由單純手工測試發展為手工、自動兼之，并有向第三方專業測試公司發展的趨勢。
一、測試用例是軟件測試的核心
軟件測試的重要性是毋庸置疑的。但如何以最少的人力、資源投入，在最短的時間內完成測試，發現軟件系統的缺陷，保證軟件的優良品質，則是軟件公司探索和追求的目標。每個軟件產品或軟件開發項目都需要有一套優秀的測試方案和測試方法。
影響軟件測試的因素很多，例如軟件本身的復雜程度、開發人員（包括分析、設計、編程和測試的人員）的素質、測試方法和技術的運用等等。因為有些因素是客觀存在的，無法避免。有些因素則是波動的、不穩定的，例如開發隊伍是流動的，有經驗的走了，新人不斷補充進來；一個具體的人工作也受情緒等影響，等等。如何保障軟件測試質量的穩定？有了測試用例，無論是誰來測試，參照測試用例實施，都能保障測試的質量�？梢园讶藶橐蛩氐挠绊憸p少到最小。即便最初的測試用例考慮不周全，隨著測試的進行和軟件版本更新，也將日趨完善。
因此測試用例的設計和編制是軟件測試活動中最重要的。測試用例是測試工作的指導，是軟件測試的必須遵守的準則。更是軟件測試質量穩定的根本保障。
二、什么叫測試用例
測試用例（Test Case）目前沒有經典的定義。比較通常的說法是：指對一項特定的軟件產品進行測試任務的描述，體現測試方案、方法、技術和策略。內容包括測試目標、測試環境、輸入數據、測試步驟、預期結果、測試腳本等，并形成文檔。
不同類別的軟件，測試用例是不同的。不同于諸如系統、工具、控制、游戲軟件，管理軟件的用戶需求更加不統一，變化更大、更快。筆者主要從事企業管理軟件的測試。因此我們的做法是把測試數據和測試腳本從測試用例中劃分出來。測試用例更趨于是針對軟件產品的功能、業務規則和業務處理所設計的測試方案。對軟件的每個特定功能或運行操作路徑的測試構成了一個個測試用例。
三、編制測試用例
著重介紹一些編制測試用例的具體做法。
1、測試用例文檔
編寫測試用例文檔應有文檔模板，須符合內部的規范要求。測試用例文檔將受制于測試用例管理軟件的約束。
軟件產品或軟件開發項目的測試用例一般以該產品的軟件模塊或子系統為單位，形成一個測試用例文檔，但并不是絕對的。
測試用例文檔由簡介和測試用例兩部分組成。簡介部分編制了測試目的、測試范圍、定義術語、參考文檔、概述等。測試用例部分逐一列示各測試用例。每個具體測試用例都將包括下列詳細信息：用例編號、用例名稱、測試等級、入口準則、驗證步驟、期望結果（含判斷標準）、出口準則、注釋等。以上內容涵蓋了測試用例的基本元素：測試索引，測試環境，測試輸入，測試操作，預期結果，評價標準。
2、測試用例的設置
我們早期的測試用例是按功能設置用例。后來引進了路徑分析法，按路徑設置用例。目前演變為按功能、路徑混合模式設置用例。
按功能測試是最簡捷的，按用例規約遍歷測試每一功能。
對于復雜操作的程序模塊，其各功能的實施是相互影響、緊密相關、環環相扣的，可以演變出數量繁多的變化。沒有嚴密的邏輯分析，產生遺漏是在所難免。路徑分析是一個很好的方法，其最大的優點是在于可以避免漏測試。
但路徑分析法也有局限性。在一個非常簡單字典維護模塊就存在十余條路徑。一個復雜的模塊會有幾十到上百條路徑是不足為奇的。筆者以為這是路徑分析比較合適的使用規模。若一個子系統有十余個或更多的模塊，這些模塊相互有關聯。再采用路徑分析法，其路徑數量成幾何級增長，達5位數或更多，就無法使用了。那么子系統模塊間的測試路徑或測試用例還是要靠傳統方法來解決。這是按功能、路徑混合模式設置用例的由來。
3、設計測試用例
測試用例可以分為基本事件、備選事件和異常事件。設計基本事件的用例，應該參照用例規約（或設計規格說明書），根據關聯的功能、操作按路徑分析法設計測試用例。而對孤立的功能則直接按功能設計測試用例�；臼录臏y試用例應包含所有需要實現的需求功能，覆蓋率達100%。
設計備選事件和異常事件的用例，則要復雜和困難得多。例如，字典的代碼是唯一的，不允許重復。測試需要驗證：字典新增程序中已存在有關字典代碼的約束，若出現代碼重復必須報錯，并且報錯文字正確。往往在設計編碼階段形成的文檔對備選事件和異常事件分析描述不夠詳盡。而測試本身則要求驗證全部非基本事件，并同時盡量發現其中的軟件缺陷。
可以采用軟件測試常用的基本方法：等價類劃分法、邊界值分析法、錯誤推測法、因果圖法、邏輯覆蓋法等設計測試用例。視軟件的不同性質采用不同的方法。如何靈活運用各種基本方法來設計完整的測試用例，并最終實現暴露隱藏的缺陷，全憑測試設計人員的豐富經驗和精心設計。
測試用例的編寫方法
首先聲明這不是我寫的，我只是看到了感覺不錯就貼出來，希望對其他人有所幫助。向原作者表示致敬。
試用例的編寫，
對于每一個Tester來說都是不可避免的，平時很一部分的工作內容就是編寫測試用例，如何寫一個好的用例呢？如果你的
用例只是用于ISO的審核，那沒必要再這里探討這個問題。好的Case，是Tester的勞動成果，它應該是充滿智慧的，具有
可復用性，啟發性，能充分體現一個Tester的水平。很多人的Case雖然寫的很不錯，可惜只有他自己才能看懂其中的內
容和體會Case的意思，為什么？因為它寫的Case描述不清楚，只有他自己看了才明白，一個好的Case必須有良好的書
寫格式與習慣，能讓所有看的人都能理解，也就是說，當你離開這個項目，其他人來接受你的工作時，只要看你的Case
就能明白項目的目標與需求。如果做到這一點呢？ 第一步，我想應該是Case格式的確立，擁有好的，清晰的格式，有
利于幫助Tester來組織他的Case，會讓你事半功倍，反之亦然，一個結構不合理的格式，會讓你覺得蹩手蹩腳，影響你
的發揮。如果選擇一個良好的結構，要根據具體工作的情況，項目的結構，以及用例的目標（功能測試用例，性能測試用
例以及其他）我認為不同的測試手段要使用不同的用例結構。確定好這些因素后，在來談談測試用例中涉及到的一些東
西，理解Case所需要的東西，我認為這些東西是比不可少的，1：軟件版本編號。2：測試用例編號，編號的格式可根據
軟件版本號+用例號來確定，這樣不會應為Case的日積越累或軟件版本的不停升級而混亂。3：用例的優先級，在一個時
間緊湊的測試環境下，為了跟效率的完成測試用例，我們所能做的是完成那些優先級高的用例，至于優先級如何來確定，
可以根據項目需求，或者用戶那邊的需求來確定，也可以根據實際經驗對那些很容易產生缺陷的模塊設置為高優先級。
4：用例步驟。5：輸入數據。 6：實際輸出數據。7：期望輸出數據。某個步驟下，輸入了某條數據，你期望程序會輸出
什么數據�？梢砸粊砜梢耘c實際輸出的數據相比較。8：備注。為什么要備注，可能你在思考這個Case的時候有一個好的
點子或者思路，可以寫在備注里面�；蛘邔@個用例還有一些必要的補充說明等。9：測試環境。10：用例編寫人/日期。
11：測試執行者/日期�？赡芨鶕煌捻椖窟�需要一些補充，可以根據具體情況具體分析。 第二步。設計測試用例，通
常情況下在你編寫測試用例之前，你必須要有一個測試計劃，這里我只討論測試用例。嗯，開始設計之前還有一些準備工
作，必須熟讀軟件需求說明，一定要清晰的了解每一條需求，明白軟件的性能指標，綜合考慮測試環境，人員配置，要根
據自己的實際能力，測試工具使用狀況寫出符合自己測試團隊的用例。用例的劃分有很多種方法，根據測試的類型，比如
功能性測試，你可以按照功能模塊劃分用例，劃分科學的模塊你可以組織這些用例直接進行集成測試，組合部分模塊或者
所有模塊來測試。性能測試，可以根據性能指標來確定用例劃分，對于用例環境的不同來劃分用例等等。也可以根據測試
工具在組織測試用例，比如那些Case可以在測試工具上完成，那些需要手動去完成，劃分的方法很多，但是有一點必須
保證，就是測試覆蓋率，是否覆蓋了所有的需求。寫好一個用例，需要工作經驗的積累，需要對項目需求的了解，我覺得
Tester應該是公司里最了解軟件需求與功能的人。測試的技術很多，可以在Case中體現出來，比如說邊界值測試，溢出
測試，等價類劃分測試法，等等。按照這些來編寫你的Case也可以提高你的技能。 第二步。審核你的Test Case，怎么
樣才能完美你的Case呢？最好的辦法就是進行同行評審，也就是讓你的同事來看你的Case，同時與開發部門負責人進行
溝通，討論你的Case。進行這兩步后可能要對你的Case進行一些修改。但并不是這樣一個好的Case就產生了，在執行
測試用例的過程中，你可能還會發現很多問題，這也是一個Case的完善過程。對于從一個項目中成長起來的Tester，會
隨著對項目的不停理解與思考而隨時修改自己的Case，我是這樣理解的。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
