基于LoadRunner+Fiddler 的小程序性能測試教學設計

馬敏，王敏，肖凌瑤

（湖北廣播電視大學，武漢430000）

0 引言

隨著近年來移動終端的迅速普及，高速網絡的快速發展，越來越多的用戶通過網絡學習、辦公、娛樂、購物。然而用戶訪問的高并發、高集中也給系統服務器帶來極大的負荷。最新的例子是今年二月中旬開始的“停課不停學”，由于大量學生在上課時段集中訪問，網絡教學平臺“雨課堂”、“職教云”、“藍墨云班課”等集體“癱瘓”。系統性能的好壞直接影響用戶的體驗、產品的市場占用率、公司的盈利，因此系統的性能測試也越來越受到各大公司的重視。順應行業需求，越來越多的高校軟件工程專業或其它計算機應用相關專業開設了《性能測試》課程。

作為一門理論知識廣泛，實踐性也很強的專業課程，《性能測試》總學時是36 個課時，2 個學分。該課程主要內容包括性能測試的基本概念、常見性能指標、性能測試執行及結果分析等。該課程標準要求在前期軟件設計及軟件測試技能基礎上提升高質量程序設計技能、掌握性能測試的基本技能、學會性能測試工具的使用方法。著重培養學生的熟練度、規范性、集成和項目能力[1]。如何在有限的學時內，讓學生達到課程目標，滿足企業測試崗位要求是一個值得研究的問題。

1 性能測試教學難點

1.1 教材中關于應用的內容太少

目前市面上關于軟件測試的教材很多，但專注于性能測試的較少，并且以理論為主，配合實戰案例的很少。這與高職強調實用、重視操作的培養目標不符。

1.2 抽象概念難理解

性能測試概念較多，例如吞吐率、點擊率、請求響應時間、事務響應時間等。以大二的學生開發水平和項目經歷理解這些抽象的概念難度較大[2]。

1.3 理論與實踐脫節

性能測試是一門理論廣度深度，實際操作要求都很高的課程，既需要學生掌握軟件測試的基本理論和流程，又需要學生快速理解不同產品的業務邏輯和常見性能指標。然而由于學生缺乏實際的項目經驗，加之現有的教材普遍停留與理論探討階段致使學生學習性能測試往往停留在表面，沒有領會其中的要領。

2 解決方案

2.1 選擇合適的被測系統

近年來，微信小程序以其便捷出色的用戶體驗成為移動端主流應用。我學院受第三方公司委托，組織本學院教師，成功開發了“我的國際農場”小程序。該項目主要是為了滿足日本關西地區面向中國市場推廣本地的農副產品和觀光旅游的需求。介紹日本茨城縣地方種植戶、加工廠、販賣店及旅游公司、運動俱樂部（足球、高爾夫等）、旅館，提供線上及線下的農場共享，旅日觀光等服務。

《性能測試》課程案例選用“我的國際農場”這個實際商用作為被測系統，幫助學生體驗真實的項目測試過程，避免所學與所用脫節。結合業內流行的抓包工具Fiddler 和性能測試工具LoadRunner，錄制和修改腳本。通過設計測試場景，執行性能測試，分析測試結果，引導學生理解性能測試[3-5]。

2.2 設計實用的教學案例

《性能測試》課程知識點多而繁雜，實戰性很強，但是僅有36 學時。如何保證教學的效率，讓學生掌握實用的崗位技能是教學案例設計的需要考慮的重點。因此通過將教學案例選取本學院自研的商用小程序“我的國際農場”，對標業內主流的測試工具和測試方法進行設計，確保學生所學內容滿足職業需求。

本課程中事務、集合點、檢查點是非常重要的基本概念，但是現有教材偏重抽象理論，沒有貫穿這三個基本知識點的案例，因此需要為這幾個知識點設計基于LoadRunner+Fiddler 的項目教學案例。

3 教學內容設計

3.1 測試環境準備

測試手機可采用學生的個人手機，建議用版本低于Android 7.0 的設備。

PC 采用學院機房Win10 系統主機，為了不影響抓包工具正常使用，PC 需要關閉防火墻，退出殺毒軟件。手機與PC 需要處于同一局域網中，PC 上安裝抓包工具Fiddler 官網最新版本和LoadRunner 12.02 社區版。配置手機網絡代理為PC 的IP 地址，端口號設為8888。Fiddler 設置偵聽端口為8888，與手機配置的端口號一致，否則無法與手機正常連接。由于小程序發送接收HTTPS 消息，因此需要勾選“Decrypt HTTPS traffic“并安裝證書。需要特別注意的是，Fiddler 配置后需要重啟，否則可能無法抓包。

3.2 測試場景設計

