最近很有幸被外派到HW做项目，接触了一个月性能测试，是HP性能专家带对，顺便学了一点规范，与大家一起分享，有不妥或遗漏的地方，请大家帮忙更正或补充下，3Q
脚本录制看似简单，貌似有很有些讲究.....
1.一个脚本应该有登陆、流程操作、登出的过程....
2.脚本录制时：vuser_init用于放登陆，action用于放操作，vuser_end用于放登出.....
3.在录制时，点击每个按钮，均最好注释，最好不要在录制后进行注释，以免注释代码对应的操作出差错，确保在脚本录制完成后，开发人员或其他测试人员能明确地区分各个操作执行时代码的模块....
4.可以设置多个action,如录制查询时，单条件查询：用名字查询设置为一个action，组合条件查询：组合查询设置为另一个action，但action的名字最好有意义....
5.录制时，操作应该简洁明了，鼠标最好不要在页面到处移动，因虽在页面未进行任何操作，但在移动时，可能与后台进行了 交互（客户端与服务端发生交互，产生请求）
6.录制时，尽量不点击页面的上下左右滚动条....
7.录制与回放的场景应一致，（如：录制时分辨率为1024X762，则回放时也为1024X762）
8.录制脚本时，最好先手工执行一次完整的流程，确保在录制中无多余或无效操作，以免关注点不在业务上或加重压力...
9.录制脚本应该有始有终，即录制开始的界面与录制结束的界面最好一致，例业务流程：创建A->提交A->操作成功提示，录制的流程应为创建A->提交A->操作成功提示->返回创建A的页面，如：当录制的流程为创建A->提交A->操作成功提示，当结束后，回放，脚本回放时，可能找不到创建A的链接Link，出现报错
10.录制后，如要重新录制，只需点击暂停，再点击开始录制即可，不需要更改录制时的配置，因为lr将录制设置参数保存在action中
11.录制完成后，应马上保存，注：保存时，应该在录制完，且运行完成，否则保存时提示失败
12.脚本最好将用户名与密码参数化，

1.脚本无语法错误，
2.脚本回放或运行后，系统产生真正的进行了操作，例:回放添加A的脚本，则在真实系统中产生A,
3.当一个曾录制并调优成功的脚本，回放脚本突然报错，则手工验证系统，以排除当前环境是否正常，或更改页面等，
4.脚本登陆出错，主要关注界面是否变化，用户名参数化，验证码是否为动态，（注：验证码产生压力较小，故测试时设置为静态）
5.脚本回放或场景运行时，提示检查点找不到，要关注页面是否已更改，切忌因检查点找不到而注释该检查点，（因不检查该检查点，虽不会报错，但系统并没有真正操作，故没有产生压力）
6.脚本回放或场景运行时出错，或系统并未真正操作，要关注：该关联的地方是否已关联，关联是否正确（如:用查出的合同作为输入条件，生成B，一个合同对应一个id,则该合同进行关联），或参数化是否正确，该参数化的地方是否已参数化（如：添加A的名字不能同名，故不能用同一参数）
7.用5个用户并发，关注pass的数量，看是否通过，当不通过时，且手工检查，重现该问题，则为系统问题，暂排除脚本问题
8.运行时出现错误，查看log日志，日志保存在结果文件下，查看日志快捷方法：ctrl+F,输入error,
9.场景运行时报错，要关注是一个用户报错还是多个用户报错，如：运行时，连续报错，故可以先停止报错用户，看是否还会继续报错，如果会则找其他原因，如果不会，则重现运行该用户（注：当一个用户登陆出现失败后，则后面的操作会连续报错，

