效能測試需求分析

原文：

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

效能測試必要性評估

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

通常情況下，必要性評估可以通過設定不同條件、不同權重進行分析，將評估項分為關鍵評估項和一般評估項兩種。關鍵評估項，只要有一項符合，則必須開展效能測試，而一般評估項，可通過加權計算，超過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. 呼叫第三方業務元件，邏輯複雜的業務。

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

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

效能測試需求評審

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

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

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

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

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

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

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

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

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

效能測試需求分析

效能測試需求分析

效能測試需求分析

效能測試 效能需求分析

相關推薦

效能測試效能需求分析