單元測試正夯，但你知道其實還有更多選擇嗎？

「想像一下現在你的面前有兩台飛機，一台號稱零件從製程到組裝都經過完整的測試，而另外一台僅經過飛行的測試而已，這樣妳會想要搭哪一台飛機呢」

 

在前面幾篇文章中，小編已經跟各位介紹過兩大開發管理心法－Scrum和看板，而其中在這兩套心法中，針對產品測試都有提到，唯有導入自動化測試，才有辦法透過週期性的檢測，使產品的良率和團隊的產出，可以有效率的大幅提升，而到底測試是什麼呢?又該如何對測試進行有效的自動化呢?

 

延伸閱讀：透過Kan-ban(看板)管理方法，視覺化並改善你的工作流程

 

 

測試的本質在於預防，防範於未然，僅管在百密一疏的程式，一但將其進行組裝時，也會很容易遇到無法解釋的問題，造成功能上的失效，以現在台灣的開發環境來說，一般產品開發過程中，團隊組員可能多為4-6位，進行產品的各項功能頁面的開發，以電子商務網站的"購物車"功能為例，我們可以想像"購物車"是飛機零件的一個螺絲，把飛機機翼(購物中心)和引擎(商品頁)進行結合和串接，也許當初在開發製程中，已經經過組員進行有效的測試，並且保證功能無誤，但萬萬卻沒想到在組裝的過程中，由於機翼和引擎都是不同團隊進行研發生產的，只要其中一個零件的孔位有所偏差，就會造成組裝失敗，或是密合度不夠，這樣的飛機，你敢坐嘛? 總不能讓乘客來幫妳驗證飛機的功能吧

 

所以在測試中，會需要最重要的三個環節如下：

(雖然本篇標題為更多”選擇“，但並不是代表選項彼此間會衝突，更多的時候是各自互補。)

 

單元測試Unit Test: 

以程式中最小的邏輯單元為對象，撰寫測試程式，來驗證邏輯正確與否，單元測試是程式開發的一種方法論，所以觀念上適用所有的程式語言。現在各大Framework，無論是寫App或是寫網站幾乎都預設已經包含這一部分了。

 

用飛機零件來解釋的話，就是最細小的螺絲都經過了完整的溫度、壓力..等等的測試囉 ，而關於單元測試的文章之前我們有用C#來當範例解釋過了，有興趣大家可以在去回顧一下。

