debug 標準 產品 發現 子集 格式 人在 bug 最重要的

　　測試用例（Test Case）是為某個特殊目標而編制的一組測試輸入、執行條件以及預期結果，以便測試某個程序路徑或核實是否滿足某個特定需求，是軟件測試人員需要具備的基礎能力。 　　好用例的標準 　　/是否可以發現Bug 　　設計測試用例的目的就是為了發現bug，如果bug都發現不了，怎麽能稱得上是一個好的測試用例呢？ 　　/是否夠高效 　　一個好的測試用例應該不止測試一個測試點，從而減少需要的用例總量。但也不能包含太多不想關的測試點，否則你這個用例就沒法測試了，並且給開發的debug造成困難。 　　/是否夠經濟 　　這個測試用例執行起來是否容易，分析和debug是否要花太多代價，都是值得考慮的，畢竟咱也要站在組織的角度來看待測試這個事，公司是為了盈利而做這些事，而不是為了做測試而測試。 　　/是否有足夠的擴展性 　　主要是考察測試用例在維護時是否要花費很大的代價。 　　測試用例的好處 　　/理清思路，避免遺漏 　　這裏是我們認為最重要的一點，假如我們測試的項目大而復雜，我們可以把項目功能細分，根據每一個功能通過編寫用例的方式來整理我們測試系統的思路，避免遺漏掉要測試的功能點。 　　/跟蹤測試進展 　　通過編寫測試用例，執行測試用例，我們可以很清楚的知道我們的測試進度。 　　/歷史參考 　　在我們所做的項目中，也許會有很多功能是相同或相近的，我們對這類功能設計了測試用例，便於以後我們遇到類似功能的時候可以做參考依據。 　　/重復性 　　我們測試一個系統不是一個人測一遍就算測完的，需要多人反復的進行測試，那麽我們就需要測試用例來規範和指導我們的測試行為。 　　測試用例方法 　　/等價類劃分 　　在某個輸入域的子集合，在該子集合中，各個輸入數據對於揭露程序中的錯誤都是等價的。 　　假如有一個輸入框要求輸入1-10000個數，我們不可能用每一個數去試，我們輸入5 和輸入6去驗證和揭露輸入框的錯誤可以看做是等價的。 　　那麽這個時候我們就可以隨機的抽取一些數據來進行驗證。如：10 、99、7777...... 　　等價類分：有效等價類和無效等價類 　　輸入框要求輸入1-10000的數 　　有效等價類：可以輸入1-10000之間的數來驗證，如：2、5、99、8495...... 　　無效等價類：可以輸入1-10000之外的任意字符驗證，如：20000、字母、下劃線、特殊符號、空格、回車..... 　　/邊界值 　　邊界值是對等價類的補充，測試工作經驗告訴我們，大量的錯誤是出在輸入輸出的邊界價上。 　　我們還拿上面的例子，一個輸入框要求輸入1-10000之間的數。 　　我們要測它有沒有超出這個範圍，如：0、-1、-2、1000、10001.....等等，來判定是否超出了我們的範圍。 　　 /因果圖 　　因果圖方法最終生成的就是判定表，它適合於檢查程序輸入條件的各種組合情況。舉個例子：原因：A=0，B=0，結果我就可以判定：A=B。 　　確切的說他是一種因果關系思想。它會無形中指導這我們的測試。 　　當然了，我們為了以免遺漏，可以把系統中的因果關系用圖畫出。不過系統大而復雜的話就是個體力活了。 　　/錯誤推測法 　　基於經驗和直覺推測出系統可能存在的錯誤，從而有針對性的設計測試用例的方法。 　　 /其它 　　設計測試用例的方法有很多，我們常用就上面幾種，其它的方法還有：狀態遷移圖、流程分析法、正交驗證法等等。 　　測試用例的格式與要素 　　 一個測試用例應該包括：編號，標題，測試場景，測試步驟，預期結果。 　　 當然還可加入一些它選項，如：優先級、測試階段.... 　　舉例： 　　上面的格式取自《微軟的軟件測試之道》，僅供大家參考，一般項目管理系統自帶的用例管理，有固定的格式，搜索、修改等功能，使用起來非常方便。 　　如：禪道項目管理、QC、bugfree 等等都帶的有用例管理功能。 　　測試用例開始設計最優時間 　　當根據客戶的需求整理出項目需求分析文檔時，我們就可以根據需求文檔來編寫測試用例了。但是，一般我們（國內大多小公司）項目需求文檔都非常“簡陋”，所以，很難根據需求文檔設計測試用例。 　　我們只有等到項目開發人員把項目開發出來，給我們系統文檔、部署環境、數據庫

結構（如果系統牽涉到數據庫的話），我們根絕這些文檔來設計測試用例。 　　什麽情況下不適合寫測試用例 　　/性價比低 　　如果一個功能我很快就測試完了，而且只需要測試一遍，但我們設計測試用例時卻比較麻煩，花時間也長。 　　這個時候就沒必要編寫測試用例了。 　　/需求變動大且頻繁 　　需求的功能變動非常頻繁，而且變動很大，之前編寫的測試用例根本沒法使用，必須要重新編寫，這個時候不建議自己做， 　　建議選擇第三方測試機構幫忙，比如類似Testin的眾包測試服務。 　　融入探索性測試思維 　　完全的執行測試用例時一件非常枯燥的事情，個人在執行測試用例時會做一些，其它的非常規性的操作，看系統是否會有相應的處理和提示。 　　我的一部分bug就是再這種非常規操作下發現的。 　　當然了真正的探索性測試需要對產品的深入了解，以及軟件開發技術有一定的深度和寬度。 轉自：http://www.jianshu.com/p/6fd4be540d37

好的測試用例是怎麽寫出來的？