性能測試基礎實戰

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

一、系統業務特點和用戶行爲分析

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

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

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

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

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

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

 

二、系統性能指標分析

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

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

  1、併發用戶數量設計

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

  a)極限法

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

  b)用戶趨勢分析

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

  c)經驗評估法

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

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

  2、事務平均響應時間

  響應時間就是用戶感受軟件系統爲其服務所耗費的時間,這與計算機性能、網絡速度和帶寬等等有關。設計事務平均響應時間指標也是性能測試用例設計的重要內容。

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

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

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

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

 

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

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

1、單業務測試

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

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

2、混合業務測試

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

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

  以下爲一個混合測試用例實例:

 

3、疲勞強度測試

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

 

 總結:

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

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章