軟件性能測試需求分析怎麼做?要點一：獲取用戶數信息1）調查系統當前和未來使用的用戶數，我來為大家科普一下關于軟件性能測試需求分析怎麼做?下面希望有你要的答案，我們一起來看看吧!

軟件性能測試需求分析怎麼做

要點一：獲取用戶數信息

1）調查系統當前和未來使用的用戶數

系統用戶數=本系統目前注冊的用戶數，注冊用戶數并不代表他會每天并且無時無刻的使用着。

在線用戶數=同時在線對系統進行操作的用戶數量（相當于混合場景）

并發用戶數=同時在線并且同時操作同一個功能（單場景添加集合點）

估算未來一到五年使用此用戶的數量，可以根據一些日志數據估算出來的。

2）調查系統當前和未來的每日、月活躍用戶數

當前活躍用戶數，即某天大概有多少用戶使用本系統：那麼這部分數據一說來也就是當前真正對系統構成壓力的數量。

要點二：獲取業務數據量

1）調查當前和未來背景數據量

因為從100條數據中查10條也許很快，但是未來數據量變成100w那你懂得...

2）調查當前和未來業務每天使用的總筆數

每個用戶每天可能下多少筆單，平均需要多少次來執行這個操作？那麼根據用戶數，我們就可以确定每天下單的筆數。如50人，平均每人每天下10次，每次下100筆，那麼總筆數就是50*10*100=50000筆。注意此數據根據TPS換算後，我們可以換算出系統的業務總處理量是否能達到這個數據，這也是一個很重要的指标。

3）調查當前和未來高峰時業務的總筆數

即上面所描述的特殊情況，這也是必須要考慮，并且拿到的數據。

要點三：場景業務的調查

1）系統關鍵、核心的業務

從系統亮點出發，以主要的業務邏輯點為第一核心：這些功能對系統或公司來說往往具有舉足輕重的地位，無論怎樣都必須要優先執行滿足這以功能的性能測試

2）高訪問量的功能，經常承受壓力的功能點

系統中表現在系統關鍵、核心業務前面必須要經過的地方：比如對于百度搜索來說，其核心業務是搜索功能，但是首先要面對的其高訪問量對是搜索輸入框加載的首頁，百度首頁加載即高訪問量的請求

3）業務複雜度高

往往說來業務邏輯複雜度的都具備1、2點的要素，可能其功能使用的人數較少但是對系統有很嚴重影響：這些功能由于其業務邏輯具有的複雜度，往往出錯的可能性也比較高，所以這些功能也是必須要進行測試的。

要點四、與性能指标指标相關的調查

1、調查每秒事務數(TPS)

這是衡量系統處理能力的一個重要指标，同時這個指标在一定程序也關系到業務數量是否能夠及時完成，所以需要獲得。

估算方式一：BS類可以參考以下指标估算：Vuser*TRequest/RPS=TPS（注意1Requset的含義為Resource=0的請求）。Resource=0的含義其實就是保證此次請求能夠真正到達服務器，去掉那些本地可以緩存的東西。

估算方式二：CS類可以參考每小時的業務數/3600s，這是沒辦法的辦法。

估算方式三：API類往往要求是Vuser*1API=TPS，由于公司的API都是提供給機構用戶的，所以API要求往往比較高，所以需要保證其遠算得非常快。

注：Vuser：虛拟用戶數；TRequest：事務中的請求數；RPS：平均響應時間。

2、調查90％（或95％）響應時間

隻看平均時間是不太科學的，對于我們的系統來說需要保證絕大多數的用戶其響應時間都是非常快的，所以我們從90％或95％用戶響應時間為指标的标準。如果拿不到，那麼我們仍可以估算：

估算方式一：BS類，按通用的标準2一5一8的标準來進行。不同業務，不同客戶類型要求不同，但對于我們的産品來說絕大多數是不能超過5s

估算方式二：CS類，根據處理的數據量其時間不同，但一般說來是不能超過15s的。

估算方式三：API類，從行業的角度來說，一般要求是毫秒級（<500ms)

3、平均響應時間和TPS的波動率

這是對響應時間的補充，要求其系統響應時間應盡量穩定，TPS的波動率受測試方法和思考、間隔時間的影響。可參考以下的計算方式：T=（TPS标準差/TPS平均值）*100％一般說來小于10％T= (RPS标準差/RPS平均值）*100％一般說來小于10%

第一類前端性能測試（客戶端）

B/S：HttpWatch、FireBug、YSlow、JS内存洩漏、大數據量下的功能測試、浏覽器長時間運行的穩定性測試等。

C/S：内存洩漏、CPU使用、顯卡使用等：

網絡性能測試：利用工具分析網絡傳輸以及延時等，為寬帶拓展做鋪墊。

第二類服務器端性能測試

性能測試，是指以性能預期目标為前提，對系統不斷施加壓力，驗證系統在資源可接受範圍内，是否能達到性能預期。（即：系統是否滿足預定的性能目标？）

負載測試，是指對系統不斷地增加壓力或增加一定壓力下的持續時間，直到系統的某項或多項性能指标達到臨界值，例如某種資源已經達到飽和狀态等：（即，最大并發數是多少？在什麼時候，響應時間不可接受”系統的服務器資源瓶頸是什麼？）

穩定性測試，是指被測試系統在特定硬件、軟件、網絡環境條件下，給系統加載一定業務壓力，使系統運行一段較長時間，以此檢測系統是否穩定，一般穩定性測試時間為n*12小時。（即系統在一般壓力條件下，是否可以提供連接不斷的優質服務？系統在長時間最大壓力條件下，是否崩潰？）

4、測試前環境的檢查收集

環境檢查包括服務器的架構以及部署方案，服務器的配置、中間件的參數配置，以及需求、功能測試報告、API調用方式等。服務器的配置需要收集生産環境與實測試環境的服務器的配置。主要收集：

• CPU：型号、核心、速度、核數、倍頻、總線速度，己耗費平均CPU内存：總物理内存、所在磁盤的虛拟内存、可用物理内存磁盤：轉速（如是舊有電腦，在執行前最好磁盤碎片整理一下）網卡：一般是100Mb，專用網絡可能在1000MB以上。

業務——跟據客戶實際使用情況，劃分業務比例：某個功能在一段時間内的使用頻率：每天使用此功能大概有多少次？在多長時間内會操作此功能？如設計腳本用例為：登錄>進入單表查詢（70％）>通過目錄導航（80％）>檢索>下載（80％），根據功能的重要性，這個用例應該首先要測試單場景，并且并發數也可能比其它的功能大一些，所以需要設置集合點。其它業務相對于使用得少一些的則可以将其與上面的用例組合成混合場景：其它場景也可以繼續細分。

思考時間——觀察、推測用戶操作這一個過程的時間以一個正常用戶使用系統業務的角色，錄制腳本随機産生，随後根據實際情況調整其值：在運行場景的時候，以50％至120％的比例随機使用思考時間

5.持續時間用戶操作此功能的時間段，采用二八定理，取80％的場景時間：注意用戶操作此功能時間段，如果是業務類軟件，中午的時間要去掉：

6.加載和退出方式一般采用緩慢登錄的方式，以便觀察當用戶數降低時其服務器的資源情況。但登錄和退出功能除外，更多的登錄和退出是集中在一個時間段。

軟件測評報告請聯系王經理：18684048962 更多資訊請關注公衆号：軟件測評閑聊站

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!