1 方案概述

XX銀行的核心業務系統是運行多年的系統。隨著業務量的逐年上升，對安全生產提出了挑戰。因此需要進行一次性能評估測試，達到：第一，當前系統能夠達到的峰值；第二，對于未來3-5年的預期，發現系統瓶頸，為系統調優做準備。

需要通過性能測試，來發現當前系統的瓶頸，以確定哪些部分需要進行優化，為后期的系統調優提供依據。

1.1 總體目標
對核心系統進行峰值測試，達到：

第一， 對核心業務系統進行分階段進行性能測試；

第二， 根據當前的運行情況，分析性能測試場景、估算吞吐量，然后根據吞吐量進行性能測試（模擬高峰），看系統是否存在隱藏缺陷。

第三， 在各個性能測試場景之下，持續對系統加大壓力，測試系統的容量（平均響應時間在可接受范圍內），并且發現系統在達到容量之后是否出現異常，為安全生產提供指標。

第四， 對系統未來3-5年的壓力進行預估（數據量和交易量），并根據預估結果進行測試，發現性能瓶頸和需要優化的節點。

第五， 根據測試情況，提交測試報告和缺陷報告。

1.2 性能測試方法論

1.2.1 性能測試分類
性能測試（Performance Testing）：性能測試方法是通過模擬生產運行的業務壓力量和使用場景組合，測試系統的性能是否滿足生成性能要求。即在特定的運行條件下驗證系統的能力狀況。

負載測試（Load Testing）：在給定的測試環境下，通過在被測系統上不斷增加壓力，直到性能指標超過預定指標或某種資源使用已經達到飽和狀態，目的是了解系統性能容量和處理能力極限。負載測試的主要用途是發現系統性能的拐點，尋找系統能夠支持的用戶、業務等處理能力的約束。也可以理解為擴展性測試（Scalability Testing），即在固定測試環境，在其它測試角度（負載方面）不變的情況下，變化一個測試角度并持續增加壓力，查看系統的性能曲線和處理極限，以及是 否有性能瓶頸存在（拐點）。主要意義是從多個不同的測試角度去探測分析系統的性能變化情況，配合性能調優。測試角度可以是并發用戶數、業務量、數據量等不 同方面的負載。

