Re: [心得] 為什麼軟體開發者需要在意軟體品質指標

看板Soft_Job作者 (華麗的天下無雙)時間12年前 (2012/05/28 23:21), 編輯推噓13(13推 0噓 89→)
留言102則, 9人參與, 最新討論串16/20 (看更多)
※ 引述《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
"比起Unit Test，有更好的方法可以提高軟體品質".
05/28 23:45, 3F
→
05/28 23:47, , 4F
事後的unit test, 無法有效提升軟體品質, 它只是用來檢驗
05/28 23:47, 4F
→
05/28 23:48, , 5F
現在這個實作, 有沒有達到一開始設計所預期的品質
05/28 23:48, 5F
推
05/28 23:52, , 6F
unit test,只是檢驗"實作",而架構/設計這和軟體品質高度相關
05/28 23:52, 6F
推
05/28 23:52, , 7F
的確, 一開始就把叉路都封死, 減少user預期之外的操作, 比
05/28 23:52, 7F
→
05/28 23:52, , 8F
事後測到死好多了
05/28 23:52, 8F
→
05/28 23:53, , 9F
必須要是相關的程式設計方法論，以及相關domain的及經驗
05/28 23:53, 9F
→
05/28 23:56, , 10F
樓上的是理想狀況吧? 現實上應該是從PM/SA/SD都沒人懂
05/28 23:56, 10F
→
05/28 23:56, , 11F
業務邏輯, 邊談使用者需求邊開規格讓外包商去做
05/28 23:56, 11F
→
05/28 23:57, , 12F
這時候test case就很有用了, 因為從頭到尾都沒有人真正懂
05/28 23:57, 12F
→
05/28 23:58, , 13F
所以設計一些test case, 來堵長官跟user的嘴
05/28 23:58, 13F
→
05/28 23:58, , 14F
你看看~ 我們通過測試這些操作流程, 所以驗收~
05/28 23:58, 14F
推
05/28 23:58, , 15F
因此當開發人員, 在進行"設計/架構"時, 不太能靠unit test
05/28 23:58, 15F
→
05/28 23:59, , 16F
結果上線後又慢, bug又一堆, 最後維護的pg就通通吃下來問題
05/28 23:59, 16F
→
05/29 00:00, , 17F
樓上混淆名詞.. "test case" and "unit test"
05/29 00:00, 17F
→
05/29 00:00, , 18F
才發現有些功能根本系統架構就做不到, 從上線就注定不能用
05/29 00:00, 18F
→
05/29 00:01, , 19F
不管是哪個,若是對"需求"進行 unit test, 或著設計test case
05/29 00:01, 19F
→
05/29 00:02, , 20F
不不, 我指的不是unit test, 是一整個作業流程的測試, 包含
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, , 27F
我不知道未來會不會有"銀彈"出現, 以大多人論述的test理論.
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
外包？用unit test檢查外包人員的成果嗎？
05/29 00:08, 32F
→
05/29 00:09, , 33F
目前看過最鳥的狀況是, PM/SA/SD全都不會寫這個專案的程式
05/29 00:09, 33F
→
05/29 00:10, , 34F
全部給外包商開發, 然後PM/SA/SD這些人手動測試到死 XDDD
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
理由可能是效能 也可能是別人有機會看到 code 如 Javasc~
05/29 02:25, 67F
→
05/29 02:26, , 68F
而檢核內容可能包含你並不想讓別人知道的資訊
05/29 02:26, 68F
→
05/29 08:38, , 69F
@lovdkkkk:你先test做過實驗再來反駁效能吧.用迴圈跑
05/29 08:38, 69F
→
05/29 08:40, , 70F
1千萬次含檢核的程式耗時.是跑幾豪秒？實驗完你就知道了
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
@guest2008 請考慮一些本身就很慢的直譯式語言
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
只是檢核條件不想讓人知道 所不寫在 js 在 server 做
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
所以你的問題是?? 你已經正解處理有安全疑慮的在 server
05/29 09:29, 90F
→
05/29 09:30, , 91F
端檢核.其餘丟JS處理.我反而不知道你上面在抱怨什麼了.
05/29 09:30, 91F
推
05/29 09:31, , 92F
lovdkkkk 的不想讓人知道應該是基於security考量吧
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
@guest2008 如果是 integration test 是有可能有效能問題啦.
05/29 10:23, 96F
→
05/29 10:24, , 97F
@lovdkkkk 前端的整合基本上以「防止使用者寫錯」為主，
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
‣ 更多 derekhsu 的文章
文章代碼(AID): #1FmvWMDn (Soft_Job)
討論串 (同標題文章)
本文引述了以下文章的的內容：
完整討論串 (本文為第 16 之 20 篇)：
排序： 最舊先 | 最新先 | 留言數
在新視窗開啟完整討論串 (共20篇)
‣ 更多 derekhsu 的文章
文章代碼(AID): #1FmvWMDn (Soft_Job)