移动APP测试总结

测试资源及准备：

1. 产品需求文档、产品原型图、接口说明文档以及设计说明文档等
2. 测试设备及工具：IOS和andriod不同版本的真机，以及相关测试工具（如：抓包工具、VPN等）
3. 确定被测试的APP的版本号和操作系统类型

设计测试用例：

1. 根据产品需求文档、产品原型图、接口说明文档以及设计说明文档等编写功能测试用例。
2. 用例评审、修改、完善，评审通过后，根据测试用例进行测试

测试阶段：UI测试、功能测试、性能压力测试、异常测试等

UI测试（User Interface 用户界面）

1. UE（User Experience）用户体验
    - 布局与交互图保持一致，风格是否满足用户需求，若有用户体验方面的建议，可以先与产品经理确认，确认通过后，可以正式向开发提出用户体验方面的问题；
    - 真机效果与UE图没有视觉上的严重偏差，如字号，字体大小，加粗，字体颜色，行高，行间距，按钮摆放位置，间隔，尺寸等；
    - 资源图正确使用，没有不必要的拉伸，压缩或其他效果；
    - 各种提示，文字通顺不产生歧义，展示符合用户使用习惯；
    - 动画效果不卡顿，正常展现；
    - 由于测试环境中的数据为模拟数据，测试时必须预先考虑到正式环境中可能出现的数据类型。

2. 页面操作
 	- 是否有防重复点击，即连续快速点击不会出现多个页面或弹窗
	- 单指滑动，单指单击，单指双击，单指长按，单指缩放，多指点击
	- 摇一摇，横竖屏切换，前后台切换
	- 长时间使用，长时间放在后台

3. 不同场景下的页面操作
	- 不同网络，弱网下的页面跳转，点击响应的展现效果
	- 修改本地参数后的页面操作展现效果，如修改日期，时间，时区，语言，键盘等
	- 修改系统权限后的页面操作展现效果，如打开关闭定位，摄像，照片，通讯录等的授权等
	- 页面操作过程中有系统打断，如来电，短信，闹钟提醒，日历提醒，蓝牙提醒，插拔数据线，插拔耳机，待机，锁屏，低电量提醒等
	- 页面操作过程中进行前后台切换，如当页面数据交换时，有弹窗，提示框的时机进行切换容易发现问题。
	- 针对非主线程调用的接口，前端要对异常及无网络情况做异步处理，不提示异常且不影响主线程操作。

4. 页面数据获取和展现
 	- 页面是否有缓存，缓存机制是怎样的，缓存的内容有哪些
	- 在提交页面数据失败后是否有重试机制，重试的接口参数是否保持不变
	- 在页面操作过程中，异步接口返回的内容，是否对用户透明（客户端兼容忽略请求返回msg）
	- 在页面操作过程中，对于接口返回的异常数据，客户端需兼容，保证程序不崩。

功能测试

功能测试时主要依据编写的功能测试用例进行软件功能的遍历；
涉及的测试主要包括基本功能测试，安装、卸载、运行测试，异常处理（包括网络突然断开或者网速过慢、机器内存不足等异常情况的处理）测试。
业务逻辑测试：主要测试客户端业务能否正常完成。
功能点测试：主要测试客户端功能点是否正常使用

关联性测试：主要测试客户端与pc端的交互，客户端处理完后，pc端与客户端数据一致

安装、卸载测试：

1. 生成apk文件在真机上可以安装及卸载；
2. Android手机端通用安装工具。如：豌豆荚
3. 应用程序应能正确安装到设备驱动程序上
4. 能够在安装设备驱动程序上找到应用程序的相应图标
5. 是否包含数字签名信息
6. JAD文件和 JAR包中包含的所有托管属性及其值必需是正确的
7. JAD文件显示的资料内容与应用程序显示的资料内容应一致
8. 安装路径应能指定
9. 没有用户的允许,应用程序不能预先设定自动启动
10. 卸载是否安全,其安装进去的文件是否全部卸载
11. 卸载用户使用过程中产生的文件是否有提示
12. 其修改的配置信息是否复原
13. 卸载是否影响其他软件的功能
14. 卸载应该移除所有的文件

运行测试

