通常情況下，性能測試關(guān)注被測對象的時間與資源利用特性及穩(wěn)定性。時間特性，即被測對象實現(xiàn)業(yè)務(wù)交易過程中所需的處理時間，從用戶角度來說，越短越好。

資源利用特性，即被測對象的系統(tǒng)資源占用情況，一般Web系統(tǒng)不關(guān)注客戶端的資源占用情況，僅關(guān)注服務(wù)器端，通常為服務(wù)器端的CPU、內(nèi)存、網(wǎng)絡(luò)帶寬、磁盤等（根據(jù)被測對象架構(gòu)設(shè)計，還可分為Web服務(wù)器、中間件、數(shù)據(jù)庫、負(fù)載均衡等）。穩(wěn)定性，關(guān)注被測對象在一定負(fù)載情況下，持續(xù)穩(wěn)定提供服務(wù)的能力。

不同的被測對象，不同的業(yè)務(wù)需求，可能有不同的指標(biāo)需求，但大多數(shù)測試需求中都包含以下幾個性能指標(biāo)：

1、并發(fā)數(shù)

并發(fā)，即為同時出發(fā)，從應(yīng)用系統(tǒng)架構(gòu)層面來看，并發(fā)意為單位時間內(nèi)服務(wù)器接受到的請求數(shù)。客戶端的某個具體業(yè)務(wù)行為包括了若干個請求，因此，并發(fā)數(shù)被抽象理解為客戶端單位時間內(nèi)發(fā)送給服務(wù)器端的請求，而客戶端的業(yè)務(wù)請求一般為用戶操作行為，因此，并發(fā)數(shù)，也可理解為并發(fā)用戶數(shù)，而這些用戶是虛擬的，又可稱為虛擬用戶。

并發(fā)數(shù)，廣義來講，是單位時間內(nèi)同時發(fā)送給服務(wù)器的業(yè)務(wù)請求，不限定具體業(yè)務(wù)類型，狹義來看，是單位時間內(nèi)同時發(fā)送給服務(wù)器的相同的業(yè)務(wù)請求，需限定具體業(yè)務(wù)類型。在性能測試實施過程中需注意二者的區(qū)別。

2、響應(yīng)時間

目前大多數(shù)的軟件系統(tǒng)客戶端與服務(wù)器交互過程如圖 1所示，用戶通過客戶端（如瀏覽器）發(fā)出業(yè)務(wù)請求（網(wǎng)絡(luò)傳輸時間T1），服務(wù)器接收并處理該請求（服務(wù)器處理時間T2），然后根據(jù)實際的處理模型返回結(jié)果（網(wǎng)絡(luò)返回數(shù)據(jù)時間T3），客戶端接收請求結(jié)果（客戶端處理展示時間T4）。

在這個處理流程中，涉及到的各個業(yè)務(wù)節(jié)點的處理時間總和T1+T2+T3即為系統(tǒng)響應(yīng)時間。這個時間的計算忽略了用戶端數(shù)據(jù)呈現(xiàn)的時間T4。從用戶角度來講，用戶應(yīng)用客戶端發(fā)出業(yè)務(wù)請求，到客戶端（通常為瀏覽器）展現(xiàn)相應(yīng)的請求結(jié)果，這個時間越短越好，即用戶視角的響應(yīng)時間為T1+T2+T3+T4。從服務(wù)器角度來講，服務(wù)器接收到客戶端發(fā)來的請求，并給出結(jié)果的響應(yīng)，這個過程所消耗的時間，記錄為響應(yīng)時間，即服務(wù)器僅關(guān)注T2的處理時間。因此，不同的視角，衡量的響應(yīng)時間指標(biāo)也不同。

圖1響應(yīng)時間組成示意圖

通過上述兩個不同視角的描述不難發(fā)現(xiàn)，用戶與服務(wù)器所理解的響應(yīng)時間存在明顯的差異。用戶關(guān)注的是發(fā)出請求至看到響應(yīng)結(jié)果的時間，而服務(wù)器關(guān)注的是接受請求到返回結(jié)果的時間，對于用戶而言，忽略了瀏覽器展示的時間，對于服務(wù)器而言，則忽略了瀏覽器展示、網(wǎng)絡(luò)傳輸?shù)葧r間。因此，在實際測試過程中，需明確以什么視角驗證被測對象的性能。

大多數(shù)情況下，性能測試主要是以用戶視角進(jìn)行，因此在實際測試過程中，通常關(guān)注用戶行為，所以，響應(yīng)時間一般指客戶端發(fā)出請求到接收到服務(wù)器端的響應(yīng)數(shù)據(jù)所消耗的時間。

需注意的是，性能測試工作中，客戶有時可能需要測試公網(wǎng)的系統(tǒng)來驗證性能指標(biāo)，從測試經(jīng)驗來看，最好不要嘗試在公網(wǎng)進(jìn)行性能測試，原因有二：

