API 測試方法：依各自獨有的發現來區分
冒煙測試
能抓到：這次部署掛了。
成本：幾分鐘。永遠都要跑。沒有別的方法能這麼快告訴你。
功能測試
能抓到：單一端點的行為錯誤，包括輸入不合法時的行為。
成本：中等。是其他所有方法都預設已經存在的基礎。
整合測試
能抓到：每一步都通過、整串流程卻失敗的情況。
成本：較高，因為牽涉狀態。對使用者看得見的錯誤，收穫最大。
迴歸測試 不是一種獨立的方法，而是一種節奏：每次變更都把你已經有的測試跑一遍。 契約測試 抓得到獨立部署的服務之間，資料結構逐漸走樣的問題。 負載測試 抓得到容量上限。 模糊測試 抓得到格式異常的輸入造成的崩潰。 安全性行為 抓得到授權上的錯誤，而且遠比它給人的印象便宜。
最常被歸錯類的那一種
迴歸測試常被列為一種方法，然後被安排成一項活動，通常排在發版之前。這就是問題所在。迴歸是你既有的測試在執行時所做的事，而它們的價值幾乎完全取決於執行的頻率。一個月才跑一次的迴歸測試套件，就是一個晚一個月才找到問題的套件。
不必全做，也能做出選擇
關鍵端點上的冒煙測試加功能測試。 現有最便宜、又真的有用的覆蓋。
針對真實使用流程的整合測試。 使用者實際遇到的錯誤，真正藏身之處。
授權檢查。 便宜，而且是真實 API 中最常被利用的漏洞。
契約測試，只在服務各自獨立部署時才需要。
負載測試與模糊測試，在風險高到值得時再做。 兩者都是真本事，但都不該是你的第一筆投資。
黑箱測試與白箱測試
對 API 的工作而言，這個區分已經不像以前那麼重要。透過公開介面測試是正確的預設做法，因為那正是你的用戶端在用的東西。白箱知識的用處在於決定要測什麼，而不是決定怎麼測。
測試金字塔在 API 上會誤導人的地方
測試金字塔當初是為了單元與使用者介面的世界而畫的，直接套用到 API 的工作上，會導致一個常見的錯誤。
金字塔說：頂端的慢速測試要少。但對 API 來說，昂貴的究竟是哪一層並不明顯：一個 API 測試比瀏覽器測試便宜得多，又比單元測試貴得多，而且它抓得到另外兩者都抓不到的問題。把 API 測試對應到金字塔窄窄頂端的團隊，最後寫得太少；把它們對應到寬闊底部的團隊，最後得到一套又慢、又塞滿瑣碎斷言的測試。
對服務而言，更好的思考模型是問：哪一層根本才回答得了這個問題。計算對不對，屬於單元測試。端點有沒有正確套用它，屬於 API 測試。使用者究竟走不走得到那裡，屬於比這兩者更上層的測試。比例自然會從你的產品裡長出來，而不是從一張圖裡抄出來。
所有方法底下都需要的東西
有四件事決定一套 API 測試能不能撐過第一年：會過期的工作階段、只在執行期才存在的值、彼此相依的呼叫，以及沒有人清理的資料。TestSprite 以 Auto-Authentication、Dynamic Variables、Dependency Chains 與 Auto-Cleanup 處理這些問題，詳見 API 測試文件。
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
如果不想在本機安裝，儀表板同樣能做到這些事；完整的指令介面則在 CLI 儲存庫。
有兩條路可走，而選擇的重點其實在於誰擁有這條管線。從儀表板連接 GitHub App 完全不需要改動你的儲存庫，因為它會對你的建置本來就會發出的部署做出反應。加入一個 GitHub Actions 步驟，則是把這道檢查放進儲存庫裡，讓它像建置流程的其他部分一樣接受審查。
TestSprite 涵蓋哪些方法
功能測試與整合測試，加上安全性當中屬於行為的那一部分，再加上以節奏、而非以活動形式存在的迴歸測試。產生的測試計畫涵蓋功能、結構描述、授權、錯誤處理與邊界等類別，並可用白話文字加以調整。
Auto-Authentication 讓工作階段在整趟執行中保持有效，Dynamic Variables 在呼叫之間傳遞數值，Dependency Chains 依每個案例所需與所產出的內容推導執行順序，Auto-Cleanup 則只移除這趟執行所建立的東西。這才讓迴歸測試真正持續進行，而不是變成排在發版前的一項工作；而這一點，正是決定任何方法能不能帶來價值的最大關鍵。
契約測試、負載測試與模糊測試仍是各自獨立的工具。好處在於，收穫最高的那三種方法不必再跟功能開發搶撰寫時間，於是覆蓋是真的存在，而不是停留在計畫裡。
哪一種方法找到的錯誤最多？
在多數產品裡是整合測試，因為使用者看得見的失敗通常出現在呼叫與呼叫之間，而不是單一呼叫內部。
冒煙測試值得獨立成一套測試嗎？
值得。每次部署都會跑的兩分鐘檢查，和一套要跑二十分鐘的測試，任務並不相同；把兩者混為一談，結果就是兩者都不會在對的時間執行。
我們需要模糊測試嗎？
如果格式異常的輸入抵達你的服務會造成真正的後果，那就需要。對多數內部 API 而言，它的優先順序低於授權檢查與整合測試的覆蓋。
那探索式 API 測試呢？
確實有價值，而且無法自動化。在 API 剛推出或有大幅變動時做，然後把發現的結果寫成測試。
這些方法如何對應到測試金字塔？
只能大略對應。金字塔當初是為單元測試與 UI 而畫的。對 API 來說，有用的軸線是每項檢查獨有的發現，而不是它屬於哪一層。