qileilove

          blog已經轉移至github,大家請訪問 http://qaseven.github.io/

          性能測試之性能需求分析

           需求分析是個繁雜過程,它并非我們想象的那么簡單,而性能測試需求除了要對系統的業務非常了解,還需要有深厚性能測試知識。才能夠挖掘分析出真正的性能需求。

           

          如何獲得有效的需求

           

          1、客戶方提出

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

            曾經有一個銀行項目,已經到最后的性能測試極端,因為數據庫設計不合理,導致性能出現很大的問題,最終不得不把整合項目作廢,對于這樣的項目,其實從分析設計階段就應該考慮系統的性能問題。性能測試也一樣,對于某些項目來說越早進行越好。當然,前期的性能測試為單元性能測試、接口性能測試,有別系統性能測試。

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

          2、根據歷史數據分析

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

            收集到這些數據之后,我們就可評估系統的系統需求指標,從而進行性能測試。

          3、需求分析與定位

            這里根據前期的需求分析與定位,來分析確定系統性能指標。例如某省幼兒園管理系統。統計全省有多少家幼兒園,系統的使用時間為幼兒到校之后,管理人員對幼兒的到校情況進行錄入,以及幼兒的午飯,放學情況的錄入時間。經過與需求人員交流分析也能得到比較明確的性能指標。

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

            如果公司之前有類似的項目經驗,根據項目大小及上次性能測試的一些指標。從根據項目的規模可以制定出相應的性能指標。

            即使本公司沒有類似的項目,但其它公司有類似的項目,例如做IPTV或者DVB計費系統的測試,可以參考電信計費系統的需求——雖然不能完全照搬數據,但是可以通過其他行業成熟的需求來了解需要測試的項目有哪些,應該考慮到的情況有哪些種。 

          5、參考其它資料數據

            如果你做的是非常獨特的產品,市場上沒有此類型的產品,而且需求及市場也難以估計,那么只能從與產品相關的資料中尋找痕跡了。不過,相信這樣不確定性的產品,老板要承擔的風險也是挺大的。^_^

           

            需要說明的是,我上面介紹的方面并非是獨立的,可以綜合的使用,你可以根據客戶提出的指標,再根據歷史數據以及參考同類型項目來進行。這樣可以更確定你的性能指標是客戶(或自己)真正需要的、最符合項目需求的。

           

          性能測試點的選取

           

          *  發生頻率非常高的(例如:某郵箱核心業務系統中的登錄、收發郵件等業務,它們在每天的業務總量中占到90%以上)

          *  關鍵程度非常高的(產品經理認為絕對不能出現問題的,如登錄等)

          *  資源占用非常嚴重的(導致磁盤I/O非常大的,例如某個業務進行結果提交時需要向數十個表存取數據,或者一個查詢提交請求時會檢索出大量的數據記錄)

           

          對性能需求點的描述

           

          準確

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

          一致

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

          特定

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

          檢查系統后臺關鍵業務數據10G、操作數據量為20K, 1500 個用戶、500 個并發用戶運行的負載下,連續運行12小時過程中,業務操作是否滿足性能需求。

           

          常見性能需求

           

          1WEB首頁打開速度5s以下,web登陸速度 15s以下。

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

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

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

          5、系統能在高于實際系統運行壓力1倍的情況下,穩定的運行12小時 

          6、這個系統能否支撐200萬的vu(每天登錄系統的人次)          vu----Virtual user(虛擬用戶) 

           

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

           

          響應時間:根據國外的一些資料,一般操作的響應時間為258秒,2秒內優秀,5秒內良好,8秒內可接受,其它一些特殊的操作,如上傳,下載可以依據用戶體驗的情況,延長響應時間。

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

            第三方研究表明,如果網頁是逐步加載的,先出現橫幅,再出現文字,最后出現圖像。在這樣的條件下,用戶會忍受更長的等待時間,用戶會把延遲在39秒內的也標識為“good”,超過56秒的才認為是“poor”的。

          80/20原則:又稱帕累托效應,比如,某一些系統一天中80%的訪問量集中在20%的時間內。

           

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

           

          其實我們上面得到的需求指標仍然是不明確的:

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

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

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

           

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

            首先,請你們當前軟件和硬件配置下驗證能否支撐200vu。如果可以支撐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 萬筆,考慮到 年后交易量遞增到每年 200萬筆。

            假設每年交易量集中在 個月,每個月 20 個工作日,每個工作日 小時,試采用 8020 原理估算系統服務器高峰期“WEB登錄”的交易吞吐量應達到怎樣的一個處理能力  

            200萬/8=25萬/月

            25萬/20=1.25萬/日

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

           

           

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

            上面的小案例算是拋出的一塊磚,需求開發難度要遠遠大于需求管理,在實際工作中常常需要我們為客戶開發這部分性能需求。所以,在追求技術的基礎上,請更多的了解分析你的項目及行業指標。  

           2012-8-24  對部分內容進行的調整。

          posted on 2014-02-14 13:56 順其自然EVO 閱讀(467) 評論(0)  編輯  收藏 所屬分類: 性能測試

          <2025年7月>
          293012345
          6789101112
          13141516171819
          20212223242526
          272829303112
          3456789

          導航

          統計

          常用鏈接

          留言簿(55)

          隨筆分類

          隨筆檔案

          文章分類

          文章檔案

          搜索

          最新評論

          閱讀排行榜

          評論排行榜

          主站蜘蛛池模板: 建始县| 建平县| 丰原市| 福鼎市| 外汇| 博客| 开远市| 安溪县| 仁布县| 额尔古纳市| 宜州市| 黄陵县| 慈溪市| 永川市| 滕州市| 石渠县| 张家界市| 廊坊市| 镇平县| 荥经县| 房山区| 手机| 冕宁县| 昭平县| 锦州市| 邯郸县| 武强县| 元阳县| 南靖县| 富源县| 柏乡县| 上饶市| 沙雅县| 海盐县| 西和县| 望都县| 德阳市| 那坡县| 渭源县| 汾阳市| 海林市|