淺說《測試用例》----給測試新手的

　　一、什么是測試用例?

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

　　通俗的講：就是把我們測試系統的操作步驟用按照一定的格式用文字描述出來。

　　二、寫測試用例有什么好處?

　　理清思路，避免遺漏

　　這里是我們認為最重要的一點，假如我們測試的項目大而復雜，我們可以把項目功能細分，根據每一個功能通過編寫用例的方式來整理我們測試系統的思路，避免遺漏掉要測試的功能點。

　　跟蹤測試進展

　　通過編寫測試用例，執行測試用例，我們可以很清楚的知道我們的測試進度。

　　歷史參考

　　在我們所做的項目中，也許會有很多功能是相同或相近的，我們對這類功能設計了測試用例，便于以后我們遇到類似功能的時候可以做參考依據。

　　重復性

　　我們測試一個系統不是一個人測一遍就算測完的，需要多人反復的進行測試，那么我們就需要測試用例來規范和指導我們的測試行為。

　　告訴領導，這事俺干過，不然別人怎么知道你測沒測，測的全面不全面，拿測試用例給他們看唄!俺就是照著這個干活，呵呵!

　　三、測試用例的方法

　　好吧，咱知道啥是測試用例了，也是知道為什么要寫測試用例了，那到底應該怎么寫?無從下手啊。我們在寫測試用例之前，先學習幾種方法，它是我們寫測試用例的指導思想。

　　1. 等價類劃分

　　在某個輸入域的子集合，在該子集合中，各個輸入數據對于揭露程序中的錯誤都是等價的。假如有一個輸入框要求輸入1-10000個數，我們不可能用每一個數去試，我們輸入5 和輸入6去驗證和揭露輸入框的錯誤可以看做是等價的。那么這個時候我們就可以隨機的抽取一些數據來進行驗證。如：10 、99、7777......

　　等價類分：有效等價類和無效等價類

　　輸入框要求輸入1-10000的數

　　有效等價類：可以輸入1-10000之間的數來驗證，如：2、5、99、8495......

　　無效等價類：可以輸入1-10000之外的任意字符驗證，如：20000、字母、下劃線、特殊符號、空格、回車.....

　　2. 邊界值

　　邊界值是對等價類的補充，測試工作經驗告訴我們，大量的錯誤是出在輸入輸出的邊界價上。我們還拿上面的例子，一個輸入框要求輸入1-10000之間的數。我們要測它有沒有超出這個范圍，如：0、-1、-2、1000、10001.....等等，來判定是否超出了我們的范圍。

　　3. 因果圖

　　因果圖方法最終生成的就是判定表，它適合于檢查程序輸入條件的各種組合情況。舉個例子：原因：A=0，B=0，結果我就可以判定：A=B。確切的說他是一種因果關系思想。它會無形中指導這我們的測試。當然了，我們為了以免遺漏，可以把系統中的因果關系用圖畫出。不過系統大而復雜的話就是個體力活了。呵呵。

　　4. 錯誤推測法

　　基于經驗和直覺推測出系統可能存在的錯誤，從而有針對性的設計測試用例的方法。

　　5. 其它

　　設計測試用例的方法有很多，我們常用就上面幾種，其它的方法還有：狀態遷移圖、流程分析法、正交驗證法等等。

　　四、測試用例的格式與要素

　　一個測試用例應該包括：編號，標題，測試場景，測試步驟，預期結果。

　　當然還可加入一些它選項，如：優先級、測試階段....

　　注：上面的格式取自《微軟的軟件測試之道》，它并不一定適合你，我只是讓大家對測試格式有個了解。

　　關于測試用例的存放管理：

　　1. 項目管理系統自帶的用例管理，一般用例會與項目掛鉤，有固定的格式，搜索、修改等功能，使用起來非常方便。如：禪道項目管理、QC、bugfree 等等都帶的有用例管理功能。

　　2. 通過world\Excel文檔形式管理，這樣的好處就是自己定義測試用例的格式。

　　-----------------------測試用例例子--------------------------------------------------------

　　基礎知識了解的差不多了，下面來看一個具體的測試用例。我們會有更深刻的認識。

　　注：這不是一個完整的測試用例，格式也不是固定必須這樣的，你們可以根據自己的需求編寫設計測試用例。

　　==========================================================================

　　------------------------------------我們還需要知道的，關于測試用例的-------------------------------

　　一、.我們在什么時候可以設計測試用例?

　　當根據客戶的需求整理出項目需求分析文檔時，我們就可以根據需求文檔來編寫測試用例了。但是，一般我們(國內大多小公司)項目需求文檔都非常“簡陋”，所以，很難根據需求文檔設計測試用例。

　　我們只有等到項目開發人員把項目開發出來，給我們系統文檔、部署環境、數據庫結構(如果系統牽涉到數據庫的話)，我們根絕這些文檔來設計測試用例。

　　二、測試用例的評審與更新

　　我們設計的測試用例設計完成之后，是否完整?是否符合系統?符合客戶要求?對用例做一個評審是必不可少。關于評審的方式，不同的公司有不同的流程。

　　我們編寫的測試用例也不是經過評審之后就不變了，隨著需求的變更、功能的改進，測試用例當然也需要更新和變動。

　　三、什么情況下不適合寫測試用例

　　文件時間

　　如果一個功能我很快就測試完了，而且只需要測試一遍，但我們設計測試用例時卻比較麻煩，花時間也長。這個時候就沒必要編寫測試用例了。

　　需求變動大且頻繁

　　需求的功能變動非常頻繁，而且變動很大，之前編寫的測試用例根本沒法使用，必須要重新編寫，這個時候也沒必要去設計測試用例了。

原文轉自：http://www.anti-gravitydesign.com