金融軟件系統的實時性、健壯性、穩定性等較一般系統軟件要高，應有效地實施性能測試，保障執行策略的制定、業務模型的建立、測試指標的選取。

一、性能測試的執行策略和方法
對于聯機類系統通常有多種測試類型(負載測試、容量測試等)，性能測試在實施前可根據測試目的，選取如下多個測試類型的組合，來制定相應的實施策略。
1．基準測試
系統在無并發壓力情況下，驗證單個功能點的性能表現，其響應時間可作為基準值，為后續場景測試提供分析參考。
測試方法：在系統無并發壓力情況下運行，單個用戶單個功能點，通過多次運行取響應時間的平均值，主要關注交易響應時間。
2．單場景測試
在一定并發壓力下，驗證單個功能點的性能表現。一般在混合場景前執行，可較早發現問題。
測試方法：使用LoadRunner工具向系統發送業務請求并接收返回結果的腳本，使用逐層遞增的并發壓力或者恒定的并發壓力進行測試，獲取單功能點并發時的性能表現。
3．負載測試
在可能發生的業務模型下，驗證系統是否滿足預期的性能指標。需要說明的是，預期的性能指標不一定達到系統的最大負載。
測試方法：針對業務模型中確定的系統主要功能點，在特定并發壓力下(通常為需求規劃值)，驗證系統是否滿足性能指標。此指標一般體現為響應時間、并發用戶數、系統處理能力、資源使用率等。主要關注性能指標在特定并發壓力下是否均達到預期要求。
4．容量測試
容量測試目的是在系統沒有出現任何軟件故障或主要功能仍可正常運行的狀態下，獲取系統的最大承載、服務能力以及系統性能表現。
測試方法：使用一定的并發壓力，通過逐步遞增并發壓力，找到系統性能拐點，獲取系統最大的并發用戶數。主要綜合關注響應時間、并發用戶數、系統處理能力、資源使用率等。
5．健壯性測試
為了驗證在異常狀態下，系統是否能夠在出現故障的情況下仍能保持繼續運行的能力。根據系統可能發生為異常狀態，設計該異常狀態場景，在可能發生的業務模型下，關注系統是否能夠繼續運行以及其性能表現。
測試方法：負載均衡或雙機熱備時，將其中一臺應用服務器宕機，在負載壓力保持不變的情況下，觀察整個系統的性能表現以及其他相關服務器的資源使用情況；主機承受了壓力無法正常工作后，驗證備份機是否能夠快速地接管負載；部分外圍系統異常，觀察應用系統能否繼續承壓運行以及與其他正常外圍系統進行交互。
6．浪涌測試
高峰和日常壓力交替多次出現的系統適用，考察系統的可靠性，驗證系統在壓力多次出現的情況下，是否存在異常情況。確定從高負載(例如系統高峰時間的負載)恢復，轉為幾乎空閑，然后再攀升到高負載，再降低的能力。
測試方法：針對高峰及日常壓力涉及的主要功能點及交易，通過增加和減少并發用戶數的方式，模擬壓力如浪潮一般上下，每輪先增加到高峰壓力，保持運行一段時間(如1小時)后減小至日常壓力，再保持運行一段時間(如1小時)，然后再反復重復這個過程。在壓力循環疊加的情況下，驗證系統是否存在業務積壓并無法處理以及宕機等異常情況、第二次高峰是否重現第一次的峰值、其后的每次高峰是等于還是大于第一次的峰值、是否顯示了內存或GC性能降低跡象等。
7．恢復性測試
適用于大多數聯機類系統，驗證系統能否快速地從錯誤狀態中恢復到正常狀態。
測試方法：增加壓力，模擬業務量突然增長情況使系統處于過載情況，主要表現為交易的失敗率陡增，系統無法正常處理，然后減少壓力至日常大小，查看系統是否能快速恢復正常處理，關注壓力減小后交易成功率、系統處理能力、資源使用率等指標是否恢復正常。壓力增大和減小可通過并發用戶數調節。
8．配置測試
主要是獲取應用平臺的最佳參數配置及其排列組合。
測試方法：在壓力相同的情況下，改變應用平臺的關鍵性能參數及其組合情況，查看系統性能變化情況，獲取系統的最佳配置。
9．穩定性測試
在一定壓力負載下，驗證系統是否可長時間穩定運行，特別關注系統資源使用情況是否平穩以及是否存在內存泄漏等異常問題。
測試方法：在可能發生的業務模型下，使用一定的并發壓力，可參考業務發生的日常壓力或者預期的負載，對于無生產業務量參考的系統，可參考容量測試結果選取(一般選取容量測試最大系統處理能力的75％對應的并發壓力)。
穩定性測試需運行較長時間，通常場景執行時間為24小時，如需適當縮短或延長執行時間，需要提供理由說明，建議最短不低于12小時。主要關注平均響應時間、系統處理能力、資源利用率、交易成功率等各項指標變化是否平穩，是否存在內存泄漏等問題。

