1 引言
為了讓企業(yè)的管理和運營更加高效。使企業(yè)商業(yè)模式由以產品為中心升級到以客戶為中心，CRM的在各個企業(yè)的使用率越來越高。CRM(Customer Relationship Mallagement)即為客戶關系管理。是指用計算機技術完成客戶管理、銷售、市場營銷等一系列功能的系統(tǒng)。CRM系統(tǒng)具有數(shù)據大集中、數(shù)據實時性強，交互性強、系統(tǒng)穩(wěn)定性高等特點，隨著電子商務客戶量和數(shù)據量的加大，CRM系統(tǒng)的負荷越來越重，其性能的好壞將直接決定企業(yè)提供服務的質量。所以相比于其他系統(tǒng)功能至上的測試理念不同，CRM系統(tǒng)最注重的則是軟件性能測試，而工業(yè)標準級負載測試工具LoadRunner則使CRM系統(tǒng)的性能測試變得輕松可靠。
2 軟件性能測試概述
性能測試是指利用自動化測試軟件模擬多種正常、峰值、異常條件來對系統(tǒng)施壓，從而驗證系統(tǒng)的各項性能指標是否能夠達到用戶所要求的標準，進而找出系統(tǒng)瓶頸，優(yōu)化系統(tǒng)性能。性能測試包括負載測試和壓力測試兩個方面：
1)負載測試：確定在各種工作負載下系統(tǒng)的性能，目標是測試當負載逐漸增加時系統(tǒng)各項性能指標的變化情況。
2)壓力測試：通過確定一個系統(tǒng)的瓶頸或者不能接收的性能點，來獲得系統(tǒng)能提供的最大服務級別。
壓力測試與負載測試原理相同但目標不同，負載測試是發(fā)現(xiàn)系統(tǒng)的性能瓶頸，而壓力測試則是找到系統(tǒng)所能承載的最大服務級別，壓力測試可以看作是極限條件下的負載測試。
3 利用LoadRunner對CRM系統(tǒng)進行負載測試
3.1 CRM系統(tǒng)介紹
當下，Web技術發(fā)展迅猛。CRM系統(tǒng)的也緊跟技術發(fā)展步伐步入了Web2.0時代。功能上，CRM一般由客戶協(xié)作管理、業(yè)務管理、分析管理和應用集成管理四個分系統(tǒng)組成，結合各個分系統(tǒng)的功能及其特點，一套優(yōu)秀的CRM系統(tǒng)應當具有綜合性、集成性、智能化、高技術和復合性等特點。
本文所要測試的國內某大型電子信息制造企業(yè)所使用的CRM系統(tǒng)主要由客戶端、Web服務器、應用服務器及數(shù)據庫服務器等組成。從架構上看，本CRM系統(tǒng)采用的是B/S模式的三層結構，即表示層、業(yè)務邏輯層與數(shù)據層，其架構與系統(tǒng)組件的對應關系如圖1所示。
圖1 CRM系統(tǒng)體系結構
3.2 制定CRM系統(tǒng)測試計劃
由于本CRM系統(tǒng)是企業(yè)運用于全球客戶關系的管理。包括供應商、合作伙伴和分銷商，并不涉及終端個人用戶，所以系統(tǒng)的用戶量不高，同時登錄系統(tǒng)的用戶不會像其他Web應用那樣造成服務器癱瘓的狀況，但是CRM系統(tǒng)產生的數(shù)據量大。系統(tǒng)操作效率要求高，因此我們不必關心系統(tǒng)最大服務級別，而要重點監(jiān)控數(shù)據庫服務器的運行狀況。由于CRM系統(tǒng)性能測試場景多且復雜，所以我們只選取了其中一個數(shù)據庫查詢場景作介紹，測試計劃表如表1所示。
表1 測試計劃表
3.3 設計測試腳本
腳本主體采用自動錄制方式，按照測試計劃表逐項操作，錄制完成后，我們必須對腳本進行增強以適合測試場景：
1)參數(shù)關聯(lián)：本例中需要關聯(lián)的量有三個，兩個會話碼和一個安全碼，首先，我們要找到其左右邊界，然后確定該會話碼在服務器響應中第一次出現(xiàn)的位置，將以下代碼嵌入其所在位置的前面。
2)插入事物：在此，我們需要測試登錄、搜索、打開、退出等一系列操作的響應時間，所以我們需要把這四種操作分別做成事物，即在每個操作的代碼前后插入事物開始和事物結束函數(shù)，以登錄為例插入事物方法如下。
Ir_start_transaction(“Sign In”)；
Ir_end_transaction(“Sign In”，LR_AUTO)；
3)插入集合點：因為要模擬用戶同時
3)插入集合點：因為要模擬用戶同時操作，為了達到并發(fā)操作，我們需要在上述四個事物前面添加集合點，按照需求，我們把集合點函數(shù)放到四個事物開始之前，以登錄為例函數(shù)如下。
Ir_rendezvous(“Sign In”)：
4)訂單號的保存：由于原網站沒有保存訂單號的鏈接。在錄制過程中無法完成此功能，所以我們必須手工編寫腳本來實現(xiàn)訂單號的保存。Action()函數(shù)開始處編寫頭文件：
3.4 設計運行場景
根據測試要求，我們設計了兩種運行場景：
1)并發(fā)用戶數(shù)20、40、60：采用運行前加載所有用戶的方式，迭代一次。
2)并發(fā)用戶逐級遞增：采用初始用戶數(shù)20，每90s增加20的方式，運行五分鐘。以上兩種方式的加載主機均為美國IP地址：10.37.143.143，思考時間設置為最高2s。
3.5 分析結果
以上幾個場景運行完成后，將結果導入Analysis，并發(fā)條件下的事物響應時間如表2所示。從表2我們可以看出各個事物響應時間隨著并發(fā)用戶數(shù)的增加而增大，但是所有響應時間數(shù)據隨著并發(fā)用戶數(shù)的增加變化平穩(wěn)，而且60個用戶并發(fā)時，所有響應時間在用戶可接受范圍之內。
表2 用戶并發(fā)測試結果表
虛擬用戶數(shù)成功數(shù)平均事物響應時間(單位：s)(并發(fā)百分比) 登錄系統(tǒng)查詢訂單打開訂單退出系統(tǒng)點擊率是指客戶端每秒向服務器提交的HTTP請求數(shù)，并不是我們平時所理解的頁面上某一內容被點擊的次數(shù)，鼠標一次點擊可以產生很多個HTTP請求，如圖2。吞吐率和點擊率正好相反，指的是客戶端每秒從服務器獲得的數(shù)據量，如圖3。點擊率可以反映用戶產生的負載量。如果系統(tǒng)運行正常，點擊率增大，相應的吞吐率也會增大，所以通過對比點擊率與吞吐率，我們可以判斷出服務器的運行狀況。
圖2 并發(fā)虛擬用戶數(shù)——點擊率對照圖
圖3 并發(fā)虛擬用戶數(shù)——吞吐率對照圖
圖2和圖3中，當虛擬用戶隨著時間而逐級增加時，我們看到點擊率和吞吐率都有一個上升的趨勢，且上升的幅度在一個合理的范圍，說明系統(tǒng)在用戶數(shù)突然增加時，仍能夠保持相對的穩(wěn)定。兩圖中吞吐率和點擊率都有四個峰值，通過時間軸判斷。此時系統(tǒng)正在執(zhí)行訂單查詢操作，說明數(shù)據庫服務器此刻接受了大量的請求，也發(fā)出了大量的響應。因為CRM系統(tǒng)數(shù)據量龐大，結合查詢事物響應時間，我們可以斷定數(shù)據庫服務器工作狀態(tài)正常。
4 結語
性能測試是一個系統(tǒng)而復雜的工程。針對各個不同的系統(tǒng)，測試方法和技術往往不同。本文介紹了性能測試的基本原理與關鍵技術，并以國內某大型電子信息制造企業(yè)CRM系統(tǒng)數(shù)據庫為例用LoadRunner進行了測試，取得了較好的結果，為CRM軟件性能測試提供了一種新思路。
核心關注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務領域、行業(yè)應用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務管理理念，功能涉及供應鏈、成本、制造、CRM、HR等眾多業(yè)務領域的管理，全面涵蓋了企業(yè)關注ERP管理系統(tǒng)的核心領域，是眾多中小企業(yè)信息化建設首選的ERP管理軟件信賴品牌。
轉載請注明出處：拓步ERP資訊網http://www.oesoe.com/
相關文章
