測試架構(gòu)師如何解讀測試平臺的各種爭議
iTesting，愛測試，愛分享
本篇文章，首發(fā)于軟件測試架構(gòu)師俱樂部公號。iTest框架作者。他對測試框架的認知非常透徹，下面一起來看下他的真知灼見。
最近關(guān)于測試平臺的討論很激烈。我本人是支持平臺的，但是現(xiàn)在好多平臺都是KPI導(dǎo)向，拿接口測試平臺來說，除了少數(shù)做得不錯之外，看到好多不是demo ，就是jmeter ,postman的web 化，不否認做平臺，對技術(shù)多少還是有提升(大多數(shù)是CRUD，僅僅是從0到1)，但是如果平臺沒人用，這平臺就是失敗的。證明有一定的技術(shù)實力，除了開發(fā)平臺，還有很多更高效的方式，比如為開源軟件提交PR，熟讀開源中件間代碼，掌握測試前后移的技術(shù)，為團隊開發(fā)實用測試小工具等。
痛點
隨著微服務(wù)架構(gòu)理念，云計算，容器技術(shù)的普及，DevOps在it界漸成共識，并成為主流開發(fā)模式，在DevOps快速迭代中測試成為快速交付的一大短板。降本增效迫在眉睫。反過來，平臺只要好用，就是好的平臺，什么是好的平臺，一定是要能做到降本增效。
先從兩個主流工具的局限性談起，postman 和jmeter 是兩個比較主流的接口測試工具，當(dāng)然jmeter 用于壓測和接口自動化都可以。這兩個工具都解決了接口測試的基本問題，但仍然存在不少問題，我羅列了以下五點：
1.可管理性不強
我認為這些工具在一定程度上就是個面向個人的“單兵武器”， 基本上無可管理性。JMX，或是JSON文件，不好管理，協(xié)同就更是難上加難。市面上對他們web化的價值，也就是可管理這一點，更深層次的痛點并沒有觸達。
2.對測試人員不足夠“友好”
用過QTP，LR之類的對測試人員都知道，傻瓜化，不懂代碼，一樣用得很開心，這對大多數(shù)不會寫代碼的測試人員來說，確實是“福報”，斷言，參數(shù)化，數(shù)據(jù)驅(qū)動都非常簡單，然而這些工具都是商業(yè)化且使用場景相對固定，并無法快速響應(yīng)互聯(lián)網(wǎng)不斷變化的測試需求。反觀postman或者jmeter，雖然免費了但是又有不少功能需要你二次開發(fā)，所以說沒有”普適性”。對于一些代碼基礎(chǔ)薄弱的同學(xué)來說，遇到定制化的需求往往束手無策。檢驗”普適性”的標(biāo)準(zhǔn)，就是是否傻瓜化，這決定了門檻的高低；高級使用人員，可以二開及使用一些高級特性。傻瓜化不是提倡，測試人員不會代碼就是好事，平臺想要推廣得好，普適性很重要，打個不太恰當(dāng)?shù)谋确?，就算會寫代碼，也沒多少人用VI 或是記事本寫，都要用IDE工具，為什么？效率高呀。會寫代碼，可以做很多實用的測試小工具，還是非常棒的!
3.對接口反向用例或混沌測試支持不夠
雖然很多平臺支持?jǐn)?shù)據(jù)驅(qū)動測試，但是對接口反向用例或混沌測試支持不夠。先從一下真實生產(chǎn)事故講起，朋友公司因第三方接口導(dǎo)致了服務(wù)器宕機，最后查到的原因是，掃碼，傳入的數(shù)據(jù)是一個比較長的亂七八糟的字符串，沒按要求傳正確的值，結(jié)果服務(wù)器，死循環(huán)掛掉了。接口測試時，無法窮舉所有參數(shù)值。在postman 和jmeter中都有數(shù)據(jù)驅(qū)動，但是我認為采用枚舉的方式來設(shè)置參數(shù)值，然后通過數(shù)據(jù)驅(qū)動的方式來執(zhí)行測試，對人的依賴太大。后面我再講接口混沌測試，瞬間可以完成笛卡爾積式的接口混沌測試，從另一個視角來實現(xiàn)，且和接口數(shù)據(jù)結(jié)構(gòu)無關(guān)。
4.理不清接口間的調(diào)用關(guān)系
縱使寫了很多接口用例，但是對接口間的關(guān)系依然是”抓瞎”。很多時候我們借助于調(diào)用鏈跟系統(tǒng)，但是對于平臺上的接口用例，調(diào)用鏈這張網(wǎng)又太大，和接口用例也不完全匹配，就算匹配，且調(diào)用鏈跟蹤突出的是，調(diào)用上的時間順序，并不突出他們之間的依賴關(guān)系，以及是什么樣的依賴關(guān)；也不是所有系統(tǒng)都用上了調(diào)用鏈路跟蹤，大多不是微服務(wù)架構(gòu)的項目，這塊想用調(diào)用鏈跟系統(tǒng)(如 SkyWalking Zipkin、Pinpoint等)還是不好辦的。接口用例間，實際上就存在依賴關(guān)系，如A接口，要依賴取token 接口，同時A還依賴B接口的響應(yīng)數(shù)據(jù)中提取的參數(shù)等等，這在postman ,jmeter 中，雖然接口依賴關(guān)系事實上存在，但只能人工去理，沒有一目了然的可視化界面來展示依賴關(guān)系，當(dāng)一個接口改動了，也不方便評估，對其他接口的影響；且通過直觀的依賴關(guān)系，可促使挖掘更多的測試場景。
5.低代碼模式對測試能效提出更高的要求
研發(fā)都低代碼了，接口測試卻還沒有低代碼，變相抬高了接口測試門檻，當(dāng)然這個對于測試來說要求也比較高，事實上這也不利于提效?？隙ㄓ腥艘磳α耍瑴y開就是要寫代碼呀，能寫代碼這很好呀，明確的說，這是五年前流行的觀點了，我們要的不是代碼的堆砌，而是高質(zhì)量的有效代碼；測開會寫代碼，做出來的產(chǎn)品和解決能效之間并不是等號！脫離方法論，脫離工程文化等能加快交付途徑的方方面面，只是“秀代碼”,沒多大價值。既然要做平臺，出發(fā)點肯定是團隊提效，而不是單兵作戰(zhàn)；另外從公司團隊組建的角度來說，也不可能全是測開，平臺化如果不考慮業(yè)務(wù)測試的融入，不考慮對非測開人員的“普適性”，就沒法解決木桶效應(yīng)的問題，我認為這個平臺是失敗的，不管如何分工，團隊的整體能效沒上去，這平臺就是測開自嗨的平臺?，F(xiàn)在開發(fā)都在提低代碼了，開發(fā)效率會大大提升，測試的壓力更大，測試也要低代碼化，才能也一起提效，否則測試這塊的短板更短，下面我也會再講講對于測試低代碼化的一些思考。
現(xiàn)在大家對低代碼的討論非常多，看低的也大有人在，我這里就不展開說了，但有一點我認為低代碼會成為趨勢，無服務(wù)對低代碼更是推波助瀾。目前比較火的低代碼平臺，比較有名的都是國外的，微軟也有低代碼平臺。拿我我們公司的低代碼平臺來說，剛畢業(yè)的新人，入職三天，就能實現(xiàn)業(yè)務(wù)開發(fā)了，效率還是杠杠的！且通過注解，單元測試不需要寫一行代碼了，加少量的注解就可以了，比手寫junit 測試類，省至少2倍的時間 。
上面是我個人認為的接口測試中最痛的點，我看到的接口測試平臺，不解決這些剛需，只是通過web封裝工具的話意義不大。從老板的角度來說，沒增效，投人力做這事就不值，大家都知道提問題簡單，難在解決問題，下面我來說我的解決方案是什么？
解決方案
下面就來談?wù)勎以O(shè)計的一站式敏捷測試管理平臺，針對我羅列的五個痛點是如何解決的。
關(guān)于管理協(xié)作，只要是平臺化，天然就解決這問題。
對測試人員友好，主要是可用性，可維護性。
postman 和jmeter 雖然受到普遍的歡迎，但從自動化角度來說存在一些硬傷，我舉兩個設(shè)計上的具體例子；
postman前后置腳本及簽名等和接口用例耦合在一起，不方便維護,比如我需要對請求簽名，如果簽名算法改了，我得來改接口用例，如果有100個接口，這改起來太可怕了，要是解偶，只要改簽名算法本身，其他接口中是選擇引用這個算法，就不存在這種痛苦；
參數(shù)維護不面向?qū)ο袂也荒茏詣愚D(zhuǎn)換 , 如參數(shù)得復(fù)雜json 只能寫json ，通常大家對表單比較熟悉, 批量維護KV 自動轉(zhuǎn)JSON ，如是復(fù)雜對像，支持dto.user.id 這種復(fù)雜kye轉(zhuǎn)josn就爽得多，完全是向面對像的式在維護參數(shù)；
直接上圖我是怎么解決的？
下圖就是插件化解耦，維護好相關(guān)插件，在接口用例中，只是下拉選而已。
參數(shù)維護方便很多,個人非常不喜歡json schema 的方式，KV 可方便轉(zhuǎn)復(fù)雜JSON ，又可下接寫復(fù)雜JSON，這才是照顧使用人的效率和提升便利，XXX.XXX.XXX這種才是以面向前對像的思維維護參數(shù)，且更切近表單屬性。
對接口反向用例或混沌測試支持不夠。
一說反向測試大家第一反應(yīng)是，通過數(shù)據(jù)驅(qū)動來測試，如果復(fù)雜JSON數(shù)據(jù)結(jié)構(gòu)，數(shù)據(jù)驅(qū)動按傳統(tǒng)的方式，對測試人員來說一點不方便，這兩個我們都是這樣來解決的接口反向或是混沌測試，只需要配置好混沌規(guī)則
看下混沌工程的執(zhí)行結(jié)果：
數(shù)據(jù)驅(qū)動，也是按面向?qū)ο竦姆绞?，方便?fù)雜JOSN的結(jié)構(gòu)，傳統(tǒng)的數(shù)據(jù)驅(qū)動，只方便KV方式，復(fù)雜對像，表達起來費勁，我們依然采用xxx.xx.xx 這種對像屬性訪問形式。
對接口間的關(guān)系理不清
前面的論述，就不重復(fù)了，接口間只要存在參數(shù)引用，就必須存在依賴關(guān)系，完全可以根據(jù)依賴關(guān)系推導(dǎo)出來，在接口測試場景中，只要選擇了一些用例，自動加入依賴的接口用例，并排好執(zhí)行順序。同時還能自動檢查循環(huán)依賴
自動循環(huán)依賴，如下圖給出了具體的循環(huán)依賴信息
研發(fā)都低代碼了，接口測試卻還沒有低代碼
這其實變相抬高了接口測試門檻，同時也不利于提效。這塊的爭議最多，不再累述?？赡軠y試人員，平時寫代碼少，低代碼會使一些人覺得剝奪他們寫代碼的權(quán)利；也有人說低代碼，容易讓大家變成工具的奴隸，低代碼只是為了提效，把重復(fù)工作工具化，并不禁錮使用人員的思想，從公司的角度來說，老板希望你把時間花在，重要的事情上， 重復(fù)的事情，工具化，平臺化。
比如初級一點的，可以在斷言以及提取參數(shù)時，通過拖拽的方式，高級玩法就是bpm 那樣的編排，就像工作流一樣，拖拉的方式來編排，通過編排實現(xiàn)接口業(yè)務(wù)場景的測試。另外，還可以重用接口用例，把他轉(zhuǎn)化為JMX 文件，這樣一個用例或是場景，接口測試可用，壓測也重用接口用例，以一當(dāng)二用。
寫到這里也幾千字了,這只是我個人之言，不對之處歡迎大家討論拍磚，看到關(guān)于平臺的討論，很是激烈；我在這里拋磚引玉，只要是有益的討論，對行業(yè)也是有利，如果能讓大家靜下心來，一起來探討什么是好的接口測試平臺，也是好事。少卷一些，少一些KPI，做真正好用的對測試人友好的測試平臺還是很香的。
好些人做平臺是為了面試時加分，或是多些談資，這太急功近利了；我看過好多只是個demo的平臺，在這里我就不一一列舉代碼地址了，多數(shù)是為了加群吸粉，這留得住人嗎??！我表示嗤之以鼻！一個好的面試官用一個爛平臺也忽悠不了他，有能力，不管是編碼能力，還是綜合能力強，有很多方方面面來體現(xiàn)，這里就不展開說了。
這貼子肯定少不了爭議，歡迎大來討論，本人是開源免費的 www.itest.work ,一站式敏捷測試管理平臺作者, 讓測試變得簡單、敏捷！是itestwork的執(zhí)念。寫這貼子，也是有感而發(fā)，我們一直在改進的路上，3年了一直在維護中，上面的痛點，必須要全面解決；當(dāng)前正在豐富壓測模塊及實現(xiàn)可視化接口編排 大家可以期待。
官網(wǎng)訪問地址：www.itest.work
往期推薦：