APP APP test basic test points finishing processes and test points APP

APP APP test process and test points substantially https://www.cnblogs.com/dengqing9393/p/6497068.html

Performance Testing: https: //blog.csdn.net/xiaomaoxiao336368/article/details/83547318

Points APP test design test cases http://blog.itpub.net/69915785/viewspace-2663955/

1 is a flowchart

 

 

 

1.2 test cycle

Test cycle project development cycle can be determined test time, the test time is generally twenty-three weeks (i.e., 15 days), may be appropriately shortened or lengthened depending on the project and the testing time quality version.

1.3 Testing Resources

Before the test task starts, check the test resources.

- Product functional requirements documentation;

- prototype drawing;

- Product renderings;

--Test Equipment;

--other.

1.4 Daily and products on-line reporting (internal reporting mechanisms)

1) Daily testers need to send a test project for the measured daily. (That is, I have here mail notification when the general test items belong output test Daily)

2) content of the test daily included are:

\\ Dell-server \ sites and other software app development \ product testing department \ test knowledge of the area \ test document class template \ project test report output message templates .doc

4) different versions of the test report output

2 App Test Point

 

App test point consolidation

One. Functional test

Products tested according to test requirements document written

Functional module includes a single client function, and the function of the business logic (functionality interaction)

 

1.1 Installation and uninstallation test

  • Whether used in different system versions andriod able to install, run
  • Can you cancel the installation process
  • Cancel the installation, the installation is normal again
  • Whether to prompt the installation space is insufficient
  • You are prompting the installation of network disconnection
  • The installation process prompts whether SMS alarm after the call is completed
  • Whether the normal operation after the installation, if the file after installation is written to the specified directory;
  • Repeat the installation, if prompted
  • Packing package automatically deleted after the installation is complete
  • Install different applications downloaded from the Market
  • Uninstall canceled, whether it can successfully be able to cancel

 

1.2 App upgrade

  • When a client has a new version, an update prompt.
  • 当版本为非强制升级版时,用户可以取消更新,老版本能正常使用。用户在下次启动App时,仍出现更新提示。
  • 当版本为强制升级版时,但给出强制更新后用户没有做更新时,退出客户端。下次启动App时,仍出现强制升级提示。
  • 当客户端有新版本时,在本地不删除客户端的情况下,直接更新检查是否能正常更新。
  • 当客户端有新版本时,在本地不删除客户端的情况下,检查更新后的客户端功能是否是新版本。
  • 当客户端有新版本时,在本地不删除客户端的情况下,检查资源同名文件如图片是否能正常更新成最新版本。
  • 在线跨版本升级后是否能够正常使用

 

1.3 登录

  • 用户名、口令(密码)错误或漏填时能否登陆,是否有提示
  • 使用已经登录的账号登录系统是否正确处理
  • 系统是否允许多次非法的登录,是否有次数限制
  • 检查账号是否能够登陆多个手机,是否将原用户剔除
  • 登陆后,页面中登录信息是否正确
  • 页面中有注销按钮
  • 登录超时的处理
  • 用户主动退出登录后,下次启动APP时,应该进入登陆界面
  • 对于支持自动登陆的APP,数据交换时,是否能够自动登陆成功
  • 密码更改后,是否做到了有效的数据的校验
  • 切换账号登陆,检查登陆信息是否   到了及时更新
  • 对于未登录状态时,一些页面的操作,是否做了控制

 

1.4 离线测试

  • 很多应用会支持离线浏览,即在本地客户端会缓存一部分数据供用户查看
  • 在无线网络情况可以浏览本地数据
  • 对于离线(无网络)时,刷新获取数据时,不能获取数据时是否能够给出友好提示
  • 对于界面数据不提供离线查看,需要给出相应的提示
  • 退出App再开启App时能正常浏览
  • 切换到后台再回到前台可以正常浏览
  • 锁屏后再解锁回到应用前台可以正常浏览
  • 在对服务器段的数据有更新时回给予离线的相应提示
  • 离线后连接到网络,是否需要从服务端获新数据

 

1.5 消息测试

  • 默认开关应该是打开的状态
  • 未锁屏时,后台运行,消息推送是否可以正常接收
  • 未锁屏时,app客户端使用的过程中,可以看到消息提醒并可查看
  • 手机消息栏是否可以显示消息并且提醒,且点击查看,点击后消息在消息栏后不显示
  • 检查Push消息是否按照指定的业务规则发送。
  • 检查不接收推送消息时,用户不会在接收到Push消息。
  • 如果用户设置了免打扰的时间段,检查在免打扰时间段内,用户接收不到Push。在非免打扰时间段内,用户能正常收到Push。
  • 当Push消息是针对登录用户的时候,需要检查收到的Push与用户身份是否相符,没有错误的将其他人的消息推送过来。一般情况下,只对手机上最后一个登录用户进行消息推送。
  • 测试Push时,需要采用真机进行测试
  • 退出登录后,是否还接收消息(根据需求来)

 

