測試用例這種東西對于剛入行的人來說是一種誘惑，初入測試的人急于掌握這門學問，所以一開始就會問測試用例怎么寫，問的同時或許還包含了一些期望。其實測試用例就是一個測試矩陣，任何人沒有必要注重形式問題，如果你現在或者未來的公司有套非常完善的文檔管理體系，那么你可以參考標準模版，如果沒有你們大可跟我一樣使用下面的格式：
---------------------------------------------------------------
- ID-ACT-DATA-EXPECTED-ACTUAL-T/F-DATE
---------------------------------------------------------------
我認為沒有什么問題，ID代表用例標號。ACT代表一種動作，因為測試動作非常復雜，如果手動執行或者自動執行，或者是一種異常狀態都可以占用此位置。DATA代表數據，很多的測試類書籍中雖然沒有直接講明測試數據的劃分，但是通常我們引用三種數據“正�！�、“異�！�、“錯誤”，分別對應關鍵字“PASS”、“ERROR”、“FAIL”，對于數據的劃分我不細說了。為什么會在一個文檔中體現這些內容——主要是為了以后的測試自動化，一個不能將手動測試轉為自動測試的人員注定是平庸的。EXPECTED、ACTUAL分別代表期望和實際，我們做這一行的經常對這兩種值的差異感到困惑，是不是“正�！�、“異�！�、“錯誤”就看個人的經驗了。T/F的引入是因為有這樣的一種情況介入，如果EXPECTED、ACTUAL是不同的，但是我們還是要給個T，因為對于單項的是否通過測試人員有著使用權，但決定權在于市場或者高層決策。DATE是一種好習慣，通常記為發現“PASS”、“ERROR”、“FAIL”的時間，很多人會忽略這個值，當然對于我們來說沒什么損失，對于QA團隊來說，僅僅提供給他們T/F是不夠的。
qiuyangzh：不過在我看來，還是要把ACTUAL-T/F-DATE部分抽取出來，因為這部分不能算是測試用例的內容，而是在后面實際執行測試的時候填寫的。當然，可以使用同一個格式，在編寫測試用例的時候，ACTUAL-T/F-DATE部分的內容空著，在每次執行這些用例的時候，將實際情況填寫進去，當然，測試用例和每次的測試執行要寫在不同的文檔里。
我覺得這就是一種構造樸實的測試用例的方式，不要過于在意一份文檔的表現形式，如果你有很多的時間，如果你一年才寫一次測試用例，你當然可以從互聯網上下載很多的資源把文檔修飾的像APPLE的產品一樣。
qiuyangzh：測試用例要簡潔、有效，這一點我非常同意。也許你和我一樣，也曾經看到過那些格式復雜的測試用例，不能說它們不好，但不一定適合組織的情況。我認為在很多情況下，應該保持測試用例簡潔和樸實的風格。簡潔不等于簡單，真正簡潔、樸實的測試用例，仍然是非常有效和實際的
不過上面的測試用例格式有些過于單薄，比如測試用例的設計者和對應的測試需求，還是需要寫上的。而且我的看法一直是：應該將測試用例和測試用例執行的記錄分開，不要混在同一個部分，這樣便于工作的進行。
入行的人員會更進一步的發揮測試偏執狂的能力，這時候的他們急需一種數量，例如：我們一個動態庫的測試用例就有3000多個，厲害吧？厲害，我當然說你厲害，你難道不厲害嗎？我記得有個500強的面試題就是你能為登錄的動作寫多少測試用例？我想了半天說就三個，或者四個，在聽到了一聲深深嘆息后，我惶恐的說大概我能寫5個吧？當然我自己也沒底，我就能寫出三個：LOGIN/PASS、LOGIN/ERROR、LOGIN/FAIL，所有的測試用例就是他們的衍生，一種本源的問題。我們繼續討論3000多個測試用例的事情，有人明眼就會說：這家伙肯定是微軟的，沒錯，除了這種大公司有了充足的資源和技術支持，哪家公司能跟他們一樣呢？當然了，寫3000個我想入行久了誰都可以，并且跟你對系統的熟悉程度，工作經驗有莫大的關系，但是這里我又想說說關于構造樸實的測試用例的問題了。
當你開始測試的時候，實際上最終是對代碼設定路徑的一種驗算，如果我們都生活在單線程、無UI的年代你可以更清楚的看到“PASS”、“ERROR”、“FAIL”三種狀態，可我們已經錯過了這個年代，我們有了包裝的UI，有了封裝的API，有了各種各樣的MESSAGE，所以你就要承受更多ERROR的打擊。這個時候有人就會通過增加測試用例的數量來回避這些陷阱，出發點是好的做法是累死人的，如果你愿意你可以為機器碼寫1億個測試用例，如果你還是很偏執，你可以為門電路寫上1萬億個測試用例，你有時間執行嗎？
qiuyangzh：如果資源充分，當然測試用例的數量多一些對于檢驗產品的質量是有好處的。但實際情況往往是資源有限的，這種情況下，就必須挑選出那些最有價值的測試來執行。
我通常不愿意寫太多的測試用例，很多人認為我工作態度有問題，我認為這更能說明我的態度：我愿意樸實的構造我的測試用例，但是我有原則來保證我的測試用例的質量：
1。接到任務不急于作而在于多思考，首先在紙上構造好業務流圖
2。業務流程圖構造好，快速挑選出公用的測試用例
3。構造測試用例，先寫符合主路徑的三種“PASS”、“ERROR”、“FAIL”
4。精化測試用例，努力為ERROR多構造1-7種假設
5。執行測試用例，增加FAIL的標準化失敗的測試，但是對應減少PASS測試用例
6。進一步精化測試用例，使“PASS”、“ERROR”、“FAIL”所占的比例分別為%20、%70、%10
qiuyangzh：就是因為上面這段話，更確切的說是第4、5、6條，使我決定把這篇文章放到我的Blog中來。根據我的經驗，在設計和執行測試的時候，應該按照這種比例來操作。
我將繼續我的樸實理論，多出來的時間，我可以看看藍天，享受享受生活！
文章來源于領測軟件測試網 http://www.kjueaiud.com/
