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

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

※ 引述《semop (semop)》之銘言：
: ※ 引述《guest2008 (guest)》之銘言：
: :  結論：請先斟酌專案狀況，不需特別的去擁護 test case 的建立或提出議聲。
: 其實反過來說，如果要製作高品質的軟體，測試反而不是重點。
: 完善的軟體架構，特別是內建的驗證、確認和錯誤處理程序，才是最基本的工夫。
: 所有支持測試的論點，都可以用在軟體架構的完善之上。
: 比較極端的時候，這部分可以佔到程式碼的三分之一，就是要追求任何問題，
: 都不能延遲到問題發生的地方之外，才發現和處理。
: 所有系統問題都有內建的錯誤處理，所有輸出入都有內建的資料驗證，
: 所有操作流程都有內建的狀態檢查，所有程式碼都要經過人工的 code review...

        前公司是人工 code reivew 跟 CI 並行，

        code review 可以幫忙解決一些問題，但經過人工 code review 的東西，
        再經過實際 test-case 跑來測試，效果會有加成的好。

        code review 可以避免蠢問題，但一樣不是「沒問題」。

: 嚴謹的開發過程，本身就是最佳的軟體品質增進辦法。
: 這時 test case 的必要性就非常低了，例如資料輸入都已經統一經過驗證程序了，

        你的架構仍然需要驗證，所以你需要 test-case 。
        有 code 就需要驗證，test-case就派的上用場。


        你資料通過「驗證程序」，假設你講的是 data validateion，
        data validation 的 code 一樣需要經過驗證。

        你怎麼知道你今天寫得這個 regex 或這個驗證條件是對得呢？
        會不會你根本就寫錯驗證條件，code reivew 也沒發現呢？


        這是有可能會發生的。


: 再餵入擺明通不過驗證的資料，有什麼意義呢?

        validator 自己也需要驗證，

        另外通常會餵通過驗證跟不會通過驗證的資料，
        succee test 跟 fail test 一樣重要，

        因為要確保 fail 是真的 fail ， succee 是真的 succee ，
        不是我不小心寫了個 if(true) 所以怎麼樣都對。


        這當然有意義，所有 test-case 的書都會提到這件事情，

        我不太理解對這種基本原則跟基本方針都不知道的人，
        到底是在跟我們談什麼樣的 test-case 。


: 以前的程式設計就是這樣的，完全不做外掛的自動化測試程式，
: 有什麼需要檢查的地方，就通通寫入程式當中，除非是一定要人工判讀的結果，
: 但那就表示軟體的設計本身就有問題，才會輸出這種東西。

: 現在有些人提倡 test case, 是為了要快速開發卻又要減少 debug 的不確定性，
: 所以付出一定的檢測成本來達成這個需求，但並不是所有狀況的最佳做法，

        如果你說得是把所有的 error state 蒐集起來，
        做好完善的 guard statement 確保東西出包了都會運作，

        出包了都會有個「回報給 microsoft」的 ui（笑），
        那你說得也是一種軟體開發的方法，但不是一種作 test-case 的方法。



        那如果你說程式碼裡面塞滿一堆 warn 或 error log ，
        在狀態有問題時叫給系統聽，一樣不是一種作 test-case 的方法。


        test-case 是自己準備好 input - output ，
        去驗證可預期的資料範圍內出什麼事情，

        不是丟著等人家來跑，完全是兩回事。


: 主要是應用在商業系統開發和維護上。
: 而在目前輕量級的軟體形成潮流，且相當重視創新價值的時候，
: 由於軟體價值的不確定性高，軟體可能非常有價值，也可能一文不值，
: 就又出現完全不搞測試的做法，先儘可能用最低成本快速開發，
: 確定軟體具有商業價值，再投入較高成本重寫有較高品質的新版本，
: 就是另一套很多人提倡的新做法了。
: 總之，歷史上從來沒有任何一個軟體方法，適用於所有的可能狀況，
: 這就是所謂的 "No Silver Bullet" 的原則了，要提倡什麼方法都好，
: 但請先確定適用的領域和前提，不要太過度相信特定的軟體工程方法了。


        其實這個問題是不需要談 startup 或產品開發的，
        純粹就是「寫code」這個開發階段，可以解決的問題。


        如果一樣的需求、一樣（可能會變動）的目標，
        有作 test-case 可以讓你縮短專案的開發時間 1/5 ，

        並且讓你開發起來更心安，
        你需要考慮他是 startup 或產品開發的專案嗎？


        不需要，對吧？


        你們談 startup 跟產品開發有差異的前提，
        都是 test-case 賺的是後期跟不改動下才賺得到的成本，

        但不是的，他在你一定的開發週期（三週以上），就有機會賺回來了。


        這麼說好了，把用人工測試的東西，盡可能的改用機器測試，
        只要人工測試的時間會大於寫 test-case 的時間，就是有賺。

        這樣能節省下來的時間，遠比你們想像的多很多，這純粹是經驗談。



        當然，我同意「沒有銀彈」的說法，

        碰上一個認為「寫 test-case 只是浪費時間」的人，
        或者是寫 test-case 就是要寫到「程式沒有 bug 」的人，
        碰到一個「test-case 好神好厲害所以非得要寫 test-case 」的人，

        這都是會賠時間的。


        所以開頭的那篇文章，我只想說如果你用這種心態作 unit-test，
        即使給你 50倍的錢跟五倍的時間，你也作不懂 unit-test 的好處在哪。


        因為你一開始觀念就不是在賺時間，要窮舉的狀況下，
        人工跟 unit-test 都一樣是做不完的。



        但是碰上會用的人，知道哪些容易會一直進行手工測試的人，

        比方你剛剛說得 form validation  如果沒包元件的話，
        通常是最容易會有 bug 跟需要被測試到的東西之一。

        這賺起來的時間是你不能想像的多。


        我只能說， unit-test 現在的地位大概就跟當年的版本控制一樣，
        當年一堆人亂用版本控制，拿它當 ftp 用，還怪版本控制太慢太麻煩。XD

        現在 unit-test 的狀況，確實也很有這個味道。


        ---------------------------------

        Anyway ，我無意說服你們用它，
        開發工具這種東西你不喜歡就是不喜歡，

        但是這跟他適合 startup 或者適合大型商業專案沒有關係；

        我用它只是因為他可以省我時間，
        如果你覺得他不會省到你時間，那你可以不要用那是你的自由。


        但我要說的是一樣在 startup 或專案公司，
        這東西我都引入使用過，都有得到效果。

        你們說得理由不是真正的理由，那只是一些常見的迷思。


        你們並沒有論述到 unit-test 真正的問題核心，
        unit-test 真正的問題核心，我認為是「人」。


        想要窮舉所有測試案例的「人」是不現實的，

        想要用 test-case 測所有東西，完全倚賴 test-case 的人是不現實的，
        寫了 test-case 之後就不去檢視 use-case，
        就不會從使用情境中找到新的 use-case （這是我們在手動測時常做的），

        這樣的人都會害專案花時間。


        能夠用 test-case 來節省自己手動測試的時間，
        並且不在那些自己不太會手動測試的地方寫 test-case 的人，

        會幫專案賺很多時間。


        但這些東西都是「現實的」，就是有人可以這麼用，
        而你們只是沒辦法想像跟拒絕去使用而已。:P