二. UI界面测试

  • 页面是否美观;
  • 文字是否正确;
  • 文字图片组合是否完美,操作是否友好;
  • 菜单,对话框,窗口,控件布局是否满足客户要求

三. 兼容性测试(取 市场主流的手机进行测试 主流手机号可参考http://tongji.baidu.com)

  • 不同的操作系统
  • 不同的分辨率
  • 不同的尺寸
  • 不同厂家

四 .安全性测试

  • 权限问题:是否允许访问相册,拍照,录音,定位,接收推送消息
  • 数据库隐私加密
  • 隐藏泄露风险:包括访问手机信息,访问联系人信息等
  • 一般对于大多数非支付类App来说,安全性不是一个特别大的问题,只需保证登录鉴权的安全性即可。

四. 前后台切换

  • App切换到后台,再回到App,检查是否停留在上一次操作界面。
  • App切换到后台,再回到App,检查功能及应用状态是否正常。
  • App切换到后台,再回到前台时,注意程序是否崩溃,功能状态是否正常,尤其是对于从后台切换回前台数据有自动更新的时候。
  • 手机锁屏解锁后进入App注意是否会崩溃,功能状态是否正常,尤其是对于从后台切换回前台数据有自动更新的时候。
  • 当App使用过程中有电话进来中断后再切换到App,功能状态是否正常。
  • 当关掉App进程后,再开启App,App能否正常启动。
  • 出现必须处理的提示框后,切换到后台,再切换回来,检查提示框是否还存在,有时候会出现应用自动跳过提示框的缺陷。
  • 对于有数据交换的页面,每个页面都必须要进行前后台切换、锁屏的测试,这种页面最容易出现崩溃
  • 对于有数据的交换的页面,每个页面都必须进行前后台切换,锁屏,网络切换,app切换,电话切换,断电切换等中端的测试

七.异常中断测试

  • 交互异常测试:客户端作为手机特性测试,包括被打扰的情况:如来电,短信,低电量测试等,还有注意硬件设备,如:待机,插拔数据线,耳机等操作会不会影响到操作
  • 异常性测试:断网,断电测试

八.网络环境

  • 测试软件在2G 3G 4G wifi 网络下应用的运行速度;
  • 一般的测试时在公司的内网进行测试,到外网再进行测试是否有异常
  • 网络不好,数据的提交测试;
  • 从有网到无网,再到有网 数据是否可以自动恢复
  • 无网络的时候,界面提示是否友好
  • 当网络环境很差的时候,用户在支付界面的多次确认必须只执行一次

九.性能测试

  • 测试APP 在不同网络速度下操作的流畅程度(FPS)
  • 测试APP操作数据库的性能;
  • 压力测试
  • 资源消耗(CPU 测试 内存 流量 )

 

普遍的apk性能测试,主要是以下七类

1、响应
2、内存
3、cpu
4、FPS (app使用的流畅度)
5、GPU过度渲染
6、耗电
7、耗流
(app除了这些性能测试,还有:手机版本号兼容性,屏幕分辨率兼容性,稳定性测试,安全测试等,后续会持续更新… 流量测试同这些一起更新,这里就不在说明了 )

一、响应
软件的响应时间和响应速度直接影响到用户的体验度,如果一个软件,迟迟加载不出来,会直接影响到软件的日活、留存。因此对于一个软件,对响应速度测试是必不可少的。

主要测试点:
1、冷启动:首次启动app的时间间隔(只是启动时间,不包括页面加载)
2、热启动:非首次启动app的时间间隔(只是启动时间,不包括页面加载)
3、完全启动:从启动到首页完全加载出来的时间间隔
4、有网启动:从发起跳转,到页面完全加载出来的时间间隔
5、无网启动:从发起跳转,到页面完全加载出来的时间间隔
(在项目中,主要测试关注点是冷启动,热启动)

测试方法:
1、使用adb命令
1) 冷启动
adb shell am start -W packageName/ActivityName(绝对路径,首个Activity)


含义:
ThisTime: 该Activity的启动耗时;
TotalTime: 应用自身启动耗时, ThisTime+应用application等资源启动时间;
WaitTime: 系统启动应用耗时, TotalTime+系统资源启动时间

2)热启动:按back按键后再启动adb命令


测试标准:冷启动时间不超过1.5s, 热启动不超过1s.

3)完全启动,无网启动,有网启动都可以通过charles抓包来获取启动的时间

