---

        前情提要，這是寫給軟體開發者的測試歷程，
        在笑談軟體測試的幾個階段（一）中我們提到測試的基本形式，


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

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

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

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


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


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


        就像先前的停車場計費程式，我們慢慢寫了很多程式，





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

        假設現在我們在做一個部落格系統好了，
        我今天已經寫好後台可以發文，

        發文時我需要提供編輯器給使用者輸入，
        還要讓使用者可以做一些刪除或修改的操作。


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


        我們一開始開始會一直用測試的『完整環境』做測試，（重點一）
        測試程式碼的運作，然後我開始發現，測試有點麻煩。



        某些重複的程式片段我會發現我測試很多次，

        有時是它很重要跟複雜，像發文的編輯器特別容易出問題或修改；
        有時則是它很重要大家都要用，像是很多功能相依於會員登入。


        這些片段改程式碼特別容易測到，
        就每次都在測一樣的程式，感覺就很瑣碎而無聊，

        特別是登入，我可能根本就沒有改那段code，為什麼我要測他？


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


        然後很重要的是，我也不總記得上次的測資，應該說，我很有可能會忘記。
                                                        （重點二）


        ---------我的現況是這樣，看起來是個困境，那我怎麼辦??---------


        你可能還是會期待我會說拆 method 跟 unit test ，
        然後補一句視狀況採用跟引入這種我自己也覺得有講等於沒講的廢話。


        好像這樣事情就結束了，這些話我很常說，它是政治正確的，
        但問題是，聽的人在這些話的訊息中收到什麼。



        平常講話是真的沒辦法，因為三言兩句我也講不出個屁，

        要講經驗我後面有一票的前提論述要講，
        還要先看看對方用的語言我有沒有經驗，像講 C++ 的測試我就囧很大。

        要講故事沒個五六小時是講不完的，不過寫文章就不一樣了。


        我寫文章很重視實戰，就是因為這種東西只有實戰體驗過，
        你才會有點體悟那些心法在幹嘛。



        特別是這種心法是可以各自表述。


        舉個例子，今天有人說『你寫的 java 程式不 OOP』，
        你真的能從『不 OOP』這四個字知道他想表達什麼，要怎麼修正嗎？


        你可能會因為這樣賭氣跑去讀 OOP 的書，
        然後試著把學到的東西用到你專案，多用了幾個模式跟切分類別，

        然後很開心的說我程式更 OO 了。（事實上是不是就另外一回事。）


        結果你可能一輩子不會知道，
        人家只是在嫌棄你寫類別時沒有寫 Getter/Setter 。

        (註：這曾經是 OOP 議題中很重要(無聊)的爭論之一)
             http://0rz.tw/3T9d0



        拿心法等級的名詞互相 PK ，
        大概也是趕雲端流行的一種做法，我是覺得作事不用這麼複雜啦，

        有時你必須承認我們真的很難明白別人的明白。


        因為他們的經驗跟心法，不是你的經驗，而且測試是一體成形的。（後述）

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

        扯遠了，拉回主題。

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


        我們剛剛有個困境，那我們現在要來試著改善他了。


          註：改善的過程不見得每個方法都是好的，
              但我的信念是有嘗試就是好事，有嘗試就會有收穫跟所得。


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

        我是懶惰的人，我痛恨無聊、重複而且不必要的事情。


        我寧願花五倍的時間寫個有趣的 template ，
        我就是不想乖乖好好一行一行 cp 當 code gen。


        我寫程式的心法就是上面這句話。

        （覺得這樣是好是壞是個人自由啦，
          有時候它真的可以省事，有時候它又會誤事。XD）

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



        首先我是想辦法設計成，我自己測試時可以跳過登入頁面，


        我嘗試設定，「測試環境」啟動時在session 先塞測試帳號假裝登入，

        以 java 來講就是寫 filter ，
        以 php 來講就是先 include 一隻php。

        (從這裡我們可以看出語言支持度跟特性會影響開發習慣很多。)

        這樣的確很有效，我瞬間省了好多測試時間，
        但問題來了，如果我上線時忘記把測試程式拿掉就完蛋了。


        所以我要想辦法建出 debug 環境，



        但是即使是最蠢的方案都可以幫我每天開發，
        省下幾分鐘到一兩小時的測試過程登入的時間。


        Ok , it works.


        但是這樣也有別的缺點，

        1.它跟真實的環境有出入
        2.要是登入真的壞掉了你也不會發現
        3.你要小心不要弄錯環境XD
        4.如果登入的程式碼有變的話，你可能也要跟著修改。



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

        測試資料的管理的部份，我會在程式碼中留下測試資料的註解，

        特別是 regular expression ，


        所以當這些紀錄薄弱時，

        我們也會特別倚賴團隊中資深成員進行「觀落陰」，

        從無邊地獄中用力回想當初的測試情境。



        最後真的不行就是走逆向工程，他會用到什麼，
        你就想辦法整他惡搞他自己想辦法丟東西測。


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

        我們第二篇的案例先講到這，
        至於那些異動頻繁的程式區塊，我們留到第三篇談。


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



        ok，

        第一篇我們講的是一個簡單的範例，
        第二篇我們講的是複雜的範例，

        從第二篇我們談到的事情裡面，有哪些測試的要素？


        1.測資的問題

          我們第一篇強調過，測資是一切的根本，

          而這篇我們開始提到，測資是需要被管理的，
          測資的有效/可靠程度就跟你程式的穩定程度跟開發效率成正比。


        2.測試路徑問題

          每個測試的過程中你需要作的操作，我稱之為測試路徑。


          測試路徑決定你的測試效率。


          最佳化你的測試路徑是開發過程中很重要的事情。
          （像是想辦法把登入這個過程跳過）


          這其實不只是程式碼的問題，比方說你 server 啟動要十分鐘，
          那你就應該挑一個 server 啟動快一點跟方便一點的設計。



        3.文章中有特別對「完整環境」這件事情下重點

          在測試的範疇裡面，我們把最接近使用者的環境測試，
          也就是 dev server 或 dev environment ，

          稱之為整合測試。 (Integration test)


          這種狀況下，你有可能被其他的因素干擾，
          舉例， db 如果掛了你登入可能就就整個沒辦法測試。

          整合測試的重點在於他是盡量要達到測試最接近真實的情境。


          當然這裡我們還沒有要對 unit test 跟 integration test 多著墨，
          但是我想說的是，通常我們一開始進行的測試都是整合測試為主。

          為什麼會這樣，我們之後的章節會繼續探討。



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

        下一篇，我們將延伸這篇的主旨，
        繼續探討其他案例下，測試路徑跟測資的問題。


--
--
※ 發信站: 批踢踢實業坊(ptt.cc)
◆ From: 111.81.205.78
※ 編輯: TonyQ           來自: 111.81.205.78        (03/24 23:16)
※ 編輯: TonyQ           來自: 111.81.205.78        (03/24 23:16)
※ 編輯: TonyQ           來自: 111.81.205.78        (03/24 23:17)
※ 編輯: TonyQ           來自: 111.81.205.78        (03/24 23:21)
※ 編輯: TonyQ           來自: 111.81.205.78        (03/25 01:06)
※ 編輯: TonyQ           來自: 111.81.205.78        (03/25 01:08)
※ 編輯: TonyQ           來自: 223.143.225.151      (03/25 22:51)

--