登入 訂閱
測試框架地圖：我為什麼建了 testframe.works，以及你該怎麼用它
精選

測試框架地圖：我為什麼建了 testframe.works，以及你該怎麼用它

如果今天身為團隊或者是公司唯一的測試人員，有一天主管走過來問你：「我們的產品，還有哪些測試可以做？」，請 AI 列一份清單？說「我們應該多做一點測試」？還是憑直覺說幾個聽起來專業的名詞？是不是有更好的測試方法論或是邏輯判斷依據，讓你可以分析產品的品質呢？ 這個是莫約 4 年前，我們團隊接了一個遺留產品專案，原本功能是分散給各個產品團隊開發，但決定由一個團隊來負責，當時主管問了我這個問題，「我們還有哪些可以做的測試？」，而我當時的做法，是拿出測試金字塔和 Marick 測試象限，把產品現有的測試活動對應進去，然後看哪些格子是空的。空的格子，就是可以補強的地方。 使用任何的理論或框架，是需要了解當時的背景 隨著資歷越來越深，我越來越相信一件事：了解測試框架的來源、步驟與適用情境，跟會用這個框架同樣重要。 因為我們很容易看到某間公司的 Best Practice 就想直接套用，卻沒有注意到它的歷史背景。Google 的測試蜂巢模型是為了他們的系統規模設計的。Netflix 的混沌工程是為了分散式架構。把這些方法放到一個十人新創或中型企業，不一定適合你的團隊或你的公司，但搞清楚框架的
閱讀時間 7 分鐘
測試策略的全知讀者視角：從金字塔到 AI 時代的多次轉變

測試策略的全知讀者視角：從金字塔到 AI 時代的多次轉變

測試策略的全知讀者視角：從金字塔到 AI 時代的多次轉變 本文由作者撰寫主要觀點，AI 協助資料蒐集、結構編排與文字潤飾，最終由作者審定。 前言 在現代軟體開發中，測試已不再是開發完成後才啟動的獨立階段，而是必須貫穿整個開發流程的核心實踐。 但隨著前後端分離、微服務架構的普及，以及 AI 輔助開發的崛起，「應該怎麼分配測試資源」這個問題也開始有了不同的答案。測試金字塔（Testing Pyramid）作為敏捷時代的經典模型，正在被測試獎盃（Testing Trophy）、測試蜂窩（Honeycomb）、測試鑽石（Diamond）、測試螃蟹（Crab）等新模型挑戰與補充。 本文將從歷史脈絡出發，梳理這些模型的起源、適用場景與侷限，幫助你在不同的架構與團隊情境下，做出更合適的測試策略決策。 測試金字塔 起源與架構邏輯 測試金字塔最早由 Mike Cohn 在其 2009 年的著作《Succeeding with Agile》
閱讀時間 28 分鐘
拒絕加班的藝術：為什麼「測試左移」是測試工程師準時下班的救星？

拒絕加班的藝術：為什麼「測試左移」是測試工程師準時下班的救星？

前言 常常上線前三天才開始測新功能，結果一跑測試才發現功能與當初的文件不符合，於是開始與 PM 和開發釐清，花了幾天的時間，才搞清楚功能規格，但上線日期不會因為這些事情而延後，但我的下班時間會？ 我曾經試著將測試左移引導至開發流程裡，對於釐清使用者需求的效果不錯，但涉及團隊的開發習慣、公司組織架構與產品特性，落地的困難度不一。如果你和我真的很想準時下班，我們可以來重新看看「測試左移」會不會是測試工程師準時下班的救星。 測試左移的起源與定義 要理解左移能不能真的幫上忙，先看看它從哪裡來。 2001 年的時空背景 測試左移在 2001 年被提出，想要理解為什麼被提出，需要先理解當時的開發環境。首先要介紹瀑布模型（Waterfall Model）和 V 模型（V-Model）這兩個當時主流的開發模型。 瀑布模型（Waterfall Model） 由 Winston Royce 在 1970 年的論文中首次描述（諷刺的是，Royce 本人其實是在論述這個模型的缺陷）
閱讀時間 24 分鐘
你的 async 真的是 async 嗎？FastAPI 平行處理踩坑紀錄

你的 async 真的是 async 嗎？FastAPI 平行處理踩坑紀錄

#開發筆記 前言 這是一個 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(
閱讀時間 13 分鐘
實戰分享：如何用 Robot Framework 建立自動化測試流程

實戰分享：如何用 Robot Framework 建立自動化測試流程

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

在新創公司建立測試流程 — 從零開始的 QA 之路

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