---

        昨天去參加活動跟幾個朋友談到測試，覺得幾個點值得專文記錄下來。

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


        首先 這篇文章不是要說測試有沒有用，測試值不值得作，不是要戰這個。


        當然有興趣要戰的可以自己開砲，但是我先說我沒有要戰這個的意思，
        純粹是分享作測試的幾個階段跟心情。


        這篇文章廢話多心得少，加減看就是了。

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


        然後基本上我們談的都是工程師如何面對程式碼的自動化測試，
        不是講專案的測試，也不是講測試方法論。

        （聽不懂我在講什麼往後看就知道）

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


        我也不假設你會怎麼樣看到測試這個名詞跟怎麼樣進入測試領域，


        我覺得測試這塊太多雷就是別人都會告訴你測試很好很讚怎樣，
        或者是給你一個很適合用測試的情境告訴你測試的好處，


        但是你會發現，(呃)，我拿到我的環境開始寫測試就完全不是這麼一回事。


        因為別人都在說，所以你覺得他好像是有用的，
        但你可能根本不知道怎麼寫你的測試，你可能不知道你要測什麼。

        你試著去做了，但是你不知道你獲得了什麼，
        然後你開始想，你是不是作錯了，


        然後你可能感覺不到他帶來的好處，於是，你就放棄了，

        你覺得測試是浪費時間。


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

        我不會用可惜來形容這件事情，因為你確實從過程中得到了經驗，

        有時候，我會認為你甚至可能是對的，
        你的確花時間在寫沒用的測試，只是那並不浪費時間。（原因後述）



        我希望盡量從我的經驗中抽出大家可能會有共鳴的部份，
        帶大家走一次我經歷測試的感想。



        我只說，我當初是怎麼開始想寫測試，經過哪些問題，
        撞過哪些雷跟我現在的想法是怎樣。


        因為時間有限再加上這不是個嚴肅的議題，
        我會用輕快的風格帶過以下的文字，

        希望你也可以感受到測試並不是個沈重的主題。:)



        然後我也必須要先說明的，

        測試是一個很有爭議的題目，
        有些我認同的見解或者我的經驗不見得是對的，歡迎挑戰跟更正。

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


        Let's get started.


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


        ok，首先我以前一開始寫程式是寫 Java 的，


        一開始時我寫程式都是寫新手級的小功能，
        有個 main method ，要使用者從 console input 一堆東西，

        然後我去印出對應的結果。


        因為我不可能找出我當初到底寫什麼，所以我舉假想例子。

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


        比方說新手入門題，

        停車場收費一小時五十塊，三小時以上打九折，六小時以上打八折，
        使用者輸入停車多少分鐘我幫他算出他要付多少錢，未滿一小時的算一小時。

                                （不要小看新手入門題，
                                  你以為我現在寫的小單元除了畫面漂亮點，

                                  需要存檔到 DB 以外，
                                  邏輯上到底比這個東西複雜到哪去？）


        這時候我就要開始寫程式啦，我用虛擬碼寫，大家將就著看。


        main(){

                //假設使用者輸入一行資料（停車幾分鐘）並轉數字
                //並假設使用者都是善良user，不會輸入英數字

                int k = console.getInt();
                int hours = ceil(k/60) ; //除60並且無條件進位
                int money = 50 * hours;

                print(money);

        }



        這時候我發現，我寫程式我需要程式他到底會怎麼作，
        我需要知道使用者輸入數字時系統要回傳什麼，


        於是我會開始累積測資：




        夠眼尖跟夠經驗的都知道，一開始的測資，
        不可能這麼機車剛好都在邊界值，一定都是順手亂打，



        所以，換句話說，如果我沒有想到有其他可能性，我就不會去測他。（竊笑）



        我沒有要表達什麼，就只是陳述一件事情。:)


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


        所有寫過程式的應該都知道我在講什麼，以上面的例子，
        每改一段 code ，你可能就會key 1，key 61 來測系統回應對不對。

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



        然後眼尖點的，會發現我剛剛的程式碼有bug，測到 181 的時候會出事，

        但是我一開始寫完時沒有想到要用 181 的測試資料去測試，
        那這隻就會是 bug ，一直到使用者測試，

        並真的碰到這條件了，我才會知道。


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


        如果你有寫程式經驗或者看到別人的介紹，
        你大概這時候會期待我說抽 method ，

        寫 unit test ，跑 unit test。



        但是我說了，我只是分享我的經驗，
        而我的經驗是，我一開始會寧可用手打。

        因為我剛寫程式很興奮，跟 console 多點互動會有滿足感。（咦）



        有時候自己當當假想中的蠢 user 其實是蠻爽的（無誤），
        一開始就要把東西變成一版一眼的 input/output 其實蠻無聊的。


        什麼可靠性阿，什麼穩定性阿，

        我還不是要花時間想一堆很機車的測試案例，
        我後面可能還有別的好點子要做，這功能隨便就好啦。


        最後還不是活人要用，我當當活人測測有什麼不好？


        （註：我這裡隱含一個判斷是，這段程式碼我對他很有信心不會錯，
              或者說我認為我對他的操作已經涵蓋大部分的使用情境，
              我對他在大部分的狀況下有信心。


              另外我假設這裡有邏輯 bug 並不會導致使用者或我散盡家財，
              不然寫個程式一下就因為 bug  game over 對新手也太可憐了。XD

                                                                         ）

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


        結果這東西就上線給使用者用了，
        糟糕，使用者回報輸入超過三個小時有問題。



        簡單嘛，小問題，我改改

                int hours = ceil(k/60) ; //除60並且無條件進位
                int money = 50 * hours;

                if( hours > 3) {
                        money = money * 0.9;
                }

                print(money);


        .........

        我又打了一次測試資料，然後我只有個模糊印象記得我上次測啥，
        好像有 1 61 121 ，

        糟糕，那這次要測什麼？


        還好使用者有告訴我 188 是有問題的，
        耶我不用自己想測試案例，真開心。 （使用者在你背後，他非常火）




        然後再測測 188 ，正確。（你安心的過板跟跑去回使用者信）


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


        然後，就沒有然後了。


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


        如果你有認真看程式碼，你可能會問我，那使用者停車超過六小時咧？

        那 bug 就放著不管嗎？？



        對，因為這個停車場是一個內用限時三個半小時餐廳，

        並且不准外人停車的停車場，
        所以上線以來沒有使用者會停車超過六小時的情境。



        （欸，你這也凹太大了吧...那你題目訂個屁啊。）

        囧，（假想的）餐廳老闆就在我寫完程式後，
        才訂了這個內用不能太久的規定。

        我寫程式時也剛好恍神沒想到這條件，怪我囉？




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

        以上案例真的就結束了，跟測試的關係是？


        1.測試資料跟希望的測試結果是人想的，而且它是測試中最重要的部份，
          而且更重要的是，不管寫不寫 unit test 或什麼鬼 test，

          這都是你的責任。


          測試不會因為你有作就自動變滿分，決定測試成效的人是你。

          另外，因為你跟其他寫程式的人終究都還是個人，
          你可能寫久了就不會像剛剛那個程式開發者（我）那麼散仙，
          連題目有寫的條件都忘記要寫要測，但是你還是可能會打錯字但沒測到。



        2.以測試而言，經過市場（使用者）測過的東西是以結果而言最可靠的，
          因為過了那關其實你也就不用太介意別的東西了，

          六個小時以上會有問題，so what ，反正現在能用，
          以後用餐時間規定又改了也不是你的錯，總有人會去 debug 。（囧）


          但是因為使用者跟後面接手的開發者會生氣說你壞話，
          所以作人還是要自我要求一下，只是那就無關「目前」的產品品質。

          而是「未來」的產品品質，所以如果一個產品沒有未來...


          當然，現實世界這種好事不多，
          多得是上 production 之後，題目沒寫到的潛規則跑來找你麻煩。



        3.test 我們本來就在做了，沒有開發者不需要作 test。



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


        因為我下午有事要出門，就先賣個關子，

        晚上再來寫（二），預計會寫到三、四篇，
        請大家輕鬆看待這個系列文章，不要太嚴肅。XD


        我不預設任何立場，只是分享經驗，以工程師看軟體測試而言，
        會看見什麼東西，更多的是你寧願相信什麼。:)



        注意，我這裡講的都是工程師自己如何作/練習軟體測試，
        不是一個專案要怎麼測試，怎麼確保專案上線有品質，那是兩回事。

--
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 111.80.200.204
※ 編輯: TonyQ           來自: 111.80.200.204       (03/24 13:46)
※ 編輯: TonyQ           來自: 111.81.205.78        (03/24 21:30)
※ 編輯: TonyQ           來自: 111.81.205.78        (03/24 21:31)

--