性能測試總結(二)---測試流程篇

本文主要介紹下性能測試的基本流程，性能測試從實際執行層面來看，測試的過程通常分爲這麼幾個階段，以下圖：

　　　　　　　

下面分別介紹下每一個階段具體須要作什麼：

1、性能需求分析：

　　性能需求分析是整個性能測試工做開展的基礎，若是連性能的需求都沒弄清楚，後面的性能測試執行實際上是沒有任何意義的，並且性能需求分析作的好很差直接影響到性能測試的結果。

　　一些性能測試人員常犯的錯誤就是測試一開始就直接用工具對系統進行加壓，沒有弄清楚性能測試的目的，稀裏糊塗作完了之後也不知道結果是否知足性能需求。市面上的書籍也大都是直接講性能測試工具如LR，jmeter如何使用，致使不少新手一提到性能測試就直接拿工具來進行錄製回放，使得不少人認爲會使用性能測試工具就等於會性能測試了，卻不知工具其實只是性能測試過程當中很小的一部分。

　在需求分析階段，測試人員須要與項目相關的人員進行溝通，收集各類項目資料，對系統進行分析，創建性能測試數據模型，並將其轉化爲可衡量的具體性能指標，確認測試的目標。因此性能測試需求分析過程是繁雜的，須要測試人員有深厚的性能理論知識，除此以外還須要懂一些數學建模的知識來幫助咱們創建性能測試模型。

 

首先，讓咱們來看看經過性能需求分析咱們須要得出哪些結論或目標：

• 明確倒底要不要作性能測試？性能測試的目的是什麼？
• 明確被測系統是什麼？被測試系統的相關技術信息如：架構、平臺、協議等
• 明確被測系統的基本業務、關鍵業務，用戶行爲
• 明確性能測試點是什麼？哪些須要測，爲何？哪些不須要測，又是爲何？
• 明確被測系統將來的業務拓展規劃以及性能需求？
• 明確性能測試策略，即應該怎麼測試？
• 明確性能測試的指標，知道測試出來的結果怎麼算經過？

 

其次，需求分析階段咱們能夠從如下幾個方面入手：

一、系統信息調研：

　　指對被測試系統進行分析，須要對其有全面的瞭解和認識，這是咱們作好性能測試的前提，並且在後續進行性能分析和調優時將會大有用處，試想若是連繫統的架構、協議都不瞭解，咱們如何進行準確的性能測試？若是進行性能分析與調優？

　　須要分析的系統信息以下（包括但不只限於以下這些）：

 

二、業務信息調研：

　　指對被測試的業務進行分析，經過對業務的分析和了解，方便咱們後續進行性能測試場景的肯定以及性能測試指標的肯定。

　　須要分析的業務信息以下（包括但不只限於以下這些）：

　　

三、性能需求評估：

　　在實施性能測試以前，咱們須要對被測系統作相應的評估，主要目的是明確是否須要作性能測試。若是肯定須要作性能測試，須要進一步確立性能測試點和指標，明確該測什麼、性能指標是多少，測試經過or不經過的標準？性能指標也會根據狀況評估，要求被測系統能知足未來必定時間段的業務壓力。

　　判斷是否進行性能測試主要從下面兩個方面進行思考：

• 業務角度:

　　 系統是公司內部 or 對外？系統使用的人數的多少？若是一個系統上線後基本沒幾我的使用，不管系統多大，設計多麼複雜，併發性的性能測試都是不必的，前期能夠否決。固然，除非在功能測試階段發現很是明顯的性能問題，使得用戶體驗較差的，此時可進行性能測試來排查問題。

 

• 系統角度：系統又能夠從如下3個方面進行分析

　　a）系統架構：

　　　　　若是一個系統採用的框架是老的系統框架（一般大公司都有本身的統一框架），只是在此框架上增長一些應用，實際上是沒有必要作性能測試，由於老框架的使用確定是通過了驗證的。若是一個系統採用的是一種新的框架，能夠考慮作性能測試。

　　b）數據庫要求：

　　　　　不少狀況下，性能測試是大數據量的併發訪問、修改數據庫，而瓶頸在於鏈接數據庫池的數量，而非數據庫自己的負載、吞吐能力。這時，能夠結合DBA的建議，來決定是否來作性能測試。

　　c）系統特殊要求：

　　　　　從實時性角度來分析，某些系統對響應時間要求比較，好比證券系統，系統的快慢直接影響客戶的收益，這種狀況就有做併發測試的必要，在大併發量的場景下，查看這個功能的響應時間。

　　　　　從大數據量上傳下載角度分析，某些系統常常須要進行較大數據量的上傳和下載操做，雖然此種操做使用的人數不會太多，可是也有必要進行性能測試，肯定系統能處理的最大容量，若是超過這個容量時系統須要進行相關控制，避免因爲不人工誤操做致使系統內存溢出或崩潰。

 

四、肯定性能測試點： 

　　在上面第3點中，咱們簡單分析瞭如何肯定一個系統是否須要作性能測試。下面簡單總結下若是一個系統肯定要作性能測試，咱們如何肯定被測系統的性能測試點？

　　咱們能夠從下面幾個方面進行分析：

• 關鍵業務：

  　　肯定被測項目是否屬於關鍵業務，有哪些主要的業務邏輯點，特別是跟交易相關的功能點。例如轉帳，扣款等接口。若是項目（或功能點）不屬於關鍵業務（或關鍵業務點），則可轉入下面。

