@import url(http://www.aygfsteel.com/CuteSoft_Client/CuteEditor/Load.ashx?type=style&file=SyntaxHighlighter.css);@import url(/css/cuteeditor.css);

　1引言

　　互聯(lián)網(wǎng)和電子商務(wù)技術(shù)的發(fā)展，人們可以足不出戶完成在線購物、實(shí)時(shí)通訊、信息檢索等操作，這些系統(tǒng)大部分是B/S架構(gòu)。對(duì)于系統(tǒng)本身而言，其性能直接決定了可容納的在線用戶數(shù)和用戶體驗(yàn)滿意度，而用戶數(shù)的攀升意味著廣告等收入增長，所以性能測試在B/S系統(tǒng)中起到了一個(gè)非常關(guān)鍵的作用，尤其是面向公眾的互聯(lián)網(wǎng)系統(tǒng)。

　　2什么是性能測試

　　性能測試是通過自動(dòng)化的測試工具模擬多種正常、峰值以及異常負(fù)載條件來對(duì)系統(tǒng)的各項(xiàng)性能指標(biāo)進(jìn)行測試，包括負(fù)載測試，強(qiáng)度測試，批量測試等類型。在性能測試過程中，會(huì)發(fā)現(xiàn)很多系統(tǒng)潛在的問題，這些問題往往與一定規(guī)模的訪問量有關(guān)，所以無法通過簡單手工測試發(fā)現(xiàn)。借助于測試工具或者自己編寫的腳本，模擬實(shí)際場景對(duì)目標(biāo)系統(tǒng)進(jìn)行全方位性能測試，能夠?qū)栴}暴露在上線之前，減少后期維護(hù)成本。

　　3性能測試階段劃分

　　性能測試整個(gè)過程大體可以劃分為測試規(guī)劃、測試執(zhí)行和結(jié)果分析。本文引入一個(gè)測試模型用于實(shí)例講解，相關(guān)信息見下表1：

　　表1 測試模型

　　模型系統(tǒng)名稱 網(wǎng)上購物系統(tǒng)

　　模型系統(tǒng)架構(gòu) 基于MVC三層架構(gòu)的B/S系統(tǒng)

　　模型系統(tǒng)功能 商品瀏覽：用戶隨意進(jìn)入網(wǎng)站進(jìn)行商品瀏覽。

　　訂單提交：注冊(cè)用戶登錄后，下訂單購買商品，系統(tǒng)返回成功與否。

　　后臺(tái)處理：數(shù)據(jù)庫每天晚上11點(diǎn)自動(dòng)執(zhí)行數(shù)據(jù)庫腳本，清算當(dāng)日的交易數(shù)據(jù)。

　　4性能測試規(guī)劃

　　測試規(guī)劃是整個(gè)性能測試最復(fù)雜，也最有價(jià)值的一部分。測試規(guī)劃包括：確認(rèn)測試目標(biāo)、整理業(yè)務(wù)流程、制定量化指標(biāo)、制定測試用例與場景、準(zhǔn)備測試資源、安排測試計(jì)劃。

　　4.1確認(rèn)測試目標(biāo)

　　針對(duì)不同被測系統(tǒng)，需首先明確本次測試的目標(biāo)。比如設(shè)定為“檢驗(yàn)當(dāng)前系統(tǒng)各業(yè)務(wù)功能的并發(fā)處理能力”，由于系統(tǒng)參與人員的職責(zé)不同，對(duì)性能測試的目標(biāo)定位也不相同，需綜合實(shí)際情況來確定。在本文測試模型中，假定有產(chǎn)品經(jīng)理和技術(shù)經(jīng)理兩個(gè)角色，他們對(duì)于性能測試目標(biāo)簡要?dú)w納為表2所述，綜合兩者就能確認(rèn)本次測試目標(biāo)。

　　表2 測試目標(biāo)

　　職責(zé) 測試目標(biāo)

