App的专项测试

文章目录

App的专项测试都从哪个方面测试
安装和卸载
版本升级
消息推送
弱网测试
兼容性测试
交互性测试

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服务器设置：推送内容/推送时机/推送频率/推送人群（全部用户/部分用户）
手机端设置：是否接收通知，提醒位置等

弱网测试

手工测试

第三方软件

网络测试的一般流程：

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到弱网