Re: [請益] 軟體測試出路?

看板Soft_Job作者時間11年前 (2014/05/10 11:16), 11年前編輯推噓10(10032)
留言42則, 9人參與, 最新討論串8/10 (看更多)
※ 引述《AmosYang (Zzz...)》之銘言: : ※ 引述《lovdkkkk (dk)》之銘言: : : 恕刪 : : 關於 agile 及 taliao 大上一篇提到的 TDD, : : 個人一直覺得是不怎麼合的兩個東西, : : 一個是變動為本,另一個則起碼要寫得出 test case。 : : (然後 test case 得隨著變動一直重寫?) : : 想了好一陣子摸不著頭腦,剛才狗了一下... : : http://www.agiledata.org/essays/tdd.html#TDDAMDD : : days... hours... minutes... : : 看起來超忙的啊 XDD : 「個人一直覺得是不怎麼合的兩個東西」這句話讓我想起一個經驗: : 我是烹飪門外漢,每次讀到食譜裡把醬油與冰糖放入同一道菜裡的作法 : 我的反應就是: dafaq? : 但對烹飪經驗豐富的人來說,醬油與冰糖就只是調味料, : 放對時機、分量、順序, 這一鹹一甜就能讓整道料理的滋味更上一層樓 : 在我的認知裡, TDD 只是一種流程工具, 一種心態(mentality) : 在試作原型(prototyping)時,測試方法可以偏向 exploratory testing : 一旦開始 coding, 那就可以試著導入 xUnit 的架構 : 有了 test case 後, (無論是否 automated); 這些 test case 除了可以協助預防 : regression, 還可以協助估計「變動規格」的代價 : 易言之,各種工具合與不合,取決於使用時機與方法是否適當 :) 事實上TDD是軟體工程發展史上一個劃時代的發明,只可惜在2000年左右發明時,很多 人第一反應是"這太花時間了吧",所以大部分人都沒有採用。但到了2009~2010,DevOps 跟Continuous Delivery被提出以後,整個軟體業的"工法"發生了根本的變化,TDD已經 成為DevOps跟Continuous Delivery裡面不可或缺的一部分,甚至某些矽谷公司,面試 時直接就是問你怎麼做TDD的,要是全無經驗,當場傻在那邊,結果一定是被發卡。 台灣的軟體業還處於非常原始的階段,相較於美國已經升到帝王後期,台灣可能才剛升 封建而已,所以對於現在最重要的DevOps跟Continuous Delivery,90%的台灣人大概是 聽都沒聽過,剩下聽過的也僅止於一知半解的階段,有深刻了解跟經驗的可說是鳳毛麟 角。但事實上DevOps跟Continuous Delivery就算不能跟蒸汽機的發明相提並論,對軟 體業的影響恐怕也至少有當年蒸汽機影響工業革命的六七成影響力。 相信很多人都知道軟體業在美國現在是最紅的行業,軟體工程師平均薪資是第一名,而 且還不斷創新高。但說到為什麼,很多人只能說"時候到了,人類發展到現在就是會開 始注重軟體"這種好像對但又很沒根據的說法。那為什麼不是十年前開始這件事,偏偏 就是差不多2011~2012以後開始發生?事實上促成現在榮景,主要是三件事的影響,第 一是創投環境跟方法的成熟,使得創業資金非常容易取得,方法論也都寫成暢銷書, 要開公司就去看lean startup,創投也有一些很有經驗的mentor可以幫忙。第二是雲 端的發展造成新創軟體公司的門檻大幅降低。第三就是DevOps跟Continuous Delivery的發明,使得軟體業的生產力和品質都獲得倍數的成長,使用這套的好比手 上拿了自動步槍,沒使用這套的跟拿大刀差不多而已,無論你刀法如何精妙,還是打 不贏自動步槍。 去翻一下現在矽谷的工程師職缺,一列出來一堆叫做"DevOps Engineer"的,就算不 是叫這個名字,點進去看job description,或多或少也都需要DevOps相關經驗。那 究竟為什麼人家都上太空了,台灣軟體業還在殺豬公,甚至連人家上太空了都不知 道,聽到人家上太空還說"太空,那是什麼,能吃嗎?"。這主要是因為台灣軟體業太 小也太落後,大部分公司又都是以接案為主的形式,而非自己本身就是做軟體出來 賣錢的,接案的話其實只要業務一張嘴會說,合約簽得下來就好,之後案子做好做 壞根本也關係不大,做壞就是砸公司招牌,以後這家客戶不能再做了而已,真要壞 到公司名聲在業界整個臭掉,無法再生存下去,那要做壞很多個案子。既然不是立 即就有生死問題,老闆們自然也不太在乎品質跟專案成功率,甚至一堆低價搶標的 。反正就算最後公司做不下去,老闆們也撈夠了,這些老闆通常也有其他事業或投 資,不會這個死了就死了,再不然換個名字重新包裝再出發,又是一條好漢。品質 ,產值,那是什麼?能幹麼?品質高一倍我可以多賺一倍錢嗎?不行呀,那我在意這 個幹麼?產值?叫工程師加班就好啦,不然多找幾個便宜的免洗來先擋著用 但是美國的軟體公司多半是自己作軟體自己賣,自家產品就是軟體,做不好沒人用 ,過不了多久公司就得關門大吉,那可是攸關生死的大事,老闆們自然不敢對品質 馬虎,所有東西都要求最高標準,自然會對能提升產值和品質數倍的軟體工程方法 趨之若鶩。當這個產業夠大,領先集團又都這樣搞的時候,其他公司自然得跟進, 導致即使不是自己賣軟體的公司也都紛紛引進這套,整個業界的生產力往上提升數 倍,自然就風生水起,整個形勢大好。 另外在這套之下,developer跟tester的界限已經愈來愈模糊,tester工作內容大 部分是在寫code,developer也要花些時間去做TDD,如果有注意facebook的職缺, 會發現他們根本沒有分developer跟tester,所有職缺都叫software engineer。 這套新的軟體工程方法跟以往的思維可說是完全不同,沒接觸過的剛聽到真的是會 覺得到了一個新世界,回頭再看會覺得以前到底是怎麼用那種方法寫出東西去賣錢 的,想一想都覺得汗顏,再戴上DevOps跟Continuous Delivery的眼鏡去看自己以 前寫的code,會覺得以前真是不懂事呀,怎麼會寫出這種鳥code。這個浪潮或許不 會在一兩年內就翻掉整個軟體業,特別是台灣的軟體業,但是長久來看這個肯定是 會慢慢的把軟體業的方法整個顛覆掉,建議台灣的軟體從業人員盡快的學習相關知 識,以免十年後整個落後一個世代,到時候被淘汰就很慘。 -- ※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 118.165.200.238 ※ 文章網址: http://www.ptt.cc/bbs/Soft_Job/M.1399691771.A.F23.html

