如何通过篡改http的返回值来模拟特定场景

最近接到一个需求,需要同时模拟20个司机出现在一个区域内,查看此时拖动地图时,我们的打车软件是否会出现地图卡顿等现象。

那么此时,如何能够模拟出20个司机出现在一个区域内呢?

方法有以下几种

1、找20台手机,同时登陆20个司机账号。

优点:数据完全真实

缺点:需要同时使用20台手机。

2、调用接口,输入司机ID与上线的经纬度

优点:完全模拟真实场景,数据也是真实的数据

缺点:需要对这个流程中的每个接口,如登陆,上线等模块了解清晰,并且事后要做下线处理,否则会对正常派单产生影响。

3、直接修改app所查询的接口返回值

优点:只需修该返回值,无需修该其他

缺点:只能模拟司机车辆图标出现,而这些司机实际是不存在的

解决方案列了出来,那我们应该选择哪个呢?

这首先就要看测试点了。我们的测试点是在乘客端的页面查看20辆车同时出现的情况

那么我们的关注点是只要车辆图标出现,随后移动地图是否卡顿。而不是后台派单是否正确

因此我们的关注点是车辆图标。

而乘客端的司机图标是怎么出现的?

他是通过一个查询附近司机的接口来画图的。

那这个接口的返回值是什么,我们只要修改返回值,给app端造成返回附近有20辆车即可。

所以我们选择方法三

通过与开发沟通,我们发现我们只要修改下经纬度与司机编号,即可。

 

{
“lt”: 30.192,
“lg”: 120.152,
“id”: 3,
“dir”: 15.0
}

而司机编号在这里是不做校验的,只要司机编号不重复即可。

因此我们只要对查询附近司机的接口做返回值替换即可。

那么 how?

首先我们把修改后的返回值保存到本地,命名为x.json

此处x.json内容如下所示:

{
“code”: 0,
“data”: {
“drivers”: [{
“lt”: 30.190,
“lg”: 120.150,
“id”: 1,
“dir”: -1.0
}, {
“lt”: 30.191,
“lg”: 120.151,
“id”: 2,
“dir”: 10.0
},
{
“lt”: 30.192,
“lg”: 120.152,
“id”: 3,
“dir”: 15.0
},
{
“lt”: 30.193,
“lg”: 120.153,
“id”: 4,
“dir”: 20.0
},
{
“lt”: 30.194,
“lg”: 120.154,
“id”: 5,
“dir”: 25.0
},
{
“lt”: 30.195,
“lg”: 120.155,
“id”: 6,
“dir”: 30.0
},{
“lt”: 30.196,
“lg”: 120.156,
“id”: 7,
“dir”: 40.0
},{
“lt”: 30.197,
“lg”: 120.157,
“id”: 8,
“dir”: 45.0
},{
“lt”: 30.197,
“lg”: 120.157,
“id”: 9,
“dir”: 50
},{
“lt”: 30.198,
“lg”: 120.158,
“id”: 10,
“dir”: 60.0
},{
“lt”: 30.199,
“lg”: 120.159,
“id”: 11,
“dir”: 70.0
},{
“lt”: 30.200,
“lg”: 120.160,
“id”: 12,
“dir”: 80.0
},{
“lt”: 30.201,
“lg”: 120.161,
“id”: 13,
“dir”: 90.0
},{
“lt”: 30.202,
“lg”: 120.162,
“id”: 14,
“dir”: 100.0
},{
“lt”: 30.204,
“lg”: 120.164,
“id”: 15,
“dir”: 40.0
},{
“lt”: 30.203,
“lg”: 120.163,
“id”: 16,
“dir”: 40.0
},{
“lt”: 30.204,
“lg”: 120.164,
“id”: 17,
“dir”: 40.0
},{
“lt”: 30.189,
“lg”: 120.149,
“id”: 18,
“dir”: 40.0
},{
“lt”: 30.188,
“lg”: 120.148,
“id”: 19,
“dir”: 40.0
},{
“lt”: 30.187,
“lg”: 120.147,
“id”: 20,
“dir”: 40.0
}] },
“message”: “成功”
}

以下前提是建立在你已经调通了charles 能正常抓包的情况下

我们打开charles

点击本地映射 map local

点击此处随后点击添加

 

随后修改请求 这些请求都可以通过抓包来获取

随后把map to指向刚才的json文件

点击保存后 结果如下图所示

