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

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

※ 引述《guest2008 (guest)》之銘言：
:   直接開新回文
:   1. test case 是否有必要:
:  回想了一下，根本不需要像 T 大一樣大力鼓摧，那個真的就是類似摩托車跟汽車
:  的關係，摩托車跟汽車都可以到達目的地，你認為摩托車真的會比汽車慢嗎??
:  錯！有時候車子塞車，或者找不到停車位，或者xxoo各種因素，結果都是摩托車
:  先到。
:  摩托車跟汽車都是可以到達終點的，要看狀況去選擇交通工具，而不是一意的說
:  汽車就是比較好。而且汽車真的成本比較貴，且貴太多了。
:  結論：請先斟酌專案狀況，不需特別的去擁護 test case 的建立或提出議聲。

        不需要特別去擁護 test case 的建立或提出異聲，
        這點我同意。


        當你知道他好得時候你自然會去用，當你環境不需要得時候你就不用去用。

        但是這跟把 test-case 講成「不現實的東西」來貶低 test-case 是兩回事，

        對你來講沒有用或更直接點講，
        我覺得你不會用的東西，在我的手上是神兵利器，

        你可以不用，但是你也不需要貶低。


        「
 幾乎每件案子都逾期了，還想的那麼美好，還可以有時間寫什麼除錯程式來測試？
 要品質誰沒這概念？ 從工讀生到老闆全部的人都早就有這個概念了，
 重點還是同樣一句話「成本」問題。

        」

        適當寫 test case 可以大幅縮短開發時間，
        你根本就不懂 test-case 的優點，
        還得意洋洋說所有人都有這觀念，我只能說很無言。

        是你貶低了 test-case ，而不是我擁護了 test-case ，這點先搞清楚。
        我並不覺得大家都非得作 test-case 不可，
        我推文也有寫到有些環境的確是不作比做好。


        就跟到現在我還有看到有些地方覺得不作版本控制也會比較省事，

        但是就我所看過得環境包括專案公司跟產品公司，
        test-case 都有能施力的地方。

:  2. test case 缺陷:
:  他只能虛擬的跑程式設計師設計的路線，可是現實狀況跟模擬都是兩碼事，他無法
:  模擬使用者「超天才的行為」，模擬的定義都是想像出可能會發生的狀況，才叫作
:  模擬，類似我們在災難演習，都是演習自認為劇情會這樣走，但災難發生，完全不
:  照劇本走。

        1.test-case 最主要的好處是幫你取代手工檢查，
          也就是讓你很白痴的改code跟一邊按畫面的行為變少，而且是大量變少。


          不是讓你測出所有 bug ，你這些所謂「超天才的行為」，
          如果你 test-caes 寫得時候想不到，你「手動測試」時也想不到。
          到時候一樣災難發生會不照劇情走。

          test-case 不是讓你測出所有 bug       

:  所以你 test case pass 1000個項目不代表程式就是ok..他一樣都是假的，他根本
:  就不是保證，你是老闆，聽到員工跟你講我已經 pass 1000個 test case 千萬別太
:  高興，別被騙了，那只是代表是「已知狀況」，「乖乖狀態」是pass的。


        他的確不是「保證」，
        但至少比你自己手工測自動化相關的 1/1000 測試案例，來得更可靠。

        再者，實務操作上這 1000 個測試案例裡面，
        打到你所沒有想到但有關的測試案例的可能性，

        比你想的可能性高多了。


:  當然你可以在加入更多的測試補盯，好吧..有10個按鈕，我就寫一個模擬使用者
:  按 1,2,3,4,5...., 按 3,2,1,4,5..，少按一次1, .........
:  把所有的狀況全考慮進來...
:  請問你一下你寫這樣的測試程式代價成本划得來嗎?? 還不如人工檢測，幾分鐘就
:  解決掉。

        人工檢測每一次都要幾分鐘，同一個東西你測超過十五次，
        （仔細觀察你的開發環境，一樣東西測超過十五次的機會很多。）

        那就是四十五分鐘

        test-case 寫好了，就是開發 test-case 的時間加上幾個零點幾秒。

        （
          開發 test-case 的時間，剛入門寫 test-case 會寫很久，
          大概投資在上面 20-30 個小時之後就會開始大幅縮短，
          而且這個成本是一次性的，寫過一次以後就都知道怎麼寫了。

          也就是因為有這個前期 gap 的關係讓 test 飽受污名跟誤解，
          但是這個 gap 完全就是一次性的，而且一個人會就可以帶人做了。
        ）


        以後你要增加測試條件，就是增加幾行 code，

        而不是每次都 deploy -> 上 test dev ，
        作一堆蠢 login 想辦法準備一堆資料後作測試。



:  另外一點：test case 只能測試邏輯面或者流程，你寫表單，少寫一個輸入驗證
:  根本就不會影響結果，你的表單欄位沒有對齊也不會影響結果，你的標單 Label
:  打錯字也是不會影響結果，但 Label 打錯字很有可能造成災難，「a0成本」打成
:  「aO成本」，test case 照你的流程跑完是 pass的，你太信任他，結果系統上線
:  就慘了，不管怎樣「人工檢核」這個程序絕對不可以少掉。

        1.你「有想到的話」要測試這些都可以測試，

          如果你「沒想到的話」人工檢核你一樣會漏。

          你假設人工檢核你會測比較多東西，test-case你就會寫漏，
          這樣不是很無聊嗎？

          再者，有了 test-case 你一樣可以用人工去作 review 檢查，
          再把 test-case 的條件補起來，而且這樣效果也會比較好。


          test-case 是幫你省人工，不是幫你把人工弄成沒有。

          test-case 的前提就是幫你省人工作測試，
          而且是作一次以後都可以有一樣的好處。


