轉轉交易全鏈路接口測試發展及擴展

發表于:2020-4-26 09:30  作者:雷子說測試   來源:雷子說測試

字體: | 上一篇 | 下一篇 |我要投稿 | 推薦標簽: 軟件測試技術 接口測試

  1.概述
  1.1.背景
  1.交易相關業務測試訂單流很多、流程偏后測試與回歸的重復工作量大,效率低;
  2.商品類型及訂單狀態多樣,訂單又包括紅包、服務、活動等屬性,全鏈路數據種類非常多,如被測需求發生在交易場景末端或者關聯多種屬性則數據構造需要操作很多步驟,效率很低。
  3.業務敏感,需求上線需要反復的對基礎業務進行回歸。
  1.2.目標
  1.測試前置。在聯調或前端提測前完成業務流程測試,讓功能測試盡可能的只關于與前端交互。
  2.抽離核心業務,作為環境檢測、冒煙測試、上線前輕量級回歸。
  3.用例可視化,提供分享執行、定時執行功能。
  4.提供數據構造,減少末端場景、復雜數據構造帶來的效率損耗。
  5.性能數據收集,多線程場景下并發量可參數化,為性能測試提供便利。
  6.用例推薦,小需求自動提供用例,方便回歸上線。
  2.發展過程
  2.1.All In One
  1.接口測試最初應用階段,沒有成型的代碼接口,為了快速響應需求,將所有代碼集中在@Test方法中,包括服務初始化、測試數據構造、測試用例、測試結果校驗。
  2.2.公共方法抽離
  1.隨著測試用例的累積,服務初始化、數據初始化相同的代碼塊重復出現,甚至校驗方式出現大同小異的方法塊。一些請求參數封裝,返回值的解析邏輯出現重復。
  2.當重復的代碼和類似的邏輯重復出現時整個測試項目便可以進行集成和重構抽象出初步的框架結構。
  3.當抽離完成后用例編寫更加高效用例對需求的覆蓋程度提高,針對不同類型的項目或不同的被測主體出現幾大類用例編寫模式,如基于被測實體狀態變化進行狀態覆蓋的狀態類測試用例如訂單流轉與交易流程中商品的狀態變化,基于業務流轉進行分支覆蓋的分支類測試用例如運營活動等等細分類別。
  基于狀態
  基于流程
  2.3.項目分離與數據構造
  隨著代碼量增長,項目開始變得臃腫,但項目從代碼邏輯來看可以清晰分為兩層,一層為提供基礎功能的代碼,如服務于基礎的工具類、服務接口調用方法等,另一層為測試用例;
  再者接口測試已經發展一段時間,用于業務測試、回歸測試的場景已經成熟,到了再往前走一步的階段:比如在功能測試中QA往往直接通過寫幾行代碼來輔助構造一些數據,項目合理的拆分似乎可以更便于將構造數據功能平臺化。
  基于以上原因對整個項目進行了分離,一個項目為zzserver-core,用于編寫直接調用服務的代碼以及通過一些組合可以用最少的參數構造出期望的數據,另外提供一些工具類,這樣zzserver-core項目不僅可以為接口測試提供基本能力還可以作為公共jar包為其他項目提供接口調用能力或提供工具。另一個項目為zzserver,用于維護接口測試用例;在項目分離的同時對測試用例進行了一次細分,分為項目測試用例用于需求和大項目測試、監控級別測試用例即checklist用于日常上線前回歸等輕量級檢測、性能測試用例用于基于testNG的性能測試。
  zzserver-core中的數據構造是在項目中維護特定的builder方法,組織一部分接口構造一些常見數據,如發布不同類型商品的接口,發布商品并構造不同狀態訂單的接口等等。以上數據構造能力被用例展示平臺引用后形成數據構造平臺,方便除接口測試外碼維護者外的用戶方便的構造出想要的數據。比如通常來說功能測試需要校驗一個已發貨訂單的詳情頁需要測試者在兩臺手機上登錄App,一個發布商品一個購買商品,然后再做發貨操作才能看到被測頁面,有了數據構造功能后僅需要在頁面上輸入兩個uid點下確認就可以在App上看到需要的訂單。
  提供數據構造后項目結構
  2.4.checklist
  1.在持續的需求迭代、大小需求上線過程中保持交易核心流程的正確性,同時降低每次上線手動回歸的時間成本,checklist便從繁重的業務接口測試中抽取出來,目標是高效的覆蓋核心業務流程。
  2.當前checklist包括正向交易流程、退款仲裁等逆向流程、紅包、活動等,同時對執行過程中的商品庫存、訂單狀態、訂單按鈕、最終打款去向和財務平賬進行校驗,確保基本流程的正確性。
  3.后續checklist會繼續細分,并引入推薦系統,協助輕量級上線。
  2.5.性能測試
  隨著交易業務發展,線上業務的性能瓶頸漸漸凸顯性能測試需求開始出現;交易性能測試偏向于某個業務場景的性能指標評估。又因為現在接口測試用例比較完善另外有用例展示平臺支持用例界面化生成和平臺執行,在已有框架和平臺最大化使用的前提下發展出基于TestNG加壓、用例平臺展示、新服務展示數據的性能測試框架;
  比如要模擬一個比較真實的線上場景:線上用戶都在隨機的瀏覽可下單的商品,并出現一定比率的用戶下單,一定比率的用戶查看訂單,一定比率的用戶付款,一定比率的用戶退款等操作,且以上操作都是混雜在一起隨時都有可能出現,另外買家和賣家也在進行著不同的操作,且有可能同時操作試圖將訂單改向兩個沖突的狀態;
  上段描述的測試場景看似復雜,但依托現有接口測試接口實現起來就簡便了很多;
  性能評估的一大要素是測試數據數據,主要包括qps、響應時間、服務器性能指標等,qps可用過服務端獲取到,接口響應時間在SCF框架的代理外增加一層代理收集數據除此代課還可以收集返回值異常的請求和返回信息方便拍錯,用例執行情況和拋出的異常通過testNG執行監聽收集數據,服務器性能參數通過agent收集,以上數據均通過RMI服務同步至性能測試平臺進行存儲和分析。
  數據收集策略
  性能測試執行流轉
  3.用例類型
  無論用于接口測試的項目結構如何持續變更,配合提高效率的外部子系統如何多樣和高效,用例永遠是接口測試的核心內容。
  交易接口用例大致分為五類:
  1.基于訂單或商品狀態流轉的狀態類測試用例。
  a)該類測試用例主要應用測試已配置好的狀態機,校驗訂單在流轉過程中的狀態變化,通過訂單狀態為用例主線來覆蓋所有業務。
  2.基于活動的分支覆蓋類測試用例。
  a)該類用例主要出現在運營活動中,通過對活動中出現的不同分支進行覆蓋達到需求測試點的覆蓋。
  3.基于業務、財務分賬的結算正確性驗證的測試用例。
  a)該類用例主要出現在交易結束時對訂單金錢流轉進行校驗,屬于交易業務特有類型。即敏感有復雜。
  b)該類用例出現在交易末端,交易的前置流程復雜,數據多樣,訂單的附加屬性又實時的影響著最終結算,通常從不同的分支過來的訂單或夾帶不同附加屬性的訂單最終的結算結果都不同,所以結算測試算是交易測試中敏感又復雜的業務,如采用功能測試則需要非常大的精力去構造各種類型輸入,如遇到Bug修復或者需求變更需要全量回歸,對整個項目的排期會帶來很大的影響。
  4.基于交易核心能力的測試用例如狀態機擴展的測試。
  a)狀態機以及狀態機擴展是交易的一種能力,可以使訂單基于配置進行流轉,如當前訂單處于狀態1,1狀態訂單僅僅可以觸發handler A、B、C,其中handler A可使訂單狀態流轉至B;狀態機擴展即在狀態機中加入擴展點,在命中擴展點之后可以在已有狀態機的基礎上執行擴展handler,同樣也是一種能力。
  b)對于交易我們平時測試主要為已配置好的狀態機以及編入業務邏輯的handler,但是如果在業務初期或基礎能力改版、擴展時沒有業務,僅有能力時,測試便是基于能力的測試而非業務,此時就需要測試者主動編入各種規則并通過訂單流轉來觸發規則以證明基礎能力是否可用。
  5.另外還有文案類,對列表頁、詳情頁按鈕、服務窗文案進行校驗。
  整體結構與輕量級上線
  1).交易接口測試整體以服務調用方法、數據構造方法、工具類為基礎,再此基礎上拼裝出滿足不同業務測試的測試用例;
  2).另在測試用例的基礎上添加不同子系統以發揮剩余價值或提高效率;
  3).用例持續提取和細分,整理出不同的checklist并配合diff數據主動推薦需求需要測試的checklist,并在測試后通過jacoco反饋diff代碼的覆蓋情況,做到小需求RD可自行通過checklist回歸上線。
  接口測試項目接口+后續擴展

      本文內容不用于商業目的,如涉及知識產權問題,請權利人聯系博為峰小編(021-64471599-8017),我們將立即處理。

【福利】填問卷送精選測試禮包+接口測試課程!為測試行業做點事!

評 論

論壇新帖

頂部 底部


建議使用IE 6.0以上瀏覽器,800×600以上分辨率,法律顧問:上海瀛東律師事務所 張楠律師
版權所有 上海博為峰軟件技術股份有限公司 Copyright©51testing.com 2003-2020, 滬ICP備05003035號
投訴及意見反饋:webmaster@51testing.com; 業務聯系:service@51testing.com 021-64471599-8017

滬公網安備 31010102002173號

51Testing官方微信

51Testing官方微博

掃一掃 測試知識全知道

日本av