本篇文章，首發(fā)于軟件測(cè)試架構(gòu)師俱樂部公號(hào)。iTest框架作者。他對(duì)測(cè)試框架的認(rèn)知非常透徹，下面一起來看下他的真知灼見。

最近關(guān)于測(cè)試平臺(tái)的討論很激烈。我本人是支持平臺(tái)的，但是現(xiàn)在好多平臺(tái)都是KPI導(dǎo)向，拿接口測(cè)試平臺(tái)來說，除了少數(shù)做得不錯(cuò)之外，看到好多不是demo ，就是jmeter ,postman的web 化，不否認(rèn)做平臺(tái)，對(duì)技術(shù)多少還是有提升(大多數(shù)是CRUD，僅僅是從0到1)，但是如果平臺(tái)沒人用，這平臺(tái)就是失敗的。證明有一定的技術(shù)實(shí)力，除了開發(fā)平臺(tái)，還有很多更高效的方式，比如為開源軟件提交PR，熟讀開源中件間代碼，掌握測(cè)試前后移的技術(shù)，為團(tuán)隊(duì)開發(fā)實(shí)用測(cè)試小工具等。

痛點(diǎn)

隨著微服務(wù)架構(gòu)理念，云計(jì)算，容器技術(shù)的普及，DevOps在it界漸成共識(shí)，并成為主流開發(fā)模式，在DevOps快速迭代中測(cè)試成為快速交付的一大短板。降本增效迫在眉睫。反過來，平臺(tái)只要好用，就是好的平臺(tái)，什么是好的平臺(tái)，一定是要能做到降本增效。

先從兩個(gè)主流工具的局限性談起，postman 和jmeter 是兩個(gè)比較主流的接口測(cè)試工具，當(dāng)然jmeter 用于壓測(cè)和接口自動(dòng)化都可以。這兩個(gè)工具都解決了接口測(cè)試的基本問題，但仍然存在不少問題，我羅列了以下五點(diǎn)：

  1.可管理性不強(qiáng)

我認(rèn)為這些工具在一定程度上就是個(gè)面向個(gè)人的“單兵武器”， 基本上無可管理性。JMX，或是JSON文件，不好管理，協(xié)同就更是難上加難。市面上對(duì)他們web化的價(jià)值，也就是可管理這一點(diǎn)，更深層次的痛點(diǎn)并沒有觸達(dá)。

 2.對(duì)測(cè)試人員不足夠“友好”

用過QTP，LR之類的對(duì)測(cè)試人員都知道，傻瓜化，不懂代碼，一樣用得很開心，這對(duì)大多數(shù)不會(huì)寫代碼的測(cè)試人員來說，確實(shí)是“福報(bào)”，斷言，參數(shù)化，數(shù)據(jù)驅(qū)動(dòng)都非常簡(jiǎn)單，然而這些工具都是商業(yè)化且使用場(chǎng)景相對(duì)固定，并無法快速響應(yīng)互聯(lián)網(wǎng)不斷變化的測(cè)試需求。反觀postman或者jmeter，雖然免費(fèi)了但是又有不少功能需要你二次開發(fā)，所以說沒有”普適性”。對(duì)于一些代碼基礎(chǔ)薄弱的同學(xué)來說，遇到定制化的需求往往束手無策。檢驗(yàn)”普適性”的標(biāo)準(zhǔn)，就是是否傻瓜化，這決定了門檻的高低；高級(jí)使用人員，可以二開及使用一些高級(jí)特性。傻瓜化不是提倡，測(cè)試人員不會(huì)代碼就是好事，平臺(tái)想要推廣得好，普適性很重要，打個(gè)不太恰當(dāng)?shù)谋确?，就算?huì)寫代碼，也沒多少人用VI 或是記事本寫，都要用IDE工具，為什么？效率高呀。會(huì)寫代碼，可以做很多實(shí)用的測(cè)試小工具，還是非常棒的!

3.對(duì)接口反向用例或混沌測(cè)試支持不夠

