“為了測試目的而設計的測試用例場景”主要根據測試設計人員的經驗來進行，但是仍然要參 考用戶的實際場景，用戶實際使用場景是設計所有測試用例的依據。例如一些業務系統，雖然備份歷史數據的周期為一年，但是設計大數據量測試用例時仍然包含了 系統運行一個月、半年等的數據量模擬測試，因為這些均屬於用戶的典型場景。
綜合上面可以看出，性能測試用例設計首先要分析出用戶現實中的典型場景，然后參照典型場景進行設計。實際項目中分析場景一般不會孤立的分析某一特定類型場景，而是把兩種或者幾種類型場景結合起來進行分析設計，這樣做主要是為了選擇更典型的場景和節省一些測試成本。
例子
下面將以圖1所示的某視頻點播網站做為示例，開始逐一討論各類測試用例設計的細節。其中圖1顯示了該視頻點播網站的主要業務及使用場景。
確定用戶使用系統情況的方法
確定用戶對系統的使用情況是設計用例具體數據的基礎，后面並發用戶數據設計、疲勞強度設計、以及各種場景設計都要依賴對用戶使用系統情況的分析結果。分析用戶使用情況經常采用現場調查和分析系統日志兩種方法。 * 用戶現場調查。實際就是通過和用戶進行溝通，進而確定用戶的人員組成情況。這類方法適用於用戶群體固定且目標測試系統沒有投產前的情況。 * 分析系統日志。很多時候，通過和用戶溝通不能掌握其使用系統的詳細情況，尤其是諸如圖1的網站業務系統，因為目標用戶使用系統的情況是不確定的。當用戶比較分散、現場調查比較困難時，可以采用對系統日志進行分析的方法，以此作為對用戶現場調查信息的補充。 大多數的系統都會對用戶使用系統的情況進行日志管理，因此可以對日志進行分析，日志分析方法適用於已經投產或者試運行的系統。 在具體設計過程中，一般是兩種方法結合使用。圖1的網上視頻點播系統就是通過兩種方法得到的測試數據:通過和用戶進行溝通得到全國各地維護人員使用系統 的大概情況，然后通過對系統一個月的日志進行分析得出其它用戶使用系統的情況，最后綜合在一起就得到了系統的使用情況圖。 也許有人會問:為什么不通過日志分析得出全部的用戶使用情況？主要原因有兩個:一是日志分析不一定能得出全部的使用情況，可能產生偏差，例如用戶反復登陸系統、注冊多個帳號都會影響統計結果;二是日志分析往往較用戶調研成本大，因為多會涉及開發工作。
並發用戶數量設計
並發用戶尤其是最大並發用戶數量的設計一直是網上很多測試論壇津津樂道的話題。 在設計並發用戶數量前，首先要了解確定系統最大並發用戶數量的方法。下面舉一個估計最大並發用戶數量的例子。 某OA系統的使用用戶為600，預計使用周期內不會發生大的變化，通過分析日志得出系統的最大在線數目為200左右，分析其最大並發用戶數量。 步驟1:OA系統的最大並發用戶數目一般在系統使用人數的5～20％之間，此系統使用頻度不高，因此我們估計最大並發用戶數量為總使用人數的15％，根據經驗得出第一個最大並發用戶數90（600×15％＝90）; 步驟2:通常OA系統的並發數為在線數的30％左右，我們根據經驗得出第二個最大並發用戶數60（200×30％＝60）; 步驟3:比較前面的結果，最后取90作為最大並發用戶數目。 完成最大並發用戶數量的評估后，接下來就可以設計每個用例要模擬的用戶數量。
通過表1可以看出並發用戶數量的設計很簡單，基本是按照最大並發用戶數量的百分比來設計，例如可以按照最大用戶的20％不斷增加來設計並發用戶數量，直到達到最大並發用戶數量。 綜合上面的內容，可以看出用戶並發數量設計是很靈活的，不用拘泥於公式和形式，只要充分考慮到用戶現在和未來的增長趨勢就可以了。
系統不同時間段場景的設計
不同時間段的場景更接近用戶使用情況，也是設計核心模塊和組合模塊並發性能測試用例的基礎。例如圖1的網上電影點播系統，每兩個小時使用系統的情況都是不同的，因此需要設計一些典型的場景。 不同時間段場景分析的數據來源主要是前面的需求分析和日志分析結果。通過圖1，很容易看出各個時間段不同模塊的用戶是如何並發的。有了上面的資料，就可以設計各個時間段的組合模塊測試用例。下面是圖1所示的網上電影點播系統“0～2點” 場景的一個測試用例。 上面場景的並發人數只是一個實際例子，如何設計最大並發用戶可以參考本節“並發用戶數量設計”和“業務模式設計”的相關內容。 不同時間段場景設計的基本原則有兩個:一是選擇典型的場景進行測試，尤其要選擇場景中並發用戶數目較大的場景;二是要覆蓋全面，即設計出的用例要覆蓋到壓力可能較大的時間段。
業務模式的設計
業務模式的設計是不同時間段場景設計的特例，也是設計核心模塊和組合模塊並發性能測試用例的基礎，設計業務模式的目的是專注於某些功能模塊的組 合。通常按時間段來設計場景會涉及很多模塊，如果系統存在由應用軟件引起的瓶頸則很難對定位，因此抽象出特定的業務模式來進行用例的設計。 以圖1的網上視頻點播系統為例，就需要對系統維護、電影欣賞、頁面查詢瀏覽三種模式進行用例的設計。 按業務模式和時間段的場景來設計性能測試用例時，會涉及到如何設計每個模塊並發用戶數目的問題。通常會取各個相關模塊在24小時內最大的並發用戶數目進 行組合。例如電影瀏覽模式在12～14點場景設計的測試用例如下:仍然取了24小時內最大值280而不是210，理由是系統登陸用戶在 10～12點內達到了高峰280。這條原則看似和前面測試最大並發用戶的方法有些沖突，實際思想還是一致的，只是這里關注每個業務模塊的最大並發用戶數。 從這里可以看出並發用戶數目的設計一定不能拘泥於形式。注意這里沒有考慮用戶數目在軟件生存期內增加的情形，讀者可以結合前面最大用戶評估方法來確定最大用戶並發數目，然后自己練習一下如何設計這兩個性能測試用例的並發用戶數目。 大數據量測試用例的設計
大數據量測試主要分為歷史數據引起的大數據量測試和運行時大數據量測試兩種。下面討論一下如何來設計大數據量性能測試用例中的數據。 歷史數據相關的大數據量測試設計主要以歷史場景作為依據，通常首先確定系統數據的最長遷移周期，這個周期值的使用情況就是一個典型場景。 運行時大數量測試主要是通過模擬系統運行時可能產生的大數據量來進行測試。例如圖2的網上視頻點播系統，可以模擬大量用戶同時下載或者播放電影的情況。這類測試用例通常根據實際情況自己去分析設計。 大數據量測試設計時可以借用前面的設計成果，因此相對容易。
一些特定測試用例設計
疲勞強度測試、最大用戶測試、容量測試等一些特殊測試的用例設計，會根據用戶的需求進行設計，因為這類用例的相關要求通常十分明確。 通過分析場景來設計性能測試，可以使性能測試用例更接近用戶實際使用情況，更容易發現系統瓶頸。這種方法抓住了性能測試的關鍵點，做到有的放矢，大大降低了測試成本。
性能測試分類
性能測試按照場景不同一般可以分為兩大類，一類是為了測試目的而進行的場景測試，另外一類是基於用戶實際情況而進行的場景測試。因此，性能測試用例的設計應該面向性能測試場景來進行。 常見的三類用戶場景
一天內不同時間段的使用場景。在同一天內，大多數系統的使用情況都會隨着時間發生變化。例如對於新浪、網易等門戶網站，在周一到周五早上剛一上班時，可能郵件系統用戶比較多，而上班前或者中午休息時間則瀏覽新聞的用戶較多。 系統運行不同時期的場景。系統運行不同時期的場景是大數據量性能測試用例設計的依據。隨着時間的推移，系統歷史數據將會不斷增加，這將對系統響應速度產生很大的影響。 不同業務模式下的場景。同一系統可能會處於不同的業務模式，例如很多電子商務系統在早上8點到10點以瀏覽模式為主，10點到下午3點以定購模式為主，而在下午3點以后可能以混合模式為主。