導讀

常態下,刀耕火種的 Test 環節給自動化的 Dev 與 Ops 踩下了剎車。Codes 以技術極其薄弱，極其不被重視的測試為發力點，通過落地敏捷測試打通了研發與運維中間的樞鈕潤滑環節。解決了 Test 在 DevOps 快速迭代中的木桶效應，促進了研發、測試、運維一體化融合進程。

 

上述也是 Codes 落地敏捷測試的初心，Codes 也有一個整套敏捷測試的方案的詳説記 Codes 開源研發項目管理平台——創新的敏捷測試解決方案，另外對的測試管理我們以創新的以迭代作為閉環，詳見 測試用例管理看這一篇就夠了 ----Codes 開源免費、全面的測試管理解決方案 ，本貼單獨就接口自動化測試展開來詳述 Codes 創新的低代碼接口自分自動化測試方案，讓大家明白我們創新的動機：Codes 產品團隊始終以用户為中心，從用户的使用場景來思考問題。解決用户痛點，如何讓用户爽，就如何實現，這也是我們創新的源動力，換句話説就是，不固守陳規，擁抱零基思維；對於接口測試，就是零代碼實現接口自動化測試，通過創新做出好用、對測試人友好的平台。

如何實現創新的零代碼實現接口自動化測試呢？還得從背景和 jmeter 、postman 痛點説起：

接口測試有多樣性

 

對測試人員來説 一般有這幾個主要問題

 

關於測試平台的討論很激烈。我本人是支持平台的，但是現在好多平台都是 KPI 導向，拿接口測試平台來説，除了少數做得不錯之外，看到好多不是 demo ，就是 jmeter ,postman 的 web 化，不否認做平台，對技術多少還是有提升 (大多數是 CRUD，僅僅是從 0 到 1)，但是如果平台沒人用，這平台就是失敗的。證明有一定的技術實力，除了開發平台，還有很多更高效的方式，比如為開源軟件提交 PR，熟讀開源中件間代碼，掌握測試前後移的技術 (TestOps)，為團隊開發實用測試小工具等。

隨着微服務架構理念，雲計算，容器技術的普及，DevOps 在 it 界漸成共識，併成為主流開發模式，在 DevOps 快速迭代中測試成為快速交付的一大短板。降本增效迫在眉睫。反過來，平台只要好用，就是好的平台，什麼是好的平台，一定是要能做到降本增效。

先從兩個主流工具的侷限性談起，postman 和 jmeter 是兩個比較主流的接口測試工具，當然 jmeter 用於壓測和接口自動化都可以。這兩個工具都解決了接口測試的基本問題，但仍然存在不少問題，Codes 產品團隊羅列了以下 9 點：

jmeter 、postman 侷限性

1. 可管理性不強

我認為這些工具在一定程度上就是個面向個人的 “單兵武器”， 基本上無可管理性。JMX，或是 JSON 文件，不好管理，協同就更是難上加難。市面上對他們 web 化的價值，也就是可管理這一點，更深層次的痛點並沒有觸達。

2. 對測試人員不足夠 “友好”

用過 QTP，LR 之類的對測試人員都知道，傻瓜化，不懂代碼，一樣用得很開心，這對大多數不會寫代碼的測試人員來説，確實是 “福報”，斷言，參數化，數據驅動都非常簡單，然而這些工具都是商業化且使用場景相對固定，並無法快速響應互聯網不斷變化的測試需求。反觀 postman 或者 jmeter，雖然免費了但是又有不少功能需要你二次開發，所以説沒有” 普適性”。對於一些代碼基礎薄弱的同學來説，遇到定製化的需求往往束手無策。檢驗” 普適性” 的標準，就是是否傻瓜化，這決定了門檻的高低；高級使用人員，可以二開及使用一些高級特性。傻瓜化不是提倡，測試人員不會代碼就是好事，平台想要推廣得好，普適性很重要，打個不太恰當的比方，就算會寫代碼，也沒多少人用 VI 或是記事本寫，都要用 IDE 工具，為什麼？效率高呀。會寫代碼，可以做很多實用的測試小工具，還是非常棒的!

3. 對接口反向用例或混沌測試支持不夠

雖然很多平台支持數據驅動測試，但是對接口反向用例或混沌測試支持不夠。先從一下真實生產事故講起，朋友公司因第三方接口導致了服務器宕機，最後查到的原因是，掃碼，傳入的數據是一個比較長的亂七八糟的字符串，沒按要求傳正確的值，結果服務器，死循環掛掉了。接口測試時，無法窮舉所有參數值。在 postman 和 jmeter 中都有數據驅動，但是我認為採用枚舉的方式來設置參數值，然後通過數據驅動的方式來執行測試，對人的依賴太大。後面我再講接口混沌測試，瞬間可以完成笛卡爾積式的接口混沌測試，從另一個視角來實現，且和接口數據結構無關。

