教学模式测试规划思维导图

一、 业务流程

1.1 主流程串联

1.1.1 通路1：标准人脸识别

• 学生上点
• 自动识别
• 就绪
• 老师点【开始】
• 测试
• 查看成绩
• 老师点【下一组】

1.1.2 通路2：手动指派

• 学生上点
• 识别失败/未识别
• 老师在小程序点击姓名
• 手动搜索/选择学生
• 就绪
• 开始测试

1.1.3 通路3：小程序下发模式

• 老师提前选人下发
• 学生上点（显示名单）
• 就绪
• 开始测试

1.1.4 通路4：竞赛模式穿插

• 先进行一轮教学模式
• 结束后不退出
• 老师直接在设备上切换为“自由竞赛模式”
• 验证功能是否正常解锁（举手返回、举右手准备等）

1.1.5 通路5：成绩查看后返回

• 完成一组测试
• 老师点击【成绩】进入排行榜
• 筛选查看
• 点击“返回教学模式”
• 验证是否准确回到原测试项目界面，且点位状态是否保持“空闲”等待下一组

1.2 异常流程 - 流程中断

1.2.1 网络中断

• 准备阶段断网
  • 验证设备端倒计时是否启动
  • 小程序提示（应提示“网络连接失败，请检查”）
• 测试中断网
  • 验证设备端是否继续独立完成测试和计时
  • 成绩是否记录
  • 网络恢复后，成绩能否同步到小程序和后台
• 查看成绩时断网
  • 筛选、翻页功能是否正常
  • 报告能否打开（应提示无网络）

1.2.2 设备断电/重启

• 测试中重启
  • 重启后设备是进入首页还是教学模式
  • 如果是教学模式，是恢复中断的测试（显示剩余时间继续），还是清空状态

1.2.3 小程序进程被杀

• 测试中，老师将小程序从后台清除
  • 设备端应如何（期望：设备端不受影响，继续测试并完成）
  • 老师重新打开小程序进入教学模式后，应能看到正在进行的测试和实时成绩

1.2.4 被更高优先级打断

• 来电
  • 测试中，老师设备接到微信语音/视频通话，小程序进入后台（同“进程被杀”场景）
• 系统弹窗
  • 低电量提示、系统更新提示等覆盖在小程序上，是否影响控制指令接收

1.3 异常流程 - 流程错乱

1.3.1 快速连续点击

• 在学生状态“识别中”时，快速多次点击其头像进行“重识别”
• 在成绩页，快速多次点击【下一组】和【成绩】按钮
• 验证目标：是否发生请求重复发送、状态紊乱、界面崩溃

1.3.2 逆向操作

• 在测试倒计时3秒内，老师点击小程序的【结束测试】（如果有）或设备端的返回手势（应无效）
• 下发名单后，在学生未上点前，老师修改了下发的名单（如更换人员）
  • 验证已上点但未就绪的学生状态如何处理

1.3.3 多端冲突操作

• 老师A小程序下发名单 -> 老师B小程序尝试对同一小站下发名单 -> 验证互斥提示
• 老师小程序点击【开始】的瞬间，学生在设备端举右手准备 -> 验证最终控制权归属（应归属小程序）

二、 功能点

2.1 可用 - 针对已提及功能

• “点击头像重识别”
  • 重识别后，是否重新触发1秒的“识别中”提示
  • 重识别时，该点位成绩是否清零
• “点击姓名手动修改”
  • 修改时，输入框是否支持粘贴
  • 修改为“游客”后，成绩归属是否为匿名
  • 修改后，设备端显示是否立即更新
• “投屏”功能
  • 投屏时，设备端倒计时暂停 -> 那小程序端的顶部项目计时是否同步暂停
  • 成绩页面投屏，报告内容是否完整
  • 关闭投屏后，计时/界面恢复是否准确

2.2