雖然很多平臺(tái)支持?jǐn)?shù)據(jù)驅(qū)動(dòng)測(cè)試，但是對(duì)接口反向用例或混沌測(cè)試支持不夠。先從一下真實(shí)生產(chǎn)事故講起，朋友公司因第三方接口導(dǎo)致了服務(wù)器宕機(jī)，最后查到的原因是，掃碼，傳入的數(shù)據(jù)是一個(gè)比較長(zhǎng)的亂七八糟的字符串，沒按要求傳正確的值，結(jié)果服務(wù)器，死循環(huán)掛掉了。接口測(cè)試時(shí)，無法窮舉所有參數(shù)值。在postman 和jmeter中都有數(shù)據(jù)驅(qū)動(dòng)，但是我認(rèn)為采用枚舉的方式來設(shè)置參數(shù)值，然后通過數(shù)據(jù)驅(qū)動(dòng)的方式來執(zhí)行測(cè)試，對(duì)人的依賴太大。后面我再講接口混沌測(cè)試，瞬間可以完成笛卡爾積式的接口混沌測(cè)試，從另一個(gè)視角來實(shí)現(xiàn)，且和接口數(shù)據(jù)結(jié)構(gòu)無關(guān)。

4.理不清接口間的調(diào)用關(guān)系

縱使寫了很多接口用例，但是對(duì)接口間的關(guān)系依然是”抓瞎”。很多時(shí)候我們借助于調(diào)用鏈跟系統(tǒng)，但是對(duì)于平臺(tái)上的接口用例，調(diào)用鏈這張網(wǎng)又太大，和接口用例也不完全匹配，就算匹配，且調(diào)用鏈跟蹤突出的是，調(diào)用上的時(shí)間順序，并不突出他們之間的依賴關(guān)系，以及是什么樣的依賴關(guān)；也不是所有系統(tǒng)都用上了調(diào)用鏈路跟蹤，大多不是微服務(wù)架構(gòu)的項(xiàng)目，這塊想用調(diào)用鏈跟系統(tǒng)(如 SkyWalking  Zipkin、Pinpoint等)還是不好辦的。接口用例間，實(shí)際上就存在依賴關(guān)系，如A接口，要依賴取token 接口，同時(shí)A還依賴B接口的響應(yīng)數(shù)據(jù)中提取的參數(shù)等等，這在postman ,jmeter 中，雖然接口依賴關(guān)系事實(shí)上存在，但只能人工去理，沒有一目了然的可視化界面來展示依賴關(guān)系，當(dāng)一個(gè)接口改動(dòng)了，也不方便評(píng)估，對(duì)其他接口的影響；且通過直觀的依賴關(guān)系，可促使挖掘更多的測(cè)試場(chǎng)景。

5.低代碼模式對(duì)測(cè)試能效提出更高的要求

研發(fā)都低代碼了，接口測(cè)試卻還沒有低代碼，變相抬高了接口測(cè)試門檻，當(dāng)然這個(gè)對(duì)于測(cè)試來說要求也比較高，事實(shí)上這也不利于提效。肯定有人要反對(duì)了，測(cè)開就是要寫代碼呀，能寫代碼這很好呀，明確的說，這是五年前流行的觀點(diǎn)了，我們要的不是代碼的堆砌，而是高質(zhì)量的有效代碼；測(cè)開會(huì)寫代碼，做出來的產(chǎn)品和解決能效之間并不是等號(hào)！脫離方法論，脫離工程文化等能加快交付途徑的方方面面，只是“秀代碼”,沒多大價(jià)值。既然要做平臺(tái)，出發(fā)點(diǎn)肯定是團(tuán)隊(duì)提效，而不是單兵作戰(zhàn)；另外從公司團(tuán)隊(duì)組建的角度來說，也不可能全是測(cè)開，平臺(tái)化如果不考慮業(yè)務(wù)測(cè)試的融入，不考慮對(duì)非測(cè)開人員的“普適性”，就沒法解決木桶效應(yīng)的問題，我認(rèn)為這個(gè)平臺(tái)是失敗的，不管如何分工，團(tuán)隊(duì)的整體能效沒上去，這平臺(tái)就是測(cè)開自嗨的平臺(tái)?，F(xiàn)在開發(fā)都在提低代碼了，開發(fā)效率會(huì)大大提升，測(cè)試的壓力更大，測(cè)試也要低代碼化，才能也一起提效，否則測(cè)試這塊的短板更短，下面我也會(huì)再講講對(duì)于測(cè)試低代碼化的一些思考。

