性能測試案例設計策略

性能測試在軟體品質保證中起著重要的作用，它包括的測試內容豐富多樣。同一個系統，不同的測試設計及測試過程會導致不同的結果，也會有不同的解讀。合理的測試規劃與設計是至關重要的。本文重點介紹如何結合用戶實際業務特點制定有效的性能測試案例。

性能測試在軟體品質保證中起著重要的作用，它包括的測試內容豐富多樣。同一個系統，不同的測試設計及測試過程會導致不同的結果，也會有不同的解讀。合理的測試規劃與設計是至關重要的。本文重點介紹如何結合用戶實際業務特點制定有效的性能測試案例。

一、系統業務特點和使用者行為分析

使用者行為反映了使用者對系統的使用模式和應用背景，在性能測試之前，我們首先需要分析使用者的使用習慣，確定系統的典型業務及發生時間。分析使用者行為是設計性能測試案例的第一步。

1、系統使用高峰時段分析

對於很多大型系統，都有業務集中開展使用的情況出現，即系統使用的高峰。這類系統使用高峰可能出現在一天、一月、一年中的某個時間點上或時間段上。例如在同一天內，大多數系統的使用情況都會隨著時間發生變化，對於這一類系統不同的業務高峰對應的時間也不同。例如對於新浪、網易等門戶網站，在週一到週五早上剛一上班時，可能郵件系統使用者比較多，而上班前或者中午休息時間則流覽新聞的用戶較多；而對於一般的OA系統則早上閱讀公告的較多，其他時間可能很多人沒有使用系統或者僅有少量的秘書或領導在起草和審批公文。電信繳費系統很可能在月末會出現集中交費的情況。計生委的特別扶助等個案資訊上報一般集中在每年的某個月份進行。

確定系統使用高峰時段，有利於我們進一步確定系統在高峰時段的性能需求，比如高峰時段的併發用戶支援需求，高峰時期的業務回應時間需求等。

2、系統高峰期業務應用分析

在系統不同的高峰期，同一系統可能會處於不同的業務模式，因此需要對系統高峰期的業務應用進行分析。其目標是為了通過分析高峰期的應用來確定高峰期的業務應用模型是單一業務類型還是混合業務類型，這對於後期的測試案例執行策略的設計至關重要。例如很多電子商務系統在早上8點到10點以流覽模式為主，10點到下午3點以定購模式為主，而在下午3點以後可能以混合模式為主。因此需要分析哪些業務應用是典型的即壓力較大的業務，進而對這些業務應用單獨進行測試，這樣做可以有效的對系統瓶頸進行隔離定位。

二、系統性能指標分析

合理的設計不可能是憑空想像，而是要基於系統的業務需求及使用者使用習慣。在性能測試中，最重要的兩個指標是確定系統需要承受的併發使用者數量，及在一定的使用者規模下系統能夠提供的應用回應時間。

下面重點介紹一下如何對併發使用者數量和平均事務回應時間這兩個性能指標進行設計：

1、併發用戶數量設計

併發使用者數設計必須以系統真實使用中可能出現的最大用戶數為基礎進行核算。下面介紹根據系統的最大使用人數或者最大線上人數來評估最大用戶數的方法。

a)    極限法

對於系統已經投產或者目標使用者群體不確定的門戶網站，可以通過分析日誌，也可以使用系統已經註冊的使用者數量做為系統最大使用者數，然後按照經驗公式來估算最大併發用戶數。

b)    用戶趨勢分析

對軟體生存週期內的使用者未來走勢進行分析，預測系統可能達到的最大使用者數，從而估計系統的最大併發使用者數，這種方法多用於系統使用者數目逐漸增加的情況。

c)    經驗評估法

按照經驗來評估系統可能的最大併發使用者數，這種方法多用於系統的使用使用者數目相對穩定且比較明確的系統。

