安德魯的部落格

昨晚我在部落格發佈了一篇文章, “AI-First Testing Workflow”. 這篇講的其

2025/11/17

昨晚我在部落格發佈了一篇文章, “AI-First Testing Workflow”. 這篇講的其實是 ai 如何輔助有效的展開測試流程, 文章內我一直在提 “探索” 這件事, 文章內我沒有講太多 “探索” 這件事的本質, 我就用這篇 post 來介紹, 同時當作文章導讀吧..

整個測試流程, 我想打通的是:

  1. 展開測試範圍 (我用 decision table)
  2. 探索測試步驟 (就是靠這個 mcp)
  3. 撰寫可重複執行的測試程式碼 (靠探索的記錄, 及情境案例, 還有 API 規格)

其實 (2) 就是今年五月, 談 vibe testing 那篇文章在做的事情, 用自然語言敘述的測試情境, 搭配 open api spec , 讓 AI 運用 function calling 的能力, 即時的逐步呼叫 api 來達成 test case 的情境敘述｡

這幾個月分別跟不同的社群 & 工作夥伴聊過這做法, 其實想法還蠻多元的, 大家對 “探索” 這件事的想法都不同｡ 我先定義一下我指的 “探索” 是什麼:

如果我的 api 提供購物車的操作有: add(將商品加入/移除購物車), getinfo(查詢購物車目前狀態), estimate(試算結帳金額, 包含折扣), 而測試情境則要求購買四罐啤酒 + 兩罐可樂, 並確認最後結帳金額跟折扣的數字正確…

這樣的案例, 過去最難的其實是要有 “人” (尤其是工程師), 看懂 api 規格, 看懂 test case 測試案例, 並且把他翻譯成這樣的 procedure:

var c = new cart(); c.add(1, 4); // 啤酒 product id: 1 c.add(2, 2); // 可樂 product id: 2 var e = c.estimate(); Assert.AreEqual(e.price, xxx); Assert.AreEqual(e.discounts[0].type, “啤酒第二件六折優惠”); var co = new checkout(c); Assert.AreEqual(co.price, xxx); var order = co.Complete(”1234”); // … 以下略 —

這段過程, 過去沒有 AI 輔助, 就只能靠人工來撰寫了, 往往是非 rd 人員很難介入的測試流程, 而 rd 通常主要任務會在開發, 也不會把撰寫 api test 的任務擺在第一順位, 這環節就成了最大的瓶頸｡

而現在有了 AI, 開始有好幾種方法解決這問題, 我收到的 feedback 有:

  1. 直接把 test case 跟 api spec 交給 ai, 他就寫的出來了, 寫完再執行就好了
  2. (我半年前的做法) 用 function calling, ai 編作邊嘗試就能執行完畢了 (但是沒有 code)
  3. (改良做法) 用 mcp 封裝 function calling, 確認執行過程正確且順利執行, 將留下記錄讓 ai 寫成 code

中間過程我就跳過了, 從結果而論, (1) 不大可靠, (1) 很吃你的 api spec 寫的夠不夠好, 而就算再好的規格, 也難以敘述實際情況下各種可能的狀況, 例如 cart.add() 如果傳回錯誤該怎麼辦?

這時如果用 (1), 就要走到 debug 的流程了, 跑看看, 查 log, 改 code 候蟲來一次, 很難一次就完成｡

(2)(3) 的適應能力就好的多, 因為 ai 執行一步就看的到這步的結果, 判斷後才會執行下一步, 因此真的有 “探索” 的行為, 踩一步後沒有跌倒, 再繼續跨下一步, 沒路了就繞路直到走到目的地為止, 這是 “探索”｡

基本上, 如果 ai (模型) 的能力相同, 探索的適應性應該遠比 (1) 直接規劃來的有效, 因為他多考慮了實際執行的維度, 能在最短的時間內就找出可行的路徑, 除非這條路還沒蓋好 ( API 只有 spec 還沒有實作 ), 這時才考慮優先用 (1).

有夠強大的 “探索” 步驟的能力, 你撰寫跟維護 test case 的負擔就能降低｡ 我文章內的例子, 你不但可以同時降低 test case 需要描述的細節複雜程度 (你只需要敘述目的, 不用敘述詳細步驟), 而如果能乾淨的將操作細節都隔離掉的話, 你就可以省掉同時維護多種不同操作方式的負擔了, 同時縮減兩個維度的複雜度, 帶來的效益市很可觀的, 而這些能力則建立在: 你拿到這些精簡的 test case, 是否有足夠的準備, “探索” 還原出你執行測試需要的所有細節｡

經過這篇文章的整個 side project 驗證, 我覺得這條路是有機會的, 也許再過半年一年, 就有大廠來做這件事了 (搞不好 GitHub 出完 SpecKit 之後, 真的會推出 TestKit 也說不定), 不論如何, 現在做的研究都不會吃虧, 因為該怎麼使用他的基礎知識, 你已經具備了 😀

– 硬要跟 ai 沾上邊, 我就拿我很喜歡的作品 NieR: Automata 的圖當 Logo .. 那個時代已經沒有人類了, 通通都是在講 AI 的故事 (咦?

– 相關文章我一樣放在留言, 包含這篇文章 (AI-First Testing Workflow), 半年前的文章 ( Vibe Testing PoC ), 以及其他相關的討論, 我都放在留言內.

最後工商一下, 今年的 .NET Conf 我會探討 MCP 的 design concept, 雖然跟這主題沒有直接關聯, 但是這次 side project 如果我沒有開發 Text 2 Calls MCP 的話, 整個 project 應該沒機會成功吧! 這場次我介紹的 MCP 設計技巧, 其實都有用在上面, 如果你看完這篇想多了解 MCP 的設計精神, 歡迎報名參加今年的 .NET Conf :D





Facebook Pages