壓力測試（Stress Testing）：測試系統在一定飽和狀態下系統能夠處理的會話能力，以及是否出現錯誤，一般用于穩定性測試。可以理解為資源的極限測試。測試關注在資源處于飽和或超負荷的情況下，系統能否正常運行，是一種在極端壓力下的穩定性測試。其主要意義是通過測試調優保證系統即使在極端的壓力情況下也不會出錯甚至系統崩潰。51Testing軟件測試網，g ZA){N%w1N

配置測試（Configuration Testing）：通過對被測系統的軟硬件環境的調整，了解各種不同環境對性能影響的程度，從而找到系統各項資源的有分配原則。51Testing軟件測試網m(V:w/_!v主要用于性能調優，在經過測試獲得了基準測試數據后，進行環境調整（包括硬件配置、網絡、操作系統、應用服務器、數據庫等），再將測試結果與基準數據進行對比，判斷調整是否達到狀態。

并發測試（Concurrency Testing）：模擬并發訪問，測試多用戶并發訪問同一個應用、模塊、數據時是否產生隱藏的并發問題，如內存泄漏、線程鎖、資源爭用問題。測試目的并非為了獲得性能指標，而是為了發現并發引起的問題。

可靠性測試（Reliability Testing）：通過給系統加載一定的業務壓力的情況下，讓應用持續運行一段時間，測試系統在這種條件下是否能夠穩定運行。需要和壓力測試區分開，兩者的測試環境和測試目的不一樣。壓力測試強調在資源極限情況下系統是否出錯，可靠性測試強調在一定的業務壓力下長時間（如24×7）運行系統，關注系統的運行情況（如資源使用率是否逐漸增加、響應是否是否越來越慢），是否有不穩定征兆。

1.2.2 性能測試的一般過程
略

如上圖，我們把性能測試分成以上階段：

測試計劃階段

規劃測試過程，編寫測試方案、測試計劃。

準備測試人員，搭建測試環境。

建立測試模型階段

根據歷史數據，構建測試模型，包括：壓力模型、業務模型、數據模型、監控模型等。

測試模型主要是根據歷史信息和未來的預期來構建。

創建測試場景階段

創建測試模型之后，需要創建不同的測試場景。

根據每日業務分布情況和特殊營業日的業務分布情況，對峰值曲線進行分析，主要分析曲線的峰值和拐點（曲率發生大的變化節點），拆分場景。

創建測試腳本

根據測試場景和具體的業務，創建測試腳本。

測試腳本依賴于測試工具。測試腳本需要考慮到被測試系統的響應速度等問題。

執行與監控

根據測試場景和加壓方式等，進行測試。

測試分成多個輪次進行。

測試分析

分析測試結果。在測試過程中，會進行壓力測試、負載測試、性能測試三個部分的測試（本次測試），并且獲得隨著壓力增長而變化的性能監控數據。

通過對數據的分析，獲得測試報告，對發現的缺陷提交缺陷。

1.2.3 性能測試模型
性能測試模型，分成：壓力模型、業務模型、數據模型、監控模型、風險模型等。

壓力模型

壓力模型，是根據系統的歷史數據，分形當前系統壓力的方法。

主要是對峰值的交易百分比進行分析處理，獲得模擬的峰值。

業務模型

根據不同的業務品種（交易）來進行分析，分析在不同的場景下，交易的百分比分布情況。

數據模型

數據模型，主要是根據當前系統的數據量和關聯。

數據模型需要在測試時候選擇不同的關聯數據。例如：典型機構的選取等。

監控模型

對哪些部分進行監控，監控的數據。

風險模型

系統存在哪些風險，也是需要重點關注的數據和瓶頸。

對于重點關注的數據和瓶頸，需要進行重點測試。

2 環境環境
2.1 測試環境
2.1.1 系統結構

說明：

1、 前置系統服務器主要負責柜面渠道、網銀渠道之外的渠道，以及與第三方系統的接口；

2、 核心業務系統采用AS/400的系統；

2.1.2 軟件配置

3 測試策略
制訂測試策略，首先有對測試進行分析，識別在影響性能測試的風險項。然后根據風險項來制訂測試策略。

3.1 壓力模型
當前高峰的壓力（下圖為節日交易數據）：

取峰的數據為日均XX筆/日；

每小時交易量為：  XX筆/小時，高峰時刻的平均吞吐率為：XX筆/秒。

3.1.1 估算模型一
從每日交易的分布情況來看，......。

吞吐率目標：75.9*120%=91筆/秒。

3.1.2 估算模型二
從交易高峰時段來看，按照......來計算：

XX/(7*3600) = XX筆/秒。

3.1.3 峰值估算
根據兩個模型的估算，我們可以把交易的峰值設置到XX筆/秒。

3.2 測試場景模型分析
3.2.1 一般營業日
根據XX銀行的數據：

3.2.2 節假日
節假日的情況如下：

峰值包括2個：

第一，上午10-11點高峰，占總交易量的10.07%；

第二，下午3-4點高峰，占總交易量的11.39%；

3.2.3 場景

3.3 測試策略
3.3.1 不同客戶端加壓的影響

如上圖，是系統的拓撲結構。可以看到在性能測試中，可以通過客戶端發起交易來給系統進行加壓，也可以通過發送報文的方式來加壓。兩種產生的效果差異在于：

3.3.2 測試策略
略

3.3.3 測試腳本分類

3.3.4 測試交易選取

3.3.5 測試數據選取
 壓力數據是按照的峰值時間段（如9點到10點）的數據交易量來進行模擬。

3.4 性能測試執行
3.4.1 壓力產生模型
3.4.2 性能測試指標
性能指標的前提：交易成功率超過99.5%。

吞吐率：

并發數：

平均響應時間：

CPU占用率：

I/O：

數據庫（鎖、sql執行時間等）數據庫是AS/400上的，還需要開發專門的程序分析性能