App的专项测试

发布于:2023-09-22 ⋅ 阅读:(213) ⋅ 点赞:(0)

App的专项测试都从哪个方面测试

在APP测试过程中,除了功能测试外,还需要进行一些专项测试来发现更为深层的问题,这些问题主要是针对某个特殊方面进行,比如安装卸载升级测试、兼容性测试、弱网测试、中断测试、流量测试、耗电量测试等。

  • 安装和卸载
  • 版本升级
  • 消息推送
  • 弱网测试
  • 兼容性测试
  • 交互性测试

性能测试

  • cpu
  • 内存
  • 启动速度
  • 响应时间
  • 耗电量测试

安装和卸载

安装卸载升级:APP是客户端程序,客户端程序就需要提前进行安装才能使用,因此需要测试安装/卸载/升级操作。

安装测试其实需要覆盖的测试点也很多,并非简单的说常规状态下能够下载即可,既然是要进行测试就需要对客户在异常情况下能够接触到的所有情况进行验证。

所以安装测试的关注点可以从两个部分出发:

    正常场景:

                    在不同的操作系统版本上安装

                    从不同的安装渠道安装(APP商城/手机助手/直接下载apk或者ipa文件安装)

                    不同的安装路径(安装到手机上,安装到SD卡上)

    异常场景:

                    安装时出现异常(关机/断网),恢复后能否继续安装

                    安装时存储空间不够

                    安装时手动取消后再次安装

                    正在运行时覆盖安装高版本

                    卸载后安装

版本升级

强制升级

非强制升级

从临近版本升级

跨版本升级

不同渠道升级(应用商场/手机助手)

升级提醒成功(可不提醒/可以提示升级/强制升级/是否有红点)

应用内升级时非WIFI提醒

升级注意:要看是否升级前后改变了数据的结构,因为可能开发没有处理好会出现升级前后的数据没有正常导入变得混乱。

消息推送

push消息根据英文单词的意思就是推送,在这里也就是APP给你推送的各种消息。通常手机中“设置”-“通知”就是进行push消息的设置,因此需要进行push消息测试。

使用场景:

  • 产品角度:功能需要,如咨询类产品的新闻推送/工具类产品的公告推送/快递签收通知等,常见如百度,支付宝等
  • 运营角度:活动运营需要,如:电商类产品的促销活动,召回用户/提高活跃度等,常见如淘宝,京东

实现原理

有push就会对应有pull(客户端主动获取),当客户端固定时间主动向服务器获取信息,若有更新信息,则发送到客户端,这样的pull是基于短连接(凡是在一次消息交互(发请求-收响应)之后立刻断开连接的情况都称为短连接);那么push(客户端被动接受)在这里很显然就是当服务器有更新信息时,主动发送到客户端,push是基于长连接(也叫持久连接,在TCP层握手成功后,不立即断开连接,并在此连接的基础上进行多次消息(包括心跳)交互,直至连接的任意一方(客户端OR服务端)主动断开连接,此过程称为一次完整的长连接)。

需要频繁交互的场景使用长连接,如即时通信工具(微信/QQ,QQ也有UDP),相反则使用短连接,比如普通的web网站,只有当浏览器发起请求时才会建立连接,服务器返回相应后,连接立即断开。

push和pull对比的话,push方式会比pull方式更好;原因很简单,push方式在满足需求的情况下会更省资源,使用pull方式下客户端需不断监测服务器变化,更费客户端的资源如(CPU/网络流量/系统电量);所以,在APP项目中,基于手机电量与流量的考虑,使用的都是push方式进行消息推送,因此又叫push消息。

常见的推送服务器分类:

操作系统级别的消息推送服务器

  • IOS:APNs(Apple Push Notification service)

  • Android:C2DM(Cloud to Device Messaging)

第三方推送平台

  • 手机厂商类:小米推送/华为推送

  • 第三方平台类:友盟推送/极光推送/云巴(基于MQTT)

  • BAT大厂的平台推送:阿里云移动推送/腾讯信鸽推送/百度云推送

PUSH推送内容测试设置(产品经理关注角度):

  • APP服务器设置:推送内容/推送时机/推送频率/推送人群(全部用户/部分用户)

  • 手机端设置:是否接收通知,提醒位置等

弱网测试

手工测试

第三方软件

