• <tr id='AKML8t'><strong id='AKML8t'></strong><small id='AKML8t'></small><button id='AKML8t'></button><li id='AKML8t'><noscript id='AKML8t'><big id='AKML8t'></big><dt id='AKML8t'></dt></noscript></li></tr><ol id='AKML8t'><option id='AKML8t'><table id='AKML8t'><blockquote id='AKML8t'><tbody id='AKML8t'></tbody></blockquote></table></option></ol><u id='AKML8t'></u><kbd id='AKML8t'><kbd id='AKML8t'></kbd></kbd>

    <code id='AKML8t'><strong id='AKML8t'></strong></code>

    <fieldset id='AKML8t'></fieldset>
          <span id='AKML8t'></span>

              <ins id='AKML8t'></ins>
              <acronym id='AKML8t'><em id='AKML8t'></em><td id='AKML8t'><div id='AKML8t'></div></td></acronym><address id='AKML8t'><big id='AKML8t'><big id='AKML8t'></big><legend id='AKML8t'></legend></big></address>

              <i id='AKML8t'><div id='AKML8t'><ins id='AKML8t'></ins></div></i>
              <i id='AKML8t'></i>
            1. <dl id='AKML8t'></dl>
              1. <blockquote id='AKML8t'><q id='AKML8t'><noscript id='AKML8t'></noscript><dt id='AKML8t'></dt></q></blockquote><noframes id='AKML8t'><i id='AKML8t'></i>

                性能測試-銀行快要幸福行業測試方案

                方案概述

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

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

                總體目標

                對核心系☆統進行峰值測試,達到:
                一, 對核心業務系統進行分階段進行性能測試。
                二, 根據當前』的運行情況,分析性能測試場景、估算高吞吐量,然後根據吞吐量進行性能測試(模擬高峰),看系統是否存在隱藏缺陷。
                三, 在〓各個性能測試場景之下,持續對系統加大壓力,測試系統的大容量(平均響應時間在可接受範圍內),並且發現系統在達到大容量之後∑是否出現異常,為安全生耳朵裏產提供指標。
                四, 對系統未來3-5年的壓力進行預估(數據量和交易量),並根據預估結果進行測試,發現性能瓶頸和需要㊣ 優化的節點。
                五, 根據測試情況,提交測試報告和缺陷報告。

                性能測試方法論№

                1.性能測試分類

                性能測試(Performance Testing):性能測試方●法是通過模擬生產運行的業務壓力量和使用場景組合,測那是之前試系統的性能是否滿足生成性能要求。即在特定的運行條件下驗證系統的能力狀況。

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

                壓力測試(Stress Testing):測試系統在一定飽和狀態下系統能夠處理的會話能力,以及是否出現錯誤,一般用於穩定性測試。可以理解為資源的極限測試。測試關註在資源處Ψ 於飽和或超負荷的情況下,系統能否正常運行,是一種在極端壓力下的穩定性測試。其主要意義是通過測試調優保證系統即使在極端的壓力情況下也不會出錯▅甚至系統崩潰。

                配置測試(Configuration Testing):通過對被測系統的軟硬件環境的調整,了解各種不同環⊙境對性能影響的程度,從而找到系統各項資源的有分配原則。主要用於性能調優,在經過測試獲得了基準測試數據後,進行環境調整(包∞括硬件配置、網絡、操作系統、應用服務器、數據庫等),再將測〒試結果與基準數據進行對比,判斷調整是否達到佳狀態。

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

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

                2.性能測試的一般過程

                我們把性能測試分成以上階段:

                測試計劃階段
                規劃測試過程,編寫測試方案▆、測試計劃。
                準備測試人員,搭建測試環境。

                建立測試模型階段
                根據歷史╲數據,構建測試模型,包括:壓力模型、業務模型、數據模型、監控模型等。
                測試模型主要是根據歷①史信息和未來的預期來構建。

                創建測試場景階段々
                創建測試模型之後,需要創建№不同的測試場景。
                根據每日業務分布情況和特殊營業日的業務分布情況,對峰值曲線進行分析,主要分析曲線的峰值和拐點(曲率發卐生大的變化節點),拆分場景。

                創建測試腳本
                根據測試※場景和具體的業務,創建測試腳本。
                測試腳本依賴於測試工具。測試腳本需要考慮到被測試系統的響應速度等問題。

                執行與監控↑↑
                根據測試場景和加壓方式等,進行測試。
                測試分成多個輪次進行。

                測試分析
                分析測試結果。在測試過程中,會進行壓卐力測試、負載測試、性能測試三個部分的測試(本次測試),並且獲得隨著壓力增長而變化的々性能監控數據。
                通過∩對數據的分析,獲得測試報告,對發現的缺陷提交缺陷身影。

                3.性能測試◤模型

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

                壓力模型
                壓力模型,是根據系統的歷史數據,分形當⊙前系統壓力的方法。
                主要是對峰值的交易百分比進行分析處理,獲得模擬□的峰值。

                業務模型
                根據不同的業務品種(交易)來進行分析,分析在不同的場景ζ下,交易的百分比分布情況。

                數據模型
                數據模型,主要是①根據當前系統的數據量和關聯。
                數據模型需要在測試時候選擇不同的關聯數據。例如:典型機構→的選取等。

                監控模型
                對哪些部分進行監控,監控的數【據。

                風險模型
                系統存在哪些風險,也是需◣要重點關註的數據和瓶頸。
                對於重點關註的數據和瓶頸,需要進行重點測試。

                環境環境

                1. 測試環境

                系統結構

                說明:
                1、 前置系Ψ統服務器主要負責櫃面渠道、網銀渠道之外的渠道,以及與第三方系統的↓接口;
                2、 核心業務系統采用AS/400的系統;

                軟件配置

                資源名稱/類型

                配置

                數據庫管理系統

                DB2(AS400)、未知(前置系統)

                應用軟件

                核心業務系統、前置系統

                客戶端〖前端展示

                櫃臺業務系統

                自動測試工何林跟那向來天坐在一張桌子之上具

                性能測』試工具

                測試管理測試工具

                N/A

                測試策略

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

                壓力模型

                當前高峰的壓力(下圖為節日交易◣數據):

                取高峰的數據為日均XX筆/日;
                每☆小時高交易量為: XX筆/小時,高峰時刻的平均吞吐率為:XX筆/秒。

                1.估▽算模型一

                從每日交易的分布情況來看,......。
                高吞吐率目標:75.9*120%=91筆/秒。

                2.估算模型二

                從交易高峰時段來看,按照......來計算:
                XX/(7*3600) = XX筆/秒。

                3.峰值估算

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

                測試場景模型分析

                一∞般營業日
                根據XX銀畢竟時間也不短了行的數據:

                節假日
                節假日的情況♂如下:

                峰值包括2個:
                第一,上午10-11點高峰,占總交易量◥的10.07%;
                第二,下午3-4點高峰,占總交易量的☉11.39%;

                場景

                場景

                場景描述

                備註

                上午8-9點

                 

                 

                上午10-11點

                 

                 

                下午3-4點

                 

                 

                下午11點

                 

                 

                測試策略

                不同客戶端加壓的影響

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

                比較項目

                協議加壓

                客戶端加壓

                腳本的復雜

                簡單,容易產】生大的壓力

                復雜,需要更多的客戶端來執行。每個客戶端都模擬何林苦笑鼠標、鍵盤的∩輸入輸出,更真實

                VU

                不需要很多的虛擬用戶(VU)

                需要更多的虛擬用戶(VU)

                測試環境

                比較簡單,基本上單機即可

                需要更復雜的測試環境起碼有過萬滴了◥,通過界面√操作,每1-3分鐘發起一個交易

                場景真實模擬

                需要編寫比較復雜的腳本

                能夠模擬更真實的場♀景(如二段式交易)

                客戶端看著這長達百米並發個數★◆

                支持模擬多個並發

                能夠模擬更多的客戶端並發

                測試腳本分類

                腳本分類

                屬性

                備註

                客戶端加壓腳本

                面向操作的︻腳本

                 

                客戶端加壓到後臺腳本

                面向協議

                 

                前置加壓腳本

                面向協議

                需要更多的虛擬用戶(VU)

                網銀界面加壓腳本

                面向∮操作界面

                需要更復雜的測試環境,通過界面♀操作,每1-3分鐘發起一個交易

                網銀協議腳本

                面向協議

                能真是找死夠模擬更真實的場景(如二段式交易)

                測試●交易選取

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

                性能測試執▲行

                壓力產生模型

                性能ξ測試指標
                性能指標的前提:交易成功率超過99.5%。
                吞吐率:
                並發數:
                平均響應時間:
                CPU占用率:
                I/O:
                數據庫(鎖、sql執行時間等)數據庫是AS/400上的,還需要開發專門的程序分析性能

                滬ICP備07036474號 2003-2019 版權所有 上海澤眾軟件科技有限公司 Shanghai ZeZhong Software Co.,Ltd.