性能測試---流程篇

一、制定目的

• 性能測試是一項嚴謹的、需要各團隊協同配合的工作，其中包括產品、開發、運維、網絡、DBA、測試等角色。從零開始實施性能測試，性能測試流程，是其中最重要的一步。
• 制定性能測試流程指南的目的：是從技術角度制定性能測試實施過程中的關鍵技術規范，更好的對系統進行性能測試，幫助性能測試人員更好地從技術上來規避系統上線后的風險、評估線上系統的真實能力，根據業務模型摸底線上能力以提前應對，盡可能減少系統上線后的性能風險帶來的損失。

二、適用范圍

• 對性能測試實施過程中非常重要和關鍵的相關技術進行分析，主要包括：系統環境、測試指標、業務模型、數據量級、測試模型、測試策略、測試腳本、被測場景、服務監控、瓶頸分析、優化驗證。

三、測試流程

• 按照業內目前的最佳實踐，性能測試的流程是很詳細的，分為很多步驟。如下圖：
  
• 但考慮到最開始實施的難度、公司所處的階段、研發部門技術建設，建議對其進行一定的精簡，原因有如下幾點：
  • 接受程度：流程越精簡，各團隊成員的接受性越快；
  • 推動難度：精簡的流程易於更快速的推動以及調整；
  • 快速產出：更快的產生反饋，性能測試產出更及時；
  • 心理落差：期待值越低，落地的結果越容易被接受。
• 根據個人的實施心得以及一些思考，精簡后的性能測試流程以及對應階段的崗位職責，如下圖：
  

四、四大階段

• 大體來說，性能測試的流程可分為如上四個階段，分別是需求階段、准備階段、實施階段以及結束。

1、需求階段

• 在需求階段，我們需要明確以下幾個點：
  • 明確倒底需不需要做性能測試？他的目的是什么？
  • 明確被測系統是什么？被測試系統的相關技術信息有哪些？
  • 明確被測系統的基本業務、關鍵業務和用戶行為
  • 明確性能測試點是什么？都有哪些需要測試，為什么？哪些不需要測試，為什么？
  • 明確被測系統未來的業務拓展規划以及性能需求
  • 明確性能測試策略，即應該怎么測試？
  • 明確性能測試的指標，知道測試出來的結果怎么算通過？

①、提出需求

• 性能測試一定是先有需求，才可以決定要不要繼續執行。而性能需求的提出方，可以是開發（覺得某個接口慢）、可以是運維（對某個系統的服務能力進行容量評估）；
  也可以是測試人員（從需求評審中分析出某個需求需要進行性能測試來規避風險）、更可以是產品（線上問題直接表現&用戶反饋）。
• 而上圖中項目負責人的角色不一定必須是崗位意義上的PM角色，而是需要這么一個角色來做好居中溝通、資源協調的工作。

②、需求調研

• 需求調研階段主要是對后續性能測試實施的一些必要信息進行更細致的溝通和確認。
• 需求調研可以從以下幾個方面入手：
  • 1、系統信息調研
    • 對被測試系統進行分析，需要對被測系統，有全面的了解和認識，這是做好性能測試的前置條件。
    • 並且在后續進行性能分析和調優時，將會有很大用處，如果連系統的架構、協議都不了解，我們如何進行准確的性能測試？如何進行性能分析與調優？
    • 注：pv訪問量（Page View），即頁面訪問量，每打開一次頁面，PV數+1，刷新頁面也是。UV訪問數（Unique Visitor）指獨立訪客訪問數，一台電腦終端即為一個訪客。
      
  • 2、業務信息調研
    • 指對被測試的業務進行分析，通過對業務的分析和了解，方便我們后續進行性能測試場景的確定以及性能測試指標的確定。
      
  • 3、性能需求評估
    • 在執行性能測試前，要對被測系統做對應的評估，主要目的為明確系統是否有必要做性能測試。
    • 如果確定要做，需要確定性能測試點和指標：明確該測什么？性能指標是多少？測試通過與否的標准？
    • 性能指標會根據情況評估，要求被測系統能滿足將來一定時間段的業務壓力。
    • 判斷是否進行性能測試主要從下面兩個方面進行思考：
      • 業務角度：系統是公司內部 or 對外？系統使用的人數的多少？
      • 系統角度：系統又可以從以下3個方面進行分析，a）系統架構；b）數據庫要求；c）系統特殊要求。
  • 4、確定性能測試點
    • 在上面第3點中，我們簡單分析了如何確定一個系統是否需要做性能測試。下面簡單總結下如果一個系統確定要做性能測試，我們如何確定被測系統的性能測試點？
      • 我們可以從下面幾個方面進行分析：
        • 關鍵業務：確定被測項目是否屬於關鍵業務，具體有哪些主要業務邏輯點，重點關注與交易相關的功能點。如果項目不屬於關鍵業務，則可轉入下面。
        • 日請求量：確定被測項目中，各功能點的日請求量，如果日請求量較高，系統壓力大，而且又是關鍵業務，則該項目需要做性能測試。而關鍵業務點，可以被確定為性能點。
        • 邏輯復雜度：判斷項目各功能點的邏輯復雜程度。如果一個主要業務的日請求量不高，但邏輯很復雜，則也要通過性能測試。因為在分布式方式的調用中，當某一個環節響應較慢，就會影響到其它環節，造成雪崩效應。
        • 運營推廣活動：根據運營的推廣計划，來判斷待測系統未來的壓力。降低運營過程中的風險，是性能測試的主要目標。
      • 以上四個方面，相輔相成、環環相扣。在實際工作中應該具體問題具體分析。
  • 5、確定性能指標
    • 性能需求分析一個很重要的目標就是需要確定后期性能分析用的性能指標，性能指標有很多，可以根據具體項目選取和設定，而具體的指標值則需要根據業務特點進行設定。

