551      小米MIX

業務模型__性能測試技術體係_性能測試體係_性能測試-阿裏雲

訪問性能測試控製台

1 引言

1.1 編寫目的

本文規範在使用性能測試過程中進行業務模型的分析，旨在指導性能測試實施人員進行業務模型建立，為後續性能實施打好基礎。

1.2 適用對象和範圍

預期讀者為測試管理人員、測試實施人員、技術支持人員、項目質量管理人員、項目管理人員等係統技術質量相關人員。

2 業務模型分析準則

2.1 分析目標

通過對調研收集到的相關資料與信息，結合測試目標和內容，針對性地從不同角度與層麵對信息進行分析梳理，並重點分析係統的交易路徑、交易關聯關係、數據的處理與流轉、業務量、交易比例、典型交易，以及係統的處理能力等性能點。

2.2 已上線係統

2.2.1 交易量分析

進行係統交易量分析主要考慮以下幾個方麵：

• 曆史峰值交易日的交易量
  分析係統在曆史最高交易日係統的交易情況，主要分析最高交易日業務的構成、占比、係統資源等消耗情況，比如峰值期間CPU、內存、I/O等資源的消耗情況，以及交易響應時間、交易吞吐量、交易成功率等應用方麵的性能指標，通過分析這些信息的目的在於分析係統可能承受的最大交易量是怎樣，在測試環境可以按照預期進行實際的測試，並盡早的發現在峰值運行時間係統可能會出現的一些異常情況，為實際生產係統的性能做參考。
• 特殊交易日的交易量
  某些係統可能在一些特定的日期，比如促銷、雙11、證券係統在基金申購日、國債發行日等特殊日期其業務量與普通交易日的業務類型或者業務量占比是不同的，此外不同的係統在節假日或工作日內其業務量和占比也有可能是不同的。
• 不同交易渠道發起的交易量
  針對同一係統可能會有不同的發起終端，進行交易量分析時要考慮到從不同交易渠道發起的交易量情況，以便在測試環境能進行同樣比例地模擬。比如電子購物網站，購物發起端主要有PC端和手機端、支付的時候主要有各大銀行、支付寶、快錢等；再比如對證券係統，發起的途徑有若幹種：網點櫃台、自助設備、電話委托、網上銀行、手機銀行等渠道，進行業務量分析要分別統計出從不同渠道發起的交易量的占比情況。

2.2.2 交易占比分析

交易占比的分析主要為了對係統的業務規模進行定量的分析，得出在特定條件下係統各業務的占比關係如何。交易比例同交易量的分析類似，也要區分不同的場景下，係統業務的構成：

• 曆史峰值交易日的交易配比
  根據之前的分析我們得出係統在曆史峰值交易日的交易量，同時要分析此期間內主要的業務構成是怎樣的，可以考察交易量top10位或者20位的交易主要是些什麼樣的交易，這些交易占總交易量的百分比，進而換算統計這些業務之間的比例關係是怎樣的。依據同樣的比例關係可以在測試環境進行同比例的模擬測試，以保證測試的準確性和有效性。
• 特殊交易日的交易配比
  同樣的，在特殊交易日的業務構成和各業務占比也采用上麵的方法進行統計。
• 不同交易渠道發起的交易配比
  這主要是進行對各交易發起方式進行量化的分析，在進行容量測試或性能測試時測試人員可以比較直觀的了解到如何對係統進行加壓。

2.2.3 單支交易分析

單支交易分析是指針對具體一支交易進行深入的調研與分析，目的在於清楚地理解特定交易在不同係統之間的調用關係和實際處理過程。 結合測試的環境及時間要求，在業務分析過程中，可能無法短期內完成所有交易的分析，但必須進行對關鍵交易、代表性交易的分析，特別是不同路徑的代表性交易的分析，以便於後續相關測試模型的建立。 單支交易調查內容主要包括：

• 交易功能描述 描述交易的基本業務功能
• 交易交換處理流程 對於跨係統交易，應描述其關聯係統以及在不同係統間的交換過程，對應的交易碼/交易名稱、主要處理邏輯，以及流轉順序
• 交易操作說明 描述交易的發起方，發起方式、具體操作及步驟
• 交易數據說明 描述交易的輸入/輸出，涉及到的係統數據、業務參數等

2.2.4 典型交易分析

典型交易是指具有一定代表性的重要交易，包括幾個方麵的代表性：
業務功能代表性或交易類型的代表性

• 交易量的代表性
• 交易路徑的代表性
• 處理邏輯的代表性
• 開發人員挑選的交易
• 有業務發展趨勢的交易
• 資源消耗高的交易
  另外還可以包括一些關鍵交易或重點交易，例如高服務級別、關鍵數據處理類的交易。這些交易也是對係統業務掌握以及在性能測試中需要重點了解的內容。通過分析這些典型交易，能快速全麵的理解係統的處理環節和處理過程，以及通過從不同渠道發起的交易，要經過各不同的交易係統。

