2012年7月14日 星期六

為什麼軟體開發者需要在意軟體品質指標 09

作者: TonyQ (自立而後立人。) 看板: Soft_Job
標題: Re: [心得] 為什麼軟體開發者需要在意軟體品質指標
時間: Mon May 28 12:34:53 2012

※ 引述《semop (semop)》之銘言:
: 看來看去,明明從頭到尾就是在講 unit test 的 automation 啊。
: test case 到底是哪來的名詞?

: 我覺得這根本就像是知道了一個"新"方法,然後就狂熱提倡的言論,
: 還真以為我們這種老人不知道啊?

        我說得其實是「寫test-case」這件事情。

        不用 automatic tests 是因為他不見得需要 automatic test ,
        很多時候我們是手動 trigger 這些 test。

        不用 unit-test 是因為還有 integration test,
        所以挑了一個比較中性的詞「寫test-case」來說。


        當然,如果你看不懂這個詞,我可以再定義清楚一些,
        寫「用程式可以跑得測試」。

        名詞是用來溝通的,如果這樣寫你還看不懂可以再問問。




        這方法一點都不新,unit-test 有很多年歷史,
        今天如果不是有人出來批評這個方法不現實,我一點興趣出來講也沒有。


        知道請用實力/經驗談,不要用「老」來談,
        我談得東西都是確實有在專案跑過得經驗。

        跟幾零年代有沒有人講過沒有關係。


        你覺得寫 test-case 不好,可以談談您用 test-case 浪費過多少時間,

        或者談談 test-case 您認為的缺點,
        也不需要別人舉經驗反駁您的缺點就舉老來反駁,這一點意義都沒有。


        你覺得我的經驗不客觀,你可以用你的經驗說說,
        哪邊你覺得有問題、哪邊有不客觀。


: 但這東西在九零年代初期就講到爛了,今天會重新被提倡有著時代的背景,
: 在 Web Programming 大行其道,文字資料愈來愈重要的狀況下,
: 測試的需求增加,測試的方便性也增加,所以測試的成本效益增加。
: 然而以軟體生命周期的觀點來看,需要在軟體開發後期建構的方法,
: 都不如在前期就執行的效益來得大。
: 一堆講 test case 的好處的,其實講的是由開發者自行做單元測試,
: 比起交給別人測試,有更多早期的效益。
: 但軟體開發在運算層次之外的核心工作是 v&v (verification and validation),
: 重點是你有沒有做 v&v, 而不是你有沒有用所謂的 test case 的方法來做。

        對,但是這裡我們說的是"寫 test-case" 可以有效作到 v&v 。

        當然, v&v 跟我們討論的 寫 test-case 原則上是不同層次的命題,
        所以寫 test-case 並沒辦法 cover 所有 v&v 的情況,
        但老話一句,他是工具,不是 total solution。


: 在軟體單元外部建構的 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 就可能很麻煩了,但不是每個人都會去避免的。

        以上,完全都跟寫 test-case 這件事情的主題沒有關係,

        這才是重點。

        test-case 是加速你開發,不是幫你做出一個「完全」穩定的系統,
        這是兩回事。


        你說得這些東西都是挑戰跟值得做的東西,
        但是有了 test-case 仍然可以幫助你作這些事情做得更好更快。


        你在談得是另一個層次的問題,而他也確實是國內開發者的問題,
        但是寫 test-case 完全就可以幫助你作到這些事情。

        我不瞭你拿張飛打岳飛幹麼?


        難道你要說因為問題是這個,所以「版本控制」就不是重要的東西?

        因為版本控制不能解決你說得這些問題?


        他們要做的是扮演好他們的職責,而你說得並不是他們的職責。


: 我在說的也就是這樣的事情,說什麼 data validation 也要做 test case,
: 一點意思也沒有,能在前期處理的就不要拖後,能內建的機制就不要外加,
: 始終是軟體開發的金科玉律,包括 unit test 的優點也是依賴這個原則的。
: 甚至以為老人們就是打死不做 unit test, 那又更是好笑了,
: 我們跟 test 無冤無仇的,如果是能用簡單方法就達成效益的事情,
: 那又為什麼不做? 那本來就是成本效益的問題。

        這,我認識的所有資深 RD 幾乎都會作喔......

        我們認識的大概是不同群的老人吧

: 我可以理解用過有加上 automated testing 的 continuous integration (CI)
: 感覺可能非常好,好像找到了軟體開發的終極解答一樣,
: 所以很想要先從 automated testing 開始提倡。
: 唉,這要怎麼說呢,工具依賴是一件很沒有救的事情,那是信念的差別了,
: 在中大型軟體機構開發的人,常常會覺得世界上有那麼多好用的工具和方法,
: 只要輕輕鬆鬆就可以完成工作,為什麼其他人不懂得使用呢。
: 我知道,我理解,但不討論。

        你不討論的話就沒什麼好說啦。