二、性能測試業務模型的建模策略和規劃
本文所指的業務模型是指用于合理地模擬生產上真實的業務發生場景，通過不同建模策略和建模規則，得到的一組或多組交易或功能點的集合及其占比。
1．建模策略
業務模型建立之前，首先要確定需要實施的業務場景。兩種常用場景為日常業務場景和高峰業務場景。此外還有異常峰值場景。
日常業務場景是指在正常工作時間內，用戶訪問較平緩時的業務場景。高峰業務場景是指在高峰業務時間內，交易量較大或者用戶訪問集中時的業務場景。異常峰值場景是指在一段較短時間內，交易量爆炸式增長或者用戶密集式訪問系統時的業務場景。
對于日常業務場景、高峰業務場景、異常峰值場景，三者的主要差距在于用來進行交易選取的時間段的不同。日常業務場景通常會選取平常日或小時的數據；高峰業務場景會選取高峰日、小時、分鐘或者特殊日、小時、分鐘的數據；而異常峰值場景往往會選取異常產生的時間點的數據。
接近實際生產運行的業務模型須建立在合理有效的數據來源基礎上。系統的運行數據往往是業務模型分析最有效的參考依據，但有些待測系統因各種原因不能提供有效的實際運行數據，如未投產的新系統。故以下從運行數據分析、類似系統數據分析和規劃數據分析三種情況來描述數據分析的過程。
(1)運行數據分析
一般從系統生產環境提取運行數據，均為一個大時間段內數據。為了獲取業務模型，需細化分析該大時間段內的交易量、交易發生時間以及變化率等。數據分析具體步驟如下。
①根據測試的具體目標選定用于數據分析的時間段，如季度、月、周等。
②根據選定時段內交易量變化趨勢或者運行情況，選定平常日、交易高峰日或者特殊日。特殊日為月末日、年末日、節假日等。
③對于選定的平常日、高峰日或特殊日，按實際需求評估細化至時、分為單位，得到該細化時段內的交易及其交易量。對于異常情況，一般直接定位到具體的時間點進行分析。
圖1為某系統高峰日的交易情況統計圖，其中l5：00～17：00交易量約為50 000左右，若以小時為單位進行建模，則可選取當日交易高峰時段15：00～17：00作為分析基準。

(2)類似系統數據分析
在沒有投產運行數據情況下，可以優先參考功能相似系統的運行情況，數據分析方法同上。同時，獲取的業務模型，須兼顧待測系統功能點的變化，根據實際情況對功能點進行合理的拆分、合并以及數量調整。
(3)規劃數據分析
對于沒有任何數據可參考的系統來說，需會同項目組與業務部門一同分析未來生產上可能出現的業務場景，獲取業務模型。一般在前期系統技術方案中，會明確系統須支撐的相關交易及其交易量。
2．建模規則
通過前期數據分析，可得到某個時間段內的交易及其交易量，作為備選集合供后續進一步的篩選。這些交勇往往數量繁多。因此，基于測試目的和效率等方面的考慮，在業務模型的建立時，通常需要遵循四大規則：TOP規則、特殊交易規則、內外部系統覆蓋規則和等價類規則。一次建模過程可以同時使用一個或多個規則，從而能更準確地獲取業務模型。
例如：通過對某系統2010年5月1日到2010年5月31日共31天的交易數據進行匯總分析，統計每日交易筆數，找出31天中日最高交易筆數數據。再對日最高交易筆數數據進行具體的分析，確定各交易筆數以及所占的比例，按照一定規則進行取舍，以此確定業務模型。
(1)TOP規則
TOP規則要求在備選集合中，選取占交易總量較大的交易納入業務模型。通常會采取以下步驟進行實施。
①對所有的交易進行占比分析。
②按占比從高到低，進行累加。
③將占比累加值不小于選取閾值的交易，納入業務模型范圍。該閾值通常為90％或以上，可根據具體項目情況設定。
如圖2所示，為一個交易選取閾值設定為90％的業務模型分析過程。最終占比累加值大于了90％的交易B、C、A、D被選入業務模型。

(2)特殊交易或功能點規則
特殊交易或功能點規則要求在備選集合中，選取那些投產運行后可能對系統有潛在性能風險的交易納入業務模型。這類交易主要的特點有以下幾方面。
①交易的系統實現邏輯復雜。
②與其他交易采用不同的實現機制，如不同中間件、通信協議等。
③生產上出現過性能問題的交易。
④對本模塊、其他關聯模塊或外圍系統等有潛在性能風險的新增交易。
(3)內外部系統覆蓋原則
內外部系統覆蓋原則要求在待測系統存在內部子系統或者相關聯的外圍系統情況下，在備選集合中選取交易時，原則上須覆蓋到該系統的眾多子系統或相關外圍系統。
如圖3所示，某系統受到來自“網銀”、“柜面”、“電話銀行"等不同外圍系統的壓力。因此，盡管“網銀”與“柜面”類交易已占到所有交易的90％，“電話銀行"類交易占比較小，但是為了全面考查三個外圍系統對待測系統的性能影響，“電話銀行"類交易也必須選擇部分重要交易納入測試。

