性能測試基礎(chǔ)

1、通過性能測試定位通過性能測試定位ORACLE性能瓶性能瓶頸并優(yōu)化頸并優(yōu)化性能測試基礎(chǔ)性能測試基礎(chǔ)中程在線(北京)科技有限公司內(nèi)部教程注意保密電子支付流程主要介紹內(nèi)容性能測試是什么（性能測試是什么（what）為什么要做性能測試（為什么要做性能測試（why）性能測試什么時候做（性能測試什么時候做（when）性能測試人力資源組成（性能測試人力資源組成（who）性能測試環(huán)境搭建（性能測試環(huán)境搭建（where）性能測試怎么做（性能測試過程）（性能測試怎么做（性能測試過程）（How）性能測試工具簡介性能測試工具簡介性能測試中的關(guān)鍵點性能測試中的關(guān)鍵點性能測試是什么？定義：定義：性能測試是指通過特定方式，對

2、被測系統(tǒng)按照一定策略施加壓力，獲取系統(tǒng)響應(yīng)時間、TPS、吞吐量、資源利用率等性能指標，以期保證生產(chǎn)系統(tǒng)的性能能夠滿足用戶需求的過程。性能測試是什么-性能測試分類 并發(fā)性能測試 負載壓力測試 疲勞強度測試（穩(wěn)定性測試） 高可用性測試（如RAC高可用性） 大數(shù)據(jù)量測試6性能測試是什么-性能測試分類并發(fā)性能測試 通過模擬多個并發(fā)用戶同時進行某個操作，驗證系統(tǒng)是否存在并發(fā)性的問題。如現(xiàn)在比較流行的秒殺、訂票等。 性能測試是什么-性能測試分類 負載壓力測試 負載壓力測試是按照測試模型確定的測試比例，逐步增加系統(tǒng)壓力，獲得系統(tǒng)各項性能指標的變化情況，并獲得系統(tǒng)的最大性能容量。8性能測試是什么-性能測試分類

3、疲勞強度測試 通常是采用系統(tǒng)穩(wěn)定運行情況下能夠支持的最大并發(fā)用戶數(shù)的80%的壓力持續(xù)運行一段時間，驗證系統(tǒng)在一定壓力下長時間穩(wěn)定運行的能力，并檢查是否有內(nèi)存泄露。 性能測試是什么-性能測試分類 高可用性測試 驗證在一定壓力下服務(wù)器集群（如oracle rac）中的某一節(jié)點發(fā)生故障時，另一節(jié)點能自動接收全部的請求。10性能測試是什么-性能測試分類 大數(shù)據(jù)量測試 驗證OLTP系統(tǒng)在大數(shù)據(jù)量的情況下增刪改查的性能； 驗證 OLAP系統(tǒng)在不同數(shù)據(jù)量下的系統(tǒng)處理情況。性能測試是什么不同角度對性能的認識 用戶角度 系統(tǒng)管理員角度 開發(fā)人員角度性能測試是什么不同角度對性能的認識 用戶角度軟件對用戶操作的響應(yīng)

4、時間，如用戶提交一個查詢操作、打開一個web頁面的鏈接等業(yè)務(wù)可用度，或者系統(tǒng)的服務(wù)水平如何？性能測試是什么不同角度對性能的認識 系統(tǒng)管理員角度 并發(fā)壓力 服務(wù)器端資源使用情況 是否存在性能瓶頸 系統(tǒng)可擴展性如何性能測試是什么不同角度對性能的認識 開發(fā)人員角度 架構(gòu)設(shè)計是否合理 數(shù)據(jù)庫設(shè)計是否存在問題 代碼是否需要優(yōu)化，如SQL語句 如何通過調(diào)整設(shè)計和代碼實現(xiàn)，或如何通過調(diào)整系統(tǒng)設(shè)置提高軟件的性能表現(xiàn)性能測試是什么？-性能測試術(shù)語命名用戶數(shù) 命名用戶數(shù)是指在應(yīng)用系統(tǒng)中注冊的所有系統(tǒng)用戶。該用戶數(shù)取決于系統(tǒng)應(yīng)用范圍和業(yè)務(wù)范圍，可以通過統(tǒng)計應(yīng)用系統(tǒng)數(shù)據(jù)庫中用戶登記表獲取。對于類似網(wǎng)站瀏覽式應(yīng)用一般通

