移动端测试设计总结

一、背景

在2019Q4的线上问题中，漏测原因均为测试用例设计覆盖不全导致，虽然小程序本质上是webview渲染，但对小程序框架宿主功能而言，是属于natvie，需要和基线一起发版上线的，在小程序框架功能的测试上，应更多的考虑移动端的测试用例设计方法。自从H5 web转为小程序框架的测试，在用例设计上大多沿用的web测试方法，很多移动端独有的特性并未考虑，测试方法落后，使得用例设计成为测试质量提升的瓶颈，因此，希望以此总结移动端常用的测试用例设计方法和关注点，完善测试设计，提升移动端的测试能力。

二、移动端和web端测试设计方法对比

移动端的测试，与WEB测试相比，有很多是通用的，比如基础功能性测试、前后端接口交互逻辑、接口容错异常、性能测试、兼容性测试等，但移动端本身还有很多独有的特性，比如应用的安装卸载、应用启动和停止、手机权限控制、系统配置、应用稳定性测试等，这在web测试上是从未考虑过的，是最容易被忽略的部分。

2.1 基础功能性测试

这部分即产品需求文档内所明确要求实现的功能，通常我们可以采用最基本的测试方法，如功能分析、因果分析、等价类边界值划分等基础方法，将产品功能逐级拆分细化，最后转化成功能性用例。这些用例过完后，通常即可保证产品需求功能是完备的，在用户正常操作的情况下不会出现大的问题，之后的问题一般是出现在基本功能外的特殊情况中，比如特殊场景、特殊操作的影响。在这一部分的用例设计上，我们应该做到以下几点：

• 合理划分产品功能模块，逐级细分，并组织用例结构，保证清晰可延展。比如针对页面的测试，我们可以从上往下，从左至右划分出不同的功能模块，再详细梳理每个模块所需事先的功能点。
• 精简的用例条例。用较少的测试用例，描述清楚覆盖的功能测试点，全面而不冗余，这往往取决于上一步针对需求的功能模块划分是合理的
• 稳定的测试方法。在一定的前置条件、执行顺序下，有明确的预期结果
• 考虑用户体验，如布局与UI/UE图是否一致、过场动画效果、文案是否有歧义，站在用户的角度上思考交互是否友好，是否有更好更简单的方式等

2.2 异常容错测试

常见的异常场景有：后端接口异常、人为操作输入、网络环境等，对于web测试，可参考wiki异常场景测试。在移动端上，可能还需要考虑以下场景，应用中断测试（如测试游戏，被电话/闹钟/短信/锁屏/置于后台等中断时的表现），应用资源抢占（如音频、视频、摄像机资源），硬件资源异常（如存储空间、内存不足时的表现）等等

2.3 应用安装卸载

web页面是运行在浏览器内的，所以没有安装和卸载的概念。对于移动端应用安装测试来说，又可以划分为以下几类：

卸载安装：卸载后相关缓存数据目录会被清理

升级覆盖安装：在本地缓存的文件、数据库等得以保留，如果数据在新老版本不兼容，安装时未得以更新，则可能会产生问题。再往下细分又可分为连续升级或跳级安装

2.4 应用启动停止

在应用的启动上，很多APP在首次启动和二次启动是会有不一样的逻辑的，比如首次启动会判断本地是否有相关数据，如果没有则进行下载，那么第二次启动时就不会下载了。这需要根据具体的业务情况进行设计。app启动也有冷启动和热启动之分，冷启动是指应用未运行在后台时启动，热启动是指应用已经存在于后台时的启动。

应用的停止，也有多种方式，如正常返回退出、杀进程、操作中出现崩溃停止、被系统或第三方管理软件停止等，以上的各种情况，均需保证下次能够正常启动。

2.5 权限管理控制

移动端权限随着发展是越增越多，控制也越来越严格，如读取联系人、定位、访问日历、相机、录音、存储等等，如果APP用到了某一项权限，那么在测试时，就一定要覆盖允许、拒绝、使用时询问这三种情况，保证APP在各种情况时均得到良好的处理，不会出现崩溃闪退等重大问题。还有就是权限的申请可能在不同系统版本有一定变化，也需要在测试的时候进行覆盖