　　產(chǎn)品經(jīng)理 檢驗(yàn)系統(tǒng)能夠支撐的最大用戶訪問量、最佳用戶訪問量、每秒鐘最大事務(wù)處理數(shù)、是否能夠滿足預(yù)期業(yè)務(wù)量7 * 24小時(shí)運(yùn)行需要。

　　技術(shù)經(jīng)理 檢驗(yàn)系統(tǒng)性能瓶頸所在、有沒有內(nèi)存泄漏、中間件和數(shù)據(jù)庫的資源利用率是否合理。

　　一般而言，性能測試是作為一個(gè)上線之前的驗(yàn)收環(huán)節(jié)。處于這個(gè)階段的系統(tǒng)功能基本都已開發(fā)完成，測試目標(biāo)主要是對(duì)系統(tǒng)整體的一個(gè)性能測驗(yàn)。此時(shí)發(fā)現(xiàn)核心組件需要修改，調(diào)整的代價(jià)是很昂貴的。我們可以在項(xiàng)目建設(shè)初期就可以引入性能檢測，在開發(fā)過程中就對(duì)各業(yè)務(wù)模塊進(jìn)行測試，進(jìn)一步細(xì)化各階段的測試目標(biāo)，如下圖所示：

　　圖 1. 性能測試切入點(diǎn)

　　從圖1可以看出，系統(tǒng)本身有很多測試切入點(diǎn)。當(dāng)用戶界面層還不穩(wěn)定的話，可以從業(yè)務(wù)邏輯層著手，對(duì)系統(tǒng)進(jìn)行性能檢測。如果把系統(tǒng)看作是一幢大樓，則至下而上的每一層就是一個(gè)組件，組件本身牢固了，房子整體才結(jié)實(shí)。

　　4.2整理業(yè)務(wù)流程

　　測試目標(biāo)確認(rèn)之后，就需要針對(duì)這個(gè)目標(biāo)，對(duì)業(yè)務(wù)流程進(jìn)行整理，對(duì)于功能復(fù)雜的系統(tǒng)，還需要業(yè)務(wù)和開發(fā)人員的參與，以下方面可以關(guān)注：

　　1：區(qū)分用戶操作流程與系統(tǒng)的處理流程。兩者都是業(yè)務(wù)流程，但是系統(tǒng)處理流程是后臺(tái)發(fā)起，用戶不可見。例如，本文測試模型中，商品瀏覽屬于用戶操作流程；數(shù)據(jù)庫自動(dòng)執(zhí)行批處理是系統(tǒng)處理流程。

　　2：站在用戶的角度模擬業(yè)務(wù)操作，要覆蓋到所有的操作分支，包括容易產(chǎn)生的操作中斷。

　　業(yè)務(wù)流程整理直接關(guān)系到后續(xù)的測試用例和場景設(shè)計(jì)，兩者決定了性能測試數(shù)據(jù)是否能夠真實(shí)反映系統(tǒng)狀況，當(dāng)遇到性能測試實(shí)施團(tuán)隊(duì)不熟悉業(yè)務(wù)的情況，性能測試項(xiàng)目經(jīng)理需安排支援。

　　4.3制定量化指標(biāo)

　　在性能測試報(bào)告中，系統(tǒng)性能狀況會(huì)體現(xiàn)為一堆測試指標(biāo)及對(duì)應(yīng)的數(shù)值。被測目標(biāo)不同，指標(biāo)集合也不同，針對(duì)本文測試模型，可以制定以下簡單的指標(biāo)（更加細(xì)化的指標(biāo)可參閱相關(guān)文檔）。

　　功能層：事務(wù)平均響應(yīng)時(shí)間、每秒完成的事務(wù)數(shù)、成功的事務(wù)數(shù)、失敗的事務(wù)數(shù)。

　　中間件：JVM內(nèi)存使用情況、中間件隊(duì)列、線程池利用率。

　　數(shù)據(jù)庫：隊(duì)列長度、最占資源的SQL、等待時(shí)間、共享池內(nèi)存使用率。