5、過類似系統(tǒng)的類比估算獲得。在線用戶數(shù) 在線用戶數(shù)是指同時登錄應(yīng)用系統(tǒng)的用戶數(shù)量該數(shù)量可通過檢查系統(tǒng)應(yīng)用與數(shù)據(jù)庫連接獲得在線用戶數(shù)量取決于系統(tǒng)命名用戶數(shù)。對于已投產(chǎn)系統(tǒng)，該數(shù)量一般通過系統(tǒng)跟蹤監(jiān)控獲取新投產(chǎn)系統(tǒng)通過經(jīng)驗值進行估算。性能測試是什么？ -性能測試術(shù)語并發(fā)用戶數(shù) 并發(fā)用戶數(shù)是指在系統(tǒng)運行期間同一時刻進行業(yè)務(wù)操作的用戶數(shù)量。該用戶取決于用戶操作習(xí)慣、業(yè)務(wù)操作間隔和單筆交易的響應(yīng)時間。在性能測試中通過對Thinktime、interval等參數(shù)的設(shè)置測算。使用頻度較低的應(yīng)用系統(tǒng)并發(fā)用戶數(shù)一般為在線用戶數(shù)的5%左右使用頻度較高的應(yīng)用系統(tǒng)并發(fā)用戶數(shù)一般為在線用戶數(shù)的10%左右。交易 交易分為業(yè)

6、務(wù)層面和技術(shù)層面兩種定義。業(yè)務(wù)層面交易是指完成一次完整的業(yè)務(wù)操作，例如進行一次取款、查詢操作。技術(shù)層面的交易是指進行一次應(yīng)用程序至應(yīng)用程序、或者應(yīng)用程序至數(shù)據(jù)庫的系統(tǒng)操作。一般的一筆業(yè)務(wù)交易由多筆技術(shù)交易組成，根據(jù)業(yè)務(wù)交易的復(fù)雜度和系統(tǒng)應(yīng)用架構(gòu)的不同，其比例大致為1：2-1：10。性能測試是什么？ -性能測試術(shù)語交易處理能力（TPS與HPS） TPS 是估算應(yīng)用系統(tǒng)性能的重要依據(jù)其意義是應(yīng)用系統(tǒng)每秒鐘處理完成的交易數(shù)量。一般的，評價系統(tǒng)性能均以每秒鐘完成的技術(shù)交易的數(shù)量來衡量。系統(tǒng)整體處理能力取決于處理能力最低模塊的TPS 值。依據(jù)經(jīng)驗，應(yīng)用系統(tǒng)的處理能力一般要求在10-100左右。不同應(yīng)用系

7、統(tǒng)的TPS有著十分大的差別，一般需要通過性能測試進行準確估算。HPS：Hits per Second 每秒點擊次數(shù)，是指在一秒鐘的時間內(nèi)用戶對Web頁面的鏈接、提交按鈕等點擊總和它一般和TPS成正比關(guān)系，是B/S系統(tǒng)中非常重要的性能指標之一。交易響應(yīng)時間 交易響應(yīng)時間是指完成一筆業(yè)務(wù)交易所需的時間。傳統(tǒng)上是指統(tǒng)計“端到端”的交易完成時間。簡單交易的響應(yīng)時間一般不得高于5秒，復(fù)雜交易的響應(yīng)時間一般在20秒左右。性能測試是什么？ -性能測試術(shù)語資源使用率 資源使用率是指在系統(tǒng)負載運行期間，數(shù)據(jù)庫服務(wù)器、應(yīng)用服務(wù)器、Web服務(wù)器的CPU、內(nèi)存、硬盤，外置存儲，網(wǎng)絡(luò)帶寬的使用率。據(jù)經(jīng)驗，低于20%的使

