ISTQB 七大原則，我工作三年才真正懂的那幾條

<p 原則本身誰都查得到。難的是——它什麼時候會在你身上發生，而你認不認得出來。這篇不重述定義，只講每一條原則，後來在我身上長成了什麼樣子。</p <h2 七大原則，與它們真正咬人的時刻</h2 <p 先把七條擺出來，一句話定義，再說我踩到的版本。</p <table style="min width: 75px;" <colgroup <col style="min width: 25px;" <col style="min width: 25px;" <col style="min width: 25px;" </colgroup <tbody <tr <th colspan="1" rowspan="1" <p 原則</p </th <th colspan="1" rowspan="1" <p 教科書說</p </th <th colspan="1" rowspan="1" <p 我學到的版本</p </th </tr <tr <td colspan="1" rowspan="1" <p 1. 測試顯示缺陷存在</p </td <td colspan="1" rowspan="1" <p 測試證明有錯，不能證明沒錯</p </td <td colspan="1" rowspan="1" <p 「我測過了」不等於「沒問題」</p </td </tr <tr <td colspan="1" rowspan="1" <p 2. 窮盡測試不可能</p </td <td colspan="1" rowspan="1" <p 測所有組合不切實際</p </td <td colspan="1" rowspan="1" <p 所以你選什麼不測，才是真本事</p </td </tr <tr <td colspan="1" rowspan="1" <p 3. 盡早測試</p </td <td colspan="1" rowspan="1" <p 越早測越省成本</p </td <td colspan="1" rowspan="1" <p 越早測，省的是別人的時間</p </td </tr <tr <td colspan="1" rowspan="1" <p 4. 缺陷具叢聚性</p </td <td colspan="1" rowspan="1" <p bug 集中在少數模組</p </td <td colspan="1" rowspan="1" <p 上次爆的地方，這次大概也爆</p </td </tr <tr <td colspan="1" rowspan="1" <p 5. 殺蟲劑悖論</p </td <td colspan="1" rowspan="1" <p 重複同案例抓不到新 bug</p </td <td colspan="1" rowspan="1" <p 你的回歸套件正在過期</p </td </tr <tr <td colspan="1" rowspan="1" <p 6. 測試視情境而定</p </td <td colspan="1" rowspan="1" <p 不同領域嚴謹度不同</p </td <td colspan="1" rowspan="1" <p 沒有「最佳實踐」，只有「這裡適合什麼」</p </td </tr <tr <td colspan="1" rowspan="1" <p 7. 沒有錯誤不代表有用</p </td <td colspan="1" rowspan="1" <p 找不到 bug 也可能是爛產品</p </td <td colspan="1" rowspan="1" <p 做對了規格，不等於做對了東西</p </td </tr </tbody </table <p 下面挑幾條真正在我工作裡留下疤的。</p <h3 第 2 條：窮盡測試不可能 —— 重點不是「測不完」，是「你敢不敢決定不測」</h3 <p 剛入行時我把這條讀成一句洩氣話：反正測不完，盡力就好。完全錯。</p <p 這條真正的意思是：既然測不完，<strong 那你怎麼選</strong 就是專業所在。你願意明確說出「登入流程我測到死，後台某個三年沒人動的報表頁我這版不測」——並為這個取捨負責——那才是測試設計。風險基礎測試整套方法，就是建在這條原則上（我寫過一篇講<a target=" blank" rel="noopener noreferrer nofollow" href="/blog/risk based testing max value" 怎麼用風險決定測試優先序</a ）。</p <p 含糊地「盡力測」不是謙虛，是逃避決策。</p <h3 第 3 條：盡早測試 —— 省的是別人的時間，所以你要主動往前擠</h3 <p Capers Jones 的經典統計：缺陷修復成本每往後一個開發階段，大約增加 10 倍。需求階段抓到改一行字，上線後抓到可能是一次 hotfix 加一場事後檢討。</p <p 但這條的陷阱是，「盡早」聽起來像在說測試執行要提前——不是。是<strong 測試思維</strong 要提前。需求還在 Figma、PRD 還在吵的時候，QA 就該進去問「這個 empty state 怎麼處理」「網路斷了會怎樣」。那時候提出來，改的是一句規格；等做完再提，改的是別人三天的程式碼（這也是我對 <a target=" blank" rel="noopener noreferrer nofollow" href="/blog/shift left paradox" shift left 的一些保留</a ——左移不是把活往前塞，是把問題往前問）。</p <h3 第 4 條 + 第 5 條：叢聚性與殺蟲劑悖論 —— 一對矛盾的雙胞胎</h3 <p 這兩條放一起看才有意思，因為它們表面上打架。</p <p <strong 叢聚性</strong 說：bug 集中在少數模組，上次爆的地方這次大概也爆，所以火力要集中在那。Pareto 在這裡很真實——大約 80% 的缺陷來自 20% 的模組。</p <p <strong 殺蟲劑悖論</strong 說：同一組案例跑久了就失效，因為那些 bug 早被修光了，蟲對你的藥產生抗性。</p <p 所以呢？火力集中在熱點（第 4 條），但用同一套案例反覆打那個熱點，又會鈍化（第 5 條）。解法是：<strong 盯著對的模組，但不斷換新的攻擊角度</strong 。同一個高風險模組，這版用邊界值打、下版用異常流打、再下版用併發打。熱點不變，彈藥要換。</p <p 我自己的回歸套件就吃過這個虧——跑了一年全綠，漂亮得可疑。後來換了個新人用沒看過的路徑點一遍，當場三個 bug。不是程式變爛，是我的測試對它免疫了。</p <h3 第 7 條：沒有錯誤不代表有用 —— 最容易背、最難做到的一條</h3 <blockquote <p <strong ⚠️ 注意：</strong 這是七條裡唯一一條，會讓「測得很乾淨」變成一種危險的自我感覺良好。</p </blockquote <p 你可以把所有 bug 都修光、所有案例都綠燈，然後交出一個沒人想用的東西。因為你驗的是「規格有沒有被正確實作」，不是「這規格本身對不對」。</p <p 我看過一個功能，QA 報告漂亮無比，零缺陷上線，兩週後使用率趨近於零——因為它解決的是一個使用者根本沒有的問題。測試全綠，產品全錯。這條原則在提醒的是：QA 的終點不是「符合規格」，是「對使用者有用」。這也是為什麼我一直主張 <a target=" blank" rel="noopener noreferrer nofollow" href="/blog/bug vs spec problem" QA 要懂業務、要參與規格討論</a ，而不只是接收需求然後驗收。</p <h2 那 F.I.R.S.T. 呢？那是給另一群人的原則</h2 <p 很多人把 ISTQB 七原則和 F.I.R.S.T. 混在一起背，其實它們服務的是不同的人。</p <p 七大原則是<strong 測試這件事</strong 的世界觀，給所有做測試的人。F.I.R.S.T. 是<strong 單元測試怎麼寫</strong 的工程準則，主要給寫 code 的人（含寫測試 code 的 SDET）：</p <ul <li <p <strong F</strong ast（快）：跑得快，開發者才願意頻繁跑。</p </li <li <p <strong I</strong ndependent（獨立）：案例彼此不相依，任意順序、單獨都能跑。</p </li <li <p <strong R</strong epeatable（可重複）：任何環境跑結果一致——不依賴特定時間、特定機器、外部服務。</p </li <li <p <strong S</strong elf Validating（自我驗證）：明確輸出 pass / fail，不用人去翻 log 判讀。</p </li <li <p <strong T</strong imely（及時）：測試與正式碼同時或緊接著寫（TDD 的核心）。</p </li </ul <p 為什麼 QA 也該懂這套？因為當你開始 review 開發寫的單元測試，F.I.R.S.T. 就是你的檢查清單。一個依賴執行順序才會綠、跑兩次結果不同、或要人去看 console 才知道有沒有過的「測試」，違反的正是 I、R、S——它不是測試，是會說謊的綠燈。</p <p 我寫過一篇講<a target=" blank" rel="noopener noreferrer nofollow" href="/blog/unit test 100 but qa finds bugs" 單元測試 100% 覆蓋率，QA 還是抓到一堆 bug</a 的事。很多時候不是覆蓋率假，是那些測試根本不符合 F.I.R.S.T.，覆蓋了等於沒覆蓋。</p <h2 背過，和懂了，差三年</h2 <p 這些原則的價值不在背得出來，在於某天現場出事時，你腦中有一個名字可以套上去——「啊，這是殺蟲劑悖論」「這是第 7 條」。有了名字，你才講得清楚問題、說服得了團隊、也才知道下一步往哪走。</p <p 如果你正準備 ISTQB，背是必要的。但別停在背。挑一條，去你手上的專案裡找它正在發生的證據。找到那一刻，你會比考一百分還懂它。</p <h2 參考資料</h2 <ul <li <p <a target=" blank" rel="noopener noreferrer nofollow" href="https://www.istqb.org/certifications/certified tester foundation level ctfl v4 0/" ISTQB Certified Tester Foundation Level (CTFL) Syllabus</a — 七大原則的官方定義與情境出處</p </li <li <p <a target=" blank" rel="noopener noreferrer nofollow" href="https://astqb.org/" ASTQB — Seven Principles of Software Testing</a — 美國分會對七原則的整理與範例</p </li <li <p <a target=" blank" rel="noopener noreferrer nofollow" href="https://www.oreilly.com/library/view/applied software measurement/9780071502443/" Capers Jones, "Applied Software Measurement"</a — 缺陷修復成本隨階段遞增的數據來源</p </li <li <p <a target=" blank" rel="noopener noreferrer nofollow" href="https://archive.org/details/softwaretestingt0000beiz" Boris Beizer, "Software Testing Techniques"</a — 殺蟲劑悖論（pesticide paradox）一詞的原始出處</p </li <li <p <a target=" blank" rel="noopener noreferrer nofollow" href="https://github.com/tekguard/Principles of Unit Testing" Robert C. Martin (Uncle Bob) — The FIRST principles</a — F.I.R.S.T. 單元測試原則的常見整理</p </li </ul <p </p