導讀
先從 TesterHome 上關於測試平臺的話題談起，再來談談介面測試的痛點是什麼，然後是我的介面測試的解決方案。希望通過本篇的論述，大家對什麼是好的平臺能達成統一的認識，且通過創新做出好用，對測試人友好的平臺。
最近 TesterHome 上，關於測試平臺的討論很激烈。我本人是支援平臺的，但是現在好多平臺都是 KPI 導向，拿介面測試平臺來說，除了少數做得不錯之外，看到好多不是 demo ，就是 jmeter ,postman 的 web 化，不否認做平臺，對技術多少還是有提升(大多數是 CRUD，僅僅是從 0 到 1)，但是如果平臺沒人用，這平臺就是失敗的。證明有一定的技術實力，除了開發平臺，還有很多更高效的方式，比如為開源軟體提交 PR，熟讀開源中件間程式碼，掌握測試前後移的技術，為團隊開發實用測試小工具等。
隨著微服務架構理念，雲端計算，容器技術的普及，DevOps 在 it 界漸成共識，併成為主流開發模式，在 DevOps 快速迭代中測試成為快速交付的一大短板。降本增效迫在眉睫。反過來，平臺只要好用，就是好的平臺，什麼是好的平臺，一定是要能做到降本增效。
先從兩個主流工具的侷限性談起，postman 和 jmeter 是兩個比較主流的介面測試工具，當然 jmeter 用於壓測和介面自動化都可以。這兩個工具都解決了介面測試的基本問題，但仍然存在不少問題，我羅列了以下五點：
1. 可管理性不強
我認為這些工具在一定程度上就是個面向個人的“單兵武器”， 基本上無可管理性。JMX，或是 JSON 檔案，不好管理，協同就更是難上加難。市面上對他們 web 化的價值，也就是可管理這一點，更深層次的痛點並沒有觸達。
2. 對測試人員不足夠“友好”
用過 QTP，LR 之類的對測試人員都知道，傻瓜化，不懂程式碼，一樣用得很開心，這對大多數不會寫程式碼的測試人員來說，確實是“福報”，斷言，引數化，資料驅動都非常簡單，然而這些工具都是商業化且使用場景相對固定，並無法快速響應網際網路不斷變化的測試需求。反觀 postman 或者 jmeter，雖然免費了但是又有不少功能需要你二次開發，所以說沒有”普適性”。對於一些程式碼基礎薄弱的同學來說，遇到定製化的需求往往束手無策。檢驗”普適性”的標準，就是是否傻瓜化，這決定了門檻的高低；高階使用人員，可以二開及使用一些高階特性。傻瓜化不是提倡，測試人員不會程式碼就是好事，平臺想要推廣得好，普適性很重要，打個不太恰當的比方，就算會寫程式碼，也沒多少人用 VI 或是記事本寫，都要用 IDE 工具，為什麼？效率高呀。會寫程式碼，可以做很多實用的測試小工具，還是非常棒的!
3. 對介面反向用例或混沌測試支援不夠
雖然很多平臺支援資料驅動測試，但是對介面反向用例或混沌測試支援不夠。先從一下真實生產事故講起，朋友公司因第三方介面導致了伺服器當機，最後查到的原因是，掃碼，傳入的資料是一個比較長的亂七八糟的字串，沒按要求傳正確的值，結果伺服器，死迴圈掛掉了。介面測試時，無法窮舉所有引數值。在 postman 和 jmeter 中都有資料驅動，但是我認為採用列舉的方式來設定引數值，然後通過資料驅動的方式來執行測試，對人的依賴太大。後面我再講介面混沌測試，瞬間可以完成笛卡爾積式的介面混沌測試，從另一個視角來實現，且和介面資料結構無關。
4. 理不清介面間的呼叫關係
縱使寫了很多介面用例，但是對介面間的關係依然是”抓瞎”。很多時候我們藉助於呼叫鏈跟系統，但是對於平臺上的介面用例，呼叫鏈這張網又太大，和介面用例也不完全匹配，就算匹配，且呼叫鏈跟蹤突出的是，呼叫上的時間順序，並不突出他們之間的依賴關係，以及是什麼樣的依賴關；也不是所有系統都用上了呼叫鏈路跟蹤，大多不是微服務架構的專案，這塊想用呼叫鏈跟系統(如 SkyWalking Zipkin、Pinpoint 等)還是不好辦的。介面用例間，實際上就存在依賴關係，如 A 介面，要依賴取 token 介面，同時 A 還依賴 B 介面的響應資料中提取的引數等等，這在 postman ,jmeter 中，雖然介面依賴關係事實上存在，但只能人工去理，沒有一目瞭然的視覺化介面來展示依賴關係，當一個介面改動了，也不方便評估，對其他介面的影響；且通過直觀的依賴關係，可促使挖掘更多的測試場景。
5. 低程式碼模式對測試能效提出更高的要求
研發都低程式碼了，介面測試卻還沒有低程式碼，變相抬高了介面測試門檻，當然這個對於測試來說要求也比較高，事實上這也不利於提效。肯定有人要反對了，測開就是要寫程式碼呀，能寫程式碼這很好呀，明確的說，這是五年前流行的觀點了，我們要的不是程式碼的堆砌，而是高質量的有效程式碼；測開會寫程式碼，做出來的產品和解決能效之間並不是等號！脫離方法論，脫離工程文化等能加快交付途徑的方方面面，只是“秀程式碼”,沒多大價值。既然要做平臺，出發點肯定是團隊提效，而不是單兵作戰；另外從公司團隊組建的角度來說，也不可能全是測開，平臺化如果不考慮業務測試的融入，不考慮對非測開人員的“普適性”，就沒法解決木桶效應的問題，我認為這個平臺是失敗的，不管如何分工，團隊的整體能效沒上去，這平臺就是測開自嗨的平臺。現在開發都在提低程式碼了，開發效率會大大提升，測試的壓力更大，測試也要低程式碼化，才能也一起提效，否則測試這塊的短板更短，下面我也會再講講對於測試低程式碼化的一些思考。
現在大家對低程式碼的討論非常多，看低的也大有人在，我這裡就不展開說了，但有一點我認為低程式碼會成為趨勢，無服務對低程式碼更是推波助瀾。目前比較火的低程式碼平臺，比較有名的都是國外的，微軟也有低程式碼平臺。拿我我們公司的低程式碼平臺來說，剛畢業的新人，入職三天，就能實現業務開發了，效率還是槓槓的！且通過註解，單元測試不需要寫一行程式碼了，加少量的註解就可以了，比手寫 junit 測試類，省至少 2 倍的時間 。
上面是我個人認為的介面測試中最痛的點，我看到的介面測試平臺，不解決這些剛需，只是通過 web 封裝工具的話意義不大。從老闆的角度來說，沒增效，投人力做這事就不值，大家都知道提問題簡單，難在解決問題，下面我來說我的解決方案是什麼？
解決方案
下面就來談談我設計的一站式敏捷測試管理平臺，針對我羅列的五個痛點是如何解決的。
1 關於管理協作，只要是平臺化，天然就解決這問題。
2 對測試人員友好，主要是可用性，可維護性。
postman 和 jmeter 雖然受到普遍的歡迎，但從自動化角度來說存在一些硬傷，我舉兩個設計上的具體例子:
(1) postman 前後置指令碼及簽名等和介面用例耦合在一起，不方便維護,比如我需要對請求籤名，如果簽名演算法改了，我得來改介面 用例，如果有 100 個介面，這改起來太可怕了，要是解偶，只要改簽名演算法本身，其他介面中是選擇引用這個演算法，就不存在這種痛苦；
(2)引數維護不面向對像且不能自動轉換 , 如引數得複雜 json 只能寫 json ，通常大家對錶單比較熟悉, 批量維護 KV 自動轉 JSON ，如是複雜對像，支援 dto.user.id 這種複雜 kye 轉 josn 就爽得多，完全是向面對像的式在維護引數；
直接上圖我是怎麼解決的？
下圖就是外掛化解耦，維護好相關外掛，在介面用例中，只是下拉選而已。
引數維護方便很多,個人非常不喜歡 json schema 的方式，KV 可方便轉複雜 JSON ，又可下接寫複雜 JSON，這才是照顧使用人的效率和提升便利，XXX.XXX.XXX 這種才是以面向前對像的思維維護引數，且更切近表單屬性。
3 對介面反向用例或混沌測試支援不夠。
一說反向測試大家第一反應是，通過資料驅動來測試，如果複雜 JSON 資料結構，資料驅動按傳統的方式，對測試人員來說一點不方便，這兩個我們都是這樣來解決的介面反向或是混沌測試，只需要配置好混沌規則 ，然後以“撞庫”的形式排列組合，替換掉正向介面用例中的引數值去執行撞庫，瞬間完成介面健壯性測試“撞庫時”先單個一個一個去換， 然後再排例組合。
看下混沌工程的執行結果：
資料驅動，也是按面向對像的方式，方便複雜 JOSN 的結構，傳統的資料驅動，只方便 KV 方式，複雜對像，表達起來費勁，我們依然採用 xxx.xx.xx 這種對像屬性訪問形式。依然採用 xxx.xx.xxx 這種對像屬性訪問形式，即支援簡單 KV ，又能一行表示一個 json 對像，直觀又易於理解
4 對介面間的關係理不清
前面的論述，就不重複了，介面間只要存在引數引用，就必須存在依賴關係，完全可以根據依賴關係推匯出來，在介面測試場景中，只要選擇了一些用例，自動加入依賴的介面用例，並排好執行順序。同時還能自動檢查迴圈依賴。
不但可以檢視依賴拓補，還可以在維護介面用例時，自動檢查迴圈依賴，如檢測到，給出提示
自動迴圈依賴，如下圖給出了具體的迴圈依賴資訊
5 研發都低程式碼了，介面測試卻還沒有低程式碼
這其實變相抬高了介面測試門檻，同時也不利於提效。這塊的爭議最多，不再累述。可能測試人員，平時寫程式碼少，低程式碼會使一些人覺得剝奪他們寫程式碼的權利；也有人說低程式碼，容易讓大家變成工具的奴隸，低程式碼只是為了提效，把重複工作工具化，並不禁錮使用人員的思想，從公司的角度來說，老闆希望你把時間花在，重要的事情上， 重複的事情，工具化，平臺化。
比如初級一點的，可以在斷言以及提取引數時，通過拖拽的方式，高階玩法就是 bpm 那樣的編排，就像工作流一樣，拖拉的方式來編排，通過編排實現介面業務場景的測試。另外，還可以重用介面用例，把他轉化為 JMX 檔案，這樣一個用例或是場景，介面測試可用，壓測也重用介面用例，以一當二用。
寫到這裡也幾千字了,這只是我個人之言，不對之處歡迎大家討論拍磚，看 TesterHome 上關於平臺的討論，很是激烈；我在這裡拋磚引玉，只要是有益的討論，對行業也是有利，如果能讓大家靜下心來，一起來探討什麼是好的介面測試平臺，也是好事。少卷一些，少一些 KPI，做真正好用的對測試人友好的測試平臺還是很香的。
好些人做平臺是為了面試時加分，或是多些談資，這太急功近利了；我看過好多隻是個 demo 的平臺，在這裡我就不一一列舉程式碼地址了，多數是為了加群吸粉，這留得住人嗎！！我表示嗤之以鼻！一個好的面試官用一個爛平臺也忽悠不了他，有能力，不管是編碼能力，還是綜合能力強，有很多方方面面來體現，這裡就不展開說了。
這貼子肯定少不了爭議，歡迎大家加入 TesterHome 反智討論群，我也在群裡方便大家來討論，本人是開源免費的 www.itest.work ,一站式敏捷測試管理平臺作者, 讓測試變得簡單、敏捷！是 itestwork 的執念。寫這貼子，也是有感而發，我們一直在改進的路上，3 年了一直在維護中，上面的痛點，必須要全面解決；當前正在豐富壓測模組及實現視覺化介面編排 大家可以期待。
官網訪問地址：www.itest.work