多產品軟件供應商經常面臨的問題之一是幾乎每個團隊的工程師（開發人員、測試人員和基礎架構管理員）的能力重複。 這也適用於昂貴的工程師 - 負載測試領域的專家。
工程師通常不得不從頭開始部署測試基礎設施、配置負載工具並將其嵌入，而不是直接履行職責並利用他們獨特的經驗來構建負載測試流程、選擇方法、最佳指標並編寫自動測試他們自己在 CI 系統中，設置監控和發布報告。
您可以找到我們在 Positive Technologies 中使用的測試中一些組織問題的解決方案 . 而在這一篇中，我將討論使用“負載測試即服務”（load testing as a service）的概念將負載測試集成到通用 CI 管道中的可能性。 您將了解如何以及在 CI 管道中使用哪些加載源的 docker 鏡像； 如何使用構建模板將加載源連接到 CI 項目； 用於運行負載測試和發布結果的演示管道是什麼樣的。 這篇文章可能對 CI 中正在考慮其負載系統架構的軟件測試工程師和自動化工程師有用。
概念的本質
負載測試即服務的概念意味著能夠將負載工具 Apache JMeter、Yandex.Tank 和您自己的框架集成到任意持續集成系統中。 該演示將針對 GitLab CI，但所有 CI 系統的原則都是通用的。
負載測試即服務是用於負載測試的集中式服務。 負載測試在專用代理池中運行，結果自動發佈在 GitLab Pages、Influx DB 和 Grafana 或測試報告系統（TestRail、ReportPortal 等）中。 盡可能簡單地實現自動化和縮放——通過在 GitLab CI 項目中添加和參數化常用的 gitlab-ci.yml 模板。
這種方式的好處是整個CI基礎設施、負載代理、負載源的docker鏡像、測試流水線和報告發布都由一個集中的自動化部門（DevOps工程師）維護，負載測試工程師可以集中精力進行測試開發和分析他們的結果，而不處理基礎設施問題。
為了描述簡單，我們假設目標應用程序或被測服務器已經預先部署和配置（可以使用Python、SaltStack、Ansible等中的自動化腳本）。 然後，負載測試即服務的整個概念分為三個階段： 準備、測試、發布報告. 圖表的更多細節（所有圖片均可點擊）：
負載測試中的基本概念和定義
在進行負載測試時，我們盡量遵守 ，使用適當的術語和推薦的指標。 我將簡要列出負載測試中的主要概念和定義。
負載代理 - 將在其上啟動應用程序的虛擬機 - 加載源（Apache JMeter、Yandex.Tank 或自行編寫的加載模塊）。
測試目標（target） - 安裝在服務器上的服務器或應用程序將受到負載。
測試場景（測試用例） - 一組參數化步驟：用戶操作和對這些操作的預期反應，具有固定的網絡請求和響應，具體取決於指定的參數。
配置文件或加載計劃（配置文件） -在 （第 4.2.4 節，第 43 頁）負載配置文件定義了對特定測試至關重要的指標以及用於在測試期間更改負載參數的選項。 您可以在圖中看到配置文件示例。
測試 — 具有一組預定參數的腳本。
測試計劃（test-plan） - 一組測試和負載配置文件。
Testran（測試運行） - 使用完全執行的負載場景和收到的報告運行一項測試的一次迭代。
網絡請求（request） — 從代理髮送到目標的 HTTP 請求。
網絡響應（response） — 從目標發送到代理的 HTTP 響應。
HTTP 響應代碼（HTTP 響應狀態）——來自應用服務器的標準響應代碼。
事務是一個完整的請求-響應循環。 從開始發送請求（request）到接收到響應（response）完成，算一次事務。
交易狀態 - 是否有可能成功完成請求-響應週期。 如果在這個循環中有任何錯誤，那麼整個交易就被認為是不成功的。
響應時間（延遲） - 從發送請求（request）結束到開始接收響應（response）的時間。
負載指標 ——負載測試過程中確定的負載服務和負載代理的特性。
測量負載參數的基本指標
方法論中一些最常用和推薦的 （第 36、52 頁）指標如下表所示。 代理和目標的類似指標列在同一行。
負載代理的指標
在負載下測試的目標系統或應用程序的指標
數 虛擬CPU 和記憶 內存,
圓盤 - 負載代理的“鐵”特性
中央處理器, 內存，磁盤使用 - CPU、內存和磁盤加載的動態
在測試的過程中。 通常以百分比來衡量
最大可用值
網絡吞吐量 （加載代理）- 吞吐量
服務器上的網絡接口，
安裝負載代理的位置。
通常以每秒字節數 (bps) 為單位
網絡吞吐量(on target) - 網絡接口帶寬
在目標服務器上。 通常以每秒字節數 (bps) 為單位
虛擬用戶- 虛擬用戶的數量，
實施負載場景和
模仿真實的用戶操作
虛擬用戶狀態, Passed/Failed/Total — 成功和
虛擬用戶的不成功狀態
對於負載場景，以及它們的總數。
通常預期所有用戶都能夠完成
負載配置文件中指定的所有任務。
任何錯誤都意味著真實用戶將無法
解決您在使用系統時遇到的問題
每秒請求數（分鐘）- 每秒（或分鐘）的網絡請求數。
負載代理的一個重要特性是它可以生成多少請求。
其實這是模擬虛擬用戶訪問應用程序
每秒響應（分鐘）
- 每秒（或分鐘）的網絡響應數。
目標服務的一個重要特徵：多少
生成並發送對查詢的響應
裝載劑
HTTP 響應狀態— 不同響應代碼的數量
從負載代理接收的應用程序服務器。
比如200 OK表示調用成功，
和 404 - 未找到資源
潛伏 (響應時間) - 從結束開始的時間
在開始接收響應（response）之前發送一個請求（request）。
通常以毫秒 (ms) 為單位
交易響應時間— 一次完整交易的時間，
完成請求-響應週期。
這是從發送請求（request）開始的時間
直到完成接收響應（response）。
交易時間可以用秒（或分鐘）來衡量
在幾個方面：考慮最小值，
最大值、平均值，例如第 90 個百分位數。
最小和最大讀數是極端的
系統性能狀態。
第 XNUMX 個百分位數是最常用的，
正如它向大多數用戶展示的那樣，
在系統性能的閾值下舒適地運行
每秒事務數（分鐘） - 完成的數量
每秒事務數（分鐘），
也就是說，應用程序能夠接受多少以及
處理請求並發出響應。
其實這是系統的吞吐量
交易狀態 , 通過/失敗/總 - 數
成功、不成功和交易總數。
對於真實用戶不成功
交易實際上意味著
無法在負載下使用系統
負載測試示意圖
負載測試的概念非常簡單，由三個主要階段組成，我已經提到過： 準備測試報告，即為負載源準備測試目標和設置參數，然後執行負載測試，最後生成並發布測試報告。
原理圖註釋：
- QA.Tester是負載測試專家，
- Target 是您想要了解其在負載下的行為的目標應用程序。
圖中實體、階段和步驟的分類器
階段和步驟
發生了什麼
入口處有什麼
什麼是輸出
Prepare：測試準備階段
加載參數
設置和初始化
用戶
加載參數，
指標的選擇和
測試計劃準備
（負載配置文件）
自定義選項
負載代理初始化
測試計劃
測試目的
VM
雲部署
虛擬機與
要求的特徵
負載代理的 VM 設置
自動化腳本
虛擬機創建
虛擬機配置於
雲
環保
操作系統設置和準備
環境
負載代理工作
環境設置
負載代理
自動化腳本
環境設置
準備好的環境：
操作系統、服務和應用程序，
工作所需
負載代理
負載代理
安裝、配置和參數化
裝載劑。
或者從下載 docker 鏡像
預配置加載源
加載源 docker 鏡像
（YAT、JM或自寫框架）
設置
負載代理
設置並準備就緒
工作負載代理
測試：負載測試的執行階段。 源是部署在 GitLab CI 專用代理池中的負載代理
加載
啟動負載代理
與選定的測試計劃
和加載參數
用戶選項
用於初始化
負載代理
測試計劃
測試目的
執行日誌
負載測試
系統日誌
目標指標和負載代理的變化動態
運行代理
代理執行
大量測試腳本
按照
負載配置文件
加載代理交互
為了測試的目的
測試計劃
測試目的
日誌
收集“原始”日誌
在負載測試期間：
負載代理活動記錄，
測試目標的狀態
和運行代理的虛擬機
執行日誌
負載測試
系統日誌
指標
在測試期間收集“原始”指標
目標指標變化的動態
和負載代理
Report：測試報告準備階段
發電機
處理收集
加載系統和
監控系統“原始”
指標和日誌
報告的形成
人類可讀形式
可能與元素
分析師
執行日誌
負載測試
系統日誌
指標變化的動態
目標和加載代理
處理過的“原始”日誌
以適合的格式
上傳到外部存儲
靜態負載報告，
人類可讀的
發布
報告發表
關於負載
外部測試
服務
處理過的“原始”
以合適的格式記錄
用於卸載到外部
儲存庫
保存在外部
存儲報告
負載，適合
用於人體分析
在 CI 模板中連接加載源
讓我們繼續進行實際操作。 我想展示如何在公司的一些項目上 我們已經實現了負載測試即服務的概念。
首先，在我們的 DevOps 工程師的幫助下，我們在 GitLab CI 中創建了一個專用的代理池來運行負載測試。 為了不在模板中將它們與其他的混淆，例如程序集池，我們為這些代理添加了標籤， ： 加載。 您可以使用任何其他可理解的標籤。 他們問 GitLab CI 運行程序。
如何通過硬件找出所需的功率？ 負載代理的特性——足夠數量的 vCPU、RAM 和磁盤——可以根據代理上運行的 Docker、Python（對於 Yandex.Tank）、GitLab CI 代理、Java（對於 Apache JMeter）來計算. 對於 JMeter 下的 Java，還建議使用至少 512 MB 的 RAM，作為上限， .
因此，根據我們的經驗，我們建議為負載代理使用至少 4 個 vCPU、4 GB RAM、60 GB SSD。 網卡的吞吐量根據負載配置文件的要求確定。
我們主要使用兩個加載源——Apache JMeter 和 Yandex.Tank docker images。
是來自 Yandex 的用於負載測試的開源工具。 其模塊化架構基於 Phantom 的高性能異步基於命中的 HTTP 請求生成器。 tank通過SSH協議內置了對被測服務器資源的監控，可以在指定條件下自動停止測試，可以在控制台和圖形的形式顯示結果，可以連接你的模塊以擴展功能。 順便說一下，我們在 Tank 還不是主流的時候使用它。 在文章“» 您可以閱讀我們在 2013 年如何使用它進行負載測試的故事 是我們公司的產品之一。
是來自 Apache 的開源負載測試工具。 它同樣可以很好地用於測試靜態和動態 Web 應用程序。 JMeter 支持大量協議和與應用程序交互的方式：HTTP、HTTPS（Java、NodeJS、PHP、ASP.NET 等）、SOAP / REST Web 服務、FTP、TCP、LDAP、SMTP(S)、POP3( S) ) 和 IMAP(S)，通過 JDBC 的數據庫，可以執行 shell 命令並使用 Java 對象。 JMeter 有一個用於創建、調試和執行測試計劃的 IDE。 還有一個 CLI，用於在任何 Java 兼容操作系統（Linux、Windows、Mac OS X）上進行命令行操作。 該工具可以動態生成 HTML 測試報告。
為了便於在我們公司內部使用，為了測試人員自己更改和添加環境的能力，我們在 GitLab CI 上構建了負載源的 docker 圖像，並發佈到內部 . 這使得將它們連接到管道中以進行負載測試變得更快、更容易。 如何通過 GitLab CI 將 docker 推送到註冊表 - 請參閱 .
我們為 Yandex.Tank 使用了這個基本的 docker 文件：
Dockerfile
1 | FROM direvius/yandex-tank
2 | ENTRYPOINT [""]對於 Apache JMeter 這個：
Dockerfile
1 | FROM vmarrazzo/jmeter
2 | ENTRYPOINT [""]您可以在文章中閱讀我們的持續集成系統的工作原理““。
模板和管道
項目中提供了用於進行負載測試的模板示例 。 在 您可以閱讀使用模板的說明。 在模板本身（文件 ) 有關於每個步驟負責什麼的註釋。
該模板非常簡單，演示了上圖中描述的負載測試的三個階段：準備、測試和發布報告。 對此負責 : 準備、測試和報告.
- 階段 應該用於預配置測試目標或檢查它們的可用性。 加載源的環境不需要配置，它們被預先構建為docker鏡像並發佈在docker registry中：只需在測試階段指定所需的版本即可。 但是您可以重建它們並製作自己的修改圖像。
- 階段 用於指定加載源、運行測試和存儲測試工件。 您可以選擇任何加載源：Yandex.Tank、Apache JMeter、您自己的或全部。 要禁用不必要的來源，只需註釋掉或刪除作業即可。 負載源的入口點：
- Yandex.Tank 的啟動參數在 .,
- Apache JMeter 啟動參數在文件中指定 .
注意：程序集配置模板用於設置與 CI 系統的交互，並不意味著在其中放置測試邏輯。 對於測試，指定入口點，控制 bash 腳本所在的位置。 運行測試、生成報告和測試腳本本身的方法必須由 QA 工程師實施。 在演示中，對於兩個加載源，Yandex 主頁請求用作最簡單的測試。 腳本和測試參數在目錄中 .
- 在舞台上 您需要描述如何將在測試階段獲得的測試結果發佈到外部存儲，例如 GitLab Pages 或特殊報告系統。 GitLab Pages 要求 ./public 目錄是非空的，並且在測試完成後至少包含一個 index.html 文件。 您可以閱讀 GitLab Pages 服務的細微差別。 .
如何導出數據的示例：
- 從 JMeter 到 ,
- 從 Yandex.Tank 到 .
發佈設置說明：
- HTML 靜態 ,
- 到 InfluxDB，然後到 .
在演示示例中，具有負載測試和兩個負載源（您可以禁用不必要的）的管道如下所示：
Apache JMeter 本身可以生成 HTML 報告，因此使用標準工具將其保存在 GitLab Pages 中更有利可圖。 這是 Apache JMeter 報告的樣子：
在 Yandex.Tank 的演示示例中，您只會看到 在 GitLab Pages 部分。 在測試期間，Tank 可以將結果保存到 InfluxDB 數據庫中，然後可以從那裡顯示結果，例如在 Grafana 中（配置在文件中完成 ). 這就是 Tank 的報告在 Grafana 中的樣子：
總結
在文章中，我談到了“負載測試即服務”（load testing as a service）的概念。 主要思想是使用預先配置的負載代理池、負載源的 docker 圖像、報告系統和基於簡單的 .gitlab-ci.yml 模板（示例 ). 所有這些都由一小群自動化工程師支持，並應產品團隊的要求進行複制。 我希望這將有助於您在貴公司準備和實施類似的計劃。 感謝您的關注！
PS 我要非常感謝我的同事 Sergey Kurbanov 和 Nikolai Yusev，感謝他們在我們公司實施負載測試即服務概念方面提供的技術幫助。
作者: - 副手Positive Technologies 技術和開發流程 (DevOps) 主管
來源： www.habr.com