最常见的APP Bug,崩溃的测试用例设计
移动App测试与传统台式机 测试相比有一定的复杂性。
这些复杂性可以被分类为:
环境(大量的设备,各种移动OSs,适应频繁OSs变化) 。
设备(触摸式和非触摸式设备,有限的内存容量,电池耗电量) 。
网络(不同的网络和运营商,在不好或无网络的情况下的App行为,离线支持) 。
可用性(方向,触摸,多触摸,缩放,分页和导航的局限性,各种干扰,如来电,来电短信,闹钟,和低电量警报) 。
所有这些手机专有的复杂性需要新的针对移动App测试的测试用例设计方案。
根据调查的结果,移动App崩溃是最常见的移动App Bug ,这是预料中的结果,因为很容易发现一个移动App崩溃。
Android OS上一个写着“强制关闭错误”的弹出窗口跳上屏幕;
当发生崩溃时,iOS中App屏幕突然消失消失。最坏的情况下,App崩溃可能会导致系统故障,操作 系统崩溃。
移动App崩溃原因
为什么移动App经常崩溃?App崩溃有几个原因:从平台或环境到开发问题。
一些崩溃原因(排名不分先后) :
设备碎片化:由于设备极具多样性,App在不同的设备上可能有表现不同。
带宽限制:带宽不佳的网络对App所需的快速响应时间可能不够。
网络的变化:不同网络间的切换可能会影响App的稳定性。
内存管理:可用内存过低,或非授权的内存位置的使用可能会导致App失败。
用户过多:连接数量过多可能会导致App崩溃。
代码错误:没有经过测试的新功能,可能会导致App在生产环境中失败。
第三方服务:广告或弹出屏幕可能会导致App崩溃。
移动App崩溃的测试用例设计
测试用例是移动测试最重要部分之一。
准备和执行预先定义的针对移动App崩溃的测试用例将简化和加速移动App崩溃的测试。
一些通用的触发移动App崩溃的测试场景,如下:
1 验证在有不同的屏幕分辨率, 操作系统 和运营商的多个设备上的App行为。
2 用新发布的操作系统版本验证App的行为。
3 验证在如隧道,电梯等网络质量突然改变的环境中的App行为。
4 通过手动网络从蜂窝更改到Wi-Fi ,或反过来,验证App行为。
5 验证在没有网络的环境中的App行为。
6 验证来电/短信和设备特定的警报(如警报和通知)时的App行为。
7 通过改变设备的方向,以不同的视图模式,验证App行为。
8 验证设备内存不足时的App行为。
9 通过用测试工具施加载荷验证App行为。
10 用不同的支持语言验证App行为。
一个重要原则是:测试你最终要发布给用户的App版本。
可能每日构建、每日测试的理念已经深入人心,我们很多时候测试的只是App的开发和Debug版本,而不是最终的Release版本。
在打包最终的 Release版本时,我们一般还要加上数字签名,或者再加上代码混淆。那么最终的发布版本和Debug版本肯定有不一致的地方。
我们iPhone的 App曾经使用过一个第三方开源库,在Debug版本时完全工作正常,但是正式上线后才发现必定会导致崩溃。
这个代价和经验非常宝贵(其实这个开源库的论 坛上已经讨论并警告过这个问题)。我们后来花了许多力气来修正和弥补这个问题。
如果在一开始就针对Release版本进行了测试,这样的问题是不会出现 的。
测试网络相关的App,有三个非常重要的最佳实践。
1、2G、3G、wifi都要覆盖
这三者之间不仅仅只是网络速度的差别,它们代表了三种不同的网络环境。
另外你可能没有想到一种特殊的情况可以用它们来测出问题:开发环境和生产环境。
一个有经验的开发团队会在内网搭建测试环境来进行开发时的测试,在上线时将配置切换到线上的生产环境。
这个切换应该是在发布流程中需要Check的一个环节。但是,我们有可能遗漏。
所以这个测试用例可以用来防止这种情况的出现,在wifi下内网环境可以work fine,但是2G和3G就不行,只有真实的环境下2G和3G才能正常工作(想想2G和3G是否可以正常访问http://192.168.1.xxx这样的地址就可以了)。
2、HTTP、HTTPS都要覆盖
许多App和后台服务都是通过HTTP来交互的,正常情况下都一切正常。
为什么需要测试HTTPS环境?在一些免费上网的环境中,例如在麦当劳、星巴 克里,它们的网络环境都要输入用户名和密码,通过SSL认证来访问网络。如果你使用HTTP Client的library对这种异常没有做捕获处理,那么你的App必定会崩溃掉。
3、进行网络异常、服务器宕机或出现404、502等情况下的测试
后台服务的稳定性是你有时很难去控制的,尤其是牵涉到DNS、空间服务商的情况下。
国内某著名DNS服务商经常出现大规模域名解析故障,碰到这种情 况,你对后台API的请求很可能就会出现404错误。
而你和API交互的数据应该是某种固定格式例如JSON和XML,这样你的数据解析必然会出现错误, 抛出异常。
如果你对异常没有进行正确的处理可能会导致程序不能正常工作。以下用伪代码解释一下逻辑:
try {
if(request() == success) {
callSuccess();
} else {
callFail();
}
hidePopup();
} catch(e) {
// do nothing, just wait….now popup window will show forever on the screen!!!
// if it is a iOS app, the popup window will lock the screen
}
1、功能性测试:
-
根据产品需求文档编写测试用例。
-
软件设计文档编写用例。
注意:就是根据产品需求文档编写测试用例而进行测试。
2、兼容性测试:
-
Android版本的兼容性
-
手机分辨率兼容性
-
网络的兼容性:2G\3G\4G\WIFI,弱网下、断网时
-
APP跨版本的兼容性
(1)适配性测试:
1>.手机不同分辨率支持:客户端支持的分辨率等
2>.手机不同版本的支持:2.34.04.4等;在测试计划中:需要安排单独的时间用于android不同系统的兼容性测试,包括2.0以下版本和4.0以上等
3>.手机不同厂家系统的支持:不同厂家会有不同android系统,例如:小米,华为,锤子对市面上主流手机的支持
4>.手机不同尺寸的支持:3.5到5.0屏幕在UI显示有区别,要支持最大到最小。
(2)安装、卸载测试:
1>.生成apk文件在真机上可以安装及卸载;
2>.Android手机端通用安装工具。如:豌豆荚
(3)在线升级测试:
1>.验证数字签名
2>.升级后可以正常使用。
3>.在线跨版本升级。
3、性能测试:
-
压力测试:
-
电量流量测试:
-
CPU、内存消耗:
-
APP启动时长
-
Crash率
-
内存泄漏
4、网络测试:
1)外网测试主要现实模拟客户使用网络环境,检验客户单程序在实际网若环境中使用情况及进行业务操作。
2)外网测试主要覆盖到wifi\2G\3G\4G,\wap、电信\移动\联通、所有可能的组合进行测试。
原则:
1)尽可能全面覆盖用户的使用场景,测试用例中需要包含不同网络排列组合的各种可能。
2)还有模拟信号被屏蔽时候。客户端的影响等。还有做外包场景测试,在高山、丘陵、火车上等特殊环境下进行全面测试
5、接口性测试:
-
client端和service端的交互
-
client端的数据更新和service端的数据是否一致
-
client端更新时断开了。
-
client端更新时service端挂了。
6、业务逻辑测试:
1)业务逻辑测试:主要测试客户端业务能否正常完成。
2)功能点测试:主要测试客户端功能点是否正常使用
3)关联性测试:主要测试客户端与pc端的交互,客户端处理完后,pc端与客户端数据一致
7、异常测试:
1)交互异常性测试:客户端作为手机特性测试,包括被打扰的情况;如来电、来短信、低电量测试等,还要注意手机端硬件上,如:待机,插拔数据线、耳机等操作不会影响客户端。
2)异常性测试:主要包含了断网、断电、服务器异常等情况下,客户端能否正常处理,保证数据正确性。
移动端安装包的测试用例
测试项 | 测试子项 | 输入说明 | 预期结果 | 备注 | 实际结果 | 测试结果 |
移动端安装包的测试 | 移动应用的安装 | 安装手册是否规范,是否简洁,是否通俗易懂。 | ||||
安装手册是否齐全,正确,有改动时,文档是否同步更新 | ||||||
直接复制安装程序到电脑上,能否正常安装 | ||||||
按安装手册给出的步骤进行安装,安装是否正确 | ||||||
查看在安装过程中存在的提示信息是否明确,意思是否明确 | ||||||
在安装过程中,点击取消按钮,能否正常退出安装程序,软件是否可用。 | ||||||
安装时是否识别有SD卡,并默认安装到sd卡中 | ||||||
安装过程中,接听电话或者短信,安装是否成功 | ||||||
安装程序是否自动检查系统的磁盘空间 | ||||||
系统磁盘空间不足时,能否中止安装 | ||||||
安装完毕后信息的显示和文件的安装是否正确,完整 | ||||||
软件安装后是否能将相应的文件复制到系统文件夹下 | ||||||
在软件安装过程中,出现突然断电的异常状态时,程序处理是否正常 | ||||||
在软件安装过程中,出现突然断网的异常状态时,程序处理是否正常 | ||||||
在不同的硬件环境下,能否正确,正常,完整的进行安装 | ||||||
在不同的网络环境下(2G/3G/wifi),能否正确,正常,完整的进行安装 | ||||||
在低于所要求的硬件配置的情况下进行安装,能否正确,正常,完整的进行安装。 | ||||||
在已经安装的情况下,所有信息与上次保存一致,覆盖安装能否再次安装 | ||||||
在已经安装的情况下,安装路径不一致,覆盖安装能否再次安装 | ||||||
在已经安装的情况下,卸载原软件,安装高版本,能否正确安装 | ||||||
在已经安装的情况下,卸载原软件,安装低版本,能否正确安装 | ||||||
在已经安装的情况下,不卸载原软件,直接安装高版本,能否正确安装 | ||||||
在已经安装的情况下,不卸载原软件,直接安装低版本,能否正确安装 | ||||||
安装完成后,能否正常启动应用程序 | ||||||
安装完成后,重启手机能否正常启动应用程序 | ||||||
安装完成后,是否对其他应用程序造成影响 | ||||||
安装完成后,能否添加快捷方式 | ||||||
安装完成后,杀毒软件是否会对其当做病毒处理。 | ||||||
安装完成后,快捷方式是否指向安装目录 | ||||||
多进程进行安装,是否安装成功 | ||||||
安装过程中,手机内存不足的情况下,能否正常安装 | ||||||
移动应用的卸载 | 用自带的卸载程序进行正确卸载,能否卸载干净 | |||||
用第三方工具进行卸载,能否卸载干净 | ||||||
在卸载过程中,关闭进程软件能否继续正常使用 | ||||||
在卸载过程中,点击取消按钮,能否正常退出卸载程序,软件能否继续正常使用 | ||||||
在卸载过程中,突然关闭移动设备电源,再次访问程序,程序能否正常运行 | ||||||
在卸载过程中,突然重启设备,再次访问程序,程序能否正常运行 | ||||||
未在使用程序时,直接删除安装目录下的文件,程序能否正常运行 | ||||||
正在使用程序时,直接删除安装目录下的文件,程序能否正常运行 | ||||||
在不同的系统下,进行卸载,能否正常卸载。 | ||||||
在不同的硬件环境下,进行卸载,能否正常卸载。 | ||||||
在不同的网络环境下,进行卸载,能否正常卸载。 | ||||||
卸载成功后,是否对其他程序造成影响 | ||||||
卸载后再次安装,一切功能是否正常 | ||||||
卸载画面上的名称及版本信息是否正确 |
更多推荐
移动APP测试の学习(1)
发布评论