本文是《LoadRunner沒有告訴你的》系列的第六篇，我將繼續保持“無廢話”的原則，用盡可能簡潔、明確的語句來表述我對性能測試的看法和經驗。在這篇文章中，我們要討論的是如何獲取“有效的”性能需求。
一個實際的例子
為了便于大家的理解，我們先來看一個性能需求的例子，讓大家有一個感性的認識，本文后面的討論也會再次提到這個例子。
這是一個證券行業系統中某個業務的“實際需求”——實際上是我根據通過網絡搜集到的數據杜撰出來的，不過看起來像是真實的 ^_^
系統總容量達到日委托6000萬筆，成交9000萬筆
系統處理速度每秒7300筆，峰值處理能力達到每秒10000筆
實際股東帳號數3000萬
這個例子中已經包括幾個明確的需求：
最佳并發用戶數需求：每秒7300筆
最大并發用戶數需求：峰值處理能力達到每秒10000筆
基礎數據容量：實際股東帳號數3000萬
業務數據容量：日委托6000萬筆，成交9000萬筆——可以根據這個推算出每周、每月、每年系統容量的增長模型
什么是“有效的”性能需求？
要想獲得有效的性能需求，就要先了解什么樣的需求是“有效的”。有效的性能需求應該符合以下三個條件。
1. 明確的數字，而不是模糊的語句。
結合上面的例子來看，相信這個應該不難理解。但是有的時候有了數字未必就不模糊。例如常見的一種需求是“系統需要支持5000用戶”，或者“最大在線用戶數為8000”。這些有數字的需求仍然不夠明確，因為還需要考慮區分系統中不同業務模塊的負載，以及區分在線用戶和并發用戶的區別。關于這方面的內容，在下面兩篇文章中的留言內容中有精彩的討論：
2. 有憑有據，合理，有實際意義。
通常來說，性能需求要么由客戶提出，要么由開發方提出。對于第一種情況，要保證需求是合理的，有現實意義的，不能由著客戶使勁往高處說，要讓客戶明白性能是有成本的。對于第二種情況，性能需求不能簡單的來源于項目組成員、PM或者測試工程師的估計或者猜測，要保證性能需求的提出是有根據的，所使用的數據和計算公式是有出處的——本文后面的部分會介紹獲得可用的數據和計算公式的方法。
3. 相關人員達成一致。
這一點非常關鍵。如果相關人不能對性能需求達成一致，可能測了也白測——特別是在客戶沒有提出明確的性能需求而由開發方提出時。這里要注意“相關人員”的識別，通常項目型的項目的需要與客戶方的項目經理或負責人進行確認，產品型的項目需要與直屬領導或者市場部進行確認。如果實在不知道該找誰確認，那就把這個責任交給你的直屬領導；如果你就是領導了，那這領導也白當了 ^_^
如何獲得有效的性能需求
上面提到了“有效的”性能需求的一個例子和三個條件，下面來我們將看到有哪些途徑可以幫助我們獲得相關的數據——這些方法我在實際的工作中都用過，并且已經被證實是可行的。這幾種方法由易到難排列如下：
1. 客戶方提出
這是最理想的一種方式，通常電信、金融、保險、證券以及一些其他運營商級系統的客戶——特別是國外的客戶都會提出比較明確的性能需求。
2. 根據歷史數據來分析
根據客戶以往的業務情況來分析客戶的業務量以及每年、每月、每周、每天的峰值業務量。如果客戶有舊的系統，可以根據已有系統的訪問日志，數據庫記錄，業務報表來分析。要特別注意的是，不同行業、不同應用、不同的業務是有各自的特點的。例如，購物網站在平時的負載主要集中在晚上，但是節假日時訪問量和交易量會是平時的數倍；而地鐵的售票系統面臨的高峰除了周末，還有周一到周五的一早一晚上下班時間。
3. 參考歷史項目的數據
如果該產品已有其他客戶使用，并且規模類似的，可以參考其他客戶的需求。例如在線購物網站，或者超市管理系統，各行業的進銷存系統。
4. 參考其他同行類似項目的數據
如果本企業沒有做過類似的項目，那么可以參考其他同行企業的公布出來的數據——通常在企業公布的新聞或者成功解決方案中會提到，包括系統容量，系統所能承受的負載以及系統響應能力等。
5. 參考其他類似行業應用的數據
如果無法找打其他同行的數據，也可以參考類似的應用的需求。例如做IPTV或者DVB計費系統的測試，可以參考電信計費系統的需求——雖然不能完全照搬數據，但是可以通過其他行業成熟的需求來了解需要測試的項目有哪些，應該考慮到的情況有哪些種。
6. 參考新聞或其他資料中的數據
最后的一招，特別是對于一些當前比較引人關注的行業，涉及到所謂的“政績”的行業，通常可以通過各種新聞媒體找到一些可供參考的數據，但是需要耐心的尋找。例如我們在IPTV和DVB系統的測試中，可以根據新聞中公布的各省、各市，以及國外各大運營商的用戶發展情況和用戶使用習慣來估算系統容量和系統各個模塊的并發量。