:  結論: 1. 請建立心態：test case 不是完美的。 test case 要完美還真的也要
:           看寫 test case 這個人的邏輯是否週密，公司把這樣的人才拿來做測
:           試員還真是悲劇。
:        2. 不管 test case 寫的再完善，還是需要做「人工檢核」。


        我跟你說個小故事，以前我剛進 ZK 時，我們是出貨前找 4-5 個工讀生，
        給他們一個禮拜來按完所有的測試案例，讓他們看看畫面上有沒有問題。

        但後來我們發現，這些工讀生對系統瞭解不夠，
        對測試案例的問題也不是很瞭解，來按一按的確可以發現問題，
        但是回報的 false alarm 更多。


        裡面也有我們自己例行在做 QA 的人跟他們一起作，
        但是 QA 的人，只有 14 個人天左右，
        沒有時間把所有測試案例(一千個以上) review 完。


        後來我們改用 selenium 自動化測試，
        就每次發新版前的 bug 回報率數據上來說。

        他比工讀生有效，而且扎實的可以告訴我們問題在哪
        並且確實的避免過幾次不可能由
                非工程師或 QA 等不懂 code 的人發現的大災難。


        所謂的人工檢核，是你心裡保險的最後一條線，
        但承認吧，面對一個至少五六個功能模組以上的 web app ，
        你根本不可能窮舉你所謂「超天才的行為」的前提下去測試。

        人工檢核跟自動化檢核一樣有極限，
        但是自動化檢核可以幫你省掉真的很無聊的測試。

        讓你針對重要的東西先作人工檢核，再換成自動化測試。


        以後都有人幫你把這個關。


        這個案例是作在 QA 期，但是對 dev 來講，一樣可以在開發期，
        由開發者自己找到相關的 test-case 賺到一樣的好處。

        把 test-case 畫給 QA team 去管，也是自斷手腳的作法。

: 3. test case 優點
:  沒有優點的話，他就會從人家蒸發，或者類似 CMMI，只剩下商業利益份子在估吹，
:  買家跟開發商根本不領情。
:  test case 他的優點是建立在「後續系統異動」，當系統結案後，放入硬碟的深層，
:  突然有一天要讓他重新上戰場，且會對程式部份做異動的話，這個 test case 的效
:  益才會真正的產生。

        系統異動並不會只發生在結案，

        你只要有兩個人同時在開發一個系統，
        就有可能兩邊對系統的認知有 conflict ，

        有效的 test-case 可以預警到，
        別人改他以為對得東西但改壞你的東西的情況，這是他最大的價值。

        這件事情根本不需要到系統結案就會發生。


        當然你可能會說整個專案都你自己開發的，這個狀況比較不會發生，
        自己獨立開發的話這個情況的確會比較少見，但是偶爾還是會發生。


:  人的記憶是不可靠的，當你在開發系統時，其實沒有那些 test case 真的沒差，
:  在你的腦袋早就有一堆 test case 在你的腦海內運作，你會很清楚知道，動到
:  A，則 B 也要記得要一併處理，這兩個模組是有牽連性的。

        test-case 重點並不是連動到哪個部份，
        是讓你記住那些所謂「超天才的操作」到底有哪些。

        還有記住「以前你測過什麼」，幫你省這個。


:  可是當案子結案，你的腦袋也會把這件事卸除，過3個月後，你已經淡忘這個系統
:  的一半了，再過一年就整個忘記了，這時候 test case 的效應就會產生了，你改了
:  A, B的 bug 就會在report 上現出原形，讓你記憶起來這件事，
:  「對了..A 跟 B 是有連動性的，我想起來，C的某某地方也要一併處理，要不然
:    會發生啥事情」


        完全不是這麼回事啊，你說得這個是 integration test ，

        但是 unit -test 完全不需要到 integration test 層就能有校。

:  結論：test case 的真正優點是記憶的便條紙，他讓你快速的重新掌握沈睡已久的
:        系統關聯記憶。
:        如果你的系統有要長期抗戰的需求，那這個 test case 還真的不可少。
:        結案就可拋棄了，還是客戶是芭樂屎，不要給自己找麻煩了，快點找下個
:        客戶比較實在。

        test-case 是記憶的便條紙這點是對的，幫你記住所有測試條件這點很重要，
        但他同時也是幫你去作無聊測試的苦力，
        讓你可以從那些你已經測過得東西上脫離，但些都不是到了結案才有用。


        我自己的評估是你專案開發週期，
        只要超過一個禮拜以上，test-case 就能對你有幫助。

        一個禮拜以內的 project 通常都太小了，不作也罷。

--

        Life's a struggle but beautiful.


--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.25.78.26
※ 編輯: TonyQ           來自: 114.25.78.26         (05/27 16:50)
※ 編輯: TonyQ           來自: 114.25.78.26         (05/27 16:51)
※ 編輯: TonyQ           來自: 114.25.78.26         (05/27 17:18)
推 Ting1024:瞭解，看來是我們自己碰到的CASE太少，不知道好處。       05/27 18:01
推 art1:後面錯字變多了 XD                                          05/27 18:10
這就是我為什麼不想回文，最近沒有充裕的時間寫文章...=3=
※ 編輯: TonyQ           來自: 114.25.78.26         (05/27 18:40)
推 thinkniht:但我很喜歡看你的文章:P                                05/27 18:43
推 dnzteeqrq:@@                                                    05/27 18:47
推 ohb:精彩的文章，但問一下，你的"test case"其實是專指automatic    05/27 20:56
→ ohb:test cases吧?                                               05/27 20:56
→ TonyQ:應該說，這篇文章講的是可以由程式執行的 test               05/27 20:57
→ ohb:那我懂了  不然我想說你的名詞定義和我所以為的不太一樣..      05/27 20:58