（1）App独特测试点：

客户端兼容性测试：系统版本、不同深度定制的rom、屏幕分辨率、中断测试、安装、卸载、升级、对其他程序的干扰等

需要的一些工具：

appnium / lr /  jmeter / 打包工具 / 抓包工具等

（2）是否需要搭建环境？

基本不需要，服务端统一搭建部署服务，跟在某个客户端运行关系不大，无需单独部署环境。

（3）推荐两个上传App安装包到应用市场的工具网站：

①www.fir.im

②www.pgyer.com

（4）网络环境测试：

手机的网络目前主要分为2G、3G、wifi，其中2G的网络相对于比较慢，测试时尤其要注意此块的测试。

1) 无网络时，执行需要网络的操作，给予友好提示，确保程序不出现crash。

2) 内网测试时，要注意选择到外网操作时的异常情况处理。

3) 在网络信号不好时，检查功能状态是否正常，确保不因提交数据失败而造成crash。

4) 在网络信号不好时，检查数据是否会一直处于提交中的状态，有无超时限制。如遇数据交换失败时要给予提示。

5) 在网络信号不好时，执行操作后，在回调没有完成的情况下，退出本页面或者执行其他操作的情况，有无异常情况。此问题也会经常出现程序crash。

注：一般可以选择在地铁、公交、电梯、隧道等代表性的场所进行测试。

（5）软件权限：

1）扣费风险：包括发送短信、拨打电话、连接网络等

2）隐私泄露风险：包括访问手机信息、访问联系人信息等

3）对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测

4）限制/允许使用手机功能接入互联网

5）限制/允许使用手机发送接受信息功能

6）限制/允许应用程序来注册自动启动应用程序

7）限制或使用本地连接

8）限制/允许使用手机拍照或录音

9）限制/允许使用手机读取用户数据

10）限制/允许使用手机写入用户数据

11）检测App的用户授权级别、数据泄漏、非法授权访问等

（6）安装与卸载安全性：

1）应用程序应能正确安装到设备驱动程序上

2）能够在安装设备驱动程序上找到应用程序的相应图标

3）是否包含数字签名信息

4）JAD文件和JAR包中包含的所有托管属性及其值必需是正确的

5）JAD文件显示的资料内容与应用程序显示的资料内容应一致

6）安装路径应能指定

7）没有用户的允许，应用程序不能预先设定自动启动

8）卸载是否安全，其安装进去的文件是否全部卸载

9）卸载用户使用过程中产生的文件是否有提示

10）其修改的配置信息是否复原

11）卸载是否影响其他软件的功能

12）卸载应该移除所有的文件

（7）数据安全性 ：

1）当将密码或其他的敏感数据输人到应用程序时，其不会被储存在设备中，同时密码也不会被解码

2）输人的密码将不以明文形式进行显示

3）密码，信用卡明细，或其他的敏感数据将不被储存在它们预输人的位置上

4）不同的应用程序的个人身份证或密码长度必需至少在4一8个数字长度之间

5）当应用程序处理信用卡明细，或其他的敏感数据时，不以明文形式将数据写到其它单独的文件或者临时文件中。以防止应用程序异常终止而又没有侧除它的临时文件，文件可能遭受人侵者的袭击，然后读取这些数据信息。

6）当将敏感数据输人到应用程序时，其不会被储存在设备中

7）备份应该加密，恢复数据应考虑恢复过程的异常通讯中断等，数据恢复后再使用前应该经过校验

8）应用程序应考虑系统或者虚拟机器产生的用户提示信息或安全替告

9）应用程序不能忽略系统或者虚拟机器产生的用户提示信息或安全警告，更不能在安全警

（8）运行：

1）App安装完成后的试运行，可正常打开软件。

2）App打开测试，是否有加载状态进度提示。

3）App打开速度测试，速度是否可观。

4）App页面间的切换是否流畅，逻辑是否正确

（9）应用的前后台切换：

1) APP切换到后台，再回到app，检查是否停留在上一次操作界面。

2) APP切换到后台，再回到app，检查功能及应用状态是否正常