1. App安装完成后的试运行，可正常打开软件。
2. App打开测试，是否有加载状态进度提示。
3. App打开速度测试，速度是否可观。
4. App页面间的切换是否流畅，逻辑是否正确

注册

1. 同表单编辑页面
2. 用户名密码长度
3. 注册后的提示页面
4. 前台注册页面和后台的管理页面数据是否一致
5. 注册后，在后台管理中页面提示

1. 使用合法的用户登录系统。
2. 系统是否允许多次非法的登陆，是否有次数限制。
3. 使用已经登陆的账号登陆系统是否正确处理。
4. 使用禁用的账号登陆系统是否正确处理。
5. 用户名、口令（密码）错误或漏填时能否登陆。
6. 删除或修改后的用户，原用户登陆。
7. 不输入用户口令和用户、重复点（确定或取消按钮）是否允许登陆。
8. 登陆后，页面中登陆信息。
9. 页面中有注销按钮。
10. 登陆超时的处理。

注销

1. 注销原模块，新的模块系统能否正确处理。
2. 终止注销能否返回原模块，原用户。
3. 注销原用户，新用户系统能否正确处理。
4. 使用错误的账号、口令、无权限的被禁用的账号进行注销

中断测试

1. APP切换到后台，再回到 App，检查是否停留在上一次操作界面。
2. APP切换到后台，再回到 App，检查功能及应用状态是否正常，IOS4和IOS5的版本的处理机制有的不一样。
3. App切换到后台，再回到前台时，注意程序是否崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。
4. 手机锁屏解屏后进入App注意是否会崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。
5. 当 App使用过程中有电话进来中断后再切换到App，功能状态是否正常
6. 当杀掉 App进程后，再开启 App，App能否正常启动。
7. 出现必须处理的提示框后，切换到后台，再切换回来，检查提示框是否还存在，有时候会出现应用自动跳过提示框的缺陷。
8. 对于有数据交换的页面，每个页面都必需要进行前后台切换、锁屏的测试，这种页面最容易出现崩溃。

免登录

很多应用提供免登录功能，当应用开启时自动以上一次登录的用户身份来使用 App。

1. App有免登录功能时，需要考虑IOS版本差异。
2. 考虑无网络情况时能否正常进入免登录状态。
3. 切换用户登录后，要校验用户登录信息及数据内容是否相应更新，确保原用户退出。
4. 根据MTOP的现有规则，一个帐户只允许登录一台机器。所以，需要检查一个帐户登录多台手机的情况。原手机里的用户需要被踢出，给出友好提示。
5. app切换到后台，再切回前台的校验
6. 切换到后台，再切换回前台的测试
7. 密码更换后，检查有数据交换时是否进行了有效身份的校验
8. 支持自动登录的应用在进行数据交换时，检查系统是否能自动登录成功并且数据操作无误。
9. 检查用户主动退出登录后，下次启动app，应停留在登录界面

数据更新

根据应用的业务规则，以及数据更新量的情况，来确定最优的数据更新方案。

1. 需要确定哪些地方需要提供手动刷新，哪些地方需要自动刷新，哪些地方需要手动+自动刷新。
2. 确定哪些地方从后台切换回前台时需要进行数据更新。
3. 根据业务、速度及流量的合理分配，确定哪些内容需要实时更新，哪些需要定时更新。
4. 确定数据展示部分的处理逻辑，是每次从服务端请求，还是有缓存到本地，这样才能有针对性的进行相应测试。
5. 检查有数据交换的地方，均有相应的异常处理。

离线浏览

很多应用会支持离线浏览，即在本地客户端会缓存一部分数据供用户查看。

1. 在无网络情况可以浏览本地数据
2. 退出 App再开启 App时能正常浏览
3. 切换到后台再切回前台可以正常浏览
4. 锁屏后再解屏回到应用前台可以正常浏览
5. 在对服务端的数据有更新时会给予离线的相应提示

App更新

1. 当客户端有新版本时，有更新提示。
2. 当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动App时，仍能出现更新提示。
3. 当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出客户端。下次启动app时，仍出现强制升级提示。
4. 当客户端有新版本时，在本地不删除客户端的情况下，直接更新检查是否能正常更新。
5. 当客户端有新版本时，在本地不删除客户端的情况下，检查更新后的客户端功能是否是新版本。
6. 当客户端有新版本时，在本地不删除客户端的情况下，检查资源同名文件如图片是否能正常更新成最新版本。如果以上无法更新成功的，也都属于缺陷。

