软件测试知识点和面试题--接口测试篇
软件测试知识点和面试题--性能测试篇
软件测试知识点和面试题--手工测试篇(功能测试)
内部
发布平台
蒲公英、Testlink等
发布步骤
1.开发打包上传到内测分发平台
2.平台可以生成对应的二维码
3.测试直接扫码进行应用安装
线上
发布平台
各类安卓手机品牌商城
App store、iTools
发布步骤
1.开发者账号注册,申请在发布平台(各种应用商店)上架
2.针对不同的发布平台,在软件包中加入对应的平台ID(渠道ID),上传到发布平台
3.平台审核通过后,用户即可在应用商店中下载
和Web测试流程一致
需求评审
编写计划和方案
设计用例和评审
执行用例和缺陷跟踪
编写测试报告
弱化文档
计划:表格/甘特图
方案:XMIND/甘特图
adb help #帮助信息
adb version #版本信息
adb start-server
adb kill-server
连接手机/模拟器
adb connect ip:端口
重启 Android 设备
adb reboot
adb reboot recovery
adb reboot bootloader
获取 root 权限
adb root
adb remount
返回设备序列号SN值
adb get-serialno
获取设备分辨率
adb shell wm size
查看当前接入的移动端设备
adb devices
获取设备的状态
adb get-state
device:设备正常连接
offline:连接出现异常,设备无响应
unknown:没有连接设备
查看设备已安装的软件包
adb shell pm list packages
查看当前打开的APP包名和Activity
adb shell dumpsys window w | findstr mFocusedApp
APP相关
应用的 dump 信息
adb shell pm dump 包名
安装APP
首次安装
adb install C:/Users/xjChen/Downloads/SoloPi.apk
覆盖安装
adb install -r C:/Users/xjChen/Downloads/SoloPi.apk
卸载APP
adb uninstall 包名
APP 启动
adb shell am start -n 软件包名/.Activity名
监控APP冷热启动时间
adb shell am start -W -n 软件包名/.Activity名
APP 关闭
adb shell am force-stop 包名
.apk 位置
adb shell pm path 包名
重置APP
adb shell pm clear 包名
截屏并保存至 sdcard 目录
无法直接保存到电脑,需要pull拉取
adb shell screencap -p /sdcard/screen.png
录制视频并保存至sdcard
执行命令后操作手机,ctrl + c 结束录制,无法直接保存到电脑,需要pull拉取
adb shell screenrecord sdcard/record.mp4
复制电脑文件到设备
adb push 电脑文件路径 设备路径
复制设备文件到电脑
adb pull 设备文件 [电脑某路径下]
生成bugreport文件:打印dumpsys、dumpstate、logcat的输出
adb bugreport > C:/Users/xjChen/Downloads/bugreport.log
jdwp进程:显示有效地jdwp (java debug wire protocol) 进程
adb jdwp
1.清空日志
adb logcat -c
2.复现问题
3.执行命令提取和查看日志
adb logcat | findstr 应用包名 > D:/log.txt
1.查看APP包名和Activity
adb shell dumpsys window w | findstr mFocusedApp
2.执行adb命令
adb [-s 设备名] shell monkey -p 包名 --ignore-crashes --ignore-timeouts --throttle 400 -v -s 500 5000 > D:/monkey_log.txt
--ignore-crashes 忽略闪退
--ignore-timeouts :忽略超时
--throttle 400 :随机延迟延迟400ms
-v : 表示记录反馈日志的详细程度 ,-v -v -v 最详细
-s 500: 用于指定伪随机数生成器的seed值
5000:伪随机的事件次数
3.查看日志
日志末尾Monkey finished--表明本次的Monkey没有异常,测试通过
CRASH--表明有进程出现问题,测试不通过
ANR--测试过程中有无响应现象,测试不通过
Exception--其他问题,测试不通过
CPU占有率
获取本机CPU占有率
adb shell dumpsys cpuinfo
获取应用的CPU占有率
adb shell dumpsys cpuinfo | findstr +包名
内存使用情况
本机内存的使用情况
adb shell getprop | findstr dalvik
应用的内存使用情况
adb shell dumpsys meminfo 包名
当前终端所有进程
adb shell ps
APP进程
adb shell ps | findstr 包名
强制停止APP进程
adb shell am force-stop 包名
FPS
adb shell dumpsys gfxinfo 包名
adb shell dumpsys gfxinfo 包名 > C:/Users/xjChen/Downloads/fps.txt
前置条件:手机开启GPU呈现模式分析,选择“在adb shell dumpsys gfxinfo 中” 一般来说,Android设备的屏幕刷新率为60帧/s,要保持画面流畅不卡顿,要求每一帧的时间不超过1000/60=16.6ms,这就是16ms的黄金准则,如果中间的某些帧的渲染时间超过16ms,就会导致这段时间的画面发生了跳帧,因此原本流畅的画面变发生了卡顿 测试APP的FPS性能有3种方式: 1.手机开发者模式,开启GPU呈现模式为条形图; 2.手机开发者模式,开启“在adb shell dumpsys gfxinfo 中”,通过adb命令导出数据,再绘制图表; 3.使用第三方的手机性能检测APP,开启监控帧率,查看数据;
adb命令
冷热启动速度 adb shell am start -W -n 包名/.Activity名
CPU adb shell dumpsys cpuinfo | findstr 包名
内存 adb shell dumpsys meminfo 包名
流畅度 adb shell dumpsys gfxinfo 包名 > C:/fps_log.log
稳定性 adb shell monkey -p 包名 -v -s 500 5000 > c:/mokey_log.log
1.选择性能测试
2.选择要测试APP以及性能指标
3.开始性能测试,并操作APP
4.结束测试,查看日志
一款APP针对不同网络情况下都需要保证不会崩溃,同时尽可能做到在弱网情况下也能达到功能正常使用,或者使用体验达到最佳。 弱网测试可以测试APP的加载时间、可用性、稳定性和健壮性。这时我们就可以借助工具来模拟不同的网络状况,模拟2G、3G或弱网情况进行测试。工具可以选择Fiddler也可以选择Charles也可以选择其他工具。
1、Fiddler中启动弱网
打开Fiddler,Rules->Performance->勾选 Simulate Modem Speeds,勾选之后访问网站会发现网络慢了很多。
2、设置弱网的参数
菜单Rules—>Cutomize Rules
oSession[“request-trickle-delay”] = “300”;
上传1KB内容需要300ms,转化一下上传速度:1Kb/0.3s = 3.3KB/s,也就是说网络上行速度只有3.3KB。
oSession["response-trickle-delay"] = "150";
下载1KB内容需要150ms,转化后的下载速度:1KB/0.15s=6.6KB/s,也就是说网络下载速度只有6.6KB。
3、验证效果
同样的接口,开启弱网前后分别运行一次,查看统计数据。
4、恢复设置
完成测试之后,需要再次执行:打开Fiddler,Rules->Performance->勾选 Simulate Modem Speeds,关闭弱网模拟。
相同点:都离不开测试的基础知识和测试原理。具体包括以下几个方面。
测试用例,均使用边界值分析法,等价类划分法等。
多数采用黑盒测试,来验证业务功能是否能得到正确的应用。
需要检查界面布局,风格,按钮是否美观、简洁,是否统一。
测试页面载入和翻页的速度、登录时长、内存是否溢出等。
测试应用系统的稳定性。
不同点:相对于web测试来说,app测试要考虑手机本身固有的属性,所以app测试还需要注意以下几点。
中断测试(来电去电,短信,蓝牙,NFC支付,闹钟,数据线插拔,锁屏,断电,关机重启等)
安装卸载测试(全新安装,新版本覆盖旧版本,卸载旧版本安装新版本,卸载新版本安装旧版本)
外在因素测试(网络切换,硬件按键,不同分辨率,兼容性,系统,系统版本)
web测试更多的是考虑自身功能和浏览器兼容。
其实APP和小程序本身基于功能业务的测试没有什么区别。 非说业务上的区别的话,小程序的特性更偏向于小,所以在易用性的方面要求更高。 第二:小程序的实现方式不一样,依托于微信终端,所以在兼容性的方面.还要考虑到各种微信版本得兼容。
在部分功能按键上有一些区别; 分系统时iso端还需要多考虑下业务处理; UI页面跳转的形式不一样; iso界面对于空数据的处理等等。
个人认为是没有区别的,基于之前所做的项目来看。一个系统不同的客户端,我们对应后台服务器是一个,也就是说后台服务代码是一致的,同样的功能对应同个接口。除非单边所特有的一些功能需要额外追加接口测试的内容外,没有什么区别。
APP登录场景大体从以下几个方面进行:
1.页面基本元素的操作。
2.大量字符,特殊字符,边界值,必填项校验。
3.注册手机号的特殊性验证,注册邮箱的格式验证。
4.密码大小写是否敏感,密码是否加密展示,密码是否有可见按钮功能,密码框能否使用复制粘贴。
5.验证码校验:必填项,过期,错误,无网络时获取验证码,多次获取,超过获取次数,输入验证码后,修改手机号。
6.登录时与系统的交互:锁屏,蓝牙,home,后退,横竖屏,修改字体字号。
7.逆向思维:已注册账号注册,未注册账号忘记密码,未注册账号登录,注册过程中退出再次注册。
8.输入法交互,切换输入法,切换输入模式,手写/九宫格。
9.登录账号的多样性:多个账号轮流登录,同一个账号多角色登录。
10.第三方登录验证:账号授权,信息正确,取消授权。
11.登录页面跳转,返回,登录成功及其他页面跳转。
12.手机兼容性测试:分辨率兼容,系统兼容,系统版本兼容,App版本兼容。
13.网络切换,网络断开,弱网。
Push消息的测试可以从以下几个方面进行:
1.检查Push消息是否按照指定的业务规则发送。
2.检查不接收推送消息时,用户不会再接收到Push消息。
3.如果用户设置了免打扰的时间段,检查在免打扰时间段内,用户接收不到Push。在非免打扰时间段内,用户能正常收到Push。
4.当Push消息是针对登录用户的时候,需要检查收到的Push与用户身份是否相符,没有错误的将其他人的消息推送过来。一般情况下,只对手机上最后一个登录用户进行消息推送。
5.测试Push时,在开关机、待机状态下执行推送,消息及其推送跳转的正确性。
6.push消息时,会有红点展示,推送消息阅读前后数字的变化是否正确;
7.应用在开发、未打开状态、应用启动且在后台运行的情况下是push显示和跳转是否正确。
8.多条推送的合集的显示和跳转是否正确。
APP闪退的原因可能是:
缓存垃圾太多,Android系统的特性,如果长时间不清理垃圾文件,会导致越来越卡,甚至闪退。
运行程序太多,导致内存不足。
应用版本兼容问题,分辨率兼容问题。
APP中访问网络的地方,组件能否正常下载并显示。
APP的SDK与手机系统不兼容。
系统升级后,新版本不兼容老版本的API,返回对象失败,报空指针。
软件权限未开放。
APP出现Crash或ANR,可以从以下几个方面处理: 可以先把日志过滤出来:adb logcat | findstr xxxxx(过滤日志信息) ; 然后再搜索其中的关键字,比如:exception、crash,看看是哪些方法或者异常导致了问题; 初步定位问题原因后,可以交给开发人员去具体查找深层原因并修复。
APP的ANR和Crash产生的原因有很多,手机本身的资源问题,也有可能是代码本身的问题导致。
通常我采用的方式有几个:
Fiddler抓包、ADB查看日志和GT监控手机资源使用情况、查看服务器日志等方式。
核心还是确认后台处理的接口和APP程序的代码是否有处理错误,日志可以查看一些错误日志信息:如Error级别的、EXCEPTION异常的。
如获取到类似日志,我自己会做一些简单的分析,1是确认功能接口信息,2是识别常见的异常:如数组越界和空指针等问题。
如分析不出来,则会提交日志信息给开发进行确认,同时也会咨询开发具体问题,累积经验。
这个主要是面试官考察你会不会看日志,是不是看得懂Java里面抛出的异常,一般面试中Java Exception(runtimeException )是必会被问到的问题,app崩溃的常见原因应该也是这些了。常见的异常列出四五种,是基本要求。
常见的几种如下:
NullPointerException - 空指针引用异常
ClassCastException - 类型强制转换异常
IllegalArgumentException - 传递非法参数异常
ArithmeticException - 算术运算异常
ArrayStoreException - 向数组中存放与声明类型不兼容对象异常
IndexOutOfBoundsException - 下标越界异常
NegativeArraySizeException - 创建一个大小为负数的数组错误异常
NumberFormatException - 数字格式异常
SecurityException - 安全异常
UnsupportedOperationException - 不支持的操作异常
APP测试的进行,可以从以下几个方面展开:
功能测试:
业务逻辑正确性测试:依据产品文档->测试用例编写。
兼容性测试:
1.系统版本:Android:官方版本,定制版本;IOS:官方提供版本。
2.分辨率:720 * 1280 1080* 1920。
3.网络情况:2g 3g 4g 5g Wi-Fi。
异常测试:
1.热启动应用:应用在后台长时间待机;应用在后台待机过程中,手机重启。
2.网络切换和中断恢复:网络切换;中断恢复。
3.电话信息中断恢复。
升级,安装,卸载测试:
1.升级测试:临近版本升级(1.0->1.1);跨版本(1.0->…->2.2)。
2.安装测试:首次安装;覆盖安装(同版本,不同版本覆盖);卸载后安装。
3.卸载测试:首次卸载;卸载安装后再卸载。
健壮性测试:
1.手机资源消耗:cpu,内存。
2.流量消耗:图片,数据,视频。
3.电量测试。
4.崩溃恢复。
1、性能关注点
包体大小:
包体大小能被列为性能指标,是从APP性能指标及运营两个维度考虑的,用户是更希望包体小的同时性能要好,有时它们会是一个互相取舍的关系。
启动时长:
移动应用的启动时间是用户体验的一个重要方面,IOS一直建议尽可能的缩短启动时间,防止用户不愿意使用它们。对于浏览器而言,由于程序启动时还会有教育页和闪屏的下发,因此启动时间的获取显得尤为重要。
启动时间分为冷启动时间和热启动时间,所谓的“冷启动”,就是一个完全没有运行的应用的启动时间,与热启动(应用已经在后台运行,某个事件将其带至前台)相比,由于此时系统尚未建立缓存,因此冷启动往往要较平时(热启动)耗费更长的时间。
内存使用:
在Android系统中,每个APP进程除了同其他进程共享(shared dirty)外,还独用私有内存(private dirty),通常我们使用PSS(=私有内存+比例分配共享内存)来衡量一个APP的内存开销。移动设备的内存资源是非常有限,为每个APP进程分配的私有内存也是有限制。一方面我们要合理的申请内存使用,以免导致频繁的GC(垃圾回收机制)影响性能和大对象申请发生内存溢出;另一方面,我们要及时释放内存,以免发生内存泄漏。
CPU占用率:
一般情况下,用主流手机使用APP20%-40%的CPU占用率算是合理的,当然这个数值随着近年来手机硬件配置的提高,会略微下降,如果CPU占用率超过80%就非常值得我们去关注了。
图片处理器每秒刷新的帧数(FPS):
可用来指示页面是否平滑的渲染。手机APP帧率FPS,30-60都可接受,上了60对于人眼主观感受差别就不大了。对于移动应用开发而言,并不是FPS越高就一定越好,FPS取决于显卡,其次是内存、CPU,然后是网络。故综合APP其他性能指标,选择一个适合的FPS即可。
电量:
相对于PC来说,移动设备的电池电量是非常有限的,保持持久的续航能力尤为重要。另外,android的很多特性都比较耗电(如屏幕,GPS,sensor传感器,唤醒机制,CPU,连网等的使用),我们必须要慎重检查APP的电量使用,以免导致用户手机耗电发热,带来不良体验。
流量:
目前的网络类型包含2G\3G\4G\5G\wifi,其中还有不同运营商的区分,我们在APP的使用中经常遇到大资源,重复请求,调用响应慢,调用失败等各种情况。在不同的网络类型之下,我们不仅要控制流量使用,还需要加快请求的响应。另外,对于需要联网的手游来说,部分游戏对不同联网方式的网络类型采用了不同的流量消耗策略,主要分为wifi环境和蜂窝网络环境。所以针对不同的游戏,我们统计流量消耗时,可能要连接不同的网络进行测试。
2、app性能测试工具
GT和iTest,Emmagee APT ,DDMS ,手机自带开发者选项中的工具,也可以通过adb命令来查看等
我之前的公司团队比较小,而且对于APP的兼容性要求不是特别高,基于需求层面首先要求andorid和iso两个系统,版本没有特别强调。 公司采购了部分手机:OPPO、iphone8和华为Mate30,加上我们自己同事的手机小米等。 除了这些真机以外,偶尔会使用一下模拟器和云手机来进行测试。
基于之前测试经验,我们的APP会涉及到手机权限功能点有扫码、拍照、安装等,一般情况下会基于这些调用本机硬件的功能去单独进行测试,验证权限允许和不允许的情况的APP功能的使用情况。
个人理解APP的性能测试的话分为两块,一块是对于APP在使用过程中,对于手机设备本身的资源消耗情况。第二是后台服务器的处理性能。 那对于APP本身对于手机设备的性能测试我做过两个方面的性能测试:一个手工操作APP,使用GT来搜集和分析资源使用数据情况,如手机CPU、内存、网络等等性能情况,第二使用monkey来做稳定性测试,验证APP是否会crash。 对于后台服务器的性能测试,和常规的性能测试没有区别,我们公司使用jmeter实现的。
首先对于app的安装卸载和升级测试,我们在版本迭代的过程中,并不是每次都专门去进行测试。 因为有版本迭代,我们需要到不同的手机进行安装最新的安装包,如果安装不成功当场就能发现问题了。 一般情况下比较大型的版本更新,我们会专门找全各种手机型号进行安装,同时还会考虑各种情况下的安装:如正在使用时、取消安装、安装中断、各种渠道安装、安装位置等,卸载的话除了正常卸载外,还会考虑安装文件、缓存文件清理的问题。 升级会考虑各种渠道升级,跨版本升级等等。
这个测试过程中安装卸载的执行方式也差不多,不会每次版本都会进行测试。 在之前的APP测试过程中的话,也是相对大点点的版本才会专门安排交叉性测试的内容。 app在使用的过程中的其它一些影响性的操作,如通话、网络切换和横竖屏幕切等。 如果是播放性的业务还会考虑一下蓝牙设备、音量控制等等测试点。
连接模拟器
安装卸载软件
文件上下传
稳定性测试
查看性能指标:内存、CPU、FPS
adb logcat > fileName.txt
此命令可以直接捕获全局的日志信息,开发人员可以通过分析日志获得自己想要的信息
adb logcat | findstr 包名 > fileName.txt
此命令可以过滤内容
用于APP稳定性测试,使用monkey验证app在大量随机性操作的下时候是否会崩溃; 测试过程中是有发现问题的,在我之前的项目中,在使用monke执行第二次压力测试时,app突然崩溃,当我查看日志信息显示NullPointerException ,并记下seed值,将错误复现了一遍,发现依然报错,就截图发给对应的开发确认是什么问题导致的
用Adb有两种连接手机的方式,在测试过程中,各有优缺点吧。
一种是用USB连接
优点:插上就可以连接,延迟低。
缺点:需求借助USB线来连接,做兼容的自动化测试的时候比较麻烦
1.会在手机上打开开发模式,启用USB调式。
2.USB线连接手机和电脑
3.在cmd窗口输入 adb devices(手机上会有一个提示:是否允许此电脑进行调试,确认)
另一种是用WIFI连接
也有优点:使用无线连接,做自动化的时候可以远程运行
缺点的话:需求借助网络,延迟高,速度略慢(并没有感觉到)
1.先用USB连接手机和电脑
2.在cmd窗口输入 adb tcpip 5555
3.拔掉USb线
4.查看手机IP地址 或者直接在CMD窗口输入命令
adb connect IP:5555
冷启动:当进程不存在的时候,从进程创建开始到界面的展示的过程;
热启动:大部分资源都在,只是应用之间的切换;
adb shell am start -W 包名/界面名
冷启动:需要1秒甚至更长;
热启动:需要<0.5秒;