測試架構師如何解讀測試平台的各種爭議

• 2021 年 7 月 2 日
• 筆記
• BUG跟蹤管理, itest 敏捷測試管理, 開源介面測試

導讀

      先從 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