測試自動化(Test Automation)是以自動方式執行測試, 管理測試數據, 以及利用結果來提高軟體品質的實踐. 它主要是一種品質保證的措施, 但它需要整個軟體團隊的承諾. 從業務分析師到開發人員和 DevOps 工程師, 要充分利用測試自動化的工具和觀念, 並且也需要每個人的參與.

下表是比較軟體測試和測試自動化的不同

軟體測試
受測產品的專業知識
要知道 測什麼 (what to test)
產出: test cases

測試自動化
軟體開發的專業知識
要思考 如何測 (how to test)
產出: test scripts

測試自動化它其實就是軟體開發, 你必須用對待軟體開發的方式來進行它, 因為你在軟體開發上遇到的問題, 在這邊都會遇到. 像是測試程式需要 code review, 需要重構. 否則一段時間後, 測試程式就會爛到不行, 不好維護, 並且 bug 也很多.

這也是開發人員很喜歡測試自動化的原因, 因為就是在進行軟體開發, 差別只是寫出來的程式用拿來測東西. 雖然開發人員對於測試自動化有異常的喜愛, 但是他只愛寫程式的部分, 但是對於要測好這部分, 會自動忽略無視.

許多公司已經在一定程度上使用測試自動化, 但仍然很大程度上依賴手動測試，因為他們不知道如何在開發過程中, 正確利用測試自動化測試的好處. 以下是常見的好處:

• 可以執行測試 多次
這點很明確, 一但程式寫完, 是可以一直重複執行.

• 可以測試動作 一致
對於某些複雜的步驟或是設定, 藉由自動化, 可以讓每次進行時, 確保做得事情都ㄧ樣. 否則還在確認是否哪裡有少, 這樣還要測試嗎?

• 可以做一些 人做不到 的測試
有時候需要在短時間內進行很多次, 或者比較大量資料, 或是查看細小差異等等, 這些都是和讓人來進行, 很容易弄錯.

• 可以方便 支援更多平台 的測試
如果有海量平台需要支援, 這時候自動化就明顯的有幫助.

• 方便 迴歸測試
在以迭代為主的開發方式, 每次迭代完後都至少要有一次迴歸測試, 這樣以人工來進行是會很想死的.

• 增加信心
測試自動化通常會先針對主要的大功能先做, 也就是 smoke test 所包含的範圍, 這些能夠先保底正確, 大家會比較有底氣一點.

那是否節省成本也是好處呢? 嗯 …… 這個有點模糊, 任何實踐做得好都可以節省成本. 但是 …. 就是那個但是 … 大多認真在做測試自動化的, 所花的成本都還蠻高的, 一方面要花時間去撰寫, 另一方面更恐怖的是維護成本. 因為開發一定會改 A 錯 B, 受測程式會受到影響, 你的測試程式不會嗎? 所以你會不斷花時間去修改和調整. 成本是比你想像的高的許多.

既然談到要花很多成本去處理測試自動化. 我們就來談談為甚麼測試自動化會失敗. 可以從這幾個面向來聊聊：

1. 組織面向

• 老闆不支持
老闆在意的是專案時程和是否能賺錢, 而不是測試自動化. 你要思考的是如何”適當地”利用測試自動化, 達到老闆想像的. 不要把測試自動化當作目標.

• 不切實際的期待
有時候管理者會認為有做測試自動化, 產品就會沒有 bug. 或者認為測試程式這玩意, 很簡單很好寫, 你怎麼會需要這麼時間, 你的能力是否有問題.

• 沒有自動化技能的人
測試自動化是需要設計的, 架構上要適當地設計, 你才容易去測它.

• 沒有經費
沒錢就什麼都不用說. 這是一種說法. 但是也有公司就是因為沒錢, 他們發展出沒錢的玩法. 看你是否是成長性思維.

2. 流程面向

• 不是測試流程的一部份
如果不是流程必要要做事情, 一方面團隊就不會考慮要做. 另一方面, 他可能不知道何時是適當的時間, 以及該要怎麼去做.

• 沒有嚴謹的開發流程
我一直強調測試自動化就是在做軟體開發, 測試人員都知道開發不嚴謹, 會寫出怎樣的爛扣. 同理, 你的測試程式不好好處理, 也會有相同的下場.

• 缺乏獨立測試環境
這跟開發一樣, 開發沒有獨立的環境去確認他們寫的東西是否正確, 到時候說完成, 通常都還會有什麼小問題要收尾. 測試程式也是如此.

• 只針對 UI 進行自動化
根據測試自動化金字塔, UI 自動化的投資報酬率最低, 可以大家都挑這個來做, 自然就會失敗.

