摘要：而在使用測試完后并不能直接生成的報告無論是用還是命令行啟動。所以需要對這個報告進行擴展。在擴展的過程中進一步發現的聚合結果中最后的總體一行在某些情況下計算的數值是不準確的。
題記：在用 loadrunner 的時候可以生成一個 HTML 的報告，并且里面包含各種圖表，各種詳細的數據。而在使用 Jmeter 測試完后并不能直接生成 Html 的報告（無論是用 GUI 還是命令行啟動）。
經過查找資料發現 Jmeter 的 extras 目錄下有生成 HTML 的 xsl 樣式表，其實 Jenkins+ant+Jmeter 生成的 HTML 報告也是調用了這里的樣式表生成的，于是
通過 xsltproc report.jtl > test.html，或者 ant 也可以。這個命令把Jmeter 的結果文件轉換為 HTML 的報告。結果如下：
這里雖然能生成 HTML 報告了，但是這個報告太弱了，基本不能用，包含的參數太少。所以需要對這個報告進行擴展。因為 Jmeter 本身的聚合報告的數據還是比較全的，
因此打算按照那個報告的值進行擴展。
xsltproc，xlst介紹
XSL 指擴展樣式表語言（EXtensible Stylesheet Language），把 XML 轉換為HTML 用的就是 xls 編寫的樣式表，所以如果要擴展這個報告，首先要對 xls
熟悉，才能更改和擴展樣式表。可以在http://www.w3school.com.cn/xsl/index.asp這里進行此語言的學習。
xsltproc 是一個快速 XSLT 引擎,它可以將通過 XSL 層疊樣式表把 XML 轉換為相應格式的文件，比如：HTML,XHTML,PDF
比如將 XML 轉換為 HTML，使用格式如下：
xsltproc xsl-html.xsl hoto.xml -o html.html （這里還可以直接把樣式表文件寫入 jtl 文件的 href 屬性中，直觀的告訴這個 XML 用哪個樣式表）
xls 中查找 XML 用的 xpath，因此還需要對 xpath 熟悉，xsltproc 這個引擎用的是 xpath1.0 版本，因此在樣式表中使用 xpath 是不能使用 xpath2.0 的函數
和一些屬性。
個人對 xpath 還算熟悉，但是對 xls 一點也不熟悉，沒辦法為了能夠擴展報告，直接學習 xls 和 xpath。（關于 xls 會再寫一遍博客介紹，順便把使用過程中
的問題和經驗匯總）
如果直接使用 ant 和 Jmeter 集成后也是可以直接生成的，但是 ant 轉換 HTML 的引擎也是只支持 xpath1.0，后來經過了解大部分的引擎都不支持xpath2.0，所以
期中不能使用 xpath2.0 的函數。
90%Line 時間
為了能夠顯示 90%Line 的時間，首先要對這個指標熟悉，這個指標值得是一組數據，在 90% 的位置的數據的時間，所以我們擴展的時候只要知道了 90%
位置的索引，那么就能取得這個值了。
以下是部分關鍵代碼
這里主要是獲得時間元素的集合，以及 90%line 的位置，有了這兩個參數后就可以進行后續的擴展了，擴展后的效果圖如下：
因為 90%Line 和 95%Line,99%Line 計算原理都是一致的，因此只要計算出一個值其他的值也很好計算
QPS 擴展
Jmeter 的具合報告有 Throughput 這個值，這個在 loadrunner 中是表示為吞吐量的，這里可以表示 QPS 或者 TPS（在使用了事務的情況下），個人把這個稱為 QPS，因為更直觀。
和 %90Line 同樣的道理，首先必須知道這個值是怎么計算出來，經過查找資料和官網的比較，發現這個值是通過如下的公式計算出來的：
官網的截圖：
Throughput = (number of requests) / (total time)
total time = 測試結束時間 - 測試開始時間
測試結束時間 = MAX(請求開始時間 + Elapsed Time)
測試開始時間 = MIN(請求開始時間)
知道了公式，那么計算就容易了，以下是關鍵代碼：
擴展后的結果如下：
吞吐量擴展
在 loadrunner 中吞吐量就是 Throughput，在 Jmeter 的聚合報告中最后一列的值就是 loadrunner 中的 Throughput，為了便于區分，我把這里的值稱為Throughput，
也就是吞吐量。
經過查找資料發現吞吐量的計算和 QPS 的計算公式是一樣的，因為也就是如下的公式：
Throughput = (請求的總字節數) / (total time)
這里的 total time 計算和 QPS 是一樣的，而總字節數直接把所有請求的加起來即可，關鍵代碼如下：
因為這里顯示的字節，最后的結果我打算以 KB 的單位顯示，因此這里需要除以1024，擴展后的結果如下
TPS擴展
TPS 在 Jmeter 中雖然某些情況和 QPS 是一致的，但是還是有不一致的地方，因此這里也需要擴展，這樣的結果看著更清晰明了。
首先和其他的參數擴展一樣，需要知道計算公式，這里的計算公式和 QPS 也是一樣的，只是數據的集合不一樣，以下是擴展后的效果。
在擴展的過程中進一步發現 Jmeter 的聚合結果中最后的”總體“一行在某些情況下計算的數值是不準確的。如果腳本中不包含事務，那么這里的結果是準確的，如果都包含事務并且把
Generate parent sample 選中后這里的結果也是準確的，在腳本中有事務并且沒有選中 Generate parent sample，或者有些有事務有些沒有時，這時的結果就不準確了，因為查看計算
方式發現它把所有的請求都算進去了。
比如，一個 jtl 文件中即包含 HTTP 請求也包含事務，因為事務只是對之前請求的一個統計，本身是不發送請求的，所以計算總的吞吐量、QPS，TPS 時是不能這么算的。
所以在擴展的過程中分成了兩個樣式表，一個樣式表處理包含事務，或者沒有事務的情況，這時的結果以 QPS 衡量；一個樣式表處理全都是事務的情況，這時候的結果以 TPS 衡量，這樣
就準確了。
測試
擴展了好幾個指標，這些指標的正確性如何呢？需要在多種情況下進行測試，經過測試后各個指標都是正確的。但是還沒有在大的數據量級別下測試，如果測試后發現哪里會有問題，會及時
更改。
切記：由于樣式表中是按照 lb 進行請求區分的，因此這里的 lable 不能重復，本身也不應該重復，包括 Jmeter 的聚合報告都是以 lable 進行區分的
PS：在擴展過程中的難點一是公式如何計算的，二是xls這個 指擴展樣式表語言不是很熟悉，本身也有很多限制，會在下個博客中說明。但是用過后感覺還是很不錯的既熟悉了 xpath 還熟悉了 xls。
三是需要對 Jmeter 的測試結果文件每個字段戴表什么意思熟悉，這樣才能定制更多的指標，這個也會在多帶帶的博客中說明
OneAPM Mobile Insight 以真實用戶體驗為度量標準進行 Crash 分析，監控網絡請求及網絡錯誤，提升用戶留存。訪問 OneAPM 官方網站感受更多應用性能優化體驗，想閱讀更多技術文章，請訪問 OneAPM 官方技術博客。
本文轉自 OneAPM 官方博客
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/49750.html
