基于loadrunner物流信息交易平臺(tái)的性能測(cè)試與改進(jìn)
2016-05-19 14:15:55王閱軍衛(wèi)文學(xué)
電腦知識(shí)與技術(shù) 2016年7期
王閱軍++衛(wèi)文學(xué)
摘要：為了改善物流行業(yè)信息化存在的問(wèn)題，物流公司開(kāi)始構(gòu)建物流信息交易平臺(tái)，由于數(shù)據(jù)量巨大，平臺(tái)的性能極其需要保證。該文以魯南物流信息交易平臺(tái)作為此次的測(cè)試對(duì)象，針對(duì)信息交易平臺(tái)的功能和性能特點(diǎn)，以及用戶的需求，和客戶管理要求，制訂了詳盡的測(cè)試方案，之后使用自動(dòng)化性能測(cè)試工具loadrunner 對(duì)信息平臺(tái)進(jìn)行性能測(cè)試，并對(duì)測(cè)試結(jié)果進(jìn)行了詳細(xì)的分析，找出了系統(tǒng)存在的瓶頸，并對(duì)問(wèn)題進(jìn)行改進(jìn)，提高物流信息交易平臺(tái)的工作效率，滿足用戶的基本需求和客戶要求。
關(guān)鍵詞：物流信息交易平臺(tái)；負(fù)載測(cè)試；自動(dòng)化性能測(cè)試工具
中圖分類號(hào)：TP311 文獻(xiàn)標(biāo)識(shí)碼：A 文章編號(hào)：1009-3044（2016）06-0079-02
Based on Loadrunne Performance Test of Logistics Information Trading Platform
WANG Yue-jun， WEI Wen-xue
（Shandong University of Science and Technology Institute of Information Science and Engineering，Qingdao 266590， China）
Abstract： In order to improve the problems existing in the logistics industry informatization， the logistics company began to build a logistics information platform， because of the huge amount of data， the performance of the platform need to guarantee. Based on great logistics information exchange platform as the test object， in accordance with the functional and performance features of the information exchange platform， and the user's requirements， and customer management requirements， formulate the detailed test plan， then using the automatic performance test tools loadrunner to performance test of information platform， and the test results are analyzed in detail， finding out the system bottlenecks， and to improve the problem， improve the working efficiency of the logistics information platform， basic meet user needs and customer requirements.
Key words： logistics information trading platform； load tests； automated performance testing tool
如今，物流行業(yè)的信息化程度還比較低，大部分從事物流的企業(yè)還處在傳統(tǒng)的運(yùn)作階段，表現(xiàn)為分散、低效的物流組織形式，粗放式經(jīng)營(yíng)的狀況。通過(guò)建立“魯南國(guó)際物流園區(qū)信息平臺(tái)”，可以使商流、物流、資金流和信息流在物流信息系統(tǒng)的支持下實(shí)現(xiàn)互動(dòng)，從而提供準(zhǔn)確和及時(shí)的物流信息服務(wù)，提高社會(huì)物流運(yùn)作效率。為了保證信息交易平臺(tái)的工作效率，使其為物流行業(yè)創(chuàng)造出更大的價(jià)值，需要通過(guò)性能測(cè)試找出系統(tǒng)性能瓶頸并進(jìn)行調(diào)優(yōu)。
傳統(tǒng)測(cè)試的測(cè)試方法是編程人員和測(cè)試人員同時(shí)登陸平臺(tái)并進(jìn)行相應(yīng)的操作，觀察瀏覽器響應(yīng)速度的快慢，如果瀏覽器反應(yīng)速度慢，對(duì)平臺(tái)的各個(gè)模塊進(jìn)行單獨(dú)測(cè)試，查找瓶頸所在并修改。傳統(tǒng)方法浪費(fèi)大量的人力物力，增加了研發(fā)成本，加長(zhǎng)了開(kāi)發(fā)周期。目前，自動(dòng)化測(cè)試軟件在市場(chǎng)上紛涌而出、種類繁多。其中，Loadrunner是惠普公司的一款適應(yīng)于各種體系框架的預(yù)測(cè)系統(tǒng)行為和性能的負(fù)載測(cè)試工具。Loadrunner是一種黑盒測(cè)試工具，通過(guò)模擬實(shí)際用戶的操作錄制的軟件腳本，將模擬出的用戶用并發(fā)負(fù)載并實(shí)時(shí)性能監(jiān)測(cè)的方式來(lái)確定和查找問(wèn)題，在測(cè)試完之后，Loadrunner自動(dòng)生成檢測(cè)報(bào)告（PDF格式或HTML格式）[1]。通過(guò)使用loadrunner，企業(yè)能最大限度地縮短測(cè)試時(shí)間，優(yōu)化性能并加速應(yīng)用系統(tǒng)的發(fā)布周期。
1 Loadrunner工作原理
Loadrunner 11工作過(guò)程大致分為五個(gè)步驟：規(guī)劃負(fù)載、錄制腳本、定義場(chǎng)景、執(zhí)行場(chǎng)景和分析結(jié)果[2]。規(guī)劃負(fù)載：定義性能測(cè)試要求（定義自己理想情況下的平均事務(wù)響應(yīng)時(shí)間），可以在執(zhí)行場(chǎng)景下，觀察服務(wù)器的CPU利用率來(lái)決定；錄制腳本：錄制實(shí)際用戶對(duì)軟件的操作；定義場(chǎng)景：設(shè)定模擬人數(shù)，初始時(shí)間，結(jié)束時(shí)間等環(huán)境，如圖1所示；執(zhí)行場(chǎng)景：實(shí)時(shí)監(jiān)控，管理人數(shù)；分析結(jié)果：將結(jié)果導(dǎo)出，對(duì)結(jié)果進(jìn)行處理。其中，錄制腳本在Virtual User Generator模塊中，定義場(chǎng)景和執(zhí)行場(chǎng)景屬于Controller模塊，Analysis模塊包含分析結(jié)果過(guò)程。
通過(guò)Controller實(shí)時(shí)監(jiān)控，測(cè)試人員用Analysis來(lái)分析評(píng)估軟件或網(wǎng)站的性能。分析測(cè)試結(jié)果是loadrunner中最關(guān)鍵的一部分，它將運(yùn)行Controller的檢測(cè)圖生成報(bào)告，用來(lái)查看網(wǎng)站或軟件性能參數(shù)。測(cè)試人員在測(cè)試報(bào)告中看見(jiàn)四大類表圖：Vusers圖、事務(wù)響應(yīng)時(shí)間圖、Web資源圖和系統(tǒng)資源圖。
2 測(cè)試過(guò)程
測(cè)試用例應(yīng)主要以用戶需求為基礎(chǔ)，驗(yàn)證正確的功能和建立能暴露潛在錯(cuò)誤并分析應(yīng)確定哪些軟件結(jié)構(gòu)未被運(yùn)行。
本次性能測(cè)試主要對(duì)象是系統(tǒng)登錄、園區(qū)資源管理、園區(qū)日程管理、園區(qū)綜合服務(wù)管理、輔助決策五個(gè)方面。按照負(fù)載測(cè)試計(jì)劃，根據(jù)用戶需求錄制各個(gè)模塊腳本，以固定時(shí)間增加運(yùn)行人數(shù)，觀察Vusers圖、事務(wù)響應(yīng)時(shí)間圖、Web資源圖和系統(tǒng)資源圖的變化確定系統(tǒng)最大承受能力。
具體操作說(shuō)明： 以 15 秒鐘為運(yùn)行階梯逐一遞增 10個(gè)虛擬用戶，當(dāng)系統(tǒng)任一主機(jī) CPU 使用率在運(yùn)行階梯內(nèi)的平均值高于 100% 或者總體事務(wù)錯(cuò)誤率在運(yùn)行階梯內(nèi)的平均值首次大于 1%，停止測(cè)試，觀察虛擬人數(shù)數(shù)量，web服務(wù)器和數(shù)據(jù)庫(kù)服務(wù)器CPU的利用率[3]。
3 測(cè)試結(jié)果分析
當(dāng)自動(dòng)化測(cè)試工具對(duì)物流信息交易平臺(tái)進(jìn)行性能測(cè)試之前，測(cè)試人員需要配置測(cè)試環(huán)境網(wǎng)絡(luò)，一些系統(tǒng)參數(shù)，否則，這樣的測(cè)試結(jié)果沒(méi)有必要分析。
在確定分析接獲之后，就是對(duì)測(cè)試數(shù)據(jù)進(jìn)行深度挖掘，一般測(cè)試人員遵循的普遍原則是“由外而內(nèi)，由表及里，層層深入”[4]。例如，最終用戶體驗(yàn)交易響應(yīng)時(shí)間到網(wǎng)絡(luò)和服務(wù)器響應(yīng)交易時(shí)間（系統(tǒng)性能響應(yīng)時(shí)間），再到各組件的性能。
通過(guò)Loadrunner的分析組件Analysis，根據(jù)測(cè)試原則“由外而內(nèi)，由表及里，層層深入”進(jìn)行分析，快速定位問(wèn)題。如圖2可以看出問(wèn)題出現(xiàn)在事務(wù)活動(dòng)。
分析組件Analysis可以直觀地看出在測(cè)試時(shí)間內(nèi)事務(wù)的成功與失敗情況，所以比第一步更容易判斷出被測(cè)系統(tǒng)運(yùn)行是否正常。然后分析事務(wù)平均響應(yīng)時(shí)間（Average Transaciton Response Time），若事務(wù)平均響應(yīng)時(shí)間曲線趨高，則說(shuō)明被測(cè)系統(tǒng)處理事務(wù)的速度開(kāi)始逐漸變慢，即被測(cè)系統(tǒng)隨著運(yùn)行時(shí)間的變化，整體性能不斷下降。當(dāng)系統(tǒng)性能存在問(wèn)題時(shí)，該曲線的走向一般表現(xiàn)為開(kāi)始緩慢上升，然后趨于平穩(wěn)，最后緩慢下降。原因是：被測(cè)系統(tǒng)處理事務(wù)能力下降，事務(wù)平均響應(yīng)時(shí)間變長(zhǎng)，在曲線上表現(xiàn)為緩慢上升；而并發(fā)事務(wù)達(dá)到一定數(shù)量時(shí)，被測(cè)系統(tǒng)無(wú)法處理多余的事務(wù)，此時(shí)曲線變現(xiàn)為趨于平穩(wěn)；當(dāng)一段時(shí)間后，事務(wù)不斷被處理，其數(shù)量減少，在曲線上表現(xiàn)為下降。如果被測(cè)系統(tǒng)沒(méi)有等待機(jī)制，那么事務(wù)響應(yīng)時(shí)間會(huì)越來(lái)越長(zhǎng)，最后系統(tǒng)崩潰。如圖3所示。
根據(jù)錄制腳本和Loadrunner的分析組件Analysis的數(shù)據(jù)，測(cè)試人員可以在日志看見(jiàn)出錯(cuò)最多的action編號(hào)，找到相應(yīng)的腳本，查找發(fā)生的問(wèn)題的代碼或配置。
4 Loadrunner定位問(wèn)題及分析問(wèn)題
測(cè)試對(duì)軟件來(lái)說(shuō)事關(guān)重要，從軟件需求開(kāi)始每一步都要得到認(rèn)證、評(píng)估、需求。對(duì)于軟件的缺陷發(fā)現(xiàn)的越早對(duì)于軟件開(kāi)發(fā)公司和客戶公司的風(fēng)險(xiǎn)和成本越少。每個(gè)階段都有每個(gè)階段的測(cè)試，數(shù)據(jù)庫(kù)有數(shù)據(jù)庫(kù)的性能測(cè)試，代碼冗余等。
軟件的性能測(cè)試主要集中在數(shù)據(jù)庫(kù)和代碼。首先，數(shù)據(jù)庫(kù)表結(jié)構(gòu)設(shè)計(jì)出現(xiàn)問(wèn)題，表與表缺乏有效的連接。多數(shù)情況下，表與表的連接是主鍵和外鍵的連接。但是當(dāng)出現(xiàn)錯(cuò)誤或需求變更時(shí)，表與表的連接斷開(kāi)或丟失導(dǎo)致程序無(wú)法運(yùn)行，項(xiàng)目組把表與表的連接用顯示連接或隱式鏈接防止表的刪除或添加導(dǎo)致數(shù)據(jù)庫(kù)的查詢降低，減少客戶的體驗(yàn)；表冗余或表內(nèi)容冗余，例如水電費(fèi)的單價(jià)和費(fèi)用，各種車輛表格統(tǒng)計(jì)；低效率的SQL語(yǔ)句同樣降低數(shù)據(jù)庫(kù)的性能，例如多個(gè)項(xiàng)目表用AND連接：
SELECTHFlexibleFee.ChargeItemName，HFlexibleFee.Amount， dMember.MembNo，HFlexibleFee.ReceivableTime，Member.MembName，HFlexibleFee.HFlexibleFeeGUID，
IndustryType.IndustryTypeName，HFlexibleFee.IfPaid，Member.TransIDCardNo
FROMHFlexibleFee，Member，IndustryType
WhereHFlexibleFee.MembGUID=Member.MembGUIDAND
Member.IndustryTypeNo=IndustryType.IndustryTypeNo
另一個(gè)方面，數(shù)據(jù)庫(kù)的配置參數(shù)也是數(shù)據(jù)庫(kù)性能問(wèn)題的表現(xiàn)，數(shù)據(jù)庫(kù)的大小會(huì)對(duì)數(shù)據(jù)庫(kù)的緩存等造成負(fù)載，造成頁(yè)面響應(yīng)緩慢、網(wǎng)頁(yè)找不到等現(xiàn)象。
代碼的書(shū)寫(xiě)和邏輯也是影響軟件性能的方面。軟件邏輯的好壞關(guān)系到處理器處理的速度，同樣的list語(yǔ)句，第一個(gè)list.addAll（queryObject.list（））方法被調(diào)用，與第二個(gè)List
性能測(cè)試結(jié)果表明系統(tǒng)存在嚴(yán)重的性能問(wèn)題。響應(yīng)時(shí)間遲緩，內(nèi)存占用過(guò)多，不能支持大量的數(shù)據(jù)請(qǐng)求，在大量用戶并發(fā)訪問(wèn)的情況下系統(tǒng)崩潰。應(yīng)該注意每一行代碼的效率，所謂“積少成多，滴水穿石”，一些看似細(xì)小的問(wèn)題可以經(jīng)過(guò)多次的執(zhí)行累積成一個(gè)大問(wèn)題。就是一個(gè)量變到質(zhì)變的過(guò)程。
5 結(jié)束語(yǔ)
通過(guò)性能測(cè)試，軟件測(cè)試的目的就是發(fā)現(xiàn)各種缺陷，測(cè)試在正常工作的狀態(tài)下工作量非常大，實(shí)現(xiàn)起來(lái)非常困難。從性能測(cè)試軟件的腳本發(fā)現(xiàn)，軟件某模塊運(yùn)行不正常，代碼冗余造 成服務(wù)器負(fù)載運(yùn)行：在有限的時(shí)間內(nèi)，有限的測(cè)試資源下，想證明程序在所有情況下都能正常工作是不可能的。因此自動(dòng)化性能測(cè)試工具并發(fā)的、穩(wěn)定的、最大吞吐量的對(duì)已開(kāi)發(fā)的軟件進(jìn)行全面的具體的測(cè)試，驗(yàn)證事務(wù)響應(yīng)時(shí)間是否滿足用戶的需求。同時(shí)，在測(cè)試環(huán)境求出最大吞吐量與合適的響應(yīng)時(shí)間，保留對(duì)軟件的擴(kuò)展空間而超出正常范圍的測(cè)試。
參考文獻(xiàn)：
[1] 趙斌.軟件測(cè)試技術(shù)經(jīng)典教程[M]. 2版.北京：科學(xué)出版社，2011.
[2] 蓸晉元. LoadRunner在軟件性能測(cè)試中的應(yīng)用[J].電腦開(kāi)發(fā)與應(yīng)用，2008，21（5）：36-37.
[3] 戴曉婧，張寧.基于loadrunner數(shù)據(jù)分析平臺(tái)性能測(cè)試及優(yōu)化[J].計(jì)算技術(shù)與發(fā)展，2013（7）：202-206.
[4] 陳紹英，劉建華，金成姬.Loadrunner性能測(cè)試實(shí)戰(zhàn)[M]. 北京： 電子工業(yè)出版社， 2007.
