基於場景的性能測試設計 軟件測試
性能測試在測試中往往不被重視，而項目中由於系統性能不合格會給企業帶來巨大的損失。基於場景的性能測試設計能避免性能測試的誤區。
很多企業在性能測試工作中存在一些常見誤區，其中部分企業選擇基於場景的設計性能測試來避免這些誤區，因爲這樣可以大幅度降低執行成本，同時提高性能測試執行效率。
性能測試常見誤區
請看下面一個性能測試小案例:
某公司OA產品的新版本即將發佈。爲了看看系統的性能，決定安排測試工程師A君執行性能測試任務。A君做法如下:
1.找到一臺PC機，CPU主頻1G，內存512M，……;
2.在找到的PC機上搭建了測試環境:安裝了Oracle9i、Weblogic等系統軟件;
3.在工作機上安裝了LoadRunner7.8;
4.然後錄製了登陸、發佈公告等功能;
5.開始設置30、50、100、500不同的併發用戶數目進行併發;
6.最後得出結論:系統只能運行80個左右的併發用戶……。
無疑上面的做法存在很多不合理的地方，例如測試內容太少、測試服務器配置太低等。現實工作中，儘管性能測試以其在測試中獨特的地位越來越爲軟件測試人員、開發人員和用戶所重視，但是不管是測試人員還是開發人員，仍然在認識上存在這樣或者那樣的誤區。
誤區1:提高硬件配置可以直接提高性能
這是以前系統規模不大時期留下來的認識。DOS時代以及後來Windows操作系統流行的初期，軟件規模一般較小，而硬件的更新卻是日新月異，軟件性能一般不是突出問題，因爲只要升級一下硬件，很容易就解決了性能問題。
現在隨着軟件規模的擴大，提高硬件配置只是解決性能問題的一個基本手段。因爲如果軟件自身存在性能問題，再多的資源可能也不夠用，例如內存泄漏問題，隨着時間的增加，內存終究會被耗盡，最後導致系統崩潰。
因此，如果用戶對軟件的性能要求較高，這意味着不但要從硬件方面來保證性能，還要從數據庫、WebServer、操作系統配置等方面入手來提高性能，同時開發的軟件系統本身也要進行優化，以便全面提高性能。
誤區2:在其它測試完成後進行性能測試
這是目前特別普遍的一種現象，例如前面的A君的現象就是沒有意識到性能測試的重要性。這種做法最嚴重的後果是如果性能問題是由軟件系統本身產生的，可能會無法根治性能問題。例如架構設計方面的失誤，可能意味着軟件系統將被廢掉。
當然這並不意味所有的性能測試都要儘早進行，性能測試的啓動時間要由軟件特點來決定。
誤區3:性能測試獨立於功能測試
功能測試可以發現性能問題，性能測試也能發現功能問題。性能測試和功能測試是緊密聯繫在一起的，原因之一是由於很多性能問題是由軟件自身功能缺陷引起的。如果應用系統功能不完善或者代碼運行效率低下，通常會帶來一些性能問題。功能測試通常要先於性能測試執行或者同步進行，軟件功能完善可以保證性能測試進行得更加順利。
誤區4:性能測試就是用戶併發測試
仍然有很多人(尤其是開發人員和部分項目實施人員)一提到性能測試，就會聯想到併發用戶測試，進而認爲性能測試就是“測試一下多用戶的併發情況”。嚴格地講，性能測試是以用戶併發測試爲主的測試。實際性能測試還包含強度測試、大數據量測試等許多內容。
誤區5:在開發環境下進行性能測試
很多時候，在軟件開發完成後進行性能測試，對軟件性能進行評估。實際上大多數的開發環境因爲硬件條件比較差，所以反映不了過多的性能問題。
因此性能測試要儘量在高配置的用戶投產環境下進行。但是有兩種可以例外的情況:一種是爲了發現某些功能方面的問題，例如爲了發現併發算法的一些缺陷;另外一種就是有非常好的硬件資源。
誤區6:系統存在瓶頸，不可以使用。
系統發現了瓶頸，的確是很讓人擔心的一件事情。不過不要緊，很多的瓶頸可以不必去理會。發現瓶頸的目的主要是爲了掌握系統特性，爲改善和擴展系統提供依據。因此在性能方面給系統留有30%左右的擴展空間就可以了。
上面列舉的都是日常性能測試工作中相關人員常犯的錯誤，這些觀點只在極其特殊的情況下才正確。希望讀者瞭解這些常見的性能測試誤區後，能在以後的工作中避免類似的情況。
基於場景的性能測試設計
由於開發環境硬件配置不高，基於用戶的測試多在用戶現場進行，而爲了測試目的而進行的測試多在開發環境即開發團隊內部進行，不過兩者進行的場所沒有嚴格的界限，例如也可以在開發團隊內部模擬用戶的環境進行性能測試。
“爲了測試目的而設計的測試用例場景”主要根據測試設計人員的經驗來進行，但是仍然要參考用戶的實際場景，用戶實際使用場景是設計所有測試用例的依據。例如一些業務系統，雖然備份歷史數據的週期爲一年，但是設計大數據量測試用例時仍然包含了系統運行一個月、半年等的數據量模擬測試，因爲這些均屬於用戶的典型場景。
綜合上面可以看出，性能測試用例設計首先要分析出用戶現實中的典型場景，然後參照典型場景進行設計。實際項目中分析場景一般不會孤立的分析某一特定類型場景，而是把兩種或者幾種類型場景結合起來進行分析設計，這樣做主要是爲了選擇更典型的場景和節省一些測試成本。
下面將以圖1所示的某視頻點播網站做爲示例，開始逐一討論各類測試用例設計的細節。其中圖1顯示了該視頻點播網站的主要業務及使用場景。
圖1 網上視頻點播系統使用情況圖
確定用戶使用系統情況的方法
確定用戶對系統的使用情況是設計用例具體數據的基礎，後面併發用戶數據設計、疲勞強度設計、以及各種場景設計都要依賴對用戶使用系統情況的分析結果。分析用戶使用情況經常採用現場調查和分析系統日誌兩種方法。
* 用戶現場調查。實際就是通過和用戶進行溝通，進而確定用戶的人員組成情況。這類方法適用於用戶羣體固定且目標測試系統沒有投產前的情況。
* 分析系統日誌。很多時候，通過和用戶溝通不能掌握其使用系統的詳細情況，尤其是諸如圖1的網站業務系統，因爲目標用戶使用系統的情況是不確定的。當用戶比較分散、現場調查比較困難時，可以採用對系統日誌進行分析的方法，以此作爲對用戶現場調查信息的補充。
大多數的系統都會對用戶使用系統的情況進行日誌管理，因此可以對日誌進行分析，日誌分析方法適用於已經投產或者試運行的系統。
在具體設計過程中，一般是兩種方法結合使用。圖1的網上視頻點播系統就是通過兩種方法得到的測試數據:通過和用戶進行溝通得到全國各地維護人員使用系統的大概情況，然後通過對系統一個月的日誌進行分析得出其它用戶使用系統的情況，最後綜合在一起就得到了系統的使用情況圖。
也許有人會問:爲什麼不通過日誌分析得出全部的用戶使用情況?主要原因有兩個:一是日誌分析不一定能得出全部的使用情況，可能產生偏差，例如用戶反覆登陸系統、註冊多個帳號都會影響統計結果;二是日誌分析往往較用戶調研成本大，因爲多會涉及開發工作。
併發用戶數量設計
併發用戶尤其是最大併發用戶數量的設計一直是網上很多測試論壇津津樂道的話題。
在設計併發用戶數量前，首先要了解確定系統最大併發用戶數量的方法。下面舉一個估計最大併發用戶數量的例子。
某OA系統的使用用戶爲600，預計使用週期內不會發生大的變化，通過分析日誌得出系統的最大在線數目爲200左右，分析其最大併發用戶數量。
步驟一: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點以後可能以混合模式爲主。