-------------------------------------------------------------------------
- ID-ACT-DATA-EXPECTED-ACTUAL-T/F-DATE
-------------------------------------------------------------------------
我認為沒有什么問題，ID代表標號（如果你愿意可以用這個ID對應需求文檔的ID或者使用詳細設計的文檔的ID，間接連接需求），ACT代表一種動作，因為測試動作非常復雜，如果手動執行或者自動執行，或者或者是一種異常狀態都可以占用此位置，但是注意不能使用性能、數據或者安全測試替代，為什么請各位自己考慮。DATA代表數據，很多的測試類書籍中雖然沒有直接講明測試數據的劃分，但是通常我們引用三種數據“正�！�、“異�！�、“錯誤”，分別對應關鍵字“PASS”、“ERROR”、“FAIL”，對于數據的劃分我以前曾經說過這里不再細談，為什么會在一個文檔中體現著點，主要是為了以后數據程序化作接口，一個不能將手動測試轉為自動測試的人員注定是平庸的。EXPECTED、ACTUAL分別代表期望和實際，我們做這一行的經常對這兩種值的差異感到困惑，是不是“正�！�、“異�！�、“錯誤”就看個人的經驗了。T/F的引入是因為有這樣的一種情況介入，如果EXPECTED、ACTUAL是不同的，但是我們還是要給個T，因為對于單項的是否通過測試人員有著使用權，但決定權在于市場或者高層決策。DATE是一種好習慣，通常記為發現“PASS”、“ERROR”、“FAIL”的時間，很多人會忽略這個值，當然對于我們來說沒什么損失，對于QA團隊來說，僅僅提供給他們T/F是不夠的。
我覺得這就是一種構造樸實的測試用例的方式，不要過于在意一份文檔的表現形式，如果你有很多的時間，如果你一年才寫一個這樣的文檔，那么你可以從互聯網上下在很多的資源把這份文檔修飾的像APPLE一樣。
入行的人員會更進一步的發揮測試偏執狂的能力，這時候他們急需一種數量，例如：我們一個動態庫的測試用例就有3000多個厲害吧？厲害，我當然說你厲害，你難道不厲害嗎？我記得有個500強的面試題就是你能為LOGIN動作寫多少的測試用例？我想了半天我說就三個，或者四個，在聽到了一聲深深嘆息后，我惶恐的說大概我能寫5個吧？！當然我自己也沒底，我就能寫出三個。LOGIN/PASS、LOGIN/ERROR、LOGIN/FAIL，所有的測試用例就是他們的衍生，一種本源的問題。我們繼續討論3000多個測試用例的事情，有人明眼就會說：這家伙肯定是微軟的，沒錯，除了這種大公司有了充足的資源和技術支持，哪家公司能跟他們一樣呢？當然了，寫3000個我想入行久了誰都可以，并且跟你對系統的熟悉程度，工作經驗有莫大的關系，但是這里我又想說說關于構造樸實的測試用例的問題了。
單元測試、集成測試這些說明的是測試范圍，功能測試、性能測試這些說明的是測試的手段，也可以這樣說某個功能測試包含了若干個功能測試也內隱含了若干個單元測試的聯動，當你開始測試的時候，實際上最終是對代碼設定路徑的一種驗算，如果我們都生活在單線程、無UI的年代你可以更清楚的看到“PASS”、“ERROR”、“FAIL”三種狀態，可我們已經錯過了這個年代，我們有了包裝的UI，有了封裝的API，有了各種各樣的MESSAGE，所以你就要承受更多ERROR的打擊。這個時候有人就會通過增加測試用例的數量來回避這些陷阱，出發點是好的做法是累死人的，如果你愿意你可以為機器碼寫1億個測試用例，如果你還是很偏執，你可以為門電路寫上1萬億個測試用例，你有命執行嗎？
我通常不愿意寫太多的測試用例，很多人認為我工作態度有問題，我認為這更能說明我的態度：我愿意樸實的構造我的測試用例，但是我有原則來保證我的測試用例：
1。接到任務不急于作而在于多思考，首先在紙上構造一個大致的業務流圖
2。流圖構造好，快速剔除公用的測試用例
3。構造測試用例先寫符合主路徑的三種“PASS”、“ERROR”、“FAIL”
4。精化測試用例努力為ERROR多構造1-7種假設
5。執行測試用例強化FAIL的標準化失敗輸出，但是對應減少PASS測試用例
6。進一步精化測試用例，使“PASS”、“ERROR”、“FAIL”所占的比例分別為%20、%70、%10
如果我還是測試，我將繼續我的樸實理論，多出來的安全時間我可以看看藍天享受享受生活！
延伸閱讀
文章來源于領測軟件測試網 http://www.kjueaiud.com/