現(xiàn)在大家對(duì)低代碼的討論非常多，看低的也大有人在，我這里就不展開說了，但有一點(diǎn)我認(rèn)為低代碼會(huì)成為趨勢(shì)，無服務(wù)對(duì)低代碼更是推波助瀾。目前比較火的低代碼平臺(tái)，比較有名的都是國外的，微軟也有低代碼平臺(tái)。拿我我們公司的低代碼平臺(tái)來說，剛畢業(yè)的新人，入職三天，就能實(shí)現(xiàn)業(yè)務(wù)開發(fā)了，效率還是杠杠的！且通過注解，單元測(cè)試不需要寫一行代碼了，加少量的注解就可以了，比手寫junit 測(cè)試類，省至少2倍的時(shí)間 。

上面是我個(gè)人認(rèn)為的接口測(cè)試中最痛的點(diǎn)，我看到的接口測(cè)試平臺(tái)，不解決這些剛需，只是通過web封裝工具的話意義不大。從老板的角度來說，沒增效，投人力做這事就不值，大家都知道提問題簡(jiǎn)單，難在解決問題，下面我來說我的解決方案是什么？

解決方案

下面就來談?wù)勎以O(shè)計(jì)的一站式敏捷測(cè)試管理平臺(tái)，針對(duì)我羅列的五個(gè)痛點(diǎn)是如何解決的。

關(guān)于管理協(xié)作，只要是平臺(tái)化，天然就解決這問題。

對(duì)測(cè)試人員友好，主要是可用性，可維護(hù)性。

postman 和jmeter 雖然受到普遍的歡迎，但從自動(dòng)化角度來說存在一些硬傷，我舉兩個(gè)設(shè)計(jì)上的具體例子；

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

• 參數(shù)維護(hù)不面向?qū)ο袂也荒茏詣?dòng)轉(zhuǎn)換 , 如參數(shù)得復(fù)雜json 只能寫json ，通常大家對(duì)表單比較熟悉, 批量維護(hù)KV 自動(dòng)轉(zhuǎn)JSON ，如是復(fù)雜對(duì)像，支持dto.user.id 這種復(fù)雜kye轉(zhuǎn)josn就爽得多，完全是向面對(duì)像的式在維護(hù)參數(shù)；

直接上圖我是怎么解決的？

下圖就是插件化解耦，維護(hù)好相關(guān)插件，在接口用例中，只是下拉選而已。

參數(shù)維護(hù)方便很多,個(gè)人非常不喜歡json schema 的方式，KV 可方便轉(zhuǎn)復(fù)雜JSON ，又可下接寫復(fù)雜JSON，這才是照顧使用人的效率和提升便利，XXX.XXX.XXX這種才是以面向前對(duì)像的思維維護(hù)參數(shù)，且更切近表單屬性。

對(duì)接口反向用例或混沌測(cè)試支持不夠。

一說反向測(cè)試大家第一反應(yīng)是，通過數(shù)據(jù)驅(qū)動(dòng)來測(cè)試，如果復(fù)雜JSON數(shù)據(jù)結(jié)構(gòu)，數(shù)據(jù)驅(qū)動(dòng)按傳統(tǒng)的方式，對(duì)測(cè)試人員來說一點(diǎn)不方便，這兩個(gè)我們都是這樣來解決的接口反向或是混沌測(cè)試，只需要配置好混沌規(guī)則

看下混沌工程的執(zhí)行結(jié)果：

