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. 調用第三方業務組件，邏輯復雜的業務。

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

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

性能測試需求評審

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

可測性

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

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

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