測試框架地圖：我為什麼建了 testframe.works，以及你該怎麼用它
如果今天身為團隊或者是公司唯一的測試人員，有一天主管走過來問你：「我們的產品，還有哪些測試可以做？」，請 AI 列一份清單？說「我們應該多做一點測試」？還是憑直覺說幾個聽起來專業的名詞？是不是有更好的測試方法論或是邏輯判斷依據，讓你可以分析產品的品質呢？
這個是莫約 4 年前，我們團隊接了一個遺留產品專案，原本功能是分散給各個產品團隊開發，但決定由一個團隊來負責，當時主管問了我這個問題，「我們還有哪些可以做的測試？」，而我當時的做法，是拿出測試金字塔和 Marick 測試象限，把產品現有的測試活動對應進去，然後看哪些格子是空的。空的格子，就是可以補強的地方。
使用任何的理論或框架，是需要了解當時的背景
隨著資歷越來越深，我越來越相信一件事：了解測試框架的來源、步驟與適用情境，跟會用這個框架同樣重要。
因為我們很容易看到某間公司的 Best Practice 就想直接套用，卻沒有注意到它的歷史背景。Google 的測試蜂巢模型是為了他們的系統規模設計的。Netflix 的混沌工程是為了分散式架構。把這些方法放到一個十人新創或中型企業，不一定適合你的團隊或你的公司，但搞清楚框架的脈絡，才能判斷它適不適合你的產品。
這就是為什麼我想要一個地方，不只列出框架名稱，還記錄它的提出者、時代背景、以及它真正適合被用在哪裡。
testframe.works 是什麼
不管你是團隊裡唯一的測試人員、還是工作 3–5 年開始想系統化自己知識的測試工程師，遲早都會遇到同一個問題：我知道有很多測試方法，但我不知道全貌長什麼樣子。
如果你還在累積資歷的階段，更需要從軟體開發流程的每個階段，理解適用的框架內容，這不是為了現在馬上用，而是為了將來在不同專案遇到不同情境時，腦子裡有東西可以調出來。
靈感從哪裡來
testframe-works 是受到作者 Luyu zhang 的 100 產品設計框架 pmframe.works 的啟發，整理測試領域的常見的測試框架，例如：測試金字塔（測試策略）、測試象限實踐（敏捷測試）。
大部分的內容是 AI 產生的，但我已經閱讀部分的框架內容，無奈資料量太打會有遺漏，或是連結錯誤，這個網站是免費使用的，不需要任何帳號或付費。如果你在使用過程中發現內容有誤，或是認為某個重要框架沒有被收錄，歡迎到 GitHub 提 issue，我會持續更新。
vansleee如果你對測試框架背後的思維更感興趣——不只是「這個框架叫什麼」，而是「為什麼需要這個框架」— 這也是我第一本書《我阿嬤都比你會測試》想傳遞的東西。框架是工具，思維才是讓工具真正發揮作用的那層東西。
用關鍵字搜尋
在某本書或某篇文章裡看過一個框架，但記不住完整名字？直接在搜尋框打關鍵字。框架名稱、提出者姓名、標籤都可以搜到。
用分類瀏覽
除了可以透過搜尋關鍵字找到對應的框架內容，也可以透過類型去了解目前某個領域內的測試方法等等。
在右上角有 Martick 測試象限，是根據四個面向將目前的測試框架分為不同的支援，可以透過 Martick 測試象限去分析目前產品哪一個象限做的比較少一點。
在每個框架裡面都會介紹使用步驟、提出者、甚至適用情境並且活耀的年代，點選深入了解可以有更想系的框架內容、和 Skill 可以下載。
框架頁面裡的範例分兩種：
- 標注「💡 情境模擬」的，是 AI 生成的誤用案例，用來說明這個框架被用錯時長什麼樣子。這不是推薦做法，請不要當成正面示範套用。
- 標注「真實事件」的，則是實際案例並附上來源。
我還整理的推薦書籍和每個框架的關鍵人物
推薦書籍：149 個框架引用的經典書籍與文獻，分類整理，方便你延伸閱讀
關鍵人物：影響測試領域的人，透過關鍵人物可以理解每個人在測試領域的研究方向與代表貢獻。
網站也依照軟體開發週期（SDLC）分類 — 在每個開發階段都有對應的測試框架，方便你根據目前所處的階段找到合適的方法。
框架是語言，不是答案
如果你對測試框架背後的思維更感興趣——不只是「這個框架叫什麼」，而是「為什麼需要這個框架」——這也是我第一本書《我阿嬤都比你會測試》想傳遞的東西。框架是工具，思維才是讓工具真正發揮作用的那層東西。