性能測試之需求開發

如下內容大多來自jackei的博客，只是整理了下，增長了本身的理解。

一個實際的例子：

 某證券行業系統中某個業務的實際需求

        一、系統總容量達到日委託6000萬筆，成交9000萬筆

       二、 系統處理速度每秒7300筆，峯值處理能力達到每秒10000筆

        三、實際股東賬號數3000萬

 從上面例子中能夠看出幾個明確的需求：

        一、最佳併發用戶數需求：每秒7300筆

        二、最大併發用戶數需求：峯值處理能力達到每秒10000筆         

        三、基礎數據容量：實際股東賬號數3000萬

        四、業務數據容量：日委託6000萬筆，成交9000萬筆——能夠根據這個推算出每週、每個月、每一年系統容量的增加模型

 

什麼是「有效的」性能需求？

要想得到有效的性能需求，就要先了解什麼樣的需求是「有效的」。有效的性能需求應該符合如下三個條件。

一、 明確的數字，而不是模糊的語句。

結合上面的例子來看，相信這個應該不難理解。可是有的時候有了數字未必就不模糊。例如常見的一種需求是「系統須要支持5000用戶」，或者「最大在線用戶數爲8000」。這些有數字的需求仍然不夠明確，由於還須要考慮區分系統中不一樣業務模塊的負載，以及區分在線用戶和併發用戶的區別。

二、有憑有據，合理，有實際意義。

       一般來講，性能需求要麼由客戶提出，要麼由開發方提出。對於第一種狀況，要保證需求是合理的，有現實意義的，不能由着客戶使勁往高處說，要讓客戶明白性能是有成本的。對於第二種狀況，性能需求不能簡單的來源於項目組成員、PM或者測試工程師的估計或者猜想，要保證性能需求的提出是有根據的，所使用的數據和計算公式是有出處的。

三、相關人員達成一致。

       若是相關人不能對性能需求達成一致，可能測了也白測——特別是在客戶沒有提出明確的性能需求而由開發方提出時。這裏要注意「相關人員」的識別，一般項目型的項目的須要與客戶方的項目經理或負責人進行確認，產品型的項目須要與直屬領導或者市場部進行確認。若是實在不知道該找誰確認，那就把這個責任交給你的直屬領導。

 

如何得到有效的性能需求：

一、 客戶方提出

       這是最理想的一種方式，一般電信、金融、保險、證券以及一些其餘運營商級系統的客戶——特別是國外的客戶都會提出比較明確的性能需求。

二、根據歷史數據來分析

       根據客戶以往的業務狀況來分析客戶的業務量以及每一年、每個月、每週、天天的峯值業務量。若是客戶有舊的系統，能夠根據已有系統的訪問日誌，數據庫記錄，業務報表來分析。要特別注意的是，不一樣行業、不一樣應用、不一樣的業務是有各自的特色的。例如，購物網站在平時的負載主要集中在晚上，可是節假日時訪問量和交易量會是平時的數倍；而地鐵的售票系統面臨的高峯除了週末，還有周一到週五的一早一夜下班時間。

三、參考歷史項目的數據

      若是該產品已有其餘客戶使用，而且規模相似的，能夠參考其餘客戶的需求。例如在線購物網站，或者超市管理系統，各行業的進銷存系統。

四、參考其餘同行相似項目的數據

      若是本企業沒有作過相似的項目，那麼能夠參考其餘同行企業的公佈出來的數據——一般在企業公佈的新聞或者成功解決方案中會提到，包括系統容量，系統所能承受的負載以及系統響應能力等。

五、參考其餘相似行業應用的數據

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

六、參考新聞或其餘資料中的數據

       最後的一招，特別是對於一些當前比較引人關注的行業，涉及到所謂的「政績」的行業，一般能夠經過各類新聞媒體找到一些可供參考的數據，可是須要耐心的尋找。例如咱們在IPTV和DVB系統的測試中，能夠根據新聞中公佈的各省、各市，以及國外各大運營商的用戶發展狀況和用戶使用習慣來估算系統容量和系統各個模塊的併發量。

 

性能測試點選取：

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

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

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

 

需求獲取的小例子：

      去年整年處理「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

 

關於性能需求的一點補充：

       在軟件開發過程當中，需求管理要遠遠簡單于需求開發，CMMI中也體現了這一點，而且實際工做中也經常須要咱們爲客戶來開發這部分的性能需求。
還但願你能考慮一下，如何根據客戶的實際使用或粗線條的性能要求來開發知足客戶須要的性能需求來。就拿例子來講，客戶告訴咱們「系統總容量達到日委託6000萬筆，成交9000萬筆；系統處理速度每秒7300筆，峯值處理能力達到每秒10000筆」，那咱們將客戶的這個要求管理起來並實現了這一點，這叫需求管理；而若是咱們根據如下2個假設：
一、採用2/8比例，即80%的業務在20%的峯值時間內完成，20%的業務在80%的非峯值時間內完成，那麼咱們能夠獲得峯值處理業務量1.5億的80%爲1.2億，非峯值處理業務量1.5億的20%爲3000萬；
二、1天系統運行時間爲20小時，另4小時爲非營業的後臺處理時間，那麼峯值時間20小時的20%爲4小時，非峯值時間20小時的80%爲16小時。

咱們能夠計算到：三、平均峯值處理速度1.2億/4*3600秒接近9000個/秒；四、平均非峯值處理速度3000萬/16*3600秒約500個/秒；       考慮到特殊狀況的發生，咱們建議實際峯值處理速度要能達到理論計算的平均峯值處理速度的1.5到2倍，因此最終肯定下來的建議峯值處理速度爲9000個/ 秒*2=18000個/秒。咱們拿這個結果向客戶說明，告訴他們原來的需求極可能在發生特殊狀況時沒法有效處理，客戶最終接受了咱們的說法並調整了他們的需求。這叫需求開發，經過分析修正了客戶的不合理需求，知足了他們最根本的須要「系統總容量達到日委託6000萬筆，成交9000萬筆」，而處理速度是他們根據本身的須要估算出來的，並不許確。       所謂需求開發，也就是根絕客戶的核心需求，爲客戶設計完整的需求體系，甚至根據客戶的業務發展須要，爲客戶設計核心需求和需求體系。