注：轉(zhuǎn)載請注明出處與原文地址。 

在各類軟件測試工作中，性能測試往往不被重視，而項目中由于系統(tǒng)性能不合格帶來損失的例子卻非常多。造成這種現(xiàn)象的原因之一就是各個公司習慣壓縮測試成本，而在性能測試方面的投入則更少。

本文重點介紹如何基于場景來設計性能測試。選擇典型的用戶場景來進行測試，不但可以大大降低執(zhí)行成本，更能提高性能測試執(zhí)行效率。

在以前的《治療軟件亞健康》中，筆者重點討論了運用“全面性能測試模型”來組織各類性能測試的方法?！?/span>全面性能測試模型”提出了設計性能測試用例的框架，在實際項目中通過它可以確定性能測試用例的范圍和類別。而在測試用例內(nèi)容確定后，接下來就要設計各類性能測試用例中的具體內(nèi)容。

性能測試按照場景不同一般可以分為兩大類，一類是為了測試目的而進行的場景測試，另外一類是基于用戶實際情況而進行的場景測試。因此，性能測試用例的設計應該面向性能測試場景來進行。

實際上，由于開發(fā)環(huán)境硬件配置不高，基于用戶的測試多在用戶現(xiàn)場進行，而為了測試目的而進行的測試多在開發(fā)環(huán)境即開發(fā)團隊內(nèi)部進行，不過兩者進行的場所沒有嚴格的界限，例如也可以在開發(fā)團隊內(nèi)部模擬用戶的環(huán)境進行性能測試。

“為了測試目的而設計的測試用例場景”主要根據(jù)測試設計人員的經(jīng)驗來進行，但是仍然要參考用戶的實際場景，用戶實際使用場景是設計所有測試用例的依據(jù)。例如一些業(yè)務系統(tǒng)，雖然備份歷史數(shù)據(jù)的周期為一年，但是設計大數(shù)據(jù)量測試用例時仍然包含了系統(tǒng)運行一個月、半年等的數(shù)據(jù)量模擬測試，因為這些均屬于用戶的典型場景。

綜合上面可以看出，性能測試用例設計首先要分析出用戶現(xiàn)實中的典型場景，然后參照典型場景進行設計。下面詳細介紹一下常見的三類用戶場景：

一天內(nèi)不同時間段的使用場景。在同一天內(nèi)，大多數(shù)系統(tǒng)的使用情況都會隨著時間發(fā)生變化。例如對于新浪、網(wǎng)易等門戶網(wǎng)站，在周一到周五早上剛一上班時，可能郵件系統(tǒng)用戶比較多，而上班前或者中午休息時間則瀏覽新聞的用戶較多；而對于一般的OA系統(tǒng)則早上閱讀公告的較多，其他時間可能很多人沒有使用系統(tǒng)或者僅有少量的秘書或領(lǐng)導在起草和審批公文。這類場景分析的任務是找出對系統(tǒng)產(chǎn)生壓力較大的場景進行測試。

系統(tǒng)運行不同時期的場景。系統(tǒng)運行不同時期的場景是大數(shù)據(jù)量性能測試用例設計的依據(jù)。隨著時間的推移，系統(tǒng)歷史數(shù)據(jù)將會不斷增加，這將對系統(tǒng)響應速度產(chǎn)生很大的影響。大數(shù)據(jù)量性能測試通常會模擬一個月、一季度、半年、一年、……的數(shù)據(jù)量進行測試，其中數(shù)據(jù)量的上限是系統(tǒng)歷史記錄轉(zhuǎn)移前可能產(chǎn)生的最大數(shù)據(jù)量，模擬的時間點是系統(tǒng)預計轉(zhuǎn)移數(shù)據(jù)的某一時間。

不同業(yè)務模式下的場景。同一系統(tǒng)可能會處于不同的業(yè)務模式，例如很多電子商務系統(tǒng)在早上8點到10點以瀏覽模式為主，10點到下午3點以定購模式為主，而在下午3點以后可能以混合模式為主。因此需要分析哪些模式是典型的即壓力較大的模式，進而對這些模式單獨進行測試，這樣做可以有效的對系統(tǒng)瓶頸進行隔離定位。與“一天內(nèi)不同時間段的場景測試”不同，“不同業(yè)務模式下的場景測試”更專注于某一種模式的測試，而“一天內(nèi)不同時間段的場景測試”則多數(shù)是不同模式的混合場景，更接近用戶的實際使用情況。

