API 測試人員工作的一體兩面
機械性工作
列舉端點、撰寫正常流程、檢查回應結構。
維護登入狀態、測試資料與清理作業。
一再重跑測試套件，並反覆分類處理同樣那幾個不穩定的測試。
判斷力
在規格沒有明說時，決定什麼才算正確。
找出可能被人鑽漏洞的商業邏輯。
分辨哪些失敗有意義，哪些只是雜訊。
自動產生測試很能處理第一欄，卻完全碰不到第二欄，因為第二欄談的是產品，而不是通訊協定。
哪些能力會變得更有價值
為模稜兩可的情況定義何謂正確。 當折扣與促銷同時適用時，應該怎麼算。規格裡沒寫，任何產生器也猜不出來。
對抗性思考。 我能不能下單負數量？能不能重送這個請求？能不能只改一個識別碼就存取別人的帳號？自動產生的涵蓋範圍會包含授權檢查，但它不會替你想出那些你根本沒想到的濫用手法。
審閱自動產生的涵蓋範圍。 一份橫跨上百個端點的計畫，需要有人刪掉雜訊、補上產品規則。這件事做起來很快、槓桿很高，而且要的正是 API 測試人員才有的那種知識。
哪些事該停止手動去做
寫第兩百個 CRUD 測試。維護 token 更新機制。為相依關係圖串接測試資料。重跑並分類同一套不穩定的測試。這些都用不到那些讓 API 測試人員有價值的知識，卻全是把時間吃掉的地方。
一套 API 測試能不能撐過第一年，取決於四件事：會過期的登入狀態、只在執行時才存在的值、彼此相依的呼叫，以及沒人清掉的資料。TestSprite 以 Auto-Authentication、Dynamic Variables、Dependency Chains 與 Auto-Cleanup 處理這四件事，詳見 API 測試文件。
最難被取代的能力
如果你在思考該把什麼練到精，答案不是某個工具，而是看著一條語意含糊的需求，能夠指出它有哪三種解讀方式的能力。
以「使用者只能看到自己的訂單」這樣一條規則為例。做過一陣子的測試人員會立刻追問：管理員呢？代人下單的訂單呢？被轉移過的訂單呢？帳號停用之後會怎樣？被刪除的訂單是看不到，還是根本不存在了？這些需求裡通通沒寫，卻全都會在正式環境發生。
沒有任何產生器列得出這份清單，因為它不是從規格推導出來的，而是從看過產品出包累積而來。當機械性的那一半愈來愈便宜，這部分工作就愈來愈值錢。
一個實際的做法
把測試產生指向你的服務，然後把時間花在計畫上，而不是花在程式碼上。刪掉管理用途的路由，補上沒人寫下來的產品規則，再加上因為你熟悉這個領域才想得到的反向案例。你一天涵蓋到的範圍會比手寫一週還多，而且涵蓋的是你的知識，不是規格書的知識。
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
如果你不想在本機安裝任何東西，TestSprite 儀表板裡也能完成同樣的設定。CLI 的其餘功能請見 CLI 儲存庫。
觸發時機比觸發方式更重要。把它接上部署事件，代表每一次變更都會被檢查，不必有人特地決定要跑； GitHub App 能從儀表板做到這件事，而一個 GitHub Actions 步驟則能從你的工作流程內部做到。
TestSprite 把判斷留給你的地方
它接手的是機械性的那一欄。API Discovery 會列舉服務對外開放了哪些內容，計畫則橫跨功能、結構描述、授權、錯誤處理與邊界等類別產生；執行過程中，Auto-Authentication 讓登入狀態持續有效，Dynamic Variables 在呼叫之間傳遞數值，Dependency Chains 依據每個案例需要什麼、產出什麼來推導執行順序，Auto-Cleanup 則只清除這次執行所建立的資料。
它刻意不做的，是決定什麼叫做正確。自動產生的計畫是一個起點，由你去刪減、修正與擴充，而這個編輯過程，正是你對產品的理解進入測試套件的途徑。花一小時在計畫上，涵蓋範圍會勝過手寫一週，而且涵蓋的是你的判斷，不是規格書的判斷。
對這個職位的實際結果是：你不必再寫第兩百個 CRUD 測試，而是把那些時間拿去處理含糊的規則與濫用情境，而這一直都是團隊需要你的原因。
自動化會取代 API 測試人員嗎？
它取代的是機械性的那一半。決定什麼才算正確、以對抗的角度思考，這兩件事不會消失，而且兩者都愈來愈稀缺。
我應該學什麼？
把產品領域學深。工具會換，但清楚知道你的系統對使用者許下什麼承諾，才是讓測試人員難以被取代的關鍵。
手動 API 測試還有用嗎？
針對新的或改動過的 API 做探索性測試，有用。用人力反覆做迴歸測試，沒用，而且從來就沒用過。
我要怎麼有效率地審閱自動產生的涵蓋範圍？
看計畫，而不是看程式碼。刪掉雜訊、補上缺漏，把注意力放在那些一旦出錯就代價高昂的端點上。
如果我的團隊根本沒有測試人員呢？
那麼需要判斷的那一半，要嘛是開發人員在不知不覺中做掉了，要嘛根本沒人做。無論最後由誰承擔，先把它明確講出來就是第一步。