第一、 可能影響現(xiàn)網(wǎng)用戶。實施性能測試過程中，可能產(chǎn)生大量的壓力與垃圾數(shù)據(jù)，從而破壞生產(chǎn)環(huán)境，導(dǎo)致缺陷的產(chǎn)生，影響實際的業(yè)務(wù)。

第二、 壓力模擬可能無法真實體現(xiàn)。性能測試工程師實施性能測試時，利用測試工具，模擬了大量的并發(fā)數(shù)，產(chǎn)生了大量的業(yè)務(wù)數(shù)據(jù)，但因負(fù)載生成器所在的網(wǎng)絡(luò)與服務(wù)器所在網(wǎng)絡(luò)不同，或者服務(wù)器的網(wǎng)絡(luò)安全設(shè)置，導(dǎo)致壓力數(shù)據(jù)無法達(dá)到被測服務(wù)器，整個網(wǎng)絡(luò)環(huán)境不可控，從而導(dǎo)致測試失敗。

有一種情況除外，模擬固定帶寬網(wǎng)絡(luò)訪問的場景，可在局域網(wǎng)中使用限制帶寬的手段進(jìn)行測試。遵循一個原則，測試過程中，任何資源都必須可控。

3、吞吐量

單位時間內(nèi)系統(tǒng)處理用戶請求的數(shù)量，可以用請求數(shù)/單位時間或者點擊數(shù)/單位時間，或者字節(jié)數(shù)/單位時間等方式來衡量，其中通過字節(jié)數(shù)/單位時間的計算方式，與當(dāng)前的網(wǎng)絡(luò)帶寬比較，可以找出網(wǎng)絡(luò)方面的問題。例如，1分鐘內(nèi)系統(tǒng)可以處理1000次轉(zhuǎn)賬交易，則吞吐量為1000/60=16.7。吞吐量指標(biāo)直接體現(xiàn)了軟件系統(tǒng)的業(yè)務(wù)處理能力，尤其適用于系統(tǒng)架構(gòu)選型，做對比測試。

4、系統(tǒng)資源耗用

系統(tǒng)資源耗用，客戶端與服務(wù)器系統(tǒng)各項硬件資源的耗用情況，如CPU使用率、內(nèi)存使用率、網(wǎng)絡(luò)帶寬占用率、磁盤I/O輸入輸出量等。一個系統(tǒng)的高效運行，除了軟件資源外，硬件資源也是不可缺少的部分，因此在性能測試過程中，需關(guān)注系統(tǒng)資源的耗用。

5、業(yè)務(wù)成功率

業(yè)務(wù)成功率意為用戶發(fā)起了多筆業(yè)務(wù)請求，成功的比率有多少。例如，測試銀行營業(yè)系統(tǒng)的并發(fā)處理性能，全北京100個網(wǎng)點，中午12:30到13:30一個小時的高峰期里，要求能支持50000筆開戶業(yè)務(wù)，其中成功率不少于98%，也就是需要成功開戶49000筆，其他的1000筆可能是超時，或者其他錯誤導(dǎo)致未能開戶成功。業(yè)務(wù)成功率展示了在特定壓力或負(fù)載情況下，服務(wù)器正確穩(wěn)定處理業(yè)務(wù)請求的能力。

6、TPS

單位時間內(nèi)服務(wù)器處理的事務(wù)數(shù)，該指標(biāo)值越大越好。一般情況下，用戶業(yè)務(wù)操作過程可能細(xì)分為若干個事務(wù)，單位時間處理的事務(wù)數(shù)越多，說明服務(wù)器的處理能力越強(qiáng)。

根據(jù)上述各個指標(biāo)的概念，結(jié)合被測對象本身的業(yè)務(wù)情況，做出如下測試需求及指標(biāo)分析。

ECShop是一個面向廣大網(wǎng)絡(luò)用戶的電子商務(wù)系統(tǒng)。大部分用戶會在某個時間段訪問該電商平臺，進(jìn)行網(wǎng)絡(luò)購物，但如何確定用戶訪問的時間段呢？

新系統(tǒng)沒有上線時，沒有歷史數(shù)據(jù)可以依據(jù)，這種情況下，測試工程師可以通過競品分析，獲取友商系統(tǒng)的運營數(shù)據(jù)作為參考。以淘寶運營數(shù)據(jù)為例，通過運營團(tuán)隊統(tǒng)計，大部分消費者集中在如圖2所示的時間段訪問電商平臺。

圖2消費者訪問電商平臺時間段分布

通過上圖分析，業(yè)務(wù)峰值幾乎在15點-17點及21點-23點左右，業(yè)務(wù)峰值期持續(xù)2個小時左右，若要測試穩(wěn)定性，則需根據(jù)實際業(yè)務(wù)情況模擬用戶應(yīng)用場景。