上面只介紹了三種典型的場景，實際項目中分析場景一般不會孤立的分析某一特定類型場景，而是把兩種或者幾種類型場景結(jié)合起來進行分析設計，這樣做主要是為了選擇更典型的場景和節(jié)省一些測試成本。

有了上面的基礎(chǔ)知識，下面開始逐一討論各類測試用例設計的細節(jié)。在下面的討論中，將以圖2所示的某視頻點播網(wǎng)站做為示例，圖2顯示了該視頻點播網(wǎng)站的主要業(yè)務以及各個時間段使用場景。

圖2網(wǎng)上視頻點播系統(tǒng)使用情況圖

1、 確定用戶使用系統(tǒng)情況的方法

確定用戶對系統(tǒng)的使用情況是設計用例具體數(shù)據(jù)的基礎(chǔ)，后面并發(fā)用戶數(shù)據(jù)設計、疲勞強度設計、以及各種場景設計都要依賴對用戶使用系統(tǒng)情況的分析結(jié)果。分析用戶使用情況經(jīng)常采用現(xiàn)場調(diào)查和分析系統(tǒng)日志兩種方法。

l  用戶現(xiàn)場調(diào)查

用戶現(xiàn)場調(diào)查實際就是通過和用戶進行溝通，進而確定用戶的人員組成情況。這類方法適用于用戶群體固定且目標測試系統(tǒng)沒有投產(chǎn)前的情況。

l  分析系統(tǒng)日志

很多時候，通過和用戶溝通不能掌握其使用系統(tǒng)的詳細情況，尤其是諸如圖2的網(wǎng)站業(yè)務系統(tǒng)，因為目標用戶使用系統(tǒng)的情況是不確定的。當用戶比較分散、現(xiàn)場調(diào)查比較困難時，可以采用對系統(tǒng)日志進行分析的方法，以此作為對用戶現(xiàn)場調(diào)查信息的補充。

大多數(shù)的系統(tǒng)都會對用戶使用系統(tǒng)的情況進行日志管理，因此可以對日志進行分析，日志分析方法適用于已經(jīng)投產(chǎn)或者試運行的系統(tǒng)。如果沒有系統(tǒng)日志功能，可以和開發(fā)人員進行溝通，在測試過程中增加日志管理功能。通常分析系統(tǒng)日志可能要開發(fā)一些程序來對其進行統(tǒng)計分析。

在具體設計過程中，一般是兩種方法結(jié)合使用。圖2的網(wǎng)上視頻點播系統(tǒng)就是通過兩種方法得到的測試數(shù)據(jù)：通過和用戶進行溝通得到全國各地維護人員使用系統(tǒng)的大概情況，然后通過對系統(tǒng)一個月的日志進行分析得出其它用戶使用系統(tǒng)的情況，最后綜合在一起就得到了系統(tǒng)的使用情況圖。

也許有人會問：為什么不通過日志分析得出全部的用戶使用情況？主要原因有兩個：一是日志分析不一定能得出全部的使用情況，可能產(chǎn)生偏差，例如用戶反復登陸系統(tǒng)、注冊多個賬號都會影響統(tǒng)計結(jié)果；二是日志分析往往較用戶調(diào)研成本大，因為多會涉及開發(fā)工作。

2、 并發(fā)用戶數(shù)量設計

并發(fā)用戶尤其是最大并發(fā)用戶數(shù)量的設計一直是網(wǎng)上很多測試論壇津津樂道的話題。在前面文章中，已經(jīng)介紹了并發(fā)用戶和并發(fā)用戶數(shù)量兩個概念，下面將在其基礎(chǔ)上討論一下如何在性能測試用例中設計并發(fā)用戶數(shù)量。

在設計并發(fā)用戶數(shù)量前，首先要了解確定系統(tǒng)最大并發(fā)用戶數(shù)量的方法。下面介紹根據(jù)系統(tǒng)的最大使用人數(shù)或者最大在線數(shù)量來評估最大并發(fā)用戶數(shù)量的方法（注：這里的最大并發(fā)用戶數(shù)量不是指系統(tǒng)支持的最大并發(fā)用戶數(shù)量，而是指系統(tǒng)在生存周期內(nèi)可能達到的最大并發(fā)用戶數(shù)量）。