就会出现20辆车同时存在的情况了

bug定位总结

bug定位基本流程:

bug定位核心方法:

  1. http抓包:  先确认http请求是否被发送
    1. App: Fiddler, charles, 云代理,
    2. 浏览器: 开发者工具, firebug等

    抓包的时候要注意依次辨别domain, path和请求参数的值,是否正确

  2. 查看日志:
    1. 应用运行日志: logs/appname/error.log, exception.log
    2. 应用启动日志: usr/local/tomcat|dubbo|jar/springboot/logs/目录下
    3. 查看实时日志: tail -f *.log
    4. 根据关键字搜索日志: grep key *.log

前端常见问题:

  1. 功能bug
  2. web: js缓存没有更新
  3. ajax请求参数拼装错误
  4. 等等

cap常见问题:

  1. URL格式非法: 返回http 400
  2. Api在缓存在不存在http 405
  3. Ip限制加入黑名单: cap 140
  4. 系统参数校验失败: cap 101
  5. 熔断: cap 154

所有的cap错误类型, 请参考错误码 或者 ErrorCodeEnum.java

dubbo接口排查:

  1. 从dubbo admin中查看应用和接口是否有提供者和消费者
  2. 核对调用方与dubbo提供方的dubbo接口版本是否一致

后台模块常见问题原因:

  1. 部署错误的代码分支
  2. 应用没有被启动, 或者启动报错了
  3. cdiamond新配置没有添加,或者值错误
  4. 服务器etc/caocao/app/config.properties配置值错误或者遗漏
  5. 数据库变更脚本没有执行
  6. kafka topic没有被添加
  7. 等等

终极定位bug方法:

  1. 了解系统架构, 系统架构图: 整体系统架构
  2. 代码调试: 本地调试(客户端,服务端),远程调试

如何提出高质量bug

发现bug是测试人员必须具备的能力,不管在什么公司,测试人员在执行测试任务的时候,发现bug和提bug,以及跟踪Bug是必要的工作。如何提出高质量的bug,是体现测试人员水平的重要标志。从功能测试人员,到测试开发,高级测试开发等,都避免不了与bug打交道。可是现在也存在这么一种现象:测试人员提的bug质量不高,开发人员看不明白。于是就来找测试人员,来解释这个bug是怎么回事,如此来回折腾浪费工作时间,在跨部门协作的时候,这样的情况尤其严重。

测试人员提bug质量不高,主要表现在如下几个方面:

(1)bug表述不清,只有一句话,介绍bug是什么,然后没有其他的说明。

(2)不提bug,发现问题直接告诉开发人员,在工作交流平台上不断讨论bug。

(3)发现bug的场景没有保留,重现成本较高。

针对上面的各种情况,我们测试人员要不断地提高相应的能力,提出高质量的bug。如何提出高质量的bug呢?

一,熟悉Bug管理工具

每个公司不管规模大小,都应该有bug管理平台,如jira,禅道,teambition,或是公司自主研发的项目管理平台;只要我们通过相应的平台来管理项目,bug等,要想更好地提bug必须先全面了管理平台的功能。很难想象,如果你相应的管理平台都不会用,如何更好的辅助测试呢?

二,准确地给bug定级

根据bug的影响,每个公司会定不同的bug分级标准。如p0,p1,p2,p3,或是致命,严重,一般,低级与建议,或者A,B,C,D。作为测试人员必须了解相应的分析标准,在发现bug后才能准确地给bug定位,从而影响bug的修改优先级。

(更多…)

接口测试全流程扫盲

