文章目錄
「這支 API 測過了。」這句話其實能包含很不一樣的意思。可能只是按了一次 Send，看到 200；也可能是正常、空白、重複資料都試過，連錯誤訊息都確認了。兩個人都說測過，心裡想的卻不是同一件事。
所以看到 Postman 在 2026 年 6 月推出 Datasets，我注意到的不是又多一個功能，而是測試資料終於有個比較固定的位置。自己試 API 時，臨時改一下 Email、換個 ID 很快，快到很容易什麼都沒留下。下次要重測，又得想一次當初到底試了哪些情況。
最怕的是忘了當初為什麼這樣測#
拿註冊來說，一個全新的 Email 可以成功，不代表這支 API 就沒問題。Email 沒填怎麼辦？已經註冊過呢？前端就算有檢查，API 也可能收到不經過這個畫面的請求。
我會想先留下三筆：正常註冊、Email 留白、Email 重複。每筆除了要送出的資料，也寫清楚預期結果。例如依這個假想 API 的規格，建立成功回 201，缺少欄位回 400，重複帳號回 409。狀態碼可以依專案約定不同，但不能只要有回應就算過關。
Postman 原本就能拿資料檔逐筆跑請求，Datasets 加強的是資料的整理與重用。把 CSV 或 JSON 接成資料來源，再用 view 選出這次要跑的欄位和案例，就能交給 Collection Runner。請求裡的 {{email}} 會換成每筆資料的值，不用再手動改來改去。
view 可以先把它想成存好的一份查詢。完整資料有二十筆，平常只跑三筆基本案例，需要確認錯誤處理時，再挑另外幾筆。不必為了兩種用途，各複製一份 CSV，然後過幾週開始懷疑哪份才是新的。
第一次過，第二次卻沒過#
註冊剛好還有一個很煩的小地方：第一筆成功跑完，那個 Email 就不再是「尚未註冊」了。下次重跑，收到重複帳號錯誤，可能完全不是程式壞掉。
這也是為什麼整理測試資料時，要一起想清楚測完要不要清理、下一次怎麼恢復起始狀態。否則資料整理得再漂亮，測試結果還是會讓人半信半疑。Datasets 能幫忙保管和選取資料，但不會替我們決定什麼叫測對，也不會自動把測試環境恢復原狀。
推出時它還是測試版，先支援桌面版裡接上 Git repository 的 Local View；CLI 和 Monitors 的支援當時還沒跟上。我不會為了試它立刻重整所有測試，倒是很想先把那幾筆每次都靠記憶輸入的資料搬進去。至少下次有人問「你測了什麼」，不用再回一句「就……正常那些」。