進度條

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

與其期待你的顧客會替產品除錯,不如用自動化測試提升產品良率

作者: Vincent Ke 更新日期:

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

 

在前面幾篇文章中,小編已經跟各位介紹過兩大開發管理心法-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

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

 

 

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

漏洞从何而来?

  很多人比较关心的问题是,为什么这样一个安全漏洞存在时间如此之久到现在才发现,以及这种漏洞为什么会存在的、。来自Cryptocat应用的 Nadim Kobeissi指出苹果系统中存在的低效if-then语句,以及重复的“goto fail”行。这些较为草率的代码可更为轻易地导致错误发生。哥大的Bellovin指出,
代码覆盖测试一般应该可以抓出这些重复的行,为什么苹果却没能发现这些问题呢?

 

那自動化測試是什麼?

 

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

 

 

接口測試:

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

 

這方面也是有相當方便的程式,例如SwaggerRAML

在測試的同時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粉絲團按讚喔!!

Medium vincent

Vincent Ke

喜歡把混亂的事情變的簡單 用嘴巴做事其實很可以 但要結合靈活的腦袋思考 就一起來拆解吧