--
對我來講，寫 test-case 就像是：
「雜事交給不重要得工讀生去作，我可以專心而安心的去面對重要的事情。」

btw 軟體開發我覺得最大的問題也是「人」，有神一般的架構也擋不了笨隊友。
--

        Life's a struggle but beautiful.


--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.25.78.26
※ 編輯: TonyQ           來自: 114.25.78.26         (05/27 16:46)
※ 編輯: TonyQ           來自: 114.25.78.26         (05/27 16:53)
※ 編輯: TonyQ           來自: 114.25.78.26         (05/27 16:54)
→ Ting1024:精彩                                                   05/27 18:02
推 art1:推！！                                                     05/27 18:15
→ andymai:test case另一個問題是:原來的程式改了，所以test case也   05/27 21:10
→ andymai:要跟著改，有多少個 test case 就得改多少個~除非...test   05/27 21:11
→ andymai:case 能自動跟著修改的程式動~這樣頂多改改輸入和輸出...   05/27 21:13
→ andymai:但是怎麼樣都不能否認它可能會造成另一個維護的工~另一個   05/27 21:13
→ andymai:寫錯的程式~這樣花費的時間對那些頻頻更動需求，吃到飽的   05/27 21:15
→ andymai:工程師來說~是好是壞...可能到最後還是得看客戶來決定      05/27 21:16
→ TonyQ:你可以換個角度想，你改了 code 你一樣要手工重測一次，      05/27 21:41
→ TonyQ:與其說是維護那個東西，倒不如說是把舊的test-case砍掉重寫   05/27 21:41
→ TonyQ:如果你寫 test-case 跟手工重測差不多了多少，重寫一個也一   05/27 21:41
→ TonyQ:樣賺得到時間。不要只看他增加的時間，要看他類比的對象。    05/27 21:41
→ TonyQ:再者如果介面切的乾淨，基本上舊的東西不太有機會動。        05/27 21:42
→ TonyQ:真的動了，就表示也真的你就是改變行為，本來就該review （   05/27 21:42
→ TonyQ:類比手工重測）。                                          05/27 21:42
→ TonyQ:所以這不能算是 test-case 的問題。                         05/27 21:43
→ TonyQ:這也是常見對 test-case 的迷思之一。                       05/27 21:43
→ TonyQ:既然提到了，所以就要也提一下， test-case能寫多快就是重點  05/27 21:48
→ TonyQ:基本上都有些方便的工具可以幫你作這些事情，只是需要練習    05/27 21:49
→ landlord:同意TonyQ說的，透過自動取代人工，且可重複使用          05/27 21:59
→ landlord:人工時間成本與誤差成本*n 跟 撰寫自動測試成本*1 來比    05/27 21:59
→ landlord:n夠大，就划算。這個夠大，基本上>=2就夠大了。           05/27 22:00
→ landlord:也的確不是所有場景都適用自動測試。                     05/27 22:00
→ landlord:所以懂得選擇場景, 在對的時候事半功倍，這就是價值       05/27 22:01
→ landlord:如何降低自動測試的開發成本與維護成本，也是一門功課     05/27 22:01
→ landlord:而且是一門很值得投資的學習課程                         05/27 22:01
→ andymai:但是這建立在"寫 test case 跟手工重測"差不了多少的情形   05/28 00:55
→ andymai:下~而且...這個 test case 不能太複雜~不然...到時候可是   05/28 00:57
→ andymai:兩邊都要debug...                                        05/28 00:57
→ TonyQ:本來寫 test-case 就不應該跟手工重測差很多或很複雜。:P     05/28 01:22