• 最後才進行時間不足夠
很多團隊是等開發做完, 手動測試做完, 才想起要做測試自動化, 這樣時間鐵定不夠. 如果這時候需要開發人員改程式去配合, 這會變成不可能的任務.

• 有錯沒有及時修改
測試程式是這樣的, 第一時間有錯不改, 之後想改就改不了, 然後就會放棄. 尤其是有跑持續整合流程的團隊, 更是要嚴守有錯立刻改的原則.

3. 技術面向

• 沒有合適的工具
以前這個問題蠻常發生的, 因為以前商用測試工具很多 bug, 並不穩定. 但是隨著開源測試工具的出現, 工具的穩定度和易用性好很多. 所以現在的問題, 通常是你不知道有這些工具可以用.

• 沒有訓練: 工具和開發能力
有些東西沒人教, 沒有人天生就會. 你也不要期待團隊成員會自動去學, 還會自己付學費去學, 在工作中公司還是需要適時安排這樣的訓練.

• 低估自動化測試的設計
你想想看, 只要專案沒有結束, 開發人員是會一直修改他的程式. 因此, 你必須要確保你的測試程式不會受到影響. 這是需要精心設計, 這是需要有不錯的架構設計能力, 否則是無法勝任.

• 很高的維護代價
正如前面所寫的, 因為開發人員不斷修改程式, 所以你也需要不斷維護你的測試程式.

接下來我們看一下測試自動化流程, 基本上這個流程分成以下步驟:

圖 29-1 測試自動化流程

• 可行性分析
測試自動化並不是說做就可以做, 必須要有適當的設計, 並且在開發階段已經有想到這件事情, 把相關的機制準備好, 這樣你才容易在這時候進行測試自動化.

• 擬定測試策略
你要看哪些地方風險比較高, 我們需要安排自動化. 自動化是做在 unit testing 還是端到端層次. 在哪一個時間點做, 是開發階段, 是在每個迭代都做, 或是測試階段才做, 或者不同階段進行不同種類的自動化. 要如何執行呢? 是在 CI 中跑嗎? 每次 check-in 跑, 還是每天半夜跑.

• 準備測試環境
有幾組測試環境可以使用. CI 每天建構 build 用一套, 進行功能測試用一套, 進行效能測試用一套, 安全測試也有單獨一套? 這些要先想清楚.

如果要共用一套, 測試環境要如何備份, 要如何安裝和復原, 這些要有規劃, 必要時也要把這些流程給自動化.
• 開立測試個案
• 執行測試個案
• 產生和分析測試結果

哪什麼測試/功能適合自動化呢? 這是很多人會問的問題. 開發系統基本上用來賺錢和解決問題的, 所以你會看投資報酬率, 以及風險高不高來決定. 絕對不是寫好寫滿, 或者是為了顯示自己很厲害很專業. 以下是個人覺得可以先下手的地方:
• 單元測試
• 複雜狀況
複雜資料/步驟
容易人為錯誤
• 多平台的測試
• Smoke test
主要場景
端到端
• 效能測試, 負載測試
• Race condition
• 很難重現的 bug
• 回歸測試
• 很長的執行時間
• 風險很高的場景

測試金字塔(Test Pyramid) 是由 Mike Cohn 於 2009 年提出, 是軟體開發中自動化測試的理想分佈的比喻, 強調大量的單元測試和較少的高層次的測試. 它有時也稱為測試自動化金字塔.

Mike Cohn 的原始測試金字塔由三層組成, 包含這些(從下到上)：
• 單元測試 (Unit testing)
• 服務測試 (Service testing)
• 使用者介面測試 (UI testing)

不幸的是，這樣的測試金字塔的有點不足了, 並且測試金字塔中的命名, 或某些概念方面並不理想, 似乎過於簡單化, 可能會產生誤導.

儘管如此, 由於其簡單性, 測試金字塔仍然可以作為一個很好的經驗法則. 測試金字塔中想要強調幾件事情：
• 測試要有不同顆粒度
• 不同顆粒度有不同測試目的
• 不同顆粒度有不同執行速度和成本
• 越下面層次的測試應該要越多

圖 29-2 測試自動化金字塔

這些層次的測試, 我們來做個比較, 從不同面向來讓你了解, 它們各自的優缺點如何, 讓你可以知道在什麼場景, 哪種層次比較適用. 以及你的測試自動化策略, 應該使用怎樣的組合

