APP测试指导手册
编写目的
本手册编写旨在帮助刚刚入手的移动端测试人员了解移动端项目,并且了解刚刚接触一个移动端的项目如何入手,有哪些问题需要明确,有哪些问题需要注意,欢迎补充
移动端产品(项目)介绍
移动端产品(项目)展现在眼前的就是一个实际的app应用,支撑这个app应用的是它的后台。后台一般有两种,一种是实际部署的后台管理系统,管理系统的基本信息和业务信息,前台仅仅做展示,查看用,如通讯录APP,掌上直播点播;另一种是后台部署的系统和前台有数据交互的,一般这种系统分为pc展现端和APP展现端,pc端和APP端的展现端存在数据交互,有共同的后台管理系统支撑这两个前台应用,如人大APP,一乡一法庭。
1功能测试
目前公司的app基本是机遇两大移动操作系统android和ios开发的,android开发的app安装文件后缀为apk,ios开发的app安装后缀名是ipa
App客户端程序的安装方式主要有如下几种:
1、手机端浏览器输入下载地址
2、通过(需要单独维护二维码信息,一般二维码是封装了下载地址,所以如果系统提供了此功能,在实施文档中必须说明二维码如何生成如何维护)
3、Android平台,通过Usb连接电脑方式安装
4、App store下载安装(正式发布,目前接触的项目没有正式发布的。如果接触的项目需要在APP store上发布,需要在发布时间前预留出时间,因为提交申请到APP store后审核比较严格,需要的时间较长,具体时间需要提前确认)
目前公司开发了一个APP推送平台,测试过程中可以让开发把apk放在推送平台上,测试人员通过这个平台取包,同时在test上进行备份,这样方便开发和测试的交互
需求分析时需要确认系统支持哪几种安装方式,是否符合项目的要求
测试重点(范围)
1、安卓主要是测试移动端不同版本的操作系统是否能正常安装。Android及IOS不同操作版本系统进行安装测试,不同版本可能会安装不成功
2、安装成功:安装完成后App程序应该可以正常打开
3、测试过程中,先在模拟器上安装,然后再适配机型。有的时候在适配机器上安装后可以打开,在模拟器上安装后无法打开。
4、通过下载的apk,需要查看下载后的apk在手机中存储的文件名是否乱码,尤其注意中文名称的apk,很可能出现乱码情况。
5、全新安装和覆盖安装都需要测试。有的apk安装过之后再次覆盖安装会出现退出或者安装后打不开的情况
1.2升级
手机App程序在服务器端有新版本时,应该允许用户继续使用现有版本,程序可以提供如下几种方式检测更新,以告知用户:
1、每次登录时检测新版本
用户登录后,自动提示服务器端有新版本可供升级,是否升级由用户决定
2、固定时间检测新版本
可以设置一定时间后,进行检测新版本,检测以上次升级时间为准
3、提供检测更新的按钮,用户点击时检测服务器端是否有新版本
一般情况下APP应用都会设置这个版本检测功能,如果需求没有写需要跟踪确认,不管是哪个版本都需要提供该功能,除非通过各种途径明确只做一版后续不维护且各方人员都认可这个结论
测试重点
1、测试不同版本操作系统升级时是否成功
2、跨版本升级
3、升级后,原有数据应该保留
4、第一版的app由于没有app可做升级,测试方法是开发打包时默认把版本号(我们看到的实体是版本号,在开发那里是一个特殊的标识)更改为比当前版本高或者低的版本即可。如果项目发布时间紧急,第一版可以不测试升级,但是这部分的实现方式必须考虑后续的升级情况
5、需求分析时需要明确支持哪些基础版本升级到目前开发版本,在测试时做覆盖测试
1.3卸载
主要测试卸载程序是否卸载干净
卸载后再安装一遍程序。卸载程序后再次安装程序看看之前安装的程序用户数据是否在新安装的程序中留下痕迹(有些数据可能没有完全卸载,保留在缓存中)
1.4同步
功能介绍:
移动终端产品是由后台服务器端和移动客户端组成,后台服务器负责信息存储,并将数据推送到移动终端,由移动终端展现,程序的很多模块都会涉及同步功能;另一种app是不仅做展现,同时还和后台的服务器有数据交互,app端也可以作为数据数据端将数据传送给后台,这部分app有的是必须联网完成数据录入,有的则是支持离线录入数据,联网后数据同步到服务器
同步数据分为全量更新和增量更新,大部分app特别是信息量大的应用,采用的都是增量更新方式,该方式的好处是刷新快,能为用户节省流量;在数据量不大时,如个人案件审批也可以采用全量更新的方式。
数据同步的时机分多钟,一种是首次登录的时候的同步,此时数据量较多时同步时间稍长,一般系统会提供一定的界面引导用户等待;一种是列表的下拉刷新数据,进行数据的上传和下载;一种是列表切换时将切换前列表的数据上传到服务器;一种是系统退出时,将系统产生的数据上传到服务器端,这种情况下一般app都会对于如何退出做特殊处理,比如连续按两次退回键即退出等;一种是前台定时任务去和服务器进行交互更新数据,不需要用户做任
何操作
数据同步的功能设计的时候需要考虑几方面,流量损耗情况,如果系统支持移动网络下进行数据交互此时要特别注意数据同步时流量的损耗情况,必要的时候可以提供仅wifi下更新数据的功能;app是否支持离线试用,如果支持,那就得注意离线时对于数据的操作种类,如果系统同时有pc端的展现界面,那么pc端和app端对于数据操作的冲突情况也是必须要考虑的
测试重点
1、测试各种功能同步的时间点,有些操作不是每次操作都会和后台取得同步更新。
A、实时更新:
时效性较强的软件(如:新闻)一般都会采用实时更新,如:诉讼无忧每次启动系统都会刷新各个页面,每进入一个订阅栏目都会实时更新。
B、非实时更新:
在信息更新频率较低,不需要每次进入页面都及后台同步的情况下,采用非实时更新。例如:诉讼无忧程序中包含多个页签(即不同分类)法院信息、诉讼指南、诉讼工具等,其中“诉讼指南”只有在启动客户端口第一次进入“诉讼指南”页面才有及后台同步的更新操作,因为“诉讼指南”是介绍法院的地址的,而地址不会经常变化,且增加法院也不是经常的,这样做也为用户节省了流量。
2、同步后数据是否及后台服务器端数据相同
1此功能及非移动端测试大致相同不做过多介绍
2注意界面显示,数据正确性