性能測試技術筆記(二):如何準備測試環境和數據

這篇文章,繼續分享工作筆記中關於性能測試的內容。

上一篇文章聊瞭如何快速上手壓測工作的幾個切入點和注意事項,這些內容可以幫助我們更快的介入項目。

但實際工作中,前期的準備工作也是很繁瑣的,其中測試環境和測試數據的準備是前期準備階段的主要工作。

這篇文章,以實際的一些場景出發,來聊聊如何準備測試環境和測試數據。

 

測試環境

生產全鏈路壓測這種在生產環境進行的壓測案例這裏就不講了,因爲難度較大,且對大部分同學來說沒太多參考意義。

以日常的壓測場景展開來說,正常壓測都是在測試環境展開的。那麼是選擇功能測試環境,還是獨立的性能測試環境呢?功能測試環境通常具備這幾個特點:

  1. 發佈頻繁;
  2. 功能&服務不穩定;
  3. 測試場景較多且交叉影響較大;

而性能測試一次壓測運行的時間相對較長(短則10min長則12小時甚至幾天),且爲了獲得誤差較小的壓測結果,性能測試對服務的穩定性要求較高。

因此我建議如果有條件,還是搭建一套獨立的性能測試環境更好

搭建獨立的性能測試環境要注意如下幾點:

  1. 獨立的域名或請求入口;
  2. 應用服務器配置和生產保持一致;
  3. 應用服務數量可以最小化(生產是集羣,測試環境1臺服務器部署1個服務);
  4. 邊緣服務&弱依賴服務&高性能服務(全讀緩存,rt幾毫秒)可以考慮1臺服務器部署多個應用服務或者mock解決;
  5. 緩存、消息隊列、數據庫配置按比例降低(比如一個mysql實例,4C8G/8C16G足以滿足日常壓測需要);
  6. 服務的發佈版本要注意如下亮點:
    1. 本次測試範圍內的服務,發佈對應的分支;
    2. 本次測試範圍外的服務,和生產版本保持一致;

當然,近幾年的流量染色等技術的應用成熟,可以在一定程度上降低搭建和維護環境的成本,但如果有能力落地流量染色服務,那搭建性能測試環境的注意事項,也就不用看了。

流量染色技術的應用實踐,可以參考這裏:得物染色環境落地實踐

 

測試數據

聊完測試環境的準備工作後,聊聊測試數據的準備。

當然,從某種程度上來說,測試數據也可以歸納到測試環境這個大的範疇中。

壓測所涉及的數據,主要分爲如下幾種類型:

鋪底數據

鋪地數據可以理解爲冷數據,因爲正常的線上業務,數據庫的表中一般是要存在一定的鋪底數據的,如電商的庫存數據,用戶基礎數據如電話號碼、收貨地址等。

在獨立的性能測試環境中,也需要準備對應的鋪底數據,因爲SQL執行過程中,空表和大表對性能的影響還是很大的。

準備鋪底數據,最常見的有如下2種方式:

  1. 從生產環境同步(需要進行敏感數據脫敏處理);
  2. 調用業務接口,用腳本批量生成寫入(無需脫敏,符合業務邏輯即可);

熱點數據

什麼是熱點數據?比如用戶的登錄態信息(token)、比如優惠券、比如商品圖片(常存儲於CDN)。

我見過很多同學在壓測時先壓測登錄接口,然後將登錄後的token拿出來再傳遞給下一個請求,完全沒必要這麼麻煩。

可以先準備一批虛擬的測試賬號,跑批登錄,然後將token預熱到緩存中,過期時間設置的比較長即可。

在後續的測試工作中,只需要在請求頭中將token和userid按照對應順序參數化到請求中即可。

壓測的場景要符合實際的業務場景,但要考慮到效率和實現成本。

其他熱點數據的準備也可以參照上述的方式,提前生成,然後預熱到緩存(也有本地緩存或jar包方式)。

參數化數據

參數化數據指的是壓測過程中腳本中需要引用到的數據。以電商業務來說,常見的有用戶id、商品數據、庫存數據、訂單數據等。準備參數化數據,最常見的有如下3種方式:

  1. 業務邏輯上強驗證的,通過腳本跑批提前生成,再從數據庫中拿出來使用;
  2. 簡單的自增邏輯(如訂單編號),可以通過壓測工具提供的插件自增生成或寫代碼實現;
  3. 只校驗字符串位數或不爲空的場景,用隨機數或uuid生成即可;

準備參數化數據的過程中,需要注意如下幾點:

  1. 數據的冪等性(是否可重複使用);
  2. 數據的關聯性(是否需要前置動作來更新狀態);
  3. 數據的有效性(數據需要在使用階段內一直生效);
  4. 數據的唯一性(數據在邏輯處理中僅且只有某些場景纔可用);

做完了上述的幾點數據準備工作,最後要做的就是對數據可用性進行驗證,看看它是否如預期滿足壓測需要。

 

以上就是關於測試環境和測試數據準備過程中需要注意的事項。

下篇整理的筆記內容,會聊聊如何設計一個簡單可用的壓測平臺。

 

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章