軟件性能測試原理及性能測試實例分析

軟件性能測試原理及性能測試實例分析

【摘要】 在大型軟件系統投入生產之前進行性能測試已經成為趨勢，本文結合一個性能測試案例對性能測試的過程和原理進行了介紹。

【關鍵字】 性能測試　　并發測試　　負載測試

• 軟件測試中的性能測試

軟件測試是保證軟件質量的重要手段，也是軟件過程中一個必不可少的環節。而性能測試則隸屬于軟件測試中的系統級測試，它對軟件在集成系統中運行的性能行為進行測試，旨在及早確定和消除軟件中與構架有關的性能瓶頸。

• 性能測試的含義

目前對性能測試沒有明確的定義，一般地，它主要是針對系統的性能指標制定性能測試方案，執行測試用例，得出測試結果來驗證系統的性能指標是否滿足既定值。性能指標里可能包括系統各個方面的能力，如系統并發處理能力，批量業務處理能力等。

• 性能測試的分解

在性能測試的執行中，可以根據具體的性能指標，分解為幾種測試，根據其關系，可以在不同的時間和空間內執行。這些子測試通常包括以下幾種：

并發測試：驗證系統的并發處理能力。一般是和服務器端建立大量的并發連接，通過客戶端的響應時間和服務器端的性能監測情況來判斷系統是否達到了既定的并發能力指標。

負載測試：驗證系統的負載工作能力。系統配置不變的條件下，在一定時間內，服務器端在高負載情況下的性能行為表現。這里的負載可以是用戶數，交易數，事務數等。

配置測試：核實在操作條件保持不變的情況下，系統在使用不同配置時其性能行為的可接受性。

健壯性測試：核實被測系統的性能行為在異�；驑O端條件之下的可接受性。這里的異�；驑O端條件指的是資源過少，用戶數過多，突發故障等。

隨著軟件系統的規模日益龐大，結構日趨復雜，對軟件系統的性能測試已經成為必須和趨勢。尤其大型的分布式軟件系統更要在正式運行前進行性能測試，因為這樣的系統在投入生產之后，往往要接受大批量的業務量，這對應用程序本身，操作系統, 中心數據庫服務器，中間件服務器，網絡設備的承受力都是一個嚴峻的考驗。在其中任意一個環節出現的問題都可能給用戶帶來巨大的商業損失。預見軟件系統的并發承受能力以避免商業風險，這是在軟件測試階段就應該解決的。例如中國人民銀行的現代化支付系統和上海外匯交易中心的本幣交易系統都在投入生產之前進行了多輪的第三方性能測試，起到了很好的作用。

下面我就介紹一個性能測試案例。

• 一個性能測試實例

• 被測系統

1)被測系統介紹

本系統應我國金融信息化發展設計，采用當今比較先進和流行的技術，是運行在城域網上的大型分布式應用系統。

本系統遵循J2EE規范，采用B/S體系結構進行設計和開發。業務主要分為交易業務和查詢業務，查詢業務采用J2EE規范，交易業務以J2EE體系架構為基礎，進行進一步的處理，采用了TCP的四層結構。系統體系結構圖如下：

圖表 1被測系統體系結構設計圖

• 表示層：　

運行在終端上。運行java applet程序，提供協議控制和用戶界面，與系統最終用戶實現直接交互，通過TCP/HTTP與前置系統通訊。向前置系統發送請求報文，并接收前置系統返回的回應報文。

• 商業邏輯層：

作為中間層實現核心業務邏輯服務。

交易應用服務：運行在交易主機上。在tuxedo中間件上運行業務處理程序，按交易規則處理前置機發來的交易指令，通過tuxedo jolt與前置機連接，通過DB2 C API與數據庫連接。

交易前置服務和查詢前置服務：運行在前置機上。交易前置服務運行服務程序接收終端請求報文并通過tuxedo jolt客戶端將其轉發給交易主機，再通過輪詢和同步反饋接收交易主機返回的報文，將其轉發給業務終端；查詢前置服務運行在weblogic應用服務器上并調用Jreport組件，通過JDBC完成對查詢流指令的發送并接受數據庫返回的結果給業務終端。

• 數據層：

運行在數據庫主機上。負責整個系統中數據信息的存儲、訪問及其優化。運行DB2數據庫服務程序。通過DB2 C API與交易主機通訊，JDBC與查詢前置服務通訊。

數據庫主機和交易主機運行在交易中心城市，前置機運行在各個分中心城市，終端是各個城市參加交易的單位，整個系統覆蓋城域網。

2) 被測系統的性能要求和性能指標

金融系統是業務處理十分頻繁、數據交換吞吐量很大的系統，業務處理的速度直接關系到公司的經濟效益和客戶對公司的評價。在客觀的條件下，整個廣域網系統必須在大業務量的情況下同時保持快速的實時響應能力，以保證整個業務系統的暢通運行。用戶對此提出如下性能指標：

表格1用戶要求性能指標表

下面我們會根據此系統和給定的性能指標來進行性能測試：

• 對被測系統進行性能測試

性能測試的目的是最大程度大模擬真實業務場景，來驗證系統的性能指標，并發現可能存在的性能瓶頸。

1）對被測系統進行系統分析

我們可以看到本系統大體上有終端、前置機、交易主機、數據庫主機節點組成。

在整個業務流程中，業務終端—>前置機—>交易主機—>數據庫主機形成了一個壓力串，每個節點在壓力下能夠正常工作是整個系統正常運轉的基礎。也就是說，如果其中任意一個節點在業務壓力下發生了擁塞、處理不力等不正常情況，那整個系統都無法正常運轉。

我們來看一下業務流程。

首先，從終端到前置機，終端產生業務報文發送至前置機，前置機上運行查詢前置服務和交易前置服務，查詢前置服務向下通過HTTP協議以WEB服務形式和終端連接，向上通過JDBC直接與數據庫系統相連。交易前置服務向下通過基于TCP協議的Socket連接和終端通訊，向上通過tuxedo jolt客戶端和交易應用服務連接。交易應用服務器進行業務邏輯計算，并操作數據庫系統。

由以上分析，我們可以整理出整個系統的兩條壓力流程線來，之所以我們把其分為兩條流程線，是因為交易前置服務和查詢前置服務的工作原理完全不同，下與終端的鏈接，上與交易主機的鏈接也完全是獨立的兩個通路。

終端→交易前置機→交易主機→數據庫系統

終端→查詢前置機→數據庫系統

下面我們先獨立分析兩條流程線，之后我們將再次綜合分析，以考慮二者之間的相互影響作用。

第一條路線上主要運行的是登陸指令和交易指令信息。

當系統運作時，多個交易終端與交易前置服務建立socket連接，完成登陸，之后發送交易指令，造成對交易前置服務的壓力。交易前置服務通過運行服務程序接收到交易指令，并檢驗其合法性，然后通過交易中間件tuxedo的客戶端把業務的壓力傳遞給交易主機進行處理。交易主機進行必要的金融計算和業務邏輯運行，得出反饋結果，生成消息，一方面順原路返回到各個終端上去，一方面記錄入數據庫。

在本條流程線上的加壓主要考驗交易前置服務程序的socket多連接建立能力，tuxedo交易中間件的即時響應能力，交易主機的計算能力，以及DB2數據庫的DML語句加鎖機制。

文章來源于領測軟件測試網 http://www.kjueaiud.com/

TAG: 軟件 實例 性能測試 原理