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 批量交易分析

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

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

步驟任務名稱業務量預計耗時

BT1	批量發紅包	總記錄3000萬，共35省市	20分鐘以內
BT2	批量推送	總記錄3000萬，共35省市	30分鐘以內
……	……	……	……

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

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

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. 業務模型分析過程

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

訪問性能測試控制臺

轉載于:https://www.cnblogs.com/AmilyWilly/p/8603131.html

總結

以上是生活随笔為你收集整理的业务模型的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。