4. 理不清接口間的調用關係

縱使寫了很多接口用例，但是對接口間的關係依然是” 抓瞎”。很多時候我們藉助於調用鏈跟系統，但是對於平台上的接口用例，調用鏈這張網又太大，和接口用例也不完全匹配，就算匹配，且調用鏈跟蹤突出的是，調用上的時間順序，並不突出他們之間的依賴關係，以及是什麼樣的依賴關；也不是所有系統都用上了調用鏈路跟蹤，大多不是微服務架構的項目，這塊想用調用鏈跟系統 (如 SkyWalking Zipkin、Pinpoint 等) 還是不好辦的。接口用例間，實際上就存在依賴關係，如 A 接口，要依賴取 token 接口，同時 A 還依賴 B 接口的響應數據中提取的參數等等，這在 postman ,jmeter 中，雖然接口依賴關係事實上存在，但只能人工去理，沒有一目瞭然的可視化界面來展示依賴關係，當一個接口改動了，也不方便評估，對其他接口的影響；且通過直觀的依賴關係，可促使挖掘更多的測試場景。且有了依賴關係，執行接口用例時 自動先執行被依賴的接口用例，對執行人員來説，不需要知道要先執行哪個接口用例。
在 postman 中 因為沒有接口依賴關係，只能在集合中手動去維護接口的執行先後順序，如果有循環依賴，時間久了鬼記得住 ！這太強調肌肉記憶了。

5. 低代碼模式對測試能效提出更高的要求

研發都低代碼了，接口測試卻還沒有低代碼，變相抬高了接口測試門檻，當然這個對於測試來説要求也比較高，事實上這也不利於提效。肯定有人要反對了，測開就是要寫代碼呀，能寫代碼這很好呀，明確的説，這是五年前流行的觀點了，我們要的不是代碼的堆砌，而是高質量的有效代碼；測開會寫代碼，做出來的產品和解決能效之間並不是等號！脱離方法論，脱離工程文化等能加快交付途徑的方方面面，只是 “秀代碼”,沒多大價值。既然要做平台，出發點肯定是團隊提效，而不是單兵作戰；另外從公司團隊組建的角度來説，也不可能全是測開，平台化如果不考慮業務測試的融入，不考慮對非測開人員的 “普適性”，就沒法解決木桶效應的問題，我認為這個平台是失敗的，不管如何分工，團隊的整體能效沒上去，這平台就是測開自嗨的平台。現在開發都在提低代碼了，開發效率會大大提升，測試的壓力更大，測試也要低代碼化，才能也一起提效，否則測試這塊的短板更短，下面我也會再講講對於測試低代碼化的一些思考。

現在大家對低代碼的討論非常多，看低的也大有人在，我這裏就不展開説了，但有一點我認為低代碼會成為趨勢，無服務對低代碼更是推波助瀾。目前比較火的低代碼平台，比較有名的都是國外的，微軟也有低代碼平台。拿我我們公司的低代碼平台來説，剛畢業的新人，入職三天，就能實現業務開發了，效率還是槓槓的！且通過註解，單元測試不需要寫一行代碼了，加少量的註解就可以了，比手寫 junit 測試類，省至少 2 倍的時間 。

6. 接口測試場景，沒有接口測試執行時的的調用鏈跟蹤

執行接口測試場景時,要是中間出錯，排錯不方便，手動一個一個去跟，要是場景中接口多，有點 “暈”。還有某些接口中提取參數，在接口的執行日誌中，沒有詳細的的看到提取表達式，以及表達式在執行時，提取到的值是什麼。

7. 內置函數太少，對於點工不太友好

如常用的加解密，一些系統函數，一些運算等，當然可以寫插件等，但這對點工來説，非常不友好，內置多，拿來就用還是爽。

上面是我個人認為的接口測試中最痛的點，我看到的接口測試平台，不解決這些剛需，只是通過 web 封裝工具的話意義不大。從老闆的角度來説，沒增效，投人力做這事就不值，大家都知道提問題簡單，難在解決問題，下面我來説我的解決方案是什麼？

8. 接口業務場景編排不友好

需要太多的硬編碼，或是業務流轉沒有直觀以圖形來顯示

9. 壓測沒法重用接口測試的用例

壓測時還要增加不少工作量，實際上接口測試用例上跑量不就是壓測嗎！