image.png

网络测试的一般流程:

step1:首先要考虑网络正常的情况

  • 各个模块的功能正常可用
  • 页面元素/数据显示正常

step2:其次要考虑无网络的情况

  • APP各个功能在无网络情况下是否可用
  • APP各个页面之间切换是否正常
  • 发送网络请求时是否会导致闪退、卡死等异常情况
  • APP各个页面是否显示完整美观,未刷新的页面是否做了相应的提示和处理
  • 在无网络情况下数据是否会丢失
  • 无网络提示信息是否友好

step3:再次考虑弱网情况

①弱网情况下APP是否针对请求做了超时处理

②络延迟的情况下,操作app进行数据同步、OTA升级是否会发生Crash、ANR等严重错误③ 弱

网情况下,APP请求回调未完成时,执行其他动作以及交互时,是否会出现APP闪退等异常。

④ 弱网情况下,原始数据是否出现丢失的情况(弱网下载时会出现丢包情况)

⑤ 弱网环境下,是否会出现请求堆积的情况

⑥ 弱网环境下,APP各个页面是否显示完整

⑦ 系统超时,提示信息是否清晰明确

⑧ 弱网情况下APP的响应时间是否在一个合理的时间范围内

⑨ 请求回调未完成–驾考科四难题攻克弹窗

⑩ 这个弹窗是服务器说了算,服务器知道该用户啥时候弹弹窗。若用户在做题页面时返回了,则该用户下次进入且在服务器缓存时间内,应该给出弹窗(产品逻辑:弹窗出现后用户必须看到才消失)

⑪ 请求堆积:水池注水排水问题

step4:最后考虑网络状态之间的转变

① 断开网络连接以后,操作APP各个功能是否正常

② 同步数据过程中,断开网络连接,APP是否出现异常情况

③ 传输数据过程中,网络由wifi切换到gprs,APP是否出现异常情况

④ 弱网环境下发送的请求是否在恢复网络以后出现重复提交的情况tips:gprs—就是咱们通常所说的流量

二、弱网测试小结

弱网测试作为健壮性测试的重要部分,对于移动端的测试来说必不可少。目前的网络并非完全的流畅WiFi,目前使用最多的是2G,3G,4G,5G,且使用场景多变,如近地铁,上公交,进电梯,进山区等弱网测试显得尤为重要。

总结:

1、弱网测试主要进行特殊网络状态下的功能测试,同时关注用户体验。

2、弱网测试主要包括弱网功能测试、无网状态测试、网络切换测试,用户体验等

三、弱网功能测试

① 这一部分主要是在各种非wifi网络环境下进行的功能测试,同时模拟高延时和高丢包的异常网络环境进行健壮性测试。

② 2G/3G/4G的网络可以通过使用电话卡移动/联通/电信等网络进行模拟,关注页面的响应时间、页面呈现是否完整一致等。

③ 高延迟和高丢包的网络环境需要借助工具来模拟,如Charles。

④ 弱网功能测试建议将整体的功能测试用例在弱网环境下进行一轮测试,相同模块下的功能可以分多个网络条件进行测试。这部分发现的问题可能会有:页面图片在弱网环境下加载不出来(图片加载逻辑需优化)需要模版的页面版式结构混乱(模版文件在弱网环境的加载需优化)页面响应时间较长没有任何显示(页面显示逻辑待优化、重试机制加入)

四、弱网UI测试

弱网情况下:APP很可能出现UI刷新不及时或者不刷新的情况,此时就可能会导致呈现在用户面前的是一个残缺的页面;偶会也会导致出现页面UI元素错乱的情况;

五、无网状态测试

无网状态测试则是在切换网络的情况下进行的测试,主要关注页面的显示与交互、本地数据的存储、断网功能的使用等,经常该部分也需要与网络切换部分协同进行。

断网情况下请求非本地数据的页面需要设定一定的时间等待上限,及时提示网络异常以及提示重试;

断网情况下请求部分本地数据的页面需要观察本地数据的部分是否加载显示正常,待请求的部分是否符合交互给的缺省样式一致;

断网情况下请求完全本地数据的页面是否显示正常。这里还需考虑本地数据存储的情况,有些需要联网后上报服务器的数据本地是否正确存储,联网后这些数据能否正常上报。