2.2.5 批量交易分析

日終批量分析主要考慮以下幾方麵的內容：

• 日終批量處理的基本流程
  首要分析日終批量處理的業務流程。可以從日終批處理任務的基本步驟著手，逐一進行分析出每一步進行的業務功能，需要處理的交易量，可能的耗費時間等。在這個過程中可以建立一個日終批處理的表格類詳細統計一些關鍵的業務或技術信息。
  以下是一個簡單的樣例：

• 日終批量處理的時間窗口
  這是統計總的日終批量處理的消耗時間。日終批處理的實際耗時如果大於設定的時間窗口必然會影響到日間業務的正常運轉。

• 日終批量處理失敗後的異常處理
  這一點是在係統架構設計時考慮的問題，在這裏列出來是為了在測試環境能對這些異常情況進行相關的模擬，驗證對應的解決方案是否正確、完善。也為生產運維部門提供一些回歸測試，對生產環境的一些現象進行複測，查找原因。

2.2.6 批量數據分析

批量數據處理分析包含係統曆史數據量、日交易流水數據量。考慮處理過程中是否包含數據轉換等其他涉及數據處理的問題。

• 係統曆史數據量 主要是分析係統目前沉積的曆史數據量的規模，分析係統業務處理是運行在怎樣的一個數據量級上，包含數據記錄總數和數據存儲占用的磁盤空間大小等。這對於在測試環境準備的基礎數據量是有很大指導意義的，如果測試環境的數據量級和生產係統相差很遠，可想而知其測試的結果的真實性和準確性是要大大折扣的。
• 日交易記錄數據量
  主要分析係統的日交易處理生成多少筆記錄，以及這些記錄占用的磁盤空間，這樣在測試環境進行測試數據準備時，就有一個數量級的概念，準備需要花費的時間和空間就有一個初步估算。
• 數據轉換規則
  分析各係統之間的數據轉換規則，采用何種技術實現，不同數據級的耗時情況，處理中是否需要人為手工幹預，處理過程能否監控。

2.2.7 生產問題分析

對生產問題的分析主要是調查係統在生產運營過程中，是否曾發生過嚴重的性能事故，如宕機、資源耗盡、交易阻塞、業務不能受理等影響自身業務及關聯係統業務處理能力的情況。
生產問題是多種多樣的，可能是係統的資源不夠、配置不合理、功能不完善、網絡異常、非法操作、應用程序例外處理錯誤或者一些特殊情況的出現等等原因引起。而且往往許多生產問題與特定環境及時間有關，問題也不好模擬重現，因此在測試中，並不能保證準確定位到問題的症結所在。
在性能測試分析時，可通過生產問題現象、現場分析意見、生產中的處理方式等信息，與項目組、運維進行基本判斷，並製訂相應的驗證策略，在性能測試過程中進行模擬驗證，找到引發問題的原因，從而協助項目組進行問題的定位和解決。

操作過程：

主要的分析點：

• 問題發生前是否有征兆
• 問題是否發生在特殊日期
• 受影響的業務主要有哪些
• 事故點與前端係統及後端係統接口的狀況
• 網絡狀況
• 操作係統、中間件、數據庫等係統軟件是否有升級、補丁，應用係統是否有功能改造
• 是否正進行係統維護或有異常操作
• 業務受理場景是否有異常或特殊情況

2.2.8 樣例

通過分析某係統曆史業務高峰時候業務量，發現某4天高峰時段10分鍾的交易量是不同的，其中有2天高峰時段DGZZ的業務量占比在50%左右，而另外兩天高峰時段DGZZ的業務量占比在20%左右，業務占比差距很大，因此在測試的時候，需要建立兩個不同的業務模型。

2.3 未上線係統

2.3.1 風險分析

已上線係統相關分析的方法完全適用於未上線係統，由於未上線係統沒有具體的業務量作為參考，業務類型和占比隻能依靠業務部分預估。預估畢竟有很大的誤差，也無法很精確的模擬現實中的場景，因此對於未上線係統，盡量減少風險。

2.3.2 風險預防

對於未上線的係統，選取業務模型的時候，應遵循如下準則：

• 盡可能的多選取典型業務
• 至少做5個梯度單交易負載，看服務器資源消耗情況
• 重新評估業務模型，對於資源消耗比較高的業務，如果業務模型中此業務占比很低的話，業務一旦爆發，會存在很大的性能風險，因此混合交易的時候，需要提高此業務占比。

3. 業務模型分析過程

請參照：流程體係——生產係統曆史交易量分析方法

訪問性能測試控製台

最後更新：2016-05-06 10:44:39

  上一篇： 測試指標__性能測試技術體係_性能測試體係_性能測試-阿裏雲

  下一篇： 測試模型__性能測試技術體係_性能測試體係_性能測試-阿裏雲