测试意识训练-12

题目来自Gemini

我们先从基础训练开始（包含三个训练），然后再逐一进行测试意识训练。

基础训练

场景设定： 移动端 APP 的“指纹/面容快捷登录”功能 功能描述： 用户在登录页可以选择开启生物识别登录。开启后，下次打开 APP 时，系统自动拉取系统级生物识别弹窗，验证通过后直接进入首页，无需输入账号密码。

训练一：异常场景测试 问题描述： 验证生物识别在非理想状态下的交互表现。 挑战： 请列举至少 5 个可能导致生物识别登录失败的场景，并说明你认为 APP 应该如何处理这些失败？

训练二：兼容性与权限测试 /问题描述： 针对移动端碎片化特征进行的专项验证。 挑战： 当用户在系统设置中关闭了该 APP 的生物识别权限，或者用户在系统层删除了所有指纹/面容数据时，APP 的登录页应该呈现什么样的状态？

训练三：安全性测试 问题描述： 确保生物识别功能不会成为安全漏洞。 挑战： 如果用户在 A 设备上开启了生物识别，随后他在 B 设备上修改了登录密码，此时 A 设备的生物识别登录是否应该继续有效？请给出你的理由。

回答：

训练一：

1.环境影响（阳光、灯光）导致人脸识别失败。处理：提示用户避开影响的阳光、灯光

2.手指失水、擦伤...导致指纹识别失败。处理：提示换一个手指或通过密码登录

3.不太清楚了

训练二：

emm...正常状态，并且会提示当前已打开生物识别登录，请打开系统权限，通过生物识别可以快速登录

训练三：

应该继续有效，但是有一个前提，就是在修改密码时，必须也进行生物识别。如果没有进行生物识别，那么会修改失败。

以下是针对基础训练的评价与补充：

基础训练点评与补充

训练一：异常场景测试

• 评价： 捕捉到了环境和物理层面的失效，但遗漏了“系统中断”和“尝试上限”这两个核心逻辑。
• 补充遗漏点：
• • 尝试次数限制： 连续错误 5 次（通常是系统级限制）后，APP 是否能自动降级切换回密码登录？
  • 进程中断： 识别弹窗弹出时，突然来电、电量不足弹窗或 APP 切换到后台，识别状态是否会被重置？
  • 硬件不可用： 传感器被遮挡、损坏，或在不支持生物识别的低端机型上强制开启的情况。

训练二：兼容性与权限测试

• 评价： 考虑到了引导，但忽略了“同步状态”的准确性。
• 补充遗漏点：
• • 状态同步： 若权限已关，APP 内部的“生物识别开关”应自动置为关闭状态，避免逻辑冲突。
  • 数据清空： 若系统指纹被全部删除，APP 必须强制要求重新输入密码登录，并清除本地的 Token（令牌），因为原有的生物特征对应关系已失效。

训练三：安全性测试

• 评价： 你的方案（修改密码必须验证生物识别）在逻辑上可行，但在安全界内有更通用的做法。
• 补充遗漏点：
• • 标准做法： 应该立即失效。修改密码意味着账户安全状态发生重大变更。为了防范“设备被盗且密码被改”的风险，通常要求在修改密码后，所有关联的生物登录 Token 必须作废，用户必须手动用新密码登录一次来重新授权。
  • Token 绑定： 测试应验证修改密码后，旧的生物识别 Token 是否在服务端已撤销。

今日练习：第一题

场景描述： 一个电商 APP 的收银台页面。用户点击“立即支付”后，APP 会弹出支付方式选择（如：微信支付、支付宝、银行卡、余额支付），并显示实付金额。

挑战： 当用户在“支付中”的状态下（例如：已经跳转到微信支付界面或正在等待支付结果返回），突然发生以下两种情况，你会如何设计测试点来验证 APP 的逻辑健壮性？

1. 网络切换： 用户从信号良好的 Wi-Fi 环境切换到了弱网环境（或断网）。
2. 应用中断： 支付中途手机突然来电，或者用户通过手势强行杀掉了 APP 进程。

回答：

1.对于网络切换，需要重点关注交易状态与用户的实际数据变化，如果交易成功，则订单状态更新为已支付，用户正常扣费。如果交易失败，则订单状态更新为未支付或支付失败，用户没有扣费。

2.对于应用中断，APP内应该有可以查询历史订单的地方（不论是成功还是失败），而且订单状态和用户数据必须同步，类似于1的回答

以下是针对该题目的评价与补充：

第一题：评价与补充

• 评价： * 优点： 意识到了“订单状态”与“实际扣款”的一致性，这是支付测试的底线。
• • 不足： 缺乏对 APP 客户端交互（即用户看得到的界面变化）和 中间态（Pending） 的处理描述。支付测试最怕的不是“成功”或“失败”，而是“不知道成没成功”。
• 补充遗漏点：

1. 1. 主动轮询逻辑： 当支付结果因网络切换或进程杀掉没能实时推送到 APP 时，用户重新打开 APP，前端是否会自动触发一个“查询请求”去后端同步状态？还是让用户在那里傻等？
   2. 重复下单/支付防护： 在弱网切换瞬间，用户如果因为界面没反应而快速多次点击“支付”按钮，APP 是否有防抖处理？后端是否能保证只有一个支付单生效（幂等性）？
   3. 逆向流程： 如果用户在微信支付界面付完钱，杀掉 APP 再回来，APP 应该直接展示“支付成功”并进入后续流程，而不是让用户停留在收银台。
   4. 超时机制： 支付中途断网，APP 应该在多久后提示“支付结果确认中”或“网络异常，请稍后在订单中查看”？