• 日請求量：

  　　肯定被測項目各功能點的日請求量（能夠統計不一樣時間粒度下的請求量如：小時，日，周，月）。若是日請求量很高，系統壓力很大，並且又是關鍵業務，該項目須要作性能測試，並且關鍵業務點，能夠被肯定爲性能點。

• 邏輯複雜度：

  　　斷定被測項目各功能點的邏輯複雜度。若是一個主要業務的日請求量不高，可是邏輯很複雜，則也須要經過性能測試。緣由是，在分佈式方式的調用中，當某一個環節響應較慢，就會影響到其它環節，形成雪崩效應。

• 運營推廣活動：

  　　根據運營的推廣計劃來斷定待測系統將來的壓力。未雨綢繆、防患於未然、下降運營風險是性能測試的主要目標。被測系統的性能不只能知足當前壓力，更須要知足將來必定時間段內的壓力。所以，事先了解運營推廣計劃，對性能點的制定有很大的做用。例如，運營計劃作活動，要求系統天天能支撐多少 PV、多少 UV，或者一個季度後，須要能支撐多大的訪問量等等數據。當新項目（或功能點）屬於運營重點推廣計劃範疇以內，則該項目（或功能點）也須要作性能測試。

　　以上 4 點，是相輔相成、環環相扣的。在實際工做中應該具體問題具體分析。例如，當一個功能點不知足以上 4 點，但又屬於資源高消耗（內存、CPU），也可列入性能測試點行列。

 

五、肯定性能指標： 

　　性能需求分析一個很重要的目標就是須要肯定後期性能分析用的性能指標，性能指標有不少，能夠根據具體項目選取和設定，而具體的指標值則須要根據業務特色進行設定，本文不詳細進行闡述，後續可考慮就此單獨寫一篇。

 

2、性能測試準備

一、測試環境準備：

　　a）系統運行環境：這個一般就是咱們的測試環境，有些時候需求比較多，作性能測試擔憂把環境搞跨了影響其它的功能測試，可能須要從新搭建一套專門用來作性能測試的環境。

　　b）執行機環境：這個就是用來生成負載的執行機，一般須要在物理機上運行，而物理機又是稀缺資源，因此咱們每次作性能測試都須要提早準備好執行機環境。

二、測試場景設計：根據性能需求分析來設計符合用戶使用習慣的場景，場景設計的好很差直接影響到性能測試的效果。

三、性能工具準備：

　　a）負載工具：根據需求分析和系統特色選擇合適的負載工具，好比LR、Jmeter或galting等

　　b）監控工具：準備性能測試時的服務器資源、JVM、數據庫監控工具，以便進行後續的性能測試分析與調優。

四、測試腳本準備：若是性能測試工具不能知足被測系統的要求或只能知足部分要求時，須要咱們本身開發腳本配合工具進行性能測試。

五、測試數據準備：

　　a）負載測試數據：併發測試時須要多少數據？好比登陸場景？

　　b）DB數據量大小：爲了儘可能符合生產場景，須要模擬線上大量數據狀況，那麼要往數據庫裏提早插入必定的數據量。這可能須要花費一些時間，特色是關聯繫統較多，邏輯複雜的業務可能同時涉及多張表。

六、其它：若是須要其它其它關聯繫統或專業人士如DBA配合的，也須要提早進行溝通。

 

3、性能測試執行

 一、人工邊執行邊分析

　　一般咱們作性能測試都是人工執行並隨時觀察系統運行的狀況、資源的使用率等指標。性能測試的吸引力之一就在於它的不可預知性。當咱們在作性能測試的時候遇到跟預期不符的狀況很正常，這個時候須要冷靜的分析。但這個過程可能會很慢長，須要不斷的調整系統配置或程序代碼來定位問題，耗時耗人力。特別是在當前敏捷開發模式比較流行的大環境下，版本發佈很是頻繁且版本週期短（一般1~2週一個版本），沒有那麼長的時間來作性能測試。

二、無人值守執行性能測試

　　無人值守是最理想化的目標，目前咱們也朝着這個方向努力。無人值守不是說沒有人力介入，而是把人爲的分析和執行過程分離，執行過程只是機器服從指令的運行而已。一般測試環境在白天比較繁忙，出現性能問題及定位難度較大且會影響功能測試。因此通常性能測試最好在晚上或週末進行，在相對較安靜的條件有利於測試結果的穩定性。這種方法也相對比較適合敏捷的模式，不須要人工一直守着。只須要在拿到結果後進行分析就行了。同進，這種方式對測試人員能力的要求比較高，須要咱們能進行自動化的收集各類監控數據、生成報表便於後續分析。

 

4、結果分析與調優

 

關於性能分析與調優這是一個比較大的話題，後續會單獨進行總結和分析。

 

5、測試報告與總結

 　　性能測試報告是性能測試的里程碑，經過報告能展現出性能測試的最終成果，展現系統性能是否符合需求，是否有性能隱患。性能測試報告中須要闡明性能測試目標、性能測試環境、性能測試數據構造規則、性能測試策略、性能測試結果、性能測試調優說明、性能測試過程當中遇到的問題和解決辦法等。

　　性能測試工程師完成該次性能測試後，須要將測試結果進行備案，並作爲下次性能測試的基線標準，具體包括性能測試結果數據、性能測試瓶頸和調優方案等。同時須要將測試過程當中遇到的問題，包括代碼瓶頸、配置項問題、數據問題和溝通問題，以及解決辦法或解決方案，進行知識沉澱。