持續整合 — 自動化測試的落實

持續整合 (Continuous Integration, CI) 這件事，已經可以說是軟體工程的基礎了，任何一個軟體專案都會導入 CI 流程。

iCHEF 在這方面也投入了很多心力，不論是 RD 團隊的 【再戰 Jenkins CI Pipeline: Parallel 加速】，或是 QE 團隊的 【當 XCUITest 碰上 Pipeline】， 都是希望透過 CI 快速的發現問題，進而改善交付品質。

在 iCHEF，RD 每發出一個 PR (Pull Request)，便會執行所有的單元測試，單元測試都通過後，才合併到指定的分支 (branch)。

但通過單元測試，並不代表產品沒有問題，如同測試金字塔所描述的，單元測試僅僅只是金字塔的底層，上層通常還有由 QE 負責的整合測試或是 GUI 測試。

過去 QE 團隊的自動化測試，一直沒有找到好的方式，和產品開發流程整合，無法發揮自動化測試的價值。

在經過一段時間的努力後，我們找到了方法。

目前在 iCHEF，RD 每天會將最新的程式碼部署到預備 (staging) 環境，而 QE 的自動化測試，也會每天執行，藉由這樣的流程，團隊每天都會得到回饋，掌握目前程式碼的品質。

在這樣的流程之中，如何經由測試報告得知目前的品質，則是 QE 團隊一直努力的目標，我們藉由之前分享過的 AWS Elastic Beanstalk 服務，蒐集每天測試的結果，再用圖表方式呈現。

上面是基於每天測試結果產生的圖表，藍色是測試的數量，紅色是測試未通過的數量。

由這張圖表可以看出，這段期間，程式碼的品質相當穩定，每天的測試通過率都在 95% 以上，這樣的情況，表示我們對於目前程式碼的品質有相當程度的信心。

Q: 為何通過率不是 100%？

A: 自動化測試有個難題叫 flaky test，目前沒有解決方案，因此難以達成 100% 通過率。

這張圖表顯示另外一個情況，由圖表可以看出，測試通過率不穩定，經常在部署新版本之後，通過率大幅降低。

測試通過率降低，並不一定表示程式碼出現問題，有可能是規格做了調整，也有可能是自動化測試出現問題，但無論是哪種原因，對於目前程式碼的品質，我們沒有足夠的信心。

總結來說，做了這樣的整合，能夠快速得到回饋，對於程式碼的品質，也有更可靠的數據標準。

對 QE 團隊而言，也是在挑戰測試的可靠度，不可靠的自動化測試，只會帶來更多的問題，這經常也是自動化測試最重要的課題。

至於如何打造可靠的自動化測試，那又是另一段故事了 😅