簡介：
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
2、以上舉的例子是在Windows下的，到了Linux下就會報錯，這是因為Linux識別路徑的符號不是反斜桿"\"，而是正斜杠"/"，而且windows下兼容性是最好的，無論正反斜杠都能識別，所以我們filename應該改為dat/ID.csv，同樣source引用java文件，也可以改成如下：
3、第三個問題，也就是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的執行目錄、根目錄才能保證路徑的正確性。
4、另外我們在編碼過程中，也有意識的多用一些相對路徑（很多程序都具有這樣的功能，這能為我們省掉一些麻煩），如下：
- /**
- * 獲得excel文件的路徑
- * @return
- * @throws IOException
- */
- public String getPath(String fileName) throws IOException {
- File directory = new File(".");
- sourceFile = directory.getCanonicalPath() + "/DataSource/"
- + fileName + ".xls";
- return sourceFile;
- }
二、字符編碼問題
只要是在我們的參數文件或是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();