首先，咱們得把話說明白：Rentgen 不是來替代 Postman 的。假裝是競品，既不誠實，也沒意思。

如果你已經深度依賴Postman——寫腳本、搞斷言、維護給CI用的測試集，甚至凌晨一點還在調試測試運行器——那Rentgen跟你用的根本不是同一個賽道。Rentgen存在于這一切步驟之前。

一條cURL貼進去。幾百條測試跑起來。沒那么多花里胡哨的步驟。

API測試里，人人都在做、但沒人愿意明說的那部分

大多數開發者只把Postman當成一個API客戶端，而不是測試框架。他們導入一條cURL，發個請求，看一眼返回，然后就干別的去了。

沒有斷言。不考慮邊界情況。不做負面測試。這不是因為他們懶，而是因為第一步的“測試”就被不必要地搞得太重了。

結果就是，API就這么交付出去了，伴隨一句經典的臺詞：“我測過了，沒問題。” 測試人員每周都能聽到這句話。而且他們早就心知肚明，接下來會怎樣。

Rentgen是什么？

Rentgen是一個純本地的API “衛生”掃描器，就干一件事：在你浪費時間去打磨那種虛假的“完成感”之前，先給你的假設來個壓力測試。

你粘貼一條cURL，發送請求，然后點擊Generate & Run Tests（生成并運行測試），就這么簡單。

Rentgen會把一個簡單的請求，擴展成一堆雜亂但貼近現實的測試組合——這正是真實系統在生產環境中，當用戶（或其他集成系統）做出一些“人類迷惑行為”時，會收到的各種奇葩輸入。

Rentgen自動測什么？

不是什么“理想路徑走過場”。是真正的衛生檢查。就是那些無聊、可預測、但一旦爆發代價高昂的問題——人們總是跳過，直到生產環境崩了才后悔。

● 缺失的必填字段和意外的空值

● 錯誤的數據類型（比如該傳數字卻給了字符串，該是數組卻給了對象）

● 本應被干凈利落拒絕的邊界值

● 枚舉值的各種變體（大小寫不對、無效值、隨機亂碼）

● 字符串的截斷和空格問題（開頭/結尾的空格、空字符串）

● 格式錯誤的數據負載——這種本就不該讓后端崩潰的東西

● 那些乍一看“好像還行”，但細看狀態碼描述就發現不對的響應

沒有斷言？對，我們故意的

Rentgen不要求你寫斷言。這是有意為之。因為Rentgen的目標不是去證明你的API是正確的。它是要暴露當輸入不完美時，你的API會如何表現。

它的判斷模型簡單粗暴：

●2xx–3xx狀態碼= “行為可接受”

●4xx狀態碼= “你的API穩住了，正確處理了錯誤輸入”

●其他所有狀態碼= 值得你點進去看看的問題

你這不是在構建一個測試套件。你是在做一次現實檢查。

沒有繁瑣的測試集管理

你把請求分組，保存成集合。想運行的時候，點一下播放就行。

沒有復雜的測試運行器。沒有啟動儀式。不需要前后置腳本。沒有“等等，那個環境變量到底在哪兒定義的？”這種破事兒。直接運行集合，看哪些地方會崩。

不礙事兒的環境管理

Rentgen 支持環境變量，而且是以一種符合現實直覺的方式。不同環境用顏色區分，你一眼就知道自己在操作哪個。

Rentgen 支持環境，但不搞形式主義。

你可以把一次請求的返回值保存到環境變量里，一次設置，自動持久化。下次跑同一個集合時，Rentgen 知道怎么自動關聯這些數據——不需要寫腳本，不需要復制粘貼，不需要假裝這套流程很合理。

為什么這不算和 Postman 競爭？

Postman 擅長需要腳本的測試、復雜的工作流、詳細的斷言。如果你的工作就是這些——請繼續用，它很棒。

Rentgen 是針對那之前的時刻——當開發者想誠實地回答一個問題：“在把這 API 交給 QA 之前，我們有沒有漏掉什么顯而易見的蠢問題？”

先用 Rentgen 掃一遍。把那些低級問題修了。然后再讓測試人員去深度挖掘。這么一來，開發者顯得更靠譜。測試人員也無需在顯而易見的 Bug 上浪費時間。雙贏。

測試人員打造，開發者使用

Rentgen 不是為了追風口造的。沒有 AI 智能體。沒有云同步。不收集遙測數據。不需要注冊賬號。

它是由一個在 API 測試領域混跡足夠久、深知真相的人打造的：大多數 Bug 都來源于那些無聊的輸入錯誤，而每個人都覺得那些錯誤“不可能發生”。

如果你已經在用 Postman——很好，請繼續用。

只是在你說出“沒問題”之前，先用 Rentgen 跑一遍。

因為“沒問題”通常只意味著“我在理想路徑上試過一次”。而生產環境，根本不在乎你的理想路徑。

??轉崗軟件測試/野路子技能提升

??想了解更多漲薪技能提升方法

??可以到我的個人號：atstudy-js

即可加入領取 ??????

轉行、入門、提升、需要的各種干貨資料

內含AI測試、 車載測試、AI大模型開發、BI數據分析、銀行測試、游戲測試、AIGC