推 banqhsia: 自動測試大好 <3 04/13 13:14
真der, 人工幾週的事情變電腦自動跑半天就好
※ 編輯: lovdkkkk (118.163.80.109), 04/13/2018 15:04:21
恕刪
有一個觀念還蠻不錯的,
"沒有銀彈"
Ref https://zh.wikipedia.org/wiki/%E6%B2%A1%E6%9C%89%E9%93%B6%E5%BC%B9
縮 https://goo.gl/S7bKr4
推薦給大家 (?)
(謎之音 : 老生常談推薦個...) (艸)
對於各種看似衝突、矛盾的評論,
如果不綜合考慮開發/運行環境, 人員組成等因素,
是很難有實質上有意義的討論的
例如若是舊系統的改寫,
像老舊的銀行系統用 JAVA 翻新,
DB 欄位確定、邏輯確定、規格一清二楚,
一個資深架構師 + PM/SA/SD + 新手菜鳥 n 名,
這種情形說用瀑布比用敏捷適合也是很合理的事情
例如很簡單的 CRUD 專案,
搭配好棒棒的前後端框架, 每個功能都非常獨立且簡短,
要求不嚴、有 bug 上線後收到使用者回報再修就好,
收到回報後可以幾分鐘內追到原因改好上新版,
這種情形說跑敏捷不必搭配 unit test 也很正常 (本來就不需要)
說跟 coding 功力沒關係也可以理解 (也是本來就不需要)
(相對如果要求很嚴、有 bug 會虧大錢,
那最少 e2e test 跑一下)
例如某複雜 lib 的核心,
有複雜的邏輯、時常變動、擴展的規格、會被用在不知道 n 百個地方,
一個改動得測過 n 百個 case 確認都 pass 後才能發佈,
這種的如果沒 coding 功力跟相當程度的自動測試做搭配,
嗯...
可能要修改完再花兩週手動測試之類的?
然後有錯 > 再改 > 全部重測
又因為 coding 功力不好這 loop 重覆許多次
全部搞定已過三個月...
這樣子應該很難敏捷得起來
(會有一堆 sprint 是 test > refix > loop) XD
總之只是想說各種方法/理論/工具都有它各自適用的情況,
也都有各自的強項與弱點,
真的要討論東西的話各面向都交待得清楚一點會比較有效果,
另外自動測試真的不錯, 人工測很累der
(剛入行幹過一陣子, 幾百幾千個 case 一天大概測四五十個)
不管敏不敏捷都建議可以試試自動測試
--
廢文能量釋放完畢 XD
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.163.80.109
※ 文章網址: https://www.ptt.cc/bbs/Soft_Job/M.1523593383.A.0E3.html