數(shù)據(jù)驅(qū)動(dòng)，也是按面向?qū)ο竦姆绞?，方便?fù)雜JOSN的結(jié)構(gòu)，傳統(tǒng)的數(shù)據(jù)驅(qū)動(dòng)，只方便KV方式，復(fù)雜對(duì)像，表達(dá)起來費(fèi)勁，我們依然采用xxx.xx.xx 這種對(duì)像屬性訪問形式。

對(duì)接口間的關(guān)系理不清

前面的論述，就不重復(fù)了，接口間只要存在參數(shù)引用，就必須存在依賴關(guān)系，完全可以根據(jù)依賴關(guān)系推導(dǎo)出來，在接口測(cè)試場(chǎng)景中，只要選擇了一些用例，自動(dòng)加入依賴的接口用例，并排好執(zhí)行順序。同時(shí)還能自動(dòng)檢查循環(huán)依賴

自動(dòng)循環(huán)依賴，如下圖給出了具體的循環(huán)依賴信息

研發(fā)都低代碼了，接口測(cè)試卻還沒有低代碼

這其實(shí)變相抬高了接口測(cè)試門檻，同時(shí)也不利于提效。這塊的爭(zhēng)議最多，不再累述?？赡軠y(cè)試人員，平時(shí)寫代碼少，低代碼會(huì)使一些人覺得剝奪他們寫代碼的權(quán)利；也有人說低代碼，容易讓大家變成工具的奴隸，低代碼只是為了提效，把重復(fù)工作工具化，并不禁錮使用人員的思想，從公司的角度來說，老板希望你把時(shí)間花在，重要的事情上， 重復(fù)的事情，工具化，平臺(tái)化。

比如初級(jí)一點(diǎn)的，可以在斷言以及提取參數(shù)時(shí)，通過拖拽的方式，高級(jí)玩法就是bpm 那樣的編排，就像工作流一樣，拖拉的方式來編排，通過編排實(shí)現(xiàn)接口業(yè)務(wù)場(chǎng)景的測(cè)試。另外，還可以重用接口用例，把他轉(zhuǎn)化為JMX 文件，這樣一個(gè)用例或是場(chǎng)景，接口測(cè)試可用，壓測(cè)也重用接口用例，以一當(dāng)二用。

寫到這里也幾千字了,這只是我個(gè)人之言，不對(duì)之處歡迎大家討論拍磚，看到關(guān)于平臺(tái)的討論，很是激烈；我在這里拋磚引玉，只要是有益的討論，對(duì)行業(yè)也是有利，如果能讓大家靜下心來，一起來探討什么是好的接口測(cè)試平臺(tái)，也是好事。少卷一些，少一些KPI，做真正好用的對(duì)測(cè)試人友好的測(cè)試平臺(tái)還是很香的。

好些人做平臺(tái)是為了面試時(shí)加分，或是多些談資，這太急功近利了；我看過好多只是個(gè)demo的平臺(tái)，在這里我就不一一列舉代碼地址了，多數(shù)是為了加群吸粉，這留得住人嗎?。∥冶硎距椭员?！一個(gè)好的面試官用一個(gè)爛平臺(tái)也忽悠不了他，有能力，不管是編碼能力，還是綜合能力強(qiáng)，有很多方方面面來體現(xiàn)，這里就不展開說了。

這貼子肯定少不了爭(zhēng)議，歡迎大來討論，本人是開源免費(fèi)的 www.itest.work ,一站式敏捷測(cè)試管理平臺(tái)作者, 讓測(cè)試變得簡(jiǎn)單、敏捷！是itestwork的執(zhí)念。寫這貼子，也是有感而發(fā)，我們一直在改進(jìn)的路上，3年了一直在維護(hù)中，上面的痛點(diǎn)，必須要全面解決；當(dāng)前正在豐富壓測(cè)模塊及實(shí)現(xiàn)可視化接口編排  大家可以期待。

官網(wǎng)訪問地址：www.itest.work

往期推薦：

itestwork壓測(cè)模塊重磅發(fā)布