省級集中營銷管理系統(tǒng)性能測試

陳珊珊

摘 要：性能測試是系統(tǒng)上線前最重要的系統(tǒng)級測試，省級集中的營銷系統(tǒng)在正式運行前進行全面、完整的性能測試進行評估是必須的環(huán)節(jié)。文章簡述了性能測試的方法、指標和資源監(jiān)控的內(nèi)容，詳細分析了省級集中營銷系統(tǒng)的體系結構，針對具體的測試目標及海量數(shù)據(jù)處理的要求設計了測試業(yè)務場景。并以一測試場景為例，介紹了消除性能瓶頸的方法。

關鍵詞：性能測試；數(shù)據(jù)處理；場景設計；調(diào)優(yōu)

中圖分類號：TP274+.4 文獻標識碼：A 文章編號：1006-8937（2016）32-0086-02

1 概 述

性能測試是保證軟件質(zhì)量的重要手段，屬于軟件測試中的系統(tǒng)級測試， 它針對軟件在繼承系統(tǒng)中運行的性能指標進行測試， 旨在及早確定和消除新系統(tǒng)中的性能瓶頸[1]。

通過負載測試、壓力測試等方法的性能測試，測試應用系統(tǒng)能否承受大量的并發(fā)用戶數(shù)以及快速響應用戶發(fā)送的請求，能否長時間穩(wěn)定運行。在系統(tǒng)測試期間監(jiān)控資源、獲取性能指標并進行分析，找出系統(tǒng)在硬件、操作系統(tǒng)、數(shù)據(jù)庫、應用軟件等方面的性能瓶頸加以改善，使整個系統(tǒng)的性能得到改進優(yōu)化[2]。

省級集中的一體化營銷管理系統(tǒng)服務于全省廣大用電客戶和適于企業(yè)內(nèi)部管理，具有如下特點：

①在可用性方面，需保證7×24小時不間斷運行；

②在業(yè)務處理方面，應具海量數(shù)據(jù)快速處理、復雜業(yè)務流轉暢順、資料查詢及時響應；

③在系統(tǒng)擴展性方面，需滿足多層次應用、地域面積覆蓋廣、使用人員眾多等多方要求。因此，系統(tǒng)的性能測試需要有完整、全面的方案。

為了獲取省級集中營銷系統(tǒng)性能指標瓶頸，提出改進、優(yōu)化措施，基于已有成果，本文結合省級集中營銷系統(tǒng)的體系結構，在設定具體測試目標基礎上，提出了基于海量數(shù)據(jù)處理的測試場景具體設計原則和監(jiān)控內(nèi)容，通過案例分析說明了系統(tǒng)性能調(diào)優(yōu)的具體方法。

2 性能測試概述

性能測試是通過模擬真實環(huán)境下的負載，采集系統(tǒng)各方面的性能數(shù)據(jù)，評估系統(tǒng)正常運行情況下的承受力和穩(wěn)定性，分析系統(tǒng)的性能與存在的瓶頸。測試方法主要包括負載測試、壓力測試、配置測試并發(fā)測試和可靠性測試等[3]。在測試過程中，通常需要合理的結合幾種測試方法，模擬真實環(huán)境，設計不同的測場景獲取更多有效的性能指標。

性能測試一般基于如下目的：

①驗證系統(tǒng)在給定條件下是否達到設計目標或用戶要求；

②探測系統(tǒng)在給定條件下極限處理能力；

③通過對系統(tǒng)各參數(shù)的調(diào)整，測試系統(tǒng)的最優(yōu)性能配置；

④通過性能測試發(fā)現(xiàn)功能測試難以發(fā)現(xiàn)的與性能有關缺陷。

因此，對當前的系統(tǒng)給予相當?shù)呢撦d，并且能夠分析系統(tǒng)在給定負載下的表現(xiàn)是實現(xiàn)性能測試的關鍵。為有效發(fā)現(xiàn)負載條件下的各項性能指標，需要篩選分析影響系統(tǒng)的主要測試性能因素，才能做到有的放矢。應用系統(tǒng)性能測試主要包括：響應時間、吞吐量、每秒事務數(shù)（TPS）、資源利用率、數(shù)據(jù)庫性能等方面。

