性能需求分析
性能需求分析
需求分析是個繁雜過程，它并非我們想象的那么簡單，而性能測試需求除了要對系統的業務非常了解，還需要有深厚性能測試知識。才能夠挖掘分析出真正的性能需求。
1、如何獲得有效的需求
1.1、客戶方提出
客戶方能提出明確的性能需求，說明對方很重視性能測試，這樣的企業一般是金融、電信、銀行、醫療器械等；他們一般對系統的性能要求非常高，對性能也非常了解。提出需求也比較明確。
曾經有一個銀行項目，已經到最后的性能測試極端，因為數據庫設計不合理，導致性能出現很大的問題，最終不得不把整合項目作廢，對于這樣的項目，其實從分析設計階段就應該考慮系統的性能問題。性能測試也一樣，對于某些項目來說越早進行越好。當然，前期的性能測試為單元性能測試、接口性能測試，有別系統性能測試。
2、根據歷史數據分析
對于一些面向用戶的獨特產品，比較難定位市場的大小，可以先上一運營一段時間，通過運營可以搜集客戶資料，比如，每月、每星期、每天的峰值業務量是多少。用戶以什么樣的速度在遞增中。用戶對系統的哪些功能模塊使用的最多，他們所點的比例等等。收集到這些數據之后，我們就可評估系統的系統需求指標，從而進行性能測試。
3、需求分析與定位
這里根據前期的需求分析與定位，來分析確定系統性能指標。例如某省幼兒園管理系統。統計全省有多少家幼兒園，系統的使用時間為幼兒到校之后，管理人員對幼兒的到校情況進行錄入，以及幼兒的午飯，放學情況的錄入時間。經過與需求人員交流分析也能得到比較明確的性能指標。
4、參考歷史項目或其它同行業的項目
如果公司之前有類似的項目經驗，根據項目大小及上次性能測試的一些指標。從根據項目的規模可以制定出相應的性能指標。
即使本公司沒有類似的項目，但其它公司有類似的項目，例如做IPTV或者DVB計費系統的測試，可以參考電信計費系統的需求——雖然不能完全照搬數據，但是可以通過其他行業成熟的需求來了解需要測試的項目有哪些，應該考慮到的情況有哪些種。
5、參考其它資料數據
如果你做的是非常獨特的產品，市場上沒有此類型的產品，而且需求及市場也難以估計，那么只能從與產品相關的資料中尋找痕跡了。不過，相信這樣不確定性的產品，老板要承擔的風險也是挺大的。
需要說明的是，我上面介紹的方面并非是獨立的，可以綜合的使用，你可以根據客戶提出的指標，再根據歷史數據以及參考同類型項目來進行。這樣可以更確定你的性能指標是客戶（或自己）真正需要的、最符合項目需求的。
2、性能測試點的選取
* 發生頻率非常高的（例如：某核心業務系統中的登錄、收發等業務，它們在每天的業務總量中占到90%以上）
* 關鍵程度非常高的（產品經理認為絕對不能出現問題的，如登錄，掃碼，支付等）
* 資源占用非常嚴重的（導致磁盤I/O非常大的，例如某個業務進行結果提交時需要向數十個表存取數據，或者一個查詢提交請求時會檢索出大量的數據記錄）
3、常見性能需求
1、接口的響應速度達到300ms以下。
2、系統服務支持50萬個在線用戶
3、接口成功率達到99.5%以上。
4、在100個并發用戶的高峰期，系統的基本功能，處理能力至少達到10TPS
5、這個系統能否支撐200萬的vu（每天登錄系統的人次） ? ? ? ? ?vu----Virtual user(虛擬用戶)
"不成文"的性能需求指標：
80/20原則：又稱帕累托效應，比如，某一些系統一天中80%的訪問量集中在20%的時間內。
4、下面來分析某移動支付的需求：
按照2018年日交易筆數的目標為1000萬筆：
如何得到每秒的交易筆數？
一： 嚴格的根據2/8原則 ?，80%的訂單集中在20%的時間生成。
集中訂單交易數： ?10000000*80%=8000000筆
集中發送的時間：24*20%=4.8小時=17280秒
每秒生成的訂單數：8000000/17280=462.9筆/秒
二：另外的200W交易筆數請求分布在另外的23個小時內，因為考慮到半夜之后基本沒什么請求量，假設另外的200W次請求分布在10:00-24:00，那么我們另外一個指標是 2000000/14/3600 = 39.68 （穩定支持這樣的TPS）
5、性能測試場景設計
峰值場景設計： 設計符合業務場景的高壓力場景，比如大量并發集中在半小時-1小時內
穩定場景設計: 8-10小時的長時間穩定壓力場景
性能瓶頸壓測場景： 逐步增加壓力，尋找業務請求瓶頸（適用于沒有業務指標，技術優化類）
秒殺類超大并發場景設計: 測試秒殺場景
6、性能測試通過標準
達到目標預期
回復
發現幫助中心更新日志數據安全關于我們服務協議反饋English
總結
