[產品開發]能相信的只有測試過的程式
之前去聽Ruddy老師的課程時，老師問了一個問題：『我們相信local端的程式還是雲端的程式？』
這個問題的答案帶點詼諧：『我們只能相信測試過的程式。』
聽到這句話讓我會心一笑，是的，我們能相信的只有有測試過的程式，而且是在『Testing環境』中測試過的這一個 assembly、component，我強調Testing環境的那個assembly、component，為什麼？下面我來說明一下前因後果。
之前去聽Ruddy老師的課程時，老師問了一個問題：『我們相信local端的程式還是雲端的程式？』
這個問題的答案帶點詼諧：『我們只能相信測試過的程式。』
聽到這句話讓我會心一笑，是的，我們能相信的只有有測試過的程式，而且是在『Testing環境』中測試過的這一個assembly、component，我強調Testing環境的那個assembly、component，為什麼？下面我來說明一下前因後果。
還記得我剛開始寫程式時，對於甚麼建構管理、Issue tracking、Version control等都不是那麼的在意，在意的只有程式能不能run的起來，所以在前期，我可能會出現這樣的狀況：
我將我的code提供給Tester請他測試，他如果測試OK的話，就把我改好的內容放到Production環境去，但這樣的流程，其實存在許多的漏洞，以下一一揭露它的問題所在：
1.Developer跟Tester的環境不同
你很難確保Developer跟Tester的所有程式版本皆相同，連結的資料庫、環境參數、系統參數等等，都很難確保兩者是相同的，最常出現的問題就是，在Developer測試OK的程式，到了Tester測試的環境去測卻發現不行，很多時候可能是少copy了一個元件、要調環境設定、其他相關程式的版本不同，一堆問題來來回回花費的時間實在驚人。
2.Developer提供給Tester的版本比Release的版本更新
一般來說我們進行完Bug fix後可能會出一個新的小版本，或稱為hot fix，這個hot fix會是一個正式release的程式版本，例如叫2.2.10.2，我們會把這個hot fix放到一個可被取得的網路空間，提供給相關人員下載，確保大家可以取得最新的程式版本，但依循以上的流程，我們發現Tester取得的程式是來自於Developer而不是hot fix的網路空間，這就可能出現Tester取得了一個尚未放到hot fix空間的幽靈版本，後續要追查問題時會變得非常的困難。
3.沒有標準的hot fix SOP
在我們做版本變更的流程中，我們很強調SOP，這個SOP包含要進行的程序、Input跟結果，而這樣的程序我們會透過工具來協助，以避免人工的失誤，例如我會把某個資料夾下的目錄、js、dll、css等都包裝到一個zip檔作為hot fix，這個動作如果透過工具來做，只要code沒寫錯，應該是萬無一失，但如果透過人工來處理，失敗的機率就變得非常高了，即使再熟練，都很難達到不會出錯，包裝好這個zip檔後會自動上傳到release區，然後由Tester透過工具去release區取得這個zip檔，自動解壓縮後放到特定的目錄下，完成一次程式的版本升級，以下幾個分鏡展示一下。
將程式透過工具打包成一個zip檔，並放到release區： 
Tester到release區取得zip檔，透過工具將zip解開，並將裡頭的程式放到對應的目錄下，開始測試，測試無誤後就上到Production。 
4.欠缺一致性的測試環境
以上的劇情我們可以發現，Tester都是在自己的環境中做測試，放到Production環境後還是有可能出現錯誤，因為兩者的環境還是有差異的，因此在實務上我們發展出另一種測試方式，就是真正環境模擬的Testing環境，這個環境與Production環境是一模一樣的，硬體規格、OS版本、Service Pack版本、連結的資料庫、環境參數、系統參數等等都是相同的，而這些參數都要被嚴格的控管，只要有調整，兩台機器要維持一致性，在這種狀況下，兩台機器間的差別只有應用程式的版本會有差異(Testing環境會比較新一點，因為有正在測試的程式)，因此流程上會有一些變動，Tester是在Testing環境中做測試，測試成功後將這個新版本放到Production環境中，因兩者的參數一致，沒有意外下，測試出來的結果也多是對的。 
5.相信測試過的A程式，不要相信別人口中的A程式
這是一個很有趣的觀念，而且也很常發生，我現在依循標準程式將我的程式包裝成zip檔給你了(還沒放到release區)，並告訴你說：『走SOP太花時間了，你先拿這個去測吧。』
於是你拿了並在Testing環境測試過了，這時候你應該要做的是把這個在Testing上測試過的zip放到release區，然後將同樣一個zip檔佈署到Production區，但多數情況下我們為了維持測試的流程，我們請Developer再"重"包一次zip，並請他上到release區，而我相信我剛剛測過了這個版本的程式，應該可以不用再測試了，所以我就把release區這個"剛剛測過"的程式直接放到Production區去，不再進行一次測試，因為我相信這個程式跟剛剛我測試的內容是"一模一樣"的。
這個問題其實很可怕的，因為很多時候Developer在打包時可能會動一下source、改一下參數，導致打包出來的zip跟剛剛測試的zip之間是有些許差異的，而這個差異可能就衍生了另一些問題出來，但Developer往往會依自己的經驗判斷：『這樣改應該不會有差吧？』，然而錯誤就往往出現在這種想法上，這個新的zip，已經跟我剛剛測試過的zip內容並非100%的相同了，有差異，就可能有不同的結果產生，但Developer又跟你說，這個就是剛剛的zip，一模一樣，你要不要相信他呢？
要解決這個問題，就是一開始就不接受Developer的提議，請他務必依循標準流程，讓測試的結果能真的落實，避免後續的麻煩。
本文不談測試方法，但談流程，一般來說我們要有工具與標準流程，工具協助我們進行建置、打包、版更的動作，標準流程協助我們依循正確的程序把工作完成，只有這樣做，我們才能相信我們在Production的程式是可以正常被執行的。
能相信的只有測試過的程式。
 |
游舒帆 (gipi) 探索原力Co-founder，曾任TutorABC協理與鼎新電腦總監，並曾獲選兩屆微軟最有價值專家 ( MVP )，離開職場後創辦探索原力，致力於協助青少年培養面對未來的能力。認為教育與組織育才其實息息相關，都是在為未來儲備能量，2018年起成立為期一年的專題課程《職涯躍升的關鍵24堂課》，為培養台灣未來的領袖而努力。 |
