从外部看,性能测试主要关注如下三个指标:
吞吐量:每秒钟系统能够处理的请求数、任务数
响应时间:服务处理一个请求或一个任务的耗时
错误率:一批请求中结果出错的请求所占比例
从服务器的角度看,性能测试主要关注CPU、内存、服务器负载、网络、磁盘IO等。
确定关键业务,关键路径;
确定测试的关键数据。比如并发量,响应时间,循环次数等;
准备测试环境,完成脚本录制或脚本开发;
执行测试,观察或监控输出参数,比如吞吐量,响应时间,资源占有率等;
对执行结果进行分析,分析性能问题。
查看聚合报告和服务器的资源使用图,检查响应时间,事务成功率,CPU,内存和IO使用率是否达到要求,如果出错率达到了总请求的3%,我们会检查是什么原因导致的,修改好后,重新测试;
如果出现了性能瓶颈,比如响应时间,或者CPU使用率不达标,我们会从服务器上导出日志,分析是哪个地方导致响应时间过长,如果分析不出来,就叫上开发一起讨论,确定问题后,就提单给代发修复,修复好了就进行回归测试。
查看在整个性能测试过程中,网络的吞吐量是多少,如果网络的吞吐量占到了服务器的70%以上,我们就认为网络存在瓶颈,通常会增加带宽或者压缩传输数据。
根据性能测试结果先检查看下是否是服务器带宽存在问题,如果带宽存在瓶颈,则会考虑增加带宽或者压缩传输数据,如果带宽没有问题的话,我们会从服务器上导出日志,开发一起讨论分析是哪个地方导致响应时间过长,确定问题后,就提单给开发修复,修复好了就进行回归测试。
CPU使用率不达标,我们会从服务器上导出日志,分析是哪个地方导致CPU使用率不达标,如果分析不出来,就叫上开发一起讨论,确定问题后,就提单给开发修复,修复好了就进行回归测试。
APP的性能测试分为服务器端的性能和手机端的性能。
服务器端的性能:jmeter工具进行测试的,和web端性能测试的方法一样的。
手机端APP的稳定测试:使用monkey做。
先使用 adb logcat -c 清空手机的logcat日志;
接下来使用 adb logcat -v time 获取logcat 日志,并导入本地文件使用 monkey 运行被测应用 adb shell monkey -p 包名 -v ;
100000 并将执行结果导入到本地测试;
如果中途失败了就要去看monkey日志中有没有crash或者anr的关键字;
如果还需要定位到是什么原因导致的anr或者crash的问题,将相关日志和logcat日志与进程号提交给开发定位;
如果是anr的问题,还需要从安卓中获取/data/anr/traces.txt文件提交给开发定位。
线程阻塞,内存不足,CPU满负荷(现在手机基本都是8核CPU,基本不会出现CPU满负荷的情况)
空指针值,数组越界,内存不足,CPU满负荷(现在手机基本都是8核CPU,基本不会出现CPU满负荷的情况)
设备碎片化:由于设备极具多样性,App在不同的设备上可能有不同表现形式;
宽带限制:宽带不佳的网络对App所需的快速响应时间不够;
网络的变化:不同网络的切换可能会影响App的稳定性;
内存管理:可能内存过低,或者是授权的内存位置的使用可能会导致App失败;
用户过多:连续数量过多可能会导致App崩溃;
代码错误:没有经过测试的新功能,可能会导致App在生产环境中失败;
第三方服务:广告或弹出屏幕可能会导致App崩溃。
adb install(apk的文件路径) 安装软件到手机或者模拟器;
adb uninstall(包名) 卸载手机或模拟器上的某款软件;
adb devices 查看与当前电脑连接的移动设备;
adb adb start-server 启动;
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 触摸与滑动事件的比例
2G的网速150kbps,折合下载速度15-20k/s
3G的网速1-6mbps,折合下载速度120k/s-600k/s
4G的网速10-100mbps,折合下载速度1.5m/s-10m/s
使用真实的SIM卡,运营商网络来进行测试
通过代理的方式模拟弱网环境下进行测试(Charles延迟)
链接模拟弱网的热点进行测试(如360WiFi助手可以设置)
后端完成开发,输出接口文档;
前端开发和后端开发进行前后端联调,结束后后端开发人员提测接口;
测试人员进行接口测试;
进行验收测试;
利用持续集成技术进行持续的校验。
通过性验证:保证接口好使,能正常传入且返回正确的结果;
参数组合:有必传项时检查必传项;
接口安全:
①绕过验证(比如商品价格不能被外部修改)
②绕过身份授权(商品必须商家本人才能修改)
③参数是否加密(用户名密码加密)
④密码复杂程度校验
根据业务逻辑来设计用例
工具:postman和jmeter。一般用postman测接口,jmeter也能测,但一般不用。
先看接口文档,根据接口文档进行测试,包含接口的URL,请求参数,响应结果。如果没有接口文档,就自己抓包。我们是用jmeter来做接口测试的,首先,要新建一个线程组,在线程组下面添加一个http请求,然后填写好服务器地址,接口路径,请求方式,请求参数。如果需要参数化,先在本地创建一个TXT文档,把参数填写到文档里面,在jmeter中添加一个csv文件设置,填写好txt文档的路径,然后在请求参数中使用json提取器把token值关联出来,然后在下单接口中使用${参数名}的方式引用;接下来添加断言,检查服务器返回的结果和预期结果是不是一致的。最后,添加查看结果数查看测试结果。
1.有一部分是重叠的,UI测试是通过前端写的界面,是来调用接口的,而接口测试是直接调用接口;
2.排除前端的处理逻辑与调用的正确性,在理论上接口测试是可以覆盖所有的UI测试,但实际中,如几口层覆盖所有的业务流,在UI上只测试前端的逻辑,而最终的结果会忽视很多原有的功能点,导致了UI测试的不充分,那么会存在人多分工且实践充分的时候可以尝试接口去做业务流的全覆盖,否则不要轻易地去尝试。
有些公司没有标准的接口文档,只能通过抓包获取接口信息;
通过抓包可以查看整个请求过程以及相应过程,从而分辨是前台bug还是后台bug;
可以查看是否有敏感信息泄漏;
抓包进行测试,拦截请求,修改请求数据,查看响应结果本来就是接口测试的一部分。
如Charles,Fiddler,LightProxy
在工具设置http代理,设置端口号,在手机上设置同一网段,设置代理IP,设置代理端口,手机上的请求就可以抓取到了。
可以设置过滤,找到自己域名下的请求,通过分析请求地址,请求参数,响应结果来查找问题。
https,下载证书就可以抓取到请求了。
打开jmeter;
创建线程组;
设置线程数和循环次数;
配置元件;
配置我们需要进行测试的程序协议、地址和端口;
构造http请求;
添加http请求头;
添加断言;
添加查看结果树;
添加Summary Report;
执行测试计划,执行测试计划不能用GUI,需要用命令来执行;
web报告。
1.在jmeter的线程组中分别添加JDBC Connection Configuration,JDBC Request,Debug Sampler,查看结果树。
2.在测试计划中将连接mysql需要的包加到classpath中。
3.在JDBC Connection Configuration中添加JDBC的配置。
做压力测试时,我们经常需要替换参数,在jmeter中,有多种参数化的形式。可以在测试计划中设置全局参数,可以设置用户参数,还可以在前置处理器中设置用户参数。在进行多线程并发的时候,如果需要多个参数,可以使用csv配置元件。比如做登录操作,后台有可能会限制一个用户不能重复登录多次,如果演示登录的并发操作,可以使用jmeter中的csv元件,将用户信息导出来,放到文件中,就可以让线程共享这些数据。另外,对于一些随机变化的参数,可以使用jmeter中的函数助手,生成随机函数,进行参数化测试。比如注册这样的操作,用户名要求唯一的,那就可以使用随机函数模拟出来。
当测试接口的时候,发现某个接口性能比较差,需要进一步判定问题的时候,会压测数据库。压测数据库需要配置驱动,设置连接池大小,需要使用sql去操作数据库。具体的哪条sql问题需要问开发要具体的sql进行压测。
用例组织不同:jmeter的组织是比较偏扁平,首先它没有工作空间的概念,直接就是测试计划,而postman功能上更简单,组织方式是轻量级,他主要针对的是单个的http请求。
支持接口的类型与测试的类型不同:jmeter的功能更强大,可以通过各种类型的接口,不支持的页可以通过网上或者自己编写的插件进行扩展,而postman更轻量级,定位不同,可用来测试rest接口。
配置不同:jmeter可以在线程组里添加http,tcp,而postman只支持rest接口。
用它来做接口测试。
查看接口的返回结果;
查看接口是get请求还是post请求;
数据库语言最常用的是SQL
多表联查:select * from table1 t1,table2 t2 where tl.id=t2.id这样就是多表联查。
left join,right join,inner join
#增
alter table 数据表名 add birthday datetime;
#删
alter table 表名 drop 列名;
#改
1.修改字段,不重命名,用modify
alter table 数据表名 modify birthday date;
2.修改字段,重命名,用change
alter table 表名 change 原名 新名 类型及约束
alter table 数据表名 change birthday birth date;
#查
查询表使用数据 select * from 表名;
部分查询 select * from 表名 where 条件;
可以使用as 为列表指定别名
select 字段 as 别名,字段 as 别名 from 数据表名 where…;
内关联是求交集
外关联是以主表为标准,去附表找需要的信息
不能,脚本需要通过Windows调试好之后,才能在Linux上运行,运行的时候,只能通过non GUL的形式进行启动jmeter,但需要注意的是,csv文件在Windows上与Linux上要统一路径,最好使用相对路径,放到统一目录下边。
cd:进入目录
cd app:切换到app目录
cd… :切换到上一层目录
cd /:切换到系统根目录
tail -10 a.txt:查看后10行数据
ifconfig:查看ip
ll:查看文件及其属性
vi:编辑
rm-rf:删除
car:解压及压缩命令
cp:复制
mv:移动
touch:创建文件
tail logcat:查看日志
cat logcat:查看日志
tail:查看日志记录信息,tail -f catinalia out
tar -xvf 文件名 :解压
tar -n logcat:查看系统日志
tar -zcvf 文件名:压缩
显示,管理执行中的程序,就是任务管理器
通过脚本代替一些手动化测试的步骤。unittest, web端:selenium ;app端:appium
find_element_by_id()(常用)
find_element_by_name()(常用)
find_element_by_class_name()
find_element_by_tag_name()
find_element_by_link_text()
find_element_by_partial_link_text()
find_element_by_xpath()(常用)
find_element_by_css_selector()
我们的电脑(c端)上运行自动化测试脚本,调用的是appium的webdriver的接口,appium服务器(s端)接收到我们client上发送过来的命令后,它会将这些命令转换为UIautomator认识的命令,然后由UIautomator来在设备上执行自动化。
用户程序安全;
系统网络安全;
数据库安全。
覆盖用户的需求;
从用户使用场景触发,考虑用户的各种正常和异常的使用场景;
用例的颗粒大小要均匀。通常,一个测试用例对应一个场景;
用例各个要素要齐全,步骤应该足够详细,容易被其它测试工程师读懂,并能顺利执行;
做好用例评审,及时更新测试用例。
首先进行需求分析,用XMind梳理测试点,再编写案例,之后就进行案例评审,寻求他人意见。之后再完善案例,发出来给其他人检查。
测试点,首先是UI方面,美观度和易操作性,易理解性方面进行测试。
然后再考虑其他功能点,注册登录,添加购物车,下单,付款,发货,确认收货,评价等。
性能方面:打开网页,确认订单,付款的响应时间等等
兼容性:支持各种主流浏览器,IE,360,火狐,谷歌等
PART 1 功能
1.在红包钱数和红包个数的输入框中只能输入数字;
2.红包最多和最少的输入钱数 200,0.01;
3.拼手气红包最多可以发多少个红包;
4.超过最大拼手气红包是否有提醒;
5.当红包钱数超过最大范围是否有提醒;
6.余额不足时,红包发送失败,或者会不会匹配切换支付方式;
7.红包描述里是否可以输入表情、汉字、英文、数字等;
8.红包描述里最多有多少个字符;
9.发送的红包别人是否能正常领取;
10.发送的红包自己可不可以领取;
11.24小时后别人没有领取的红包是否可以退回原来的账户,或者是否还可以领取;
12.用户是否可以多次抢一个红包;
13.用户在多人群里发红包是否可以抢自己的红包;
14.红包余额里的小位数是否有限制;
15.返回键可以正常取消发红包吗;
16.断网时是否可以抢红包;
17.收发红包界面是否有自己以前收发红包的记录,以及和自己实际收发红包是否匹配;
18.支付时密码支付和指纹支付是否正常;
19.支付成功是否正常返回聊天界面;
20.是否可以连续发红包。
PART 2 性能
1.网络环境差,发红包的时间;
2.不同网速时,抢红包的时间;
3.收发红包后跳转时间;
4.收发红包的耗电量;
5.退款到账的时间。
PART3 兼容
1.苹果,安卓系统;
2.电脑端是否可以抢红包;
3.不同品牌的手机是否正常使用。
PART4 界面
1.发红包界面有没有错别字;
2.抢完红包界面有没有错别字;
3.收发红包界面排版美观合理;
4.界面颜色搭配好。
PART5 安全
1.发送红包领取红包后对应相关的金额是否会变化;
2.发送失败银行卡或者余额会不会变;
3.发送成功后是否会收到微信支付的通知。
PART6 易用
1.支持指纹,人脸识别支付码;
2.红包描述可以通过语音输入吗。
这才是2022最精细的自动化测试自学教程,我把它刷了无数遍才上岸字节跳动,做到涨薪20K【值得自学软件测试的人刷】
接口性能测试 — 软件测试人必会618实战场景分析
软件测试工程师月薪2W以上薪资必学技能 — Python接口自动化框架封装.
美团面试真题_高级测试25K岗位面试 — 软件测试人都应该看看
测试开发之全面剖析自动化测试平台 — 软件测试人的必经之路
软件测试必会_Jmeter大厂实战 — 仅6步可实现接口自动化测试
Jmeter实战讲解案例 — 软件测试人必会
最后: 可以在公众号:伤心的辣条 ! 自行领取一份216页软件测试工程师面试宝典文档资料【免费的】。以及相对应的视频学习教程免费分享!,其中包括了有基础知识、Linux必备、Shell、互联网程序原理、Mysql数据库、抓包工具专题、接口测试工具、测试进阶-Python编程、Web自动化测试、APP自动化测试、接口自动化测试、测试高级持续集成、测试架构开发测试框架、性能测试、安全测试等。
我推荐一个【Python自动化测试交流群:746506216】,大家可以一起探讨交流软件测试,共同学习软件测试技术、面试等软件测试方方面面,助你快速进阶Python自动化测试/测试开发,走向高薪之路。
喜欢软件测试的小伙伴们,如果我的博客对你有帮助、如果你喜欢我的博客内容,请 “点赞” “评论” “收藏” 一 键三连哦!