測試場景設定：
首先將指令碼放入場景，分配設定vuser數量為10、15、50和75，分四次執行，每次持續5分鐘（這裡設定持續5分鐘，並不是說每次場景只需要執行5分鐘而已，而是為了快速採集部分演示資料，實際不同的場景指令碼需要持續多少時間，根據業務需求而定），收集併發使用者數、響應時間和通過事務量來進行資料曲線的變化的分析。此處省略了lr結果圖形截圖，讓我們直接來看整理後的資料。（監控資料暫不納入其中）
通過整理後的統計資料可以看出（以併發使用者數從10增加到15 為栗）：
使用者併發量增加了約為1.5倍；
平均響應時間從
0.227s
增加到了
0.297s
，增加約為
1.3倍； 平均
tps（
tps採用的計算方法為
tps=
併發使用者數
*1/平均響應時間）由約為
44增加到了約為
51，約增加了
1.16倍；
事務通過量由
652增加到了
907，約增加為
1.4倍。
由歸納整理後的資料，可以做出以下分析：
如果當我們系統的tps在沒有達到最大值之前，使用者量增加1.5倍，那麼通過事務總量也應該增加1.5倍，但是實際情況是通過的事務總量增量了1.4倍；
如果tps在10
個併發使用者的時候已經是最大值了，那麼併發使用者增加
1.5倍，響應時間應該增加
1.5倍，事務通過量無明顯增加或者減少，實際上我們的平均響應時間增加了約為
1.3倍，事務通過總量增加了約為
1.4倍。
通過以上分析方法，我們可以確定：
在併發使用者為10的時候，系統的tps還是有提公升空間的。
同理可得，當併發使用者達到15的時候tps已經不會繼續提公升了，但是不代表系統響應就很糟糕了，因為當tps到達50的時候平均響應時間也只有1s而已。
當使用者達到75時，tps已經不會繼續提公升了且平均響應時間達到11.238s。接下去我們需要運用相同的方法，細化此時間段的測試，結合其他監控資料去定位系統最優可承受的併發使用者數。
綜上所述，我們所做的一切分析都是基於列表中資料展開的，列表經過處理的資料是來自效能測試工具lr的原始統計資料。由此可見，分析方法沒有本質區別，主要區別在於我們如何獲取要分析的資料、分析哪些資料。選擇資料的時候也並非所有場景資料都可以納入分析範疇，要選擇整個場景執行穩定的資料進行相關分析。將有效資料歸納整合成資料走勢圖，根據資料走勢運用理論的思想分析資料，就是本篇的核心所在。
Apache ab效能測試結果分析
一直以來我都是用loadrunner去做效能測試。loadrunner實際上是乙個很重的效能測試工具。他的功能很全面，是一把很好的牛刀。如果我們只是需要對乙個頁面做簡單的效能測試，使用loadruner這把牛刀就不是乙個很好的選擇了。測試命令 ab n 100 c 10 本文主要針對ab的測試報告進...
測試結果分析 所羅門學習風格測試結果及分析量表
測試須知 以下的題目可以幫助你了解自己的學習風格。請你仔細閱讀每個題目，然後選擇乙個答案。每個答案無所謂正確與錯誤。回答時不要考慮應該怎樣，只回答你平時是怎樣的。每題都要回答。1.為了較好地理解某些事物，我首先 a 試試看。b 深思熟慮。2.我辦事喜歡 a 講究實際。b 標新立異。3.當我回想以前做...
測試結果分析 第四單元測試結果分析
今天考查第四單元，測試結果分數層如下 一百分 13人 九十分層 39人 八十分層 6人 七十分層 2人 六十分層 1人 第一題我會聽，也會做，聽老師讀詞語，連一連，練成詞語，錯誤人數 3人 烈建 楷鑫 沐晴 第二題我會選，也會連 第一小題，蝴蝶應落到哪朵花上，選出來塗成紅色的，錯誤人數 16人，大多...