併發使用者數的設計基本是按照系統最大使用者數的百分比來設計的，對於某一特定案例，需要注意併發使用者設計的最大值一般不會超過前面計算的系統實際使用的最大使用者數的30% ，除非是為了測試系統能支援的最大併發用戶數量。

2、事務平均回應時間

回應時間就是使用者感受軟體系統為其服務所耗費的時間，這與電腦性能、網路速度和頻寬等等有關。設計事務平均回應時間指標也是性能測試案例設計的重要內容。

目前關於事務平均回應時間指標設計基本可參考以下2種方式：

對於在需求分析和設計階段已經明確提出回應時間性能指標要求的系統，如要求”系統回應時間不得超過20秒”，平均回應時間確定應以需求為准。

對於沒有明確性能需求的系統，事務平均回應時間應以用戶使用感受或者需求方指定為准。一般來講有3秒以內用戶會認為回應時間較快；5秒以內用戶認為可以接受，超過8秒，一般用戶會認為回應太慢。當然回應時間的長短還和業務類型緊密相關，提交類業務操作對回應時間要求一般而言比統計類的業務操作要求更高。

其他性能指標的設計可以採取事務平均回應時間指標相同的設計方式來進行。

三、性能測試執行策略分析

性能測試執行策略需要注意兩點：一是選擇典型的業務進行測試，尤其要選擇併發使用者數目較大的業務；二是要覆蓋全面，即設計出的案例要覆蓋到系統高峰期的主要業務。在性能測試執行過程中，明確每個業務的參與者人數、比例和具體行為是非常重要的，這些都是性能測試案例設計的基礎。下面重點介紹一下如何制定單業務測試、混合業務測試和疲勞強度測試的具體執行策略。

1、單業務測試

性能測試不可能對所有功能都進行測試，所以需要抽象一些特定的獨立業務來進行案例的設計。獨立業務實際是指一些核心業務模組對應的業務，這些模組通常具有功能比較複雜，使用比較頻繁，屬於核心業務等特點。針對這類獨立業務進行的性能測試稱之為單業務性能測試。

使用者併發能力測試是單業務性能測試的重點，使用者併發能力測試是指模擬一定數量的用戶同時使用某一核心模組的相同或者不同的功能，並且持續一段時間，考察系統能夠支援指定的使用者規模。

2、混合業務測試

在系統真實應用中，通常不會存在所有用戶只使用一個或者幾個核心業務模組的情況，即一個應用系統的每個功能模組都可能被使用到；所以性能測試既要類比多使用者的相同操作，又要模擬多用戶的不同操作。

混合業務性能測試是最接近使用者實際使用情況的測試，也是性能測試的一個必要內容。在混合業務測試中，通常需要按照使用者的實際使用人數比例來類比各個模組的組合併發情況。混合業務測試的突出特點是根據使用者使用系統的情況分成不同的使用者組進行併發，每組的使用者比例要根據實際情況來匹配，通常會取各個相關模組最大的併發使用者數目進行組合。

3、疲勞強度測試

疲勞強度測試是指在系統正常運行的情況下，以一定的負載壓力來長時間運行系統的測試。疲勞強度測試的主要特點是長時間對目標測試系統加壓，目的是測試系統的穩定性，持續時間一般在1小時以上；疲勞強度測試屬於用戶併發測試的延續，因此核心內容仍然是核心模組使用者併發和組合模組使用者併發，在編寫測試案例時需要編寫不同參數或者負載條件下的多個測試案例，可以參考混合業務併發性能測試案例的設計內容，通常修改相應的場景參數就可實現所需要的測試案例。

總結

本文重點討論了如何結合用戶實際業務特點制定有效的性能測試案例，通過分析用戶實際業務特點來設計性能測試，可以使性能測試案例更接近使用者實際使用情況，更容易發現系統瓶頸。這種方法抓住了性能測試的關鍵點，做到有的放矢，大大降低了測試成本。