事务：在脚本中定义的某段操作，是一段脚本语句，可以将其整个脚本定义事务
插入事务时应注意：
1.找准插入是事务的开始位置与结束位置，系统从起点计时，结束点结束计时，
2.事务的作用：系统自动记录事务的运行时间等性能数据，在脚本运行完毕后，系统会在结果信息中单独反映每个事务运行结果，
3.插入事务可在录制时进行，也可录制完成后进行，建议在完成后进行
4.插入事务千万要插入正确，（在HW做Po打通时，被HP专家叼了一下，不过叼得值，呼呼）
事务的一般标志为web_sumbit_data,但有特殊情况，如有的事务可能会与服务器发生多次交互：提交按钮+返回主页面：URl+sumbit
注：比较方便且不容易出错的方法:
在录制时，每操作一个步骤前，先插入一个注释，
优点：1.方便本人或其他人维护脚本时，很容易看出那个步骤从哪里开始到哪里结束
 2.方便插入事务，即插入事务的开始标志为：第一个注释后，结束为：第二个注释前
3.插入事务时，最好将思考时间移到事务外面，以免测试不准确，

实际案例一：
1.添加无销售合同B时，发现点击提交的事物响应时间十分慢，单用户单循环大于10秒
业务流程：填写基本信息，点击提交按钮
问题发现：并非是提交产生的事物慢，而是提交成功后到刷新到主页面的时间较慢，因数据关联太多引起
解决方案：优化系统，并发测试响应时间小于1秒
实际案例二：
1.添加有销售合同B时，发现查询、选择合同的事物响应时间十分慢，但提交时单用户单循环大于10秒，
业务流程：查询合同->选择合同->点击提交
问题发现：查询合同的关联数据太多引起，因为选择合同时，也需要先查询一次合同，
解决方案：优化系统，并发测试响应时间小于1秒
实际案例三：
1.手工点击有销售合同B的task按钮（用于添加C）>10秒，手工点击无销售合同B的按钮（用于添加C）<0.5秒
业务流程：选择有销售合同的B，点击task
问题发现：有销售合同的关联数据太多引起，
解决方案：优化系统，并发测试响应时间小于1秒
实际案例三：
查询B时，组合条件查询快，响应时间<1秒，单条件查询较慢，响应时间>30秒
业务流程：组合查询：输入用编码+名字，点击search
               单条件查询：输入名字，点击search
问题发现：查询B时，组合条件查询快，响应时间<1秒，因为，查询时，通过组合条件添加将不必要的条件                进行过滤，而单条件查询较慢，响应时间>30秒，且含数字的名字比含字母的名字查询快一些                  ，因为用名字查询时，还要区分大小写
解决方案：该问题解决比较麻烦，1. 第一次进行性能优化，平均响应时间10<响应时间<15秒，
                                              2.开发认为优化空间不大，因为关联的表太多（注：B层属于A层，查询                                                 出B层还要先将A层查询出来），建议业务将响应时间改为15秒
                                             3.考虑是权限问题，造成数据量太大，因测试时用管理员帐号，查询出的B是在全球所有B中找出的，建议改为只有某国家区域的权限（如：某国的接口人）测试，
                                             4.第二次性能优化解决，响应时间<3秒
实际案例四：
单用户手工用管理员帐号进入申请单的页面响应时间>30分钟，最后提示超时，用tes3进入申请单的页面响应时间>1分钟
业务流程：点击项目工程->点击我的申请单，
问题发现：1.权限问题，造成数据量太大，因测试时用管理员帐号，可以查出所有的项目申请单，而接口人                  只能查出该权限的申请单
                2.对申请单未进行添加索引
