前言：html
在面試的時候，常常遇到有應聘者說本身的職業規劃是向性能測試工程師發展。對此說一下個人見解，但願對剛接觸性能測試的同行有所幫助。前端
其實真正作過性能測試的都知道，平時遇到的性能測試需求大都比較簡單，只要掌握一門性能測試工具的使用基本就能完成任務。那麼掌握一種性能測試工具通常用多長時間呢？ 以loadrunner爲例，大約5-10個小時我就能夠教會一個稍微有點性能測試基礎的人上手使用——換句話說，把十個小時就能達成的目標做爲職業發展方向，是否是要求過低了點呢？並且，多數小公司都不作性能測試，只有規模較大的公司或者性質特殊的項目纔有性能測試的需求，即便在大公司，性能測試團隊的規模也很小，通常也就兩三我的（這意味着很難鍛鍊管理能力）。以咱們公司爲例，大多數時候都在作功能測試， 功能測試完了才作性能測試，並且性能測試是階段性的，因此即便半數以上的項目都作性能測試，我也不會招專門的性能測試人員——由於工做不飽滿。最後，就我我的而言，我以爲性能測試作多了也挺無聊的——翻過來覆過去就是那麼點東西。ios
因此，我以爲性能測試適合作一個技能，但不適合作一個職業發展目標。面試
正文數據庫
言歸正傳，要設定性能測試的目標避免不了要了解此次性能測試的目的（好比是測負載，測壓力，測優化效果仍是測穩定性），以及測試側重點，而後肯定使用的工具，好比測前端性能可使用findbugs、fiddler，測試後端的性能（也就是服務器端的性能）可使用loadrunner、soupui等。後端
我曾經見過作了一兩年手機APP測試的同行，在被問到如何對手機APP進行壓力測試時，只回答用monkey作。——其實monkey的官方介紹文檔裏很清楚的說明了它只能作客戶端的壓力測試，沒法作對服務器端的壓力測試。服務器
也曾見到一些剛接觸性能測試的測試人員，雖然掌握了工具的使用，但卻仍然不會作好性能測試，緣由之一是不清楚如何設定性能測試的目標。也就是今天要討論的重點。微信
一個實際的例子
這是一個證券系統中某個業務的「實際需求」session
系統總容量達到日委託6000萬筆，成交9000萬筆併發
系統處理速度每秒7300筆，峯值處理能力達到每秒10000筆
實際股東賬號數3000萬
這個例子中已經包括幾個明確的需求：
最佳併發用戶數需求：每秒7300筆
最大併發用戶數需求：峯值處理能力達到每秒10000筆
基礎數據容量：實際股東賬號數3000萬
業務數據容量：日委託6000萬筆，成交9000萬筆——能夠根據這個推算出每週、每個月、每一年系統容量的增加模型
什麼是「有效的」性能需求？
要想得到效的性能需求，就要先了解什麼樣的需求是「有效的」。有效的性能需求應該符合如下三個條件。
1. 明確的數字，而不是模糊的語句。
結合上面的例子來看，相信這個應該不難理解。可是的時候了數字未必就不模糊。例如常見的一種需求是「系統須要支持5000用戶」，或者「最大在線用戶數爲8000」。這些數字的需求仍然不夠明確，由於還須要考慮區分系統中不一樣業務模塊的負載，以及區分在線用戶和併發用戶的區別（參考http://www.cnblogs.com/scios/p/5413666.html）。
2. 憑據，合理，實際意義。
一般來講，性能需求要麼由客戶提出，要麼由開發方提出。對於第一種狀況，要保證需求是合理的，有現實意義的，不能由着客戶使勁往高處說，要讓客戶明白性能是有成本的。對於第二種狀況，性能需求不能簡單的來源於項目組成員、PM或者測試工程師的估計或者猜想，要保證性能需求的提出是有根據的，所使用的數據和計算公式是有出處的——本文後面的部分會介紹得到可用的數據和計算公式的方法。
3. 相關人員達成一致。
這一點很是關鍵。若是相關人不能對性能需求達成一致，可能測了也白測——特別是在客戶沒有提出明確的性能需求而由開發方提出時。這裏要注意「相關人員」的識別，一般項目型的項目的須要與客戶方的項目經理或負責人進行確認，產品型的項目須要與直屬領導或者市場部進行確認。
如何得到效的性能需求？
1. 客戶方提出
這是最理想的一種方式，一般電信、金融、保險、證券以及一些其餘運營商級系統的客戶——特別是國外的客戶都會提出比較明確的性能需求。
2. 根據歷史數據來分析
根據客戶以往的業務狀況來分析客戶的業務量以及每一年、每個月、每週、天天的峯值業務量。若是客戶舊的系統，能夠根據已係統的訪問日誌，數據庫記錄，業務報表來分析。要特別注意的是，不一樣行業、不一樣應用、不一樣的業務是各自的特色的。例如，購物網站在平時的負載主要集中在晚上，可是節假日時訪問量和交易量會是平時的數倍；而地鐵的售票系統面臨的高峯除了週末，還週一到週五的一早一夜下班時間。
3. 參考歷史項目的數據
若是該產品已其餘客戶使用，而且規模相似的，能夠參考其餘客戶的需求。例如在線購物網站，或者超市管理系統，各行業的進銷存系統。
4. 參考其餘同行相似項目的數據
若是本企業沒作過相似的項目，那麼能夠參考其餘同行企業的公佈出來的數據——一般在企業公佈的新聞或者成功解決方案中會提到，包括系統容量，系統所能承受的負載以及系統響應能力等。
5. 參考其餘相似行業應用的數據
若是沒法找打其餘同行的數據，也能夠參考相似的應用的需求。例如作IPTV或者DVB計費系統的測試，能夠參考電信計費系統的需求——雖然不能徹底照搬數據，可是能夠經過其餘行業成熟的需求來了解須要測試的項目有哪些，應該考慮到的狀況有哪些種。
6. 參考新聞或其餘資料中的數據
最後的一招，特別是對於一些當前比較引人關注的行業，涉及到所謂的「政績」的行業，一般能夠經過各類新聞媒體找到一些可供參考的數據，可是須要耐心的尋找。例如咱們在IPTV和DVB系統的測試中，能夠根據新聞中公佈的各省、各市，以及國外各大運營商的用戶發展狀況和用戶使用習慣來估算系統容量和系統各個模塊的併發量
如何「去僞存真」？
在軟件開發過程當中，需求管理要遠遠簡單于需求開發，CMMI中也體現了這一點，而且實際工做中也經常須要咱們思考，如何根據客戶的實際使用或粗線條的性能要求來開發知足客戶須要的性能需求來。
還拿文中例子來講，客戶告訴咱們「系統總容量達到日委託6000萬筆，成交9000萬筆；系統處理速度每秒7300筆，峯值處理能力達到每秒10000筆」，那咱們將客戶的這個要求管理起來並實現了這一點，這叫需求管理；而若是咱們根據如下2個假設：
採用2/8比例，即80%的業務在20%的峯值時間內完成，20%的業務在80%的非峯值時間內完成，那麼咱們能夠獲得峯值處理業務量1.5億（6000w+9000w）的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萬筆」，而處理速度是他們根據本身的須要估算出來的，並不許確。
說明：1）所謂需求開發，也就是根絕客戶的核心需求，爲客戶設計完整的需求體系，甚至根據客戶的業務發展須要，爲客戶設計核心需求和需求體系。2）在我說的這個例子中只用了1個計算，而實際的需求開發中須要作調研、出可研報告、作需求方案、設計等一整套的工做。
「併發用戶數」、「系統用戶數」和「同時在線用戶數」的計算公式
（1）計算平均的併發用戶數：C=nL/T
（2）併發用戶數峯值：C’≈C+3根號C
公式（1）中，C是平均的併發用戶數；n是loginsession的數量；L是login session的平均長度；T指考察的時間段長度。
公式（2）則給出了併發用戶數峯值的計算方式中，其中，C’指併發用戶數的峯值，C就是公式（1）中獲得的平均的併發用戶數。該公式的得出是假設用戶的loginsession產生符合泊松分佈而估算獲得的。
實例：
假設一個OA系統，該系統有3000個用戶，平均天天大約有400個用戶要訪問該系統，對一個典型用戶來講，一天以內用戶從登陸到退出該系統的平均時間爲4小時，在一天的時間內，用戶只在8小時內使用該系統。
則根據公式（1）和公式（2），能夠獲得：
C=400*4/8=200
C’≈200+3*根號200=242
說明：這個公式的真僞有待驗證。
結束語
最後，從我瞭解的狀況來看，多數公司作性能測試時只須要看看系統在不一樣併發下的TPS和平均事務處理時間，以及支持的最大併發。那麼做爲測試人員，咱們只要給出三個指標便可：TPS，平均事務響應時間，是否支持橫行擴展。
本文分享自微信公衆號 - 軟件測試經驗與教訓（udatest）。
若有侵權，請聯繫 support@oschina.cn 刪除。
本文參與「OSC源創計劃」，歡迎正在閱讀的你也加入，一塊兒分享。