此篇文章為看完 【從理想、到現實的距離，開啟品味軟體測試之路 】【Rick Hwang】【軟體測試系列講座01】 的筆記整理。

我相信對軟體測試領域的各位，這上方這張圖片一點也不陌生
但往往這張圖都是理想的樣子，能真正做到的這樣的企業可能不也多
因為這不只是 QA 足夠厲害就能解決的，它是會跟整個開發團隊人才、執行方針、流程 都有息息相關的。

從下往上的順序為

1. Unit:
   從開發工程師撰寫 單元測試 開始，是工程師需確保自己寫程式碼基本邏輯是正常為前提，然而這個測試的成本是最低也是最快(撰寫速度/執行的速度)，通常只要 單元測試 足夠多，也能盡量降低後期測試成本，因為若有問題 CI 階段一定會無法通過。
   • 單元測試 的教學，詳細請看 [Day10] 常見軟體測試種類有哪些？新手也能快速了解 (上)
2. Service/Integration:
   主要是會整合其他服務的邏輯，確保某個業務邏輯是正確的，同時也是在確保系統整塊本身是否正常，同常需要具備一定的技術含量且測試複雜度高。

   e.g.
   我要測試結帳功能，但執行 UI 測試成本又太高，但我可以先透過了解背後結帳功能的系統邏輯。
   從 A api -> 第三方金流 -> 將結果回傳到系統內部 結帳的 service -> DB -> 結帳的 service-> 回傳 A api 內容。
   了解系統流程後，就可以只針對這個流程進行驗證，將相關的 api 串起來
   進而對每一個階段都做一層檢查
   

3. UI:
   也就是我們常在說的 手動/自動化 驗證，光是條列 Test Case 就非常耗時了，寫成自動化也是要花費撰寫時間的，測試角度都以使用者為出發。
   所以 UI 測試不管是在 人事成本(e.g. 找會寫自動化的人才)、工作成本(e.g. 驗證時間) 都是相到高的。

簡單總結

從單元測試到 UI 測試等，越往上越是接近 UI 層級，它執行時間就越長、成本也就越高，不論是人工執行，還是將其寫成自動化都一樣。

但這並不代表 UI 測試就不用做，只是透過這個三角圖關係會清楚明白成本的差異

現實的三角形可能會如何？

版本一：

版本二：

版本三：

版本四:(大多中小企業可能都是這種作法)

其實這三角型概念並不是絕對值，還是會回頭響應在我文章系列的文章

• [Day2]開發團隊常說的品質到底是什麼？
• [Day5] [軟技能篇] 原來 QA 沒有想像中的簡單，QA 應該具備什麼特質

品質不是結果論、不同類型公司 QA 負責內容也會有不同

套用在上方的三角形也是相同概念。

其實不同類型的產業、不同規模大小的公司，它的測試三角形也會不同

不同類型的產業

• 電商
• 區塊鏈
• 影音
• AI
• 物聯網

不同規模大小的公司

• 草創期: 20 人內
• 成長中: 200 人以內
• 成熟中: 500 人以內
• 集團: 幾千人

結論

以前會認為理想中的 測試金字塔 是所有企業應該都要達成的，無法達成都是爛XDDD(誤
但後來才發現
那個理想中金字塔確實很美好，但現實中要達成，要靠大量的時間、金錢、人才、組織文化 等等才能逐步達成的。
也就是說
我們要學會在有限的資源下，將測試發揮到最大值，這部分就需要整個團隊有共識才能一起完成的。

測試金字塔更像是一種概念，讓你區分現在執行的測試成本為多少，是否能發揮最大的效益。

參考來源

• Rick Hwang 部落格: https://rickhw.github.io/categories/%E8%BB%9F%E9%AB%94%E6%B8%AC%E8%A9%A6/
• Martin Fowler 部落格：https://martinfowler.com/articles/practical-test-pyramid.html
• Mike Cohn 部落格：https://www.mountaingoatsoftware.com/blog/the-forgotten-layer-of-the-test-automation-pyramid

大家務必要點進去看一下影片，Rick Hwang 大神講解得非常詳細。