在現代軟體開發中，測試已不再是開發完成後才啟動的獨立階段，而是必須貫穿整個開發流程的核心實踐。 但隨著前後端分離、微服務架構的普及，以及 AI 輔助開發的崛起，「應該怎麼分配測試資源」這個問題也開始有了不同的答案。測試金字塔（Testing Pyramid）作為敏捷時代的經典模型，正在被測試獎盃（Testing Trophy）、測試蜂窩（Honeycomb）、測試鑽石（Diamond）、測試螃蟹（Crab）等新模型挑戰與補充。 本文將從歷史脈絡出發，梳理這些模型的起源、適用場景與侷限，幫助你在不同的架構與團隊情境下，做出更合適的測試策略決策。 測試金字塔 起源與架構邏輯 測試金字塔最早由 Mike Cohn 在其 2009 年的著作《Succeeding with Agile》中以「The Automation Pyramid」的形式提出，後來經過 Martin Fowler 等人的推廣，逐漸成為敏捷開發時代的測試策略基礎。

#開發筆記 前言 這是一個 RTSP 攝影機串流模擬工具。主要功能是當收到 API 的請求後，用 ffmpeg 將原本錄製好的 mp4 檔案透過 RTSP 推出去，模擬多台攝影機同時輸入的情境。 但當我同時送出兩個 API request，我發現第二個請求一定會等到第一個請求跑完才開始處理。可是程式碼裡面我明明宣告了 async def，為什麼沒有同時平行處理呢？ ThreadPoolExecutor 是什麼 Python 的程式預設是單執行緒，也就是說同一個時間只會有一條執行路徑在執行。ThreadPoolExecutor 是標準函式庫 concurrent.futures 所提供的工具，讓我們可以同時間執行多個執行緒來處理工作。 基本概念 from concurrent.futures import ThreadPoolExecutor def do_work(n): return n * 2 with ThreadPoolExecutor(

回到 2019 年，那時的我們對 Robot Framework 的了解還不夠深入，導致許多測試案例無法平行執行；再加上測試資料管理的不足，進一步加大了測試的複雜度。然而，經過這些年的實踐，我們逐漸找到了應對之道。在撰寫新的自動化測試框架時，我們特別考慮了這些問題，並融入了解決方案。與五年前相比，現在的測試流程更加效率且穩定。 如果你對測試領域有興趣，建議參考我的 Threads，裡面涵蓋了豐富的測試知識、實用技巧和測試思維。若你想深入探討測試議題，例如：測試的學習路徑、敏捷流程的應用，或小型新創公司與大型企業的測試困難點。 前言 在 2019 年初，隨著產品迭代的速度變得越來越快，對於快速釋出新功能變得越來越不容易。當時團隊負責的產品已經是第八版 (2019)，已經累積將近 8000 多個測試案例。 如果要釋出一項新功能，必須花費將近數個禮拜的時間做迴歸測試 (Regression Testing)，除了原本的新功能，還必須重複地執行可能會被影響的舊功能的測試案例，以確保舊功能沒有任何的影響。 於是透過自動化測試保護重要的功能和新功能。最後花費將近一年的時間，將大部分的

最近在 reddit 看到一篇文章(原文連結)，讓我感觸很深。身為新創公司唯一的 QA/SDET，我發現不少人也面臨相同的挑戰。即使有多年經驗，還是會覺得挑戰不小，更何況是剛入行的 QA？這感覺就像是一個新手球隊經理，獨自肩負打造冠軍隊伍的責任，既困難但也充滿機會。 瞭解公司的開發流程 在一間已經有產品上線的新創公司要建立測試流程，第一步是先搞清楚目前的開發流程，看看是否已經有測試機制運作中。也要特別注意開發週期中是否有經常被忽略的環節，這些地方往往是問題最多、最容易在上線後爆發的地方。 如果前期的測試還無法涵蓋大部分的使用者情境，那麼上線後的監控就變得特別重要。確保有足夠的監控機制，能夠即時發現問題、快速修復，這樣才能降低對用戶體驗的影響，並持續優化產品品質。 通常，我會使用測試金字塔模型或敏捷測試象限圖來檢視測試的缺口，確認有哪些地方做得不夠完善，但卻很關鍵部分。這些工具可以幫助我們更有系統地分配測試資源，確保每個環節都有適當的測試覆蓋。 在測試執行方面，一般來說： 單元測試通常由開發人員來寫，如果團隊還沒有這個習慣，可以先鼓勵大家養成撰寫單元測試或整合測試 (API