第一步：獲取開發文檔，了解接口地址和參數名
第二步：jmeter中添加需要測試的接口
a.設計APP的接口框架：
b.http請求默認值設置如下：
- c.接口中應需要用到sign字段，加密字符串與時間戳，所以需要自己編寫加密的代碼。
在eclipse中編寫需要加密的代碼，調試成功后，在elipse中到處jar包
將導出的jar放到Jmeter安裝目錄下的lib文件夾下；
因為sign字段是由：時間戳+$+key加密而成，所以我們先需要獲取時間戳：
因為所有接口中的sign規則相同，所以將需要的3個字段在測試計划中添加即可
添加完成后，在jmeter中添加beanshell Sampler，導入該jar包，將需要的字符串引用該方法即可,首先定義各個字符串，將字符串拼接后引用加密的方法，加密后的字符存到sign1中，設計如下：
在接口中引用該sign1字段：
d.接口的請求參數值需要從數據庫中隨機獲取，那么設計如下：
添加JDBC Connection Configuration設置
再添加JDBC Request，首先需要將JDBC Connection Configuration中的
與jdbc Request中的
設置相同；然后將從數據庫中獲取需要的參數值，將所有的數據存儲到result對象中，
在BeanShell中獲取存儲id值的對象，並隨機讀取
在請求參數中引用，sign與times獲取方式如上設置一致，id的字段即從數據庫中隨機獲取的值；
調試無問題后，設置查看結果：
監控測試的服務器需要用PMC
在測試服務器中加入
在測試服務器中linux服務器上首先將startAgent.sh設定為可執行文件：
啟動服務后，再進行壓力測試。
因為壓力測試，需要分布式壓力測試：
e.點擊“全程啟動”進行壓力測試，再對結果進行分析：
聚合報告分析
- Label：httpRequest name屬性值。
- Samples：測試的過程中一共發出了多少個請求即總線程數，（如果模擬10個用戶，每個用戶迭代10次，這里就顯示100），對應圖形報表中的樣本數目。
- Average：單個Request的平均響應時間，計算方法是總運行時間除以發送到服務器的總請求數，對應圖形報表中的平均值。
- Median：50%用戶的響應時間。
- 90%Line：90%用戶的響應時間。
- Min：服務器響應的最短時間。
- Max：服務器響應的最長時間。
- Error%：本次測試中出錯率，請求的數量/請求的總數。
- Throughput：吞吐量，默認情況下表示每秒完成的請求數。
- KB/Sec：每秒從服務器接收到的數據量，即每秒鍾請求的字節數，時間單位均為ms。
根據聚合報告以及圖形結果各項參數指標分析
（1）每間隔一秒鍾並發的線程數越多，接口99%Line參數值先增加后減小，多少個線程時基本達到峰值；
（2）每間隔一秒鍾並發的線程數越多，吞吐量先減后增，每秒鍾完成的請求數減幅較大。
據圖形結果分析
（1）隨着發送到服務器的請求數越來越多，偏離數量越來越大，服務器越來越不穩定；
（2）發送到服務器的請求數增加，吞吐量（即服務器每分鍾處理的服務器的請求）先減少后增加。
一般情況下，當用戶能夠在2秒以內得到響應時，會感覺系統的響應很快；當用戶在2-5秒之間
得到響應時，會感覺系統的響應速度還可以；當用戶在5-10秒以內得到響應時，會感覺系統的
響應速度很慢，但是還可以接受；而當用戶在超過10秒后仍然無法得到響應時，會感覺系統糟
透了，或者認為系統已經失去響應，而選擇離開這個Web站點，或者發起第二次請求。