性能測試知多少---性能需求分析

　　需求分析是個繁雜過程，它並不是咱們想象的那麼簡單，而性能測試需求除了要對系統的業務很是瞭解，還須要有深厚性能測試知識。纔可以挖掘分析出真正的性能需求。

 

如何得到有效的需求

一、客戶方提出

　　客戶方能提出明確的性能需求，說明對方很重視性能測試，這樣的企業通常是金融、電信、銀行、醫療器械等；他們通常對系統的性能要求很是高，對性能也很是瞭解。提出需求也比較明確。

　　曾經有一個銀行項目，已經到最後的性能測試極端，由於數據庫設計不合理，致使性能出現很大的問題，最終不得不把整合項目做廢，對於這樣的項目，其實從分析設計階段就應該考慮系統的性能問題。性能測試也同樣，對於某些項目來講越早進行越好。固然，前期的性能測試爲單元性能測試、接口性能測試，有別系統性能測試。

　　有時候也會碰到不懂裝懂的客戶，提出一些無理的需求，好比只能2000人使用的OA系統，客戶要求併發用戶2000，這顯然是不合理的需求。這個就要看你怎麼給客戶溝通了。可是，千萬別僞造數據欺騙客戶。

二、根據歷史數據分析

　　對於一些面向用戶的獨特產品，比較難定位市場的大小，能夠先上一運營一段時間，經過運營能夠蒐集客戶資料，好比，每個月、每星期、天天的峯值業務量是多少。用戶以 什麼樣的速度在遞增中。用戶對系統的哪些功能模塊使用的最多，他們所點的比例等等。

　　收集到這些數據以後，咱們就可評估系統的系統需求指標，從而進行性能測試。

三、需求分析與定位

　　這裏根據前期的需求分析與定位，來分析肯定系統性能指標。例如某省幼兒園管理系統。統計全省有多少家幼兒園，系統的使用時間爲幼兒到校以後，管理人員對幼兒的到校狀況進行錄入，以及幼兒的午餐，放學狀況的錄入時間。通過與需求人員交流分析也能獲得比較明確的性能指標。

四、參考歷史項目或其它同行業的項目

　　若是公司以前有相似的項目經驗，根據項目大小及上次性能測試的一些指標。從根據項目的規模能夠制定出相應的性能指標。

　　即便本公司沒有相似的項目，但其它公司有相似的項目，例如作IPTV或者DVB計費系統的測試，能夠參考電信計費系統的需求——雖然不能徹底照搬數據，可是能夠經過其餘行業成熟的需求來了解須要測試的項目有哪些，應該考慮到的狀況有哪些種。

五、參考其它資料數據

　　若是你作的是很是獨特的產品，市場上沒有此類型的產品，並且需求及市場也難以估計，那麼只能從與產品相關的資料中尋找痕跡了。不過，相信這樣不肯定性的產品，老闆要承擔的風險也是挺大的。^_^

 

　　須要說明的是，我上面介紹的方面並不是是獨立的，能夠綜合的使用，你能夠根據客戶提出的指標，再根據歷史數據以及參考同類型項目來進行。這樣能夠更肯定你的性能指標是客戶（或本身）真正須要的、最符合項目需求的。

 

性能測試點的選取

*　　發生頻率很是高的（例如：某郵箱核心業務系統中的登陸、收發郵件等業務，它們在天天的業務總量中佔到90%以上）

*　　關鍵程度很是高的（產品經理認爲絕對不能出現問題的，如登陸等）

*　　資源佔用很是嚴重的（致使磁盤I/O很是大的，例如某個業務進行結果提交時須要向數十個表存取數據，或者一個查詢提交請求時會檢索出大量的數據記錄）

 

對性能需求點的描述

準確

如**系統必須在不超過 10 秒的響應時間內,處理 20 起登陸任務。再如發郵件時間最大不超過5秒以及平均時間在2秒之內。

一致

用戶和性能測試工程師對有關術語的理解要一致,如:併發用戶數、在線用戶數、註冊用戶數:

特定

性能測試的需求必定是有條件的。

檢查系統後臺關鍵業務數據10G、操做數據量爲20K, 1500 個用戶、500 個併發用戶運行的負載下，連續運行12小時過程當中,業務操做是否知足性能需求。

 

常見性能需求

1、WEB首頁打開速度5s如下，web登錄速度 15s如下。

2、郵件服務支持50萬個在線用戶

3、計費話單成功率達到99.999%以上。

