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

看板Soft_Job作者semop (semop)時間13年前 (2012/05/28 10:16)推噓3(3推 0噓 9→)

留言12則, 4人參與討論串12/20 (看更多)

看來看去，明明從頭到尾就是在講 unit test 的 automation 啊。 test case 到底是哪來的名詞? 我覺得這根本就像是知道了一個"新"方法，然後就狂熱提倡的言論，還真以為我們這種老人不知道啊? 但這東西在九零年代初期就講到爛了，今天會重新被提倡有著時代的背景，在 Web Programming 大行其道，文字資料愈來愈重要的狀況下，測試的需求增加，測試的方便性也增加，所以測試的成本效益增加。然而以軟體生命周期的觀點來看，需要在軟體開發後期建構的方法，都不如在前期就執行的效益來得大。一堆講 test case 的好處的，其實講的是由開發者自行做單元測試，比起交給別人測試，有更多早期的效益。但軟體開發在運算層次之外的核心工作是 v&v (verification and validation), 重點是你有沒有做 v&v, 而不是你有沒有用所謂的 test case 的方法來做。在軟體單元外部建構的 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 就可能很麻煩了，但不是每個人都會去避免的。我在說的也就是這樣的事情，說什麼 data validation 也要做 test case, 一點意思也沒有，能在前期處理的就不要拖後，能內建的機制就不要外加，始終是軟體開發的金科玉律，包括 unit test 的優點也是依賴這個原則的。甚至以為老人們就是打死不做 unit test, 那又更是好笑了，我們跟 test 無冤無仇的，如果是能用簡單方法就達成效益的事情，那又為什麼不做? 那本來就是成本效益的問題。我可以理解用過有加上 automated testing 的 continuous integration (CI) 感覺可能非常好，好像找到了軟體開發的終極解答一樣，所以很想要先從 automated testing 開始提倡。唉，這要怎麼說呢，工具依賴是一件很沒有救的事情，那是信念的差別了，在中大型軟體機構開發的人，常常會覺得世界上有那麼多好用的工具和方法，只要輕輕鬆鬆就可以完成工作，為什麼其他人不懂得使用呢。我知道，我理解，但不討論。從早年生存至今的開發者，為什麼許多人會走向以程式設計方法論為主，儘量不依賴外部工具來寫程式，而不是以軟體工程體系的建構為核心，那真的要經過很多風浪之後才會知道... -- ※ 發信站: 批踢踢實業坊(ptt.cc) ◆ From: 218.174.32.74

→

guest2008

05/28 10:40, , 1^F

05/28 10:40, 1^F

→

guest2008

05/28 10:43, , 2^F

05/28 10:43, 2^F

→

guest2008

05/28 10:44, , 3^F

05/28 10:44, 3^F