接口测试全流程扫盲

  接口测试全流程扫盲
  扫盲内容:
  1.什么是接口?
  2.接口都有哪些类型?
  3.接口的本质是什么?
  4.什么是接口测试?
  5.问什么要做接口测试?
  6.怎样做接口测试?
  7.接口测测试点是什么?
  8.接口测试都要掌握哪些知识?
  9.其他相关知识?
  1.什么是接口?
  接口测试主要用于外部系统与系统之间以及内部各个子系统之间的交互点,定义特定的交互点,然后通过这些交互点来,通过一些特殊的规则也就是协议,来进行数据之间的交互。
  2.接口都有哪些类型?
  接口一般分为两种:1.程序内部的接口 2.系统对外的接口
  系统对外的接口:比如你要从别的网站或服务器上获取资源或信息,别人肯定不会把数据库共享给你,他只能给你提供一个他们写好的方法来获取数据,你引用他提供的接口就能使用他写好的方法,从而达到数据共享的目的。
  程序内部的接口:方法与方法之间,模块与模块之间的交互,程序内部抛出的接口,比如bbs系统,有登录模块、发帖模块等等,那你要发帖就必须先登录,那么这两个模块就得有交互,它就会抛出一个接口,供内部系统进行调用。
  接口的分类:1.webservice接口 2.http api接口
  webService接口是走soap协议通过http传输,请求报文和返回报文都是xml格式的,我们在测试的时候都用通过工具才能进行调用,测试。
  http api接口是走http协议,通过路径来区分调用的方法,请求报文都是key-value形式的,返回报文一般都是json串,有get和post等方法,这也是最常用的两种请求方式。
  json是一种通用的数据类型,所有的语言都认识它。(json的本质是字符串,他与其他语言无关,只是可以经过稍稍加工可以转换成其他语言的数据类型,比如可以转换成Python中的字典,key-value的形式,可以转换成JavaScript中的原生对象,可以转换成java中的类对象等。)
  3.接口的本质及其工作原理是什么?
  接口你可以简单的理解他就是URL,工作原理就会说URL通过get或者post请求像服务器发送一些东西,然后得到一些相应的返回值,本质就是数据的传输与接收。
  4.什么是接口测试?
  接口测试是测试系统组件间接口的一种测试。接口测试主要用于检测外部系统与系统之间以及内部各个子系统之间的交互点。测试的重点是要检查数据的交换,传递和控制管理过程,以及系统间的相互逻辑依赖关系等。
                –百度百科
  简答的说就是通过URL向服务器或者其他模块等,传输我们想传输的数据,然后看看他们返回的是不是我们预期想要的。
  5.问什么要做接口测试?
     1.越底层发现bug,它的修复成本是越低的。
     2.前端随便变,接口测好了,后端不用变,前后端是两拨人开发的。
     3.检查系统的安全性、稳定性,前端传参不可信,比如京东购物,前端价格不可能传入-1元,但是通过接口可以传入-1元。
   4.如今的系统复杂度不断上升,传统的测试方法成本急剧增加且测试效率大幅下降,接口测试可以提供这种情况下的解决方案。
   5.接口测试相对容易实现自动化持续集成,且相对UI自动化也比较稳定,可以减少人工回归测试人力成本与时间,缩短测试周期,支持后端快速发版需求。接口持续集成是为什么能低成本高收益的根源。
   6.现在很多系统前后端架构是分离的,从安全层面来说:
          (1)、只依赖前端进行限制已经完全不能满足系统的安全要求(绕过前面实在太容易), 需要后端同样进行控制,在这种情况下就需要从接口层面进行验证。
          (2)、前后端传输、日志打印等信息是否加密传输也是需要验证的,特别是涉及到用户的隐私信息,如身份证,银行卡等。
  6.怎样做接口测试?
  –由于我们项目前后端调用主要是基于http协议的接口,所以测试接口时主要是通过工具或代码模拟http请求的发送与接收。工具有很多如:postman、jmeter、soupUI、java+httpclient、robotframework+httplibrary等。
  –也可以用 接口自动化来实现,就是用代码实现,框架和UI自动化差不多,发送请求用断言来判断。
  7.接口测测试点是什么?
  目的:测试接口的正确性和稳定性;
  原理:模拟客户端向服务器发送请求报文,服务器接收请求报文后对相应的报文做处理并向客户端返回应答,客户端接收应答的过程;
  重点:检查数据的交换,传递和控制管理过程,还包括处理的次数;
  核心:持续集成是接口测试的核心;
  优点:为高复杂性的平台带来高效的缺陷监测和质量监督能力,平台越复杂,系统越庞大,接口测试的效果越明显(提高测试效率,提升用户体验,降低研发成本);
    用例设计重点:通常情况下主要测试最外层的两类接口:数据进入系统接口(调用外部系统的参数为本系统使用)和数据流出系统接口(验证系统处理后的数据是否正常);
    PS:设计用例时还需要注意外部接口提供给使用这些接口的外部用户什么功能,外部用户真正需要什么功能;
  问题1.1、后端接口都测试什么?
    –回答这个问题,我们可以从接口测试活动内容的角度下手,看一下面这张图,基本反应了当前我们项目后端接口测试的主要内容:
  问题2、后端接口测试一遍 ,前端也测试一遍,是不是重复测试了?
    –回答这个问题,我们可以直接对比接口测试和app端测试活动的内容,如下图为app测试时需要覆盖或考虑内容:
   从上面这两张图对比可以看出,两个测试活动中相同的部分有功能测试、边界分析测试和性能测试,其它部分由于各自特性或关注点不同需要进行特殊的测试,在此不做讨论。接下来我们针对以上三部分相同的内容再进行分析:
  1、基本功能测试:
  由于是针对基本业务功能进行测试,所以这部分是两种测试重合度最高的一块,开发同学通常所指的也主要是这部分的内容。
  2、边界分析测试:
  在基本功能测试的基础上考虑输入输出的边界条件,这部分内容也会有重复的部分(比如业务规则的边界)。但是,前端的输入输出很多时候都是提供固守的值让用户选择(如下拉框),在这种情况下测试的边界范围就非常有限,但接口测试就不存在这方面的限制,相对来说接口可以覆盖的范围更广,同样的,接口出现问题的概率也更高。
  3、性能测试:
  这个比较容易区分,虽然都需要做性能测试,但关注点确大不相同。App端性能主要关注与手机相关的特性,如手机cpu、内存、流量、fps等。而接口性能主要关注接口响应时间、并发、服务端资源的使用情况等。两种测试时的策略和方法都有很大区别,所以这部分内容是需要分开单独进行测试的,理论上来说这也是不同的部分。
  综论:
  1、接口测试和app测试的活动有部分重复的内容,主要集中在业务功能测试方面。除此之外,针对各自特性的测试都不一样,需要分别进行有针对性的测试,才能确保整个产品的质量。
  2、接口测试可以关注于服务器逻辑验证,而UI测试可以关注于页面展示逻辑及界面前端与服务器集成验证
  3、接口测试持续集成:
  对接口测试而言,持续集成自动化是核心内容,通过持自动化的手段我们才能做到低成本高收益。目前我们已经实现了接口自动化,主要应用于回归阶段,后续还需要加强自动化的程度,包括但不限于下面的内容:
    a) 流程方面:在回归阶段加强接口异常场景的覆盖度,并逐步向系统测试,冒烟测试阶段延伸,最终达到全流程自动化。
    b) 结果展示:更加丰富的结果展示、趋势分析,质量统计和分析等
    c) 问题定位:报错信息、日志更精准,方便问题复现与定位。
    d) 结果校验:加强自动化校验能力,如数据库信息校验。
    e) 代码覆盖率:不断尝试由目前的黑盒向白盒下探,提高代码覆盖率。
    f) 性能需求:完善性能测试体系,通过自动化的手段监控接口性能指标是否正常。
  4、接口测试质量评估标准:
    a) 业务功能覆盖是否完整
    b) 业务规则覆盖是否完整
    c) 参数验证是否达到要求(边界、业务规则)
    d) 接口异常场景覆盖是否完整
    e) 接口覆盖率是否达到要求
    f)  代码覆盖率是否达到要求
    g) 性能指标是否满足要求
    h) 安全指标是否满足要求
  8.接口测试都要掌握哪些知识?
  ①了解系统及内部各个组件之间的业务逻辑交互;
  ②了解接口的I/O(input/output:输入输出);
  ③了解协议的基本内容,包括:通信原理、三次握手、常用的协议类型、报文构成、数据传输方式、常见的状态码、URL构成等;
  ④常用的接口测试工具,比如:jmeter、loadrunner、postman、soapUI等;
  ⑤数据库基础操作命令(检查数据入库、提取测试数据等);
  ⑥常见的字符类型,比如:char、varchar、text、int、float、datatime、string等;
  如何学这些技能?
  ①系统间业务交互逻辑:通过需求文档、流程图、思维导图、沟通等很多渠道和方式;
  ②协议:推荐《图解http》这本书,内容生动,相对算是入门级的书籍,其他的还有《图解tcp、IP》等;
  ③接口测试工具:百度这些工具,然后你会发现,好多的教学博客、相关问题解决方案、以及一些基于工具的书籍,当然,选择合适的书很重要;
  ④数据库操作命令:学习网站(W3C、菜鸟教程)、教学博客,以及一些数据库相关书籍,入门级推荐:《mysql必知必会》、《oracle PL/SQL必知必会》等
  ⑤字符类型:还是百度,有句话这么说:内事不决问百度,外事不决问Google。。。
   如何获取接口相关信息?
  一般的企业,都会由开发或者对应的技术负责人员编写接口文档,里面会注明接口相关的地址、参数类型、方法、输入、输出等信息,如果没有,想办法获取。。。
  接口文档八要素:
  封面:封面最好是本公司规定的封面,有logo,内容标题,版本号,公司名称,文档产生日期;
  修订历史:表格形式较好些,包括:版本、修订说明、修订日期、修订人、审核时间审核人等;
  接口信息:接口调用方式,常用的GET/POST方式,接口地址;
  功能描述:简洁清晰的描述接口功能,比如:接口获取的信息不包括哪些;
  接口参数说明:每个参数都要和实际中调用的一样,包括大小写;参数的含义言简意赅的说明,格式,是string 还是int 还是long等格式;
              说明部分,说明参数值是需要哪里提供,并详细说明参数怎么生成的,例如时间戳,是哪个时间段的,参数是否必填,一些参数是必须要有的,有些是可选参数等;
  返回值说明:
  ①最好有一个模板返回值,并说明每个返回参数的意义;
  ②提供一个真实的调用接口,真实的返回值;
  调用限制,安全方面:
  加密方式,或者自己公司一个特殊的加密过程,只要双方采用一致的加密算法就可以调用接口,保证了接口调用的安全性,比如常见的md5;
  文档维护:文档在维护的时候,如有修改一定要写上修改日期,修改人,对大的修改要有版本号变更;
  9.其他相关知识?
  get请求,post请求的区别:
  1、GET使用URL或Cookie传参。而POST将数据放在BODY中。
  2、GET的URL会有长度上的限制,则POST的数据则可以非常大。
  3、POST比GET安全,因为数据在地址栏上不可见。
  4、一般get请求用来获取数据,post请求用来发送数据。
  其实上面这几点,只有最后一点说的是比较靠谱的,第一点post请求也可以把数据放到url里面,get请求其实也没长度限制,post请求看起来参数是隐式的,稍微安全那么一些些,但是那只是对于小白用户来说的,就算post请求,你通过抓包也是可以抓到参数的。(唯一区别就是这一点,上面3点区别都是不准确的)
  http状态码:
  1、200 2开头的都表示这个请求发送成功,最常见的就是200,就代表这个请求是ok的,服务器也返回了。
  2、300 3开头的代表重定向,最常见的是302,把这个请求重定向到别的地方了。
  3、400 400代表客户端发送的请求有语法错误,401代表访问的页面没有授权,403表示没有权限访问这个页面,404代表没有这个页面。
  4、500 5开头的代表服务器有异常,500代表服务器内部异常,504代表服务器端超时,没返回结果。
  webservice接口怎么测试:
  它不需要你在拼报文了,会给一个webservice的地址,或者wsdl文件,直接在soapui导入,就可以看到这个webservice里面的所有接口,也有报文,直接填入参数调用,看返回结果就可以了。
  天气预报wsdl地址:http://www.webservicex.net/globalweather.asmx?wsdl
  cookie与session的区别:
  1、cookie数据存放在客户的浏览器上,session数据放在服务器上。
  2、cookie不是很安全,别人可以分析存放在本地的cookie并进行cookie欺骗
  考虑到安全应当使用session。
  3、session会在一定时间内保存在服务器上。当访问增多,会比较占用你服务器的性能
  考虑到减轻服务器性能方面,应当使用cookie。
  4、单个cookie保存的数据不能超过4K,很多浏览器都限制一个站点最多保存20个cookie。
  5、所以个人建议:
  将登陆信息等重要信息存放为session
  其他信息如果需要保留,可以放在cookie中

