一、 規範性能測試實施流程的意義

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

二、 效能測試實施流程

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

每個階段做什麼事情？重點關注什麼？

1.需求調研階段

1.1. 階段概述

調研階段的主要工作為：組建工作小組、專案建立、需求分析、模型構建、定製效能測試詳細實施計劃。

重點關注：需求調研、需要分析、模型構建

1.2. 關鍵點描述

需求調研分為兩個步驟進行：需求調研、需求分析。

該工作是效能測試必須的工作環節。工作產出檔案為《XX專案效能測試需求表》，如：《雲智慧_XXX系統_XXX模組效能測試需求表》。

此階段模型構建主要是業務模型構建。

1.2.1需求調研

•  需求調研工作由效能測試實施人員牽頭負責，產品經理、開發工程師、運維工程師配合完成；
•  需求調研的主要內容為：
•  系統線上環境的效能需求，例如效能需求、可靠性需求、可維護性需求等；
•  與系統性能需求相關的其它資訊，包括系統資訊（如線上環境硬體、引數配置、系統架構與部署方式、關聯絡統部署等）、業務資訊（關鍵業務邏輯與處理流程、交易列表、交易量資訊、業務分佈規律等）、生產問題、文件資料等方面，並對收集到的資訊進行彙總整理，實現對待測系統業務與技術的整體瞭解；
•  開發專案組、需求部門、運維部門等測試任務提出方應填寫《雲智慧_XXX系統_XXX模組效能測試需求表》中的“任務資訊”和“測試背景”等資訊，提出的測試需求,簡單文字不能說明的，可附加檔案；
•  效能測試小組的實施人員將調研獲取的其它內容填入《雲智慧_XXX系統_XXX模組效能測試需求表》；
•  對於新立項系統或系統新開發版本，《雲智慧_XXX系統_XXX模組效能測試需求表》應與《需求規格說明書》中的效能需求相一致。

1.2.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原則推算,則(500000*80%)/(8*20%*3600)=69.4筆/秒，取整為70筆/秒，每年按業務量增長50%計算，則一年後系統處理能力指標約等於70+70*50%=105筆/秒。

穩定性交易量推導: 取系統處理能力的60%*時長=105筆/秒*60%*8*3600=1814400筆。

經過分析後彙總成測試指標值

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

n 效能測試需求：應準確描述效能測試指標項及需求指標值。

n 系統範圍：應準確描述效能測試需求指標值所依託的測試範圍資訊，如應描述測試範圍的關聯絡統邏輯示意圖，及各關聯絡統的資訊；在對系統區域性環節進行測試時，也需闡明具體測試範圍，詳細描述被測系統的相關子系統。

n 環境差異分析：應準確描述效能測試需求指標值所依託的測試環境資訊，如須描述測試環境的總體網路拓撲結構圖、測試環境機器配置表（數量、型號、資源、作業系統）、以及相應的軟體配置、重要引數配置等。同時應準確描述線上環境的上述資訊，並進行詳細的環境差異性分析。

    以上分析內容將作為效能測試方案的重要組成部分。

1.2.3模型構建例如：業務模型

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

2.測試準備階段

2.1階段概述

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

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

2.2關鍵點描述

2.2.1測試模型構建

測試模型構建工作由效能測試實施人員完成；

在需求分析的基礎上，對調研收集到的相關資料與資訊進行分析梳理，重點分析跨系統的交易路徑、交易關聯關係、資料的處理與流轉、業務量、交易比例、典型交易，以及系統的處理能力等效能測試點，針對性地確定多個業務場景，併為每個場景選擇一套具體的業務交易集，按照業務量比例構建相應的測試模型。

本階段的產出物為，各個測試場景，以及場景中典型交易及所佔比率。

例如：從業務模型到測試模型推導

依據業務模型，通過與專案組及產品經理溝通，確定本次測試模型還需著重考慮以下內容：

（1） 考慮到後期證券系統資料庫升級，歷史查詢可能會影響，所以本次測試單獨增加一個場景：歷史委託和歷史成交查詢各50%（即0456和0457）。同時，考慮到線上環境絕大部分該交易是由總中心前置發起，所以本次測試“歷史委託和歷史成交查詢”交易均採用從總中心發起；

（2） 增加國債發行交易場景，國債發行認購日一般在櫃檯營業前進行，此場景只選擇國債發行認購一支交易；

（3） 同時，證券系統交易高峰時段櫃員簽到、櫃員簽退交易佔比較小。

通過以上分析得出本次測試模型有3個：一般交易日日間模型、國債發行日模型、以及歷史查詢交易模型。

一般交易日日間模型：

儲蓄國債交易模型：

歷史查詢交易模型：

2.2.2方案設計

效能測試實施方案編制是效能測試工作中必須的工作環節，其產出為《效能測試方案》，如：《雲智慧_XXX專案_XXX功能模組_效能能測試方案V1.0.xlsb》。

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

2.2.3案例設計

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

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

2.2.4資料準備

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

2.2.5測試指令碼開發

測試指令碼開發工作就是發揮LR的時候。

測試指令碼是對業務操作的程式化體現，一個指令碼一般為一項業務的過程描述。本活動主要為指令碼的錄製（編寫）、修改和除錯工作，從而保證在測試實施之前每個測試用例的指令碼都能夠在單筆和少量迭代次數的條件下能夠正確執行。測試指令碼開發的一般步驟如下：

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

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

Ø 設定檢查點，根據報文內容欄位判斷交易是否正確執行，即檢查點的設定在應用層面；

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

3.測試執行階段

3.1階段概述

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

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

3.2關鍵點描述

3.2.1測試執行與結果記錄

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

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

3.2.2測試監控

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

監控寶監控頁面

透視寶主機資源監控頁面

在執行結束後，停止測試監控，並提取監控結果資料。

3.2.3測試結果分析

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

例如：

測試組在執行“一般日日間交易模型”負載測試570TPS壓力時，資料庫監控發現有死鎖想象，具體如下：

問題分析：經與開發一同分析，原因如下：流控資訊收集程式（pltflowGthDaemon）在同一櫃員、在毫秒級併發做交易時plt_flowgather表出現死鎖。測試環境聯機交易使用同一個櫃員號發起，因此出現概率較高。

4.測試報告階段

4.1階段概述

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

4.2關鍵點描述

4.2.1報告撰寫

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

4.2.2測試結果描述

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

4.2.3測試缺陷與問題

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

4.2.4最終結果分析

測試最終結果的分析，該部分內容應該全面、透徹、易理解且通過圖表方式表達更直觀。

例如：

4.2.5測試結論

測試結論是效能測試分析報告必須包括的內容。測試的結論須清晰、準確回答效能測試需求中描述的各項指標，需全面覆蓋測試需求。

5.測試總結階段

5.1階段概述

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