幹貨｜一次完整的性能測試，測試人員需要做什麼？

一.流程概述

• 1.規範流程的意義

規範的性能測試實施流程能夠加強測試工作流程控制，明确性能測試各階段應完成的工作，指導測試人員正确、有序的開展性能測試工作，提高各角色在性能能測試中的工作效率。本次分享的性能測試實施流程是性能測試開展的”指導方針”，希望幫助您可以早日成為性能測試”達人”。

• 2.具體的流程

  性能測試流程分為五個階段，分别是【需求調研階段】→【測試準備階段】→【測試執行階段】→【測試報告階段】→【測試總結階段】。

  

二. 需求調研

1.需求調研

需求調研工作由性能測試實施人員牽頭負責，産品經理、開發工程師、運維工程師配合完成；需求調研的主要内容為：

• 1.1 系統線上環境的性能需求

  例如性能需求、可靠性需求、可維護性需求等；

• 1.2 與系統性能需求相關的其它資訊

  包括系統資訊（如線上環境硬體、參數配置、系統架構與部署方式、關聯系統部署等）、業務資訊（關鍵業務邏輯與處理流程、交易清單、交易量資訊、業務分布規律等）、生産問題、文檔資料等方面，并對收集到的資訊進行彙總整理，實作對待測系統業務與技術的整體了解；

• 1.3 需求彙總

  開發項目組、需求部門、運維部門等測試任務提出方應填寫《雲智慧_XXX系統_XXX子產品性能測試需求表》中的“任務資訊”和“測試背景”等資訊，提出的測試需求,簡單文字不能說明的，可附加檔案。

2.需求分析

需求分析的基本流程是：

• 首先，由性能測試工程師根據需求調研所擷取的資訊進行分析，将《雲智慧_XXX系統_XXX子產品性能測試需求表》中的性能需求轉換為具體的性能需求名額值；
• 其次，根據測試環境與線上環境的差異分析，由性能測試工程師将線上環境條件下的性能需求名額值轉換為本次測試環境條件下的性能需求名額值

例如：

• TPS（Transaction per Second）： 系統每秒處理交易數，推導過程如下，目前線上APP1.0試用系統主要為查詢類交易，交易占比40%，系統生産交易量統計為1個月約20W筆，假設APP2.0系統上線後業務量激增到每日查詢類20W，則每日總交易量T達到:T = 20W/40%=500000筆/日
• 系統處理能力TPS推導： APP2.0上線後交易量最大500000筆/日,系統晚間幾乎無交易量，按2:8原則推算,則(50000080%)/(820%3600)=69.4筆/秒，取整為70筆/秒，每年按業務量增長50%計算，則一年後系統處理能力名額約等于70+7050%=105筆/秒。
• 穩定性交易量推導: 取系統處理能力的60%時長=105筆/秒60%83600=1814400筆。經過分析後彙總成測試名額值

  

Ø 需求分析其主要内容和規範性要求如下：

• 性能測試需求：應準确描述性能測試名額項及需求名額值。
• 系統範圍：應準确描述性能測試需求名額值所依托的測試範圍資訊，如應描述測試範圍的關聯系統邏輯示意圖，及各關聯系統的資訊；在對系統局部環節進行測試時，也需闡明具體測試範圍，較長的描述被測系統的相關子系統。
• 環境差異分析：應準确描述性能測試需求名額值所依托的測試環境資訊，如須描述測試環境的總體網絡拓撲結構圖、測試環境機器配置表（數量、型号、資源、作業系統）、以及相應的軟體配置、重要參數配置等。同時應準确描述線上環境的上述資訊，并進行詳細的環境差異性分析。

3.模型建構，場景設計

業務類型：

根據200X年XX月XX日~200X年XX月XX日期間的業務高峰日200X年XX月XX日的業務量統計，經過略微調整得出以下業務模型，要求業務模型交易至少占線上交易量的90%以上：

三.測試準備階段

測試準備階段是性能測試工作中重要階段。在準備階段，需要完成業務模型到測試模型的建構、性能測試實施方案編寫、測試環境的準備、性能測試案例設計、性能測試監控方案設計、性能測試腳本，及相關測試資料的準備，并在上述相關準備活動結束後按照測試計劃進行準入檢查。

重點關注：測試模型建構、方案設計、案例設計、資料準備等

1.測試模型（場景）建構

在需求分析的基礎上，對調研收集到的相關資料與資訊進行分析梳理，重點分析跨系統的交易路徑、交易關聯關系、資料的處理與流轉、業務量、交易比例、典型交易，以及系統的處理能力等性能測試點，針對性地确定多個業務場景，并為每個場景選擇一套具體的業務交易集，按照業務量比例建構相應的測試模型。通過分析得出本次測試模型有3個：一般交易日日間模型、國債發行日模型、以及曆史查詢交易模型。