在進行性能測試時，需要對系統(tǒng)各個方面（包括系統(tǒng)硬件、操作系統(tǒng)、中間件、數(shù)據(jù)庫等）統(tǒng)一監(jiān)控，以便進行系統(tǒng)瓶頸的分析與優(yōu)化。

3 測試方案

省級集中的營銷系統(tǒng)為了滿足高可用性、高可擴展性和高性能需求，采用了分布式協(xié)調(diào)服務ZooKeeper和自適配通信環(huán)境（ACE）技術構建通用的高性能分布式計算框架；同時，為了滿足全省千家萬戶用電服務、電量電費計量收費的信息支撐服務要求，在系統(tǒng)中存放了海量的用戶數(shù)據(jù)、電網(wǎng)數(shù)據(jù)，以及系統(tǒng)支持信息。測試場景的設計既要發(fā)現(xiàn)系統(tǒng)框架中用戶訪問的性能瓶頸，又要測試到海量數(shù)據(jù)處理的反應速度。

3.1 系統(tǒng)結構

基于SOA的多層架構的省級集中系統(tǒng)，在技術路線上采用將表示邏輯、業(yè)務邏輯與數(shù)據(jù)邏輯相分離，客戶端支持PC、掌上電腦、手持電腦等設備；接入端通過負載均衡器將用戶的訪問按照一定的策略分配到不同的服務器群組；應用服務器將展示與運算邏輯分離，而邏輯運算服務組件采用混合模式，針對不同的服務要求采用C或Java來進行開發(fā)，以充分利用C語言及Java語言的優(yōu)勢；數(shù)據(jù)層通過小型機群與存儲陣列實現(xiàn)海量數(shù)據(jù)的存放與訪問。

3.2 具體測試目標

評估系統(tǒng)在現(xiàn)有軟、硬件環(huán)境下可支持業(yè)務規(guī)模的系統(tǒng)性能。在包括多類業(yè)務場景情況下的如下指標：

①訪問的平均響應時間；

②訪問的最大響應時間；

③平均每秒處理訪問數(shù)量；

④訪問用戶的成功率；

⑤規(guī)定最大用戶并發(fā)數(shù)下的性能指標。

根據(jù)上述量化的指標測試，分析被測營銷管理系統(tǒng)在不同并發(fā)用戶數(shù)下的性能指標，找出系統(tǒng)性能瓶頸，提出改善性能方案。

3.3 測試場景設計|

性能測試的用例設計不同于功能測試用例，它只是有針對性地根據(jù)系統(tǒng)最可能出現(xiàn)瓶頸的功能點來編寫，不需要覆蓋整個系統(tǒng)需求[4]。為使性能測試的覆蓋率更廣泛，性能測試用例的設計需考慮單一場景測試用例和混合場景測試用例的同時存在，性能測試用例中也需考慮并發(fā)數(shù)、響應時間、持續(xù)時間、資源使用情況等關鍵設計值或者指標值的存在。見表1。

3.3.1 單一場景測試用例

單一場景測試用例（見表1）考察系統(tǒng)對于單一業(yè)務的并發(fā)處理能力，本次測試選擇具有代表性、最核心的9個業(yè)務場景，按照實際數(shù)據(jù)確定并發(fā)數(shù)。

3.3.2 混合場景測試用例

在性能測試中，常見的錯誤觀點是，認為分別優(yōu)化單個操作，就能優(yōu)化系統(tǒng)的整體性能，而事實上系統(tǒng)運行時，不同的操作之間往往對系統(tǒng)資源有互鎖關系。為了模擬用戶的真實體驗，避免性能測試偏重于技術人員的想法，需要綜合考慮整個系統(tǒng)的運行情況[5]。省級集中的應用系統(tǒng)中最具有代表性、最核心的9個單一業(yè)務場景組合起來則是有代表性、最核心的混合場景的測試用例，見表2。