確定性能測試評估的時間段后，需確定在該時間段內(nèi)需完成的業(yè)務(wù)量，這就需要統(tǒng)計有多少人在這個時間段使用ECShop電商系統(tǒng)。統(tǒng)計這個數(shù)據(jù)比較難，因為各個公司運營規(guī)模不一樣。這種情況下，測試工程師需根據(jù)產(chǎn)品團(tuán)隊的業(yè)務(wù)規(guī)劃、產(chǎn)品設(shè)計給出一個參考值，比如系統(tǒng)初期設(shè)計規(guī)模在單天15萬業(yè)務(wù)量，峰值交易5000筆、最高并發(fā)100用戶（如秒殺業(yè)務(wù)）等。通過對預(yù)設(shè)業(yè)務(wù)目標(biāo)的分析，可得出以下幾個數(shù)據(jù)：

• （1） 峰值時間段2個小時；
• （2） 單天15萬業(yè)務(wù)量訪問；
• （3） 峰值交易5000筆；
• （4） 最高并發(fā)100個用戶。

接著分析，滿足上述需求的同時，還需要考慮業(yè)務(wù)的響應(yīng)時間。被測對象的響應(yīng)時間，作為一個很直觀的用戶體驗數(shù)據(jù)，可很好的衡量被測對象是否讓用戶感受好，但感受好并沒有一個量化的指標(biāo)，只是個相對的概念。

響應(yīng)時間在業(yè)內(nèi)一個經(jīng)驗值，采用Apdex聯(lián)盟的建議值：3秒、3秒-12秒，12秒以上。0-3秒的業(yè)務(wù)處理響應(yīng)時間是非常理想的，而3秒-12秒則是普遍可容忍的時間，但超過12秒的響應(yīng)時間，用戶一般不會接受，可能選擇刷新，甚至放棄操作。

這樣的經(jīng)驗值在實際測試中對確定響應(yīng)時間有很高的參考價值，當(dāng)然響應(yīng)時間還應(yīng)該根據(jù)業(yè)務(wù)類型確定，而不能僅從用戶的感官考慮。本次項目測試采用常規(guī)的5秒為目標(biāo)，也就是說ECShop平臺處理登陸、商品隨機(jī)瀏覽購買等業(yè)務(wù)的服務(wù)器響應(yīng)時間均不超過5秒。

單天15萬業(yè)務(wù)量，表明在一天時間內(nèi)總的業(yè)務(wù)量為15萬，但未明確是哪些業(yè)務(wù)的數(shù)據(jù)量疊加，還是每項業(yè)務(wù)都是此要求。此處假定單項業(yè)務(wù)每天有15萬的數(shù)據(jù)量。

從圖2得知，用戶訪問并非是均分在24個小時內(nèi)，因此，在沒有歷史數(shù)據(jù)可依據(jù)的情況下，利用經(jīng)濟(jì)學(xué)中的“二八原則”進(jìn)行分析，80%的業(yè)務(wù)量集中在20%的時間段內(nèi)。單天峰值時間段共有2個：15點-17點，21點-23點，可得如下業(yè)務(wù)量分解數(shù)據(jù)：

15萬*80%=12萬

24個小時*20%=4.8小時

4小時/4.8小時=83%

以15點-17點，21點-23點為總考察時間段，則期望業(yè)務(wù)量值為：

12萬*83%=9.96萬

以15點-17點為測試考察段，則期望業(yè)務(wù)量值為：

12萬*（2小時/4.8小時）=5萬

通過上述分析，需測試ECShop平臺在2小時內(nèi)支持5萬用戶登陸及商品隨機(jī)瀏覽購買。

除了軟件性能要求外，還應(yīng)該對硬件資源進(jìn)行監(jiān)控，比如服務(wù)器CPU使用率、內(nèi)存使用率、網(wǎng)絡(luò)帶寬等。如果用戶需求、項目組或其他利益相關(guān)方未提出性能指標(biāo)要求，則可按照行業(yè)經(jīng)驗，CPU使用率不超過80%、內(nèi)存使用率不超過80%、網(wǎng)絡(luò)帶寬占用不超過50%等。CPU使用率超過80%表明CPU應(yīng)用繁忙，如果持續(xù)維持在90%甚至更高，很可能導(dǎo)致機(jī)器響應(yīng)慢、死機(jī)等問題。當(dāng)然，過低也不好，說明CPU比較空閑，可能存在資源浪費的問題。對于內(nèi)存存在同樣的問題。當(dāng)然，80%只是一個經(jīng)驗值，最終的性能測試指標(biāo)需經(jīng)過評審才能最終確定。

通過上述業(yè)務(wù)數(shù)據(jù)分析，最終得到本次測試的性能需求指標(biāo)如表3所示：

表 3 ECShop平臺性能需求指標(biāo)

測試項響應(yīng)時間業(yè)務(wù)成功率業(yè)務(wù)量并發(fā)測試CPU使用率內(nèi)存使用率登陸<=5秒100%2小時5萬次100<=80%<=80%隨機(jī)購買商品<=5秒100%2小時5萬次100<=80%<=80%

得出本次測試的性能參考指標(biāo)后，測試工程師即可進(jìn)行性能測試模型的建立。