测试实战(接口+性能+APP+自动化)
一、接口测试篇
1、接口测试是怎么做的?
我以下单这个接口说下吧:下单这个接口用的是http协议,使用post请求方式,发送给服务器的参数有token,产品ID,购买数量,收货人地址等等,这些参数都是必传的参数。我们是使用Jmeter来做接口测试的,首先,要新建一个线程组,在线程组下面添加一个http的请求,然后填写好服务器地址,接口路径,请求方式,请求参数。由于下单的接口依赖于等于,所以我们会先调用登录接口,从中获取token值,在下单接口中使用${参数名}的方式引用,接下来还要对其他参数进行参数化,构造各种正常和异常的数据,我们先在本地创建一个txt文档,把参数填写到文档里面,在Jmeter中添加一个csv文件设置,填写好txt文档的路径,然后在请求参数中使用Json提取器把token值关联出来,然后在下单接口中使用${参数名}的方式引用;接下来添加断言,检查服务器返回的结果和预期结果是不是一致的。最后,添加查看结果树查看测试结果。
2、JMeter测试环境怎么搭建
-
因为JMeter是JAVA程序开发的,所以要先安装JDK;
-
配置JAVA环境变量,包括:JAVA_HOME,PATH,CLASSPATH;
-
双击jmeter的bin目录里面的jmeter.bat文件,就可以启动Jmeter。
3、什么时候会用到使用Fiddler
-
做安全测试,检测敏感信息是否加密,拦截篡改数据;
-
当测试时发现缺陷,用fiddler抓包,定位该问题是前端还是后台的问题;
-
模拟弱网环境;
-
统计单个功能的响应时间。
4、Fiddler怎么拦截篡改数据
-
就拿下单来说吧,点击下单之前,先启动Fiddler,按F11打断点,将请求拦截下来,
-
然后在fiddler中,对拦截下来的请求,修改其中的数据,比如将价格或者商品数量进行修改
-
修改完成后,关闭拦截,继续请求的发送即可。
5、Fiddler怎么模拟弱网测试
-
点击规则-->自定义规则,打开fiddler的脚本编辑器,找到simulateModem
-
设置上传和下载的延时速度
-
点击规则-->性能,选模拟带宽
6、fiddler如何模拟2g/3G的网络
2G一般上行/下行速率约为:2.7、9.6kbs,模拟设置为:uploaded 约 2962 ms,downloaded 约 833 ms;(弱网一般指2G网络)
3G一般上行/下行速率约为:384、2560kbs,设置为:uploaded 约 2.6 ms,downloaded 约 0.39 ms;
7、Fiddler怎么抓HTTPS的包
-
安装安全证书;
-
点击fiddler的Tools-->options-->https
-
勾选上所有选项,更换证书,重启fiddler
8、在进行接口的自动化测试,如果遇到token校验,怎么处理的?
首先需要获取token,获取token的整个思路为:
-
先进行登录
-
登录成功后
-
获取token
-
把获取的token当作下一个接口的请求参数
-
上面这个题目可以这样延伸:有一个接口A,发送给服务器的数据需要从接口B中获取,怎样对A接口进行测试?
参考答案:
-
在A接口前面添加接口B,在B接口中添加Json提取器,把A接口需要用到的数据关联出来,保存到参数中;
-
在A接口中使用${参数名}的方式进行引用。
9、Jmeter的断言怎么做?
选中需要断言的请求,右键,选择响应断言,在响应断言输入框中添加要断言的值;如果这个接口有多个请求数据,针对每个请求数据服务器返回数据都不一样的,这时候,我们就要把断言的值进行参数化,步骤是:现在本地添加一个txt文档,把参数化的值写入文档里面,然后再在jmeter选中需要断言的请求,右键,添加CSV文件设置,把刚才编辑好的txt文档添加进来,在响应断言输入框中使用${字段名}的方式来引用参数的值。
10、接口出错了怎么办?
首先,我会先检查一下请求参数啊,还有其他的填入的数据是否有问题,如果这些都没问题,我会ping一下网络,看网络通不通,如果网络也没问题的话,我会去看看系统服务器有没有启动,如果服务器也没问题的话,那可能就要发给开发定位一下了。
11、接口测试用例怎么写?
我们每个版本都会有四五个接口需求,有的是新增的接口,有的是原来的接口做了一些调整,我们会查看这些接口有哪些参数,每个参数有什么约束条件,加密方式是什么,正常和异常的响应信息有哪些,然后编写测试用例来覆盖这些需求,一个版本下来大概有五六十条接口测试用例。
12、接口有哪些参数?
比方说:下单接口,会有token,产品ID,购买数量,收货人地址,收件人电话等等;注册接口,会有手机号,密码,验证码这些参数;我们项目的接口有五六十个,每个接口实现的功能不一样,参数是不一样的。
13、接口的状态码有哪些
接口不一样,返回的状态码也不一样,我们接口的状态码是由开发统一定义的,比如,我们xxx这个项目,修改昵称这个接口,成功修改的状态码是0,30001表示token无效,30002表示用户不存在,还有30003等一些其他的状态码,具体意思记不太清楚了。
14、能说一下第三方支付接口的流程吗
首先用户下订单,网站后台就会生成一个支付请求发送到第三方支付平台;支付平台收到请求后会直接发送响应给用户,展示金额等,并且要求用户输入账号密码,用户输入信息直接发送到第三方平台;付款成功后第三方平台会返回支付结果给到网站后台和用户;后台收到付款成功信息后就会生成付款成功的订单信息发给用户;大概的流程就是这样。
15、Fiddler怎么抓手机app的包?
-
手机与fiddler所在的电脑连接到同一网络;
-
在fiddler设置监听端口,并允许远程终端连接;
-
在手机上填写代理服务器的地址和端口。
16、为什么要做接口测试 / 接口测试的目的
-
尽早介入测试,早发现bug,降低修复成本
-
UI界面测试无法发现底层问题
17、接口的加密如何处理
一般来说的话加密都是开发那边会给到加密的文档或者脚本给到我们,我们将参数进行加密后,然后再在Jmeter中填写。
二、性能测试篇
1、性能测试怎么做的?
-
做性能需求分析,挑选了用户使用最频繁的功能来做性能测试,比如:登陆,打开系统首页,搜索,提交订单,确定性能指标,比如:事务通过率为100%,90%的事务响应时间不超过3秒,CPU和内存的使用率为70%以下。
-
搭建性能测试环境,准备好性能测试数据。
-
使用Jmeter开发优化脚本,包括:参数化,断言,关联等。
-
设计性能测试场景,我们这个项目做了单用户单功能循环200次的基准测试,然后使用1500个用户,执行30分钟的负载测试,看系统有没有性能瓶颈;
-
我们搭建了分布式压力测试环境进行测试,每台压力机并发500个用户,并监控linux服务器的CPU,内存,IO。
-
分析性能测试结果,如果有性能瓶颈,收集相关的日志提单给开发修改。
-
开发修改好后,回归性能测试,然后输出性能测试报告。
2、如何确定系统能够承载的最大用户数?
通过负载测试,不断增加用户数,随着用户数的增加,各项性能指标也会相应产生变化,当出现了性能拐点,比如,当用户数达到某个数量级时,响应时间突然增长,那么这个拐点处对应的用户数就是系统能承载的最大用户数。
3、系统哪些地方(哪些功能)做了性能测试?
我们选用了用户使用最频繁的功能来做性能测试,比如:登陆,打开系统首页,搜索,提交订单。
4、性能测试什么时间做?
功能测试之后,系统比较稳定的时候再做。
5、怎样分析性能测试结果?
-
查看聚合报告和服务器的资源使用图,检查响应时间,事务成功率,CPU,内存和IO使用率是否达到要求,如果出错率达到了总请求数的3%,我们会检查是什么原因导致的,修改好后,重新测试;
-
如果出现了性能瓶颈,比如响应时间,或者CPU使用率不达标,我们会从服务器上导出日志,分析是哪个地方导致响应时间过长,如果分析不出来,就叫上开发一起讨论,确定问题后,就提单给开发修复,修复好了就进行回归测试。
7、如何判断网络是否存在瓶颈?
在性能测试结束之后,我们会根据性能测试的结果,查看在整个性能测试过程中,网络的吞吐量是多少,如果网络的吞吐量占到了服务器的70%以上,我们就认为网络存在瓶颈,通常会增加带宽或者压缩传输数据。
8、响应时间不达标
响应时间不达标的话,我们会根据性能测试结果先检查看下是否是服务器带宽存在问题,如果带宽存在瓶颈,则会考虑增加带宽或者压缩传输数据,如果带宽没有问题的话,我们会从服务器上导出日志,开发一起讨论分析是哪个地方导致响应时间过长,确定问题后,就提单给开发修复,修复好了就进行回归测试。
9、CPU使用率不达标
CPU使用率不达标,我们会从服务器上导出日志,分析是哪个地方导致CPU使用率不达标,如果分析不出来,就叫上开发一起讨论,确定问题后,就提单给开发修复,修复好了就进行回归测试。
10、性能测试需求哪里来的?
需求文档上有的,不过有时候不太合理,我们可能需要和BA进行讨论。比如,我之前做了一个公司内部用的OA系统的性能测试时,要求并发用户200人,我们整个公司都没有100人,很明显,做200人并发是没有必要的,后来,我们只做了50人并发。
11、有验证码的功能,怎么做性能测试?
1)、将验证码暂时屏蔽,完成性能测试后,再恢复。注意:屏蔽验证码是不会给性能测试的结果带来影响的。
2)、使用一个万能的验证码。
12、性能测试指标有哪些?
平均事务响应时间,90%的事务响应时间,TPS,CPU、内存
三、APP测试篇
1、app测试与web测试的区别
-
系统架构:web端系统,更新服务器,不需要更新客户端;APP如果更新了服务端,客户端也要更新并测试;
-
兼容性。Web端要考虑不同的浏览器内核进行测试(IE、chrome、Firefox),APP的兼容性要考虑选择主流的机型,不同的分辨率、尺寸, 以及不同的操作系统;
-
App要考虑交叉事件测试,安装,卸载,前后台切换测试;
-
App还要考虑界面操作,如:横竖屏切换,多点触控,事件触发区域。
2、怎么做app测试的?
测试前,先熟悉app的原型图和业务需求,确定测试点,开发做完接口之后,先做接口测试,App开发好后,先做一个冒烟测试,看看软件的基本功能是否可用,如果正常,我们再做功能测试,UI测试,兼容性测试,交叉事件测试,安装卸载测试等。
如果面试官问具体某个测试类型怎么,就要举例子加以说明。
比如:
UI测试:检查app的UI是否和原型图一致。
功能测试:xxxx
兼容性测试:xxxx
用户体验测试:xxxx
(补上app的8大测试点,并举例子说明)
功能,兼容性,用户体验,安全性,安装卸载升级测试,交叉事件,UI测试,性能测试。
3、App的性能测试怎么做的
App的性能分为服务器端的性能和手机端的性能。
服务器端的性能,我们用Jmeter工具进行测试的,和web的端性能测试方法一样的。
我们是用monkey做手机端App的稳定性测试的,使用monkey跑10万次,看它会不会出问题,如果出了问题,我们再定位原因,具体的做法是这样的:
-
在跑monkey前,先使用
adb logcat -c清空手机的logcat日志 -
接下来,使用
adb logcat -v time获取logcat日志并导入本地文件 -
使用monkey运行被测应用:
adb shell monkey -p 包名 -v 10万次并将执行结果导入到本地 -
测试完成后查看monkey日志,如果说它跑的次数跟我设的次数不一样.就说明monkey中途跑失败了。那我就要去看看monkey日志中有没有crash或者anr的关键字,如果有还需定位到是什么原因导致的anr或者crash的问题。并且将相关日志和logcat日志与进程号提交给开发定位,如果是anr的问题,还需要从安卓中获取/data/anr/traces.txt文件提交给开发定位。
4、用MONKEY做APP测试,怎么做的?如果有问题的话怎么定位?
-
在跑monkey前,先使用
adb logcat -c清空手机的logcat日志 -
接下来,使用
adb logcat -v time获取logcat日志并导入本地文件 -
使用monkey运行被测应用:
adb shell monkey -p 包名 -v 10万次并将执行结果导入到本地 -
测试完成后查看monkey日志,如果说它跑的次数跟我设的次数不一样.就说明monkey中途跑失败了。那我就要去看看monkey日志中有没有crash或者anr的关键字,如果有还需定位到是什么原因导致的anr或者crash的问题。并且将相关日志和logcat日志与进程号提交给开发定位,如果是anr的问题,还需要从安卓中获取/data/anr/traces.txt文件提交给开发定位。
5、APP出现ANR的原因
-
线程阻塞的
-
内存不足
-
CPU满负荷(由于现在的手机基本都是8核CPU,所以基本不会出现CPU满负荷的情况)
6、APP出现CRASH的原因
-
空值指针
-
数组越界
-
内存不足
-
CPU满负荷(由于现在的手机基本都是8核CPU,所以基本不会出现CPU满负荷的情况)
7、如何判断客户端还是后台的问题
-
一、客户端问题
-
文字,图片有误;
-
无法输入,按钮不可用;
-
抓包信息显示客户端发送的信息有误。
-
二、服务器端问题
-
通过抓包检查服务器返回的信息,如果信息有误,就可以断定是服务器的问题;
-
客户端向服务器发送信息后,服务器无响应。
四、自动化测试篇
1、自动化测试是怎么做的?
就拿简历上的xxx项目来说吧,在编写脚本前,我们会对系统进行评估,确认这个系统可不可以实现UI自动化,如果可以的话,就筛选出能实现自动化测试的用例,一般优先把冒烟测试用例的转为成脚本。我们是用selenium工具来实现自动化,采用python脚本语言,基于unittest框架进行用例的编写。比如,下单这个功能的脚本,我们是这样做的:首先,我们会构建一个测试工程,测试工程包含testcase,主要用来存放测试用例,report用来存放测试报告,其次我们会把用例中公共的部分封装到public中,最后用runAllCase的python文件运行项目自动化用例,脚本调试完后,我们会用jenkins持续集成工具,设置脚本每天晚上10点跑一遍脚本,跑完后生成html格式的自动化测试报告。
2、自动化脚本失败的原因
-
可能是测试环境的网络不稳定;
-
开发修改了代码没通知到测试人员修改脚本;
-
开发引入了新的问题。
3、测试脚本用到了哪些技术
元素定位,表单切换,模块调用,JS定位等等,脚本是基于python自带的unittest单元测试框架,采用了模块化方式编写,把复用性高的操作封装到公共模块中,如果脚本需要用到对应的操作,直接调用就可以了,如果元素发生变化,只需要调整元素封装的代码就可以了,提高测试用例的可维护性。
4、脚本怎么组织的?(编写自动化脚本,你的思路是什么?)
构建一个测试工程,测试工程包含testcase,主要用来存放测试用例,report用来存放测试报告,其次我们会把用例中公共的部分封装到public中,最后用runAllCase的python文件运行项目自动化用例。测试脚本使用的是python的unittest单元测试框架组织管理,将所有测试脚本通过单元测试框架组织起来运行,这样做的好处是,维护起来方便,可以生成测试html格式的测试报告,报告包括:测试用例,通过数,失败数。
5、自动化率多少
一般是30%到40%,这个没有固定的,我们是优先将优先级高的测试用例,比如,冒烟测试的测试用例转换成自动化脚本的,后面有时间的时候再不断补充,能写多少写多少。
6、unittest框架了解吗
unittest框架,由setUp()--环境预置,testCase()--- 测试用例 tearDown()----环境恢复,三大部分组成,unittest框架可组织执行测试用例,并且提供丰富的断言方法,判断测试用例是否通过,最终生成测试结果。
7、怎样用python连接mysql数据
我们之前主要是用python语言来写web端的自动化测试脚本,连接数据库的话,我们主要使用pymysql这个模块来进行连接的。一般在进行完自动化测试之后,我们会连接上数据库,将数据进行清除。
8、python的第三方模块/标准库有哪些
time,random,unittest,selenium,HTMLTestRunner
9、元素的属性值是动态变化的,怎么定位这个元素?
如果元素有属性值是动态变化的,我们就不要使用这个属性进行定位;我们可以使用这个元素的非动态变化,并且是唯一的值属性进行定位;也可以使用xpath或者css,使用层次+属性的方式定位。
五、经典测试举例篇
1.如何测试一个杯子
功能测试
-
能否装水,
-
除了装水, 能否装其他液体。比如可乐,酒精
-
能装多少ML的水
-
杯子是否有刻度表
-
杯子能否泡茶,跑咖啡
-
杯子是否能放冰箱,做冰块
7.杯子的材质是什么(玻璃,塑料,黄金做的)
界面测试
-
外观好不好看。
-
什么颜色
-
杯子的形状是怎么样的。
-
杯子的重量是多少
-
杯子是否有异味
-
杯子的图案是否合理
性能测试
-
能否装100度的开水
-
能否装0度冰水
-
装满水,放几天后,是否会漏水
-
杯子内壁上的涂料是否容易脱落。
-
杯子上的颜色是否容易褪色或者脱落
-
被一个大人压下,是否会碎
安全性测试
-
制作杯子的材料,是否有毒
-
放微波炉里转的时候,是否会爆炸, 或者杯子是否会熔化。
-
从桌子上掉到水泥地上是否会摔碎。
-
杯子是否容易长细菌
-
杯子是否有缺口,会划坏嘴巴
-
杯子内壁上的材料,是否会溶解到水中
-
杯子破碎后,是否会对使用者造成伤害
可用性测试
-
杯子是否容易烫手
-
杯子是否好端,好拿
-
杯子的水是否容易喝到
-
杯子是否有防滑措施
具体需求:
有一个登录页面,有一个账号和一个密码输入框,一个提交按钮。
此题的考察目的:
1、了解需求(测什么都是从了解需求开始);
2、是否有设计Test Case的能力;
3、是否熟悉各种测试方法;
4、是否有丰富的Web测试经验;
5、是否了解Web开发;
了解需求:
1、登录界面应该是弹出窗口式的,还是直接在网页里面;
2、账号长度和密码的强度(比如需要多少位、大小写敏感、特殊字符混搭等);
3、界面美观是否有特殊要求?(即是否要进行UI测试);
用例设计:
测试需求分析完成后,开始用例设计,主要可以从以下几个方面考虑:
功能测试(Function Test)
1、输入正确的账号和密码,点击提交按钮,验证是否能正确登录。(正常输入)
2、输入错误的账号或者密码,验证登录会失败,并且提示相应的错误信息。(错误校验)
3、登录成功后能否跳转到正确的页面(低)
4、账号和密码,如果太短或者太长,应该怎么处理(安全性,密码太短时是否有提示)
5、账号和密码,中有特殊字符(比如空格),和其他非英文的情况(是否做了过滤)
6、记住账号的功能
7、登录失败后,不能记录密码的功能
8、账号和密码前后有空格的处理
9、密码是否加密显示(星号圆点等)
10、牵扯到验证码的,还要考虑文字是否扭曲过度导致辨认难度大,考虑颜色(色盲使用者),刷新或换一个按钮是否好用
11、登录页面中的注册、忘记密码,登出用另一帐号登录等链接是否正确
12、输入密码的时候,大写键盘开启的时候要有提示信息。
13、什么都不输入,点击提交按钮,看提示信息。(非空检查)
界面测试(UI Test)
1、布局是否合理,2个Testbox和一个按钮是否对齐
2、Testbox和按钮的长度,高度是否符合要求
3、界面的设计风格是否与Ul的设计风格统一
4、界面中的文字简洁易懂,没有错别字。
性能测试(Performance Test)
1、打开登录页面,需要几秒
2、输入正确的账号和密码后,登录成功跳转到新页面,不超过5秒
安全性测试(Security Test)1、登录成功后生成的Cookie是否有HttpOnly(降低脚本盗取风险)2、账号和密码是否通过加密的方式,发送给Web服务器3、账号和密码的验证,应该是用服务器端验证,而不能单单是在客户端用javaScript验证4、账号和密码的输入框,应该屏蔽SQL注入攻击5、账号和密码的输入框,应该禁止输入脚本(防止XSS攻击)6、错误登录的次数限制(防止暴力破解)7、考虑是否支持多用户在同一机器上登录;8、考虑一用户在多台机器上登录。
可用性测试(Usability Test)
1、是否可以全用键盘操作,是否有快捷键
2、输入账号,密码后按回车,是否可以登录
3、输入框是否可以以Tab键切换
兼容性测试(Compatibility Test)
1、主流的浏览器下能否显示正常已经功能正常(IE6-11,FireFox.Chrome,Safari等)
2、不同的平台是否能正常工作,比如Windows,Mac
3、移动设备上是否正常工作,比如iPhone,Android
4、不同的分辨率

浙公网安备 33010602011771号