解决方案：添加索引，响应时间<1秒
实际案例五：
查询合同，响应时间>20秒
业务流程：进入查询合同页面，输入精确合同号，点击search
问题发现：合同关联数据太多，合同是在全球合同中查出的
解决方案：在查询时，将国家地区作为必选项，再进行查询，响应时间<2秒
实际案例六：
单用户导出D的时间大于10秒
业务流程：查询出A后，点击导出（因为D属于A）
问题发现：系统导出D的时间与后台处理导出D的消息队列时间间隙太长
解决方案：缩短系统导出D的时间与后台处理导出D的消息队列时间间隙，
新问题：导出一定数量D后，提示unkown system error
实际案例七：
导出一定数量D后，提示unkown system error
业务流程：查询出A后，点击导出（因为D属于A）
问题发现：当导出D的次数过多，引起导出D的队列消未处理完，出现报错，如：队列消息最大为5000，且导出D的次数已达到5000，但此时的队列空间已满，且队列消息还未及时处理，还有500条未时，则队列消息剩余空间只有5000-500=4500，故出现前台系统报错
解决方案：1.将队列消息的空间值加大
实际案例八：
查询发票的场景登陆后，出现自动登出，手工可以重现
业务流程：进入查询发票页面，输入精确合同号，点击search
问题发现：数据库被锁
解决方案：数据库解锁
实际案例九：
查询合同的场景运行30分钟左右，连续出现失败事物，（排除脚本问题），（注：验证10次，重现10次）
业务流程：进入查询合同页面，输入精确合同号，点击search
问题发现： loadrunner日志：1.找不到进入查询合同页面的检查点，但手工不能重现
                                       2.发现系统运行一段时间后，请求的链接在服务端返回后，重定向到另一个链                                          接
                 开发认为：可能为登陆30分钟运行后，出现自动退出，
解决方案：1.开发建议将进入查询合同页面的检查点置后，再进行测试
               2.建议将进行查询询合同页面的链接放在登陆，以便更能发现问题规律
               3.最终因该问题比较难以定位，项目进度紧张，故作为历史遗留问题，
          注：最终解决办法：是LoadRunner的一个设置问题，是将浏览器设置为：每运行一次后，清除一次缓存，即解决该问题 

本次测试中，测试某模块的查询场景，结果：在场景运行后30分钟出现

检查点的目的：主要用于验证某个界面上是否存在指定的text或image等对象，LoadRunner主要检查在压力较大的情况时，web服务器能否返回正常页面
例：正常业务流程：
   录入A->提交A->提示操作成功的窗口->返回录入A的页面
如将“提示操作成功的窗口”作为检查点，当A的名字已存在时，LoadRunner运行该业务流程，则系统提示：A的名字存在，LoadRunner就会出错，提示找不到“提示操作成功的窗口”的检查点，即该业务流操作失败
LoadRunner中使用检查点的方法：
定位要检查的页面：
1.脚本切换到Tree View方式->点击页面左侧对应URL->查看到页面与页面需要检查图形或文本信息
2.插入文字检查点：
在相应ULR->单击右键->弹出菜单选择Insert After或insert before->URL脚本前或后插入函数，函数名为web_find,->插入图像或文字检查点：则选择image Check或text check->输入查询文字或图像，如：operation success，在tree view视图中树形表插入类似step,如：Sumbit From=query cgi,Service:find_find title
3.设置于检查点有关选择项：
系统执行时启用检查点->Vuser->Run-Time->Setting->Preferencrd->Enable imageand text check前打钩
4.检查点是否通过的查看方法
a.脚本运行结束->Tree View下->右键点击检查点步骤->选择go to Step inexecution Log->系统自动定位到执行日子中获取检查点结果的一行
b.最简单，直接在scrpit View下查看Log即可
检查点插入注意技巧：
检查点的位置应设置在页面的较下方
案例分析：
现象：打开百度网，页面较上方为标题“百度”，较下方有“把百度设为主页”，检查点设置为“百度”，在较大压力下，打开该网页，脚本出现报错，该检查点找不到，但查看系统该检查点存在
注：正常情况打开百度网页，响应时间小于0.1秒，此次压力情况下，响应时间为10秒
原因分析：
在压力较大情况下运行场景，页面显示速度较慢，当脚本运行至“百度”检查点时，因为响应时间较长，该检查点还未在页面上显示，故提示该检查点找不到（注：该检查点最终显示在页面）
解决办法：
检查点的位置应设置在页面的较下方

 

在性能测试中，业务流程越简单越好，不需要与功能需求一样复杂....
  性能测试与功能的区别：
  性能测试：LoadRunner强调的是客户端与服务端的交互
  功能测试：QTP强调的是业务流传的实现，如视图对象
