性能測試從零開始實施指南——流程篇

很久沒更博客了，最近忙着調整狀態、適應新環境各方面，學習方面大多都是零散的筆記，感受再不更新下，就真的要斷更了。有點理解寫做者的苦衷了，催更啊。。。。。。

因爲新公司業務快速發展帶來的流量突增以及技術負債各方面，性能的問題就開始急速冒頭，這點不少創業階段的中小型公司都存在該問題，表如今以下幾個方面：

一、技術負債累積過大

二、流程規範定義不清

三、崗位職責劃分模糊

四、QA建設幾乎爲零

快速發展的業務須要更好的技術支撐（這點在以前的博客：當咱們討論性能測試時，咱們在說什麼？已經討論過這個問題），然而現實倒是技術永遠慢業務需求一拍甚至好幾拍。

這篇博客，就最近我在新公司開始性能測試實施工做的總結以及我的的一些思考，來聊聊從零開始實施性能測試，要注意哪些方面。。。

 

1、制定目的

性能測試是一項嚴謹的須要各團隊協同配合的工做，其中包括產品、開發、運維、網絡、DBA、測試等角色。從零開始實施性能測試，而性能測試流程，是最重要的一步。

制定性能測試流程指南的目的，是從技術角度制定性能測試實施過程當中關鍵技術規範，更好的對系統進行性能測試，幫助性能測試人員更好地從技術上來規避系統上線後的風險、

評估線上系統的真實能力，根據業務模型摸底線上能力以提早應對，儘量減小系統上線後的性能風險帶來的損失。

 

2、適用範圍

對性能測試實施過程當中很是重要和關鍵的相關技術進行分析，主要包括：

系統環境、測試指標、業務模型、數據量級、測試模型、測試策略、測試腳本、被測場景、服務監控、瓶頸分析、優化驗證。

 

3、測試流程

按照業內目前的最佳實踐，性能測試的流程是很詳細的，分爲不少步驟。以下圖：

但考慮到從零開始實施的難度、公司所處的階段、研發部門技術建設以及上面提到的4點問題，在最開始時候，建議對其進行必定的精簡，緣由有以下幾點：

一、接受程度：流程越精簡，各團隊成員的接受性越快；

二、推進難度：精簡的流程易於更快速的推進以及調整；

三、快速產出：更快的產生反饋，性能測試產出更及時；

四、心理落差：期待值越低，落地的結果越容易被接受；

根據我的最近的實施心得以及一些思考，精簡後的性能測試流程以及對應階段的崗位職責，以下圖：

 

4、四大階段

大致來講，性能測試的流程可分爲如上四個階段，分別是需求階段、準備階段、實施階段以及結束。

一、需求階段

①、提出需求

性能測試必定是先有需求，才能夠決定要不要繼續執行。而性能需求的提出方，能夠是開發（以爲某個接口慢）、能夠是運維（對某個系統的服務能力進行容量評估）；

也能夠是測試人員（從需求評審中分析出某個需求須要進行性能測試來規避風險）、更能夠是產品（線上問題直接表現&用戶反饋）。

而上圖中項目負責人的角色不必定必須是崗位title意義上的PM角色，而是須要這麼一個角色來作好居中溝通、資源協調的工做。

②、需求評審

不通過評審的需求每每有不少坑！！！只有多方相關人員參與評審，從各自的角度給出意見，溝通達成一致，才能決定後續的要不要作？怎麼作？以及誰來作什麼事情！

③、需求調研

需求調研階段主要是對後續性能測試實施的一些必要信息進行更細緻的溝通和確認，以及在職責、工時、排期、交付時間這幾點上尋求平衡的可接受的點。

 

二、準備階段

①、環境準備

不管是功能測試仍是自動化或者性能測試，老是須要一個合適的環境來進行。

對性能測試來講，不管是環境選擇（生產or性能測試環境）仍是申請對應的資源（虛擬機&雲服務器&docker），通常都須要運維工程師來進行搭建配置。

②、應用部署

性能測試的被測應用必須是穩定的，沒有P2及以上缺陷或經過迴歸測試的版本包，根據每一個公司的職責定位不一樣，應用部署通常是開發進行部署，或開發提供對應的代碼路徑，運維進行拉取部署。

③、數據準備

性能測試對數據的要求是很高的，不管是數據量級、精準度抑或是數據的多樣性。通常分爲以下幾種數據類型：

鋪底數據：最多見的準備方式爲從生產拖庫最新的最完整的基礎數據來做爲性能測試所用；

測試數據：好比性能測試場景須要讀寫大量的數據，而爲了保證測試結果的準確性，通常經過從生產拉取同等量級或者至少將來一年的增加量級的脫敏數據；

參數化數據：不一樣類型的數據處理邏輯有差別時，須要經過測試數據的多樣化來提升性能測試代碼的覆蓋率，而參數化是最多見的方式；

④、腳本開發

性能測試腳本須要針對業務模型轉化後的測試模型以及採用的測試策略進行鍼對性的開發調試試運行。

 

三、實施階段

完成準備階段的工做，就開始開展性能壓測了（有時候須要進行壓測預熱），這也是不少對性能測試不太瞭解的同窗對性能測試的認知（錄製腳本→無腦高併發）。

①、壓測執行

性能測試執行階段，是須要執行不少輪次，且測試腳本也須要不斷地調整修改，根據測試結果不斷改進的，這樣才能獲得更爲準確的測試結果。

②、服務監控

這個階段稱之爲APM（Application Performance Management：對應用程序性能和可用性的監控管理）更合適。

狹義上的APM單指應用程序的監控，如應用的各接口性能和錯誤監控，分佈式調用鏈路跟蹤，以及其餘各種用於診斷(內存，線程等)的監控信息等。

廣義上的APM, 除了應用層的監控意外，還包括App端監控、頁面端監控、容器、服務器監控，以及其餘平臺組件如中間件容器、數據庫等層面的監控。

③、瓶頸定位

進行性能測試的目的，就是爲了探測系統是否存在影響提供正常服務的性能瓶頸以及爲上線提供容量評估。

若是系統性能表現未到達預期指標，則須要對日誌、監控數據進行分析，定位其性能瓶頸並針對性的進行優化才能夠。

④、優化驗證

發現性能瓶頸並修改優化後，須要再次執行壓測，以驗證問題是否獲得解決以及性能的提高能力，衡量的標準是需求評審和調研階段肯定的業務性能指標。

 

四、結束階段

性能測試結束的標誌，通常包括以下以下幾點：

涉及的測試場景均已測試完畢、測試過程當中發現的問題已所有修復驗證、測試結果達到了預期的性能指標、知足上線要求。

①、測試報告

在知足上面4個條件後，最好是出具一份簡潔可是明確的測試報告，說明本次性能測試的目的、範圍、環境信息、測試結果、問題，並給出測試結論。

測試報告的方式能夠是文檔、郵件、一個HTML頁面等方式，但這個環節必定不能省略！！！

②、報告評審

最好是讓參與本次性能測試各環節工做的各個角色都參與進行評審，你們對結果無異議，便可視爲本次性能測試結束。

 

以上即爲性能測試從零開始實施的我的總結，若有更好的建議，請及時指出，內容僅供參考。。。