200个不同用户登陆结果分析
Loadrunner测试结果分析如下：
1、
Summary（场景摘要）结果及分析如下：
Secenario name 场景名称 Results in session 场景运行的结果目录
Duration 场景运行时间 Maximum running vusers（场景最大用户数）
Total throughput （bytes）（总带宽流量） Average throughput （bytes/second） （平均每秒宽带流量）Total hit（总点击数）Average hits per second（平均每秒点击数）
图 1-1
此次测试我用了200个用户，163个passed，所以实际参与测试的虚拟用户总共有163个。其中，总的吞吐量为535484969bytes，平均吞吐量为1459087bytes，总的请求量为12321，平均每秒请求量为33.572，错误共有37个。从该图可以看出，该网页在用户登陆方面存在问题。
图 1-2
图 1-3
（注： Action.c(92): Error -27796: Failed to connect to server "61.177.55.188:8080": [10060] Connection timed out.
Action.c(104): Error -27727: Step download timeout (120 seconds) has expired when downloading resource(s). Set the "Step Timeout caused by resources is a warning" Run-Time Setting to Yes/No to have this message as a warning/error, respectively.
Error: missing newline in D:\Program Files\HP\LoadRunner\tutorial\账户登陆1\Name.dat）
2、Running Vusers结果及分析如下：
图 2-1
通过上面图形结果可知，在刚开始虚拟用户为100个，11s左右时达到200个，从1min45s后逐渐减少，6min7s左右时用户全部退出访问。
3、Hits per Second（每秒点击数）结果及分析如下：
每秒点击数每一次点击相当于对服务器发出一次请求，一般点击数会随着负载的增加而增加，该数据越大越好
图 3-1
该图为每秒点击次数，即是运行场景过程中虚拟用户每秒向Web服务器提交的HTTP请数。通过它可以评估虚拟用户产生的负载量，如将其和“平均事务响应时间”图比较，可以查看点击次数对事务性能产生的影响。通过对查看“每秒点击次数”，可以判断系统是否稳定。系统点击率下降通常表明服务器的响应速度在变慢，需进一步分析，发现系统瓶颈所在。
由上图不难看出：在5s、15s两个时间点点击数最大，在15s、1min17s、2min40s、4min、4min32s时间点点击数也处于最大值，数值变化非常大。
4、 Througput（宽带使用）结果分析如下：
该数据越小说明系统的宽带依赖越小
图 4-1
此图和可以看出：分别在15s、1min38s、2min8s、2min46s、4min、4min15s、4min46s这几个时间点吞吐量最大，而且全过程数值起伏较大，这不难看出是由于点击数引起的。
5、HTTP Responses per Second 结果分析如下：
图 5-1
该图显示运行场景过程中每秒从Web服务器返回的不同HTTP状态代码的数量，还能返回其他各类状态码的信息，通过分析状态码，可以判断服务器在压力下的运行情况，也可以通过对图中显示的结果进行分组，进而定位生成错误的代码脚本。通过该图看出：紫色线条的HTTP状态代码的数量比较大，即网络服务器的压力较大。
6、Error statistics结果分析如下：
图 6-1
由图可以看出系统运行中的错误所占的比例为16.22% of 37。
7、Errors per second结果分析如下：
图 7-1
反映登录用户的错误数据，该图中没有数值，说明在此方面比较好。
8、Vuser Summary 结果分析如下：
图 8-1
由该图不难看出：虚拟用户通过的占81.5%，所以用户运行有错误。
9、Average Transaction Response Time结果分析如下：
图 9-1
从上图不难看出：这是评价反应时间，数据变化大，3min12s数据下降，3min28s降到最小值后数据又开始上升。
10、Transaction per Second结果分析如下：
图 10-1
从上图不难看出：系统执行速度不稳定，有起伏。
11、Total Transaction per Second结果分析如下：
图 11-1
由上图不难看出：正常用户分别在1min20s、1min45s、2min31s、3min11s、3min52s、4min40s、21s、23s、26s、28s、31s时有响应，其他时间没有响应。
12、Transaction Performance Summary结果分析如下：
图 12-1
从上图可以看出各个页面请求的最大为0.498、最小为43.763、平均响应时间为115.687。
13、Transaction Response Time结果分析如下：
图 13-1
从上图不难看出：响应时间的变化情况。
14、Transaction Response Time结果分析如下：
图 14-1
通过该图可以看出该服务器性能是否在可以接受的范围内。
15、Connections 结果分析如下：
图 15-1
连接点的变化，在运行刚开始数值为0，后数值渐渐变大，达到最大值810后趋于稳定，但又下降的趋势。
16、Connection per second 结果分析如下：
图 16-1
体现出每秒连接点的变化情况，前50s变化度比较大，之后较为平稳。
17、综述：
在进行200个不同用户同时登陆时，在用户登陆方面共出现了37个fail和38个error,在时间点方面共有363个passed和20个failed该系统还需做略微的改进。
第二篇：Loadrunner 接口测试的两种方法
请求报文格式： <?xml version="1.0" encoding="ISO-8859-1"?>
< Publish >
<SNSID>123</SNSID>
<UserID>456</ UserID>
<CommentsTypeID>2</ CommentsTypeID>
<CommentsID>123</CommentsID>
<AuthorID>456</AuthorID>
<CommentsContent>Don't forget the meeting!</CommentsContent>
</Publish>
有了上述的说明书之后，测试人员可以根据文档的描述在LoadRunner书写相应的接口测试脚本。 LoadRunner中涉及到向服务器发送请求的API方法包括：web_url()，web_submit_form()，web_submit_data()，web_custom_request()。下面介绍两种我常用的方法：
方法一：使用web_submit_data()
web_submit_data("insert",
"Action=http://116.211.23.123/SNS/Publish.htm ",
"Method=POST",
"Referer=http://116.211.23.123/SNS/Publish.htm ",
"Mode=HTML",
ITEMDATA,
"Name= SNSID ","Value=6601",ENDITEM,
"Name= UserID ","Value=123",ENDITEM,
"Name= CommentsTypeID ","Value=1",ENDITEM,
"Name= CommentsID ","Value=456",ENDITEM,
"Name= AuthorID","Value=789",ENDITEM,
"Name= CommentsContent ","Value=Just for testing",ENDITEM,
LAST);
方法二：使用web_custom_request()
char str[1000];
strcpy(str,"SNSID=7999&UserID=1&CommentsTypeID=1&CommentsID=1&AuthorID=1&CommentsContent=1");
web_custom_request("Publish",
"Url= http://116.211.23.123/SNS/Publish.htm",
"Method=POST",
"Referer=http://116.211.23.123/SNS/Publish.htm ",
"Mode=HTTP",
str,
LAST); 这也是一种写法，可以跟web_submit_data互换。这种写法更利于拼接参数。
方法一适合一些xml结构的根元素下的子元素同处于根元素下面，且子元素数目较少的情况下，如果xml结构比较复杂，比如说根元素下面有多级子元素，或者xml树结构分叉较多的时候，我们可以先把xml拼接成一个字符串然后通过web_custom_request()向服务器发送请求。
我们在做接口功能测试的时候会很注意接口的应答报文的信息，这时候我们可以通过LoadRunner的日志信息查看或者可以通过web_reg_find()或者web_find()这样的API函数来统计接口的运行结果，推荐使用web_reg_find()，web_reg_find()和web_find()区别请大家百度一下，详细信息太多，在这里不便叙述。
因为web_reg_find()是注册型函数，所以应该放在web_submit_data()或者web_custom_request
()的前面。
如：
web_reg_find("Text=<StatusCode>0</StatusCode>",//应答报文里边的信息
"SaveCount= StatusCodeCount", //统计查询字段的信息，如果找到值为1，如果未找到值为0
LAST);
在脚本的最后我们可以对查询字段的信息进行统计
// Check result
if (atoi(lr_eval_string("{StatusCodeCount }")) > 0){ //判断如果Welcome字符串出现次//数大于0
lr_output_message("Send out the comment successfully."); }//在日志中输出Send out //the comment successfully
else{ //如果出现次数小于等于
lr_error_message("Send out the comment unsuccessfully."); //在日志中输出Send out //the comment successfully
return(0);
} 总结：用LoadRunner做接口测试无法做到把接口参数和程序分理，接口的参数可以通过参数化的方法来实现对同一个参数多个数据的测试。参数化后的测试数据保存在此脚本的保存位置下。
方法二、通过Java + Fitnesse实现接口功能测试
什么是Fitnesse？
FitNesse是一套软件开发协作工具 FitNesse是帮助大家加强软件开发过程中的协作的工具。能够让客户、测试人员和开发人员了解软件要做成什么样，帮助建议软件最终是否达到了设计初衷。
FitNesse是一套软件测试工具 从另外一个角度看，FitNesse是一个轻量级的、开源的框架，能够帮助开发团队方便的定义验收测试（Acceptance Tests），通过在web页面上简单的输出和预计输出的表格就可实现，并且可以运行这些测试以确定是否通过。
FitNesse是wiki可以很方便的创建和编辑页面 FitNesse是一个web服务器不用过多的安装配置，很方便使用。
我习惯使用Eclipse集成开发工具写测试代码，用fitnesse准备接口的测试数据，由此实现接口的测试数据和测试程序的分离。
关于Fitnesse的使用大家可以参考官方网址。Fitnesse的四种常见表格是：
ColumnFixture，ActionFixture，Decision Table，ScriptTable。在工作中ColumnFixture用的最多。
下面的程序使用的是ColumnFixture表格。
// Java fixtures
package info.fitnesse.fixturegallery;
import fit.ColumnFixture;
public class PublishTest extends ColumnFixture {
//通过url向服务器发送请求的程序段省略
public StringSNSID; //对应列名|first part|
public StringUserID; //对应列名|second part| private StringCommentsTypeID;
private StringAuthorID;
private StringCommentsContent;
private StringUserID;
//对参数的set和get方法省略
}
ColumnFixture表格里边的测试数据是：
//省略设置表格的存储位置信息
总结：上述两种方法都是对接口做功能测试的方法，使用LoadRunner做接口测试的时候可以不用让开发人员提供测试人员相应的UI测试页面，直接调用接口做测试，但是测试程序和数据的依赖性太强；使用Fitnesse做接口测试的时候可以实现测试程序和数据的分离，只用点击Fitnesse界面的Test按钮就可以实现测试，测试消耗时间比使用LoadRunner做接口测试少。
以上纯属个人见解，敬请拍砖！