1. 程式人生 > 其它 >效能測試從零開始實施指南——測試報告篇(轉)

效能測試從零開始實施指南——測試報告篇(轉)

效能測試的目的,是通過模擬真實的業務場景和海量的使用者請求及資料對業務系統進行多種場景的測試,來驗證各個服務的效能表現是否滿足實際的業務需要。

長期來看,效能測試最終的目標是為生產環境容量規劃提供可靠地參考資料,使生產服務的可用性、擴充套件性和穩定性更高,讓技術更好的服務業務,創造更多的價值

從整個效能測試的生命週期來說,測試報告的產出就意味著一次完整效能測試專案的結束。那麼,怎樣的測試報告,才是真正具有價值的呢?

這篇部落格,聊聊一份完善且具有價值的效能測試報告,都包含哪些內容。。。

關鍵詞:資訊完善,簡潔明瞭,有圖有資料有結論!!!即讓每一個業務服務能夠清晰地知道:

單機水位是多少、滿足業務需求要上多少機器、什麼時候該加機器、什麼時候應該減機器。雙11等大促場景需要準備多少機器,既能保障系統擴充套件性和穩定性,又能節約成本。

一份完善且具有價值的效能測試報告,主要包含如下幾個方面:

一、測試背景

首先要闡述本次效能測試的背景,即被測系統型別,面向哪些使用者,具備什麼特點,為什麼要進行效能測試,預期的一些指標等等。

比如:為了保證“雙十一”大促期間,系統能穩定執行且保障業務的高可用,進行效能測試。

核心:評估系統性能、分析效能變化趨勢、定位系統瓶頸風險、協助規劃系統容量。

二、測試目的

測試的目的要根據測試背景來分析設定,比如:

1、線上服務由於流量過高某部分應用掛了,那測試目的就是:定位瓶頸、分析調優驗證;

2、運營做了拉新和新的渠道拓展,那測試目的就是:評估系統性能是否滿足新的線上業務;

3、系統架構由叢集技改為微服務,那測試目的就是:驗證穩定性、可用性、單例項容量,為線上服務擴容提供容量規劃資料;

三、測試範圍

比如,梳理出測試的業務域、場景、對應的服務:

業務歸屬模組 業務涉及場景 對應服務
訂單 建立訂單 order-service
取消訂單
購物車 新增購物車
刪除購物車
商品 商品列表 product-service
商品詳情
支付 餘額支付 payment-service
支付寶支付
微信支付

或者,以思維導圖的形式進行說明也可以,如下圖:

四、預期指標

這裡的效能指標包含如下兩項:

①、業務效能指標

即預期的TPS、RT、99%RT、請求成功率(一般預設請求成功率≥99.99%)。

②、硬體效能指標

即服務端資源耗用指標(也稱為水位),常規的資源監控指標有:CPU使用率、Memory使用率、系統IO、網路IO等。

③、應用流量指標

比如:核心業務鏈路的QPS、Redis的命中率、DB的峰值QPS等數值。

五、實施說明

實施說明主要包含如下兩項:

1、環境配置

服務名稱 數量 配置 備註
gateway server 5 4C8G 閘道器服務,身份驗證和請求轉發
web server 2 4C8G
app server 2 8C8G
Redis 2 12G 哨兵模式,一主一從
DB 2 8C16G 一主一從

2、測試策略

本次效能測試所採用的測試策略,比如:

探測系統性能拐點,需要階梯式壓測;

探測系統在可接受的效能指標下最大的處理能力,需要採用負載、容量測試策略;

驗證系統的穩定性和高可用,需要採用穩定性、高可用測試策略;

驗證系統在不同配置下的效能表現,一般採用配置測試策略;

六、測試結果

測試結果展示,依據具體的測試範圍、目的來選擇性展示。展示的方式可以是多種形式,最常見的是圖表型別。

舉個例子:單鏈路基準的場景,一般只需要以表格形式羅列出測試結果即可,做個記錄。全鏈路壓測,可以用相對具體的圖表來提現測試的結果。

但最重要的,還是結論!以及最終在線上環境所展現的價值。

demo1:表格統計

demo2:圖形化展示

PS:報告中具體貼多少的圖表,以公司實際的流程和技術文化為準。比如銀行金融業就比較重視,網際網路企業,一般只需要核心的資料證明即可。

七、階段進度

這裡主要指的是從需求階段到結束,各個階段的工作進展以及資源安排,建議採用看板的方式,及時更新進度,方便推進工作的開展。示例如下:

階段

事項

開始時間

結束時間

狀態

責任人

需求階段

需求評審

完成

多方參與

系統架構圖

完成

開發

需求調研

完成

效能測試人員

準備階段

環境交付

完成

運維、開發

應用部署

完成

運維、開發

資料準備

完成

開發、DBA、測試

指令碼開發

完成

效能測試人員

實施階段

執行壓測

未完成

效能測試人員

服務監控

未完成

運維、測試

資料收集

未完成

效能測試人員

結束

報告評審

未完成

多方評審

八、問題記錄

壓測過程中的問題進行記錄彙報,也是很有必要的,測試同學懂得都懂。。。下面是一個示例的問題記錄表格,請參考。

九、測試結論

還記得本篇文章最開始是怎麼說的麼?效能測試的最終目的是,讓每一個業務服務能夠清晰地知道:

單機水位是多少、滿足業務需求要上多少機器、什麼時候該加機器、什麼時候應該減機器。雙11等大促場景需要準備多少機器,既能保障系統擴充套件性和穩定性,又能節約成本。

下面是一個比較萬金油的描述,具體的結論還需要根據具體的壓測需求和場景來描述:

本次效能測試在效能測試環境進行,所有涉及場景已測試完畢;測試過程中發現的缺陷已全部修復並驗證通過。

A-service服務在水位為50%時最大TPS為200,業務預期指標為2000TPS,生產環境現有同等配置伺服器8臺。

為滿足本次活動的營銷增長需要,線上建議部署12臺機器(10臺正常提供服務,2臺留作buffer)經過評估,當前效能表現滿足預期效能指標,達到上線要求。

本次效能測試通過。

轉自https://www.cnblogs.com/imyalost/p/10993600.html

本文來自部落格園,作者:up~up,轉載請註明原文連結:https://www.cnblogs.com/soft-engineer/p/15387064.html