SoapUI 至今依然做得好的地方
SOAP 與 WSDL。 這是真正一流的支援，多數現代工具頂多把它當成事後才補上的附加品，甚至根本不支援。
複雜訊息的組裝。 深入的 XML 操作與斷言，正好是企業整合所需要的。
Mock 服務。 內建功能，可以架起假的端點供開發時串接。
如果你的工作大量涉及 SOAP，就要謹慎評估自己會放棄掉什麼。它的涵蓋廣度是真的。
那為什麼團隊還是會另尋他路
| 為桌面而生的工作流程 | 專案檔案放在某個人的電腦裡，很難進行審查。變更在 pull request 裡也難以看出是誰改了什麼。 |
| 與管線之間的摩擦 | headless 執行做得到，只是過程很少讓人愉快。測試報告也不會出現在 CI 其他報告匯集的地方。 |
| REST 的使用手感 | 它的模型是為 SOAP 打造的。REST 能用，但用起來像是後來才移植進去的。 |
評估 SoapUI 替代方案時該比較什麼
| 比較面向 | SoapUI | TestSprite |
|---|---|---|
| 協定涵蓋範圍 | SOAP、WSDL、REST、JMS 等 | 針對執行中服務的 REST API |
| 測試放在哪裡 | 專案檔案，在桌面用戶端中編輯 | 就在專案裡，以白話描述 |
| 測試覆蓋怎麼建立 | 每一個請求與斷言都要有人親手做出來 | 由規格文件或探索流程自動產生 |
| 工作階段與狀態 | 由你自己維護的屬性與指令碼 | Auto-Authentication 與 Dynamic Variables |
| 執行順序與清理 | 測試案例順序，再加上 teardown 指令碼 | 自動推導出的執行順序，以及 Auto-Cleanup |
| 與管線的契合度 | headless 執行器，報告自成一套 | 由變更觸發，結果直接回報在 pull request 上 |
狀態處理的運作機制，詳見 API 測試文件。
搬遷前該做的檢查
先盤點哪些東西真的是 SOAP。團隊常會發現，整套測試有九成其實是 REST，只剩下少數幾個多年沒人碰過的舊有 SOAP 端點。如果你的情況正是如此，這場搬遷會比看起來小得多，剩下的 SOAP 也可以留在原地。
如果真的大量使用 SOAP，就別為了使用手感而搬家。涵蓋範圍更重要。
該怎麼評估這些工具
刻意弄壞一個東西。製造一個真實的迴歸問題，例如存檔之後資料不再保留，然後看看每個候選工具會回報什麼。它會失敗嗎？失敗訊息有沒有點出真正的落差所在？負責修的人能不能直接從那份輸出著手，而不必自己重新拼湊來龍去脈？如果一次執行根本沒跑到斷言，工具卻回報通過，那它已經沒通過唯一重要的那項測試。
搬遷前先把測試套件拆開
真正行得通的搬遷幾乎不會是一次到位，而且拆分比想像中容易，因為 SOAP 和 REST 很少交錯出現在同一個測試裡。
先從替每一個測試案例依協定貼上標籤開始。多數團隊會分出三類：針對舊有服務、真正使用 SOAP 的測試；針對較新服務的 REST 測試；以及少數因為流程橫跨新舊世代而兩邊都碰到的測試。第一類留在原地，並且不再構成把整套測試都留在那裡的理由。第二類搬走。第三類值得逐一檢視，通常可以拆成兩個測試，當初會合在一起往往只是圖方便，而不是非如此不可。
先把標籤貼完，搬遷才會有一個看得見的終點；一個專案能不能真的結案，和一年後還做到一半，差別就在這裡。
開始使用
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
如果你不想安裝任何東西，在儀表板上做同樣的事也可以。命令列還能做的其他所有事情，都收錄在 CLI 儲存庫。
GitHub App 是你在 TestSprite 儀表板中設定的一個 webhook。它會監聽你的管線本來就會產生的部署事件，因此你的儲存庫完全不用改動。
GitHub Actions 則是把這個步驟放進你自己的工作流程裡，從終端機完成設定。
TestSprite 在 REST 這一側涵蓋什麼
你原本那套測試中，REST 部分在做的事它都能做，只是工作流程是為管線而設計，而不是為桌面。測試案例就放在專案裡，以白話描述，也用同樣的方式調整，所以任何一次變更都是第二個人可以審查的東西。
狀態處理直接由產品提供：Auto-Authentication、Dynamic Variables、Dependency Chains 和 Auto-Cleanup；這些在 SoapUI 裡，是你得自己維護的屬性、transfer 步驟、測試案例順序與 teardown 指令碼。
測試由你的部署或你自己的工作流程觸發，結果會以留言的形式出現在 pull request 上。你的 SOAP 工作留在有妥善支援的地方，而整場搬遷有一個看得見的終點，不會一年後還做到一半。
TestSprite 支援 SOAP 嗎？
它的重點是針對執行中服務的 REST API。如果測試套件大量使用 SOAP，請保留原本能妥善處理 SOAP 的工具，REST 的部分再交給這套工具。
我們可以轉換既有的 SoapUI 專案嗎？
把它們當成現有內容的清單來盤點，而不是拿來轉換的東西。端點清單，以及大家真正在意的那些斷言，才是有價值的內容。
那 Mock 服務怎麼辦？
那是另一項獨立的能力，如果你依賴它就值得保留。Mock 和驗證本來就是兩件不同的工作。
與其換掉工具，升級 Pro 版划算嗎？
如果問題出在功能，有可能。如果問題是工作流程不適合管線，換一個授權方案並不會改變這件事。
轉換期間要怎麼同時跑兩套？
讓兩套各自負責不同的範圍，都從 CI 執行。沒有理由要一步到位地切換過去。