• 一般交易日日間模型：

• 儲蓄國債交易模型：

  

  -曆史查詢交易模型：

  

  2.方案設計

  性能測試實施方案編制是性能測試工作中必須的工作環節，其産出為《性能測試方案》，如：《雲智慧_XXX項目_XXX功能子產品_性能能測試方案V1.0.xlsb》。

  在方案中需要描述：測試需求、啟停準則、測試模型設計、測試政策、測試内容、測試環境與工具需求，以及各個階段的輸出文檔。在方案中還需說明性能測試工作的時間計劃安排、預期的風險與風險規避方法等。測試模型設計内容來自本階段測試模型設計中形成的測試場景，以及場景中典型交易及所占比率。

3.案例準備

在案例設計中，包括案例的描述、測試環境描述（硬體、軟體、應用版本、測試資料）、延遲設定、壓力場景、執行描述、預期結果、監控要點。

案例設計是性能測試工作的必須工作環節，案例設計的産出檔案是《性能測試案例》

4.資料準備

環境準備工作中涉及到基礎資料的準備。測試資料的數量、邏輯關系要求十分嚴格，測試基礎資料的準備一般采用自造模拟資料或者使用脫敏後的線上資料

5.測試腳本開發

測試腳本開發的一般步驟如下：

Ø 通過錄制，或者編寫，完成腳本代碼生成。代碼生成時，主要根據需求插入事務，作為測試過程中統計交易響應時間的機關；

Ø 根據測試需求，進行參數化設定；

Ø 設定檢查點，根據封包内容字段判斷交易是否正确執行，即檢查點的設定在應用層面；

Ø 根據測試要求确定是否設定集合點；

四.測試執行階段

測試執行階段是執行測試案例，獲得系統處理能力名額資料，發現性能測試缺陷的階段。測試執行期間，借助測試工具執行測試場景或測試腳本，同時配合各類監控工具。執行結束後統一收集各種結果資料進行分析。根據需要，執行階段可進行系統的調優和回歸測試。

重點關注：結果記錄、測試監控、結果分析

1.測試執行及結果記錄

測試執行過程有相應的優先級政策，依據測試案例的優先級别，優先執行級别較高的測試案例。測試過程中，通過對每個測試結果的分析來決定是重複執行目前案例還是執行新的測試案例；通常發現瓶頸問題會立即進行調整并重新執行測試用例，直到目前的案例通過。

在執行階段，測試的執行、分析調優、回歸測試工作較為反複，須認真記錄全部執行過程和執行結果，執行結果資料是分析瓶頸的主要依據。

2.測試監控

測試的監控工作與執行工作同步進行，場景或腳本開始執行時，同時啟動監控程式（可以用nmon或者系統指令top/vmstat/iostat 等），當然也可以用雲智慧的監控寶和透視寶協同工作，監控寶可以監控網站／網頁性能／Ping/DNS/FTP/UDP/TCP/SMTP等IT基礎設施的性能名額，透視寶可以發現主機資源、Web應用、浏覽器、APP等應用的性能瓶頸，如下圖所示：

監控寶監控頁面：

3.測試結果分析

測試過程中根據前端性能測試工具顯示結果、監控結果綜合分析出現的測試問題。

五.測試報告階段

測試執行工作結束後開始撰寫性能測試報告。性能測試報告在釋出前需要進行評審

1.報告撰寫

性能測試報告要内容包括：測試目的、範圍及方法、環境描述、測試結果描述、結果分析、結論和建議等。

2.測試結果描述

測試結果的描述，應展現性能測試的執行過程，如：混合場景的容量測試結果展示中，需要描述各個并發梯度下測試結果及監控結果；在數字形式的結果記錄中，要求小數點後精确3位有效數字。

3測試缺陷與問題

在性能測試分析報告中須描述測試過程發現的缺陷與問題，對于确認是測試缺陷的項進行風險評估，并給出風險提示。

4.最終結果分析

測試最終結果的分析，該部分内容應該全面、透徹、易了解且通過圖表方式表達更直覺：

5.測試結論

測試結論是性能測試分析報告必須包括的内容。測試的結論須清晰、準确回答性能測試需求中描述的各項名額，需全面覆寫測試需求。

六.測試總結階段

性能測試的總結工作，主要對該任務的測試過程和測試技術進行總結。性能測試工作進入總結階段，也意味着性能測試工作臨近結束。在這個階段，時間允許的情況下應将所有的重要測試資産進行歸檔儲存。