場景運行結束后，需針對測試結果進行性能分析。通常而言，Jmeter性能測試結果分析可從性能測試指標達成方面著手，然后再分析測試過程中出現的異常情況，逐一判斷是否存在性能風險。

1.用戶登陸并發測試結果分析

獲取測試指標提取階段獲得的用戶登陸并發性能指標數據，如表1所示。

測試項響應時間業務成功率并發測試CPU使用率內存使用率登陸<=5秒100%100<=80%<=80%

(1)響應時間

用戶登陸響應時間目標指標<=5秒，結合Jmeter執行結果后的聚合報告分析，如圖1所示。

從圖中可以看到，每個請求的平均值為559.18毫秒、108毫秒、80毫秒，用戶登陸過程中的每一個請求均<=5秒，故測試通過。在Average response time與90%、95%相差不大時，可采用90%采樣數據填入測試結果對比表。

(2)Apdex

性能指數，Apdex(Application Performance Index)是一個國際通用標準，Apdex 是用戶對應用性能滿意度的量化值。它提供了一個統一的測量和報告用戶體驗的方法，把最終用戶的體驗和應用性能作為一個完整的指標進行統一度量。該指標在制定性能測試指標時可根據實際性能評價需求增加。

圖2表示為通用用戶滿意度區域，0代表沒有滿意用戶，1則代表所有用戶都滿意。實際業務系統開發過程中，1是團隊的追求目標。

針對ECShop用戶登陸業務，100個并發登陸的APDEX指標如圖3所示。從圖中可看出，所有請求的Apdex值都接近1，因此用戶滿意度優秀，也從側面說明了服務器響應速度快。

(3)業務成功率

測試腳本中設置了斷言，判斷用戶登陸后是否出現“登陸成功”字樣，并設定了“斷言結果”查看器，通過查看斷言結果，全部通過，則說明登陸全部完成，業務成功率為100%。

(4)并發數

線程組設置為100個線程，運行過程中未出現任何異常，滿足100個線程并發操作需求。

(5)系統資源使用

利用Jmeter監控系統資源，測試完成后結果如圖5所示。

通過上圖分析，CPU處于正常狀態，因此次測試場景運行時間短，所以波峰及波谷明顯，但均未持續超過80%，內存幾乎無變化，被測服務器內存使用率維持在20%以內。因此測試結果符合預期目標指標。

(6)數據庫監控

利用Spotlight監控到的服務器Mysql數據庫在測試期間運行的SQL為SELECT,與被測登陸業務對數據庫操作吻合，如圖6所示。

通過上述測試指標分析，更新用戶登陸并發測試結果表如表2所示。

測試項結果屬性響應時間業務成功率并發測試CPU使用率內存使用率

登陸預期結果<=5秒100%100<=80%<=80%實際結果0.169秒100%100不超過80%20%通過/失敗YYYYY

2.用戶登陸業務量測試結果分析

提取用戶登陸業務量測試的目標指標如表3所示

測試項響應時間業務成功率業務量CPU使用率內存使用率登陸<=5秒100%2小時5萬次<=80%<=80%

(1)響應時間

測試完成，生成測試報告后，獲取響應時間趨勢圖，如圖7所示。

通過上圖分析，采用90%采樣數據，分析整個請求，任何一個請求均未超過5秒，因此響應時間通過。

(2)業務成功率

測試過程中所有斷言通過，并且沒有任何錯誤，登陸成功率100%。“打開首頁”、“打開用戶登陸頁面”、“提交登陸信息”與后面請求數據存在差異，是因為測試時間到達后部分請求立刻停止，故未能保證業務的完整性。

(3)業務量

本次業務量測試，設置線程數為78個，2小時完成登陸總數為8427次登陸，其中包含了11秒操作停留時間，如果去除11秒停留時間，從數據理論計算，2*60*60/0.131=54961次，可達到預期2小時5萬次登陸操作，需進一步測試。

(4)系統資源使用

通過Jmeter監控服務器CPU及內存使用率來看，CPU及內存使用率非常穩定，且維持在20%-30%之間，滿足預期目標不超過80%，測試通過。

(5) 數據庫監控

數據庫執行過程監控正常，符合業務請求變化趨勢，如圖9所示。

通過上述測試指標分析，更新用戶登陸業務量測試結果表如表4所示。

測試項結果屬性響應時間業務成功率業務量CPU使用率內存使用率用戶登陸預期結果<=5秒100%2小時5萬<=80%<=80%實際結果0.131秒100%54961<40%20%通過/失敗YYNYY

業務量測試存在一定差異，可進一步測試。

3.隨機購物并發測試結果分析

提取隨機購物并發測試的目標指標如表5所示。

測試項響應時間業務成功率并發測試CPU使用率內存使用率隨機購買商品<=5秒100%100<=80%<=80%

(1)響應時間

測試完成后，根據生成的測試報告，獲取隨機購物100個并發響應時間如圖10所示。