10. 自動化測試和 CI CD 聯動麻煩

測試人員實現聯動相對來説不是那麼容易，不管是搭建相關環境 還是流水線編排，有點技術成本，換句話説對測試不是好麼友好。

Codes 創新解決方案

也是從述提出問題到給解決方案思路方式來談

 

下面就具體來談談 Codes 的一站式敏捷測試管理平台，如何解決上述 9 個痛點。

 

1 關於管理協作，只要是平台化，天然就解決這問題。

2 對測試人員友好，主要是可用性，可維護性。

postman 和 jmeter 雖然受到普遍的歡迎，但從自動化角度來説存在一些硬傷，我舉兩個設計上的具體例子:

(1) postman 前後置腳本及簽名等和接口用例耦合在一起，不方便維護,比如我需要對請求籤名，如果簽名算法改了，我得來改接口 用例，如果有 100 個接口，這改起來太可怕了，要是解偶，只要改簽名算法本身，其他接口中是選擇引用這個算法，就不存在這種痛苦；

(2) 參數維護不面向對像且不能自動轉換 , 如參數得複雜 json 只能寫 json ，通常大家對錶單比較熟悉, 批量維護 KV 自動轉 JSON ，如是複雜對像，支持 dto.user.id 這種複雜 kye 轉 josn 就爽得多，完全是向面對像的式在維護參數；

直接上圖，看 Codes 是怎麼解決的？

下圖就是插件化解耦，維護好相關插件，在接口用例中，只是下拉選而已。

插件列表

 

 

 

參數維護方便很多,個人非常不喜歡 json schema 的方式，KV 可方便轉複雜 JSON ，又可直接寫複雜 JSON，這才是照顧使用人的效率和提升便利，XXX.XXX.XXX 這種才是以面向前對像的思維維護參數，且更切近表單屬性。

 

3 對接口反向用例或混沌測試支持不夠。

一説反向測試大家第一反應是，通過數據驅動來測試，如果複雜 JSON 數據結構，數據驅動按傳統的方式，對測試人員來説一點不方便，這兩個我們都是這樣來解決的接口反向或是混沌測試，只需要配置好混沌規則 ，然後以 “撞庫” 的形式排列組合，替換掉正向接口用例中的參數值去執行撞庫，瞬間完成接口健壯性測試 “撞庫時” 先單個一個一個去換， 然後再排例組合。

 

看下混沌工程的執行結果：

 

數據驅動，也是按面向對像的方式，方便複雜 JOSN 的結構，傳統的數據驅動，只方便 KV 方式，複雜對像，表達起來費勁，我們依然採用 xxx.xx.xx 這種對像屬性訪問形式。依然採用 xxx.xx.xxx 這種對像屬性訪問形式，即支持簡單 KV ，又能一行表示一個 json 對像，直觀又易於理解

 

4 .對接口間的關係理不清

前面的論述，就不重複了，接口間只要存在參數引用，就必須存在依賴關係，完全可以根據依賴關係推導出來，在接口測試場景中，只要選擇了一些用例，自動加入依賴的接口用例，並排好執行順序。同時還能自動檢查循環依賴。

不但可以查看依賴拓補，還可以在維護接口用例時，自動檢查循環依賴，如檢測到，給出提示

 

這是用户的一個真實接口依賴關係，Codes 自動推導出來的

 

自動循環依賴，如下圖給出了具體的循環依賴信息（偷個懶用的 Codes 前身 itest 的截圖）

 

 

5. 研發都低代碼了，接口測試卻還沒有低代碼

這其實變相抬高了接口測試門檻，同時也不利於提效。這塊的爭議最多，不再累述。可能測試人員，平時寫代碼少，低代碼會使一些人覺得剝奪他們寫代碼的權利；也有人説低代碼，容易讓大家變成工具的奴隸，低代碼只是為了提效，把重複工作工具化，並不禁錮使用人員的思想，從公司的角度來説，老闆希望你把時間花在，重要的事情上， 重複的事情，工具化，平台化。

比如初級一點的，可以在斷言以及提取參數時，通過拖拽的方式，高級玩法就是 bpm 那樣的編排，就像工作流一樣，拖拉的方式來編排，通過編排實現接口業務場景的測試。另外，還可以重用接口用例，把他轉化為 JMX 文件，這樣一個用例或是場景，接口測試可用，壓測也重用接口用例，以一當二用。

 

 

6 接口測試場景，沒有接口測試執行時的的調用鏈跟蹤

