一、性能測試需求分析

與功能測試需求分析一樣，性能測試同樣需要針對被測對象進行需求分析。一般而言，用戶或產品團隊設定性能測試需求時，僅會表述字面意義上需求，如「系統TPS需達到300以上，單筆交易時間不超過3秒」等。需要性能測試工程師結合用戶需求及性能測試活動本身需求進行顯性與隱性性能測試需求的分解與提取。

隨著互聯網技術的飛速發展，互聯網應用架構越來越複雜，運營系統涉及的利益相關方越來越多，因此，在性能測試工作實施過程中，需從不同的用戶層面分析待測需求。

確定性能測試的必要性後，性能測試工程師主要從以下兩個用戶方確定性能測試需求：

1. 業務用戶

（1） 用戶頻繁使用，且存在大量用戶使用的業務流程；

（2） 交易佔比較高，日常佔比在80%以上甚至更高的業務流程；

（3） 特殊交易日或峯值交易佔比80%以上甚至更高的業務流程；

（4） 性能較差且有過調整的業務流程；

（5） 特殊業務場景；

（6） 核心業務發生重大流程調整的業務流程。

以上從業務用戶層面，考慮的可能需要進行性能測試的點。實際實施過程中，如果可能，可向終端用戶調研。

2. 項目團隊

（1） 曾經測過性能後調整了架構設計的業務；

（2） 邏輯複雜，關鍵的業務；

（3） 可能消耗大量資源的業務；

（4） 與外部系統存在介面調用，且有大量數據交互的業務；

（5） 調用第三方業務組件，邏輯複雜的業務。

以上從項目開發角度考慮可能需要進行性能測試業務流程，性能測試工程師需對被測對象深入瞭解，並且需要研發團隊配合。

除上述兩種用戶，還可能包括運營團隊，調研未來業務發展規劃，系統需滿足未來業務需求的可能性。

二、性能測試需求評審

確定性能測試需求後，如有必要，需進行某種程度的測試需求評審活動。性能測試需求評審與功能測試需求評審類似，都需關注需求本身的可測性、一致性及正確性。

1. 可測性

軟體可測性，通常理解為軟體本身是否具備實施測試的條件，是否便於發現缺陷及定位缺陷。

在一定的時間及成本範圍內，構建測試環境，設計及執行測試用例，測試工程師能夠相對便捷的發現、定位缺陷，從而協助研發人員解決對應的缺陷，無論是功能測試，還是性能測試，都需要被測對象具備上述的可測試特性。

性能測試活動與功能測試活動有個顯著的特點是被測對象運行環境要求不同。實施功能測試時，只要被測對象能夠在合理的運行環境中正常運行即可，即使測試環境與生產環境可能存在較大的差異，性能測試則不同，一定需模擬儘可能真實的運行環境。

當測試環境與實際生產環境差異較大時，性能測試結果往往不被接受，如果在性能測試實施過程中，無法搭建相對真實的測試環境，即可認為被測對象不具備性能的可測性。

2. 一致性

性能測試需求一致性，主要關注用戶需求、生產需求、運營需求幾個方面。通過對性能測試需求的分析，判斷本次測試需求是否滿足用戶需求規格說明書中明確列出的性能需求項。生產需求，則是關注被測對象運行的真實性，從而在測試結束後能夠提供相對準確的數據依據。

運營需求，需以歷史數據或者現今運營數據為基礎，規劃未來業務發展的可能性，從而使得被測對象性能指標具有一定的冗餘度。

通過性能測試需求評審活動，確定本次性能需求與上述的關注點一致。

3. 正確性

在可測性與一致性得到保證的基礎上，需針對性能測試指標進行驗證，從而保證後續實施活動中所關注的各個項目需求、場景及指標的正確性，從而盡量減少返工、重新設計的風險。

通過可測性、一致性及正確性的評估，最終確定本輪性能測試需求，並以此作為後續測試實施活動的輸入。

推薦閱讀：