針對三種不同缺口的最佳 AI 測試工具
數量。 「我們幾乎沒有測試。」你要的是自動生成。要留意的是,生成出來的測試會繼承程式碼本身的假設。
維護。 「我們有一半的測試是紅的,而且原因跟產品無關。」你要的是能自我調適的執行機制。要留意的是,它該在行為真的改變時失敗,而不只是撐得過外觀上的改動。
信任。 「測試全綠,發布出去照樣壞掉,而且大部分程式碼都是 agent 寫的。」你要的是對著運行中的產品做驗證。
能區分出候選產品的那個問題
不論你缺的是哪一塊,都要問:失敗的時候會發生什麼。一列紅字只是 demo。真正堪用的工具會告訴你它嘗試做了什麼、應用程式實際做了什麼,以及兩者從哪裡開始分岔,而且是以負責修的人不必自己重建整段來龍去脈就能動手的形式呈現。
當負責修的是 coding agent,這件事的重要性還要再加倍,因為它沒辦法瞇著眼看一張截圖,然後自己推敲出原本的意圖。
第二個問題
第一次使用結束時,你拿到的是一道接進交付流程裡的檢查,還是螢幕上的一份報告。這裡講的每一個類別,只要測試得靠人記得才會跑,最後都等於零。
每個類別共有的陷阱
和程式碼出自同一位作者的測試,一定會同意程式碼的說法,包括兩邊都錯的地方。用生成的測試去跑生成的程式碼,再高的通過率也幾乎不帶任何資訊。你真正要買的,是一道對照預期行為、獨立進行的檢查。
要小心的 demo 把戲
這個類別裡幾乎每個產品,展示的都是同一件事:用自然語言描述一段流程,看著它跑起來,看它通過。那確實令人印象深刻,但它幾乎沒有測到任何你真正在意的東西。
它展示的,是這個工具能在某人挑好的順利路徑上操控瀏覽器。你真正需要知道的,是應用程式出錯時會怎樣、介面改版時會怎樣,以及沒有人在盯著的時候會怎樣。這三件事,都不會出現在照腳本走的 demo 裡。
所以,請他們展示另外三件事。給我看一份失敗報告。給我看改版之後會發生什麼。給我看沒有人去啟動、檢查自己跑起來的樣子。三件都做得到的產品會很樂意展示;做不到的,就會把話題帶回那條順利路徑,而這本身就是答案。
該怎麼正確評估
試用期間,真的去弄壞一個東西。一個存了卻不再保留的儲存動作、一個默默把全部資料都回傳的篩選器。候選產品會失敗嗎、失敗時會不會指名是哪裡分岔了、負責修的人能不能從這裡直接動手。半天就夠,而且勝過一個月的功能比較。
終端機
npm install -g @testsprite/testsprite-cli
testsprite setup
如果你不想安裝任何東西,儀表板也能做到同樣的事。命令列能做的其他一切,都收錄在 CLI 儲存庫。
從儀表板連上儲存庫,測試就會從你本來就會產出的部署開始執行;或者,你也可以改成在自己的工作流程裡加上一個步驟。
TestSprite 是為哪一塊缺口打造的
信任。它會打開你正在運行的應用程式,像真人一樣操作它,並把壞掉的東西整理成單一份資料,讓你的 coding agent 可以直接動手處理。測試案例是從你的產品生成出來的,再用白話文調整;每個步驟記錄的是意圖,而不是選擇器;第一次使用結束時,你拿到的是一道跑在 pull request 上的檢查,而不是螢幕上的一份報告。
它會生成測試案例,也撐得過介面改動,所以數量和維護這兩塊缺口它同樣會碰到,但那些是為了得出結論而存在,並不是重點本身。
你得到的是:那些一壞掉就會讓你很難看的流程,在每一次變更時都被驗證過,而失敗時會直接指出是哪裡分岔了。如果你真正的抱怨是寫測試很繁瑣,或是現有的測試套件不穩定,評估時就把話說清楚,改去看那些專為這些問題打造的產品。
到底哪一個工具才是最好的?
缺數量,就找生成工具。缺維護,就找能自我調適的執行器。想對 agent 寫的程式碼有信任,就找能對著運行中的產品做驗證的工具。先說清楚你缺的是哪一塊。
有可能用一個工具三塊全包嗎?
某種程度上可以,但設計重心會露出馬腳。問這個產品用什麼指標衡量自己,你就會知道它當初是為哪個問題打造的。
我們大概該預期花多少錢?
要比的是總成本,不是授權費。一個便宜、卻需要一名工程師去維護的工具,並不便宜。
免費方案呢?
好的不少。成本從來就不在授權,而在撰寫和維護,而這部分不管選哪一邊都差不多。
一次評估該花多久?
長到足以涵蓋一次真正的發布,和一次真正的回歸問題。少了這兩者,你評估的只是上手流程。