3) app切换到后台，再回到前台时，注意程序是否崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。

4) 手机锁屏解屏后进入app注意是否会崩溃，功能状态是否正常，尤其是对于从后台切换回前台数据有自动更新的时候。

5) 当App使用过程中有电话进来中断后再切换到app，功能状态是否正常

6) 当杀掉app进程后，再开启app，app能否正常启动。

7) 出现必须处理的提示框后，切换到后台，再切换回来，检查提示框是否还存在，有时候会出现应用自动跳过提示框的缺陷。

8) 对于有数据交换的页面，每个页面都必需要进行前后台切换、锁屏的测试，这种页面最容易出现崩溃。

（10）免登录 ：

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

1) app有免登录功能时，需要考虑IOS版本差异。

2) 考虑无网络情况时能否正常进入免登录状态。

3) 切换用户登录后，要校验用户登录信息及数据内容是否相应更新，确保原用户退出。

4) 如果一个帐户只允许登录一台机器。需要检查一个帐户登录多台手机的情况。原手机里的用户需要被踢出，给出友好提示。

5) app切换到后台，再切回前台的校验

6) 切换到后台，再切换回前台的测试

7) 密码更换后，检查有数据交换时是否进行了有效身份的校验

8) 支持自动登录的应用在进行数据交换时，检查系统是否能自动登录成功并且数据操作无误。

9) 检查用户主动退出登录后，下次启动app，应停留在登录界面

（11）数据更新：

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

1) 需要确定哪些地方需要提供手动刷新，哪些地方需要自动刷新，哪些地方需要手动+自动刷新。

2) 确定哪些地方从后台切换回前台时需要进行数据更新。

3) 根据业务、速度及流量的合理分配，确定哪些内容需要实时更新，哪些需要定时更新。

4) 确定数据展示部分的处理逻辑，是每次从服务端请求，还是有缓存到本地，这样才能有针对性的进行相应测试。

5) 检查有数据交换的地方，均有相应的异常处理。

（12）离线浏览：

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

1) 在无网络情况可以浏览本地数据

2) 退出app再开启app时能正常浏览

3) 切换到后台再切回前台可以正常浏览

4) 锁屏后再解屏回到应用前台可以正常浏览

5) 在对服务端的数据有更新时会给予离线的相应提示

（13）App更新：

1) 当客户端有新版本时，有更新提示

2) 当版本为非强制升级版时，用户可以取消更新，老版本能正常使用。用户在下次启动app时，仍能出现更新提示。

3) 当版本为强制升级版时，当给出强制更新后用户没有做更新时，退出客户端。下次启动app时，仍出现强制升级提示。

4) 当客户端有新版本时，在本地不删除客户端的情况下，直接更新检查是否能正常更新。

5) 当客户端有新版本时，在本地不删除客户端的情况下，检查更新后的客户端功能是否是新版本。

6) 当客户端有新版本时，在本地不删除客户端的情况下，检查资源同名文件如图片是否能正常更新成最新版本。

如果以上无法更新成功的，也都属于缺陷。

7）测试App的增量升级，测试App在升级失败以后，是否可以继续使用升级之前的版本。

8）新版版发布后，配合不同网络环境的自劢更新提示及下载、安装、更新、启劢、运行的验证测试。

需要检查的内容：

测试升级后的功能是否与需求说明一样

测试与升级模块相关的模块的功能是否与需求一致

升级安装意外情况的测试（如死机、断电、重启）

升级界面的UI测试

不同操作系统间的升级测试

数字签名、升级覆盖安装、下载后手动覆盖安装、跨版本升级、升级后可以正常使用。覆盖安装要确保数据库有字段更新的话，能正常更新，否则就容易导致app异常。

（14）定位、照相机服务:

1) App有用到相机，定位服务时，需要注意系统版本差异

2) 有用到定位服务、照相机服务的地方，需要进行前后台的切换测试，检查应用是否正常。

3) 当定位服务没有开启时，使用定位服务，会友好性弹出是否允许设置定位提示。当确定允许开启定位时，能自动跳转到定位设置中开启定位服务。