8、用率為資源空閑，20%-60%的使用率為資源使用穩(wěn)定，60%-80%的使用率表示資源使用飽和，超過80%使用率的資源使用率必須盡快進行資源調(diào)整和優(yōu)化。批量處理時間 批量處理時間是指應(yīng)用系統(tǒng)完成批量操作所消耗的時間資源批量處理完成時間取決于業(yè)務(wù)接受程度一般的批量處理時間應(yīng)在數(shù)小時內(nèi)完成。其他指標 在性能測試過程中還有大量與軟件產(chǎn)品或者硬件設(shè)備相關(guān)的測算指標這些指標隨著設(shè)備或者軟件的不同有著較大差別隨著性能測試的深入將逐漸積累匯總這些指標。性能測試是什么？ -性能測試術(shù)語響應(yīng)時間：響應(yīng)時間：n響應(yīng)時間指的是從客戶端發(fā)起一個請求開始，到客戶端接收到從服響應(yīng)時間指的是從客戶端發(fā)起一個請求開始，到客戶端

9、接收到從服務(wù)器端返回的響應(yīng)結(jié)束，這個過程所耗費的時間。務(wù)器端返回的響應(yīng)結(jié)束，這個過程所耗費的時間。響應(yīng)時間響應(yīng)時間 = 網(wǎng)絡(luò)響應(yīng)時間網(wǎng)絡(luò)響應(yīng)時間 + 應(yīng)用程序響應(yīng)時間應(yīng)用程序響應(yīng)時間性能測試是什么？ -性能測試術(shù)語吞吐量：吞吐量：為什么要做性能測試？未作性能測試失敗實例為什么要做性能測試？編碼階段：防微杜漸-在編碼階段就進行開發(fā)員級的單元性能測試，盡早發(fā)現(xiàn)性能問題，降低缺陷修復(fù)的成本系統(tǒng)運營維護階段：整體保障-當(dāng)代碼被修改、數(shù)據(jù)庫配置改變、應(yīng)用服務(wù)器配置改變等情況發(fā)生后，不僅需要功能回歸測試，還要進行性能回歸測試，避免由于一個小小的SQL語句缺陷而導(dǎo)致嚴重的系統(tǒng)性能問題性能測試什么時候做？新系

10、統(tǒng)上線新系統(tǒng)上線新系統(tǒng)上線后，全國推廣前新系統(tǒng)上線后，全國推廣前已有系統(tǒng)版本更新后或者已發(fā)現(xiàn)性能問題后已有系統(tǒng)版本更新后或者已發(fā)現(xiàn)性能問題后已有系統(tǒng)硬件更換或者升級后已有系統(tǒng)硬件更換或者升級后*準入評審：準入評審：在性能測試正式啟動之前，需要對兩個方面進行評審被測系統(tǒng)是否符合準入標準實施性能測試的可行性和必要性目的：考察被測系統(tǒng)是否具備性能測試的條件。不符合測試條件的系統(tǒng)會導(dǎo)致測試難以實施，或者測試結(jié)果嚴重失真勉強測試會使測試工作失去意義，浪費大量的時間、人力和軟硬件資源。性能測試人力資源組成？性能測試人力資源組成？限制因素：參與人員雜技術(shù)難度高實施時間緊工作壓力大需要一支層次分明、責(zé)任明確、