例：在A的B下创建C,
流程：查询Ａ或添加A－>选择列表中已存在的B或添加B->添加C
功能测试QTP关注以下是否实现：
         添加A－>添加B->添加C
         查询Ａ－>添加B->添加C
         查询Ａ－>选择列表中已存在的B->添加C
         ..........
    注：依场景法考虑所有覆盖的业务场景
性能测试LoadRunner：考虑业务流程，查询固定的A下->选择固定的B->添加C
如：A：5510762，B：3353862，C：任意
Loadrunner:不管在什么场景下添加，只要能成功添加C即可，可以避免参数化的，尽量不做参数化，以减少不必要的性能压力，
注：性能测试业务流程设计应满足：单用户单循环，单用户多循环，多用户单循环，多用户多循环等

 

 

 

Iperf  是一个网络性能测试工具。Iperf可以测试TCP和UDP带宽质量。Iperf可以测量最大TCP带宽，具有多种参数和UDP特性。Iperf可以报告带宽，延迟抖动和数据包丢失。

功能介绍
TCP
测量网络带宽
  报告MSS/MTU值的大小和观测值
支持TCP窗口值通过套接字缓冲
当P线程或Win32线程可用时，支持多线程。客户端与服务端支持同时多重连接
UDP
客户端可以创建指定带宽的UDP流
测量丢包
测量延迟
支持多播
当P线程可用时，支持多线程。客户端与服务端支持同时多重连接（不支持Windows）
在适当的地方，选项中可以使用K（kilo-）和M（mega-）。例如131072字节可以用128K代替。
可以指定运行的总时间，甚至可以设置传输的数据总量。
在报告中，为数据选用最合适的单位。
服务器支持多重连接，而不是等待一个单线程测试。
在指定时间间隔重复显示网络带宽，波动和丢包情况。
服务器端可作为后台程序运行。
服务器端可作为Windows 服务运行。
使用典型数据流来测试链接层压缩对于可用带宽的影响。
参数与说明
命令行选项
环境变量选项
描述
客户端与服务器端选项
-f, --format [bkmaBKMA]
$IPERF_FORMAT
格式化带宽数输出。支持的格式有：
    'b' = bits/sec            'B' = Bytes/sec
    'k' = Kbits/sec           'K' = KBytes/sec
    'm' = Mbits/sec           'M' = MBytes/sec
    'g' = Gbits/sec           'G' = GBytes/sec
    'a' = adaptive bits/sec   'A' = adaptive Bytes/sec
自适应格式是kilo-和mega-二者之一。除了带宽之外的字段都输出为字节，除非指定输出的格式，默认的参数是a。
注意：在计算字节byte时，Kilo = 1024， Mega = 1024^2，Giga = 1024^3。通常，在网络中，Kilo = 1000， Mega = 1000^2， and Giga = 1000^3，所以，Iperf也按此来计算比特（位）。如果这些困扰了你，那么请使用-f b参数，然后亲自计算一下。
-i, --interval #
$IPERF_INTERVAL
设置每次报告之间的时间间隔，单位为秒。如果设置为非零值，就会按照此时间间隔输出测试报告。默认值为零。
-l, --len #[KM]
$IPERF_LEN
设置读写缓冲区的长度。TCP方式默认为8KB，UDP方式默认为1470字节。

-m, --print_mss
$IPERF_PRINT_MSS
输出TCP MSS值（通过TCP_MAXSEG支持）。MSS值一般比MTU值小40字节。通常情况