　　操作系統(tǒng)：CPU平均利用率、CPU隊(duì)列、內(nèi)存利用率、磁盤IO。

　　有了指標(biāo)，我們還需要根據(jù)測試目標(biāo)，設(shè)定其對(duì)應(yīng)的數(shù)值范圍。例如根據(jù)產(chǎn)品經(jīng)理要求，在并發(fā)一千人訪問的情況下，系統(tǒng)平均一次事務(wù)響應(yīng)時(shí)間不超過5秒，則可以設(shè)定響應(yīng)時(shí)間的數(shù)值范圍是小于5秒成功，大于5秒失敗。還可以指定CPU利用率、JVM內(nèi)存利用率等性能指標(biāo)的數(shù)值范圍（表3），需要說明的是，不同測試工具支持的指標(biāo)集是不同的，可利用多個(gè)測試工具進(jìn)行協(xié)同收集。

　　表3 性能指標(biāo)數(shù)值范圍

　　指標(biāo)項(xiàng)目 測試場景 合理指標(biāo)值

　　平均CPU利用率 并發(fā)一千用戶 < 85%

　　平均JVM利用率 并發(fā)一千用戶 < 80%

　　量化的性能指標(biāo)能夠給系統(tǒng)帶來優(yōu)化的目標(biāo)，當(dāng)我們說性能符合預(yù)期，指的是所有指標(biāo)的值都在理想范圍以內(nèi)，那么如何制定正確的數(shù)值范圍呢，這個(gè)就必須靠經(jīng)驗(yàn)和系統(tǒng)歷史數(shù)據(jù)來進(jìn)行分析。前者是類比同類型系統(tǒng)的性能指標(biāo)，后者需要挖掘運(yùn)維數(shù)據(jù)，包括用戶訪問峰值，每秒最高事務(wù)處理數(shù)等。
4.4制定測試用例與場景

　　性能測試用例是對(duì)整理過的業(yè)務(wù)流程進(jìn)行再分解，描述其成為可測試的功能點(diǎn)，結(jié)合性能指標(biāo)轉(zhuǎn)換為測試執(zhí)行代碼。本文測試模型中，用戶登錄的用例簡要描寫如下（省略掉用例前置條件，例如系統(tǒng)配置和部署信息）：

　　表4 測試用例1

　　登錄測試用例

　　1：用戶打開網(wǎng)站首頁，頁面應(yīng)該正常展現(xiàn)，超過60秒則算失敗。

　　2：用戶輸入賬號(hào)和密碼，點(diǎn)擊登錄按鈕，等待系統(tǒng)提示成功或失敗，如果等待超過60秒，則算登錄失敗。

　　測試用例1中，用戶與系統(tǒng)有兩次交互（打開網(wǎng)址和點(diǎn)擊登錄按鈕），需分別統(tǒng)計(jì)每一次交互的等待時(shí)間。考慮到用戶實(shí)際操作的話，會(huì)有一定的停頓，我們可在腳本中添加思考時(shí)間來模擬（固定或隨機(jī)等待時(shí)間）。不要小看這個(gè)設(shè)置，在用戶量大的情況下，對(duì)系統(tǒng)施加的壓力是完全不同的，然后在在統(tǒng)計(jì)的時(shí)候，去掉這部分思考時(shí)間。

　　性能測試用例執(zhí)行需對(duì)應(yīng)的場景，用于模擬系統(tǒng)實(shí)際運(yùn)行狀況。全面的系統(tǒng)測試在理論上是不可行的，所以設(shè)計(jì)測試場景的時(shí)候，主要定位是用戶典型的應(yīng)用場景。可粗略劃分為兩類：功能點(diǎn)測試場景和復(fù)雜業(yè)務(wù)測試場景。前者的目標(biāo)主要是檢驗(yàn)系統(tǒng)某個(gè)功能點(diǎn)的并發(fā)能力，后者更加貼近系統(tǒng)實(shí)際運(yùn)行情況。對(duì)于測試模型的用戶登錄功能，設(shè)計(jì)功能點(diǎn)測試場景1如下：

