作者: guest2008 (guest) 看板: Soft_Job
標題: Re: [心得] 為什麼軟體開發者需要在意軟體品質指標
時間: Sun May 27 11:25:11 2012
直接開新回文
1. test case 是否有必要:
回想了一下，根本不需要像 T 大一樣大力鼓摧，那個真的就是類似摩托車跟汽車
的關係，摩托車跟汽車都可以到達目的地，你認為摩托車真的會比汽車慢嗎??
錯！有時候車子塞車，或者找不到停車位，或者xxoo各種因素，結果都是摩托車
先到。
摩托車跟汽車都是可以到達終點的，要看狀況去選擇交通工具，而不是一意的說
汽車就是比較好。而且汽車真的成本比較貴，且貴太多了。
結論：請先斟酌專案狀況，不需特別的去擁護 test case 的建立或提出議聲。
2. test case 缺陷:
他只能虛擬的跑程式設計師設計的路線，可是現實狀況跟模擬都是兩碼事，他無法
模擬使用者「超天才的行為」，模擬的定義都是想像出可能會發生的狀況，才叫作
模擬，類似我們在災難演習，都是演習自認為劇情會這樣走，但災難發生，完全不
照劇本走。
所以你 test case pass 1000個項目不代表程式就是ok..他一樣都是假的，他根本
就不是保證，你是老闆，聽到員工跟你講我已經 pass 1000個 test case 千萬別太
高興，別被騙了，那只是代表是「已知狀況」，「乖乖狀態」是pass的。
當然你可以在加入更多的測試補盯，好吧..有10個按鈕，我就寫一個模擬使用者
按 1,2,3,4,5...., 按 3,2,1,4,5..，少按一次1, .........
把所有的狀況全考慮進來...
請問你一下你寫這樣的測試程式代價成本划得來嗎?? 還不如人工檢測，幾分鐘就
解決掉。
另外一點：test case 只能測試邏輯面或者流程，你寫表單，少寫一個輸入驗證
根本就不會影響結果，你的表單欄位沒有對齊也不會影響結果，你的標單 Label
打錯字也是不會影響結果，但 Label 打錯字很有可能造成災難，「a0成本」打成
「aO成本」，test case 照你的流程跑完是 pass的，你太信任他，結果系統上線
就慘了，不管怎樣「人工檢核」這個程序絕對不可以少掉。
結論: 1. 請建立心態：test case 不是完美的。 test case 要完美還真的也要
看寫 test case 這個人的邏輯是否週密，公司把這樣的人才拿來做測
試員還真是悲劇。
2. 不管 test case 寫的再完善，還是需要做「人工檢核」。
3. test case 優點
沒有優點的話，他就會從人家蒸發，或者類似 CMMI，只剩下商業利益份子在估吹，
買家跟開發商根本不領情。
test case 他的優點是建立在「後續系統異動」，當系統結案後，放入硬碟的深層，
突然有一天要讓他重新上戰場，且會對程式部份做異動的話，這個 test case 的效
益才會真正的產生。
人的記憶是不可靠的，當你在開發系統時，其實沒有那些 test case 真的沒差，
在你的腦袋早就有一堆 test case 在你的腦海內運作，你會很清楚知道，動到
A，則 B 也要記得要一併處理，這兩個模組是有牽連性的。
可是當案子結案，你的腦袋也會把這件事卸除，過3個月後，你已經淡忘這個系統
的一半了，再過一年就整個忘記了，這時候 test case 的效應就會產生了，你改了
A, B的 bug 就會在report 上現出原形，讓你記憶起來這件事，
「對了..A 跟 B 是有連動性的，我想起來，C的某某地方也要一併處理，要不然
會發生啥事情」
結論：test case 的真正優點是記憶的便條紙，他讓你快速的重新掌握沈睡已久的
系統關聯記憶。
如果你的系統有要長期抗戰的需求，那這個 test case 還真的不可少。
結案就可拋棄了，還是客戶是芭樂屎，不要給自己找麻煩了，快點找下個
客戶比較實在。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 1.170.125.31
→ lovdkkkk:同意要看狀況, 不過 3 不太一定, 要看系統多大怎麼分工 05/27 11:33
推 gname:大大的中肯啊!!! 用適合的方法比用對的方法來的重要! 05/27 12:36
推 Ting1024:是這樣沒錯。尤其WEB的專案，都以PAGE為主。 05/27 13:08
→ Ting1024:其實要複雜也有個限度，不用太CARE這個 :D 05/27 13:08
推 ashram:推超天才的行為 05/27 14:17
沒有留言:
張貼留言
您好.本資料庫並非第一手資料.如果你有對文章作者的詢問,意見與需求,請自行找尋文章作者並提供意見,謝謝.