11、執(zhí)行力強的隊伍明確規(guī)定各角色人員的工作職責(zé)定期召開工作分析和工作總結(jié)會，確認階段工作結(jié)果建立協(xié)調(diào)上級領(lǐng)導(dǎo)進行決策的機制建立協(xié)調(diào)上級領(lǐng)導(dǎo)進行強制執(zhí)行的機制建立測試組工作時間共享的機制建立項目組工作過程文檔/結(jié)果共享的機制性能測試環(huán)境搭建，包括被測應(yīng)用系統(tǒng)、壓力發(fā)生系統(tǒng)、監(jiān)控系統(tǒng)、網(wǎng)絡(luò)系統(tǒng)的配置，根據(jù)業(yè)務(wù)模型確定典型交易列表和場景。對于無法采用壓力發(fā)生工具直接發(fā)起交易的性能測試，要設(shè)計開發(fā)壓力傳遞系統(tǒng)，將交易壓力正確、有效地加載至被測系統(tǒng)，包括測試腳本的開發(fā)，包括基礎(chǔ)數(shù)據(jù)的獲得、數(shù)據(jù)量評估和基礎(chǔ)數(shù)據(jù)改造。，根據(jù)腳本參數(shù)化字段，從基礎(chǔ)數(shù)據(jù)中抽取有效的、正確的交易發(fā)起數(shù)據(jù)。包括獲得抽取規(guī)則、抽取執(zhí)行和

12、數(shù)據(jù)驗證，保證所有數(shù)據(jù)可以通過腳本正確執(zhí)行。，保證參數(shù)化的測試腳本與基礎(chǔ)數(shù)據(jù)結(jié)合能夠在測試執(zhí)行環(huán)境下正確運行。對于測試方案中確定需要通過時間戳系統(tǒng)記錄交易在某個交易路徑上的相應(yīng)時間的情況，需要開發(fā)針對性的時間戳程序和相應(yīng)的時間戳日志分析程序。包括擋板程序的設(shè)計、開發(fā)、部署和調(diào)試。另一方面，需要為擋板準備返回報文 性能測試環(huán)境搭建被測應(yīng)用的主機和應(yīng)用環(huán)境的申請、部署壓力發(fā)生環(huán)境準備網(wǎng)絡(luò)環(huán)境申請和部署監(jiān)控系統(tǒng)準備測試人員辦公網(wǎng)絡(luò)環(huán)境性能測試怎么做？規(guī)劃階段：測試時間、測試目標、測試組織建模階段：收集數(shù)據(jù)、性能指標、測試范圍預(yù)驗證階段： 風(fēng)險評估、技術(shù)驗證準備階段：測試環(huán)境、測試數(shù)據(jù)、測試腳本、測試

13、程序執(zhí)行階段：響應(yīng)時間基準測試、負載測試、壓力測試、容量測試、Benchmark測試、穩(wěn)定性測試調(diào)優(yōu)階段：收集/分析測試結(jié)果數(shù)據(jù)、性能調(diào)優(yōu)報告階段：測試成果確認、測試目標完成確認、收集測試環(huán)境最終配置信息、測試報告編制性能測試怎么做？性能測試中的關(guān)鍵點獲取測試需求獲取測試需求確定測試目標確定測試目標進行業(yè)務(wù)調(diào)研進行業(yè)務(wù)調(diào)研建立測試模型建立測試模型測試模型數(shù)據(jù)模型業(yè)務(wù)模型監(jiān)控模型風(fēng)險模型執(zhí)行模型性能測試中的關(guān)鍵點性能測試中的關(guān)鍵點性能測試中的關(guān)鍵點性能測試中的關(guān)鍵點性能測試中的關(guān)鍵點按按8月份交月份交易量統(tǒng)計：易量統(tǒng)計：業(yè)務(wù)總交易量7697540.5券商=6571752.3，525476.2，6

14、00312券商：銀行5.84：1券商=6571752.3，銀行=1125788.21.13：16.83%，7.8% 業(yè)務(wù)模型：業(yè)務(wù)模型：測試模型：測試模型：（8組模型）組模型）模型比例模型比例1 1：券商端：查詢:轉(zhuǎn)帳1:4；轉(zhuǎn)入:轉(zhuǎn)出1:1; A股：B股=9：1； 高 (8月生產(chǎn)數(shù)據(jù)模型)模型比例模型比例2 2：券商端：查詢:轉(zhuǎn)帳1:3；轉(zhuǎn)入:轉(zhuǎn)出1:1; A股：B股=9：1； 高 （6月生產(chǎn)數(shù)據(jù)模型）性能測試中的關(guān)鍵點 新開發(fā)系統(tǒng)性能測試需求分析（1）標識需求規(guī)格中的性能指標（2）將需求規(guī)則中的業(yè)務(wù)需求轉(zhuǎn)化為性能測試需求（3）分析系統(tǒng)的技術(shù)架構(gòu)及特點（4）分析系統(tǒng)的數(shù)據(jù)規(guī)模及數(shù)據(jù)增長速度（

