AI 讓開發者能在很短時間內產生功能雛形、修改既有邏輯，甚至補上一整段過去需要查文件、讀範例才寫得出來的程式。
開發流程看起來變順，測試工作卻會承受更大壓力。測試要先理解需求、整理情境、確認預期結果，再判斷要用單元測試（Unit Test）、整合測試（Integration Test）或端對端測試（End-to-End Test, E2E Test）來保護系統行為。
當生成速度超過測試建立速度，團隊很快就會累積一批「看起來完成」的變更。畫面能跑、介面有回應、主流程沒有錯，容易讓人誤以為風險已經被控制住，其實都還沒有經過完整驗證。
測試追不上時，風險會往後移動。原本應該在開發中發現的問題，會延後到程式碼審查（Code Review）、整合測試、使用者驗收，甚至正式環境才浮現。速度提高後，測試角色需要更早介入，先把需求行為、風險區域與驗證方式整理清楚，再讓 AI 協助產生程式與測試內容。
AI 產出的程式的麻煩之處在於它看起來很完整，命名合理、結構整齊，錯誤處理也像是已經被考慮過，容易讓人降低警覺。
傳統測試多半會先針對明顯錯誤下手，例如輸入錯誤、計算錯誤、流程中斷。AI 產出的錯誤常藏在看似合理的假設裡，測試設計需要更仔細。
這些失敗模式可能來自需求誤解。AI 可能把「主管可查看部門資料」理解成「主管可查看所有資料」。也可能把「退款後不得再次申請」寫成只檢查當前狀態，沒有處理歷史紀錄。
程式碼可以執行，行為卻已經偏離業務規則。
另一種失敗模式來自系統脈絡不足。AI 可能把局部邏輯寫得通順，卻沒有理解整體流程。單元測試可能會通過，整合到完整流程後，才發現資料欄位、交易邊界或權限規則對不上。
AI 時代的測試需要確認三件事：行為是否符合需求、設計是否遵守系統邊界、資料變化是否符合預期。測試策略也要從檢查明顯錯誤，延伸到檢查 AI 是否帶入錯誤假設。
AI 協助產生測試時，最直接的幫助是補出基本案例、邊界條件與錯誤輸入，也能減少撰寫測試樣板的時間。對測試不足的系統來說，這些內容可以作為起點，讓團隊先建立初步安全網。
AI 生成的測試仍需要品質檢查。它容易根據現有程式碼反推出測試案例，最後測到「目前程式怎麼做」，需求原本的運作規則反而沒有被檢查。
當原始程式已經有錯，AI 生成的測試也可能把錯誤行為固定下來，讓團隊得到一組看似可靠的綠燈。
生成出來的測試常偏向能順利通過的情境。成功路徑（Happy Path）會被寫得比較完整，權限不足、資料不存在、重複送出、外部服務逾時、併發操作等情境，仍需要人主動要求與補充。測試用例的數量增加，不代表系統風險已經降低。
團隊應把 AI 生成的測試當成草稿，回到規格、驗收條件和具體範例，檢查案例名稱、輸入資料與預期結果，看是否能說清楚保護的是哪一條規則。
AI 可以加快撰寫，人仍要負責判斷這些測試能不能保護系統。
測試金字塔（Test Pyramid）原本想提醒團隊：底層需要大量快速、穩定、容易定位問題的測試。上層測試接近真實使用情境，執行成本較高，情境也較複雜，因此數量需要控制得更精簡。
AI 加速開發後，這個觀念需要重新被看重，因為高速變更最怕所有錯誤都等到完整流程才被發現。
單元測試負責驗證局部邏輯意圖。它關心的是某個函式、類別或模組在特定輸入下，是否產生預期結果。
折扣計算、權限判斷、狀態轉換、欄位格式化，這些規則一旦被 AI 改偏，單元測試可以很快指出問題位置。
AI 很適合協助產生單元測試草稿，特別是補齊常見輸入、邊界值和錯誤資料。不過單元測試的名稱、測試意圖和預期結果仍要由人確認。
單元測試的價值在於回饋快。AI 修改一段邏輯後，開發者不用等到完整流程測完，才發現最基本的規則已經出錯。
整合測試關心不同模組、服務、資料庫與外部系統之間的互動。AI 產出的程式常能讓局部邏輯通過，到了系統邊界才出現問題。
資料格式不一致、交易邊界處理錯誤、介面契約變更、事件欄位語意不同，或外部服務失敗時沒有正確補救，都可能讓流程在整合後才壞掉。
AI 容易根據單一檔案或局部上下文產生看似合理的實作，卻沒有完整理解系統之間的約定。
舉例來說，某個欄位在交易服務代表「付款完成時間」，在庫存管理服務卻被當成「訂單成立時間」。程式可以編譯，單元測試也能通過，跨服務流程卻會產生錯誤報表或錯誤通知。
整合測試的主要瓶頸，常落在環境與資料準備。資料庫狀態、帳號權限、訂單狀態、外部服務回應、訊息佇列內容與時間條件彼此有關聯，少一個狀態就可能讓測試失敗。
若測試資料建立方式不穩定，團隊會花很多時間判斷是程式錯、資料錯，還是測試環境壞掉。
AI 在產生整合測試時，最困難的地方也在這裡。它可以依照程式碼快速寫出測試流程，卻不容易掌握跨系統狀態背後的業務語意。
像是訂單在付款後、保留了庫存、發票尚待開立，這些狀態需要一起成立，測試才有意義。若 AI 只看到局部程式碼，常會建立出看似合理、其實不符合真實流程的測試資料。
測試替身（Test Doubles）的維護也會影響整合測試品質。模擬物件（Mock Object）、樁件（Stub）與假實作（Fake）可以降低外部依賴造成的不穩定，讓測試更容易執行。
這些替身仍要貼近真實系統行為。若 AI 產生的模擬回應過度簡化，只固定回傳成功結果，逾時、失敗、重試、資料不一致與補償流程就不會被檢查到。
整合測試要保護的是系統邊界的一致性。資料庫存取、介面呼叫、訊息佇列、檔案匯入匯出、第三方服務串接，都需要透過測試確認重要約定沒有被破壞。
這類測試不用追求大量覆蓋，重點在於挑出風險高、影響大的互動點，並讓測試資料、環境設定與測試替身能被穩定重建。
AI 可以根據介面規格、資料表結構或事件範例產生整合測試草稿。不過測試如果把外部依賴包得太完整，最後驗證到的仍是團隊自己假設出來的互動。
端對端測試從使用者或外部系統的角度出發，驗證一整段流程是否能順利完成。
它接近真實情境，因此很有價值，也比較昂貴。執行速度慢、維護成本高、失敗時定位時間長，是這類測試常見的代價。
AI 加速開發後，團隊容易想把大量情境都交給端對端測試保護。這樣短期看起來安心，長期會讓測試管線變慢，也會讓失敗訊號變得模糊。
每次小改動都要跑一大批端對端測試，團隊會開始等待測試結果。測試一旦不穩，大家也會降低對它的信任。
端對端測試適合保護關鍵行為。所謂關鍵行為，是使用者真的會走、出錯代價高、跨越多個系統的流程。
例如註冊、登入、付款、退款、權限申請、資料匯入、報表產生。這些流程一旦壞掉，會直接影響使用者、營收、營運或合規，因此值得用較高成本的測試來保護。
測試金字塔在 AI 時代的重點，是讓不同層級各自承擔合適責任。單元測試提供快速回饋，整合測試守住系統邊界，端對端測試確認關鍵流程。
三層分工清楚，高速變更才不會全部壓到最慢、最貴的測試上。
測試覆蓋率（Test Coverage）常被用來觀察程式碼有多少比例被測試跑過。這個數字的參考價值是能讓團隊看見哪些地方有測試保護，哪些地方幾乎沒有被碰過。
AI 可以很快產生大量測試，讓覆蓋率變得高度完整，測試品質卻未必一起提升。
高覆蓋率只能說明程式碼被執行過，不能直接代表需求已經被正確驗證。
某段測試可能只是呼叫方法、檢查沒有拋出錯誤，或確認回傳值不為空。這類測試能讓覆蓋率變漂亮，卻無法說明業務規則有被保護。當 AI 根據現有程式碼產生測試時，這種情況需要被留意。
AI 產生測試的速度很快，若缺少控制，也會造成大量脆弱測試（Fragile Tests）。這類測試對實作細節過度敏感，例如綁定內部方法呼叫順序、過度檢查中間狀態、依賴不穩定測試資料，或把模擬設定得太細。
當業務需求只是微調，開發者卻要跟著修復數十個甚至數百個無效測試，測試就會從安全網變成維護負擔。
測試程式碼也需要可維護性。測試名稱、測試資料建立方式、斷言內容與輔助函式，都會影響後續修改成本。
若 AI 產生的測試大量重複、命名模糊、資料準備散落各處，團隊後續很難判斷每個測試保護的是哪一條規則。覆蓋率看起來提高了，測試庫卻變得更難整理。
因此，測試程式碼也要定期整理。重構測試時，驗證意圖要保留下來，測試也要變得更容易閱讀、維護與擴充。
像是抽出共用的測試資料建立器、整理測試資料、刪除重複測試、調整過度脆弱的斷言，都能降低長期成本。AI 可以協助整理草稿，人要確認原本想驗證的規則沒有被改掉。
測試真正有價值的地方，在於它能說明某個重要行為已經被驗證。例如付款金額不能為負數、取消訂單後不能再次出貨、未授權使用者不能讀取資料，這些測試都指向明確規則。
在 AI 生成測試越來越容易的情境下，覆蓋率比較適合提醒「哪裡需要再看一下」，不適合直接當作品質分數。
低覆蓋區域代表修改風險較高。當某段程式幾乎沒有測試保護，開發者在修改時就很難知道哪些行為受到影響。
AI 參與修改後，問題會被放大：它可以很快產生一組看似合理的實作，團隊卻缺少自動化測試來確認舊行為有沒有被破壞。
低覆蓋不一定代表程式有錯，它代表快速回饋不足。每次修改都要靠人工檢查、手動測試或資深成員的記憶來判斷結果。
這會讓團隊對某些區域變得保守，尤其是關鍵核心業務和跨系統整合等區域。這些地方一旦出錯，影響常會超出單一功能。
AI 也可能把低覆蓋區域當成一般程式來修改。它不一定知道這段邏輯背後有歷史包袱、例外客戶、舊資料格式或特殊營運規則。當測試不足時，這些隱性規則就不容易被看見。
低覆蓋區域需要成為風險地圖的一部分。團隊不用一次把所有地方補滿測試，可以先找出變更頻繁、曾經發生事故、業務影響高的區域，優先建立測試保護。
覆蓋率最有用的地方，是協助團隊排定改善順序。它讓測試不足從模糊感覺變成具體區域。
當覆蓋率資料搭配變更紀錄、事故紀錄與模組複雜度一起看，哪些地方該先補安全網會更清楚。
適合優先處理的區域，會有幾個特徵：最近常被修改、出錯代價高、理解成本（Cost of Understanding）高、依賴其他系統。
這些地方只要缺少測試，每次變更都會拖慢團隊。AI 能加快修改速度，仍無法消除驗證需求。
覆蓋率也能幫助團隊設計漸進改善。面對一個沒有測試的舊模組，團隊不用一開始就追求完整覆蓋。
可以先為最重要的行為補上特徵測試（Characterization Test），也就是描述目前系統實際行為的測試。接著再針對新的變更補上更明確的規格測試。這樣做能降低重構與修改時的風險。
把覆蓋率當成診斷工具，討論就會回到「哪裡風險最高」、「哪裡最需要快速回饋」、「哪些測試真的能保護關鍵行為」。
在 AI 時代，測試覆蓋率仍然重要，只是它需要服務風險判斷與改善排序，不能單獨被當成品質結論。
AI 開發流程要有測試保護，起點要放在規格。這裡的規格不需要一開始就很龐大，它可以是驗收條件、行為範例、情境、行為與結果，也可以是產品、工程與品質保證共同整理出的關鍵情境。
第一步就是把「這個功能應該怎麼運作」說清楚，讓後面的生成與測試都有共同基準。
如果團隊直接請 AI 寫程式，再回頭補測試，AI 容易根據已經寫好的實作產生測試。這樣測到的內容會貼近目前程式碼，卻不一定貼近需求。
當需求理解一開始就有偏差，測試也可能把偏差固定下來，讓團隊誤以為功能已經受到保護。
應該先把重要行為寫成可檢查的規則，這些規則會成為 AI 生成程式的上下文，也會成為測試案例的來源。
規格先行還能提早討論邊界條件。成功路徑容易理解，失敗路徑容易被忽略。權限不足、資料不存在、重複送出、外部服務逾時、舊資料格式、時間區間判斷，這些情境如果在生成前先被整理出來，AI 產出的程式就不會只沿著主流程前進。
規格整理清楚後，可以讓 AI 協助產生測試草稿。測試案例常包含大量重複結構，例如建立資料、呼叫方法、驗證結果、清理狀態。這些樣板工作交給工具處理，開發者就能把注意力放在測試意圖與風險判斷上。
使用 AI 產生測試時，輸入內容要盡量包含需求規則、範例資料、邊界條件與系統限制。
只要求「產生單元測試」，多半會得到很表面的結果。提供具體情境，例如「未登入使用者建立訂單要回傳 401」、「庫存不足時不能扣款」、「同一張優惠券不能重複使用」，生成結果才會接近需求。
AI 產出的測試草稿需要經過人工整理。開發者要看測試名稱是否描述清楚、測試資料是否合理、預期結果是否符合規格、模擬物件是否過度包裝。
外部依賴如果全部被替換成假的成功回應，整合風險就會被遮住。測試如果只驗證方法有被呼叫，也很難保護真正的業務行為。
團隊需要先把測試分層，哪些規則適合作為單元測試，哪些行為需要透過整合測試驗證，哪些流程應該提升為端對端測試，最好在草稿階段就先分清楚。
這樣 AI 生成測試時，才不會把所有驗證都塞進同一層，造成測試變慢、定位困難，也讓失敗原因更難判斷。
測試放進 AI 開發流程後，測試結果可以成為修正訊號。
當 AI 產出的程式造成測試失敗，若只提供錯誤訊息，AI 很難判斷問題出在程式、測試，還是原本的需求理解。
團隊可以把失敗訊息、相關規格、測試案例與限制條件一起提供給 AI，讓它協助分析原因並提出修正。
測試失敗時，不應只要求 AI「修到測試通過」。這種指令容易讓 AI 朝最短路徑修補，例如硬編碼回傳值、放寬驗證條件、修改測試預期結果。應該要先要求 AI 先解釋失敗原因，再說明修正方案如何符合規格，最後產生修改內容。
團隊需要在這裡建立明確邊界，同一輪 AI 修正中，只允許修改系統程式碼或測試程式碼其中一邊。
若目標是讓既有測試通過，AI 只能修改系統程式碼，不得同時調整測試。若目標是補齊測試，AI 只能新增或修改測試，不得順帶更動系統邏輯。
這項限制可以避免 AI 為了讓測試顯示綠燈，直接將測試改成符合目前錯誤實作的版本。
對風險較高的功能，團隊也可以把「生成系統程式碼」與「生成測試」交給不同的 AI 代理人（AI Agent）。
第一個代理人依照規格產生系統實作，第二個代理人只讀規格與驗收條件來產生測試，不直接依賴第一個代理人的實作細節。這樣做能降低同一個錯誤假設同時進入程式與測試的機率，也能讓測試更接近需求描述。
這個做法的前提是規格要夠清楚。若兩個代理人使用相同的基底大型語言模型（Large Language Model, LLM），面對同一份模糊規格時，仍可能產生高度相似的誤解。
規格裡沒有說清楚角色、條件、例外情境與預期結果時，兩個代理人可能各自用相同錯誤邏輯完成實作與測試，最後測試通過，團隊卻得到假性信心。
分離實作與測試代理人只能降低部分風險，不能取代規格釐清。團隊仍要先用驗收條件、行為範例與邊界情境，把需求描述到足以檢查的程度。
必要時，可以讓測試代理人先列出它對規格的理解與假設，再由人確認後才產生測試。
對關鍵邏輯，團隊可以搭配變異測試（Mutation Testing），刻意對程式做小幅錯誤變更，再觀察測試是否會失敗。若程式被改錯後測試仍然通過，就代表測試沒有真正保護該行為。
測試結果能幫助團隊縮短回饋循環。開發者可以先讓 AI 產生小範圍變更，執行相關測試，讀取失敗訊號，再調整下一版。
這種短循環能避免一次生成過大範圍的變更，也能讓風險提早暴露。當失敗集中在同一類情境時，就能再回頭改善規格、測試資料或提示詞（Prompt）。
最後仍要保留人工判斷。AI 可以根據測試結果協助修正，開發者仍要確認修正是否符合需求、是否破壞架構邊界、是否引入新的耦合。
測試讓 AI 開發流程有了回饋，人工判斷則讓這個回饋不會只追求綠燈。
iThome鐵人賽
看影片追技術