作者：薛定諤的破貓

基礎數據分析

以下圖表均取自互聯網，本文是在“已經獲取所需數據”的前提下，講解性能測試的一些設計思路。至于如何才能取得這些數據，將在后續的文章中說明。

系統訪問量分布

由系統的日訪問量分布圖，可知系統的訪問壓力集中在哪個時間段內。系統的壓力是在一天中平均分布的，還是集中在某幾個更小的時間段內。根據此信息，我們對測試場景的時間進行設計，如從分布圖中明顯看出每天的大部分訪問量集中在9：00～11：00和14：00～16：00兩個時段，那么就可以設計2小時內完成一半訪問量的測試場景。

用戶的平均活躍時間

用戶活躍時間，是指用戶一次使用系統的時長，可用來指導測試腳本的設計，即每個虛擬用戶腳本應該在多長時間內執行完。

由系統訪問量分布和用戶活躍時間兩個數據，可以對系統使用的并發度進行估算。比如已知系統在2個小時內有200訪問量，且分布接近于平均，用戶的平均活躍時間為30分鐘，那么此時間段的并發度應為：200*30/120=50。這里并發度50傳遞的信息是，在一個用戶活躍周期內，總共會有50個用戶與服務端進行交互(即相對并發)。也就是說任意時間點，最大的絕對并發可能性是50，當然實際可能遠低于此，可以根據業務特點再乘以相應比例進行估算。

在性能測試時，可以依據此數據設計系統高峰期壓力的測試場景。比如我們已知，系統壓力最大時，單位時間段內活躍用戶有100人(并發度100)，那么這種壓力場景，就可以以用戶平均活躍時間為測試時間段，啟動100個虛擬用戶并在該時間段內完成各自的工作量。

頁面停留時間

即請求之間的間隔(思考)時間，如在編輯頁面上停留多久才會點提交按鈕。如果無此數據，性能測試腳本只有運行時長是有數據(活躍時間)支撐的，腳本中的各請求之間的思考時間，只能通過常規判斷和猜測，由性能測試人員自己掌控。收集到此數據后，性能測試腳本會更加符合真實用戶的操作習慣，更加接近真實用戶。

熱點模塊(頁面)

分析系統各模塊或頁面的訪問頻率，可以用來檢查性能測試是否設計了足夠的覆蓋、是否遺漏的用戶頻繁使用的功能，并據此對用戶模型進行完善。此外，此數據可用來分析各模塊或功能所涉及到的工作量，如每天平均完成多少次提交操作、多少次統計操作。這對于確定系統的使用壓力有很大的作用。

場景數據

最后，綜合所有數據，為特定測試場景制訂出成如下表格：總體

場景名稱100用戶負載場景

場景描述模擬系統使用高峰期時，在2小時左右有100用戶的訪問

場景時長2h

場景加載策略每4.5分鐘加載5個虛擬用戶。因為要在2小時內完成100用戶的訪問，而每個用戶的運行時間在30分鐘左右，那么在1小時30分鐘時就最后一批用戶就要開始訪問系統，即90分鐘內加載100個用戶。

虛擬用戶數100

用戶模型見XX用戶模型

虛擬用戶運行時間30min

平均思考時間30~60s

場景并發度25。

虛擬用戶數*(虛擬用戶運行時間/場景時長)

操作說明

登錄Think Time平均8s，最小5s，最大20s

Pass/Fail 條件如果失敗，重試一次，依然失敗就中止。

數據每虛擬用戶使用不同的賬號

...

可以說，用戶模型表達的是，系統運行中的壓力是如何分布的。　　而場景數據表達的是，要給系統施加多大的壓力。　　只有結合用戶模型和場景數據兩部分，才能構造出一個確定的負載場景。

如果到這里都已經做好，并且經過了技術負責人和業務負責人的確認，那么接下來要做的就是按照設計來實現測試腳本了。

總結

以上是生活随笔為你收集整理的数据分析转软件测试,（转）性能测试用户模型（三）：基础数据分析、场景数据...的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。