在聊移动APP测试用例设计之前，我请大家先思考如下2个问题：
- 第一，我们为什么要做好测试用例设计？——why？
- 第二，好的测试用例设计有什么共性？——what?
深入思考这2个问题的答案是一件很有意义的事情，作为移动互联网时代的产品质量守卫军，我们必须提升自己的测试设计能力，必须清楚的知道要测什么，怎么测。但单从我们测试团队现状来看，有很多人都没有做好准备，测试设计方法仍然比较落后，所以我整理此文，旨在总结沉淀移动客户端测试用例设计实践，帮助测试人员时刻审视完善自我测试能力提升。
那么回到文章开头的2个问题，我也说一下我的理解，有不妥当之处望同行指出。
Why? 为什么要做好测试用例设计？
测试用例设计的目的，通俗来讲主要是通过对需求点的测试设计从而避免测试点的遗漏，而且现在每个公司也都非常认同测试用例设计这个环节存在的必要性和意义，不论测试用例设计的好坏与否，该环节的存在都对质量和效率起到最基本的促进作用。
那么我们为什么要做好测试用例设计？
第一，测试用例设计能力的好坏，直接影响了开发人员对我们的第一印象的好坏。例如，我们如何评价一个优秀的开发人员呢？
- 1、coding好，bug少
- 2、思维严谨，沟通顺畅，有责任心...
同理心，开发人员一般怎样评价一个优秀的测试人员呢？
- 1、case覆盖率高，漏测少
- 2、思维严谨，沟通顺畅，有责任心...
所以，测试人员写不出好的测试用例，就如同开发人员写不好代码一样，有点丢面儿，但是往往很多测试人员根本也意识不到这一点，包括我遇到很多工作了五六年的资深测试人员，测试用例设计能力很一般，姿态却摆的老高，这里就不说了。我想表达的是，测试用例设计毕竟是门基础课，不论是测试新兵老兵，没学好没学扎实都建议再学一遍。
第二，测试用例设计的好坏，直接关系着最根本的测试质量和测试效率的优劣。为什么这么说，从质量角度，好的测试用例设计都是需要经历根据需求设计层层剥析，开发设计逻辑的深入理解去构造的，因而其测试点挖掘的往往更深，场景更全，发生漏测的几率也更低。从效率角度，在开发人员提测前就做好的高质量测试设计，在测试执行阶段，则不用再去费心构造设计，按计划执行完测试用例后，那么这个需求的测试就基本完成了。
what?好的测试用例设计的共性？
这其实是一个见仁见智的问题，不同的测试人员有不同的测试设计风格，这里我们求同存异即可。好的测试用例设计的共性大致如下：
（1）测试设计结构组织合理。从测试用例的组织是开展测试的起点，良好的组织能够帮助我们快速定位到我们想关注的部分，这个部分的好坏关系到测试工作的持续性发展。
（2）测试用例设计覆盖全面且不冗余，用精简的语言描述清楚一条测试用例，用较少的测试用例描述清楚需求测试点的覆盖。
（3）测试用例设计具有可执行，可判定，可再现的特点，即在测试前提符合的前提下，按照测试步骤每一个测试用例都可以顺利执行，同时呈现相应的预期结果，而且测试用例在被多次执行的结果都应该是相同的。
移动客户端平台的测试，在传统的软件测试基础上，本身又具有自身比较突出的诸多特点。比如客户端平台多样化，系统碎片化问题突出，灵活性极高，因此仅仅将测试停留在基本功能以及传统理念上的测试组织，来确保移动客户端的测试全面性是不够的。
传统的用例组织方式，如等价类划分，边界值分析，因果分析等，更多的是从面向如果精简测试用例，确保测试全面的前提下，尽量降低冗余而来的。现在我们推荐一种是面向问题发现的测试的组织方式，即由bug出现的分布对应相应的测试内容，从而达到测试全面性的一种组织方式。
在测试工作的过程中我们需要不断的去总结与储备自己的知识与经验，譬如具备特定属性、环境以及场景，如：PC、手机、智能设备、特定网络环境下，我们需要关注的功能点，容易出错的位置，这将对我们整个测试过程中起到至关作用，让测试变得更高效，发现较多的潜在问题。
在我们的测试工作中，对于某个APP的测试其实有很多东西都是类似的可以抽象出来的，这里TestMadman总结一下大部分APP测试的时候都要考虑到的方面。如果漏下了其他方面，欢迎大家补充。
那么现在我们为大家总结了在移动App测试过程中需要关注的功能点，希望对大家有所帮助！
（ps：为了便于后续的阅读下文中我们将用“APP”代指“应用”）
应用的启动和停止
1.1 首次启动
是否出现欢迎界面，欢迎界面的停留时间合理，欢迎界面后是否正常进入应用;
首次启动时间是否合理;
该拉取的信息是否正确;
桌面图标是否创建成功，功能启动快捷键创建是否成功（某些安卓手机会有在桌面创建应用内某个功能的快捷键的需求）
1.2 二次启动
启动时间是否符合预期；
从各个启动入口进入应用是否可以正常进入：程序启动主图标，某个功能的快捷键，widget；
启动后状态检查：如初始化信息、初始状态、启动对网络
启动进程服务检查：进程名、进程数、服务名、服务数、第三方调用的SDK如GPS
带登陆的应用是否二次启动的时候正常登录
1.3 程序异常退出后的启动
操作出现crash后再启动：如空指针、内存溢出等
手动停止进程：多进程的情况停止所有或者停止其中一个后重启
手动停止服务：多服务的情况，停止所有或者停止部分服务后，未重启直接使用
管家软件一键清理进程后重启
其他系统软件工具停止进程、清理软件数据
程序功能模块
这个一般是根据需求来对应用的所有模块所以功能的触发事件逐一验证。这个最基本的要从两个方面考察，一方面是顺从需求来对模块进行操作，是否达到需求规定的预期；另一方面就是与需求背道而驰是否程序会有相应异常控制等等。廖叔提出了Google正在使用的测试建模的概念，这个方法可以可以帮助我们更好的结合需求分析应用的架构，设计更完善的功能模块用例。
2.1 文本框输入功能
正常输入，输入越界，特殊字符集(\n,\r等等),利用复制粘贴向文本输入内容，输入程序规定不让输入的字符
2.2 事件触发
每一个按钮、每一个可点击项是否能够完成需求规定的功能
尝试点击页面上不可点击的区域，来验证在测试过程当中的预留测试后门是否关闭
权限安全
· 需要用户确认的权限没有授权，权限默认关闭
· 联网权限被管家、系统安全类软件限制情况下的联网操作
· 权限敏感度，如通讯录等为系统的绝密权限谨慎获取
· 使用安全软件进行安全漏洞、病毒扫描，看被测APP是否会被这些安全软件提示有问题而影响用户的对被测APP的使用或者印象
文件存储
· APP使用过程中产生的临时文件存储路径、命名方式等
· APP中涉及的下载操作产生的文件存储方式
· 存储的文件被锁、占用
· 有外置SD、内置SD卡都要考察APP产生的文件是否正确
· APP被安装在SD卡或者手机存储空间
· 磁盘空间不足、磁盘无权限（如读、写）
网络与流量
· 网络信号，尤其是弱网络环境下应用的表现
· 不同运营商网络：电信、联通、移动，2G/3G/4G
· 网络中断、网络恢复场景的逻辑处理（如重试），以及网络提示
· 首次启动应用的流量是否符合预期
· 统计、异常上报对流量的影响
· APP中图片大小、尺寸是否有考虑对网络流量的影响
· 基于流量安全的特殊业务，如仅wifi联网
接口容错
· 请求网络层错误：http response返回非200的状态
· 请求业务层错误：接口返回内容为空、超长、字段类型不匹配
中断测试
· 锁屏中断：停留在程序操作界面进行锁屏，恢复后检查操作是否正常
· 前后台切换：停留在程序操作界面，通过Home键，进行程序的前后台切换
· 加载中断：页面接口请求、界面框架加载时，通过Home键、返回键、快速切换操作进行中断
· 系统异常中断：如关机、断电、来电
机型适配
8.1 分辨率适配
UI结构、对话框基于分辨率、屏幕大小进行适配
8.2 OS版本适配
涉及API调用如获取SIM卡信息、外置SD卡设置（4.4外置SD卡不具备写的权限）
8.3 CPU硬件配置
X86机型、V5、V6、V7、V8
系统配置
· 进程管理：省电管理、后台进程驻留管理
· 显示管理：字体大小、字体类型
· 语言环境：语言环境
· 横竖屏配置：是否支持横竖屏自适应处理
升级 覆盖安装
· 逐步升级：用户数据、设置、状态的保留，特步注意新版本已去掉的状态或设置
· 跳级：即隔开版本覆盖安装
· 降级：覆盖安装更低版本
· 卸载安装 4、卸载安装，安装目录清理，SD卡存储数据不被清理
· 省流量升级：有些助手提供省流量升级的方式
· 在没有更新或者网络时，需要给予用户正确的信息表达
· 如果升级有忽略本次版本升级，那么当有新的升级版本时，是否还有提示升级
· 强制升级 8、不升级无法使用
性能测试
11.1 性能
核心操作的性能指标：如CPU/内存、响应时长、电量、流量
11.2 稳定性
· 选择某些场景做持续反复操作
· Monkey稳定性操作，持续多个小时
11.3 流畅度
列表滑动、返回进入、快速点击（这个肉眼不好评判，可以借助GT，一般打分在90分以上是比较好的）
11.4 软件兼容
· 通用软件 输入法
· 安全软件
· 通信类
· 竞品软件 同类软件，是否出现冲突
竞品对比测试
· 功能方面：与同类竞品软件在UI设计，交互体验等方面进行对比
· 性能方面：同类竞品软件在性能、耗电、流量等方面至少与对方持平，最好不要低于对方太多
软件测试交流群：785128166
微信公众号：程序员二黑；关注后可免费领取一套视频资源；详细讲解了：python自动化测试、web自动化、接口自动化、移动端自动化、面试经验等相关内容，学习资源的价值取决于你的行动，莫做“收藏家”
功能测试精选干货文章合集点这：