(更多…)

接口测试方法论

此处需要回答的几个基本问题

  1. 既然已经在客户端上做了功能测试,为什么还要再做接口测试?是否重复劳动了?
  2. 接口测试更近一步的目的
  3. 怎么做接口测试

客户端测试与接口测试

拿App做例子, 开发一个App, 需要客户端开发(IOS和Android)与服务端开发. 客户端主要做页面交互相关的东西,服务端提供http接口供前端调用. 所以对应的,必然需要客户端和服务端接口的逻辑分别都做校验和测试. 因为任何一方的代码问题,都可能会导致程序行为出错.

举一个简单的例子来说明. 比如在app上输入手机号和6个密码进行登录这么一个功能.

如果你的用例是输入一个合法的手机号+正确的密码, 那么你将登录成功. 这个时候,客户端行为和服务端行为都是正确,并且一致的

如果你的用例是输入一个合法的手机号+5位数字的密码,那么在客户端上你点登录,很可能在端上直接被提示密码位数不足,请求无法提交. 但是5位数字的密码,也是接口测试的一个case

以下场景,是端上没法覆盖的:

  1. 对接口请求的频繁反复调用
  2. 对接口调用使用异常的参数
  3. 需要特殊的接口返回,端上不能制造数据的时候
  4. 接口越权调用
  5. 接口sql注入等
  6. 接口登录验证
  7. 接口非法数据,比如修改订单商品价格等
  8. 等等

