Jmeter性能測試系列-性能測試需求分析

性能測試需求分析

性能測試需求分析與傳統的功能測試需求有所不同，功能測試需求分析重點在於從用戶層面分析被測對象的功能性、易用性等質量特性，性能測試則需要從終端用戶應用、系統架構設計、硬體配置等多個緯度分析系統可能存在性能瓶頸的業務。

性能測試必要性評估

任何項目在開展性能測試活動前都需要進行必要性評估。通過必要性評估活動，確認被測對象是否有必要實施性能測試活動，千萬不可為了性能而性能。

通常情況下，必要性評估可以通過設定不同條件、不同權重進行分析，將評估項分為關鍵評估項和一般評估項兩種。關鍵評估項，只要有一項符合，則必須開展性能測試，而一般評估項，可通過加權計算，超過60分，則需開展性能測試。

軟體測試活動中，根據測試要求可分為功能測試與非功能測試。非功能測試，通常指的即是性能測試。當然，具體情況具體分析。

常見性能測試關鍵評估項如下：

1. 被測對象需經過主管部門或監管單位審查、認可，需提供性能測試報告。目前，很多企業的軟體產品在正式上市對外銷售、應用時，政府機關、主管部門或監管單位，可能需要其出具功能測試報告、性能測試報告，甚至是第三方測試報告，這種情況下，必須進行性能測試；

2. 涉及財產生命安全的系統。通常情況，電商系統、金融業務系統、醫療健康評估，涉及用戶或行方資金交易，生命安全類的，需要進行性能測試；

3. 首次投產的大型系統，具有大量用戶使用的核心業務；

4. 系統核心資料庫、業務邏輯、軟硬體升級。與歷史系統對比，系統核心資料庫、業務邏輯調整、軟體硬體設備升級，同樣需要實施性能測試；

5. 歷史版本存在重大非功能缺陷或風險較大的未評估項；

6. 業務量、用戶量、節點增長30%以上。系統升級後，業務量、用戶量、應用節點，增長量在30%以上的，具體數值可根據實際情況調整。應用節點增長一般指甲方因業務需求，增加應用節點，銀行拓展分行、分中心、分公司、營業網點等；

7. 系統架構發生重大變化。不同的系統架構可能存在較大的性能差異，因此在系統架構發生變化後，必須實施性能測試，並且在此過程中，無法通過類推的思路推斷架構變化後的系統性能；

8. 生產環境非功能嚴重缺陷修復後。生產環境在使用過程中產生重大非功能性缺陷成功修復後，需重新開展性能測試活動，以驗證修復活動是否對生產環境造成不良影響。

以上僅僅列出筆者在日常性能測試活動參考的關鍵評估項，對於不同行業，不同測試對象可能存在的不同的關鍵評估項，讀者可自行增減。

常見的性能測試一般評估項，主要從單次版本考慮，如果是平台性的，則為關鍵評估項，如果是單次版本，單個組件或業務，則從以下幾個一般評估項評估權重：

1. 是否在平台中處於核心位置（15分）；

2. 是否有升級，且升級內容中包含了外部系統對接介面、支付介面、Web Service調用介面等與其他系統關聯介面（20分）；

3. 是否存在部署方式調整或優化（15分）；

4. 是否增加了性能風險較高的調整（20分）；

5. 是否存在客戶要求必須測試的組件或業務流程（20分）；

6. 是否涉及多個功能缺陷的修復，且流程發生較大變化（10分）。

如果上述一般評估項，總計分值超過60分，則需進行性能測試。

以本ECShop平台為例，通過針對上述關鍵評估項及一般評估項的評估，滿足關鍵評估項中的第三條：首次投產的大型系統，具有大量用戶使用的核心業務」，因此本ECShop平台的性能測試活動必須開展。

性能測試工具選型

通過測試必要性評估，確定了需要對被測對象實施性能測試後，則需要考慮採用哪種性能測試方式。根據被測對象的業務特性和架構設計，可以採用以下兩種方式開展有效的性能測試活動。

如果被測對象為批處理方式實現，並且在資料庫中設立起始與終止標識欄位，則可以利用存儲過程或發起批處理的方式進行，資源監控可以利用監控腳本如python腳本、shell腳本或其他監控工具，最終統計時，以結束時間減去開始時間，則可獲得交易時間，並可根據每筆交易獲得平均交易時間，相對來說較為方便。

如果被測對象不是批處理模式，且可能存在大量數據交互，則可能需要採用專業的性能測試工具來實現。一般而言，業內常用的性能測試工具主要要開源的Jmeter和商用的HP公司的LoadRunner。

Jmeter是個開源的性能測試工具，目前在市場中的熱度很高，不依賴於界面，功能測試的腳本同樣可以作為性能測試腳本運行，對測試工程師技術技能要求不高，而且提供了參數化、函數、關聯等功能便於腳本的優化與擴展。

LoadRunner在商用領域一枝獨秀，很多年保持排前的市場佔有率，與Jmeter相比，LoadRunner具有強大的腳本開發功能、完善的函數庫及結果分析功能。對測試工程師技術要求相對較高，但因其在業內流行很多年，LoadRunner應用的資料相對於Jmeter較多，便於學習與應用。

企業在選擇性能測試工具時，如有條件可以自己根據實際測試需求自定義開發測試工具，也可以選擇市場上常用的測試工具，通常選擇時需考慮以下幾個問題：

1. 能否自定義開發，更符合實際測試需求；

2. 商用的測試工具所需的成本，企業能否承受；

3. 採購的測試工具是否提供了完善的服務、細緻的培訓；

4. 團隊人員能否掌握測試活動所需的工具技能。

開源是行業趨勢，本書案例項目用開源性能工具Jmeter實施性能測試。

性能測試需求分析

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

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

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

業務用戶

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

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

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

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

5. 特殊業務場景；

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

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

項目團隊

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

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

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

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

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

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

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

性能測試需求評審

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

可測性

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

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

性能測試活動與功能測試活動有個顯著的特點是被測對象運行環境要求不同。實施功能測試時，只要被測對象能夠在合理的運行環境中正常運行即可，即使測試環境與生產環境可能存在較大的差異，性能測試則不同，一定需模擬儘可能真實的運行環境。當測試環境與實際生產環境差異較大時，性能測試結果往往不被接受，如果在性能測試實施過程中，無法搭建相對真實的測試環境，即可認為被測對象不具備性能的可測性。

一致性

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

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

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

正確性

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

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

推薦閱讀：