: 從早年生存至今的開發者,為什麼許多人會走向以程式設計方法論為主,
: 儘量不依賴外部工具來寫程式,而不是以軟體工程體系的建構為核心,
: 那真的要經過很多風浪之後才會知道...


        我也經過一些專案,不算多但是也不能算少,

        我深知論述一個 solution 的困難,
        所以我寫作的方針就是只寫實際的經驗跟例子,

        有人問的時候我會盡量把所有的前提跟假設,
        甚至是哪個案子中有用到的東西寫出來,這是很重要的。

        因為這其中很多東西都跟你用的工具跟你的經驗,
        甚至是一些新工具新 IDE 的抬頭有關系。


        你的風浪如果不能換作你論述的實際依據,

        不能因此舉出專案有哪些特性跟前提,
        如果不能因此讓別人多一點參考價值。


        坦白說,你的風浪是死的。
        在你的腦袋裡面有用,在其他人的腦袋理面一點價值也沒有。


        再者你誤會了,這些東西做起來並不輕鬆,學習新東西總有時間跟成本,
        但是還是比反覆無聊的手工操作來得輕鬆。


        我從頭到尾都只是抱著「我用了一個好東西」,
        然後「別人不識貨」,所以出來說說這東西是好東西,

        但是你用不用你怎麼想,這坦白說我一點都不在乎。


        寫 test-case 我也試著用超過三年,從 ppolis 、自己接小專案、 ZK,

        我想是不是你所謂「知道了新方法就大力推薦」,

        我是知道了、做了,我也碰過其中有很麻煩得部份,
        你回去翻我之前寫有關測試的文章就知道,

        但是權衡之下這我認為還是有做的價值。

--

[1;36;44m      網頁上拉近距離的幫手              實現 GMail豐富應用的功臣  

[1;36m        數也數不清的友善使用者體驗      這就是javascript

[1;30m                                                歡迎同好到 AJAX 板一同討論。

--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 111.250.32.241
※ 編輯: TonyQ           來自: 111.250.32.241       (05/28 12:37)
※ 編輯: TonyQ           來自: 111.250.32.241       (05/28 12:40)
→ ykjiang:我本來想說些什麼的,後來發現得長篇大論,就算了 :p       05/28 12:43
→ ykjiang:不是針對你,是針對這個討論串 :)                         05/28 12:44
→ andymai:個人小觀感:"test case"是T大定義的?"不懂"可以再問問?    05/28 13:05
→ andymai:如果是開發金融或醫療系統~test case該做到什麼樣的程度呢  05/28 13:06
→ andymai:先說好~我並沒有不用test case~我只是很不負責任的想丟問   05/28 13:08
→ andymai:題出來而已XD 對了~其實"不識貨"這個詞有那種"試圖說服或   05/28 13:09
→ andymai:取笑"的意味...                                          05/28 13:09
→ TonyQ:事在人讀,高興的話你也可以解讀「回文這個行為有試圖說服或  05/28 14:17
→ TonyQ:取笑」意味,我並不認為需要你的感覺多作說明。XD            05/28 14:17
→ TonyQ:                        *為                               05/28 14:19
→ TonyQ:名詞是用來討論的,我提出一個名詞必然有我指涉的對象,      05/28 14:20
→ TonyQ:如果你認為我這個命名用得不好,不懂我在討論的對像是什麼,  05/28 14:20
→ TonyQ:有幾個可能性 1. 我用錯名詞  2.這個名詞我們認知不一樣,    05/28 14:21
→ TonyQ:但無論如何,既然有人說他認為 test case 是錯誤的名詞,     05/28 14:21
→ TonyQ:那我就提出細節的描述跟說明。這就是討論啊~                05/28 14:21
→ TonyQ:那句話的意思是說如果你還是看不懂「我定義的」這個名詞,    05/28 14:21
→ TonyQ:我很樂意換很多句話說來講這個詞。:p                        05/28 14:21
→ TonyQ:至於金融或醫療系統,test-case 要作到程度,當然是看專案需  05/28 14:22
→ TonyQ:求囉。我有幾分證據說幾分話,沒有作過得我會回不知道。      05/28 14:22
推 ledia:推張飛打岳飛                                              05/28 21:42

沒有留言:

張貼留言

您好.本資料庫並非第一手資料.如果你有對文章作者的詢問,意見與需求,請自行找尋文章作者並提供意見,謝謝.