PHPUnit 自動化測試大作戰【CH01】
初遇自動化測試
在數年前，我剛從第一份工作離職，轉職到第二份工作， 新工作是在一個大集團的IT部門，職位是後端工程師。 當時集團正準備導入一個由子公司開發的微服務系統， 使用的技術是PHP 8 及 Laravel 9 因為該系 統在子公司運作得不錯， 因此集團高層想將它擴展成，全集團都可使用的規模， 也因此需要招募人手來協助進行（而那個人手就是我）。
到職當天，部門副理協助我建置好環境， 並告訴我子公司工程師在開發此微服務系統時，有寫了很多自動化測試， 建議我可以由閱讀自動化測試案例，來了解這個微服務系統的功能。 這就是我第一接觸到自動化測試，以及 PHPUnit 這個工具。
什麼是自動化測試？
讓我們來看看維基百科的定義：
In software testing, test automation is the use of software separate from the software being tested to control the execution of tests and the comparison of actual outcomes with predicted outcomes.換言之，所謂 自動化測試 ，指的是使用其他軟體來自動測試待測軟體、比較實際結果與預期結果之異同、生成測試報告的這一個過程。
簡單地說，就是用測試程式來測試原始程式的邏輯，是否符合預期。
為什麼要撰寫自動化測試？
這時候一定會有人問，手動測試不香嗎，為什麼要用自動化測試？多花時間寫測試值得嗎？ 的確，大多數自動化測試能做到的事情，手動測試都能做到， 且撰寫自動化測試不是毫無成本， 有時甚至會花上比開發功能本身，更多的人力成本來撰寫測試。
但若我們從另一個角度來探討， 自動化測試基本上只有第一次撰寫時最花時間，後續執行測試時，都是以秒來計算 而且是讓電腦自動執行測試程式來進行測試， 只要測試腳本沒問題，那電腦就會以正確的方式進行測試。
反觀手動測試，因為執行測試的是人， 而只要有人介入，就有一定的人為出錯率， 有可能是測試時漏了某個動作，導致測試要重來； 有可能是漏了某個測試資料，導致測試又要重來； 有可能是漏了某項測試案例，導致發生了改A壞B，上線了才爆炸； 有可能測試者心情不好，沒有心力按下測試鍵。 以上種種，都是人為手動測試可能發生的情況， 若是使用自動化測試，這些情況大多可避免。
此外，手動測試花的是人力，通常以 分鐘來計算，這也是不小的成本。 而自動化測試，會花到的成本大概只有 幾秒鐘的電力。
自動化測試的優點與缺點
讓我們來總結一下自動化測試的優缺點：
優點
- 交給電腦來執行測試程式，執行測試時無需消耗人力，也不會喊累
- 避免人為因素導致的出錯
- 可以計算測試覆蓋率，了解程式庫中有多少部分有被測試
缺點
- 需要花費額外成本開發測試程式
- 需要花費額外成本建立測試環境
TDD與自動化測試的關聯
許多人常會將自動化測試，與近年流行的測試驅動開發（TDD, Test-Driven Development）掛勾在一起，但我認為實際上兩者是描述不同的概念。
自動化測試，指的是一種測試軟體的測試方式； 測試驅動開發，指的是一種先擬好測試，再撰寫程式邏輯的，開發流程。
使用自動化測試，未必也採用了測試驅動開發，反之亦然。
舉例來說，小明是一個API開發者， 每當他在開發API時，他會先撰寫程式邏輯，接著進行手動測試驗證， 確認無誤後，再撰寫自動化測試程式。
而另一位API開發者小華， 他會先在紙上擬好各功能的測試案例， 包含測試資料準備、測試流程、預期結果等， 接著用這些案例測試程式。 因為對應的程式邏輯根本尚未開發，因此一定都不符測試預期， 這時小華再開始開發各功能的程式邏輯， 並在每次開發完一項功能時，就執行該功能相關的各測試案例， 直到所有測試案例都被滿足的當下，即為開發完成。
在小明的例子中，他採用了自動化測試來測試程式，但沒有使用測試驅動開發； 在小華的例子中，他採用了測試驅動開發的開發流程，但沒有使用自動化測試。
本系列文章討論範圍
在這個系列中，我將與大家分享這數年來使用 PHPUnit 的各種經驗，以其各種測試情境，主要內容包含 常用測試函數、API測試、資料庫測試、畫面測試、Mocking、測試覆蓋率計算、Seeder、Data Provider等內容，望能對初學PHPUnit及自動化測試的同好們有所幫助。
下一篇來為大家介紹環境建置。
如果您喜歡這篇文章，歡迎加入追蹤以接收新文章通知 😄
參考資料：
你可能也想看
