ALM-測試
你有沒有碰過這些問題?
為什麼要一直改需求?不能把需求都定下來嗎?
Ruddy老師說過的話，一位信仰敏捷的人，是會認清這個事實：
「你無法凍結需求，正如你無法凍結市場、競爭、知識、進化或者成長一樣。」
改了A功能後，B功能不能動了?改A壞B
維護前人留下的專案，不安感很重
除了主機要放乖乖之外，程式碼也要擺個平安符
平安就是福
進退兩難
了解前人的程式碼不難，難的是你不知道是否會引發出意料之外的副作用
總是要到上線前一刻才發現程式有問題，無法立即反應
http://www.lifeparty.idv.tw/blog/archives/308
找不到錯誤，你認為沒有問題但是結果一直不對
用錯方法，除錯所花費的時間會是你開發的兩倍時間以上
所以…
需求改來改去，PM下班，我加班
久而久之，形成對立
不寫測試的推託說詞
為什麼覺得不容易執行
測試寫了，還是沒有辦法滿足使用者的需求
心理障礙，不習慣改變、害怕、質疑
不知道如何開始
主管不挺
測試VS不測試
其實你一直都在寫測試
開發階段，你可能會這樣做...
需求異動時，你可能會這樣做
把UI打開，將所有的按鈕都按過一遍，下次需求異動的時候，在手動按過一遍
好花時間、好麻煩阿，最後，只針對那個需求按A按鈕
結果：
A功能改好了，但BCD功能壞掉了，可怕的是BCD壞了你還不知道....
以前的測試方法做不到
你誤會了，F5是偵錯，不是測試
你以為你在開發，其實是在創造臭蟲...
不要用臆測的方法來除錯
使用案例
用使用案例來開發的好處
為什麼用使用案例會減少整體開發時間
使用案例能取代以往的文件嗎
開發人員最討厭的事
軟體工程
測試驅動開發
（Test-driven development，TDD）
行為驅動開發
Behavior-driven development，BDD）
補測試的時機
我發現以下幾個情況，都是寫新測試碼的好時機：
在程式裡輸出訊息找錯誤：與其花時間寫 print、看輸出訊息、再回頭砍掉 print，不如寫個 unit test，之後能持續受惠。
執行 debugger：同上，你還是得花時間設中斷，一步步看訊息，不如寫個 unit test，之後能持續受惠。
不知錯誤在那，該如何進行下一步：這表示一次貪心實作太多功能，把目標縮小，一步步補 unit test 吧。
甚麼情況下不要寫測試
不要測，好爽，是哪個案子，我要加入。
以下情境不要寫測試
Survey API、POC
無法預測結果的
亂數
圖片
非對稱式加密
測試涵蓋率
涵蓋率越高，發現缺陷的可能性更大
沒有用需求，而是用無意義的糟糕測試達到100%的涵蓋率，所以，一昧的提高涵蓋率並不能解決問題
不要為了測試而測試
測試涵蓋率不是唯一指標
不是用使用案例數量當指標
為什麼會測試不好寫
物件相依性太高
物件設計能力太差