誤區4:性能測試就是用戶并發測試
仍然有很多人(尤其是開發人員和部分項目實施人員)一提到性能測試,就會聯想到并發用戶測試,進而認為性能測試就是“測試一下多用戶的并發情況”。嚴格地講,性能測試是以用戶并發測試為主的測試。實際性能測試還包含強度測試、大數據量測試等許多內容。
誤區5:在開發環境下進行性能測試
很多時候,在軟件開發完成后進行性能測試,對軟件性能進行評估。實際上大多數的開發環境因為硬件條件比較差,所以反映不了過多的性能問題。
因此性能測試要盡量在高配置的用戶投產環境下進行。但是有兩種可以例外的情況:一種是為了發現某些功能方面的問題,例如為了發現并發算法的一些缺陷;另外一種就是有非常好的硬件資源。
誤區6:系統存在瓶頸,不可以使用。
系統發現了瓶頸,的確是很讓人擔心的一件事情。不過不要緊,很多的瓶頸可以不必去理會。發現瓶頸的目的主要是為了掌握系統特性,為改善和擴展系統提供依據。因此在性能方面給系統留有30%左右的擴展空間就可以了。
上面列舉的都是日常性能測試工作中相關人員常犯的錯誤,這些觀點只在極其特殊的情況下才正確。希望讀者了解這些常見的性能測試誤區后,能在以后的工作中避免類似的情況。
基于場景的性能測試設計
由于開發環境硬件配置不高,基于用戶的測試多在用戶現場進行,而為了測試目的而進行的測試多在開發環境即開發團隊內部進行,不過兩者進行的場所沒有嚴格的界限,例如也可以在開發團隊內部模擬用戶的環境進行性能測試。
“為了測試目的而設計的測試用例場景”主要根據測試設計人員的經驗來進行,但是仍然要參考用戶的實際場景,用戶實際使用場景是設計所有測試用例的依據。例如一些業務系統,雖然備份歷史數據的周期為一年,但是設計大數據量測試用例時仍然包含了系統運行一個月、半年等的數據量模擬測試,因為這些均屬于用戶的典型場景。
綜合上面可以看出,性能測試用例設計首先要分析出用戶現實中的典型場景,然后參照典型場景進行設計。實際項目中分析場景一般不會孤立的分析某一特定類型場景,而是把兩種或者幾種類型場景結合起來進行分析設計,這樣做主要是為了選擇更典型的場景和節省一些測試成本。
下面將以圖1所示的某視頻點播網站做為示例,開始逐一討論各類測試用例設計的細節。其中圖1顯示了該視頻點播網站的主要業務及使用場景。

圖1 網上視頻點播系統使用情況圖
文章來源于領測軟件測試網 http://www.kjueaiud.com/