15、5）確定系統(tǒng)的測試目的及測試范圍（6）分析應(yīng)用系統(tǒng)中待測交易的業(yè)務(wù)規(guī)則（7）分析應(yīng)用系統(tǒng)中待測交易的業(yè)務(wù)流程（8）根據(jù)待測交易的業(yè)務(wù)占比設(shè)計業(yè)務(wù)模型（9）根據(jù)業(yè)務(wù)模型設(shè)計測試模型性能測試中的關(guān)鍵點 已投產(chǎn)系統(tǒng)性能測試需求分析（1）收集生產(chǎn)運維日志或性能故障發(fā)生時的相關(guān)數(shù)據(jù)（2）分析生產(chǎn)環(huán)境的部署關(guān)系圖（3）分析連續(xù)多天的生產(chǎn)運維日志（4）確定高峰日期高峰時段的交易量（5）分析需求和設(shè)計文檔（6）根據(jù)生產(chǎn)統(tǒng)計信息設(shè)計待測交易的業(yè)務(wù)模型（7）根據(jù)業(yè)務(wù)模型設(shè)計測試模型性能測試中的關(guān)鍵點 真實宕機事故分析 *銀行柜面交易系統(tǒng)在某天突然發(fā)生宕機，造成營業(yè)中斷近30多分鐘，為了不影響交易，系統(tǒng)運維人員收集

16、了相關(guān)日志、CORE DUMP等資料后重啟應(yīng)用系統(tǒng)。 分析思路 首先分析應(yīng)用系統(tǒng)日志、中間件日志、數(shù)據(jù)庫日志； 其次分析系統(tǒng)CORE DUMP文件； 第三在測試環(huán)境中復(fù)現(xiàn)問題。對CORE文件的初步分析結(jié)果一、事件時序重組：15:24:46 15:38:52 POSB coredump開始 POSB coredump結(jié)束 | |- | | | | 15:24:55 15:27:07 15:41:52 15:47:31 系統(tǒng)資源異常 checkpoint開始 checkpoint結(jié)束 系統(tǒng)資源恢復(fù) 從上圖可以看出，core dump的時間、checkpoint的時間存在一定重疊，系統(tǒng)資源異常的情況

17、則持續(xù)時間較長。二、事件待查疑點：1、core dump的時間為何持續(xù)了14分鐘？在測試環(huán)境（通過壓力測試工具模擬了生產(chǎn)環(huán)境正常交易壓力）多次模擬觸發(fā)了POSB switch及其他進程的coredump場景，發(fā)現(xiàn)coredump文件的生成時間都非?？?，在毫秒級完成。同時，我們看到生產(chǎn)環(huán)境的core文件只有36K，理論上這么小的core文件dump到硬盤上不可能耗時14分鐘之久。（日志來源：Daemon.log）對CORE文件的初步分析結(jié)果2、是否由coredump操作引起系統(tǒng)資源異常？從事件時序可以看出，core產(chǎn)生時間和系統(tǒng)資源異?；就瑫r發(fā)生，但由于sar -q命令看到的系統(tǒng)資源異常由于是

18、幾秒鐘采樣一次，比core產(chǎn)生的時間晚個幾秒不能說明一定是由core dump引起。同時，core dump及checkpoint都結(jié)束之后，系統(tǒng)資源仍在6分鐘之后才全面恢復(fù)，建議系統(tǒng)專家進一步分析這一段時間操作系統(tǒng)有何操作？在測試環(huán)境多次測試也發(fā)現(xiàn)，core dump時間瞬時完成，系統(tǒng)資源采樣沒有監(jiān)控到系統(tǒng)資源的異常。三、初步結(jié)論通過日志及對core文件的分析，可以確定的信息是：1、core文件是由于informix問題引起；2、informix的checkponit時間長是由于swap區(qū)耗盡引起；3、swap區(qū)的故障時間比core和checkpoint都要長；初步推斷，由于informix