05/10 12:10, , 1F
05/10 12:10, 1F

05/10 13:33, , 2F
TDD真的是很重大的改變~正反都有人擁護!!
05/10 13:33, 2F

05/10 13:43, , 3F
現在已經沒有人反了...用過的都回不去了
05/10 13:43, 3F
※ 編輯: Wolfken (118.165.200.238), 05/10/2014 13:48:24

05/10 13:48, , 4F
有呀... RoR的發明人前陣子才公開演說不要盲信TDD XD
05/10 13:48, 4F

05/10 14:39, , 5F
補一下~http://goo.gl/UCKuWe 值得玩味~
05/10 14:39, 5F

05/10 14:52, , 6F
我覺得重點還是在精神啦 名詞只不過是個路牌...
05/10 14:52, 6F

05/10 15:00, , 7F
TDD已死,但測試萬歲啊,都一樣要寫單元測試
05/10 15:00, 7F

05/10 15:00, , 8F
目前還沒聽過有哪位大師出來說寫單元測試是不好的
05/10 15:00, 8F

05/10 15:09, , 9F
我覺得他說的是有些人走火入魔,為了TDD寫了一堆不必要的
05/10 15:09, 9F

05/10 15:09, , 10F
他應該也不是說TDD一定不好,只是認為不是100%都適用那樣
05/10 15:09, 10F

05/10 15:09, , 11F
class跟interface,搞的架構很亂
05/10 15:09, 11F

05/10 15:09, , 12F
TDD重點其實不在測試,TDD本身是一個確保你code design正
05/10 15:09, 12F