总之,接口测试和端上的测试, 有少部分重复的测试. 但是,他们之间更多的还是差异,测试的侧重点不同.

在一个公司里, 不管测试是否分服务端和客户端. 服务端和客户端自己的特性,都是需要被充分测试到的.

接口测试的作用

如下作用:

  1. 用于回归测试,支持快速迭代,提高测试效率
  2. 有助于测试人员深入理解代码逻辑,发现更多问题
  3. 与端上的测试互补,能够覆盖端上覆盖不到的逻辑
  4. 学会定位问题,便于与开发同学沟通

怎么做接口测试

  1. Fiddler, charles等抓包工具
  2. Jmeter
  3. 写代码Java, python等

CaocaoTest框架接口测试总结(Dubbo接口)

Caocaotest是基于testng的接口测试框架,通过dubbo框架可以直接对后台接口进行调用,无需校验session,稳定性和便利性都大于http接口。

1、 环境配置(eclipse)

右击caocaotest >properties

根据需要可以配置,33、44、55、stable等环境

框架会根据配置读取对应的环境配置文件

2、 获取dubbo接口名

测试前首先要问开发要所需测试的接口名,并在dubbo admin上查询,确保该接口已经正常运行在服务器上

dubbo admin地址

33:http://101.37.36.67:2080      root:admin_caocao1818