定位、照相机服务

1. App有用到相机，定位服务时，需要注意系统版本差异
2. 有用到定位服务、照相机服务的地方，需要进行前后台的切换测试，检查应用是否正常。
3. 当定位服务没有开启时，使用定位服务，会友好性弹出是否允许设置定位提示。当确定允许开启定位时，能自动跳转到定位设置中开启定位服务。
4. 测试定位、照相机服务时，需要采用真机进行测试。

时间测试

1. 客户端可以自行设置手机的时区、时间，因此需要校验该设置对 app的影响。
2. 中国为东8区，所以当手机设置的时间非东8区时，查看需要显示时间的地方，时间是否展示正确，应用功能是否正常。时间一般需要根据服务器时间再转换成客户端对应的时区来展示，这样的用户体验比较好。比如发表一篇微博在服务端记录的是10：00，此时，华盛顿时间为22：00，客户端去浏览时，如果设置的是华盛顿时间,则显示的发表时间即为22:00,当时间设回东 8区时间时，再查看则显示为10：00。

兼容性及适配测试

1. 硬件的适配：不同手机厂商(华为、OPPO、锤子等)、硬件性能，不同屏幕大小的适配（3.5到5.0屏幕在UI显示有区别，要支持最大到最小）；
2. OS版本的兼容：IOS6-9；Andriod3以上等，如果用了一些新的API在老的系统上不支持会导致crash；
3. 不同分辨率屏幕的适配：移动设备的分辨率多种多样，如果APP没有做比较合适的处理就可能会显示不好，甚至影响功能的操作。
4. 兼容性测试必须在一定数量的真机上进行，由于真机类型过多，尤其Android在做兼容性测试时，可以选取典型的几种运用较多的真机，进行兼容性测试；
5. 另外可以借助开源测试testin云测，进行更多机型的兼容性测试，testin云测提供基本的运行情况和一些截图，以及简单的测试报告，有助于扩大测试的范围。
6. 网络的兼容性：2G3G4GWIFI,弱网下、断网时
7. app跨版本的兼容性

稳定性测试

1. 安卓APP的稳定性常常使用monkey命令进行测试，通过随机事件流模拟人的操作，对检查程序的内存溢出、空指针有很大的作用。
2. Monkey主要用来检测系统ANR及Crash等问题

安全性测试

1. 软件权限：其中包括发送信息，拨打电话，链接网络，访问手机信息，联系人信息等等
2. 数据在本地的存储、传输等
3. 执行某些操作时导致的输入有效性验证、授权、数据加密等方面
4. 基于各种通信协议或者行业标准来检查

支付测试

1. 支付结果的确认，数据库查询
2. 请求报文是否加密
3. 不同场景的支付:金额足够、金额不足、重复支付、无网支付、弱网支付、同账号多平台一起支付、余额宝微信信用卡等多种支付方式、不同支付方式的组合、密码正确/错误、支付上限等情况
4. 选择付款方式为‘支付宝’，测试是否提示“允许打开支付宝”
5. 测试支付宝没有安装的情况下，APP是否有正确提示（未安装支付宝）
6. 测试支付宝正确安装的情况下，未登录支付宝，是否提示登录页面
7. 测试支付宝正确安装的情况下，已登录支付宝，是否提示支付页面

性能测试

1. 客户端性能测试重点关注：安装卸载时间、启动时间、页面加载时间、主要功能占用的CPU、内存、流量、耗电量等，以及与同类产品相比较是否有优势；
2. 其中页面加载时间可以利用Android调试工具DDMS获取到，在DDMS里面搜索Displayed关键字就可以看到页面加载时间；
3. 运行过程中主要功能占用的CPU、内存、流量等可以借助开源工具emmagee（适用于Android）获取到；
4. 至于服务器端的性能，主要利用接口对服务器施加压力，重点关注响应时间、吞吐量、并发数、事物通过率等，可以视同工具loadrunner、jmeter进行测试。

回归测试

bug修复后的回归测试，上线交付前进行全部的回归，验证