4) 测试定位、照相机服务时，需要采用真机进行测试。

(15)时间测试:

客户端可以自行设置手机的时区、时间，因此需要校验该设置对app的影响。

中国为东8区，所以当手机设置的时间非东8区时，查看需要显示时间的地方，时间是否展示正确，应用功能是否正常。时间一般需要根据服务器时间再转换成客户端对应的时区来展示，这样的用户体验比较好。

比如发表一篇微博在服务端记录的是10：00，此时，华盛顿时间为22：00，客户端去浏览时，如果设置的是华盛顿时间,则显示的发表时间即为22:00,当时间设回东8区时间时，再查看则显示为10：00。

(16)PUSH测试:

1) 检查push消息是否按照指定的业务规则发送

2) 检查不接受推送消息时，检查用户不会再接收到push.

3) 如果用户设置了免打扰的时间段，检查在免打扰时间段内，用户接收不到PUSH。 在非免打扰时间段，用户能正常收到push。

4) 当push消息是针对登录用户的时候，需要检查收到的push与用户身份是否相符，没有错误地将其它人的消息推送过来。

一般情况下，只对手机上最后一个登录用户进行消息推送。

5) 测试push时，需要采用真机进行测试。

(17)性能测试:

评估App的时间和空间特性 ：

1）极限测试：在各种边界压力情况下，如电池、存储、网速等，验证App是否能正确响应。

内存满时安装App --运行App时手机断电 --运行App时断掉网络

2）响应能力测试：测试App中的各类操作是否满足用户响应时间要求 。 --App安装、卸载的响应时间 --App各类功能性操作的影响时间

3）压力测试：反复/长期操作下、系统资源是否占用异常。

App反复进行安装卸载，查看系统资源是否正常

其他功能反复进行操作，查看系统资源是否正常

4）性能评估：评估典型用户应用场景下，系统资源的使用情况。

可测试的方面- 安装和启动时间- CPU的占用- 内存的占用- 流量的耗用- 电量的耗用- 后端,测试App中的各类操作是否满足用户响应时间要求，主要是测试点在网速方面，2g，3g，wifi， 4g一定要覆盖到- 后端 有网络并发

(18)交叉事件测试:

针对智能终端应用的服务等级划分方式及实时特性所提出的测试方法。交叉测试又叫事件或冲突测试，是指一个功能正在执行过程中，同时另外一个事件或操作对该过程进行干扰的测试。

如：App在前/后台运行状态时与来电、文件下载、音乐收听等关键运用的交互情况测试等。交叉事件测试非常重要，能发现很多应用中潜在的性能问题。

1） 多个App同时运行是否影响正常功能

2） App运行时前/后台切换是否影响正常功能

3） App运行时拨打/接听电话 4） App运行时发送/接收信息

5） App运行时发送/收取邮件

6） App运行时切换网络（2G、3G、4G、WIFI ）

7） App运行时浏览网络

8） App运行时使用蓝牙传送/接收数据

9） App运行时使用相机、计算器等手机自带设备

(19)兼容测试:

主要测试内部和外部兼容性

1）与本地及主流App是否兼容

2）基于开发环境和生产环境的不同，检验在各种网络连接下(WiFi、GSM、GPRS、EDGE、WCDMA、CDMA1x、CDMA2000、HSPDA等)，App的数据和运用是否正确

3）与各种设备是否兼容，若有跨系统支持则需要检验是否在各系统下，各种行为是否一致

不同操作系统的兼容性，是否适配

不同手机屏幕分辨率的兼容性

不同手机品牌的兼容性

(20)用户体验测试:

以主观的普通消费者的角度去感知产品或服务的舒适、有用、易用、友好亲切程度。 通过不同个体、独立空间和非经验的统计复用方式去有效评价产品的体验特性升产品的潜在客户满意度。

1）是否有空数据界面设计，引导用户去执行操作。

2）是否滥用用户引导。

3）是否有不可点击的效果，如：你的按钮此时处于不可用状态，那么一定要灰掉，或者拿掉按钮，否则会给用户误导

