Jmeter 添加CSV Data set config 文件的相對路徑及編碼在Windows和Linux下的兼容性(轉)

簡介： 

Jmeter其實是不須要安裝的，只須要有ApacheJMeter.jar、啓動批處理文件（jmeter.bat或jmeter）、配置文件（jmeter.properties、user.properties、saveservice.properties等）、lib文件（一堆的jar包）就足夠在Windws和Linux下運行了，純綠色而且是輕量級的（總共不到50M就夠用了）。另外Jmeter各個版本中，首先推薦的是Jmeter3.1版本，由於它足夠新，並且同時兼容JDK1.7和1.8（但要注意的是，Server端和Client端仍是應該保持統一版本的JDK），更高的版本就再也不支持JDK1.7了。

       既然Jmeter能同時在Windws和Linux下運行，那麼咱們還須要注意什麼呢？有兩點，一是路徑關係及路徑符號，二是字符集編碼，解決了這兩個問題，咱們就能將Windows下調試經過的Jmeter包（包括jmx腳本）所有複製到Linux下並直接就能夠用jmeter啓動文件調用jmx腳本跑起來，甚至連輸出jtl報告、CSV報告、html報告都能徹底兼容。

1、路徑問題

一、相對路徑

      Jmeter的相對路徑是指腳本所對應的目錄：

    1.1 如同目錄下java輸入 ./test.cvs  ，Jmeter直接輸入文件名test.cvs，沒必要輸入 ./

   1.2 如子目錄下 dataFiles\測試數據.csv

 

   1.3 如上級目錄下  ..\dataFiles\測試數據.csv

 

 

 

這個路徑就表示，ID.csv文件對應的絕對路徑是D:\testJmeter\dat\ID.csv。

一樣若是Beanshell中引用了Java的相對路徑以下：

那麼就表示對應的絕對路徑是D:\testJmeter\etlCount.java

二、以上舉的例子是在Windows下的，到了Linux下就會報錯，這是由於Linux識別路徑的符號不是反斜杆"\"，而是正斜槓"/"，並且windows下兼容性是最好的，不管正反斜槓都能識別，因此咱們filename應該改成dat/ID.csv，一樣source引用java文件，也能夠改爲以下：

三、第三個問題，也就是jmx腳本文件到底應該放哪比較好，雖然以上的相對路徑可以解決換電腦後不須要修改文件路徑了，但仍是不夠可靠，這是由於jmeter執行文件是在bin目錄下的，不少時候程序默認是以jmeter的bin目錄爲根路徑的，若是參數文件或是java文件的相對路徑不是以bin爲開始目錄，極可能在分佈式測試時，就出現遠程代理機所調用的文件路徑與本地腳本不一致。

      因此最好的方式是，將jmx腳本統一放在bin目錄下，而後參數文件或是source文件再以腳本的相對路徑進行匹配。好比參數文件的絕對路徑爲：D:\testJmeter\bin\dat\ID.csv，這樣相對路徑還會是dat/ID.csv，那麼換任何一種環境，或是用任何一種方式調用（好比經過Ant調用）都能保證找到一致路徑下的文件。

      同時，還要確保全部被調用的jar放到lib/ext目錄下（其實放到lib目錄下也行），這樣就不須要配置jar的路徑了，程序會自動找到這個目錄並調用jar包。

總結：相對路徑只是爲了方便代碼或腳本的遷移，而將腳本放到bin目錄下，只是方便默認路徑的引用，不然就要經過配置環境變量（如export）或是在build.xml中配置好jmeter的執行目錄、根目錄才能保證路徑的正確性。

四、另外咱們在編碼過程當中，也有意識的多用一些相對路徑（不少程序都具備這樣的功能，這能爲咱們省掉一些麻煩），以下：

 

/**
   * 得到excel文件的路徑
   * @return
   * @throws IOException
   */
  public String getPath(String fileName) throws IOException {
      File directory = new File(".");
      sourceFile = directory.getCanonicalPath() + "/DataSource/"
              + fileName + ".xls";
      return sourceFile;
  }

 

 

2、字符編碼問題

      只要是在咱們的參數文件或是java文件中使用了中文，就避免不了編碼兼容性的問題。咱們常常會碰到在Windows下編輯好的文件，到了linux下就顯示中文亂碼，甚至經過Jmeter輸出的日誌、發送的請求都成了亂碼。

      解決這個問題的最好方式，是統一編碼，通常咱們都是統一採用UTF-8編碼，或者在Linux環境中安裝部署更多的中文支持包。

      若是當咱們的參數文件或是Java文件在Linux下讀取時出現亂碼，咱們最簡單的一種方式是用在Windows下用編輯器（如UltraEdit）另存爲無BOM的UTF-8格式，記住是無BOM的，不然到了Linux環境就會出現編譯錯誤（若是純粹只寫不讀取的文件，是否帶BOM頭就無所謂了）。從這點來講，Windows對編碼格式的處理要比Linux兼容性強（開源的東西，老是要到處踩着坑才能過去）。

      關於Jmeter的編碼問題，能夠參照個人另外一篇文章 http://blog.csdn.net/smooth00/article/details/70236638

      須要說明的是jmeter響應數據默認編碼格式是ISO-8859-1(向下兼容ASCII，自身不顯示中文，依賴於平臺的編碼來顯示中文)，Windows默認保存的文件編碼格式是ANSI/ASCII（但Windows默認以GBK來顯示中文），而在Linux咱們一般默認以UTF-8編碼格式來顯示中文。因此這三者若是能統一的話，就能夠避免亂碼顯示。另外就是不少網站是以UTF-8或gb18030(GBK)編碼來顯示中文的，經過Jmeter來發送郵件時最好注意一下Web展現方面的問題。

      jmeter的配置文件jmeter.properties中能夠修改sampler響應數據的編碼：

 

# The encoding to be used if none is provided (default ISO-8859-1)
#sampleresult.default.encoding=ISO-8859-1

 

     也能夠經過後置處理器BeanShell PostProcessor來修改顯示的編碼：

 

      若是咱們不想麻煩，就是說不肯意去花時間統一linux和windows的中文編碼，那麼除了上面提到的手動將文件（如etlCount.java）另存爲UTF-8 -無BOM格式，再傳到linux中運行的方法，也能夠寫個批處理，將從windows傳過來的文件強制轉爲UTF-8格式，具體你們能夠靈活應用：

 iconv -f gbk -t utf-8 etlCount.java >etlCount.java.bak

 mv -f etlCount.java.bak etlCount.java

      最後再說一種狀況：一樣是utf-8格式，Linux下建立的文件是不帶BOM頭的，那麼到Windows下用相關軟件好比Excel打開就會顯示亂碼，實際上Excel支持utf-8的中文顯示，只是由於沒有BOM頭，因此致使格式判斷和識別錯誤。解決的辦法就是在Java中生成csv之類文件的時候，強制加上BOM頭（(byte)0xEF, (byte)0xBB, (byte)0xBF）：

 

File file = new File("output.csv");
OutputStream out = new FileOutputStream(file);
out.write(new byte[]{(byte)0xEF, (byte)0xBB, (byte)0xBF});
out.write("date,CountName,業務庫,數據中心,國家庫,result\r\n".getBytes());
out.close();

View Code