雖然在大多數的文章中, 都是鼓勵自動化的配置要是正金字塔的形狀. 也就是說 unit testing 最多, UI testing 最少. 但是在真實世界中, 很多公司的配置是倒立金字塔. 為什麼會這樣呢? 可能的原因如下:

• 像用戶一樣操作
之所以會選擇 UI testing 去做自動化, 很大的原因是他們認為這就是真實用戶的場景, 他們就是這樣去使用系統. 如果是進行單元測試, 那個只是一小段場景, 你還有很多場景沒有去測, 他們認爲這樣涵蓋度是有問題的.

• 依賴工具
很多工具的廠商, 宣稱你只要錄製操作過程, 不需要寫測試程式, 或者不用寫太多測試程式, 整個自動化開發過程非常快速. 但是事實上不是如此的, 你還是需要精心設計的. 例如: 當開發人員修改畫面元件, 或者是畫面流程, 你之前所錄製的測試腳本, 有很大的機會需要重新錄製, 這個代價是非常大的.

• 只做一次, 最後才做
很多時候能夠開發測試程式, 通常是在專案進行到後期, 所有功能都開發完, bug也修得差不多, 所以就可以來進行測試自動化. 那時候其實時間不多, 大概就只有一次機會, 並且可能只有測試人員願意做. 所以他們會選擇 UI testing. 開發人員通常不是很想做, 如果他們願意做, 可能也做得不多, 所以只會少量的 unit testing.

• 缺乏有人指導
要把 unit testing 寫好, 其實是需要精心設計的, 你的架構上需要做調整, 才能讓你方便進行單元測試. 這邊需要有經驗豐富的架構師等級來幫助, 會比較容易成功. 尤其是你要面對許多 legacy codes, 很多開發人員會放棄的.

• 功能比技術債重要
正如前面所說, 趕進度把功能寫完是首要任務. 要設計 unit testing 去確保程式有精心設計, 以輔助你不斷重構, 好還要更好, 這些事情通常是被放在最後.

接下來我們談一下測試工具, 很多人會問說要如何選擇, 以下是常見選擇測試工具的考量因素：

圖 29-3 選擇測試工具的考量因素

1. 成本
開發測試自動化就是在做軟體開發, 所以最大的成本就是在維護. 如果語言或工具不好學習, 並且也不好除錯, 這時候維護的成本就會相當高.

另一個就是授權費用, 是算人頭嗎? 單次計費? 還是每年都需要 renew? 這些都是會影響你要不要用.

2. 易於導入
在導入時, 在意的是供應商可以提供什麼訓練? 是線上版呢？還是實體訓練? 教材有本地化嗎?

另外在安裝系統, 或者是使用過程中遭遇到任何問題, 是否有支援團隊可以幫忙回答問題, 或者協助錯誤排除.

3. 整合性
通常我們不會單一來使用某個工具, 我們可能會需要跟 CI 系統做整合, 這時候就要看他有提供哪些 API 或是 plug-in, 讓我們可能進行近一步的開發.

4. 可支援的測試平台
通常受測產品可以執行的平台, 不是只是單純一種, 可能不同手機, 不同作業系統等等, 一般你不會想說 iOS 用一套, 然後 Android 又用另一套. 這樣就會雙倍費用, 雙倍學習.

5. 可支援的開發語言
開發受測產品的程式語言會有很多種, 有些用 C#, 有些用 C++, 有些是前端的語言, 有些是後端的語言, 有些在 windwos上面執行, 有些在 Mac 上面執行. 這些你的測試工具可以支援多少呢?

6. 產品狀況
這個工具有產生什麼報表嗎? 可以讓我很清楚一些執行狀況嗎? 它是不是很穩定, 不會常常出包? 如果有出包, 哪裡可以抓最新的 hotfix. 工具執行起來的效能如何? 是否可以負荷很大的用戶量或是資料量?

至於有哪些測試自動化工具可以用, 其實你把最近三年軟體測試的調查報告拿出來看, 反來覆去的就是哪幾套, 在西瓜依大邊的原理, 其實就是閉著眼睛選.

一方面可以參考的資料比較多, 人家踩的坑你可以先知道, 人家的解法也可以拿來用, 人家避不了你也是避不了. 另一方面, 其實你也不用太計較, 大多數的公司其實都還沒有空大量使用測試工具, 測試工具通常都不是關鍵成敗原因. 如果是關鍵因素, 大多也會有專門團隊自行開發. 所以就先湊合著吧.
• Selenium
• Appium
• Cypress
• Playwright
• Cucumber
• TestNG
• Jmeter
• Robot Framework
• Postman
• Katalon