---

        前情提要，這是寫給軟體開發者的測試歷程，

        主要是以我自己進入測試的經驗說明如何進入測試門檻，
        以及我身為軟體開發者進行軟體測試時需要知道的事情跟可能的心路歷程。

        所有的內容都只是個人經驗僅供參考，歡迎提供意見分享跟挑戰。

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

        另外這裡所指的軟體測試都只是主要針對者自己對軟體的測試，
        而與專案測試（目的為增加專案品質）的目的並不直接相關。


        也就是說，這裡講的主要目的，是開發者如何可以在開發過程，
        快速驗證自己的修改是否有誤跟常見的一些問題。


        -----------------------------------
        本文開始
        -----------------------------------



        到目前為止我們依序描述了幾個情境，


        1.我寫了一個簡單程式，我要驗證他的結果是不是對的。

          我需要：測資。


        2.我寫了一個複雜程式，我需要一直測試系統的某個部份是不是對的。

          我發現：測試路徑跟測試路徑優化


        3.我發現我測試的過程，常常需要修改程式碼才能加速、優化測試路徑，
          然後發現有時候改的多，有時候改的少，有時候甚至測不動。

          這時候我知道，程式碼有可測試性。


          而我將開始研究起如何讓代碼更有測試性。


        4.我從這些過程中開始發現，測試程式碼時，
          常常需要撰寫特別的測試程式碼，這些程式碼如何管理，
          如何讓測試程式盡量避免影響程式，也會是一個大問題。


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

        什麼是我們沒有說的：

        1.我們沒有說單元測試 (unit test)
        2.我們沒有說自動化測試


        我認為他們在你還沒掌握可測試性之前一點都不重要。


        如果你連改 code 測試都做不到，
        那就更不用討論寫 unit test 這種必須從抽象視野才能作得事情了。

        而且時候還沒到，在這個時候，
        我們還看不出來單元測試跟自動化測試的好處在哪。


        如果還不知道好處，甚至是連想像都想不到好處，
        那我個人認為與其從中貿然進入，倒不如先從改善手邊流程著手。


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


        我們即將繼續往後走，繼續討論更多的開發案例，
        並且發現更多開發過程伴隨而來的測試觀念。


        之後我們還會回來再來談可測試性，但現在我們要先往前走，
        因為可測試性也並不是我們關注的全部。


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


        討論可測試性的要點之前，
        我要繼續先帶入更多的測試看法，

        那就是「測試權重」。(Test Priority)


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


        我們這裡談的是開發上的測試權重，而不是專案的測試權重，


        專案測試是期待有高品質的專案，但開發測試，
        則主要是希望能加速開發者工作流程。（測得快自然寫得快。）


        專案測試是希望測試能完整，能夠測到所有情境，

        並且達到至少跟原本一樣的開發效果。



        專案的目的不見得總是跟開發的目的相合，
        我們之後也會專章討論專案測試，現在還不是時候。



        所以我們這裡的權重主要的判斷依據，

        並不是這些程式碼對專案目的真的有多重要，
        而是這些需要測試的程式碼對其他的程式碼有多重要，

        也就是你今天萬一改壞了這東西，後面會影響多大程式碼。



        以開發者而言，專案的測試權重比較難定義，
        但開發的測試權重則相對單純。


        我們每一段程式碼被呼叫的次數是顯然會有很大差異的，

        有些很冷門的情境可能久久才被呼叫一次，
        有些程式碼屬於別人依賴的資料來源，自然就會影響比較大。


        一般而言我是用使用者的最常操作路徑，作為優先權重的第一個要素，
        也就是使用者最常走的路。（通常都是 default 值造成的路徑。）

        以 blog 類型的專案而言，
        最多的操作顯然是顯示文章、登入系統、新增文章、修改文章，

        其他的像是 sidebar 的操作、 theme 的編輯、留言管理等，
        相對之下就會是次要權重的操作。



        再來就是以程式庫的相依性，

        以網頁專案而言，ORM / DAO 的東西雖然單純，
        但是以影響而言則沒有什麼東西比他們影響更大了。

        下錯一個 SQL 你後面的顯示資料可能會完全不對，
        本來要算平均值的妳下錯下成最大值，大概也不見得有多少人會發現。


        一個類別被越多的地方呼叫，目的越多，他的測試權重就越高。



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



        我舉我的 Eclipse plugin 專案 (Run-Jety-Run) 為例，


        使用者的使用情境是，他們會用這個工具開啟一個 web server ，
        然後跑他們的網頁專案進行瀏覽。


        而這個 web server 會先需要建立一個 Run Configuration （執行設定檔），

        其中有提供超過 20 個選項可以設定，但是根據非正式統計，
        有八成的選項只有 10% 不到的使用者使用過。

        有一些選項甚至是 undocumented feature（主要使用者就是我 （笑））。



        舉個例子，其中有個功能叫 SSL enable，可以提供 https 協定作為測試，
        但是絕大多數的開發者不會需要用到 Https 。

        我自己用這工具一年半了，我也從來沒用過，
        所以對我這開發者來說，他的測試權重是相對低的。


        或者我應該這麼說，即使他今天是壞的，使用者也還有其他替代方案，
        對開發者/使用者來說也不痛不癢，它是個可以被放棄的 feature 。



        當然，站在開發者立場我們是魚能撈的盡量撈，

        但是如果資源不足，像這個專案只有我一個人在維護，
        平均每週只能吃我六到八小時，那我們還是得要挑重要的事情作。


        開發是這樣，測試當然更是這樣。

        測試是有權重的，而他的權重通常就跟開發的權重一樣。


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



        有個時間管理的法則是這樣說的，把事情分成四種。


        緊急且重要              緊急但不重要
        不緊急但重要            不緊急也不重要


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

        在這裡我則是把測試分成四種，


        簡單且重要              簡單但不重要（Ex. getter/setter)
        不簡單但重要            不簡單也不重要


        這裡說的簡單是說寫 test case 的簡單程度，
        而這簡單與否便是我們反覆強調的可測試性，

        會隨著程式碼品質跟開發者能力而變化。


        其中有些東西天生可測試性就是低的，
        什麼是不簡單的 test case 我們之後會慢慢介紹。


      （一次只說一點點，這個主題才說的清楚，
        即使拆開來看，很多東西可以挑戰，
        但是當所有主題講完時就會相對清楚了。:P）


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


        以測試的目的來講，如果讓我再重來一次，
        我會說，寫簡單而重要的測試；


        一個 test case ，如果你不能在一個小時內寫完一個，那就不要寫了。



        我過去就是花了太多時間寫「不簡單但重要」的測試，
        而且這個重要很有可能隨著需求變更而變成「不重要」。


        如果這個測試對你來講寫起來不簡單，
        那你應該要記在心裡偶爾想想為什麼難，
        有空閒或有碰到前輩時，再一次的來 review 更適合的方法，


        但盡量不要一頭熱就栽進去想寫測試，
        往往你只是繞一大圈作手動測試很簡單的東西。

        切記不要貪圖測試的好處而卡在「不簡單而重要」的測試上。



        如果寫 test 賺不到比你開發手動測試更多的時間，
        像是 test case 每次你修改程式碼時都要異動，那就不如不要做了。

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

        我可以說我在這點上自認幹過最大的蠢事是什麼。


        玩 web test 的大概都對 seleinum 不陌生，
        敝公司全面導入 selenium 對元件進行自動化測試已經快兩年了。


        PS. 當初一開始它是不被公司看好的，是我主管跟我幾個死忠派的人，
        自願協助並力挺到他開始發揮效果，現在已成為敝公司最主要驗證工具之一。

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


        一方面是當時我還是公司內的新人，又算是 JS debug 經驗還可以，
        另一方面也是我個人興趣，所以被指派去撰寫 test case，

        再加上自己閒暇把時間丟進去作，大概前後也累積至少有兩三個多人月。



        Selenium 1.1.2 官方要升 selenium 2.0 時，
        也就是正在改很大的要跳 web driver那時，

        IE9 剛出沒多久， chrome 也拼命在追版本，當時也還改很大。


        IE9 Selenium 支援還很爛，
        drag and drop 跟相關事件根本沒辦法在 ie9 測，

        我們雖然當時已經有專門的 VM 搭配 hudson 在作自動化測試，


        測試 IE6, IE7 ,IE8 ,FF3 ,FF4 ,Chrome , safari 5 ，
        印象中大概一千個 test case 全瀏覽器跑完只需要四五個小時。

        （時間都浪費在啟動 browser ，
          後來我有用一些點子作 finetune ，讓時間縮到只剩 1/5 。:P）



        阿我說的蠢事是什麼？

        因為 IE9 支援壞掉了，我為了要自動化測試好處，
        缺 IE9 總覺得可惜，而且他確實是重要的。


        我跑去 debug selenium，把他的 js 解出來一隻一隻看，
        selenium code 是 java base跟js ，程式碼有點髒但不算難懂。


        花點時間了解 selenium 原理，也對 IE9 打 patch ，
        但是代價實在是太高了，我花了快八個工作天才搞定這件事，

        結果 IE 改個版上個更新，他就又壞別的東西了。Orz


        最後還是要放棄 IE9 一部分的測試，人森啊...


        而 dnd 的 test case 大概只有 50-100 個（估計值），
        如果我犧牲掉 IE9 上那一百個 test case，

        把那八個工作天拿來寫別的 test case ，
        我大概可以多寫出至少幾十個 test case，對整體的效益算起來會更大，

        後來還被噹說花時間結果作白工。（囧 XD）


        ps. selenium 2.0 換成 web driver ，是有穩定一點，速度也有變快，

        不過最近換 firefox 最新版測不動了，還是奉勸要 debug selenium 的人，
        還是把時間花去寫別的 test case 吧。囧



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

        總之，寫 test case 我認為是寫那些重要，而且寫起來很快的測試。

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


        如果你的測試寫起來不快，你該檢討的是你的開發方法跟程式碼品質，
        或者是你該注意的事情是那個對象是不是很難測試的東西。


        我們之後的章節也會探討哪些是難測試的東西，
        跟一些因應而生的測試工具，測試工具的面貌有很多而且很有趣的。


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


        希望你看完這篇之後，能了解「不是所有東西都需要測試」。

        你幾乎不可能窮舉整個系統進行測試，因為那測試組合將是天文數字。



        本篇介紹的是測試權重，下篇我們將回頭探討重新可測試性。




--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 114.25.104.110
※ 編輯: TonyQ           來自: 114.25.104.110       (03/27 23:56)
※ 編輯: TonyQ           來自: 114.25.104.110       (03/27 23:58)

--
※ 編輯: TonyQ 時間: 2012-03-28 00:07:28