　　表5 測試場景1

　　并發(fā)用戶數(shù)：總共300，起始數(shù)量100，每1秒鐘增加10個(gè)用戶。

　　運(yùn)行方式：每一個(gè)并發(fā)用戶循環(huán)執(zhí)行登錄測試用例，持續(xù)15分鐘。

　　考慮到業(yè)務(wù)流程可以交叉進(jìn)行，例如測試模型中數(shù)據(jù)庫批處理與用戶操作混搭，我們?cè)O(shè)計(jì)一個(gè)復(fù)雜的測試場景如表6所示：

　　表6 測試場景2

　　并發(fā)用戶數(shù)：總共300，起始數(shù)量100，每1秒鐘增加10個(gè)用戶。

　　運(yùn)行方式：數(shù)據(jù)庫啟動(dòng)批處理清算，同時(shí)并發(fā)200個(gè)用戶進(jìn)行循環(huán)登錄，另外100個(gè)用戶隨機(jī)瀏覽商品。

　4.5準(zhǔn)備測試資源

　　測試資源包括4個(gè)方面：

　　1：硬件資源。性能測試環(huán)境應(yīng)該采用與生產(chǎn)環(huán)境一致的硬件條件，嚴(yán)格來說，如果硬件環(huán)境不一致，性能測試報(bào)告是不具備說服力的。

　　2：軟件資源。性能測試目標(biāo)系統(tǒng)需要部署與生產(chǎn)一致的軟件，在系統(tǒng)上生產(chǎn)之后，往往會(huì)增加一個(gè)監(jiān)控軟件，但監(jiān)控軟件也是有資源損耗的，尤其是B/S系統(tǒng)，頻繁的抓取JVM數(shù)據(jù)，會(huì)造成較大的壓力。

　　3：數(shù)據(jù)資源。數(shù)據(jù)量對(duì)性能的影響非常大，分兩種情況考慮測試數(shù)據(jù)，第一種是已經(jīng)運(yùn)行的系統(tǒng)做改造，則可以把生產(chǎn)環(huán)境的數(shù)據(jù)備份到測試環(huán)境。另外一種是首次上線的系統(tǒng)，這個(gè)時(shí)候業(yè)務(wù)數(shù)據(jù)是空的，需要造一些測試數(shù)據(jù)。至于數(shù)據(jù)量的級(jí)別，可以預(yù)測兩年后，業(yè)務(wù)數(shù)據(jù)量會(huì)有多少，性能測試需要有一定的前瞻性。

　　4：人力資源。性能測試會(huì)發(fā)現(xiàn)很多問題，而問題的定位和解決，需要更加專業(yè)的人來完成，包括商業(yè)軟件提供商。測試過程中，保持與開發(fā)團(tuán)隊(duì)的緊密溝通，是順利開展項(xiàng)目的關(guān)鍵。

　　4.6安排測試計(jì)劃

　　當(dāng)測試資源、可執(zhí)行代碼準(zhǔn)備好之后，就需制定一個(gè)測試計(jì)劃并分階段實(shí)施，簡單示例如表7所示。

　　表7 測試計(jì)劃

　　測試項(xiàng) 描述 測試類型/測試目標(biāo)（簡要）

　　基準(zhǔn)測試 收集系統(tǒng)基準(zhǔn)測試性能指標(biāo) 強(qiáng)度測試，獲取基準(zhǔn)測試數(shù)據(jù)數(shù)據(jù)。

　　開發(fā)調(diào)試 開發(fā)修復(fù)性能測試發(fā)現(xiàn)的Bug

　　功能點(diǎn)測試 對(duì)各業(yè)務(wù)功能點(diǎn)進(jìn)行性能測試 強(qiáng)度測試，獲取系統(tǒng)最大并發(fā)值等數(shù)據(jù)。