性能測試必須基于產品需求。小程序“我的國際農場”需求說明書中要求，50 個用戶同時登錄小程序并瀏覽商品列表，用戶平均登錄時間不超過2 秒，商品展示網頁正常顯示。因此性能測試場景應該圍繞這個需求設計，生成50 個虛擬用戶進行登錄和瀏覽操作。為了確認網頁的正常跳轉，需要進行文本檢查點設置。企業項目測試中，為了盡可能真實地模擬用戶的操作，50 個虛擬用戶通常使用不同的賬號登錄，需要用到參數化。由于本次教學內容不包括參數化的知識點，因此50 個虛擬用戶均以相同的賬號登錄。

3.3 Fiddler錄制腳本

首先打開已經配置好的抓包工具Fiddler 開始錄制，然后手機登錄微信小程序“我的國際農場”，點擊“我的工廠”菜單，頁面跳轉后瀏覽商品列表。將所有session 消息保存為login.saz。如圖1 所示。

圖1 Fiddler抓包消息

3.4 LoadRunner解析腳本

使用LoadRunner 打開腳本，刪除無關內容，根據需求設置登錄集合點、查詢商品列表事務和檢查點。案例要求對登錄進行壓力測試，因此需要在登錄相關代碼前設置集合點，并且統計登錄事務的耗時。注意事務開始和結束是同一個事務名稱，否則無法統計事務時間。為了驗證商品列表正確地顯示出來了，選擇商品“日本娃娃”作為頁面文字檢查點，如圖2。為了驗證修改后的腳本的正確性，在單用戶模式下運行腳本。如失敗，結合運行日志進行修改，直至成功。

3.5 LoadRunner場景設置并執行

上面的腳本是單個用戶的腳本。本次測試要求的是模擬50 個虛擬用戶，因此需要打開LoadRunner 控制器，設置虛擬用戶數量為50，腳本僅迭代一次。并添加服務器資源監控，關注測試執行過程中相關性能指標的變化情況。常用的資源監控有CPU 利用率、內存指標、TPS 等。設置完成后，點擊運行，開始運行場景，同時觀察資源監控波形圖的變化。如多用戶場景運行失敗，需返回修改腳本或者場景設置。

圖2 性能測試腳本

3.6 測試結果分析

腳本成功執行完畢后，打開LoadRunner 分析器，通過分析圖3，得出初步的測試結論：

圖3 運行用戶-事務平均響應時間

從圖3 可看出，測試50 個人同時登錄平均時間小于1 秒。“登錄事務”平均響應時間與虛擬用戶數量成正比關系。當并發虛擬用戶數量達到最大值50，“登錄事務”平均響應時間也隨之達到最大值0.055 秒.根據小程序“我的國際農場”的產品需求，50 人登錄時間小于2 秒即可。從測試日志也可看到返回頁面包含“日本娃娃”關鍵字，檢查點測試通過。綜上所述，該小程序對于50 人以內的并發“登錄事務”具有較好的處理能力，不存在明顯的性能瓶頸。需要注意的是，在企業實際性能測試項目中，需要結合多個圖表，針對當前測試環境進行瓶頸分析，并與開發人員溝通確認。教學中可簡化為分析典型圖表，得出初步結論即可。

3.7 教學的延伸

實施本教學案例的過程中，學生使用測試工具遇到的問題頗多。例如，Fiddler 無法抓到有效數據包，HTTPS 協議解析不成功，LoadRunner 系統資源監控的設置方法等。腳本的編寫方面，設置集合點和檢查點的位置是一個難點，同學出錯幾率高，設置位置錯誤造成測試結果不準確。測試結果圖表分析對于大多數同學是一個門檻，需要至少兩節課進行理論到實例的講解鋪墊，可重點突出“拐點法”。

由于學生在實際操作過程中遇到的問題很多，因此在課堂上建議劃分多個學習組進行團隊互助學習交流。每個學習組由4-5 個同學組成，每個組指定一位專業成績優異的同學擔任組長，負責組織和協調工作，并代表本小組做測試匯報。

4 結語

通過在《性能測試》課程中引入基于業內主流測試工具LoadRunner+Fiddler 的小程序測試案例，幫助學生在實際項目實踐中融會貫通抽象的理論知識。學生在團隊學習中主動投入，積極討論，共同解決疑難問題，提高了學習的興趣和信心，達到了較好的學習效果。

我學院目前已經在《功能測試》、《性能測試》課程中采用這種案例設計模式。接下來，我學院將在其他編程類課程中融入此類型案例。實踐證明這種跟隨業內主流技術，基于真實商業項目的教學案例更符合對理論廣度和實踐能力有較高要求的專業課程，更貼合企業的崗位需求，有利于增強學生的就業競爭力。