一個完整的性能測試流程

下午逛一個測試交流羣時，聊起性能測試，而後某位羣成員說他們用的loadrunner作性能，當時以爲這話有點偏頗，雖然我也是一個性能測試道路上的摸索前進者。。。

誠然，咱們在進行性能測試工做的過程當中，須要藉助工具的輔助來幫咱們完成一些工做，但loadrunner≠性能測試！或者說，性能測試工具≠性能測試，工具永遠是一種

輔助的工具，而不能認爲會用工具就會性能測試了！但願看到這裏的童鞋（測試小白這種認知比較多），能夠改變這個觀念。。。

下面，就說說一個完整的性能測試過程吧。。。

PS：文末附上一張性能測試的思惟導圖

 

1、準備工做

一、系統基礎功能驗證

性能測試在什麼階段適合實施？切入點很重要！通常而言，只有在系統基礎功能測試驗證完成、系統趨於穩定的狀況下，纔會進行性能測試，不然性能測試是無心義的。

二、測試團隊組建

根據該項目的具體狀況，組建一個幾人的性能測試team，其中DBA是必不可少的，而後須要一至幾名系統開發人員（對應前端、後臺等），還有性能測試設計和分析人員、腳本開發

和執行人員；在正式開始工做以前，應該對腳本開發和執行人員進行一些培訓，或者應該由具備相關經驗的人員擔任。

三、工具的選擇

綜合系統設計、工具成本、測試團隊的技能來考慮，選擇合適的測試工具，最起碼應該知足一下幾點：

①支持對web（這裏以web系統爲例）系統的性能測試，支持http和https協議；

②工具運行在Windows平臺上；

③支持對webserver、前端、數據庫的性能計數器進行監控；

四、預先的業務場景分析

爲了對系統性能創建直觀上的認識和分析，應對系統較重要和經常使用的業務場景模塊進行分析，針對性的進行分析，以對接下來的測試計劃設計進行準備。

 

2、測試計劃

測試計劃階段最重要的是分析用戶場景，肯定系統性能目標。

一、性能測試領域分析

根據對項目背景，業務的瞭解，肯定本次性能測試要解決的問題點；是測試系統可否知足實際運行時的須要，仍是目前的系統在哪些方面制約系統性能的表現，或者，哪些系統因素致使

系統沒法跟上業務發展？肯定測試領域，而後具體問題具體分析。

二、用戶場景剖析和業務建模

根據對系統業務、用戶活躍時間、訪問頻率、場景交互等各方面的分析，整理一個業務場景表，固然其中最好對用戶操做場景、步驟進行詳細的描述，爲測試腳本開發提供依據。

三、肯定性能目標

前面已經肯定了本次性能測試的應用領域，接下來就是針對具體的領域關注點，肯定性能目標（指標）；其中須要和其餘業務部門進行溝通協商，以及結合當前系統的響應時間等數據，肯定

最終咱們須要達到的響應時間和系統資源使用率等目標；好比：

①登陸請求到登陸成功的頁面響應時間不能超過2秒；

②報表審覈提交的頁面響應時間不能超過5秒；

③文件的上傳、下載頁面響應時間不超過8秒；

④服務器的CPU平均使用率小於70%，內存使用率小於75%；

⑤各個業務系統的響應時間和服務器資源使用狀況在不一樣測試環境下，各指標隨負載變化的狀況等；

四、制定測試計劃的實施時間

預設本次性能測試各子模塊的起止時間，產出，參與人員等等。

 

3、測試腳本設計與開發

性能測試中，測試腳本設計與開發佔據了很大的時間比重。

一、測試環境設計

本次性能測試的目標是須要驗證系統在實際運行環境中的性能外，還須要考慮到不一樣的硬件配置是否會是制約系統性能的重要因素！所以在測試環境中，須要部署多個不一樣的測試環境，

在不一樣的硬件配置上檢查應用系統的性能，並對不一樣配置下系統的測試結果進行分析，得出最優結果（最適合當前系統的配置）。

這裏所說的配置大概是以下幾類：

①數據庫服務器

②應用服務器

③負載模擬器

④軟件運行環境，平臺