通過上圖分析，隨機購物100個線程并發執行時，平均響應時間分別為：631毫秒、105毫秒、588毫秒、748毫秒、246毫秒、288毫秒、786毫秒、2848毫秒、1934毫秒、2161毫秒、836毫秒、290毫秒、307毫秒，通過這些數據分析，每個請求所消耗的時間均未超過5秒，但90%采樣數據中，“填寫收貨信息”請求響應時間為5395毫秒，嚴格來說，該請求測試不通過。更新測試目標指標表時可采用90%采樣。

(2)Apdex指標

隨機購物100個并發測試的Apdex指標信息如圖11所示。

通過上圖可以看出，填寫收貨信息、提交物流及付款方式、進入物流及付款方式設定頁面三個請求用戶滿意度低于0.5，意味系統對這三個請求的響應時間較慢，尤其是收貨信息、提交物流及付款方式這兩個情況。測試工程師可針對這兩個請求，給出性能測試不通過結論。通常而言，最低要求超過0.5，當然項目組可設定具體需求。

(3)業務成功率

測試結束后，檢查系統后臺訂單信息，100個并發線程，每個線程循環1次，故生成100個訂單，且運行過程中沒有任何錯誤。故認為隨機購物100并發測試業務成功率為100%。

(4)并發數

線程組設置為100個線程，運行過程中未出現任何異常，滿足100個線程并發操作需求。

(5)系統資源使用

執行過程，通過Jmeter監控得到本次測試系統資源使用情況，如圖12所示。

通過上圖分析可知，CPU在測試過程中持續值維持在90%以上，有17秒時間幾乎達到100%，因此從指標信息判斷，本次CPU使用率超過預期80%的目標。

同時，內存使用率在25秒以后也呈現明顯上升趨勢，需分析這段時間什么業務導致資源使用率上升。總體內存使用率維持在30%-40%之間，低于預期目標不超過80%，故內存使用率通過。

基于CPU、內存使用率，分析響應時間圖表，如圖13所示。

通過上圖分析，可知“填寫收貨信息”響應時間持續升高，需測試工程師報告此問題，聯合研發同事分析“填寫收貨信息”涉及哪些具體操作，如是否操作數據庫，是否需要大量緩存、是否調用第三方地址編輯控件等，從而確定響應時間升高原因，是否因此導致CPU及內存使用率升高。

(6)數據庫監控

從Mysql數據庫SQL語句執行速度來看，符合場景執行設計過程，但SQL中Inserts語句體現不明顯，需關注原因，確定是監控本身問題，還是被測對象SQL語句設計問題。

通過上述測試指標分析，更新用戶登陸并發測試結果表如表6所示。

測試項結果屬性響應時間業務成功率并發測試CPU使用率內存使用率 隨機購買商品預期結果<=5秒100%100<=80%<=80%實際結果2.302秒100%100>90%20%通過/失敗NYYNY

綜合測試數據分析，“填寫收貨信息”請求響應時間超過5秒，CPU使用率超過90%，故隨機購物100并發場景測試不通過。需分析“填寫收貨信息”涉及哪些操作，導致響應時間變長的原因，是否對CPU及內存使用率造成了影響。

4.隨機購物業務量測試結果分析

提取隨機購物業務量測試指標如表7所示：

測試項響應時間業務成功率業務量CPU使用率內存使用率隨機購買商品<=5秒100%2小時5萬次<=80%<=80%

100個線程持續執行2分鐘后，出現大量業務錯誤，服務器CPU使用率持續維持在100%附近，因此利用100個線程進行2小時的隨機購物業務量測試失敗。可根據需要，利用折半驗證法，驗證系統穩定性測試的最佳線程數及服務器資源配置是否合理。

數據庫報錯如下：

MySQL server error report:Array( [0] => Array ( [message] => MySQL Query Error ) [1] => Array ( [sql] => INSERT INTO `ecshop`.`ecs_order_info` (order_sn, user_id, order_status, shipping_status, pay_status, consignee, country, province, city, district, address, zipcode, tel, mobile, email, best_time, sign_building, postscript, shipping_id, shipping_name, pay_id, pay_name, how_oos, card_message, inv_payee, inv_content, goods_amount, shipping_fee, insure_fee, pay_fee, pack_fee, card_fee, surplus, integral, integral_money, bonus, order_amount, from_ad, referer, add_time, pack_id, card_id, bonus_id, extension_code, extension_id, agency_id, inv_type, tax, parent_id, discount, lastmodify) VALUES ('2017110775867', '2223', '0', '0', '0', 'hzdl00168', '1', '2', '37', '403', '北京東城區', '', '01088888888', '', 'hzdl00168@qq.com', '', '', '', '5', '申通快遞', '2', '銀行匯款/轉帳', '等待所有商品備齊后再發', '', '', '', '1999', '15', '0', '0', '0', '0', '0', '0', '0', '0', '2014.00', '0', '本站', '1510050069', '0', '0', '0', '', '0', '0', '', '0', '0', '', '1510050069') ) [2] => Array ( [error] => Duplicate entry '2017110775867' for key 'order_sn' ) [3] => Array ( [errno] => 1062 ))

系統資源趨勢圖：

上述所有場景，如時間、條件、資源允許，測試工程師應當多測試幾次，根據平均值輸出測試報告。