性能測試負載目標探討 軟件測試
一、 前提
近期我跟蹤了2個(gè)外協(xié)人員參與的性能測試項目，溝通中發(fā)現大家在制定測試策略時(shí)對如何確定負載目標、計算并發(fā)用戶(hù)數量等方面有很多不同方法，本文希望能對各種方法進(jìn)行探討，并根據已有經(jīng)驗對策略制定方面給出一些自己的建議。本文被測應用以銀行系統為主，壓力發(fā)起工具以LoadRunner為例。
二、 術(shù)語(yǔ)
l 單位時(shí)間：本文中以1秒為單位時(shí)間。
l 在線(xiàn)用戶(hù)數量：訪(fǎng)問(wèn)被測應用的用戶(hù)數量，但單位時(shí)間內用戶(hù)不會(huì )同時(shí)對被測服務(wù)器發(fā)送請求，產(chǎn)生壓力。
l 并發(fā)用戶(hù)數量：部分書(shū)中分狹義和廣義兩種，狹義指單位時(shí)間內同時(shí)執行一種操作的用戶(hù)數量，廣義指單位時(shí)間內同時(shí)執行多種不同操作的用戶(hù)數量，廣義的并發(fā)用戶(hù)操作更接近實(shí)際業(yè)務(wù)環(huán)境。但本文中的并發(fā)用戶(hù)數量?jì)H指狹義而言，因為廣義是多種狹義的組合。
l TPS：Transaction per Second，每秒事務(wù)數量，單位是事務(wù)/秒。
l TRT：Transaction Response Time，事務(wù)響應時(shí)間，指TPS穩定時(shí)的平均事務(wù)響應時(shí)間，單位是秒。
三、 負載目標
1. 負載視角
制定測試策略是性能測試的重點(diǎn)，包括測試范圍、場(chǎng)景提取、負載目標、發(fā)起方式、通過(guò)標準等。而負載目標關(guān)系整個(gè)測試的場(chǎng)景設計、并發(fā)配比、結果評判，因此確定負載目標也決定了測試的總體方向。通過(guò)了解業(yè)務(wù)需求，負載目標都會(huì )轉化為一系列具體的數值，一般可從兩方面來(lái)劃分：
l 前端：業(yè)務(wù)人員更關(guān)注前端并發(fā)用戶(hù)數量或在線(xiàn)用戶(hù)數量，以人數衡量;
l 后端：技術(shù)人員更關(guān)注后端應用服務(wù)器和數據庫服務(wù)器的負載能力，以TPS衡量;
前端并發(fā)用戶(hù)數量的計算在業(yè)界中有很多公式和原則，如2/8原則、10%在線(xiàn)用戶(hù)數量估算、(在線(xiàn)用戶(hù)數量*session時(shí)間)/監控時(shí)間等，但各公式和原則計算出的并發(fā)用戶(hù)數量并不精確，如有10萬(wàn)在線(xiàn)用戶(hù)的系統不能說(shuō)僅測試10萬(wàn)*10%=1萬(wàn)并發(fā)用戶(hù)即可。
后端TPS反應被測應用的實(shí)際負載能力，對已有具體業(yè)務(wù)量的應用可以計算精確，如銀行系統中某省行對公交易量日均10萬(wàn)筆，則可精確計算出TPS均值=10萬(wàn)/(6*3600)=4.63筆/秒(對公業(yè)務(wù)按6小時(shí)計算)，若被測應用達不到TPS要求則完成不了當日業(yè)務(wù)。
同一個(gè)被測應用以不同視角估算負載目標，得到的數值可能會(huì )有很大差異，因此如何正確選擇負載目標，將會(huì )直接影響之后的測試方法和場(chǎng)景設計。
2. 負載指標
拋開(kāi)視角的選擇，單從最終測試指標來(lái)說(shuō)，對于一個(gè)軟硬件環(huán)境固定的應用程序，只有一個(gè)負載指標是固定的，那就是最大事務(wù)處理能力–通常以TPS衡量。隨著(zhù)負載的增加，被測應用將會(huì )逐漸達到最大事務(wù)處理能力，若應用足夠健壯，則負載繼續增加，應用的事務(wù)處理能力也不會(huì )驟然下降。因此性能測試的目標就是確定被測應用的最大事務(wù)處理能力。以事務(wù)處理能力反推，將逐漸捋清TPS、TRT、并發(fā)用戶(hù)數量、在線(xiàn)用戶(hù)數量等負載目標的關(guān)系和估算。
TPS
Transaction的粒度會(huì )直接影響TPS的計算，因此Transaction定義時(shí)要保證粒度適當：
l C/S架構聯(lián)機類(lèi)應用中一筆交易往往會(huì )流經(jīng)多層前置應用，需要確定壓力發(fā)起工具所在位置，建議跨過(guò)前端直壓被測應用，此時(shí)一個(gè)Transaction代表一支后臺交易。
l B/S架構經(jīng)管類(lèi)應用中一個(gè)頁(yè)面操作可能會(huì )和后臺有多次交互，建議以頁(yè)面上的操作為T(mén)ransaction劃分基準，但要保證Transaction內的交互操作在前端是不可再拆分的。
l LoadRunner發(fā)起壓力時(shí)Action內的語(yǔ)句是反復迭代的，而LR計算TPS僅看1秒內執行了幾次Transaction，如果Action內有多個(gè)Transaction則各事務(wù)的TPS都一樣，反應不出各事務(wù)的真實(shí)處理能力，因此建議Action內只定義一個(gè)或盡量精簡(jiǎn)的Transaction。
由此TPS才可以準確表示被測應用的事務(wù)處理能力。
文章來(lái)源于領(lǐng)測軟件測試網(wǎng) http://kjueaiud.com/