l  極限法。取最大在線用戶數(shù)作為最大并發(fā)數(shù)，這種方法適用于系統(tǒng)已經(jīng)投產(chǎn)或者目標用戶群體不確定的門戶網(wǎng)站，可以通過分析日志來得出結(jié)果；也可以使用系統(tǒng)已經(jīng)注冊的用戶數(shù)量做為系統(tǒng)的用戶數(shù)量，然后按照經(jīng)驗公式來估算最大并發(fā)用戶數(shù)量。

l  用戶趨勢分析。對軟件生存周期內(nèi)的用戶未來走勢進行分析，預測系統(tǒng)可能達到的最大使用用戶數(shù)目，從而估計系統(tǒng)的最大并發(fā)用戶數(shù)目，這種方法多用于系統(tǒng)用戶數(shù)目逐漸增加的情況。

l  經(jīng)驗評估法。按照經(jīng)驗來評估系統(tǒng)可能的最大并發(fā)用戶數(shù)，這種方法多用于系統(tǒng)的使用用戶數(shù)目相對穩(wěn)定且比較明確的系統(tǒng)。

完成最大并發(fā)用戶數(shù)量的評估后，接下來就可以設計每個用例要模擬的用戶數(shù)量。表1是上面OA系統(tǒng)的一個性能測試用例。

表1 性能測試用例并發(fā)用戶設計示例

通過表1可以看出并發(fā)用戶數(shù)量的設計很簡單，基本是按照最大并發(fā)用戶數(shù)量的百分比來設計，例如可以按照最大用戶的20％不斷增加來設計并發(fā)用戶數(shù)量，直到達到最大并發(fā)用戶數(shù)量。對于某一特定的用例，設計用戶數(shù)量需要注意下面三點：

（1）              按照各類用戶同時遞增的方式來設計用戶數(shù)量。按照遞增的順序設計測試用例是為了按照由淺入深的方法來發(fā)現(xiàn)系統(tǒng)的瓶頸，因此系統(tǒng)的各類用戶應該同時增加。

（2）              并發(fā)用戶數(shù)的最大值一般不會超過前面計算的最大并發(fā)用戶數(shù)量的20％，除非是為了測試系統(tǒng)能支持的最大并發(fā)用戶數(shù)量。

（3）              設計用戶數(shù)量時要考慮成本，因為每組用戶數(shù)都意味著至少執(zhí)行一次測試。

綜合上面的內(nèi)容，可以看出用戶并發(fā)數(shù)量設計是很靈活的，不用拘泥于公式和形式，只要充分考慮到用戶現(xiàn)在和未來的增長趨勢就可以了。

3、 系統(tǒng)不同時間段場景的設計

不同時間段的場景更接近用戶使用情況，也是設計核心模塊和組合模塊并發(fā)性能測試用例的基礎(chǔ)。例如圖2的網(wǎng)上電影點播系統(tǒng)，每兩個小時使用系統(tǒng)的情況都是不同的，因此需要設計一些典型的場景。

不同時間段場景分析的數(shù)據(jù)來源主要是前面的需求分析和日志分析結(jié)果。通過圖2，很容易看出各個時間段不同模塊的用戶是如何并發(fā)的。有了上面的資料，就可以設計各個時間段的組合模塊測試用例。下面是圖2所示的網(wǎng)上電影點播系統(tǒng)“0~2點” 場景的一個測試用例：

上面場景的并發(fā)人數(shù)只是一個實際例子，如何設計最大并發(fā)用戶可以參考本節(jié)“并發(fā)用戶數(shù)量設計”和“業(yè)務模式設計”的相關(guān)內(nèi)容。

不同時間段場景設計的基本原則有兩個：一是選擇典型的場景進行測試，尤其要選擇場景中并發(fā)用戶數(shù)目較大的場景；二是要覆蓋全面，即設計出的用例要覆蓋到壓力可能較大的時間段。

用戶場景的設計一般和后面的業(yè)務模式結(jié)合起來進行，下面會進一步討論兩者如何結(jié)合在一起進行用例設計。

4、 業(yè)務模式的設計

