構造樸實的測試用例
測試用例 這種東西對于剛入行的人來說是一種誘惑,初入測試的人急于掌握這門學問,所以一開始就會問測試用例怎么寫,問的同時或許還包含了一些期望。其實測試用例就是一個測試矩陣,任何人沒有必要注重形式問題,如果你現在或者未來的公司有套非常完善的文檔
測試用例這種東西對于剛入行的人來說是一種誘惑,初入
測試的人急于掌握這門學問,所以一開始就會問
測試用例怎么寫,問的同時或許還包含了一些期望。其實
測試用例就是一個測試矩陣,任何人沒有必要注重形式問題,如果你現在或者未來的公司有套非常完善的文檔管理體系,那么你可以參考標準模版,如果沒有你們大可跟我一樣使用下面的格式:
-------------------------------------------------------------------------
- ID-ACT-DATA-E
XPECTED-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.anti-gravitydesign.com