直接上圖，場景執行完，要是有問題，通過執行的執行鏈跟蹤，也就是通常的調用鏈跟蹤,便於排錯，如出錯，還可從調用鏈上從出錯的節點一下,手動觸發接着執行，且是在同一數據上下文，在調用連上點接口名，可查看，該接口在執行時具體的出入參等信息

 

下圖為，提取參數，給其他接口使用，在接口日誌中詳細記錄了提取表達式及提取值

 

 

7 內置了常用的 45 個函數

 

 

 

 

 

8. 可視化拖拽接口業務場景編排

拖拽方式維護接口業務場景，

拖拽方式維護接口業務場景，用一個示例來説明
先看效果圖

 

接口場景編排加接口混沌測試可以一步到位 ,真是爽得不要不要的，真擔心繫統會不會一搞就掛了，按 Codes 給的 DEMO POC 下來幾分鐘完事，不信你看看 POC 過程。

step1：定義好接口場景中的每個接口

聽説是可以進行錄製可惜小 T 還不會用，先手動增加登錄接口以及 POC 的場景中其它相關接口。

 

step2：設置登錄接口斷言

小 T 覺得拖拽式的方式設置斷言蠻爽的，當然高級玩家們也可以自己編碼實現哦。

 

step3：編排業務場景

拖拽式編排接口為業務場景，説實在的不要太爽啦！（小 T 已暈）

 

step4：設置業務場景流轉條件

真的就像是工作流一樣，雙擊接口間的連線可以設置流轉條件，會把前一個接口的響應結果解析為一個樹狀結構，拖動樹狀結構上的節點，如下圖所示：

 

step5：設置好所有流轉邏輯

 

step6：下面是最哇塞的功能，自動化推導接口間依賴拓撲

 

step7：配置混沌規則並在場景中應用

Codes 可以配置任意多的混沌規則，小 T 假定場景中某個接口的參數為 M，配置了 N 個混沌規則，執行場景中每個接口的次數 M+C ab * P aa （M 和 N 哪個大哪個是 a 另一個是 B），假定場景中有 X 個接口那麼總執行次數就是希格碼 M+C ab * P aa

 

 

step8：運行場景查看調用鏈

 

step9：查看調用情況及混沌日誌

查看某次正常執行情況。

 

（還好系統在這裏居然沒掛，30 多秒裏運行了 1800 多次）

 

9 壓測直接重用接口測試的用例

點點完成分佈式節點管理，讓分佈式壓測環境分分鐘準備好; 幾步設置好壓測場景和壓測參數，分分鐘跑完壓測試場景；
重用接口用例為壓測場景複用，不再從零起步,助您彈射"起飛"。
把接口用例轉為 jmeter JMX 文件，可然可視化的方式配置 jmeter 集羣

 

節點管理

 

 

 

寫到這裏也幾千字了,這只是我個人之言，不對之處歡迎大家討論拍磚，看 TesterHome 上關於平台的討論，很是激烈；我在這裏拋磚引玉，只要是有益的討論，對行業也是有利，如果能讓大家靜下心來，一起來探討什麼是好的接口測試平台，也是好事。少卷一些，少一些 KPI，做真正好用的對測試人友好的測試平台還是很香的。

好些人做平台是為了面試時加分，或是多些談資，這太急功近利了；我看過好多隻是個 demo 的平台，在這裏我就不一一列舉代碼地址了，多數是為了加羣吸粉，這留得住人嗎！！我表示嗤之以鼻！一個好的面試官用一個爛平台也忽悠不了他，有能力，不管是編碼能力，還是綜合能力強，有很多方方面面來體現，這裏就不展開説了。

10. Codes 0 代碼自動化測試與 CI CD 聯動

零代碼拖拽式 CI CD 流水線編排,
“潤物細無聲” 的方式實現代碼掃描，代碼管理與質量流程無縫對接，不增加測試人員認知負荷。
“輕” 運維，幫助測試人員零基礎右移，打通測試與運維的屏障，提升測試效率。

 

詳見 記 Codes 研發項目管理平台——拖拽式無代碼 CICD 創新實現

展望

接口自動化測試，後期主要在於測試數據的維護，我們正在實現接口數據集管理功能，實現接口用例和接口數據的分離。每個接口或接口場景 可以配置上用的數據集，數據集裏的每個數據項，都有一個數據產生器，數據產生器可以用我們官方的，也可以自行用插件實現，不但接口用例和接口數據分離，且數據項和其數據產後器也是分熟的 ，可按需配置。

這貼子肯定少不了爭議，以上就是 Codes 接口自動化測試的底層設計邏輯。
Codes 官網, 讓測試變得簡單、敏捷！是 Codes 的執念。