③、需求評審

• 不經過評審的需求往往有很多坑！！！只有多方相關人員參與評審，從各自的角度給出意見，溝通達成一致，才能決定后續的要不要做？怎么做？以及誰來做什么事情！在職責、工時、排期、交付時間這幾點上尋求平衡的可接受的點。

2、准備階段

①、環境准備

• 無論是功能測試還是自動化測試或者性能測試，總是需要一個合適的環境來進行。對性能測試來說，無論是環境選擇（生產or性能測試環境）還是申請對應的資源（虛擬機&雲服務器&docker），一般都需要運維工程師來進行搭建配置，或者運維工程師和性能測試工程師配合搭建。
• 需准備的環境一般有以下兩個：
  • 系統運行環境：
    • 這個通常就是我們的測試環境，有些時候需求比較多，做性能測試擔心把環境搞跨了影響其它的功能測試，可能需要重新搭建一套專門用來做性能測試的環境。
  • 執行機環境：
    • 這個就是用來生成負載的執行機，通常需要在物理機上運行，而物理機又是稀缺資源，所以我們每次做性能測試都需要提前准備好執行機環境。

②、應用部署

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

③、數據准備

• 測試場景設計
  • 根據性能需求分析，設計符合用戶習慣的場景，場景設計的好壞，直接影響到性能測試效果。
• 性能測試對數據的要求是很高的，無論是數據量級、精准度抑或是數據的多樣性。一般分為如下幾種數據類型：
  • 鋪底數據：最常見的准備方式為從生產拖庫最新的最完整的基礎數據來作為性能測試所用；
  • 測試數據：比如性能測試場景需要讀寫大量的數據，而為了保證測試結果的准確性，一般通過從生產拉取同等量級或者至少未來一年的增長量級的脫敏數據；
  • 參數化數據：不同類型的數據處理邏輯有差異時，需要通過測試數據的多樣化來提高性能測試代碼的覆蓋率，而參數化是最常見的方式。
• 性能工具准備
  • 負載工具：
    • 根據需求分析和系統特點選擇合適的負載工具，比如LR、Jmeter等
  • 監控工具：
    • 准備性能測試時的服務器資源、JVM、數據庫監控工具，比如nmon等，以便進行后續的性能測試分析與調優。

④、腳本開發

• 性能測試腳本需要針對業務模型轉化后的測試模型以及采用的測試策略進行針對性的開發調試試運行。

3、實施階段

• 完成准備階段的工作，就開始開展性能壓測了（有時候需要進行壓測預熱）

①、壓測執行

• 性能測試執行階段，是需要執行很多輪次，且測試腳本也需要不斷地調整修改，根據測試結果不斷改進的，這樣才能得到更為准確的測試結果。

②、服務監控

• 這個階段稱之為APM（Application Performance Management：對應用程序性能和可用性的監控管理）更合適。
• 狹義上的APM單指應用程序的監控，如應用的各接口性能和錯誤監控，分布式調用鏈路跟蹤，以及其他各類用於診斷(內存，線程等)的監控信息等。
• 廣義上的APM, 除了應用層的監控意外，還包括App端監控、頁面端監控、容器、服務器監控，以及其他平台組件如中間件容器、數據庫等層面的監控。

③、瓶頸定位

• 進行性能測試的目的，就是為了探測系統是否存在影響提供正常服務的性能瓶頸以及為上線提供容量評估。
• 如果系統性能表現未到達預期指標，則需要對日志、監控數據進行分析，定位其性能瓶頸並針對性的進行優化才可以。

④、優化驗證

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

4、結束階段

• 性能測試結束的標志，一般包括如下如下幾點：
  • 涉及的測試場景均已測試完畢；
  • 測試過程中發現的問題已全部修復驗證；
  • 測試結果達到了預期的性能指標、滿足上線要求。

①、測試報告

• 在滿足上面4個條件后，最好是出具一份簡潔但是明確的測試報告，性能測試報告中，需要對性能測試目標、性能測試環境、性能測試數據構造規則、性能測試策略、性能測試結果、性能測試調優說明、性能測試過程中，遇到的問題和解決辦法等進行說明，並給出測試結論。（測試報告的方式可以是文檔、郵件、一個HTML頁面等方式）

②、報告評審

• 最好是讓參與本次性能測試各環節工作的各個角色都參與進行評審，大家對結果無異議，即可視為本次性能測試結束。
• 評審通過后，性能測試工程師，要將測試結果進行備案，並做為下次性能測試的基線標准。
  • 具體包括：性能測試結果數據、性能測試瓶頸和調優方案等。
  • 同時還需要將測試過程中，遇到的問題，包括：代碼瓶頸、配置項問題、數據問題和溝通問題，以及相應的解決辦法或方案，進行知識沉淀。