无网状态测试建议按照页面划分进行,针对每个页面单独测试无网状态的显示,页面间跳转的显示,页面内功能的点击和显示,同时关注无网到有网时的页面恢复显示状态、数据上报情况是否正常。

六、网络切换测试

这部分主要是进行几个不同网络场景的切换,包括:

wifi-2G/3G/4G、wifi-无网、2G/3G/4G-wifi、2G/3G/4G-无网、无网-2G/3G/4G、无网-wifi

主要关注页面的显示与交互,尤其:弱网到wifi;wifi到弱网

以上两种情况验证是否会有页面的crash以及显示的错乱、session是否一致、请求堆积处理等。

七、用户体验关注

弱网测试的目的就是尽可能保证用户体验,测试点如下:

用户体验:以主现的消费者的角度去考虑我们的产品,以及产品的舒服度,友好感受程度。

(1)页面响应时间是否可接受,关注包括热启动、冷启动时间,页面切换,前后台切换。

(2)页面呈现是否完整一致

(3)超时文案是否符合定义,异常信息是否显示正常。

(4)是否会有超时重连

(5)大流量事件风险:是否会在弱网下进行更新apk包、下载文件等大流量动作。

兼容性测试

兼容性测试是指测试软件在特定的硬件平台上、不同的应用软件之间、不同的操作系统平台上、不同的网络等环境中是否能够很友好的运行的测试。–百度百科

为什么要做兼容性测试

目前碎片化十分严重,尤其是安卓设备。安卓设备碎片化、品牌碎片化,大家熟知的安卓品牌都有好多家,每家可能还有定制的系统,都给我们适配带来了不小的挑战。除了上面的碎片化,当然还有系统版本碎片化,屏幕碎片化等,为了给用户更好的用户体验,做APP的兼容性测试,还是非常有必要的。

1:手工测试

厂商的选择 --》热门的厂商 小米,华为,oppo,vivo

设备选择 -->android 可以根据市面上比较热销的机型,top 前几的手机型号 比如 小米12 红米k50

不同分辨率的选择 2560*1080

不同的屏幕大小选择 6.5 5.5 7

2:用第三方的软件进行测试

APP在不同的机型上由于软件/硬件等不同可能出现各种各样的问题,因此需要做兼容性测试

常见的兼容性测试有手机型号/系统版本/分辨率屏幕尺寸/网络/应用兼容性

手机型号:需要对市场上主流的机型进行覆盖(android:华为,苹果,三星小米,OPPO)需要考虑APP线上排名

系统版本:安卓系统:4.4/5.1/6.0/7.0,ios系统:9.x/10.x/11.x/12.x

分辨率:1080x1920/720x1280

屏幕尺寸:5.5/4.7

网络:3g/2g,4g,wifi…

应用兼容性:手机硬件/外部硬件/操作系统/其他APP

那么如何来执行兼容性测试,一般情况下公司会存在各种型号的手机可以使用真机来进行兼容性测试即可。但是,如果项目的用户量非常大,真机无法覆盖完全,这时候就可以找第三方的兼容性平台进行测试。如:

1、线上云测平台Testin云测

2、Wetest,与Antest类似,也是一个在线测试平台,其提供的功能也与Antest类似,值得一提的是,Wetest的兼容性测试是收费的,而且收费相对来说较高;

3、精灵云测,这个平台提供的功能与前两个在线测试工具提供的功能类似,但是这个平台提供的机型比较全面,但是这个平台也是收费的。

交互性测试

交互性测试也被叫做冲突测试或者干扰测试,这样从字面意思上来进行理解是不是比较好理解了。它指的是一个功能正在执行过程中,另外一个事件或者操作对该过程进行干扰的测试。例如:在APP前台发短信,接打电话等等。

常见的交叉事件测试点有:

手机开锁屏对运行中的 App的影响

APP运行时切换网络(4G/Wi-Fi)

运行中的 App前后台切换的影响

多个运行中的 App的切换

App运行时关机

App运行时重启系统

App运行时充电

App运行时kill掉进程再打开

APP运行时接打电话

APP运行时接收发信息

APP运行时查看应用推送

APP运行接上蓝牙设备

APP运行时接收文件弹窗提醒

APP运行时旋转屏幕


网站公告

今日签到

点亮在社区的每一天
去签到