2.6 稳定性测试

稳定性测试是为了验证APP在长时间运行的情况下，是否会有崩溃或明显卡顿现象。一般采用的是Monkey命令行工具，通过模拟发送随机事件（如点击、滑动等），监测应用在各种操作下可保持运行的最大时间。

2.7 兼容性测试

web端兼容性一般主要是针对浏览器，当然系统版本、屏幕尺寸分辨率也会稍加考虑，移动端的兼容性测试主要以系统版本、屏幕尺寸分辨率，还有一个很重要的是版本间的兼容性，比如2.0版本新上线的功能，在1.0版本表现是怎样的，会不会出现重大的问题。

2.8 性能测试

性能测试在web端主要是页面的加载时间、白屏时间，移动端性能则比较多，除了页面加载和白屏，还有应用启动时长、CPU、内存、渲染FPS、电量、流量等。

三、小程序框架项目测试关注点

以上阐述了在移动端测试设计上可能需要关注的点，但都比较笼统，每个应用、每个需求的功能点都是不一样的，需要具体的业务具体分析，不能一概而论。针对小程序框架这个业务而言，我们在项目测试上，用例应该要覆盖哪些方面呢。

3.1 影响业务范围

拿到项目后，首先应该确认该需求的范围。基线小程序在业务上来分，有小程序和小游戏两大块，小程序又可分为标准小程序框架和虚拟小程序框架，产品在提需求时，往往只会提到标准小程序，而忽略了虚拟小程序框架和小游戏两块业务，这三大部分在代码上互相独立的。比如需要在小程序框架更多菜单栏内增加反馈入口，需要覆盖虚拟小程序和小游戏，特别小游戏，比较容易被忽略，需要在评审期间就确认。

image.png

3.2 宿主API测试关注点

宿主功能API是小程序业务中比较重要的部分，在用例全集中也占据相当大的比例。对于API的测试，总结了以下用例设计关注点。

• ****业务功能点**** 所要实现的业务基本功能测试，根据需求而定，同时需要判断是否影响线上已有API功能
• 调用传参格式和返回值规范
  API可大致分为两类，同步和异步API两种，同步是直接返回结果，不需要传回调函数，如果是异步，则必须传3个回调函数，分别是success、fail、complete，格式为：{success: res => {}, fail: res=> {}, complete: res => {}}。同时，需要确认触发success和fail的条件，什么情况可认为是success，什么情况算fail，compelete是必须触发的，不管失败还是成功。对于返回值，如果是失败，必须明确code和msg字段，给予友好提示。
• 传参参数
  参数必须考虑到各种异常情况，如参数缺失、类型错误、值错误，以及针对业务功能可能涉及的情况情况，如获取用户手机号需要考虑用户未绑定手机号或其他情况导致无法获取手机号的情况
• 调用权限
  考虑该API是否可以对外部小程序公开，如果不能公开，需要在后台增加相应的权限设置，仅对内部开发者使用。如果可以对外公开，也需要考虑是否要增加权限配置，即小程序内的权限管理页面，如获取用户地址、用户信息、相机等这类的权限设置
• 安全性
  考虑接口安全性问题，如泄露私密信息或恶意调用导致公司利益或形象受损
• 隐私弹窗提醒
  对于涉及到用户隐私信息获取相关的API，需要弹窗提醒以提示用户，如获取手机号、用户名等信息
• 覆盖安装
  如果是涉及到基础库，特别是私有API的基础库js文件的变更，一定要测试覆盖升级安装的
• 性能测试
  对于前端API来说，尽量使用异步线程执行，不要阻塞用户操作导致anr。如果涉及到后台接口，需评估线上调用量并考虑是否需要压测
• 兼容性测试
  按照基线小程序兼容性覆盖

其他容易遗漏的点

• 动画效果
• wifi 4g
• 置于后台
• 与APP资源争抢，如音频视频