業(yè)務模式的設計是不同時間段場景設計的特例，也是設計核心模塊和組合模塊并發(fā)性能測試用例的基礎(chǔ)，設計業(yè)務模式的目的是專注于某些功能模塊的組合。通常按時間段來設計場景會涉及很多模塊，如果系統(tǒng)存在由應用軟件引起的瓶頸則很難對定位，因此才抽象一些特定的業(yè)務模式來進行用例的設計。

以圖2的網(wǎng)上視頻點播系統(tǒng)為例，就需要對系統(tǒng)維護、電影欣賞、頁面查詢?yōu)g覽三種模式進行用例的設計。

按業(yè)務模式和時間段的場景來設計性能測試用例時，會涉及到如何設計每個模塊并發(fā)用戶數(shù)目的問題。通常會取各個相關(guān)模塊在24小時內(nèi)最大的并發(fā)用戶數(shù)目進行組合。例如電影瀏覽模式在12～14點場景設計的測試用例如下：

這里需要注意雖然在圖2中12～14點內(nèi)系統(tǒng)并發(fā)用戶數(shù)目最多，但是系統(tǒng)登陸用戶仍然取了24小時內(nèi)最大值280而不是210，理由是系統(tǒng)登陸用戶在10～12點內(nèi)達到了高峰280。這條原則看似和前面測試最大并發(fā)用戶的方法有些沖突，實際思想還是一致的，只是這里關(guān)注每個業(yè)務模塊的最大并發(fā)用戶數(shù)。實際加大用戶數(shù)量沒有太大的影響，尤其對于這類用戶數(shù)目逐漸增加的Web系統(tǒng)，多測試一些并發(fā)用戶然后進行調(diào)優(yōu)，更能保證系統(tǒng)的擴展性。

從這里可以看出并發(fā)用戶數(shù)目的設計一定不能拘泥于形式。注意這里沒有考慮用戶數(shù)目在軟件生存期內(nèi)增加的情形，讀者可以結(jié)合前面最大用戶評估方法來確定最大用戶并發(fā)數(shù)目，然后自己練習一下如何設計這兩個性能測試用例的并發(fā)用戶數(shù)目。

5、 大數(shù)據(jù)量測試用例的設計

大數(shù)據(jù)量測試主要分為歷史數(shù)據(jù)引起的大數(shù)據(jù)量測試和運行時大數(shù)據(jù)量測試兩種。下面討論一下如何來設計大數(shù)據(jù)量性能測試用例中的數(shù)據(jù)。

歷史數(shù)據(jù)相關(guān)的大數(shù)據(jù)量測試設計主要以歷史場景作為依據(jù)，通常首先確定系統(tǒng)數(shù)據(jù)的最長遷移周期，這個周期值的使用情況就是一個典型場景。例如歷史數(shù)據(jù)只保留一年，設計用例時就可以把一年作為周期，然后分別設計系統(tǒng)在三個月、半年、一年歷史數(shù)據(jù)量情況下的測試用例。確定了系統(tǒng)的最大數(shù)據(jù)量后，接下來選擇一些前面的核心模塊或者組合模塊的并發(fā)用戶測試用例作為其主要內(nèi)容即可。

運行時大數(shù)量測試主要是通過模擬系統(tǒng)運行時可能產(chǎn)生的大數(shù)據(jù)量來進行測試。例如圖2的網(wǎng)上視頻點播系統(tǒng)，可以模擬大量用戶同時下載或者播放電影的情況。這類測試用例通常根據(jù)實際情況自己去分析設計。

大數(shù)據(jù)量測試設計時可以借用前面的設計成果，因此相對容易。

6、 一些特定測試用例設計

疲勞強度測試、最大用戶測試、容量測試等一些特殊測試的用例設計，會根據(jù)用戶的需求進行設計，因為這類用例的相關(guān)要求通常十分明確。

總結(jié)

本文首先介紹了性能測試的常見誤區(qū)，接下來重點討論了如何基于場景來設計性能測試用例的數(shù)據(jù)。通過分析場景來設計性能測試，可以使性能測試用例更接近用戶實際使用情況，更容易發(fā)現(xiàn)系統(tǒng)瓶頸。這種方法抓住了性能測試的關(guān)鍵點，做到有的放矢，大大降低了測試成本。