Re: [心得] 為什麼軟體開發者需要在意軟體品質指標
※ 引述《TonyQ (自立而後立人。)》之銘言:
: 註:2012/05/28 有使用者提出 test-case 名詞的異議,為免爭論修改用詞。
: ※ 引述《semop (semop)》之銘言:
: : 看來看去,明明從頭到尾就是在講 unit test 的 automation 啊。
: : test case 到底是哪來的名詞?
: : 我覺得這根本就像是知道了一個"新"方法,然後就狂熱提倡的言論,
: : 還真以為我們這種老人不知道啊?
: 我說得其實是「實作 test-case」這件事情。
: 不用 automatic tests 是因為他不見得需要 automatic test ,
: 很多時候我們是手動 trigger 這些 test。
: 不用 unit-test 是因為還有 integration test,
: 所以挑了一個比較中性的詞「實作 test-case」來說。
: 當然,如果你看不懂這個詞,我可以再定義清楚一些,
: 寫「用程式可以跑得測試」。
: 名詞是用來溝通的,如果這樣寫你還看不懂可以再問問。
: 這方法一點都不新,unit-test 有很多年歷史,
: 今天如果不是有人出來批評這個方法不現實,我一點興趣出來講也沒有。
: 知道請用實力/經驗談,不要用「老」來談,
: 我談得東西都是確實有在專案跑過得經驗。
: 跟幾零年代有沒有人講過沒有關係。
: 你覺得寫 unit-test 不好,可以談談您用 unit-test 浪費過多少時間,
: 或者談談 unit-test 您認為的缺點,
: 也不需要別人舉經驗反駁您的缺點就舉老來反駁,這一點意義都沒有。
: 你覺得我的經驗不客觀,你可以用你的經驗說說,
: 哪邊你覺得有問題、哪邊有不客觀。
我好像看不出來semop覺得Unit Test哪裡不好,覺得用Unit Test浪費過多少時間...
他只是說比起做Unit Test,有更好的方法可以提高軟體品質而已。
: : 但這東西在九零年代初期就講到爛了,今天會重新被提倡有著時代的背景,
: : 在 Web Programming 大行其道,文字資料愈來愈重要的狀況下,
: : 測試的需求增加,測試的方便性也增加,所以測試的成本效益增加。
: : 然而以軟體生命周期的觀點來看,需要在軟體開發後期建構的方法,
: : 都不如在前期就執行的效益來得大。
: : 一堆講 test case 的好處的,其實講的是由開發者自行做單元測試,
: : 比起交給別人測試,有更多早期的效益。
: : 但軟體開發在運算層次之外的核心工作是 v&v (verification and validation),
: : 重點是你有沒有做 v&v, 而不是你有沒有用所謂的 test case 的方法來做。
: 對,但是這裡我們說的是"寫 unit-test" 可以有效作到 v&v 。
: 當然, v&v 跟我們討論的 寫 unit-test 原則上是不同層次的命題,
: 所以寫 unit-test 並沒辦法 cover 所有 v&v 的情況,
: 但老話一句,他是工具,不是 total solution。
這裡對於Test Case的定義又有點亂了,我認為semop大是在說你的test case
是指「Well-documented」的那種文件化的Test Case,有Input/Output array
跟Step、Precondition...
我還是不知道為什麼會從Automation Test跳到談Unit Test去....
Unit Test是指針對程式碼層級的測試,一個Class你不寫Unit Test Code根本就不可能
做到Unit Test,所以針對Library層級的Unit Test一定會是Automation Test。
我一直覺得文章前後之間都是雞同鴨講....
Unit Test當然不能保證可以做到v&v。Unit Test是程式碼/Class層級的測試,講到
Unit Test就不可避免的談到Code Coverage Rate,然而做到100%的Code Coverage Rate
依然不能保證v&v,因為Follow spec做出來的Unit Test即使100% Test Success,而且有
100% Coverage Rate,但依然不能避免在Integration Test時期會發生的錯誤。
: : 在軟體單元外部建構的 v&v, 本來就沒有比在軟體單元內置的 v&v,
: : 來得更接近開發的前期。
: : 而在 design 階段就建構的 v&v 機制,特別是完善的 exception handling (EH)
: : -- 這不是指 C++ 對於 EH 的支援,這遠遠不等於 EH 的機制 --
: : 則又更是在更早的軟體開發階段了。
: : 例如現在我就很傾向即時監控機制的做法,客戶不見得看得懂測試報告,
: : 要是測試報告說 ok 又出問題還會更怒,但若有個即時監控的功能,
: : 系統的測試者或使用者都隨時都看得到系統的各種檢測狀態,
: : 不但測試方便,更重要的是,對於客戶來說,系統即時監控的爽感可說是超級高的,
: : 當然他們付錢也就爽快了。
: : 若以為在畫面上出現不知所云的錯誤訊息就是 EH, 那可真是顯得有些無知了。
: : 能在 analysis 階段就主動避免問題發生,又是再好一些的做法,
: : 例如我就儘量不碰使用者輸出入,不處理字串內容,只接受良好的格式化資料,
: : 這種狀況還會出問題,都是作業系統層級甚至硬體的問題比較多,
: : 何況做那些 UI 功能的事情,不是不太需要專業就是需要 UI 的專業...
: : 所以到現在還在寫 C/C++ 的軟體開發者,特別是傾向系統層級或技術研發的,
: : 就很少人在談 unit test 層級的事情,更何況如果不是內建的檢測機制,
: : 光是物件導向的 yo-yo problem 就可能很麻煩了,但不是每個人都會去避免的。
: 以上,完全都跟寫 unit-test 這件事情的主題沒有關係,
: 這才是重點。
: unit-test 是加速你開發,不是幫你做出一個「完全」穩定的系統,
: 這是兩回事。
: 你說得這些東西都是挑戰跟值得做的東西,
: 但是有了 unit-test 仍然可以幫助你作這些事情做得更好更快。
: 你在談得是另一個層次的問題,而他也確實是國內開發者的問題,
: 但是寫 unit-test 完全就可以幫助你作到這些事情。
: 我不瞭你拿張飛打岳飛幹麼?
: 難道你要說因為問題是這個,所以「版本控制」就不是重要的東西?
: 因為版本控制不能解決你說得這些問題?
: 他們要做的是扮演好他們的職責,而你說得並不是他們的職責。
我認為semop談論的是另外一個主題「防禦性程式設計」
至於為什麼沒去談Unit Test層級的東西,就我的看法,他不是認為那不重要
而是比起Unit Test他更著重在開發防禦性的程式。
另外為什麼這邊把UI和Unit Test搞在一起,這我就完全看不懂了。
: : 我在說的也就是這樣的事情,說什麼 data validation 也要做 test case,
: : 一點意思也沒有,能在前期處理的就不要拖後,能內建的機制就不要外加,
: : 始終是軟體開發的金科玉律,包括 unit test 的優點也是依賴這個原則的。
: : 甚至以為老人們就是打死不做 unit test, 那又更是好笑了,
: : 我們跟 test 無冤無仇的,如果是能用簡單方法就達成效益的事情,
: : 那又為什麼不做? 那本來就是成本效益的問題。
: 這,我認識的所有資深 RD 幾乎都會作喔......
: 我們認識的大概是不同群的老人吧
Data Validation要不要做Unit Test?當然要,因為你是用Code來做Data Validation
的吧,既然有Code以Unit Test的角度來說就需要測試。
至於要不要寫成Test Case,甚至寫成Test Case以後再做Automation,這個就跟ROI
有關。
: : 我可以理解用過有加上 automated testing 的 continuous integration (CI)
: : 感覺可能非常好,好像找到了軟體開發的終極解答一樣,
: : 所以很想要先從 automated testing 開始提倡。
: : 唉,這要怎麼說呢,工具依賴是一件很沒有救的事情,那是信念的差別了,
: : 在中大型軟體機構開發的人,常常會覺得世界上有那麼多好用的工具和方法,
: : 只要輕輕鬆鬆就可以完成工作,為什麼其他人不懂得使用呢。
: : 我知道,我理解,但不討論。
: 你不討論的話就沒什麼好說啦。
: : 從早年生存至今的開發者,為什麼許多人會走向以程式設計方法論為主,
: : 儘量不依賴外部工具來寫程式,而不是以軟體工程體系的建構為核心,
: : 那真的要經過很多風浪之後才會知道...
: 我也經過一些專案,不算多但是也不能算少,
: 我深知論述一個 solution 的困難,
: 所以我寫作的方針就是只寫實際的經驗跟例子,
: 有人問的時候我會盡量把所有的前提跟假設,
: 甚至是哪個案子中有用到的東西寫出來,這是很重要的。
: 因為這其中很多東西都跟你用的工具跟你的經驗,
: 甚至是一些新工具新 IDE 的抬頭有關系。
: 你的風浪如果不能換作你論述的實際依據,
: 不能因此舉出專案有哪些特性跟前提,
: 如果不能因此讓別人多一點參考價值。
: 坦白說,你的風浪是死的。
: 在你的腦袋裡面有用,在其他人的腦袋理面一點價值也沒有。
: 再者你誤會了,這些東西做起來並不輕鬆,學習新東西總有時間跟成本,
: 但是還是比反覆無聊的手工操作來得輕鬆。
: 我從頭到尾都只是抱著「我用了一個好東西」,
: 然後「別人不識貨」,所以出來說說這東西是好東西,
: 但是你用不用你怎麼想,這坦白說我一點都不在乎。
: 寫 unit-test 我也試著用超過三年,從 ppolis 、自己接小專案、 ZK,
: 我想是不是你所謂「知道了新方法就大力推薦」,
: 我是知道了、做了,我也碰過其中有很麻煩得部份,
: 你回去翻我之前寫有關測試的文章就知道,
: 但是權衡之下這我認為還是有做的價值。
我還是認為semop並沒有刻意去貶低Unit Test的價值。然而他認為把力氣放在
防禦性程式設計更為重要。
不過整篇文章我還是很看到很多不易理解的術語,查也查不到,
「而不是以軟體工程體系的建構為核心」我實在不知道這行在說什麼...
我很多地方都是靠猜測兩邊在說些什麼,但在我看來semop並沒有徹底否定Unit Test
的價值。
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 175.182.34.146
推
05/28 23:31, , 1F
05/28 23:31, 1F
→
05/28 23:33, , 2F
05/28 23:33, 2F
推
05/28 23:45, , 3F
05/28 23:45, 3F
→
05/28 23:47, , 4F
05/28 23:47, 4F
→
05/28 23:48, , 5F
05/28 23:48, 5F
推
05/28 23:52, , 6F
05/28 23:52, 6F
推
05/28 23:52, , 7F
05/28 23:52, 7F
→
05/28 23:52, , 8F
05/28 23:52, 8F
→
05/28 23:53, , 9F
05/28 23:53, 9F
→
05/28 23:56, , 10F
05/28 23:56, 10F
→
05/28 23:56, , 11F
05/28 23:56, 11F
→
05/28 23:57, , 12F
05/28 23:57, 12F
→
05/28 23:58, , 13F
05/28 23:58, 13F
→
05/28 23:58, , 14F
05/28 23:58, 14F
推
05/28 23:58, , 15F
05/28 23:58, 15F
→
05/28 23:59, , 16F
05/28 23:59, 16F
→
05/29 00:00, , 17F
05/29 00:00, 17F
→
05/29 00:00, , 18F
05/29 00:00, 18F
→
05/29 00:01, , 19F
05/29 00:01, 19F
→
05/29 00:02, , 20F
05/29 00:02, 20F
→
05/29 00:02, , 21F
05/29 00:02, 21F
→
05/29 00:02, , 22F
05/29 00:02, 22F
→
05/29 00:04, , 23F
05/29 00:04, 23F
推
05/29 00:05, , 24F
05/29 00:05, 24F
→
05/29 00:05, , 25F
05/29 00:05, 25F
→
05/29 00:05, , 26F
05/29 00:05, 26F
→
05/29 00:05, , 27F
05/29 00:05, 27F
→
05/29 00:07, , 28F
05/29 00:07, 28F
→
05/29 00:07, , 29F
05/29 00:07, 29F
推
05/29 00:07, , 30F
05/29 00:07, 30F
→
05/29 00:08, , 31F
05/29 00:08, 31F
→
05/29 00:08, , 32F
05/29 00:08, 32F
→
05/29 00:09, , 33F
05/29 00:09, 33F
→
05/29 00:10, , 34F
05/29 00:10, 34F
→
05/29 01:18, , 35F
05/29 01:18, 35F
→
05/29 01:18, , 36F
05/29 01:18, 36F
→
05/29 01:19, , 37F
05/29 01:19, 37F
→
05/29 01:19, , 38F
05/29 01:19, 38F
→
05/29 01:19, , 39F
05/29 01:19, 39F
還有 23 則推文
→
05/29 01:37, , 63F
05/29 01:37, 63F
→
05/29 01:37, , 64F
05/29 01:37, 64F
→
05/29 01:56, , 65F
05/29 01:56, 65F
推
05/29 02:21, , 66F
05/29 02:21, 66F
→
05/29 02:25, , 67F
05/29 02:25, 67F
→
05/29 02:26, , 68F
05/29 02:26, 68F
→
05/29 08:38, , 69F
05/29 08:38, 69F
→
05/29 08:40, , 70F
05/29 08:40, 70F
→
05/29 08:42, , 71F
05/29 08:42, 71F
→
05/29 08:44, , 72F
05/29 08:44, 72F
→
05/29 08:45, , 73F
05/29 08:45, 73F
→
05/29 08:49, , 74F
05/29 08:49, 74F
→
05/29 08:51, , 75F
05/29 08:51, 75F
→
05/29 08:51, , 76F
05/29 08:51, 76F
→
05/29 08:53, , 77F
05/29 08:53, 77F
→
05/29 08:55, , 78F
05/29 08:55, 78F
→
05/29 08:56, , 79F
05/29 08:56, 79F
→
05/29 08:57, , 80F
05/29 08:57, 80F
→
05/29 09:05, , 81F
05/29 09:05, 81F
→
05/29 09:06, , 82F
05/29 09:06, 82F
→
05/29 09:07, , 83F
05/29 09:07, 83F
推
05/29 09:17, , 84F
05/29 09:17, 84F
→
05/29 09:17, , 85F
05/29 09:17, 85F
→
05/29 09:18, , 86F
05/29 09:18, 86F
→
05/29 09:20, , 87F
05/29 09:20, 87F
→
05/29 09:20, , 88F
05/29 09:20, 88F
→
05/29 09:22, , 89F
05/29 09:22, 89F
→
05/29 09:29, , 90F
05/29 09:29, 90F
→
05/29 09:30, , 91F
05/29 09:30, 91F
推
05/29 09:31, , 92F
05/29 09:31, 92F
推
05/29 09:43, , 93F
05/29 09:43, 93F
推
05/29 09:50, , 94F
05/29 09:50, 94F
→
05/29 09:51, , 95F
05/29 09:51, 95F
→
05/29 10:23, , 96F
05/29 10:23, 96F
→
05/29 10:24, , 97F
05/29 10:24, 97F
→
05/29 10:24, , 98F
05/29 10:24, 98F
→
05/29 10:24, , 99F
05/29 10:24, 99F
→
05/29 10:24, , 100F
05/29 10:24, 100F
→
05/29 18:44, , 101F
05/29 18:44, 101F
→
05/29 18:45, , 102F
05/29 18:45, 102F
討論串 (同標題文章)
本文引述了以下文章的的內容:
完整討論串 (本文為第 16 之 20 篇):