-p, --port #
$IPERF_PORT
设置端口，与服务器端的监听端口一致。默认是5001端口，与ttcp的一样。
-u, --udp
$IPERF_UDP
使用UDP方式而不是TCP方式。参看-b选项。
-w, --window #[KM]
$TCP_WINDOW_SIZE
设置套接字缓冲区为指定大小。对于TCP方式，此设置为TCP窗口大小。对于UDP方式，此设置为接受UDP数据包的缓冲区大小，限制可以接受数据包的最大值。
-B, --bind host
$IPERF_BIND
绑定到主机的多个地址中的一个。对于客户端来说，这个参数设置了出栈接口。对于服务器端来说，这个参数设置入栈接口。这个参数只用于具有多网络接口的主机。在Iperf的UDP模式下，此参数用于绑定和加入一个多播组。使用范围在224.0.0.0至239.255.255.255的多播地址。参考-T 参数。
-C, --compatibility
$IPERF_COMPAT
与低版本的Iperf使用时，可以使用兼容模式。不需要两端同时使用兼容模式，但是强烈推荐两端同时使用兼容模式。某些情况下，使用某些数据流可以引起1.7版本的服务器端崩溃或引起非预期的连接尝试。
-M, --mss #[KM}
$IPERF_MSS
通过TCP_MAXSEG选项尝试设置TCP最大信息段的值。MSS值的大小通常是TCP/IP头减去40字节。在以太网中，MSS值 为1460字节（MTU1500字节）。许多操作系统不支持此选项。
-N, --nodelay
$IPERF_NODELAY
设置TCP无延迟选项，禁用Nagle's运算法则。通常情况此选项对于交互程序，例如telnet，是禁用的。
-V (from v1.6 or higher)

绑定一个IPv6地址。
服务端：$ iperf -s –V
客户端：$ iperf -c  -V
注意：在1.6.3或更高版本中，指定IPv6地址不需要使用-B参数绑定，在1.6之前的版本则需要。在大多数操作系统中，将响应IPv4客户端映射的IPv4地址。
服务器端专用选项
-s, --server
$IPERF_SERVER
Iperf服务器模式
-D (v1.2或更高版本)

Unix平台下Iperf作为后台守护进程运行。在Win32平台下，Iperf将作为服务运行。
-R(v1.2或更高版本，仅用于Windows)

卸载Iperf服务（如果它在运行）。
-o(v1.2或更高版本，仅用于Windows)

重定向输出到指定文件
-c, --client host
$IPERF_CLIENT
如果Iperf运行在服务器模式，并且用-c参数指定一个主机，那么Iperf将只接受指定主机的连接。此参数不能工作于UDP模式。
-P, --parallel #
$IPERF_PARALLEL
服务器关闭之前保持的连接数。默认是0，这意味着永远接受连接。
客户端专用选项
-b, --bandwidth #[KM]
$IPERF_BANDWIDTH
UDP模式使用的带宽，单位bits/sec。此选项与-u选项相关。默认值是1 Mbit/sec。
-c, --client host
$IPERF_CLIENT
运行Iperf的客户端模式，连接到指定的Iperf服务器端。
-d, --dualtest
$IPERF_DUALTEST
运行双测试模式。这将使服务器端反向连接到客户端，使用-L 参数中指定的端口（或默认使用客户端连接到服务器端的端口）。这些在操作的同时就立即完成了。如果你想要一个交互的测试，请尝试-r参数。
-n, --num #[KM]
$IPERF_NUM
传送的缓冲器数量。通常情况，Iperf按照10秒钟发送数据。-n参数跨越此限制，按照指定次数发送指定长度的数据，而不论该操作耗费多少时间。参考-l与-t选项。
-r, --tradeoff
$IPERF_TRADEOFF
往复测试模式。当客户端到服务器端的测试结束时，服务器端通过-l选项指定的端口（或默认为客户端连接到服务器端的端口），反向连接至客户端。当客户端连接终止时，反向连接随即开始。如果需要同时进行双向测试，请尝试-d参数。
-t, --time #
$IPERF_TIME
设置传输的总时间。Iperf在指定的时间内，重复的发送指定长度的数据包。默认是10秒钟。参考-l与-n选项。
-L, --listenport #
$IPERF_LISTENPORT
指定服务端反向连接到客户端时使用的端口。默认使用客户端连接至服务端的端口。
-P, --parallel #
$IPERF_PARALLEL
线程数。指定客户端与服务端之间使用的线程数。默认是1线程。需要客户端与服务器端同时使用此参数。
-S, --tos #
$IPERF_TOS
出栈数据包的服务类型。许多路由器忽略TOS字段。你可以指定这个值，使用以“0x”开始的16进制数，或以“0”开始的8进制数或10进制数。
例如，16进制'0x10' = 8进制'020' = 十进制'16'。TOS值1349就是：
    IPTOS_LOWDELAY     minimize delay        0x10    IPTOS_THROUGHPUT   maximize throughput   0x08    IPTOS_RELIABILITY  maximize reliability  0x04    IPTOS_LOWCOST      minimize cost         0x02