延伸閱讀：[C#][Unit Test] 01. 軟體上線就等於今晚不用回家? 學"單元測試"可能有辦法挽救您的婚姻。

 

功能測試function Test：

針對程式結合UI組合而成的功能進行測試，來檢視欄位寫入資料庫或是功能是否正常運行等動作，看是否符合SPEC或是執行無誤，以電子商務為例，把商品加入購物車，就可以算是功能測試的一個案例。若是以飛機零件來行容，就是當零件組成引擎之後，對於是否可以正常的使用作測試。

 

這一段也是傳統上測試單位所做的事情，通常也是 客戶 / PM 研判功能是否正常的方法。但因為現在測試方式與理論越來越進步，所以就算是這層面上的測試往往也借助程式。(例如工廠用自動程式開關機1000次)

 

 

整合測試Internal Test：

 

通常提到整合測試就會結合了劇情，也可以透過當初開發所撰寫的UserStory來作驗證，以電子商務為例，從消費者進入頁面選購商品，放入購物車，到結帳，配送等，一個完整的使用情境測試，就可以稱之為整合測試。以飛機來作形容，就是指這架飛機組裝完成後，可以作完整的飛行測試，從乘客登機到著陸，都可以使乘客可以安全無慮的完成。

 

但因為這部分包含的比較大，所以很難監測到很細節的問題。例如Mac / iPhone 內建瀏覽器Safari以前有發生過使用SSL連網路並沒有真正的驗證。這如果跑整合測試很容易就被忽略到，因為很大的可能性測試結果是只看上面的小鎖頭來判斷是否有加密，並沒有真正用程式去看收到與傳出的是加密後的內容。

延伸閱讀：HTTPS 

 

現存歷史新聞：http://tech.sina.com.cn/mobile/n/2014-02-26/07509192679.shtml

避免連結失效，以下截圖重點。

 

 

重點節錄：(原文為簡體故保留之)

 

那自動化測試是什麼?

 

自動化測試是把以人為驅動的測試行為，轉化為機器執行的一種過程。通常，在設計好測試劇情後，就會由測試人員根據測試用劇情中描述的過程，一步步執行測試，得到實際結果與期望結果的比較，來模擬使用者在正常的使用過程中會遇到的問題。在此過程中，為了節省人力、時間或資源，並提高測試效率，便引入了自動化測試的概念。當然自動化測試又可分為：功能自動化測試與效能自動化測試。我們一般所說的自動化測試就是指功能自動化測試，想像一下我們每天都會在對程式進行優化或改善，而每一次的發布後，都必須嚴謹的進行一次功能測試，才可以知道這次更版，有沒有把其他的功能改壞，這樣重複的工作如果通過相關的技術，通過編碼的方式來測試一個產品(或UI)的特定功能，來自動化進行定期重複的測試。不但可以減少更板時的風險，來了解產品的完善性，而自動化測試除了依據上述的三大分類外，還可一兆產品屬性，多拆成一個接口和UI的自動化測試:

 

 

接口測試：

如果說單元測試的自動化測試目的為確認邏輯，例如一個 if或一個 for 循環的邏輯是否正常；那接口測試的目的，為確認函數和程式邏輯之間所提供的接口是否可靠。以API為例，我們使用get 方式送request，那麼我們發送的內容做為 JSON傳送到Servise時，是否可以回傳正確的值來達到當初請求的目的。

 

這方面也是有相當方便的程式，例如Swagger, RAML

在測試的同時API的文件也同時完成了

 

UI測試：

例如針對表單的填寫和提送去作自動化的測試，整合測試時可以確保UI的功能正常無誤，並且符合SPEC設計上的邏輯，例如超過表單的填寫時間時，UI就會去鎖定讓使用者送出時知道已經逾期，無法執行，而UI的自動化測試工具就相當多了，例如常見的 Selenium ,QTP，Robot Framework、watir、等，都是業界常使用的軟體。

 

 

所以簡言之，自動化測式的目的，就是把每天枯燥乏味的測試動作，變成系統化，可自動執行的標準作業，形容起來貌似簡單，僅管現在也有許多套裝軟體可以針對上述測試來實現，但是"自動化測試"這個制度的確立，卻是需要打破現有的組織章程，並且額外播出人力來作實現和開發的，在制度實現面的重點如下：

 

1. 先從無到有，其他別談

一開始目標是先設定為有測試自動化的制度, 所以先試著要求對每個單元、接口、功能，甚至劇情, 模擬出少數的測試個案, 當然在時間的壓力下，也可以只對核心功能, 撰寫較多的自動化，先求有在求好。

 

2. 天天執行，立即修復

自動化測試的目的，就是為了減少每天人工處理的成本，所以若可以每天在測試環境執行自動化測試，或是定期在每一次Sprint Release前去執行，當然是最好的結果，而 一旦出錯後, 因為我們熟悉撰寫的測試劇情和框架，所以若可以在短時間內(1小時內), 找出錯誤並修復，才是自動化測試最大的目的，所以當然一開始的設計就必須精心雕研 , 讓團隊能在最短時間找出原因.

 

3. 加速執行時間

執行的時間相當重要，每一次的測試都是在跟時間賽跑, 因此除了可以在最短時間處理完成外，如何讓測試在最短時間內完成也是重點，經過不斷的精鍊和強化，來縮短整個測試的CircleTime，更是自動化測試的精華。

 

所以從此我們可以知道， 自動化測試的重點，在於如何「自動化執行測試」，並且釐清要「測試什麼」，並且落實制度，與之推進，但單元測試嚴格來說只能算是工程師的基本，亦是不易發現盲點，更可以透過Pair programming(兩個人相互檢查程式碼)的方式來作第二層的Double check，而最核心的UI自動化測試及整合測試，在有限的時間內，可以需要依據產品的性質和功能，來作通盤的規劃後作出部分實作。

 

 

但記得，人工整合測試及測試劇情仍是絕對必須的，自動化測試只是可以減輕重複測試的負擔，但對於功能上的盲點去切入，還是必須依靠使用者的觀點來作確認。若是有興趣了解細節的朋友，其實各大Framework現在都已經包含相關的開發工具，例如開發iOS的Xcode開啟專案的時候會問你要不要開Unit Test 與 UI Test.  Ruby on rails 同樣也包含了測試段，雖然官方的工具在很多開發團隊不是第一選擇，但至少文件與觀念會相對的完整，大家可以去看看。

 

萬事起頭難，工作就是一種和時間上的競賽，相信大家一定有經驗，每一次在專案的兩頭燒時，往往為了進度而忽略掉了自動化測試制度的建立，但這樣的制度一但確立之後，對於產品良率的提升是絕對有幫助的，也許第一次總是需要花較長的時間來建立自動化測試的目標，但踏出之後的收穫一定是甜美豐碩的，共勉之!

 

最後，如果你喜歡我們的文章，別忘了到我們的FB粉絲團按讚喔!!