　　復(fù)雜業(yè)務(wù)測試 復(fù)雜業(yè)務(wù)場景性能測試 容量測試，獲取最佳用戶訪問值等數(shù)據(jù)。

　　開發(fā)調(diào)試 開發(fā)修復(fù)性能測試發(fā)現(xiàn)的Bug

　　長時(shí)間負(fù)載測試 系統(tǒng)在一定負(fù)載的情況下，長時(shí)間運(yùn)行。 疲勞測試，發(fā)現(xiàn)內(nèi)存泄漏等情況。

　　表7測試計(jì)劃說明如下：

　　1：表7中省略掉了測試項(xiàng)目的起止時(shí)間，包括了開發(fā)調(diào)試的工作。這是因?yàn)樵趯?shí)施過程中，如果遇到性能問題，開發(fā)是需要時(shí)間去修復(fù)的，性能測試有可能需要暫停。

　　2：首先進(jìn)行功能點(diǎn)測試，通過之后再進(jìn)行復(fù)雜業(yè)務(wù)測試，這是因?yàn)閱蝹€(gè)功能點(diǎn)相對(duì)簡單，業(yè)務(wù)邏輯復(fù)雜度不高，資源競爭與數(shù)據(jù)鎖等問題不太容易暴露。

　　3：基準(zhǔn)測試是系統(tǒng)日后升級(jí)的性能比較對(duì)象，例如在硬件升級(jí)后，同樣的測試場景，是否會(huì)得到更優(yōu)的結(jié)果，系統(tǒng)新技術(shù)的引進(jìn)或版本升級(jí)，對(duì)性能的影響是正面還是負(fù)面，都可以通過與基準(zhǔn)測試比較得出。

　　4：每一個(gè)測試階段都有相應(yīng)的測試目標(biāo)，采用的測試類型也不同，具體需根據(jù)之前的測試規(guī)劃來制定。

　　5性能測試執(zhí)行

　　執(zhí)行過程需要注意以下事項(xiàng)：

　　1：注意保存測試運(yùn)行過程的數(shù)據(jù)，作為測試結(jié)果的佐證。

　　2：有問題盡快反饋，系統(tǒng)的修改可能導(dǎo)致測試返工。

　　3：基準(zhǔn)功能點(diǎn)測試過程中，需清理測試現(xiàn)場后再進(jìn)行后續(xù)的測試，因?yàn)橄到y(tǒng)可能存在緩存。

　　4：按優(yōu)先級(jí)測試各業(yè)務(wù)場景。

　　6測試結(jié)果分析

　　每次執(zhí)行完測試后，會(huì)得到一個(gè)測試結(jié)果。先別著急完成后續(xù)的測試任務(wù)，可以先簡要的分析一下本次測試結(jié)果，看看數(shù)據(jù)是否符合邏輯。例如，對(duì)于同一個(gè)測試場景，增加并發(fā)用戶數(shù)（強(qiáng)度測試中常見），卻發(fā)現(xiàn)響應(yīng)時(shí)間反而變短，這就不符合邏輯。當(dāng)所有的測試任務(wù)完成后，分析數(shù)據(jù)并提交測試報(bào)告，注意以下方面：

　　1：針對(duì)不同角色的人員出具不同的測試報(bào)告，對(duì)于技術(shù)人員，可以有較多的性能數(shù)據(jù)和分析。

　　2：進(jìn)行一些前瞻性的預(yù)測，綜合本次測試的資源情況和指標(biāo)數(shù)據(jù)，分析系統(tǒng)性能擴(kuò)展的瓶頸。

　　7總結(jié)

　　性能測試不是一錘子買賣，隨著系統(tǒng)不斷升級(jí)，性能測試需要作為一個(gè)常態(tài)被關(guān)注。性能測試領(lǐng)導(dǎo)者也需保持對(duì)業(yè)務(wù)的關(guān)注，及時(shí)調(diào)整測試策略

天貓 軟件自動(dòng)化測試開發(fā)