05/10 15:10, , 13F
確的方法,但是用了這方法反而讓你的設計亂掉就不對了
05/10 15:10, 13F

05/10 15:40, , 14F
@kinanson 你沒看完 DHH 的討論吧,DHH 就是批評 test 過度
05/10 15:40, 14F

05/10 15:41, , 15F
drive 開發跟讓開發過早陷入細節。他反而沒有否定設計先行
05/10 15:41, 15F

05/10 15:42, , 16F
的這個 TDD 核心概念。他討厭是因為 test 帶來的爭論。
05/10 15:42, 16F

05/10 15:43, , 17F
其中從他認為 database 不需要作 mock test 這件事情與相關
05/10 15:43, 17F

05/10 15:44, , 18F
討論可以清楚的看出它對過度為了 test 而設計的看法。
05/10 15:44, 18F

05/10 15:44, , 19F
當然 Ttest 跟 TDD 我認為他並沒有否定,而是這兩件事情目前
05/10 15:44, 19F

05/10 15:44, , 20F
*Test
05/10 15:44, 20F

05/10 15:44, , 21F
過度的走火入魔到走偏了,應該點到為止。
05/10 15:44, 21F

05/10 17:09, , 22F
需矯正的是走火入魔的人,而不是 TDD 本身。若走火入魔的人
05/10 17:09, 22F

05/10 17:09, , 23F
迷上了 XXX 方法後,幾年後又得來一次 XXX IS DEAD。這樣弄
05/10 17:09, 23F

05/10 17:09, , 24F
不累嗎qq
05/10 17:09, 24F

05/10 17:20, , 25F
我目前也是先寫code才寫測試,當你開始寫測試的時候,每
05/10 17:20, 25F

05/10 17:20, , 26F
寫一段code就補測試,會思考職責是否過多,哪些code其實
05/10 17:20, 26F

05/10 17:20, , 27F
不需要,也並不是所有模組都寫測試,dhh並沒有說不用寫
05/10 17:20, 27F

05/10 17:20, , 28F
測試,我到目前為止從來沒看過哪位大師跳出來鼓勵不用寫
05/10 17:20, 28F

05/10 17:20, , 29F
測試的,tdd本來就不是跟單元測試綁在一起的東西,更何況
05/10 17:20, 29F

05/10 17:20, , 30F
大師們的嘴炮大戰,顯然也很多人吐草dhh,看人怎麼用和
05/10 17:20, 30F

05/10 17:20, , 31F
看專案吧
05/10 17:20, 31F

05/10 17:22, , 32F
@kinanson 羨慕。因為維護舊專案很少能這麼做,只有先獨立寫
05/10 17:22, 32F

05/10 17:23, , 33F
library 時才能做到接近 TDD。不過主要是東西有確實經過邏
05/10 17:23, 33F

05/10 17:23, , 34F
輯驗證,我也不用把事情拖到整合時才一次炸開。
05/10 17:23, 34F

05/10 17:54, , 35F
如果有時間,上面不催進度的話,雖然應該很難....倒是可
05/10 17:54, 35F

05/10 17:54, , 36F
以透過重構來補測試,除了提升程式碼的品質,也能深刻了
05/10 17:54, 36F

05/10 17:54, , 37F
解舊產品的邏輯性......
05/10 17:54, 37F

05/10 18:11, , 38F
我說測不了是因為 ......... 一堆舊 code 寫在 jsp 內啊orz
05/10 18:11, 38F

05/10 18:39, , 39F
Java 也有測試框架可以用啊
05/10 18:39, 39F

05/10 19:41, , 40F
方法沒問題,有問題的是人.人搞錯精神,再好的方法也是錯誤.
05/10 19:41, 40F

05/10 19:41, , 41F
DHH大概Code寫太多了,只要一TDD就會走火入魔,分散焦點,
05/10 19:41, 41F

05/10 19:42, , 42F
然後趕不上Schedule,然後出來幹譙TDD .... XDD
05/10 19:42, 42F
文章代碼(AID): #1JRPdxyZ (Soft_Job)
討論串 (同標題文章)
文章代碼(AID): #1JRPdxyZ (Soft_Job)