44:http://116.62.106.235:2080    root:admin_caocao1818

55:http://116.62.106.188:2080/    root:admin_caocao1818

Stable:http://101.37.82.41:2080/  root/admin_caocao1818

3、 配置dubbo xml

创建xml配置文件,命名可以参考已有的配置文件

然后copy其他的配置,重点修改这一段,配置要测的dubbo接口

版本号的配置会去配置文件里读取,配置文件:

注:如果是以上方式的话,读取的是步骤1中配置环境对应的配置文件里的参数。如果没有的话,去配置文件里加,例子如下

4、 配置数据库(不需要操作数据库可以略过)

Src/test/resources/applicationContext.xml中配置DB

Step1环境配置文件中配置url,用户名密码默认已在配置文件中。

5、 创建测试套(fleet.dubbo为例)

新建package,然后创建基类脚本

内容如下:

6、 创建excel参数(用excel取参数的话,你也可以用别的方法)

Excel中填写所需的参数

正文中取参数方法,

7、 脚本正文

以下是例子

monkey使用分享

1、环境部署:
Windows:http://www.cnblogs.com/ydnice/p/5788058.html
Mac:http://blog.csdn.net/rwang99/article/details/48292341

2、执行命令: http://www.cnblogs.com/zyanrong/p/5417535.html
adb shell monkey -p cn.businesstravel.user –ignore-crashes –ignore-timeouts –ignore-native-crashes –pct-touch 30 -s 1 -v -v –throttle 200 100000 2>C:\Users\paddy\Desktop\error.txt 1>C:\Users\paddy\Desktop\info.txt
参数 描述
-p com.lenovo.ideafriend 只仅针对特定包名进行测试
–ignore-crashes 忽略应用程序崩溃(Force & Close错误),继续发送执行事件,直到事件数执行完成
–ignore-timeouts 忽略应用程序发生ANR(Application No Responding)错误时,直到事件数执行完成
–ignore-native-crashes 忽略本地应用程序发生奔溃,直到事件数执行完成
–pct-touch 30 调整触摸事件为30%。即整个事件过程中触摸事件占30%
-s 1 伪随机数生成器seed值。Seed值为1。相同的seed值再次执行monkey,将产生相同的事件序列
-v -v 日志级别为Leve1 1。将提供较为详细的日志,包括每个发送到Activity的事件信息
–throttle 200 事件之间延时200毫秒。可以控制monkey的执行速度,如果不指定该选项,monkey事件间将不会延时
100000 执行事件数为10万次
2>/sdcard/error.txt Leve1 2日志保存到sdcard上的error.txt中
1>/sdcard/info.txt Leve1 1日志保存到sdcard上的info.txt中