今日练习：第二题

场景描述： APP 内部的“消息通知中心”。该功能负责接收：1. 系统公告（全员同步）；2. 订单物流（实时触发）；3. 营销活动（定时推送）。

挑战： 现在的需求是：当用户点击某条“订单物流”通知时，必须精准跳转到对应的“订单详情”页。请问从测试的角度，你会设计哪些用例来确保这个“精准跳转”在各种复杂情况下都不会失效？

回答：

1.点击通知后，应用冷启动，能否正常跳转。

2.用户长期未登录，token失效，点击通知后，要求用户输入信息进行登录，用户成功登录后，能否正常跳转

3.用户在当前通知跳转页的更浅/深一层的页面，点击通知后，能否正常跳转

4.用户跳转后，点击返回，能否返回到上级页面

5.若通知跳转的页面已失效，能否有正确的提示

以下是针对第二题的评价与补充：

第二题：评价与补充

• 评价： * 优点： 覆盖了冷热启动切换、登录态拦截和路径回溯（返回键逻辑），这些是跳转测试的核心点。
• • 不足： 稍微漏掉了一些关于数据准确性和多通知覆盖的细节。
• 补充遗漏点：

1. 1. 参数传递的准确性： 点击订单 A 的通知，是否误跳到了订单 B？（特别是在连续收到多条物流通知时）。
   2. 多重通知堆栈： 状态栏有多条通知时，依次点击，跳转逻辑是否会混乱？
   3. 覆盖安装/版本兼容： 旧版本 APP 收到新格式的通知跳转协议（Schema），是否会造成崩溃或跳转失败？
   4. 页面重入逻辑： 如果当前已经停留在订单详情页（订单 A），再次点击订单 A 的通知，是刷新当前页，还是又盖了一层一模一样的页面？

今日练习：第三题

场景描述： APP 的**“个人中心”头像上传**功能。支持用户通过“拍照”或“从相册选择”来更换头像。上传前有图片裁剪界面。

挑战： 作为测试，请跳出“图片能成功上传”这个基本点，从 **APP 专项测试（如流量、性能、权限、文件处理）**的角度，给出至少 4 个深度的测试场景。

回答：

不太会

我直接为你拆解这一类问题的**“深度思维路径”**，你可以对照看看，这些角度是不是平时比较容易忽略的：

第三题：深度专项测试场景（解析）

• 场景一：存储与空间边界（文件处理）
• • 测试点： 如果手机内存空间几乎已满（例如剩余不足 1MB），尝试拍摄一张高清照片并进行裁剪上传。
  • 关注点： APP 是否会因为无法生成裁剪后的缓存文件而直接闪退（Crash） ？是否有友好的空间不足提示？
• 场景二：权限与隐私（系统权限）
• • 测试点： 用户在点击上传时，先授权权限，但在裁剪过程中，手动切换到系统设置里关闭相册权限，再回到 APP 点击完成。
  • 关注点： APP 是否能处理这种动态权限丢失，还是会卡死在上传进度条？
• 场景三：流量与性能（网络/资源）
• • 测试点： 在 3G/弱网 环境下上传一张 10MB 以上的高清原图。
  • 关注点： 1. 超时控制： 是否有进度提示？如果上传 30 秒没成功，是无限等待还是报错？ 2. 流量消耗： APP 是否在本地做了预压缩？（如果不压缩直接传原图，会对用户流量和服务器带宽造成压力）。
• 场景四：图片格式的“攻击性”（安全性）
• • 测试点： 修改文件后缀名（例如将一个 txt 文档改名为 jpg），或者上传带有特殊字符文件名的图片。
  • 关注点： 服务端和客户端是否能识别非真正的图片文件，防止恶意脚本注入。

📝 今日训练复盘笔记

1. 核心战绩评价

• 基础训练（生物识别）： 表现及格。你捕捉到了物理环境影响，但在系统机制（重试限制、数据失效同步）上还有补强空间。
• 意识训练一（支付异常）： 表现良好。稳稳守住了数据一致性（钱与状态）的底线。
• 意识训练二（消息跳转）： 表现优秀（全场最佳） 。你提出的“冷启动、Token失效、路径回溯、页面失效”四部曲非常专业，这证明你具备了处理复杂交互链路的能力。
• 意识训练三（文件上传）： 认知突破点。通过这一题，你接触到了 APP 专项测试（流量压缩、权限变更、存储边界）的深度。

2. 你的思维闪光点

• 逻辑连贯性： 你不只关注“点击能否跳转”，更关注“跳转后返回去哪”以及“登录态丢了怎么办”，这种全链路思维是中高级测试的标志。
• 异常防御意识： 在支付场景中，你第一时间想到了网络切换对交易状态的影响，具备了基本的风控意识。

3. 后续进阶建议（需要补强的“盲区”）

• 从“用户面”转向“系统面”： 练习时可以多想一步： “如果这时候系统内存满了/权限关了，底层代码会怎么报错？”
• 关注数据中间态： 除了“成功”和“失败”，要多考虑**“处理中/结果未知”**的灰度地带。
• 客户端性能优化： 像头像上传这类功能，可以多考虑流量损耗（压缩）和设备适配（高低端机稳定性）。