4、在100個併發用戶的高峯期，郵箱的基本功能，處理能力至少達到10TPS

5、系統能在高於實際系統運行壓力1倍的狀況下，穩定的運行12小時

6、這個系統可否支撐200萬的vu（天天登陸系統的人次） vu----Virtual user(虛擬用戶)

 

"不成文"的性能需求指標：　　

響應時間：根據國外的一些資料，通常操做的響應時間爲2，5，8秒，2秒內優秀，5秒內良好，8秒內可接受，其它一些特殊的操做，如上傳，下載能夠依據用戶體驗的狀況，延長響應時間。

　　Peter bickford 在調查用戶反應時發現：在連續27次即便反饋以後，第28次操做進，計算機讓用戶等待2分鐘，結果半數人在第8.5秒左右就走開或者按下種啓鍵。使用了鼠標指針變成漏斗提示的界面會把用戶的等待時間延長到20秒左右，使用動畫的鼠標指針漏斗提示界面則會讓用戶的等待時間超過1分鐘，而進度條則可讓用戶等待到最後。Peter bickford的調查結果被普遍用到web軟件系統的性能需求的響應時間定義中。

　　第三方研究代表，若是網頁是逐步加載的，先出現橫幅，再出現文字，最後出現圖像。在這樣的條件下，用戶會忍受更長的等待時間，用戶會把延遲在39秒內的也標識爲「good」，超過56秒的才認爲是「poor」的。

80/20原則：又稱帕累託效應，好比，某一些系統一天中80%的訪問量集中在20%的時間內。

 

如何根據性能需求進行測試

其實咱們上面獲得的需求指標仍然是不明確的：

是驗證當前硬件和軟件配置可否支撐200萬vu？

是測試當前的硬件和軟件配置最多能支撐多少vu?

是幫助開發尋找性能瓶頸？

 

根據需求進行性能測試的過程：

　　首先，請大家當前軟件和硬件配置下驗證可否支撐200萬vu。若是能夠支撐200萬，再增長到300萬看是否能夠支撐。若是不能達到200萬，那麼就須要尋找一下是否有性能瓶頸，將主要的性能瓶頸解決後，再看一下是否能夠支撐200萬，若是能夠支撐，輸出測試結果。仍然不能，請評估須要添加多少硬件設備。

　　經過上面流程的分析，那麼咱們對於需求實施過程就很是明確了。

 

下面看來分析某郵箱系統的需求：

　　

按照 某某 郵箱20000萬註冊用戶，其中日活躍用戶數爲1.5%的規模計算：

日活躍用戶=20000*1.5%=300萬

日活躍用戶人均天天發6封郵件，用戶使用客戶端收發郵件比例20%，則：

天天發郵件投遞量=300萬*6*20%=360萬封

如何獲得每秒的郵件數？

方式一： 嚴格的根據2/8原則 ，80%的郵件集中在20%的時間發送。

集中發郵件數： 3600000*80%=28800000封

集中發送的時間：24*20%=4.8小時=17280秒

每秒發送郵件數：2880000/17280=166.7封/秒

 

方式二，根據 某某郵箱業務模型表，天天忙時集中郵件係數0.15，郵件平均峯值係數2,則：

峯值郵件量=3600000*0.15*2/3600=300封/秒

注：忙時集中係數=忙時業務量/全天業務量

在兩種方式的分析中，方法二得出的結果是方法一的將近一倍，咱們不要根據經驗理所固然的去分析，要深刻的瞭解系統，咱們要對行業指標及計算方式。若是按照第一種方式，性能測試達標了，但系統真正上線後可能遠遠超出了咱們的評估。2008年北京奧運運門票系統就是一個典型的案例。

再來分析系統的登陸：

 

　　去年整年處理「WEB登陸」交易約 100 萬筆，考慮到 3 年後交易量遞增到每一年 200萬筆。

　　假設每一年交易量集中在 8 個月，每月 20 個工做日，每一個工做日 8 小時，試採用 80～20 原理估算系統服務器高峯期「WEB登陸」的交易吞吐量應達到怎樣的一個處理能力　　

　　200萬/8=25萬/月

　　25萬/20=1.25萬/日

　　1.25萬*80%/(8*20%*3600)=1.74TPS

 

----------------------

　　上面的小案例算是拋出的一塊磚，需求開發難度要遠遠大於需求管理，在實際工做中經常須要咱們爲客戶開發這部分性能需求。因此，在追求技術的基礎上，請更多的瞭解分析你的項目及行業指標。