3、扩展一:
0:触摸事件百分比,即参数–pct-touch
1:滑动事件百分比,即参数–pct-motion
2:缩放事件百分比,即参数–pct-pinchzoom
3:轨迹球事件百分比,即参数–pct-trackball
4:屏幕旋转事件百分比,即参数–pct-rotation
5:基本导航事件百分比,即参数–pct-nav
6:主要导航事件百分比,即参数–pct-majornav
7:系统事件百分比,即参数–pct-syskeys
8:Activity启动事件百分比,即参数–pct-appswitch
9:键盘翻转事件百分比,即参数–pct-flip
10:其他事件百分比,即参数–pct-anyevent

4、日志: http://blog.csdn.net/qinglang0213/article/details/50014663 https://www.zhihu.com/question/31685044
0:无响应问题可以在日志中搜索 “ANR” ,
1:崩溃问题搜索 “CRASH” ,
2:内存泄露问题搜索”GC”(需进一步分析),
3:异常问题搜索 “Exception”(如果出现空指针, NullPointerException,需格外重视)

Dubbo接口性能测试文档

一、接口协议文档

 

二、编写CarInfoApi.findByDriverNo接口性能脚本

2.1. 导入项目所需要的jar包

2.2. 初始化

2.3. 参数化

2.4. jmeter调用接口

 

三、将项目打成 jmeter-dubbo.jar

 

四、将jmeter-dubbo.jar放置到apache-jmeter-3.1\lib\ext目录下

 

五、选择要压测的类名称,并进行压力测试

Fiddler断点的使用

一、准备工作:

1、Fiddler的安装

链接:http://pan.baidu.com/s/1miSNKla
密码:1c1s

⚠️注意:此链接包含证书文件,如果不适合使用请另行下载

2、参数配置

(1)对PC(笔记本)参数进行配置

配置fiddler允许远程连接:

打开Fiddler菜单项Tools->Options->HTTPS

勾选CaptureHTTPS CONNECTs,

勾选Decrypt HTTPS traffic(下拉框建议选择…..from all processes)Ignore servercertificate errors两项,点击OK(主要是为了可以获取http和Https信息),见图:

     

 

配置fiddler允许远程连接:

上一步窗口中点击Tools->Options->Connections,勾选allow remote computers to connect,默认监听端口为8888(下图Fiddler listens on port就是端口号),若端口被占用可以设置成其他的,配置好后要重新启动fiddler,如下图:

(2)证书安装:

手机和电脑连接同一个网络,打开手机浏览器,输入http://ip:端口号,点击前往下载证书,可能需要设置手机锁屏密码;见下图:

     

二、进行断点操作:

通过Fidller有三种方法修改返回结果:

 

第一种:在AutoRespnder里Add Rule,然后在Rule Editor里设置response的内容;

 

第二种:在Fiddler底部的黑色命令行显示区域通过bpu url的形式按回车之后进行拦截,通过手机app访问指定接口,拦截到后可以选择response文件后通过拦截;

 

第三种:在Rules设置中选择Automatic Breakpoints中的After Responses进行拦截。

⚠️注意:前两种方法当程序运行到断点处的时候都会停止,需要手动点击“Run to Completion”重新启动,非常不方便。所以实际测试拦截请求中,最灵活、功能最强的是第二种。

例子,比如修改

1. 抓包,找到要拦截的请求,然后在AutoResponder中Add Rule(或者直接拖拽需要拦截的请求):
2. 在Rule Editor中的第二栏选择“Create New Response…”(也可以在此右击直接修改):
3. 点击Save,会弹出一个窗口,在弹窗中选择Raw栏,将抓包抓到的请求对应的Raw栏内容复制粘贴进去,然后将其中想要修改的部分进行修改,然后点击“Save”进行保存:
4. 如果想要频繁修改替换返回体中某些内容,可以在AutoResponder里相应待拦截请求上点击右键,“Edit Response”编辑返回体:
5、再次请求:
总结:话说用完Charles的断点功能,感觉Fiddler的断点太难用了。。。。。