導讀
先從 TesterHome 上關于測驗平臺的話題談起，再來談談介面測驗的痛點是什么，然后是itest work介面測驗的解決方案，希望通過本篇的論述，大家對什么是好的平臺能達成統一的認識，且通過創新做出好用，對測驗人友好的平臺，
最近 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
轉載請註明出處，本文鏈接：https://www.uj5u.com/qita/288870.html
標籤：其他
上一篇：hdu1232 并查集總結
下一篇：Electron入門學習筆記