項目背景：機器人調度平台
迭代背景：敏捷開發
記錄方向：mqtt壓測
記錄時間：20211009
===================================================
生產環境上線后，前期主要關注的是功能正確，非功能性的測試內容沒有過多關注，生產環境上線一段時候后，領導要求進行相關的性能測試。這里記錄一下編寫測試計划及重點測試問題（主要是rabbitmq方面）的處理處理過程；
=====================================性能測試計划=====================================
性能測試計划——10萬+設備並發
一、前言... 1
二、准備工作... 1
2.1、系統基本功能驗證... 1
2.2、測試團隊組建... 1
2.3、工具選擇... 2
2.4、預先業務場景分析... 2
三、測試計划... 2
3.1、性能測試項目相關信息... 2
3.2、測試環境准備... 3
3.2.1、UAT和PRO對比... 3
3.3、性能場景分析及業務建模... 3
3.4、確定性能指標... 3
3.5、測試腳本開發... 4
四、測試實施... 4
4.1、測試環境確認... 4
4.2、執行測試腳本... 4
4.3、記錄測試結果... 4
4.4、階段進度統計... 4
五、測試分析... 4
5.1、測試環境的系統性能分析... 4
5.2、硬件設備對系統性能表現的影響因素... 4
5.3、其他影響因素分析... 4
5.4、測試中發現的問題... 4
5.5、測試后續跟蹤... 4
一、前言
現在MARS系統基本的功能已經穩定，且后端框架基本定型，是時候來一個全身體檢了。領導提出MARS系統必須支持10萬+的設備並發的模糊需求，沒有明確的各種系統資源水位，響應時間等具體指標，也沒有明確前段的用戶並發。現在根據該模糊需求制定一個比較籠統大概的性能測試計划，只針對本次的性能測試需求，系統支持10萬+的並發；
二、准備工作
2.1、系統基本功能驗證
現在MARS系統已上生產環境，已經開始接入設備，設備信息上報、告警、設備控制已經打通，功能驗證已經通過，整個服務端框架已經定型，可以進行性能測試中容量測試、配置測試。
2.2、測試團隊組建
整個性能測試活動中的人員組成，需要各組成成員。在本次性能測試項目中項目負責人與產品為同一人，運維和DBA為同一人。
2.3、工具選擇
常規的性能測試工具主要有jmeter、loadrunner等，根據本次的性能需求主要是通過mqtt發布訂閱操作來進行模擬設備上進行發布、訂閱消息。經過調研，jmeter有相關mqtt協議的開源插件，但是插件效果不是很適用且有bug，所以直接采用python+第三方mqtt庫來模擬完成設備的發布訂閱操作。
2.4、預先業務場景分析
本次的性能需求為支持10萬+的設備並發，根據I型機器人與平台的通訊協議（I型機器人的通訊協議比較全，就暫時按照I型的協議進行羅列），主要有以下幾個方面的發布、訂閱協議：設備登錄認證、屬性上報、組織下發協議、地圖交互協議、作業交互協議、告警協議、初始化定位等協議。
截止目前接入****系統的機器人主要有以下幾款協議：*****。
下表為不同機器人類型功能交互場景列舉截圖，具體的交互協議如下附件，****系統與機器人的交互協議主要為mqtt通訊，有少量的https接口。現在
三、測試計划
3.1、性能測試項目相關信息
| 序號 |
信息類型 |
說明 |
| 1 |
項目名稱 |
***** |
| 2 |
項目類型 |
新建 |
| 3 |
項目背景 |
整體功能已經穩定，后端端架基本定型，已上生產環境 |
| 4 |
測試目的 |
容量測試、配置測試、負載測試、壓力測試、性能驗證 |
| 5 |
測試范圍 |
mqtt broker、各服務在10萬+並發下業務處理能力 |
| 6 |
里程碑 |
測試計划、環境准備、測試實施、性能優化 |
| 7 |
影響因素 |
測試環境確定為UAt環境，測試環境與生產環境的配置不一致，無法准確評估生產環境的水位容量、沒有具體的性能指標，指標是否通過無法明確界定 |
3.2、測試環境准備
現目前MARS系統的環境有：DEV、SIT、UAT、PRO四個環境，生產環境已經上線開始運行，已經有部分設備接入到生產環境中，不能直接用來作為性能測試的環境，有業務因素，也有技術不支持的因素。生產環境的壓測是需要進行進行請求流量區分、影子庫區分。所以確定使用最接近生產環境的UAT環境來進行性能測試。
3.2.1、UAT和PRO對比
現在UAT環境的各個服務的副本都是沒有進行資源限定的如CPU、內存、帶寬、磁盤大小、緩存等，也無法知曉生產環境的各服務的資源配置，無法對UAT和PRO環境的資源配置及服務部署形成有效的對比。找運維確認過，PRO環境的系統資源配置是比UAT環境的配置要高，且PRO環境各個服務所開的副本數量是比UAT環境的副本要多。所以暫時就不在這兒邏輯性能測試環境與PRO環境的具體差異，直接簡單粗暴的使用UAT環境進行測試。
3.3、性能場景分析及業務建模
本次性能測試場景為10萬+設備並發，根據此場景羅列出本次測試的核心業務場景。
根據上文的MARs系統的接入設備類型及設備占比進行統計得出每種接入的設備業務並發
| 10萬+設備占比情況 |
||||
| 序號 |
設備類型 |
接入占比 |
並發數量 |
備注 |
| 1 |
***** |
10% |
10000 |
|
| 2 |
***** |
40% |
40000 |
|
| 3 |
***** |
35% |
35000 |
|
| 4 |
***** |
10% |
10000 |
|
| 5 |
***** |
5% |
5000 |
|
| 合計 |
100% |
100000 |
|
|
根據接入設備的實際占比情況及接入設備的通信協議開發測試腳本。
3.4、確定性能指標
3.5、測試腳本開發
四、測試實施
4.1、測試環境確認
性能測試確定為UAT環境，UAT環境配置如下。
4.2、執行測試腳本
4.3、記錄測試結果
4.4、階段進度統計
五、測試分析
5.1、測試環境的系統性能分析
5.2、硬件設備對系統性能表現的影響因素
5.3、其他影響因素分析
5.4、測試中發現的問題
5.5、測試后續跟蹤
==========================性能測試過程中重點問題分析====================================
主要記錄一下rabbitmq方面的問題，消息重復消費問題暫未發現，在前期編碼的時候進行過重復消費異常做過相應處理；
1、rabbitmq集群在壓測時所有的壓力都堆積到一個node節點中；
分析：后續經過分析，運維人員配置rabbitmq的配置出現問題，重新修改配置后各個節點負載均衡；
2、通過模擬大量設備並發推送消息時有丟包現象；
分析：
原因1、mqtt broker接收到機器人推送的消息后發布到MQ發布失敗，MQ內存超過限制，導致觸發報警，報警解除前不允許新的發布
措施：增加MQ內存
原因2、消息者消費消息過慢，MQ宏消息堆積過多，導致消息堆積阻塞。消息堆積阻塞的本質就是生產消息速率大於消費消息速率，導致生產的消息大量堆積在隊列中
措施：增加消費者數、提高消費者並發從而提高消費速率、提高消費者的預取文件數。