上一講提到我們通過 Acceptance Criteria 來定義一個需求被「做完」，而其中所列出的內容就是使用者角度的操作手冊：我們怎們做，就會得到怎麼樣的結果。

今天來聊聊合併開發者和使用者的視角下，需要做什麼樣的測試、怎麼做最有效率？又為什麼要做這些測試？

我們為何要做測試？又為何要做自動化測試？

關於測試的目的，我們可以分成兩個角度來看：使用者及開發者。

交付給使用者的測試：驗證需求

首先是使用者，也就是客戶，當產品要交付給他們時，每個功能我們都得先驗證過才能給客戶吧，否則讓客戶才用一下下就發現 Bug，留了這些低級錯誤就非常不妙了。

這種理應在 Developer 開發時會發現的、PM 在玩功能時能看見的、QA 在驗證時要抓出來的，居然都沒擋住而被客戶發現，我們稱作這種錯誤為 Customer Visible Issues。

如果是機率很低，很難出現的 Bug 也就算了，但不應該是低級錯誤，這也就是我們需要 Acceptance Criteria 這樣條列式的清單來逐條驗證的原因。

開發者的測試：守護程式碼的城池

從開發者的角度來看就很不一樣了，我們需要面對的是快速變化的局面。

為何？因為「需求是不斷變動的」！我從來沒有聽過一個功能的需求是能夠一步到位的，在討論中總會有初版、二版、三版；就算確定之後還可能增加修訂版、修訂二版、修訂三版。

你說我們和客戶談完了，約都簽了，他們難道還能一調再調嗎？難說，如果遇到強硬一點客戶，或是客戶就是你老闆，又或者直接就用錢解決你，最終可能還是得改。

除了客戶的需求，工程師自己的需求、寫的 Code 也常常變動，我們可能會更換不同的 Library、修改被抓到的 Bug、讓程式碼變乾淨的重構等等，通通都需要改。

既然需求變動的可能性如此之大，我們一開始就應該先假設需求會改，做好變化的準備。而這個準備，就是測試。

如果我們在開發的同時，就先建立好各種不同的測試集，在 Code 變更的同時能夠重新執行這些測試，自己就有了底氣讓 Code 不會被改壞，不會牽一髮而動全身。

我覺得開發者測試的意義，就是給了自己因應變化的安全感，讓我們能夠功能導向的先完成需求，之後再回來檢討寫法，改進實作，並且不會讓產品壞掉。

開發者的自動化測試

為了要在每次變化的時候能夠重新執行我們預先設計的測試集，自動化就是一件相當重要的事情。

小到 Function Level 的 Unit Testing，到多個 Functions 或是 Components 綁在一起測的 Integration Testing 等等，如果都能夠做到自動化測試的話，每次修改後檢查錯誤的成本就會降的很低。

對於修改程式碼所造成的影響，雖然現今在 IDE 的幫助下都可以 Refer 到有誰用過這個變數、函式，也能用全域搜尋來找到被影響到的範圍，但實務上總會在你一時沒有想到的地方出錯，自動化測試就能在你每次 Commit Code 的時候發揮效用。

測試金字塔，Unit Testing + Integration Testing + E2E Testing

聊完了做測試的原因，接著來看看有哪些測試的型態是我們可以做的：

1. 單元測試 Unit Testing，來針對小範圍的 Function 做測試，每個 Unit Test 的撰寫成本比較低

2. 整合測試 Integration Testing，測試多個 Function 或多個 Component 所組成的 Module 是否能正常運作，由於牽涉到比較多的 Code、甚至是需要啟動或 Mock Database 等服務，這種測試的通常要多花點時間撰寫

3. 端到端測試 End-to-End Testing，簡稱 E2E Testing，基本上就是把整個全端的服務跑起來，以使用者的角度來測試功能，要撰寫和修改此測試的成本最高

這三種是我在全端開發時都會撰寫的測試，根據我們寫的測試案例數量的多寡，和測試範圍及成本的高低，我們可以將這三種測試類型畫成一個金字塔的形狀。

*測試金字塔

位於金字塔底端的是 Unit Tests，因為測試和撰寫成本低，可以多寫一點盡量覆蓋有風險的 Function；而中間則是 Integration Tests，可以開始測試一些實際需求的功能了，但因為範圍較大一些、撰寫和測試的成本也高一些，我們能夠花時間寫的測試數量就會相對少一些。

以上兩種測試，Unit Tests 和 Integration Tests 是我會將其做成自動化測試的，因為測試的頻率較高，通常在程式碼有新增或改動的時候就會執行測試。例如某個轉換時間 format 的小 Function 就適用 Unit Testing 來確保正確性、一個新增用戶的 API 因為包含後端程式碼和資料庫，就適合用 Integration Tests 來覆蓋。

至於 E2E Tests 則是範圍最大，測試成本最高的，每個 E2E Test 就像是 Acceptance Criteria 裡面所撰寫的某個項目，例如新增用戶的功能需要從前端登入、進入指定頁面點擊按鈕，到送出 API 得到回傳值後重新渲染畫面。

這樣的 Test Cases 撰寫和測試的成本都很高，通常我也只會在一個功能完成後、或是出一個 Release 時跑一遍 E2E Tests，有的時候花太多時間來開發自動化測試，反而不如低頻的手動測試來的有效率。

測試小結

回到測試的目的，我們希望能在需求變更時不怕改壞既有的功能，這樣的話便能透過 Unit Testing 和 Integration Testing 的自動化來達成目標，在開發的階段就要同步撰寫這兩種自動化測試。

而另一個測試目的，驗證需求是否有完成，則可以透過 E2E Testing 來完成。如果也想透過自動化測試來避免改壞功能，可以將 E2E Tests 的部分內容自動化，透過這種稱為 Regression Testing 型態的回歸測試，在每次 Release 或是 Deploy 在任何環境之後跑一次 E2E Tests。

至於這些不同種類的測試，有什麼撰寫和測試上的細節和範例，我們接著聊。