省級集中營銷管理系統性能測試

陳珊珊

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

關鍵詞：性能測試；數據處理；場景設計；調優

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

1 概 述

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

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

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

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

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

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

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

2 性能測試概述

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

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

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

②探測系統在給定條件下極限處理能力；

③通過對系統各參數的調整，測試系統的最優性能配置；

④通過性能測試發現功能測試難以發現的與性能有關缺陷。

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

在進行性能測試時，需要對系統各個方面（包括系統硬件、操作系統、中間件、數據庫等）統一監控，以便進行系統瓶頸的分析與優化。

3 測試方案

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

3.1 系統結構

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

3.2 具體測試目標

評估系統在現有軟、硬件環境下可支持業務規模的系統性能。在包括多類業務場景情況下的如下指標：

①訪問的平均響應時間；

②訪問的最大響應時間；

③平均每秒處理訪問數量；

④訪問用戶的成功率；

⑤規定最大用戶并發數下的性能指標。

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

3.3 測試場景設計|

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

3.3.1 單一場景測試用例

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

3.3.2 混合場景測試用例

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

按照實際數據情況確定并發數。在設計測試場景時，嚴格按照業務數據的處理關聯和順序，并且為真實模擬實際業務來滿足測試的需要。

4 案例測試及分析

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

4.1 測試結果

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

4.2 各測試結果指標分析

①系統響應：在10分鐘內運行虛擬用戶數一直在1000并發中，平均事務響應時間無特別大的波動，系統在此壓力下運行比較穩定。

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

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

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

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

4.3 系統優化

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

5 結 語

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

參考文獻：

[1] 張永祥等.性能測試專家分析系統[J].計算機系統應用，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系統性能測試的設計與實現[J].計算機工程，2009，35（10）：

51-53.