• 接口自動化測試框架建設的經驗與教訓

    發表于:2024-3-08 09:15

    字體: | 上一篇 | 下一篇 | 我要投稿

     作者:軟件質量保障    來源:知乎

    分享:
      為什么選擇這個話題?
      一是發現很多“點工”在轉型迷茫期都會問一些自動化測試相關的問題,可以說自動化測試是“點工”升級的必經之路;二是Google一下接口自動化測試,你會發現很多自動化測試框架相關的文章,但是大部分文章都有一個通病,就是只告訴讀者how(怎么做),很少介紹why,還有框架開發完成之后的事情(例如如何推廣、維護等)。那下面就聊一聊我的接口自動化測試框架建設的一些經驗和教訓吧,希望能給大家一些借鑒。
      工作多年,第一次聽說接口測試是在《軟件測試的藝術》的書上面,那時候校招復習軟件測試理論,當時沒有體感,甚至不知道什么是接口。第一次接觸接口測試并非來源于項目需要,而是來源于團隊KPI需要。當時校招剛入職沒多久,團隊內部有測試相關知識與技能培訓(雖然只是測試工具的使用),當時接觸的第一個接口測試工具是 JMeter。還記得我同事通過一個word文檔給我介紹它的一些常用組件,然后就給我安排上了一個任務 - 將團隊 xx 平臺接口代碼覆蓋率提升至40%以上。當時還不知道代碼覆蓋率是什么,但是只曉得通過 JMeter 開發更多單接口/業務場景組合的用例就是了,于是乎就開始通過針對單接口的入參類型、邊界、是否必傳做各種組合,而場景組合用例就做接口間的笛卡爾積生成不同的業務流。第二份工作老板想打造一個團隊內部使用的接口測試平臺,當時就給我這個機會負責接口測試框架的建設。這也是第一次實踐接口自動化測試框架。今天聊的故事就從這里開始。
      一、為什么要自建測試框架
      1.1先談談接口測試
      何為接口?通俗來講生活中常見的電燈開關就是接口,它接收開、關(默認)指令(值),輸出對燈泡的控制結果(亮、滅)。接口測試是測試系統組件間接口的一種測試。測試的重點是要檢查數據的交換,傳遞以及系統間的相互邏輯依賴關系等。
      1.接口測試“套路”
      根據我舉的例子,可以知道對接口測試,從功能上可以把接口當做黑盒進行輸入以觀察其輸出,根據不同的輸入去測試其內部的邏輯,我們可以借助邊界值分析、等價類等方法設計用例。非功能上要測試接口性能、安全、冪等。此外,如果所測接口存在上下接口調用的依賴,則還需要進行全鏈路聯調測試(不部分接口不是獨立存在的,都是和其他接口相互調用的),聯調測試是為了保證上下聯路接口之間契約的準確性。
      2.為什么適合自動化
      根據分層測試思想,可以將系統測試分為單元測試、接口測試以及界面測試。一般來說,單元測試就像一座房子的地基,地基打得好,房子也就比較穩固;接口測試就像房子的架子,決定房子的形態;而界面測試就像房子的裝修,體現房子的外觀。誠然,地基以及房子架子是比較穩定的,變化不大的,而房子的裝修是可以根據心情不斷更換的。大家都知道變化和成本是成正比的,變化越大成本越高,根據ROI=產出/投入,分子不變,分母越大,ROI越小,這也是界面測試不適合自動化的主要原因。當然不代表所有項目都不適合做UI自動化,如果UI比較固定也是可以做自動化的。
      當然,大公司在這方面已經走在了前列了。就拿行業標桿Google來說,《How Google Tests Software》書中也有提到,70%自動化在單測,20%自動化在接口測試,10%自動化在UI測試。
      3.常用的接口測試工具
      介紹下我使用過的JMeter、Postman這兩工具。
      總體而言JMeter更適合作為接口自動化工具的,雖然官網將其定義為壓測工具(The Apache JMeter? application is open source software, a 100% pure Java application designed to load test functional behavior and measure performance.)因為JMeter幾乎能滿足接口自動化測試的所有訴求,有豐富的函數(類似utils)(例如生成個隨機數、uuid等,這些都是測試過程經常用的能力,而且還支持自己擴展)、斷言豐富、結合Jenkins做持續集成、有測試報告、有豐富的插件庫可供下載等等,非常適合技術感不強的測試團隊。Postman也是可以做自動化,但是我還沒有實踐過,平常更多將其作為接口調試的工具,不做過多贅述。
      1.2自動化測試目的
      本來這個小標題是“接口自動化測試目的”,提筆寫的時候發現所有自動化目的貌似是公途的。我先拋出來兩個論點:發現缺陷?提高測試效率?
      大家可能覺得實現自動化的話,這兩個目的是自然而然的。當然我不否認但也不完全贊同。那我為什么要把這兩個論點拿出來討論下呢?因為自動化測試是一個有計劃的過程,不同的目的可能會有不同的實現過程,有不同的實現側重點。
      如果目的是 發現缺陷,那么自動化測試用例就要覆蓋的比較全面且細致(業務層面、斷言層面),這無疑會加大自動化測試用例的開發成本,所以投入過程需要重點分析業務以及多排期些開發時間。
      而提高測試效率呢?當然這里的提效不僅僅體現在測試過程,而且還體現在測試者的日常工作中,類似造數據等工作內容。因此如果以提效為目標,那么自動化測試用例開發要重點分析哪些業務流是調用比較頻繁的,而在斷言層面也沒有必要太過細致,以造數為例,畢竟提效的目的在于獲得結果,只要結果符合預期就是OK的。當然,這些都是筆者個人看法,大家可以各抒己見。
      1.3為什么需要自研框架?
      上文也說道做接口自動化測試,當下有現成的開源工具 JMeter、Postman等可以選擇,也有一些開源的自動化測試平臺。但是,這些開箱即用工具也有弊端:
      1. 測試工具開發的測試用例往往不易于維護,試想一下當你維護JMeter生成的各種JMX文件場景。
      2. 大量的測試用例可重用性差,例如登陸模塊,每個接口調用前都要獲取cookie,而登陸則是前置模塊,使用JMeter開發用例需要每個JMX文件都要包含登陸,重復度太高。
      3. 無法滿足自動化平臺訴求,短期內確實可以快速實現自動化,但是這些工具對于平臺非自動化能力的拓展成本較高,畢竟改動開源工具的成本比自研高很多。
      4. 使用開源工具不利于提升團隊在自動化技術方面的成長。自動化能力的提升離不開編程能力的提升,使用開源工具能提升工具學習使用能力,最終你的成長無外乎又掌握了一個測試工具的使用。
      5. 無法最大化提升自己解決問題的能力。
      1.4接口測試框架選型
      · 關于語言
      語言建議和負責項目的系統語言保持一致,如果被測項目語言是Java,測試框架就選用Java語言開發,結合Spring boot框架搭建。
      · 關于擴展性
      擴展性是非常重要的,因為框架不是一蹴而就的,是一個需要基于業務的迭代不斷“更新”的,良好的擴展性,可以讓你更高效的開發所需的feature。這點可以參考JMeter的架構設計。
      · 關于實現方案
      確定使用的技術后,務必要將的實現思路整理出來,寫一個實現方案,就像項目的系分文檔一樣,這樣對你來說具備指導意義。仔細想想,測試框架的開發,就是要求自己兼顧產研測的角色(條件可以的話,可以讓產品/UI幫你設計平臺草圖)。
      二、經驗沉淀
      1.計劃的重要性
      萬事預則立,不預則廢。對于測試來說,計劃尤為重要。一方面測試框架建設的任務并不會允許你100%工作時間去做,因為你還有業務測試工作要負責和跟進。另一方面,老板要看結果,制定每個階段的里程碑是非常重要的,當然計劃這些會在OKR里體現的。
      以我的經驗,可以制定按照feature數量給自己排期,例如每周實現x個feature,這樣就可以大概推出完成測試框架開發需要的周數,盡量周報里有所體現實現的進度,以及下周的todo。
      2.文檔必不可少
      為什么文檔這么重要?文檔其實是另一種“自動化測試框架”的實現方式。代碼實現框架本身,文字為框架“穿上衣服”。再者,文檔可以節約你未來非常多的“客服”時間。文檔內容范圍不限,總的來說有三類:技術實現文檔、使用說明文檔以及問題記錄的文檔。
      1. 技術實現文檔用于描述框架實現的技術手段以及編碼規范,可以在系分文檔上繼續補充。
      2. 使用說明文檔用于介紹使用方法,最好是先以快速入門為例,教大家如何利用測試框架開發一個測試用例。再詳細介紹如何使用(調用)某些公共組件(工具)。當然建議錄制操作視頻。
      3. 問題記錄文檔 用于協作開發的時候供其他小伙伴參考使用,畢竟你踩過的坑別人也有可能踩過。這樣可以減少同類問題排查和定位時間。(筆者曾經在幫助小組同學排查問題方面就耗費了不少時間。)
      3.多人協作下的開發模式
      自動化框架最終的是推廣給大家使用它去開發接口測試用例,以替代JMeter這些接口測試工具。在平臺化實現之前,就避免不了多人同時提交開發好的用例代碼。針對這個,我建議使用master\dev分支,每日的自動化用例運行使用master分支代碼,而dev分支用于大家提交各自分支的代碼。這就需要經常dev分支的代碼合到master分支。
      4.做好代碼review工作
      正如經驗3一樣,確定好開發模式之后,同樣不能避免有些同學在提交代碼時“亂來”(不規范開發和提交,例如隨意修改別人的代碼等),導致代碼沖突。而作為項目的負責人,就像一個門神,要做好代碼review工作。這樣可以在一定程度上降低代碼沖突的概率?傊M量不要將寶貴的時間消耗在這些代碼管理的問題上。
      5.推廣小組試用
      框架開發好后,不建議急于大批量推廣,建議先“小流量”灰度試用。我們大團隊下面分了很多小團隊,基本上業務owner帶一些外包保障項目質量。而管理者注重框架的結果?蚣荛_發者是全職員工,框架的使用者主要是外包和偏業務測試全職同學。當時搞定框架開發之后(算是1.0版本,已經可以使用),就在我的小組進行使用。這樣可以先搜集一下使用效果和反饋的問題,先做一版小迭代,把他們覺得比較影響使用的問題先解決掉。
      6.分享和培訓
      先給大家做了一次分享,演示框架操作原理,如何開發接口測試用例。為了讓大家好理解,我就拿postman 的使用步驟和框架測試一個接口做類比。即使如此, 大家剛使用測試框架時候仍遇到了不少問題(也是意料之中,大多數外包幾乎 0 編程經驗),包括接口測試用例開發成本高,外包同學代碼能力差遇到問題解決不了,不會debug代碼,開發好的用例上傳gitlab經常搞出沖突需要解決,每個同學用例的寫法千奇百怪等等。還記得當時那段時間的內容,除了做手上的業務就是幫忙看大家在寫用例遇到的各種問題。為了解決這些問題,我也擠時間編寫測試框架使用說明書,對大家進行git使用培訓,debug培訓等,鼓勵大家多學點Java,多讀讀《Java編程思想》。
      7.注重大家的使用反饋
      使用反饋是非常重要的。因為它是你進行版本迭代的驅動力。其實就和產品做項目一樣,每個版本都要分析用戶的使用反饋,根據反饋進行版本優化和迭代?梢院褪褂谜邷贤,發現一些他們使用過程的痛點。當然這只是第一步,更重要的是要有解決方案。
      8.考慮代碼生成
      針對用例開發成本高的問題,我通過在測試用例開發過程總結到HTTP不同請求方法對應的接口測試寫法不一樣,同方法的測試接口寫法幾乎一致,突然想到可以使用模板(freemarker)自動生成接口測試用例,然后我就整理幾種接口測試用例生成模板(post、get等),這樣大大降低測試用例開發成本,大家更多在于測試數據的準備和斷言。
      個人覺得代碼生成是每個測試框架設計的必須考慮的點,因為像postman、jmeter等這些工具本質上和你開發測試框架是雷同的,如果做到用例之間可以相互轉化,可以提高用例的可遷移性和復用性。
      三、教訓總結
      1.缺乏自動化效果的統計&度量
      上文說了,相比過程,老板更看重結果。如何體現結果,那就是要有數據統計與度量。記得被開發挑戰過,你們搞得自動化發現了多少缺陷、節約了多少時間等問題。這塊當時做的不好。
      1是框架本身還沒有平臺化,當時實現的功能是測試用例開發模塊的實現,統計數據沒有落DB,這塊需要靠人工統計比較費時間(當時為了統計自動化用例運行結果數據,在Jenkins服務器上撈日志,簡直是痛苦)。
      2是當時沒有明確的度量目標,像節約了多少時間這類,確實難以衡量。
      現在我覺得當時的框架設計之初是遺漏了這個問題的,建議后來者可以將測試數據都落DB。
      2.沒有對測試進行測試
      這個主要是沒有對測試框架本身進行測試,特別是多人協作開發模式,單測尤為重要,單測在一定程度上是保障代碼質量的手段,可以有效避免部分同學“亂改”別人的代碼。當然,如果時間充足,建議對測試框架寫單測。
      3.自動化用例開發計劃沒有突出側重點
      這個也是教訓1的一個原因?蚣芡瓿芍,我們就在okr里計劃xx完成接口100%自動化覆蓋,剛開始階段沒有對被測接口重要性做分析,導致沒有將時間花在核心的接口用例開發上,也間接導致產出不高。
      現在想想,其實是計劃不明確且沒有突出重點的問題,顆粒度還不夠,現在的建議是大家要優先實現核心接口,這些接口流量大,更容易有產出。不要為了追求覆蓋率而本末倒置。
      4.斷言的不完善
      當時的框架沒有開發DB checker,所以斷言全靠http 響應,其實這樣的用例是質量不高的,也就是測試預期不全面,可能會存在漏網之魚(遺漏缺陷)。
      建議大家一定要斷言模塊重點考慮到。包括http層面(響應時間、響應碼、key字段斷言、狀態碼等)、DB層面(key字段值比對等)。
      本文內容不用于商業目的,如涉及知識產權問題,請權利人聯系51Testing小編(021-64471599-8017),我們將立即處理
    《2023軟件測試行業現狀調查報告》獨家發布~

    關注51Testing

    聯系我們

    快捷面板 站點地圖 聯系我們 廣告服務 關于我們 站長統計 發展歷程

    法律顧問:上海蘭迪律師事務所 項棋律師
    版權所有 上海博為峰軟件技術股份有限公司 Copyright©51testing.com 2003-2024
    投訴及意見反饋:webmaster@51testing.com; 業務聯系:service@51testing.com 021-64471599-8017

    滬ICP備05003035號

    滬公網安備 31010102002173號

    久久97久久97精品免视_欧洲国产伦久久久久久_91麻豆精品国产自产在线观_伊人久久大香线蕉综合av