charles是一个很强大的抓包工具,除了截取请求还能进行单接口压测,修改请求参数并发出请求,以及模拟无网,弱网,2G,3G,4G等。能解决app的很多专项测试。


限制网络情况需要用到charles的一个功能: Throttle Setting

通过设置网速和抓包,可以获取启动时间,但是有一定的误差。在项目中,一般只需要测试冷启动,热启动便可。

2、使用AndroidStudio的Android Monitor,查看手机日志系统输出
Android Monitor总共有5大模块:logcat, memory, cpu, network,GPU
我们可以通过logcat获取应用的响应时间(如何使用,内存中有介绍)


3、代码日志输入查看
直接源码打日志,输入各个位置的耗时操作最为有效,需要源码。

4、借用工具,高速相机,但是成本较高。(如下图:目前项目团队使用的测试工具)
原理: 通过压力感应来自动识别起始点,回放图片判断结束点,(一般默认手机界面静止不动为结束点), 键盘按S键为起始点,按F键为结束点。
这里便不介绍用法了。

 

 

二、内存
在Android系统中,每个APP进程除了同其他进程共享内存(shared dirty)外,还独用私有内存(private dirty),通常我们使用PSS(私有内存+比例分配共享内存)来衡量一个APP的内存开销。由于一个移动设备的内存是固定的,如果内存消耗过大就会造成应用卡顿或者闪退,需要对内存进行测试。正常情况下,应用不应占用过多的内存资源,且能够及时释放内存,保证整个应用内的稳定性和流畅性。

测试点:
1、空闲状态:切换至后台或者启动后不做任何操作,消耗内存最少。
2、中强度状态:时间偏长的操作应用。
3、高强度状态:高强度使用应用,可以跑monkey来测试(通常用来测试内存泄漏)。
** 内存泄漏:指应用里的内存一直没有释放,内存一直增加 ,系统内存一直减少 **

测试方法:
1、使用adb命令: adb shell dumpsys meminfo packageName

获取应用包名和Actively:
adb shell dumpsys window | findstr mCurrentFocus

测试关注点:
1、Native heap alloc
2、Dalvik heap alloc
3、PSS


