如何建立軟件性能測試模型

如何建立軟件性能測試模型 

今天和大家分享的是一個相對寬泛的設計思路，有興趣的朋友可以再補充和細化。在以往的模型設計中，我一般會遵循這個設計步驟：信息調研—場景分析—模型設計。

• 信息調研

按照上線情況將應用系統分為未上線和已上線兩類。

對于未上線的系統的信息調研比較困難（由于各類系統差異較大，今天對于未上線系統的調研與分析就不作深入探討了）。在沒有參考案例的情況下，更多的是與系統的最終用戶和系統設計人員進行溝通。溝通的范圍一般包括：

• 應用系統的類型，如：交易型系統、管理型系統、數據處理型系統等；
• 應用系統的操作人群，以及他們經常操作的哪些功能，也就是依靠系統處理的業務；
• 固定人群的操作習慣，如：哪些人會在哪個時間段集中處理哪些業務；
• 固定操作人群的用戶量有多少；
• 系統設計的最大并發用戶數、最大在線用戶數等信息
• 初步預計，系統上線后日處理業務量有多少
• 對于后臺系統，需要關注系統的前端渠道，以及各個渠道的交易請求規律和交易量

對于已經上線的系統，可以方便的從運維部門獲取相關數據信息。生產環境下的交易場景復雜多變（取決于市場表現），不能夠僅對一個特定時期的業務量信息進行調研。如果你對這個系統還不夠了解，我建議采樣一個周期較長的時間段的交易量信息，有條件的情況下，可以把全年的交易量信息收集一份。

無論是已上線和未上線的系統調研工作，建議大家事先準備好調研表，很多剛剛接觸這方面工作的朋友或許準備起來比較困難，我這里有一份整理過的供大家參考。各位在自己定制調研表時，要記得不斷更新不斷增加調研的內容，從而使得調研工作更加充分。

• 場景分析

所謂場景分析，就是對不同交易場景進行分類，大多數情況下，每一個應用系統都存在多個典型場景。這些典型場景或許不全是交易量的峰值情況，它們具體體現為交易的類別與交易比例上的差異。之所以需要分析多個場景，是因為在不同的交易類別、比例情況下，系統的處理能力存在著較大的差別，有可能在一個交易量不大的特定場景下，應用系統已經趨于資源占用的最大負荷，或者會產生未知的影響，比如大量報錯等。針對典型場景的選取，請大家參考如下：

如上圖所示，我們可以看出有4～5個交易量較高的交易日，就可以嘗試從這個幾個日期入手進行分析，對具體某一天的分析如下：

通過對場景的分析，我們已經初步得到每個交易日的特定場景發生的具體時間，要知道，每個場景的背后一定有一個刺激因素在支持，我們需要根據當日的相關信息進行判斷其發生的原因以及未來再次發生的幾率性。

• 模型分析

在圈定特點場景后，就可以對業務（交易）的模型模型進行分析了。很多人分析到這個步驟時，往往采用“小時交易量（筆）/3600（秒）”來計算TPS，然后進行一個加權算法。個人認為這種非常不精確，當然，如果基礎信息數據無法再精確，很多時候也只能采用這個算法。在有條件的情況下，盡量獲得更詳細的調研數據，如：每10分鐘（5分鐘）的交易量匯總統計數據。我在以往的工作中會調研到這個微粒度：

然后，采用該“10分鐘的交易量/（10分鐘*60秒）”，然后再根據情況進行適當的加權計算，從而得到TPS值。剩下的工作就是分析業務（交易）占比了，根據以往的經驗，典型交易的選取一般遵循如下原則：

• 采用TOP 10或TOP 20依次篩選占比較高的交易，直至篩選總量超過基礎數據總量的80%；
• 重要的交易不按照TOP方式選取，可直接選入典型交易范圍；什么是重要的交易呢，一般認為交易的優先級較高，交易在歷史過程中易發生錯誤，或是一支新交易，我們對他了解甚少，需要納入測試范圍。

這里給出一個選取的樣例，請大家參考：

基于上述的樣例，共篩選了12支交易作為初步的典型交易，共計占比81%。如下：

接下來的工作就是反推出測試模型的各支交易占比了，反推結果如下：

到了這個步驟，測試模型的分析工作基本就結束了，需要特別說明的是，在選取典型交易過程中，你會發現有部分典型交易不具備可測試性，當然，原因就很多了，比如：數據不具備重復利用性、或者這支交易本身存在問題。對于這種情況，我們需要對模型進行適當的調整，調整的方法很多，如：

• 放棄這支交易，增加一支性質相同的交易的比重；
• 放棄這支交易，重新選擇一支新的交易來替代。

對已模型調整，應當采取謹慎、科學的方式，在不了解各支交易特點的情況下，不建議隨便進行調整。這份模型分析，僅作為一份指南，希望對大家有所幫助，在很多性能測試個案中，這份指南也有很多不適應性，希望大家酌情參考，也希望各位多多給意見，我們一同提高。（

文章來源于領測軟件測試網 http://www.kjueaiud.com/

TAG: 模型 軟件 性能測試