測試環境測試數據，能夠根據系統的運行預期來肯定，好比須要測試的業務場景，數據多久執行一次備份轉移，該業務場景涉及哪些表，每次操做數據怎樣寫入，寫入幾條，須要多少的

測試數據來使得測試環境的數據保持一致性等等。

能夠在首次測試數據生成時，將其導出到本地保存，在每次測試開始前導入數據，保持一致性。

二、測試場景設計

經過和業務部門溝通以及以往用戶操做習慣，肯定用戶操做習慣模式，以及不一樣的場景用戶數量，操做次數，肯定測試指標，以及性能監控等。

三、測試用例設計

確認測試場景後，在系統已有的操做描述上，進一步完善爲可映射爲腳本的測試用例描述，用例大概內容以下：

用例編號：查詢表單_xxx_x1（命名以業務操做場景爲主，簡潔易懂便可）

用例條件：用戶已登陸、具備對應權限等。。。

操做步驟：

①進入對應頁面。。。。。。

②查詢相關數據。。。。。。

③勾選導出數據。。。。。。

④修改上傳數據。。。。。。

PS：這裏的操做步驟只是個例子，具體以系統業務場景描述；

四、腳本和輔助工具的開發及使用

按照用例描述，可利用工具進行錄製，而後在錄製的腳本中進行修改；好比參數化、關聯、檢查點等等，最後的結果使得測試腳本可用，能達到測試要求便可；

PS：我的而言，建議儘可能本身寫腳原本實現業務操做場景，這樣對我的技能提高較大；一句話：能寫就毫不錄製！！！

 

4、測試執行與管理

在這個階段，只須要按照以前已經設計好的業務場景、環境和測試用例腳本，部署環境，執行測試並記錄結果便可。

一、創建測試環境

按照以前已經設計好的測試環境，部署對應的環境，由運維或開發人員進行部署，檢查，並仔細調整，同時保持測試環境的乾淨和穩定，不受外來因素影響。

二、執行測試腳本

這一點比較簡單，在已部署好的測試環境中，按照業務場景和編號，按順序執行咱們已經設計好的測試腳本。

三、測試結果記錄

根據測試採用的工具不一樣，結果的記錄也有不一樣的形式；如今大多的性能測試工具都提供比較完整的界面圖形化的測試結果，固然，對於服務器的資源使用等狀況，能夠利用一些計數器或

第三方監控工具來對其進行記錄，執行完測試後，對結果進行整理分析。

 

5、測試分析

一、測試環境的系統性能分析

根據咱們以前記錄獲得的測試結果（圖表、曲線等），通過計算，與預約的性能指標進行對比，肯定是否達到了咱們須要的結果；如未達到，查看具體的瓶頸點，而後根據瓶頸點的具體數據，

進行具體狀況具體分析（影響性能的因素不少，這一點，能夠根據經驗和數據表現來判斷分析）。

二、硬件設備對系統性能表現的影響分析

因爲以前設計了幾個不一樣的測試環境，故能夠根據不一樣測試環境的硬件資源使用情況圖進行分析，肯定瓶頸是再數據庫服務器、應用服務器抑或其餘方面，而後針對性的進行優化等操做。

三、其餘影響因素分析

影響系統性能的因素不少，能夠從用戶能感覺到的場景分析，哪裏比較慢，哪裏速度尚可，這裏能夠根據2\5\8原則對其進行分析；

至於其餘諸如網絡帶寬、操做動做、存儲池、線程實現、服務器處理機制等一系列的影響因素，具體問題具體分析，這裏就不一一表述了。

四、測試中發現的問題

在性能測試執行過程當中，可能會發現某些功能上的不足或存在的缺陷，以及須要優化的地方，這也是執行屢次測試的優勢。

 

6、性能測試思惟導圖

以上就是一個較簡單，完整的性能測試過程，固然其中頗有不少值得分析和探討的內容，限於篇幅和時間問題，這裏不一一贅述，之後會慢慢對性能測試執行、瓶頸分析、優化的內容不斷

補充，也但願看到的童鞋能夠提出建議和指正，若有興趣，可加入博客主頁的羣連接，一塊兒交流關於軟件測試的相關技術和經驗。。。