一：操作
或者
增加用戶數的方法
一：僅對單個場景增加用戶數
二：同時對多個場景增加用戶數
第一步：
第二步：
二：腳本編寫示例
Action()
{
int nHttpRetCode;
web_reg_save_param("ResponseBody", "LB=", "RB=", "Search=Body", LAST);
web_save_header(RESPONSE,"ResponseHeader");
lr_start_transaction("activity");
web_custom_request("get_test",
"URL=http://192.168.1.249:8088/mobile2/activity/list.json?resultType=0&userType=3",
"Method=GET",
"Resource=0",
"Referer=",
"Mode=HTTP",
"EncType=text/html;charset=UTF-8",
"Body=",
LAST);
lr_end_transaction("activity", LR_PASS);
//打印返回信息
lr_output_message("# 響應頭信息：\n %s", lr_eval_string("{ResponseHeader}"));
//lr_output_message("# 響應原始內容體：\n %s", lr_eval_string("{ResponseBody}"));
lr_convert_string_encoding(lr_eval_string("{ResponseBody}"),LR_ENC_UTF8 ,LR_ENC_SYSTEM_LOCALE,"ResponseBodyUTF8");
lr_output_message("# 響應解碼后內容體：\n %s", lr_eval_string("{ResponseBodyUTF8}"));
//獲取服務器http響應碼
nHttpRetCode = web_get_int_property(HTTP_INFO_RETURN_CODE);
if(nHttpRetCode == 200)
{ lr_output_message("Success!"); }
else
{ lr_output_message("Failed! "); }
return 0;
}
三：測試報告查看
關注：
Transaction: Transaction Name 事務名稱
Minimum 最小值
Average 平均值
Maximum 最大值
Std. Deviation 標准方差值
90 Percent 90% 響應時間
報告講解：
1、90 Percent響應時間：表示該組中90%的用戶都能在該時間內響應（完成該操作） 90 Percent 表示90%的用戶在 0.xxx 秒內完成操作 可以通過Properties中 Percentile 90 可以修改 -> Additional Settings -> Transaction Percentile 若改為80，表示80%的用戶。 再改回90%
2、一個事務，100用戶執行，其中一個用戶執行時間1000秒，其他99%的用戶響應時間為0.001秒。 則該情況下90% 和 平均響應時間 哪個更准確？ 90 Percent
3、標准方差值：越小越好。越趨近於0，表示所有用戶執行該事務的響應時間越接近，表示系統越穩定。
（數學中知識）
Mininum Average Maximum Std.Deviation
0.203 0.313 0.404 0.095
說明前面幾個值比較接近，比較穩定。
4、網絡帶寬充足的情況下，當吞吐量（Throughput）隨着點擊率（Hits per second）的升高而升高，說明AUT的服務器處理能力充足。
四：測試報告導出
- 2
就會彈出了下拉菜單中進行選擇為”new report“選項。
- 3
然后就會在new report中進行填寫為general、format、content進行在其中內容根據的需要進行填寫，然后進行點擊generate。
- 4
然后就會彈出了一個word的文檔的格式選項。進行對當前的word文檔進行保存到本地的位置中，進行點擊菜單中的“save”的選項。
- 5
彈出了一個下拉的菜單中進行選擇為“Microsoft word 2007 file”的選項。
- 6
然后就會彈出了export settings的選項框，可以直接點擊OK。
- 7
進行選擇為本地電腦的報告位置。
- 8
word可以在本地電腦中找到該文件的報告，說明的是文件導出成功的。
生成html形式報告
五：測試結果分析
1. LoadRunner測試結果分析的第一步應該是查看分析綜述（Analysis Summary），其包括統計綜述（Statistics Summary）、事務綜述（Transaction Summary）、HTTP 響應綜述（HTTP Responses Summary）三部分。在統計綜述中查看Total Errors的數量，HTTP 響應綜述中查看HTTP 404數量，若數值相對較大（HTTP 404則相對於HTTP 200），則說明系統測試中出錯較多，系統系能有問題；另外查看事務的平均響應時間和其90%的事務平均響應時間，若時間過長，超過測試計划中的要求值，則說明系統的性能不滿足我們的要求。
2. 第二步對LoadRunner測試結果圖進行分析，首先對事務綜述（Transaction Summary）進行分析，該圖可以直觀地看出在測試時間內事務的成功與失敗情況，所以比第一步更容易判斷出被測系統運行是否正常。
3. 接着分析事務平均響應時間（Average Transaciton Response Time），若事務平均響應時間曲線趨高，則說明被測系統處理事務的速度開始逐漸變慢，即被測系統隨着運行時間的變化，整體性能不斷下降。當系統性能存在問題時，該曲線的走向一般表現為開始緩慢上升，然后趨於平穩，最后緩慢下降。原因是：被測系統處理事務能力下降，事務平均響應時間變長，在曲線上表現為緩慢上升；而並發事務達到一定數量時，被測系統無法處理多余的事務，此時曲線變現為趨於平穩；當一段時間后，事務不斷被處理，其數量減少，在曲線上表現為下降。如果被測系統沒有等待機制，那么事務響應時間會越來越長，最后系統崩潰。
4. 再分析每秒通過事務數（Transactions per Second/TPS），該曲線表示被測系統在運行的任意時刻，每個事務通過、失敗的情況，其是考查系統性能的一個重要參數。若隨着壓力的增加，曲線如果開始變化緩慢或有平穩的趨勢，則有可能是服務器開始出現瓶頸。
[5]. 分析每秒通過事務總數（Total Transactions per Second），該曲線顯示在任意時刻被測系統通過的事務總數、失敗的事務總數。該曲線走向和TPS曲線走向一致。
[6]. 事務性能摘要（Transaction Performance Sunmmary）該曲線表示被測系統中所有事務的最小、最大和平均事務響應時間。
[7]. 事務在負載情況下的響應時間（Transaction Response Time Under Load），該曲線表示在不同數量的虛擬用戶情況下的事務響應時間情況。該圖對分析具有漸變負載的測試場景比較有用。
[8]. 事務響應時間（百分比）（Transaction Response Time（Percentile）），該曲線可以容易地分析出在給定的響應時間范圍內事務量的百分比重。
[9]. 事務響應時間（分布）（Transaction Response Time(Distribution)），該圖可以容易地分析出在給定響應時間范圍內的事務量情況。
其實，若並不是十分詳細地分析測試結果，第4步與第5步選其一分析，第6步、第7步、第8步為可選項，因為在第1步就在一定程度上分析了，而第9步又與第8步功能相識。LoadRunner生成測試結果圖在很大的程度上具有一定的重復性，只不過是在不同情況下的具體顯示。
六：優化調整
（1）Tomcat conf文件夾下的server.xml
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
URIEncoding="UTF-8"
enableLookups="false"
disableUploadTimeout="true"
acceptCount="500"
maxThreads="500"
seURIValidationHack="false"
redirectPort="8443" />
（2）tomcat bin目錄catalina.sh增加
JAVA_OPTS='-server -Xms1024m -Xmx1024m'