【吐槽】低程式碼的介面自動化測試平臺不好用

前言

之前在小公司呆了一年半，搭建了 Python 的介面自動化框架，純程式碼實現雖說不算簡單，但自由度更好，能夠更好的除錯和新增功能。

之後來到國內某大公司的軟體測試工作（外包），到現在也呆了一年半多，公司使用的是零程式碼關鍵字驅動的介面自動化測試平臺，有點類似於這個平臺。寫了 30+ 用例，有一些自己的感想，故分享出來

無法轉化為自身價值

就算把平臺使用得再好，出去了就沒有了這樣的平臺，所有的經驗就都失效

公司強調線上作業，在這樣的一個前提下，測試人員被迫學習這個介面測試自動化平臺的使用。

比較離譜的是，明明市面上有比較好的 JSONPath 定位方式，但平臺依然基於 JSONPath 定義了自己的一套語法，這意味著我需要學習它的語法，真的無語。明明看它生成的 Java 程式碼最後都是使用的 JSONPath。

使用者體驗不好

感覺就是平臺開發者並不清楚使用者 (測試人員) 實際的使用場景。當然，我們測試人員編寫測試點時，也經常考慮不到使用者那麼多複雜業務場景。

很多功能操作後的預設狀態，和心理預期不符。例如

• 點選『一鍵除錯』之後，編寫自動化用例的介面就被覆蓋了，需要點選『取消全屏』才能同時看到用例編寫介面和除錯執行頁面。既然是除錯，那我一般是對用例執行情況不確定才點的，我希望看到：是否有出錯？出錯在哪裡？能快速定位到指令碼位置。
• 除錯失敗時，JSON 文字過長被隱藏，需要下載壓縮包，找到對應檔名才能檢視完整的文字。太麻煩了，為什麼不直接給這個 JSON 檔案的下載連結呢？。出現問題 debug，還得下載壓縮包，解壓壓縮包，比對檔名，找到對應 JSON 檔案，太心累了。
• 除錯速度極其慢。因為是零程式碼，每次除錯都得將指令碼轉義成程式碼，並編譯。如果編譯報錯/執行出錯，就需要調整後再次執行。編譯的時間又很慢，不斷地編寫自動化指令碼、編譯除錯、修改指令碼、編譯除錯，浪費了大量的等待時間。Postman 可以斷點執行，執行不透過只需要修改後重新執行這一個介面就可以了。

只能用 Java 編寫指令碼

我用 Python 比較多，也熟悉一點 Java，但真不想寫 Java

平臺是 Java 實現的，因此『自定義程式碼』節點只能使用 Java 編寫，不支援其他語言。有很多資料準備/資料處理操作是必須要編寫『自定義程式碼』才能完成

1. Java 的語法就比較嚴格，對於不熟悉的人來說，容易忘掉末尾的 “;” 雙引號，每次新增變數都得進行型別定義。
2. 又或者使用到了 Java 中的一些資料結構，需要進行額外的學習才能編寫出可用的程式碼。
3. 最可惡的是，『自定義程式碼』中無法像編譯器中一樣，給出程式碼是否有問題的提醒。這意味著只能在執行時，才能報出編譯錯誤。這對於不熟悉 Java 語言的人來說，太容易發生了。

後記

團隊內的介面自動化效果很差。發現的 bug 少，都沒有起到最基礎的輔助的作用。更像是領導 PPT 上的一項 KPI，只論數量，不論質量。好在領導也清楚 UI 自動化更為雞肋，沒有讓我們推行。

正如前輩們所說，介面自動化更看重的是自動化用例的設計能力，而非平臺能力。平臺底層無非就是資料準備、響應斷言、資料提取、線上管理、報告生成，並不能當做護城河。業務千千萬，如何把業務高效落實到介面自動化上，才比較值得關注。

所以，不再迷信所謂的自動化平臺，Testhome 上也不建議大家分享輪子，使用者體驗都做不好的情況下，沒人用呀，還不如用 postman 方便。累計到 5000、6000 條用例時，維護真的麻煩。

我們的自動化用例更偏向於場景級，是多個介面之間組合呼叫，而不是單個介面的入參校驗。因此會寫用例會稍微麻煩一點。

在人力不足、缺少維護的情況下，自動化只能是領導們的 KPI。面試時也許還可以說道說道。