陳珊珊

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

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

中圖分類號：TP274+.4 文獻(xiàn)標(biāo)識碼：A 文章編號：1006-8937（2016）32-0086-02

1 概 述

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

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

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

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

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

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

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

2 性能測試概述

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

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

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

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

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

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

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

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

3 測試方案

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

3.1 系統(tǒng)結(jié)構(gòu)

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

3.2 具體測試目標(biāo)

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

①訪問的平均響應(yīng)時間；

②訪問的最大響應(yīng)時間；

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

④訪問用戶的成功率；

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

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

3.3 測試場景設(shè)計|

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

3.3.1 單一場景測試用例

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

3.3.2 混合場景測試用例

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

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

4 案例測試及分析

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

4.1 測試結(jié)果

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

4.2 各測試結(jié)果指標(biāo)分析

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

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

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

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

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

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

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

5 結(jié) 語

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

參考文獻(xiàn)：

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

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

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

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

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

51-53.