2、使用性能测试工具:Emmagee(只支持Android)
Emmagee是网易开发的一款测安卓应用性能的测试apk
1、安装Emmagee.apk,打开。
2、选择需要测试性能的应用启动
3、被测应用界面会展示内存、CPU、电流、流量等数据
4、stop Test之后,在本地SD卡中保存一份性能测试数据,可以从里面获取内存信息。
5、可以通过execl将数据转化成图表,更直观的查看各性能指标的数据。
(保存地址:/sdcard/Emmagee/******* .csv文件)


生成的csv文件:

原理:Emmagee是使用Android自身提供的ActivityManager.MemoryInfo()方法获得
可查看: cpu 内存 流量 电量 FPS(流畅度)是一个相对比较好的选择
但是只支持安卓6.0及以下的版本

除了Emmagee,还有腾讯提供的一个同样测试性能的app, GT。使用与Emmagee大体一致,但是GT除了支持Android,同样支持ios。GT相对于Emmagee功能也更强大:性能测试(CPU、内存、流量、电量、帧率/流畅度等等)、开发日志的查看、Crash日志查看、网络数据包的抓取、APP内部参数的调试、真机代码耗时统计。

3、使用AndroidStudio 自带 CPU 和内存检测功能 – Android Monitor
(首先要下载并安装好Android Studio)
Android Monitor 可以检测CPU 和内存,能够绘制出变化图,可以直观明了的看出内存和cpu的变化曲线。


Android Monitor ,有5个模块 :logcat、Memory、CPU、Network、GPU。


关注点:
1、退出某个页面后,内存是否有回落。
如果没有及时回落,且程序自动GC或者手动GC,那便可确认有问题。
2、进行某个操作后,内存是否增长过快。
如果增长过快,也有可能存在风险,需重复操作确认。

三、CPU
CPU测试,主要关注的是cpu的占用率。很多时候,我们玩手机时,会出现发热发烫,那是因为CPU使用率过高,CPU过于繁忙,会使整个手机无法响应用户,整体性能降低,用户体验就会很差,也容易引起ANR(application not responding, 主线程(UI线程)如果在规定时内没有处理完相应工作,就会出现ANR)等等一系列问题。

测试点:
1).在空闲时间(切换至后台)的消耗,基本没大应用使用cpu
2).在运行一些应用的情况下,cpu已占50%的情况下,观察应用程序占用cpu的情况
3).在高负荷的情况下看CPU的表现(cpu占用应是在80%以上)

具体场景:
1、应用空闲状态运行监测CPU占用率
空闲状态:应用按Home键退到后台,不再占用系统的状态(通常是灭屏半分钟后)
CPU占用率=0%

2、应用中等规格运行监测CPU占用率
中等规格:模拟用户最常见的使用场景
CPU占用率≤30%

3、应用满规格长时间正常运行监测CPU占用率
Monkey测试
CPU占用率≤30%

4、应用正常运行期间监测CPU占用率峰值
应用正常运行:打开应用进行基本操作
CPU占用率≤50%

测试方法:
1、使用adb命令:
1) top -m -s cpu |grep packageName


top cpu 参数:
-m 显示最大数
-s 按指定行排序
-t 显示进程名称
-n 在退出前刷新几次
-d 刷新间隔

如果反复进行某个操作,cpu占用过高且一直无法释放,那便可能存在风险。

2)dumpsys cpuinfo |grep packageName


2、使用第三方测试工具:Emmagee、GT等。
3、使用AndroidStudio自带的检测工具Android Monitor。

四、FPS (应用的使用流畅度)

FPS是图像领域中的定义,是指画面每秒传输帧数,通俗来讲就是指动画或视频的画面数。FPS是测量用于保存、显示动态视频的信息数量。每秒钟帧数愈多,所显示的动作就会愈流畅。
´一般来说,Android设备的屏幕刷新率为60帧/s,要保持画面流畅不卡顿,要求每一帧的时间不超过1000/60=16.6ms,这就是16ms的黄金准则,如果中间的某些帧的渲染时间超过16ms,就会导致这段时间的画面发生了跳帧,因此原本流畅的画面变发生了卡顿。

测试方法:
1、adb命令
1)打开手机:开发者选项—>profile GPU rendering —> in adb shell dumpsys gfxinfo
2) 操作要测试的apk
3) cmd窗口输入命令: adb shell dumpsys gfxinfo packageName
4) 得到一个矩阵数据,计算矩阵中帧率大于16的点所占比例,即为卡顿比

 

含义:
Draw: 表示在Java中创建显示列表部分中,OnDraw()方法占用的时间。
Process:表示渲染引擎执行显示列表所花的时间,view越多,时间就越长。
Execute:表示把一帧数据发送到屏幕上排版显示实际花费的时间。
Draw + Process + Execute = 完整显示一帧 ,这个时间要小于16ms才能保存每秒60帧。

5)通过execl进行表格处理可以直观的查看软件的流畅度


2、除了使用adb shell, 还可以直接使用开发者选项自带的图表
1)打开手机:开发者选项—>profile GPU rendering —> on screen as bars
2) 操作被测的软件
3)界面会显示如下的一个统计数据表


2、使用第三方测试工具:Emmagee、GT等。
3、使用AndroidStudio自带的检测工具Android Monitor。

五、GPU渲染

GPU渲染是指在一个像素点上绘制多次(超过一次):显示一个什么都没有做的activity界面算作画了1层,给activity加一个背景是第2层,在上面放了一个Text View(有背景的Text View)是第3层,Text View显示文本就是第4层仅仅只是为了显示一个文本,却在同一个像素点绘制了四次,这是一定要优化的。过度绘制对动画性能的影响是极其严重的,如果你想要流畅的动画效果,那么一定不能忽视过度绘制。

测试方法:
1、手机自动的Debug GPU overdraw
1)打开手机—>设置—>开发者选项—>Debug GPU overdraw—>show overdraw areas
2)打开被测的应用


GPU过渡渲染不同的颜色代表不同的绘制程度
1)、原色:无过渡绘制
2)、蓝色:绘制一次 (理想状态)
3)、绿色:绘制二次
4)、浅红:绘制三次 (可以优化)
5)、深红:绘制四次 (必须优化)

测试指标:
1、控制过渡绘制为2x
2、不允许存在4x过渡绘制
3、不允许存在面积超过屏幕1/4的3x过渡绘制

六、耗电量
测试应用对电量的消耗前需要对手机本身的电量消耗有个大概了解,测试前先看规定时间内手机正常待机下(重启后待机)电量消耗为多少。然后再启动待测试APP看看消耗的电量增加了多少取差值。

测试点:
  测试手机安装目标APK前后待机功耗无明显差异;
  常见使用场景中能够正常进入待机,待机电流在正常范围内;
  长时间连续使用应用无异常耗电现象。

测试方法 :(先关闭所有的应用,再打开被测app)
1、使用第三方测试工具:Emmagee、GT等,只需要测试的电流静置一晚,待机电流在正常范围内即可。一般是被测应用对比待机电流<=2mA。
2、使用adb命令
adb shell dumpsys batterystats |grep packageName

性能测试:https://blog.csdn.net/xiaomaoxiao336368/article/details/83547318

APP测试设计测试用例的要点   http://blog.itpub.net/69915785/viewspace-2663955/

1流程图

 

 

 

1.2测试周期

测试周期可按项目的开发周期来确定测试时间,一般测试时间为两三周(即15个工作日),根据项目情况以及版本质量可适当缩短或延长测试时间。

1.3测试资源

测试任务开始前,检查各项测试资源。

--产品功能需求文档;

--产品原型图;

--产品效果图;

--测试设备;

--其他。

1.4日报及产品上线报告(内部报告机制)

1)测试人员每天需对所测项目发送测试日报。(也就是我这边有邮件通知测试项目的时候一般均属于输出测试日报)

2)测试日报所包含的内容为:

\\Dell-server\网站软件app等开发\产品测试部\测试知识区域\测试文档类模板\项目测试报告邮件输出模板.doc

4)不同版本测试报告输出

2 App测试点

 

App测试点整理

一. 功能性测试

根据产品需求文档编写的测试用例进行测试

功能性包括客户端的单个功能模块,以及功能业务逻辑(功能交互)

 

1.1安装与卸载测试

  • 应用是否在andriod不同系统版本上能够进行安装,运行
  • 在安装过程是否可以取消
  • 取消安装,再次安装是否正常
  • 安装空间不足 是否提示
  • 安装过程中网络断开的情况下 是否提示
  • 安装过程中 来电 短信 闹铃 完成后是否提示
  • 安装后是否正常运行,安装后的文件是否写入到指定的的目录里;
  • 重复安装,是否提示
  • 安装完成后自动删除包装包
  • 从不同的应用市场下载进行安装
  • 卸载取消,是否能能够取消成功

 

1.2 App 升级

  • 当客户端有新版本时,有更新提示。
  • 当版本为非强制升级版时,用户可以取消更新,老版本能正常使用。用户在下次启动App时,仍出现更新提示。
  • 当版本为强制升级版时,但给出强制更新后用户没有做更新时,退出客户端。下次启动App时,仍出现强制升级提示。
  • 当客户端有新版本时,在本地不删除客户端的情况下,直接更新检查是否能正常更新。
  • 当客户端有新版本时,在本地不删除客户端的情况下,检查更新后的客户端功能是否是新版本。
  • 当客户端有新版本时,在本地不删除客户端的情况下,检查资源同名文件如图片是否能正常更新成最新版本。
  • 在线跨版本升级后是否能够正常使用

 

1.3 登录

  • 用户名、口令(密码)错误或漏填时能否登陆,是否有提示
  • 使用已经登录的账号登录系统是否正确处理
  • 系统是否允许多次非法的登录,是否有次数限制
  • 检查账号是否能够登陆多个手机,是否将原用户剔除
  • 登陆后,页面中登录信息是否正确
  • 页面中有注销按钮
  • 登录超时的处理
  • 用户主动退出登录后,下次启动APP时,应该进入登陆界面
  • 对于支持自动登陆的APP,数据交换时,是否能够自动登陆成功
  • 密码更改后,是否做到了有效的数据的校验
  • 切换账号登陆,检查登陆信息是否   到了及时更新
  • 对于未登录状态时,一些页面的操作,是否做了控制

 

1.4 离线测试

  • 很多应用会支持离线浏览,即在本地客户端会缓存一部分数据供用户查看
  • 在无线网络情况可以浏览本地数据
  • 对于离线(无网络)时,刷新获取数据时,不能获取数据时是否能够给出友好提示
  • 对于界面数据不提供离线查看,需要给出相应的提示
  • 退出App再开启App时能正常浏览
  • 切换到后台再回到前台可以正常浏览
  • 锁屏后再解锁回到应用前台可以正常浏览
  • 在对服务器段的数据有更新时回给予离线的相应提示
  • 离线后连接到网络,是否需要从服务端获新数据

 

1.5 消息测试

  • 默认开关应该是打开的状态
  • 未锁屏时,后台运行,消息推送是否可以正常接收
  • 未锁屏时,app客户端使用的过程中,可以看到消息提醒并可查看
  • 手机消息栏是否可以显示消息并且提醒,且点击查看,点击后消息在消息栏后不显示
  • 检查Push消息是否按照指定的业务规则发送。
  • 检查不接收推送消息时,用户不会在接收到Push消息。
  • 如果用户设置了免打扰的时间段,检查在免打扰时间段内,用户接收不到Push。在非免打扰时间段内,用户能正常收到Push。
  • 当Push消息是针对登录用户的时候,需要检查收到的Push与用户身份是否相符,没有错误的将其他人的消息推送过来。一般情况下,只对手机上最后一个登录用户进行消息推送。
  • 测试Push时,需要采用真机进行测试
  • 退出登录后,是否还接收消息(根据需求来)

 

二. UI界面测试

  • 页面是否美观;
  • 文字是否正确;
  • 文字图片组合是否完美,操作是否友好;
  • 菜单,对话框,窗口,控件布局是否满足客户要求

三. 兼容性测试(取 市场主流的手机进行测试 主流手机号可参考http://tongji.baidu.com)

  • 不同的操作系统
  • 不同的分辨率
  • 不同的尺寸
  • 不同厂家

四 .安全性测试

  • 权限问题:是否允许访问相册,拍照,录音,定位,接收推送消息
  • 数据库隐私加密
  • 隐藏泄露风险:包括访问手机信息,访问联系人信息等
  • 一般对于大多数非支付类App来说,安全性不是一个特别大的问题,只需保证登录鉴权的安全性即可。

四. 前后台切换

  • App切换到后台,再回到App,检查是否停留在上一次操作界面。
  • App切换到后台,再回到App,检查功能及应用状态是否正常。
  • App切换到后台,再回到前台时,注意程序是否崩溃,功能状态是否正常,尤其是对于从后台切换回前台数据有自动更新的时候。
  • 手机锁屏解锁后进入App注意是否会崩溃,功能状态是否正常,尤其是对于从后台切换回前台数据有自动更新的时候。
  • 当App使用过程中有电话进来中断后再切换到App,功能状态是否正常。
  • 当关掉App进程后,再开启App,App能否正常启动。
  • 出现必须处理的提示框后,切换到后台,再切换回来,检查提示框是否还存在,有时候会出现应用自动跳过提示框的缺陷。
  • 对于有数据交换的页面,每个页面都必须要进行前后台切换、锁屏的测试,这种页面最容易出现崩溃
  • 对于有数据的交换的页面,每个页面都必须进行前后台切换,锁屏,网络切换,app切换,电话切换,断电切换等中端的测试

七.异常中断测试

  • 交互异常测试:客户端作为手机特性测试,包括被打扰的情况:如来电,短信,低电量测试等,还有注意硬件设备,如:待机,插拔数据线,耳机等操作会不会影响到操作
  • 异常性测试:断网,断电测试

八.网络环境

  • 测试软件在2G 3G 4G wifi 网络下应用的运行速度;
  • 一般的测试时在公司的内网进行测试,到外网再进行测试是否有异常
  • 网络不好,数据的提交测试;
  • 从有网到无网,再到有网 数据是否可以自动恢复
  • 无网络的时候,界面提示是否友好
  • 当网络环境很差的时候,用户在支付界面的多次确认必须只执行一次

九.性能测试

  • 测试APP 在不同网络速度下操作的流畅程度(FPS)
  • 测试APP操作数据库的性能;
  • 压力测试
  • 资源消耗(CPU 测试 内存 流量 )

 

普遍的apk性能测试,主要是以下七类

1、响应
2、内存
3、cpu
4、FPS (app使用的流畅度)
5、GPU过度渲染
6、耗电
7、耗流
(app除了这些性能测试,还有:手机版本号兼容性,屏幕分辨率兼容性,稳定性测试,安全测试等,后续会持续更新… 流量测试同这些一起更新,这里就不在说明了 )

一、响应
软件的响应时间和响应速度直接影响到用户的体验度,如果一个软件,迟迟加载不出来,会直接影响到软件的日活、留存。因此对于一个软件,对响应速度测试是必不可少的。

主要测试点:
1、冷启动:首次启动app的时间间隔(只是启动时间,不包括页面加载)
2、热启动:非首次启动app的时间间隔(只是启动时间,不包括页面加载)
3、完全启动:从启动到首页完全加载出来的时间间隔
4、有网启动:从发起跳转,到页面完全加载出来的时间间隔
5、无网启动:从发起跳转,到页面完全加载出来的时间间隔
(在项目中,主要测试关注点是冷启动,热启动)

测试方法:
1、使用adb命令
1) 冷启动
adb shell am start -W packageName/ActivityName(绝对路径,首个Activity)


含义:
ThisTime: 该Activity的启动耗时;
TotalTime: 应用自身启动耗时, ThisTime+应用application等资源启动时间;
WaitTime: 系统启动应用耗时, TotalTime+系统资源启动时间

2)热启动:按back按键后再启动adb命令


测试标准:冷启动时间不超过1.5s, 热启动不超过1s.

3)完全启动,无网启动,有网启动都可以通过charles抓包来获取启动的时间

charles是一个很强大的抓包工具,除了截取请求还能进行单接口压测,修改请求参数并发出请求,以及模拟无网,弱网,2G,3G,4G等。能解决app的很多专项测试。


限制网络情况需要用到charles的一个功能: Throttle Setting

通过设置网速和抓包,可以获取启动时间,但是有一定的误差。在项目中,一般只需要测试冷启动,热启动便可。

2、使用AndroidStudio的Android Monitor,查看手机日志系统输出
Android Monitor总共有5大模块:logcat, memory, cpu, network,GPU
我们可以通过logcat获取应用的响应时间(如何使用,内存中有介绍)


3、代码日志输入查看
直接源码打日志,输入各个位置的耗时操作最为有效,需要源码。

4、借用工具,高速相机,但是成本较高。(如下图:目前项目团队使用的测试工具)
原理: 通过压力感应来自动识别起始点,回放图片判断结束点,(一般默认手机界面静止不动为结束点), 键盘按S键为起始点,按F键为结束点。
这里便不介绍用法了。

 

 

二、内存
在Android系统中,每个APP进程除了同其他进程共享内存(shared dirty)外,还独用私有内存(private dirty),通常我们使用PSS(私有内存+比例分配共享内存)来衡量一个APP的内存开销。由于一个移动设备的内存是固定的,如果内存消耗过大就会造成应用卡顿或者闪退,需要对内存进行测试。正常情况下,应用不应占用过多的内存资源,且能够及时释放内存,保证整个应用内的稳定性和流畅性。

测试点:
1、空闲状态:切换至后台或者启动后不做任何操作,消耗内存最少。
2、中强度状态:时间偏长的操作应用。
3、高强度状态:高强度使用应用,可以跑monkey来测试(通常用来测试内存泄漏)。
** 内存泄漏:指应用里的内存一直没有释放,内存一直增加 ,系统内存一直减少 **

测试方法:
1、使用adb命令: adb shell dumpsys meminfo packageName

获取应用包名和Actively:
adb shell dumpsys window | findstr mCurrentFocus

测试关注点:
1、Native heap alloc
2、Dalvik heap alloc
3、PSS


2、使用性能测试工具:Emmagee(只支持Android)
Emmagee是网易开发的一款测安卓应用性能的测试apk
1、安装Emmagee.apk,打开。
2、选择需要测试性能的应用启动
3、被测应用界面会展示内存、CPU、电流、流量等数据
4、stop Test之后,在本地SD卡中保存一份性能测试数据,可以从里面获取内存信息。
5、可以通过execl将数据转化成图表,更直观的查看各性能指标的数据。
(保存地址:/sdcard/Emmagee/******* .csv文件)


生成的csv文件:

原理:Emmagee是使用Android自身提供的ActivityManager.MemoryInfo()方法获得
可查看: cpu 内存 流量 电量 FPS(流畅度)是一个相对比较好的选择
但是只支持安卓6.0及以下的版本

除了Emmagee,还有腾讯提供的一个同样测试性能的app, GT。使用与Emmagee大体一致,但是GT除了支持Android,同样支持ios。GT相对于Emmagee功能也更强大:性能测试(CPU、内存、流量、电量、帧率/流畅度等等)、开发日志的查看、Crash日志查看、网络数据包的抓取、APP内部参数的调试、真机代码耗时统计。

3、使用AndroidStudio 自带 CPU 和内存检测功能 – Android Monitor
(首先要下载并安装好Android Studio)
Android Monitor 可以检测CPU 和内存,能够绘制出变化图,可以直观明了的看出内存和cpu的变化曲线。


Android Monitor ,有5个模块 :logcat、Memory、CPU、Network、GPU。


关注点:
1、退出某个页面后,内存是否有回落。
如果没有及时回落,且程序自动GC或者手动GC,那便可确认有问题。
2、进行某个操作后,内存是否增长过快。
如果增长过快,也有可能存在风险,需重复操作确认。

三、CPU
CPU测试,主要关注的是cpu的占用率。很多时候,我们玩手机时,会出现发热发烫,那是因为CPU使用率过高,CPU过于繁忙,会使整个手机无法响应用户,整体性能降低,用户体验就会很差,也容易引起ANR(application not responding, 主线程(UI线程)如果在规定时内没有处理完相应工作,就会出现ANR)等等一系列问题。

测试点:
1).在空闲时间(切换至后台)的消耗,基本没大应用使用cpu
2).在运行一些应用的情况下,cpu已占50%的情况下,观察应用程序占用cpu的情况
3).在高负荷的情况下看CPU的表现(cpu占用应是在80%以上)

具体场景:
1、应用空闲状态运行监测CPU占用率
空闲状态:应用按Home键退到后台,不再占用系统的状态(通常是灭屏半分钟后)
CPU占用率=0%

2、应用中等规格运行监测CPU占用率
中等规格:模拟用户最常见的使用场景
CPU占用率≤30%

3、应用满规格长时间正常运行监测CPU占用率
Monkey测试
CPU占用率≤30%

4、应用正常运行期间监测CPU占用率峰值
应用正常运行:打开应用进行基本操作
CPU占用率≤50%

测试方法:
1、使用adb命令:
1) top -m -s cpu |grep packageName


top cpu 参数:
-m 显示最大数
-s 按指定行排序
-t 显示进程名称
-n 在退出前刷新几次
-d 刷新间隔

如果反复进行某个操作,cpu占用过高且一直无法释放,那便可能存在风险。

2)dumpsys cpuinfo |grep packageName


2、使用第三方测试工具:Emmagee、GT等。
3、使用AndroidStudio自带的检测工具Android Monitor。

四、FPS (应用的使用流畅度)

FPS是图像领域中的定义,是指画面每秒传输帧数,通俗来讲就是指动画或视频的画面数。FPS是测量用于保存、显示动态视频的信息数量。每秒钟帧数愈多,所显示的动作就会愈流畅。
´一般来说,Android设备的屏幕刷新率为60帧/s,要保持画面流畅不卡顿,要求每一帧的时间不超过1000/60=16.6ms,这就是16ms的黄金准则,如果中间的某些帧的渲染时间超过16ms,就会导致这段时间的画面发生了跳帧,因此原本流畅的画面变发生了卡顿。

测试方法:
1、adb命令
1)打开手机:开发者选项—>profile GPU rendering —> in adb shell dumpsys gfxinfo
2) 操作要测试的apk
3) cmd窗口输入命令: adb shell dumpsys gfxinfo packageName
4) 得到一个矩阵数据,计算矩阵中帧率大于16的点所占比例,即为卡顿比

 

含义:
Draw: 表示在Java中创建显示列表部分中,OnDraw()方法占用的时间。
Process:表示渲染引擎执行显示列表所花的时间,view越多,时间就越长。
Execute:表示把一帧数据发送到屏幕上排版显示实际花费的时间。
Draw + Process + Execute = 完整显示一帧 ,这个时间要小于16ms才能保存每秒60帧。

5)通过execl进行表格处理可以直观的查看软件的流畅度


2、除了使用adb shell, 还可以直接使用开发者选项自带的图表
1)打开手机:开发者选项—>profile GPU rendering —> on screen as bars
2) 操作被测的软件
3)界面会显示如下的一个统计数据表


2、使用第三方测试工具:Emmagee、GT等。
3、使用AndroidStudio自带的检测工具Android Monitor。

五、GPU渲染

GPU渲染是指在一个像素点上绘制多次(超过一次):显示一个什么都没有做的activity界面算作画了1层,给activity加一个背景是第2层,在上面放了一个Text View(有背景的Text View)是第3层,Text View显示文本就是第4层仅仅只是为了显示一个文本,却在同一个像素点绘制了四次,这是一定要优化的。过度绘制对动画性能的影响是极其严重的,如果你想要流畅的动画效果,那么一定不能忽视过度绘制。

测试方法:
1、手机自动的Debug GPU overdraw
1)打开手机—>设置—>开发者选项—>Debug GPU overdraw—>show overdraw areas
2)打开被测的应用


GPU过渡渲染不同的颜色代表不同的绘制程度
1)、原色:无过渡绘制
2)、蓝色:绘制一次 (理想状态)
3)、绿色:绘制二次
4)、浅红:绘制三次 (可以优化)
5)、深红:绘制四次 (必须优化)

测试指标:
1、控制过渡绘制为2x
2、不允许存在4x过渡绘制
3、不允许存在面积超过屏幕1/4的3x过渡绘制

六、耗电量
测试应用对电量的消耗前需要对手机本身的电量消耗有个大概了解,测试前先看规定时间内手机正常待机下(重启后待机)电量消耗为多少。然后再启动待测试APP看看消耗的电量增加了多少取差值。

测试点:
  测试手机安装目标APK前后待机功耗无明显差异;
  常见使用场景中能够正常进入待机,待机电流在正常范围内;
  长时间连续使用应用无异常耗电现象。

测试方法 :(先关闭所有的应用,再打开被测app)
1、使用第三方测试工具:Emmagee、GT等,只需要测试的电流静置一晚,待机电流在正常范围内即可。一般是被测应用对比待机电流<=2mA。
2、使用adb命令
adb shell dumpsys batterystats |grep packageName

Guess you like

Origin www.cnblogs.com/klb561/p/12014240.html