第一篇:Android客户端性能测试总结
Android客户端性能软件测试小结
发布时间: 2012-3-09 13:52 作者: xiaowan 来源: TaoBao QA Team 字体: 小 中 大 |上一篇下一篇 |打印 |我要投稿 |推荐标签:性能测试软件测试
Android手机客户端的性能测试开展近3个月了,期间包括性能监测工具的开发周期和工具的投入使用和优化;客户端性能测试从这里起步,从这里开始。
一般情况,对于新生的产品,都会用定势的思维考虑:优先功能测试,之后才会是安全、性能等方面。android客户端从诞生到现在,在测试上走的也是这样的路线。随着客户端功能越来越完善、越来越繁大,用户群越来越多,性能、响应、稳定等被正式提上议程,重点考虑关注。
为什么我们要从以上几个点来考虑客户端性能呢? 针对上面的几个点我们是如何开展监控测试的?如何来评估一个客户端的性能好不好,是否给予通过?下面就我自己看法跟大家详细交流。
有数据统计:有很大一部分人群喜欢睡觉前、公交车、厕所、或者会议中开小差中使用手机;在看下移动互联网的发展趋势【下图摘自某次互联网统计报告】:
在上图为各大运营商所占移动市场份额的变化情况:整体上移动用户数仍绝对领先,但其市场份额也明显的下降趋势,百度推断导致此变化的原因是基础网络的性能已经开始影响移动互联网应用的使用,即网络到底好不好,速度到底快不快,已经开始在影响应用市场份额了。同样,对用户而言:特定网络下客户端流畅不流畅、响应快不快决定着用户对客户端的使用时长和粘度;此外,用户在考虑速度的同时,还会考虑跟自身利益相关的—-金额&网络流量的消耗。
一个成熟的场景包括:人、时间、地点、行为。换言之:什么特征的人在什么情况下会使用比较容易比较经常使用客户端,他们又经常使用客户端的哪些面呢?
在客户端性能监测前,我们需要采集真实场景中的性能数据:2G的网络下的时间指标、访问量较多页面的流量消耗情况、整个客户端的稳定情况。
(1)稳定性测试:【不同网络、不同软硬件系统下】
客户端可稳定运行的时间、以及长时间操作后的流量消耗和内存消耗;
(2)性能测试指标:【不同网络下】
界面流畅性、界面切换时间、占用的内存数、服务器返回数据消耗流量大小及数据的返回时间;
对以上的点,有几种方法可以采用来监测。现在我们使用的是自己开发的客户端性能工具。其中:流量统计使用TrafficStats.getUidRxBytes()来获取下行流量值;响应时间通过判断activity的状态和日志中记录的时间戳来获取响应时间段; 内存通过解析dumpsys命令返回内容,截取我们需要的值进行分析;电量统计android系统提供查看。除了自己研发的小工具之外,外界也提供很多工具,都可以帮助我们完成相关的性能监测。
对用户而言,性能不等于响应。坚持客户第一,通过我们一个测试环节来保证用户手中的每个客户端都用的畅快。
第二篇:性能测试学习总结
性能测试学习总结
一、明确性能测试的范围
例如:以iptv系统为例,是需要测试bss页面、中间件具体接口、boss/crm具体接口
二、明确性能测试的指标 例如:
1、支持最大并发用户数是多少?(压力测试)
2、每秒n个用户并发,能正常持续运行多久?(负载测试)
3、在系统用户为n个的情况下,每秒x个用户并发,持续运行y分钟,查看系统硬件io、cpu、内存;查看软件平均吞度量、tps、平均响应时间、事务成功率、事务失败率、错误率等(性能测试)、响应时间:事务从开始到完成所花费时间
平均吞吐量:指单位时间内系统处理用户的请求数
TPS:transaction per second 服务器单位时间处理的事务数(事务数/运行时间s)
事务:指访问并可能更新数据库中各种数据项的一个程序执行单元。例如订购操作,它含有多个请求
事务成功率:成功事务数占完成总事务数的比率 事务失败率:失败事务数占完成总事务数的比率
三、定义数据模型
1、目标系统用户数、目标每秒并发数、硬件系统配置情况,如下:模板
IPTV-BSS 性能指标.docx
四、设计性能测试方案
IPTV BSS四川电信版本性能
五、搭建性能测试环境
1、尽可能模拟现网的环境与组网结构
2、前台应用和后台数据库安装在独立干净的服务器上。
3、当前性能测试环境分别为:192.168.12.11(前台)192.168.12.31(数据库)192.167.12.177(Loadrunner)
六、构造性能测试数据
1、使用LR、QTP自动化工具构造(比较慢,不需要了解表结构,但是需要了解业务流)
2、编写存储过程构造用户、包月、订购数据(比较快,需要对相关表结构和数据库了解)
七、录制、调试测试脚本
1、中间件接口目前是web services协议,因当前测试指标均超过100个并发,故使用web(http/html)协议录制。中间件接口录制页面:
2、boss接口当前有两种协议,一种是web services协议,一种是sockets协议,因当前测试指标最大为100个并发,故可以使用web services协议或http/html协议录制。
3、bss页面基于ie运行,故使用web(http/html)协议录制。
注明:当前中间件接口,四川boss接口,浙江电信bss部分页面均有现成的脚本,如果其它局点需要测试可使用原有的脚本调试即可。
详细参考:LoadRunner性能测试_刘双林_20110115.doc
2.3/2.4章节 进行学习
八、执行性能测试场景
1、按照测试方案文档中的测试用例执行即可。
2、在执行性能测试过程中会具体使用到性能测试工具LR。关于性能测试工具的使用方法网上有大把资料。请自行学习:场景设置、参数化等
详细参考:LoadRunner性能测试.doc
3章节 进行学习
九、监控并记录性能测试结果
1、硬件性能:bss应用服务器cpu、内存;数据库服务器cpu、内存、io 内存、cpu 不高于70% ;IO不高于80% 否则可能存在性能瓶颈 统计方式:
(1)通过命令在服务器上查询
内存 sar-r 5 120
(每5s刷新1次共刷新120次)cpu sar-u 5 120 io
iostat 5 120(2)在服务器上安装rpc.rstatd工具,通过LR客户端窗口监控记录
2、软件性能:平均吞度量、tps、平均响应时间、事务成功率、事务失败率、错误率等(场景运行完毕可通过loadrunner工具导出性能测试结果),是否达标是要与性能测试指标进行比对。
详细参考:LoadRunner性能测试.doc
4章节 进行学习
十、分析性能测试结果输出总结报告
1、将实际测试结果和性能测试指标进行对比,总结出不达标测试对象及具体测试数据
2、测试与开发人员根据性能测试数据,从硬件环境和软件本身进行分析。例如:优化硬件配置、软件处理逻辑、数据库架构脚本等。
3、具体分析的方法:一般是具体问题具体分析,查找瓶颈时按以下顺序,由易到难。(1)服务器硬件瓶颈
(2)网络瓶颈(对局域网,可以不考虑)(3)服务器操作系统瓶颈(参数配置)(4)中间件瓶颈(参数配置,数据库,web 服务器等)(5)应用瓶颈(SQL 语句、数据库设计、业务逻辑、算法等)注:以上过程并不是每个分析中都需要的,要根据测试目的和要求来确定分析的深度。对一些要求低的,我们分析到应用系统在将来大的负载压力(并发用户数、数据量)下,系统的硬件瓶颈在哪儿就够了。
十一、LoadRunner性能测试工具操作文档
LoadRunner性能测试.doc
loadrunner8.1教材.pdf
第三篇:手机银行客户端测试总结
手机银行测评总结
一、功能总结
通过对十三家手机银行的功能试用和对比,可以将目前手机银行的功能大致分为以下四类与账户服务、金融产品及其服务、生活服务、其他业务。以下是多家银行的手机界面:
账户服务:
这部分的服务是银行最基本的服务,所以各家银行在功能上没有太大差别。一般分为账户管理、转账汇款、无卡取现、信用卡这四部分。除了无卡取现这一相对比较新鲜的业务外,其他的功能可以用应有尽有来描述。细化的功能就不再赘述,可以参考各家银行手机测评报告中的功能地图。金融产品及其服务:
金融产品及其服务目前主要提供的业务有:基金业务、外汇业务、理财业务、贵金属业务、国债业务、保险业务、银期业务、银证业务、个人贷款、结售汇、手机股市、大智慧;以及个别银行针对自己的特色产品提供的相关服务,如工行的账户原油、高尔夫,交行的双利理财、薪金宝等。生活服务:
生活服务方面目前提供的主要业务有:生活缴费(水费、电费、燃气费、通信费、取暖费、有线电视费、小区物业费、彩票站点缴费)、手机充值、游戏点卡充值、电影票、彩票、飞机票、演出票、酒店预订、公益捐款、银医服务、代驾服务、交通罚款、优惠商户、商城购物等。其他业务:
除上述业务外,还有诸如理财计算器、网点查询、排号预约、业务指南、优惠活动、银行资讯、自助注册、客户服务等辅助业务。
以上基本是目前我国手机银行业提供的所有功能和业务,每家手机银行并不是都具有了上面所说的全部,除了账户服务和其他业务相差较小外,其他两个服务因为每家银行的侧重点不一样,在各个银行间还是具有较大差异。做的较好较全面的,要数工行、建行、招行、交行、民生等银行。做的最差的当属中国银行,功能稀少、操作不便、界面粗糙等等,各方面都排在了众多银行的后面,实在是有辱其大行之名。
二、特色分析
对比各家银行,目前手机银行所具有的特色主要体现在转账支付手段的创新以及营销手段的创新等方面。转账支付创新: 在银行传统转账操作的基础上,各家银行充分发挥自己的创作能力。提供了摇一摇转账、手机号转账、二维码转账、手机无卡取现等多种新颖别致,颇具个性化的功能。并且由于支付实质上也是归结为一种转账,将以上各服务运用在消费支付上,就形成了一种新的支付手段。这方面做的比较好的有建行、平安、民生等。
以下就是建行摇一摇功能,除了进行转账功能外,还可以进行个性化设置,实现账户余额、外汇买卖、账户贵金属、网点的快速查询。
以下是建行“一拍享购”的二维码功能,通过建行手机银行客户端拍摄二维码,可以轻松享受一拍理财、购物等时尚生活体验。
营销手段创新:
在营销手段方面,各家银行互相发挥自己的优势和才智,除了借鉴已经成功的互联网电子商业模式外,还结合手机银行自身的特性,推出了不少新的服务。这其中比较有特色的是招行、交行和建行。
1、在其他手机银行的优惠商户里面一般只有衣食住行方面的普通优惠商户,这些商户的特点就是单次消费低,客户需求大优惠方式以折扣为主;招行另辟蹊径,提供了针对医疗、教育、家电、汽车、通讯等昂贵产品和服务的分期商户,迎合了市场,满足了人们的不同需求。以下是招行优惠商户和分期商户的界面:
2、另外一个比较具有特色的就是交行的“最红星期五”和建行的“建行e路惠,最炫星期天”。他们都选取了周末这个平日消费相对集中的时间段进行一种折上折的促销,或者是开展本行的一些优惠活动,这样活动必将会引发客户的争相参与,引起一波消费热潮。长期使用他们手机客户端的人,很容易由于这种活动而对他们的手机客户端产生习惯和依赖。以下是相关界面:
3、除此之外,还有一个不得不提的就是民生银行,其跨行账户管理功能十分强大。在其余手机银行里面,一般只能对本行账户进行管理,而在民生手机银行里面,只要进行了签约,就可以对他行账户进行余额查询操作,为多卡用户提供了极大的方便。并且民生银行将年初炒的比较热的“超级网银”,即跨行资金归集业务也移植到了手机上,如果用户办理了相关业务,并合理运用。只用一个手机,不同银行多个账户之间的资金真是想怎么转就怎么转,将手机银行的优势发挥到了极致。由于这些业务只有需要多张银行卡,且办理了相关业务资费才能显示,过程较为繁琐,相关页面就不再列出了。下面是民生银行的转账汇款业务,其中的“同名汇款”在其他银行较为少见,列出来算是一种补充。
4、其他如排号预约、理财计算器、交行的语音服务、火车票查询;招行的“e代驾”、《财经内参》和《财智生活》;工行的业务指南等功能也颇具特色。以下是一些相关界面:
建行转账汇款的界面:
工行的理财计算器:
工行的业务指南:
招行的“e代驾”、《财经内参》和《财智生活》:
类似的功能很多家银行都有,每家银行也都有自己的一项或数项特色功能,在此就不一一列举了。其实特色功能不一定代表实用,看起来很实用的功能,也不不一定代表用的人就很多。具体情况如何,也只能待若干年后,我国手机银行稳定和壮大,方能见分晓。
三、总结
由于我国手机银行客户端还处于起步的阶段,能熟练使用的人还不是很多,许多人对这一新鲜事物还不了解,有的了解却对它的业务只是停留在像网银一样的账户管理、投资理财、代缴费等传统业务上面,甚至对它的安全性还抱怀疑态度。
目前,各大银行都处于一种剑拔弩张的态势。随着移动互联网大潮的到来,移动支付是一种必然的趋势。手机银行客户端作为其中的媒介,谁的客户端占领了用户的手机,谁就占领了市场。所以客户端的界面好坏,操作是否方便快捷,功能是否齐全,安全性能如何,是否具有特色服务等等都会在用户做出选择时起到十分重要的作用。当然,银行的宣传力度对于手机银行市场占有率的提升也是至关重要的,尤其是在现在这种起步阶段。
上面以几家银行为例,列举了一些特色业务,其实这些业务并非他们所独有,甚至也不是他们所首创。比如“摇一摇”转账,百度里面搜到的最先推出这种服务的是中信银行,现在建行、平安等也推出了同样的业务,并且建行活学活用,还将“摇一摇”用到了其他功能上,显得比中信更胜一筹。其他如二维码转账支付、手机号转账、无卡取款、排号预约等特色服务,目前虽然并不是每家银行都有,但确实是处于逐渐添加和完善的状态。比如工行10月23号更新的客户端里面添加了二维码购物等多项功能。究其原因,我们可以归结为目前我国的手机银行市场还不太成熟和稳定,但市场空间又无比广阔,银行间竞争激烈,都希望先人一步,占据尽可能多的市场份额。即使在某项功能尚不成熟,市场前景未知的情况下,也去盲目跟风推出,寄希望于增加功能来吸引用户。然而一个APP的功能容量是有限的,以往多家银行都缺乏产品策略规划,估计就在今年,功能增加将走向尽头。银行必须考虑重新建立产品策略和产品形态。
银行业务复杂,产品众多,用户面也非常广泛,仅靠一个APP承载这么多使得产品臃肿而市场响应迟钝。银行应该学习新浪、腾讯、阿里巴巴这类企业,根据业务特点做垂直应用。同时,手机银行产品雷同问题严重,而独立APP产品线是差异化的出路。目前,招行除了手机银行还有掌上生活APP,交行新推出了校园版APP;估计其他银行也会陆续跟进,女性手机银行、理财专用APP、黄金买卖APP、青少年用户版本APP等各种细分产品将形成银行APP产品线。
得益于智能手机的普及,以及各商业银行的重视以及宣传,手机银行的用户数正在直线上升,交易额也呈现出一种爆发式增长的态势,将来极有可能发展到与网上银行体积相当的程度。专家预计,移动支付和移动金融,将是手机银行的主要增长点。
注:
1、以上图片有看不清的,可以放大word文档的倍数进行查看!
2、本文档数个人原创,仅限学习交流,严禁下载后到其他网站四处上传,做人要厚道!
第四篇:性能测试QQ面试总结
21克
9:46:17 你全权参与的性能测试项目有几个? 低调的鱼
9:48:08 BECIF平安银行客户信息管理系统
平安银行个人网银改造(接入一帐通卡后)平安投行证券管理系统 交通银行积分管理系统 中银联OA系统
21克
9:48:50 那在性能测试中有没有发现什么缺陷? 低调的鱼
9:53:09 我去整理一下 21克
9:55:29 好的
低调的鱼
10:03:24 BECIF平安银行客户信息管理系统 1822 BECIF1.0.0 性能测试-客户基本信息查询(20并发 场景脚本 查询客户基本信息_byBecif_c.lrs)P2 L2 关闭 2 1842 BECIF 新增客户性能优化 P4 L3 已关闭 3 1848 综合场景测试(300 4hour)未达到1S响应时间要求 P2 L2 已分配
1.疑似客户判断代码取线程数有误。
2.查询疑似客户返回值最大个数未做限定。
3.中间件ESB对于XML脚本的最大长度限制过小。4.数据库连接数不够。
平安银行个人网银改造(接入一帐通卡后)1.weblogic线程数不够 2.数据库连接池数不够
平安投行证券管理系统 1.服务器系统资源不够
2.用户登陆验证机制时间过长。
交通银行积分管理系统
1.100并发用户时积分查询交易超时
中银联OA系统 1.tomcat JVM过少
2.tomcat 线程数过少。
3.多用户登陆时流量统计插件报错。
低调的鱼
10:04:09 BECIF的缺陷当时我有记录,其他的项目只是记得自己当时做性能测试过程中发现的问题。21克
10:06:45 对BECIF平安银行客户信息管理系统来说,你提及的4条调优的建议是基于什么测试结果提出的?
21克
10:07:00 也就是说你是如何得出这4调结论的 低调的鱼
10:25:36 1.疑似客户判断代码取线程数有误。
查询疑似交易单独运行时,weblogic的线程数增长速度过快,系统线程数迅速到到最大负荷
2.查询疑似客户返回值最大个数未做限定。
我当时编写的脚本是新增用户后再进行疑似查询操作,用户的五项关键信息为:姓名,性别,生日,证件类型,证件号码 2.1 证件类型,证件号码同 2.2 姓名、性别、生日三者相同 如上两种情况都是属于疑似客户,我的查询疑似的脚本中只用户姓名进行了参数化,(每增加一个用户,疑似判断的用户就+1)
因为当时跑了100并发用户的综合场景,分了15分钟,1小时,4小时几次运行。查询疑似交易的平均响应时间越来越长,后面去CC上取代码看的时候,发现开发未对疑似的最大值进行限制。
3.中间件ESB对于XML脚本的最大长度限制过小。
新增用户不添加产品信息时,查询客户所有信息交易平均响应时间正常。
但是从生产上取下来的数据屏蔽名字后,进行综合场景运行过程中,查询客户所有信息的交易失败率大大增加.原因为客户产品信息和基本信息所涉及的字段有300余个,有80多个字段为文本类型,如果客户有多个产品信息的话 查询时系统后台生成的XML脚本文件有可能大于
而ESB对于BECIF传出的XML脚本文件限制的最大值为1M
4.数据库连接数不够。
200用户综合场景运行时,查询类的交易平均响应时间过长,后台log中,返回交易有超时情况 weblogic中事务排队严重。21克
10:32:10 上面的这些的调优工作是有测试人远来做还是由开发人员来做的? 低调的鱼
10:35:33 中间件的参数变更平安银行那边是有专门的人做的,我们只能是提缺陷和建议,然后由他们评审之后确定是他们的问题再作修改的,至于代码类的问题是开发来改的。
我所做的事情就是尽自己可能去收集资源,发现问题,提出自己的见解 21克
10:36:41 你提出的这些建议都有别接受吗? 21克
10:37:02 他们修改后的性能提高了多少? 低调的鱼
10:37:36 这几个都是接受了的 21克
10:37:44 他们修改后的性能提高了多少? 低调的鱼
10:37:55 BECIF项目,按照平安规范,依据性能测试需求分析和方案。进行压力测试
测试目的(1)模拟真实应用,系统各个主要业务流程能否在78个并发用户同时访问情况下响应时间为1s以内。
(2)在系统各业务流程能正常运行的情况下,系统能承受多少个并发用户同时访问(系统承压能力)。
(3)测试主要业务流程(或者某事物)的响应时间。
低调的鱼
10:38:25 这个是一期的要求,经过一系列调整后所有交易都达到上面的指标 21克
10:39:25 你们的性能测试时有自己的环境还是在生产环境上进行的? 低调的鱼
10:43:10 生产上肯定是禁止运行的,专门的性能测试应当说有的 一般都是在STG环境上运行的,BECIF这个项目,当时用于性能测试的有三个环境,PER环境 新功能及系统的测试环境
PIR环境主要用于常规版本测试的生产缺陷问题验证和修复
还有一个是容灾环境,这个环境都是最新版本的系统,一般都是在这个上面做性能测试。21克
10:44:15 你们的性能测试用的是什么工具? 低调的鱼
10:46:30 loadrunner 8.1 和loadrunner9.0 当时做性能测试的时候都是在专门的远程服务器上做的,我用过的一共有5台,3台上面装的是loadrunner8.1另外2台上面装的是loadrunner9.0
21克
10:46:56 好的
21克
10:47:36 你的简历已经通过了筛选,我会吧你的简历提交给测试经理。结果会尽快通知你的 21克
10:47:42
谢谢
低调的鱼
10:47:51 好的,多谢了
第五篇:Linux_网络性能测试(总结)
Linux网络性能测试 使用 Ipref测试吞吐
1.1 安装
tar-zxvf iperf-2.0.5.tar.gz cd iperf-2.0.5./configure make && make install
1.2 测试UDP
服务器命令:iperf-s-i 1-u 客户端命令:iperf-c 170.0.0.100-i 1-t 999-b 1000000000-u-l 22-c:服务器地址-i:每次报告的间隔-t:持续测试的时间-b:带宽-u:UDP-l:UDP 有效负荷大小
各字节测试时,输入-l参数如下:
在服务端查看结果,64字节UDP小包的吞吐约是7.32 Mbits/s。
[root@localhost ~]# iperf-s-u-i 2-----------------------------Server listening on UDP port 5001 Receiving 1470 byte datagrams UDP buffer size: 208 KByte(default)-----------------------------[ 3] 10.0-12.0 sec 1.72 MBytes 7.22 Mbits/sec 0.022 ms 55728/137802(40%)[ 3] 12.0-14.0 sec 1.79 MBytes 7.49 Mbits/sec 0.016 ms 52637/137735(38%)[ 3] 14.0-16.0 sec 1.74 MBytes 7.30 Mbits/sec 0.040 ms 53247/136227(39%)[ 3] 16.0-18.0 sec 1.74 MBytes 7.32 Mbits/sec 0.071 ms 54608/137771(40%)[ 3] 18.0-20.0 sec 1.79 MBytes 7.52 Mbits/sec 0.021 ms 52133/137632(38%)[ 3] 20.0-22.0 sec 1.75 MBytes [ 3] 22.0-24.0 sec 1.74 MBytes 7.32 Mbits/sec 0.020 ms 54508/137672(40%)[ 3] 24.0-26.0 sec 1.79 MBytes 7.51 Mbits/sec 0.022 ms 52519/137838(38%)[ 3] 26.0-28.0 sec 1.72 MBytes 7.20 Mbits/sec 0.019 ms 55779/137599(41%)[ 3] 28.0-30.0 sec 1.72 MBytes 7.23 Mbits/sec 0.016 ms 55504/137640(40%)[ 3] 30.0-32.0 sec 1.77 MBytes 7.41 Mbits/sec 0.017 ms 52849/137002(39%)[ 3] 32.0-34.0 sec 1.74 MBytes 7.31 Mbits/sec 0.022 ms 54785/137842(40%)[ 3] 34.0-36.0 sec 1.74 MBytes 7.30 Mbits/sec 0.019 ms 54717/137710(40%)
7.32 Mbits/sec 0.021 ms 54418/137616(40%)2 使用http_load测试HTTP Server吞吐和并发
2.1 安装Apache服务器
1、安装并启动
yum-y install httpd service httpd start
2、在Apache服务端准备好各字节大小的页面
(页面大小:64、128、256、512、768、1024、1280、1518)cd /var/ Document Length: 64 bytes
Concurrency Level: 10 // 每秒测试并发数 Time taken for tests: 9.920 seconds Complete requests: 100 // 成功的请求数 Failed requests: 0 // 失败的请求数 Write errors: 0 Total transferred: 45100 bytes HTML transferred: 6400 bytes Requests per second: 10.08 [#/sec](mean)// 每秒事物处理,mean表示平均值 Time per request: 992.027 [ms](mean)//平均事物响应时间
Time per request: 99.203 [ms](mean, across all concurrent requests)Transfer rate: 4.44 [Kbytes/sec] received //传输为4.44字节每秒 吞吐为4.44 * 8 = 35.52 Mbit/s 3.3 其他参数
-n requests 全部请求数-c concurrency 并发数
-t timelimit 最传等待回应时间-p postfile POST数 据文件-T content-type POST Content-type-v verbosity How much troubleshooting info to print-w Print out results in HTML tables-i Use HEAD instead of GET-x attributes String to insert as table attributes-y attributes String to insert as tr attributes-z attributes String to insert as td or th attributes-C attribute-H attribute Inserted after all normal header lines.(repeatable)-A attribute http-P attribute Add Basic Proxy Authentication, the attributes are a colon separated username and password.-X proxy:port-V-k Use HTTP KeepAlive feature-d Do not show percentiles served table.-S Do not show confidence estimators and warnings.-g filename Output collected data to gnuplot format file.-e filename Output CSV file with percentages served-h Display usage information(this message)加入cookie, eg.'Apache=1234.(repeatable)加入http头, eg.'Accept-Encoding: gzip' 验证,分隔传递用户名及密码
代理服务器 查看ab版本
使用sendip发原地址跳变的数据包(并发)
3.1 安装
1、到http://www.xiexiebang.com and CWR bits Default: 0-tfe x TCP ECN bit(rfc2481)Default: 0(options are 0,1,r)-tfc x TCP CWR bit(rfc2481)Default: 0(options are 0,1,r)-tfu x TCP URG bit Default: 0, or 1 if-tu specified(options are 0,1,r)-tfa x TCP ACK bit Default: 0, or 1 if-ta specified(options are 0,1,r)-tfp x TCP PSH bit Default: 0(options are 0,1,r)-tfr x TCP RST bit Default: 0(options are 0,1,r)-tfs x TCP SYN bit Default: 1(options are 0,1,r)-tff x TCP FIN bit Default: 0(options are 0,1,r)-tw x TCP window size Default: 65535-tc x TCP checksum Default: Correct-tu x TCP urgent pointer Default: 0-tonum x TCP option as string of hex bytes(length is always correct)Default:(no options)-toeol TCP option: end of list-tonop TCP option: no op-tomss x TCP option: maximum segment size-towscale x TCP option: window scale(rfc1323)-tosackok TCP option: allow selective ack(rfc2018)-tosack x TCP option: selective ack(rfc2018), format is-tots x TCP option: timestamp(rfc1323), format is tsval:tsecr l_edge1:r_edge1,l_edge2:r_edge2...