4）菜单层次是否太深

5）交互流程分支是否太多

6）相关的选项是否离得很远

7）一次是否载入太多的数据

8）界面中按钮可点击范围是否适中

9）标签页是否跟内容没有从属关系，当切换标签的时候，内容跟着切换

10）操作应该有主次从属关系

11）是否有横屏模式的设计，应用一般需要支持横屏模式，即自适应设计

(21)硬件环境测试:

手势操作测试

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

2）切换网络对运行中的App的影响

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

4）多个运行中的App的切换

5）App运行时关机

6）App运行时重启系统

7）App运行时充电

8）App运行时kill掉进程再打开

(22)再次总结：

1. UI 测试
app主要核ui与实际设计的效果图是否一致；交互方面的问题建议，可以先与产品经理确认，确认通过后，才开始让开发实施更改或优化

2. 功能测试
根据软件说明或用户需求验证App的各个功能实现；

与其它测试一样，无太大区别，可以看看之前的测试点梳理文章，以及其它老徐的文章；

3. 中断测试
模拟用户真实使用app时会遇到的中断情况进行测试.

如： 网络的断网，切换网络， 断电，来电话/短信，听音乐，切换到其他app， 打开其他app 的通知、低电量时能否正常使用等

4. 兼容以及适配测试
新旧版本的在功能，逻辑层面的兼容测试， 同一个app 在不同系统版本运行，以及不同机型之间的适配测试兼容测试：接口的兼容性测试能够保证大部分的功能完善；

app在不同系统版本上保证运行适配性： 屏幕，系统版本等（系统位数一定要考虑）该部分通过第三方的云平台进行

用不同的支持语言验证App行为。

5. 安全测试

App安全测试大概划分为以下几类：

1）从数据的本地存储到数据的传输、处理以及远程访问等各个环节，基于相应的安全标准/行业标准评估App的安全特性；

借鉴在WebApp和网络安全测试的一些成功经验在智能终端App测试中进行裁减或适配；

2）检测App的用户授权级别，数据泄漏，非法授权访问等；

3）对App的输入有效性校验、认证、授权、敏感数据存储、数据加密等方面进行检测,以期发现潜在的安全问题；

4）基于各种通信协议或相应的行业安全标准检视App是否满足相应的要求。

6. 线上测试
线上测试是产品上线之后一定要完成的，这部分可以根据场景化进行回归测试，其中网络环境要全部覆盖一遍

（23）测试App的消息显示和通知显示：

在安装App的时候是否申请相应的权限

验证收到App新的消息的时候，如何通过通知向用户进行消息展示

测试App能否及时显示和同步消息

测试在多台设备登录App，是否同步消息、设置、内容、数据等

测试App的消息是否同步在PC端（无论Web版本或者PC版本）

测试App中高内存使用的功能

测试App对于读取大量图片、视频等进行高内存占用操作的处理能力

查看App是否有对应的异步加载功能等

测试App的流量和电量消耗

测试App的安装文件大小

测试App占用的存储空间

测试App使用的流量和电量

测试App支持的文件格式

测试App支持Office文件操作

测试App支持图片文件展示

测试App支持PDF文件打开

测试App支持视频和音频文件播放

（24）需要考虑的一些情况：

1）如果程序里面包括分享功能，那么检测点击分享的时候是否会正常给出分享提示，点击分享后所填写的分享内容是否正确

2）app在清空数据或强制退出后还能正常运行否
3）api，包括在app内跳转到另一个界面，在返回来，以及跳转到系统api

4）长时间开机且开app，看是否会出现异常情况

（26）

移动App崩溃的一些常见原因：
设备碎片化：由于设备极具多样性，App在不同的设备上可能有表现不同。

带宽限制：带宽不佳的网络对App所需的快速响应时间可能不够。
网络的变化：不同网络间的切换可能会影响App的稳定性。
内存管理：可用内存过低，或非授权的内存位置的使用可能会导致App失败。
用户过多：连接数量过多可能会导致App崩溃。