19、數(shù)據(jù)庫的BUG及swap區(qū)異常（可能也是由于數(shù)據(jù)庫bug導(dǎo)致），導(dǎo)致了posb core，以及導(dǎo)致了core dump和checkpoint的時間過長。性能測試中的關(guān)鍵點月份業(yè)務(wù)量1 122043220432 222123221233 322143221434 422122221225 520342203426 619873198737 716543165438 837643376439 92983229832101024212242121111209822098212122109821098業(yè)務(wù)調(diào)研例：年業(yè)務(wù)量調(diào)研業(yè)務(wù)調(diào)研例：年業(yè)務(wù)量調(diào)研性能測試中的關(guān)鍵點業(yè)務(wù)調(diào)研例：月業(yè)務(wù)量調(diào)研業(yè)務(wù)調(diào)研例：

20、月業(yè)務(wù)量調(diào)研日期業(yè)務(wù)量日期業(yè)務(wù)量1 1112111211717134513452 2103710371818167816783 3102310231919178617864 49879872020154315435 5154315432121123112316 6102210222222109410947 71267126723239879878 81098109824248998999 91376137625251022102210101675167526261034103411111324132427271213121312121099109928281112111213131256125

21、6292913451345141410981098303012741274151510211021313110121012161611211121性能測試中的關(guān)鍵點業(yè)務(wù)調(diào)研例：日業(yè)務(wù)量調(diào)研業(yè)務(wù)調(diào)研例：日業(yè)務(wù)量調(diào)研時間時間交易量交易量0 05 51 11 12 20 03 30 04 40 05 52 26 623237 743438 864649 997971010212212111132432412122432431313211211141416716715151431431616122122171790901818111119197 720209 921215 522223 323234

22、4業(yè)務(wù)名稱自定義搜索自定義搜索分類搜索分類搜索新建帳戶新建帳戶新建訂單新建訂單更新訂單更新訂單業(yè)務(wù)量122122101101202072729 9業(yè)務(wù)配比37.65%37.65%31.17%31.17%6.17%6.17%22.22%22.22%2.78%2.78%性能測試中的關(guān)鍵點 性能測試方案 性能測試方案是指導(dǎo)性能測試的綱領(lǐng)，在性能測試方案中應(yīng)該對測試目的、測試范圍、測試需求、測試策略等進行說明。性能測試中的關(guān)鍵點方案設(shè)計性能測試中的關(guān)鍵點 性能測試案例 性能測試案例是指導(dǎo)測試實施的具體說明，在性能測試案例中應(yīng)該對測試場景、加壓方式、具體步驟、測試數(shù)據(jù)、預(yù)期結(jié)果等進行說明。 真實測試案例分析性能測試中的關(guān)鍵點案例設(shè)計規(guī)范性能測試中的關(guān)鍵點腳本開發(fā)腳本開發(fā)腳本增強腳本增強腳本腳本開發(fā)指南開發(fā)指南AB腳本腳本/數(shù)據(jù)驗證數(shù)據(jù)驗證D腳本調(diào)試腳本調(diào)試Cl 編寫方式編寫方式l 錄制方式錄制方式l 事務(wù)事務(wù)l 檢查點檢查點l 參數(shù)化參數(shù)化l 關(guān)聯(lián)關(guān)聯(lián)l 集合點集合點l 注釋注釋l Run Time Settingl 設(shè)置斷點與設(shè)置斷點與單步調(diào)試單步調(diào)試l 增加增加Logl 應(yīng)用系統(tǒng)日應(yīng)用系統(tǒng)日志志l 常見錯誤常見錯誤l 驗證函數(shù)驗證函數(shù)