从外部看,性能测试主要关注如下三个指标:
吞吐量:每秒钟系统能够处理的请求数、任务数
响应时间:服务处理一个请求或一个任务的耗时
错误率:一批请求中结果出错的请求所占比例
从服务器的角度看,性能测试主要关注CPU、内存、服务器负载、网络、磁盘IO等。
1.确定关键业务,关键路径;
2.确定测试的关键数据。比如并发量,响应时间,循环次数等;
3.准备测试环境,完成脚本录制或脚本开发;
4.执行测试,观察或监控输出参数,比如吞吐量,响应时间,资源占有率等;
5.对执行结果进行分析,分析性能问题。
1.查看聚合报告和服务器的资源使用图,检查响应时间,事务成功率,CPU,内存和IO使用率是否达到要求,如果出错率达到了总请求的3%,我们会检查是什么原因导致的,修改好后,重新测试;
2.如果出现了性能瓶颈,比如响应时间,或者CPU使用率不达标,我们会从服务器上导出日志,分析是哪个地方导致响应时间过长,如果分析不出来,就叫上开发一起讨论,确定问题后,就提单给代发修复,修复好了就进行回归测试。
查看在整个性能测试过程中,网络的吞吐量是多少,如果网络的吞吐量占到了服务器的70%以上,我们就认为网络存在瓶颈,通常会增加带宽或者压缩传输数据。
根据性能测试结果先检查看下是否是服务器带宽存在问题,如果带宽存在瓶颈,则会考虑增加带宽或者压缩传输数据,如果带宽没有问题的话,我们会从服务器上导出日志,开发一起讨论分析是哪个地方导致响应时间过长,确定问题后,就提单给开发修复,修复好了就进行回归测试。
CPU使用率不达标,我们会从服务器上导出日志,分析是哪个地方导致CPU使用率不达标,如果分析不出来,就叫上开发一起讨论,确定问题后,就提单给开发修复,修复好了就进行回归测试。
APP的性能测试分为服务器端的性能和手机端的性能。
服务器端的性能:jmeter工具进行测试的,和web端性能测试的方法一样的。
手机端APP的稳定测试:使用monkey做。
1.先使用 adb logcat -c 清空手机的logcat日志;
2.接下来使用 adb logcat -v time 获取logcat 日志,并导入本地文件使用 monkey 运行被测应用 adb shell monkey -p 包名 -v 3.100000 并将执行结果导入到本地测试;
4.如果中途失败了就要去看monkey日志中有没有crash或者anr的关键字;
5.如果还需要定位到是什么原因导致的anr或者crash的问题,将相关日志和logcat日志与进程号提交给开发定位;
6.如果是anr的问题,还需要从安卓中获取/data/anr/traces.txt文件提交给开发定位。
线程阻塞,内存不足,CPU满负荷(现在手机基本都是8核CPU,基本不会出现CPU满负荷的情况)
空指针值,数组越界,内存不足,CPU满负荷(现在手机基本都是8核CPU,基本不会出现CPU满负荷的情况)
1.设备碎片化:由于设备极具多样性,App在不同的设备上可能有不同表现形式;
2.宽带限制:宽带不佳的网络对App所需的快速响应时间不够;
3.网络的变化:不同网络的切换可能会影响App的稳定性;
4.内存管理:可能内存过低,或者是授权的内存位置的使用可能会导致App失败;
5.用户过多:连续数量过多可能会导致App崩溃;
6.代码错误:没有经过测试的新功能,可能会导致App在生产环境中失败;
7.第三方服务:广告或弹出屏幕可能会导致App崩溃。
adb install(apk的文件路径) 安装软件到手机或者模拟器
adb uninstall(包名) 卸载手机或模拟器上的某款软件
adb devices 查看与当前电脑连接的移动设备
adb ,adb start-server 启动
adb,adb kill-server 杀死
adb logcat 查看日志
adb logcat -v time process >
adb install -r xx.apk 覆盖低版本的
adb install -r -d 覆盖高版本的
adb shell dumpsys cpuinfo 查看手机cpu的使用情况
adb shell getprop|findstr dalvik 手机系统自己运行的内存使用
Adb shell monkey -p 包名
Adb-shell–ignore-crashes 忽略崩溃
Adb-shell–ignore-timeouts 忽略延时
Adb-shell–ignore-throttle 延时毫秒值
Adb-shell–pct-touch–pct-motion 触摸与滑动事件的比例
1.2G的网速150kbps,折合下载速度15-20k/s
2.3G的网速1-6mbps,折合下载速度120k/s-600k/s
3.4G的网速10-100mbps,折合下载速度1.5m/s-10m/s
4.使用真实的SIM卡,运营商网络来进行测试
5.通过代理的方式模拟弱网环境下进行测试(Charles延迟)
6.链接模拟弱网的热点进行测试(如360WiFi助手可以设置)
1.后端完成开发,输出接口文档;
2.前端开发和后端开发进行前后端联调,结束后后端开发人员提测接口;
3.测试人员进行接口测试;
4.进行验收测试;
5.利用持续集成技术进行持续的校验。
1.通过性验证:保证接口好使,能正常传入且返回正确的结果;
参数组合:有必传项时检查必传项;
接口安全:
a.验证(比如商品价格不能被外部修改)
b.身份授权(商品必须商家本人才能修改)
c.是否加密(用户名密码加密)
d.复杂程度校验
2.根据业务逻辑来设计用例
3.工具:postman和jmeter。一般用postman测接口,jmeter也能侧,但一般不用。
先看接口文档,根据接口文档进行测试,包含接口的URL,请求参数,响应结果。
如果没有接口文档,就自己抓包。我们是用jmeter来做接口测试的,首先,要新建一个线程组,在线程组下面添加一个http请求,然后填写好服务器地址,接口路径,请求方式,请求参数。
如果需要参数化,先在本地创建一个TXT文档,把参数填写到文档里面,在jmeter中添加一个csv文件设置,填写好TXT文档的路径,然后在请求参数中使用json提取器把token值关联出来
然后在下单接口中使用${参数名}的方式引用;接下来添加断言,检查服务器返回的结果和预期结果是不是一致的。最后,添加查看结果数查看测试结果。
1.有一部分是重叠的,UI测试是通过前端写的界面,是来调用接口的,而接口测试是直接调用接口;
2.排除前端的处理逻辑与调用的正确性,在理论上接口测试是可以覆盖所有的UI测试,但实际中,如几口层覆盖所有的业务流,在UI上只测试前端的逻辑
而最终的结果会忽视很多原有的功能点,导致了UI测试的不充分,那么会存在人多分工且实践充分的时候可以尝试接口去做业务流的全覆盖,否则不要轻易地去尝试。
...