-T, --ttl #
$IPERF_TTL
出栈多播数据包的TTL值。这本质上就是数据通过路由器的跳数。默认是1，链接本地。
-F (from v1.2 or higher)

使用特定的数据流测量带宽，例如指定的文件。
$ iperf -c  -F
-I (from v1.2 or higher)

与-F一样，由标准输入输出文件输入数据。
杂项
-h, --help

显示命令行参考并退出 。
-v, --version

显示版本信息和编译信息并退出。
举例：
1）TCP测试
服务器执行：./iperf -s -i 1 -w 1M
客户端执行：./iperf -c host -i 1 -w 1M
其中-w表示TCP window size，host需替换成服务器地址。
2）UDP测试
服务器执行：./iperf -u -s
客户端执行：./iperf -u -c 10.255.255.251 -b 900M  -i 1  -w 1M  -t 60
其中-b表示使用多少带宽，1G的线路你可以使用900M进行测试。

 

 

例：如 192.168.3.131 做服务端，cm:10.190.1.13做客户端，

则在cm端：进入到该目录，然后 输入iperf .exe –c –u 192.168.3.131 –t 30 –i 10

  在131端：进入到该目录，然后输入iperf .exe –s –u

注意：发包端为客户端，接收端为服务端 

测试CMTS在不同环境下，吞吐量的大小；在测试吞吐量的过程中，观察CPU的使用情况

测试环境：

硬件：PC机器、CMTS、 cable modem (1.0、2.0、3.0各一个)

软件：linux系统、windowsXP、CMTS自带系统、CutFTP 8（服务器）

  测试环境搭建：

        物理连接：

1.        CMTS上连接测试所用的CM，如：1.0、2.0、3.0,并上线；

注意：3.0cable modem测试时，做四个上行与四个下行绑定；

2.        将PC机的千兆网卡连接cable modem,并自动获取ip，即：PC机的ip与cable modem的ip处于同一网段；

配置文件的使用：

,    默认：

                Cxh1_0.bin (1.0的cm)

               throughout.bin   (2.0与3.0的cm)

注：具体配置文件根据测试需求

CMTS环境配置：

     默认：

             interleave 8；

upstream map size 2；

map-advance static 200；

channel-width 6400000；

minslot  4；

annex   b;

注：3.0cable modem下载：使用annex  A

测试方法与步骤

测试吞吐量：

      法一：

1. 用CutFTP工具上传：在客户端将文件通过CutFTP上传到服务端；

例：客户端：192.168.0.63；服务端：192.168.3.131

             1.在pc机(192.168.0.63)上打开cuteFTP 8,并双击192.168.3.131

2.在左侧的C：\down….\myth1.mpg下将要上传的文件拖入右侧的pub下，即可，（注：先在右侧的上框输入pub）；

       3. 1.0cable modem测试使用 profile 2,2.0cable modem测试使用profile 3,3.0cable modem上传测试使用profile 30,annex b,下载使用profile 3,annex A,

4.在测试过程中观察吞吐量的变化，

5.观察cpu利用率的变化，

观察方法：

1．   用nroot登陆，在nroot下，访问上行板块，如：telnet 1.0.2 (上行板块的位置),然后用croot登陆，并输入TOP,观察即可

                     6.在异常情况，可观察channel利用率：show docsis channel utilization

2.用CutFTP工具上传下载：在服务端将文件通过CutFTP上传到客户端，具体方法与上传类似

法二：

            使用吞吐量测试工具iperf测试，具体方法（略）

预期参考值：

  3.0最佳：下载 120 兆

            上传 90 兆

      注：可修改配置文件的max burstup，使值越大越好