(4)等價類規則
 等價類規則是指建立業務模型時，可根據測試目的，適當地將技術實現相同的交易進行合并，在對服務器端造成同等壓力的前提下，減少業務模型復雜度。
如圖4所示，為一個等價類原則的應用圖。對于部分查詢交易，系統采用了三種技術進行實現。因此在交易選取時，可對同樣采用實現技術2的交易A、C進行合并，僅選擇交易A并根據A和C的交易總量重新計算占比。

三、性能測試指標的確定
性能指標是用來度量系統各項運行能力的數值指標。常用的性能測試指標包括：系統處理能力、響應時間、相對并發用戶數、絕對并發用戶數、成功率和資源利用率等。金融軟件系統的聯機性能指標包括但不限于上述度量指標，根據系統特點及不同類型的性能測試，其指標可調整。
1．系統處理能力
從業務指標角度來說，系統處理能力是指系統每秒鐘處理完成的業務交易筆數，即TPS(Transaction Per Second)。
從系統角度來說，需詳細考慮每筆業務對后臺服務器的請求次數，從而將每筆業務交易轉化為系統請求數，因此，在這個角度上，系統處理能力可以定義為系統每秒鐘處理完成的請求數量，即CPS(Call Per Second)。TPS更為業務人員所理解，而CPS更能考察出系統真實的處理能力。在實際分析系統處理能力需求的時候，需要根據項目組關注點的不同，采用不同指標進行衡量。
2．響應時間
通常，響應時間是指從客戶端發起業務請求，到得到響應的整個過程所經歷的時間。系統響應時間，是指從前端發出請求，到系統處理完畢返回給前端處理結果的時間，僅包含了服務器處理以及網絡通信所消耗的時問。用戶響應時間，除了包含系統響應時間外，還需要考慮前端呈現時間(前端響應時間)和用戶操作時間。
性能測試主要考查服務器的性能表現，故一般采用系統響應時間作為衡量指標，以LoadRunner為壓測工具，系統響應時間是指從LoadRunner執行機發出請求，到獲得響應之間的時間差。如需求方提供的指標值為用戶響應時間，則須進一步分析得到系統響應時間。在某些特殊情況下，如需考查前端性能表現時，可考慮采用用戶響應時間。
對于系統響應時間，通常采用交易平均響應時間、90％交易響應時間、最大和最小響應時間等指標衡量系統性能。
(1)平均響應時間：在單位時間內，某交易運行得到響應時間結果的平均值。
(2)最大、最小響應時間：在單位時間內，某交易所有響應時間的最大和最小值。
(3)90％交易響應時間：在單位時間內，某交易運行多次，將該交易的所有響應時間結果按升序排列，前90％響應時間結果都小于的值，即為90％交易響應時間。
3．在線用戶數
在線用戶數是指同一時間段內訪問系統的用戶數量。這些用戶在同一時間段內已登錄或者已訪問系統，但是不一定每時每刻都在進行操作。如果使用在線用戶敦進行并發測試，需要考慮增加模擬用戶思考的等待時間(即迭代時間)，來進行測試。
估算方法：一段時間內訪問用戶總數×session保持時間(分鐘)／該時間段(分鐘)
4．并發用戶數
并發用戶數是指在同一時刻與服務器進行了交互的并發用戶數量。這些用戶的最大特征是和服務器產生了交互，這種交互既可以是單向的傳輸數據，也可以是雙向的傳送數據。并發用戶數是從服務器端承受的壓力來考慮的，越多的用戶同時使用系統，系統承受的壓力越大。
在性能測試中，如采用并發用戶數進行測試，那么這些用戶操作間將不加間隔時間。對于并發用戶數，可以采用平均值(平均并發用戶數)和峰值(峰值并發用戶數)進行計算。一般均采用平均值進行測試。在浪涌測試中，峰值并發用戶數可被用于做峰值點的壓力。
在估算并發用戶數時，首先須確認用于分析的時間段(一般與業務模型估算時間段一致)，然后在該時間段的實際生產數據或者規劃數據的基準上進一步地估算。
5．成功率
成功率是指交易成功的數量占發出交易總量的百分比。性能測試一般只采用正案例對系統進行施壓，因此測試過程中產生的錯誤交易絕大多數是由于系統無法承受壓力而導致的。實時類要求性高的系統通常將成功率不低于99．9％作為衡量指標。
6．資源利用率
資源利用率用來衡量各服務器或者外設的系統資源占用情況。主要的監控項有CPU、內存、磁盤IO、剩余空間容量、網絡帶寬等。一般CPU使用率采用75％～80％，內存使用率采用80％～90％作為衡量指標。
HP小型機下，內存使用率關注sys以及usr之和。IBM小型機下，內存使用率關注計算內存(comp)。windows下，內存使用率關注剩余內存量，使用TotalAvailable Memory計算得到。Linux下，關注buffer、cache、free，綜合考慮應用內存使用模式，酌情去除buffer或cache。