APP 全角色权限与异常场景测试思路

前段时间对接一个需求，甲方提出 APP 的测试工作两天内完成，我并未直接反驳。很多时候工期压得紧，不代表测试可以简化边界与异常场景。下面把我的测试思路分享出来；如果项目包含多语言能力，下文所有测试维度，都需要在各语种环境下再完整遍历一轮。

一、测试前准备

1.测试环境：独立测试环境，提前建好全套测试账号，每个账号状态固定、可复现；会员区分不同周期（月卡、季卡、年卡等），方便分别验证权益。

2.兼容原则：真机优先，受现有设备条件限制，兼容性做到现有机型尽量全覆盖，不强行扩大设备池，测试报告中备注设备清单与局限性。

3.核心校验标准：权限优先。同一个功能入口，不同用户看到的按钮、可操作范围、提交权限、会员权益、付费入口必须和身份匹配；禁止出现越权操作、前端隐藏接口放行、缓存残留旧身份数据。

4.执行方式：每个用户角色独立遍历 APP 全部功能模块（首页、列表、详情、个人中心、会员页、订单、支付、编辑提交、分享、收藏等），先正向主流程，再叠加异常场景复测。

5.抵用券计算规则专项：提前完成测试数据预置，梳理各类抵用券适用场景、计算公式与预期结果，每一类券均可单独编写测试用例；用例编写范式可参考上一篇预警类用例。

二、用户角色准备

三、安装与兼容性测试

1.iOS 安装：内测包、正式包安装、覆盖安装、卸载重装、低版本 iOS、主流 iPhone 机型；检查安装、启动、首次弹窗、权限申请（相册、通知等）、闪退、布局错乱。

2.Android 安装：正式包、内测包，覆盖主流厂商定制系统（小米、华为、OPPO、vivo 等）、不同分辨率；测试正常安装、覆盖升级、卸载、禁止安装来源未知应用场景、权限弹窗。

3.兼容备注：受现有真机数量限制，优先使用项目用户占比高的机型；模拟器仅做辅助，重点异常（弱网、断网、崩溃）优先真机验证；测试报告写明本次用到的设备清单，说明兼容覆盖边界。

四、正向功能 + 权限基线测试

每一类账号单独走一遍 APP 全部功能，包括全部菜单、页面、弹窗、按钮：

1.浏览类：文章列表、详情、图片、视频、搜索、筛选、收藏、分享；

2.操作类：表单编辑、提交、预约、下单、支付、订单查看、售后；

3.会员类：会员中心、权益说明、会员专属内容、会员价、优惠券；

4.个人中心：资料修改、账号绑定、消息、设置、退出登录。

每条功能判定标准： 

A.该身份有权限：页面正常渲染、按钮可点击、提交成功、数据落库正确；

B该身份无权限：按钮置灰 / 隐藏、点击弹窗提示 “需要登录 / 开通会员”，后端接口拒绝越权请求，不能只做前端隐藏。

五、专项异常场景测试

在上述所有角色基础上叠加复测以下各种情况：

1.验证码相关异常

验证码错误、验证码过期、验证码频繁发送、输入空格 / 复制多余字符；

同一账号多次验证码失败，校验限流、锁定机制；

验证码请求过程中切后台、关闭 APP。

预期：错误提示清晰，不崩溃，不绕过校验。

2. 操作中途中断：提交未完成就回退 / 关闭 APP

覆盖登录、表单提交、下单、开通会员、支付提交等关键流程：

点击提交，接口请求中，直接点返回上一页；

提交请求中，直接划掉进程关闭 APP；

提交中锁屏、切后台长时间挂起再切回。

预期：不会产生脏数据、重复订单、重复会员、状态错乱；后台幂等处理，前端状态可恢复，提示友好。

3 .付费 / 支付流程异常

唤起支付后，主动取消支付；

支付中途断网、关闭APP；

支付回调延迟、支付成功但 APP 页面未刷新；

取消支付后，订单状态、会员状态保持正确，不会出现 “未付款权益到账”。

4. 用户身份切换对比测试

操作路径：A 账号登录 → 操作若干功能 → 退出登录 → 切换 B 账号（权限差异大的组合：游客↔会员、过期会员↔有效会员、普通用户↔交易用户） 重点检查：

页面缓存清空，不残留上一个用户的订单、会员标识、收藏、个人信息；

切换后接口自动使用新 token，不会拿旧身份继续请求；

会员价格、专属入口、订单列表实时刷新；

多账号来回切换多次，不出现身份混淆、权限错乱。

5. 网络专项：断网、弱网、网络切换

可以借用工具Fiddler或Charles（手机上不用装很多软件）

断网（飞行模式）：打开页面、下拉刷新、提交表单、发起支付；要有友好提示，不卡死、不崩溃；

弱网（低带宽、高延迟）：验证 loading 状态、超时提示，超时后可重试；禁止无限 loading；

网络切换：WiFi 切 4G、4G 切 WiFi、恢复网络后自动重试 / 手动重试逻辑；

弱网下连续多次点击提交：防重复提交、防重复下单。

6. 高频点击、重复点击测试

所有提交按钮、查询按钮、支付按钮、切换 tab、会员开通按钮：短时间连续多点。 预期：防抖生效，不重复发请求、不重复生成订单、不重复扣费。

7 编辑框输入边界与安全输入测试

超长文本：超过字段最大长度，前端限制截断 / 提示，后端校验不报错、不数据库异常；

特殊字符：emoji、全角符号、换行符、@#￥%&* 等；

注入类 payload：XSS 脚本、SQL 注入语句 <script>alert(1)</script>、' or 1=1 -- 等；

校验目标：输入可正常过滤转义，不会弹窗执行脚本、不会篡改数据库，防止注入漏洞。

六、测试执行顺序建议

1.先完成 iOS、Android 安装、基础启动兼容；

2.逐个账号登录，按角色矩阵跑【正向权限基线】，记录权限是否符合预期；

3.在每个角色上叠加：验证码异常、中断关闭、取消支付；

4.集中做身份交叉切换测试（重点测缓存和 token 污染）；

5.统一叠加弱网、断网、高频点击、输入异常、注入测试；

6.回归一轮核心支付、会员开通、订单，防止异常场景引入状态 bug。

七、缺陷判定重点

1.越权缺陷：前端隐藏但后端接口可直接访问、游客能拿到会员接口数据、过期会员还能使用会员权益；

2.状态不一致：APP 展示状态和后台不一致、支付取消但权益发放、续费后会员有效期计算错误；

3.脏数据：关闭 APP / 回退中断后，产生空订单、重复订单、重复会员记录；

4.缓存问题：切换账号后，页面还是上一个用户的数据；

5.兼容崩溃：特定机型安装失败、启动闪退、布局遮挡；

6.安全缺陷：输入框未过滤 XSS/SQL 注入，可执行脚本或绕过校验。

八、小结

这套测试思路不是简单点点功能，而是以用户身份和权限为骨架，把游客、新老用户、交易用户、会员全生命周期状态纳入验证矩阵，同时补齐移动端最容易出事故的中断、网络、支付、输入安全场景。适合 APP 版本上线前验收、会员体系迭代、支付链路改版时使用；在真机资源有限的项目里，优先保证角色全覆盖、核心异常不漏测，兼容性如实写明覆盖边界，让测试结论可信可控。

如果您有补充与纠正，欢迎交流！