按照實際數(shù)據(jù)情況確定并發(fā)數(shù)。在設計測試場景時，嚴格按照業(yè)務數(shù)據(jù)的處理關聯(lián)和順序，并且為真實模擬實際業(yè)務來滿足測試的需要。

4 案例測試及分析

性能測試中的測試分析是難點，在應用測試實踐中，需要針對具體測試結果進行分析。以下列舉本方案中單一登錄業(yè)務場景的測試及系統(tǒng)性能問題的調(diào)優(yōu)方法和步驟，其中案例所用數(shù)據(jù)庫為Oracle；數(shù)據(jù)庫服務器操作系統(tǒng)為AIX；應用服務器平臺為WebLogic。

4.1 測試結果

模擬實際操作員的登陸退出操作的功能，設置1 000并發(fā)循環(huán)10分鐘，測試結果顯示登陸的平均事務響應時間為3.139 S，HTTP返回狀態(tài)全部是HTTP 200狀態(tài)。

4.2 各測試結果指標分析

①系統(tǒng)響應：在10分鐘內(nèi)運行虛擬用戶數(shù)一直在1000并發(fā)中，平均事務響應時間無特別大的波動，系統(tǒng)在此壓力下運行比較穩(wěn)定。

②在10分鐘內(nèi)每秒點擊率圖和吞吐量圖呈現(xiàn)一致情況，平均每秒吞吐量為14 967 273.462Byte/s=14.27 MB/s，相對于千兆網(wǎng)絡不會形成網(wǎng)絡瓶頸。

③服務器性能：從Web服務器、Java組件服務器、數(shù)據(jù)庫服務器資源情況來看，Web應用服務器CPU在30%左右，JAVA應用服務器CPU不超過5%，數(shù)據(jù)庫服務器CPU不超過5%，服務器資源運行良好。

從上述結果中我們看到登陸功能壓力測試期間運行穩(wěn)定，各個系統(tǒng)資源沒有形成明顯的瓶頸。

④問題癥結：平均響應時間為3.139 s，不符合要求。針對這種情況，我們對登陸事務進行網(wǎng)頁細分進一步查看時間消耗，找到登陸中時間占比最大的頁面請求，進一步排查發(fā)現(xiàn)登陸功能的頁面請求量比較多。

4.3 系統(tǒng)優(yōu)化

經(jīng)程序代碼排查，簡化login.jsp頁面請求、壓縮grid.js文件組件，提高較大頁面組件的執(zhí)行效率，從而縮短響應時間，提高系統(tǒng)性能。調(diào)整后，登陸響應時間滿足測試方案需求。

5 結 語

性能測試是應用系統(tǒng)上線前必須經(jīng)歷的過程。系統(tǒng)設計中的任何一個小問題都可能造成嚴重的性能影響，尤其針對省級集中的系統(tǒng)，一旦出現(xiàn)問題影響范圍更大。在性能測試方案中，針對系統(tǒng)特點模擬運行真實的業(yè)務場景發(fā)現(xiàn)系統(tǒng)架構、系統(tǒng)設計、中間件、數(shù)據(jù)庫、應用服務等各個方面的性能問題，對性能瓶頸有的放矢不斷優(yōu)化調(diào)整，使省級集中的營銷管理系統(tǒng)達到設計和應用要求，為系統(tǒng)上線打下堅實的技術基礎。

參考文獻：

[1] 張永祥等.性能測試專家分析系統(tǒng)[J].計算機系統(tǒng)應用，2013，22（4）：6-9.

[2] 李怡，周國祥.基于Load Runner 的一種性能測試流程方案研究與設 計[J].計算機應用研究，2009，26（11）：4143-4145.

[3] 莊嚴，程紹銀，廉明，等.性能測試在等級測評中的應用[J]計算機應用與 軟件，2014，31（7）：55-58.

[4] 李怡，周國祥.基于Load Runner 的一種性能測試流程方案研究與設 計[J].計算機應用研究，2009，26（11）：4143-4145.

[5] 簡玲.B/S系統(tǒng)性能測試的設計與實現(xiàn)[J].計算機工程，2009，35（10）：

51-53.