器材室每天闭馆前都要确认次日借还预约。值班员只需知道预约列表有没有正常刷新、哪几件物品需要提前准备。团队另有一个测试版 App，准备验证网络中断后的预约重试。最后，他们想看看 Agent 能否在手机切换语言后找到同一条记录。三项任务可以共用一部专用测试机，但应分别交付值班记录、回归报告和操作轨迹，避免把脚本确实点到了按钮误判为业务已完成。
把日常点击做成可以安全停止的定时任务
先人工走一遍。打开器材 App，进入预约列表，选次日日期，等待加载结束，然后核对页头日期和列表的状态。这个任务只需要读取。准备一个仅含虚构借用者的测试账号，记录设备、应用版本和执行时区。把输出约定为日期、记录条数、完成时间和结果状态。列表为空可以是成功，显示加载失败则应保留错误，设备锁屏应记为未运行。
动作固定且界面稳定时可以从设备端脚本开始。启动目标应用后先确认当前页面，再定位按钮。能读取资源标识或无障碍标签时，用它们定位；如果界面只暴露画面，先固定方向和分辨率，再用截图校验目标区域。脚本发现界面和预期不同就保存脱敏截图并退出。不要为了一次偶发找不到按钮而在同一区域连续点击，因为后续页面可能把同一位置用作提交按钮。
把定时交给已获准的调度环境，给单次运行设截止时间，并在启动前检查前一轮是否还在运行。时间跨过午夜时，要用器材室的业务时区重新计算次日日期。测试设备休眠、短时断网和列表更新三种情况。报告里同时记录计划时间和实际开始时间，这样值班员可以判断是调度未触发还是脚本开始后失败。若设备要求人工解锁，把这一条件写进交接说明，等待值班员处理。
在真机上验收预约重试
为回归测试单独准备安装包、测试账号和可重置的样例。使用 Appium 时先核对 Appium 与 UiAutomator2 驱动的版本要求，准备对应的 Android SDK 和平台工具。获准开启 USB 调试后，在设备上确认连接授权，再从主机核对设备序列号。并行连接多台设备时，在会话中明确指定设备，避免把新构建装到另一台手机上。驱动的安装和会话设置以 Appium 官方仓库文档为准。
先用测试版本复现一个完整的成功路径。给编号为 KIT-07 的虚构设备创建预约，检查确认页显示的时段和测试后台中的记录。然后恢复样例状态，模拟提交过程中网络中断。分别验证服务器已收到但客户端没有拿到响应，以及服务器确实未收到请求两种情况。恢复网络后重试，核对有效预约只有一条，时段没有被意外改写，用户也能在列表里看到最终结果。测试结束后只清理由本轮生成的样例。
写脚本时把固定等待改成可观察的条件，例如等待加载标志消失且目标行可读。把日期、器材编号和预期状态放进测试数据。生成脚本的能力可以帮忙整理定位器和断言，仍需在真机确认它连接了正确的构建与账号。给失败报告附上构建号、系统版本、复现步骤、页面反馈和获准查看的后台证据。若手动执行也无法复现预期，先判断是环境问题还是需求理解有偏差，再决定是否修改脚本。
让 Agent 在界面变化后找到同一条预约
把目标限定为在测试版器材 App 内读取次日的 KIT-07 记录，返回预约状态与脱敏截图。控制器只允许打开预约列表、切换日期、滚动和查看详情，最多执行八步。先读取当前包名、活动页面和可用控件，再决定下一步。操作完成后重新读取画面和控件，确认详情页的器材编号与预约日期都正确。发现两个标题相同的候选时，核对编号与所属区域，仍有歧义就把候选写入结果，交给值班员选择。
对经常变更布局的页面，优先用控件标识；绘制在画布上的按钮可以通过截图辅助定位。模型提出的坐标要经过执行器校验，落点必须在当前画面中属于允许点击的区域。点击之前如果画面旋转、系统键盘弹出或通知遮住目标，要重新观察。遇到权限申请、外部浏览器、系统设置或账号切换界面时结束本轮，记录包名和最后一次成功动作。这样故障可以在测试机重现，也能判断是识别错了还是操作跑出了指定范围。
在中英文、深浅主题和两种字号下分别执行同一任务。验收表记录目标控件、动作依据、设备反馈和最终业务状态。比如英文页面里 Tomorrow 与日期文本同时出现，Agent 应根据已选日期和器材编号确认记录。只有画面反馈、控件身份和实际数据一致，才标为通过。如果运行需要把截图发给视觉服务，先使用只含虚构内容的设备画面，并明确哪些页面可以发送。
故障复盘和交接
某次夜间演练没有生成值班记录。检查计划时间和开始时间，发现调度已触发，但设备处于锁屏。给值班员留下设备编号与失败时刻。下一次先用人工解锁的测试设备复跑，再制造一次短时断网。断网结果应与锁屏分开记录。设备已连接却无法创建 Appium 会话时，先核对同一序列号在主机工具中是否在线，再检查驱动与服务器版本、应用包名和启动活动。能连设备但找不到元素，则保存当前界面和控件树，复查等待条件和应用实际停留的页面。
同一个失败可由不同环节造成。列表没有记录，可能确实没有预约，也可能是选错日期或后台请求失败。排查时先确认界面日期，再核对测试接口或受控后台的记录数。确认按钮被点过，也不能据此证明预约只创建了一条。把页面显示与后台有效记录分别写进报告。通过这两项交叉核对，可以将误报分给负责 UI 的同事，将重复写入交给维护预约服务的人处理。
交付前用三组故障验证停止条件
第一组给列表准备两条同名记录，只有一条的编号是 KIT-07。检查操作轨迹是否先读取编号，再进入详情。第二组故意在打开列表后切到系统设置，检查控制器是否立即退出并记录越界。第三组在等待详情时关闭测试网络，检查报告是否将结果标成未验证，并保留最后一个可观察状态。把这三组故障与正常运行用同一张验收表记录，后续升级时对照。
常见问题
自动化一定要 root 吗？
先用支持标准调试和测试接口的专用设备完成验证。若某个动作需要额外权限，检查它是否属于任务本身，并明确由谁授权。将权限缺失记成测试前提，改用受支持的测试入口或保留人工步骤。不要用一台存有真实账号和个人资料的设备验证权限边界。
怎么避免手机接着执行旧任务？
给每轮运行分配编号，并在动作前检查运行是否超时、目标包名是否匹配以及本轮是否已取消。调度重启后先读取上一轮留下的状态，再决定继续还是从头读取。涉及写入的步骤应先核对最终业务记录。若服务已接收预约，就收集确认信息，不再提交一次。
模拟器通过，真机还要测什么？
在真机复查至少一种常用屏幕规格，以及与硬件或系统状态有关的路径，例如设备锁屏、横竖屏切换和网络恢复。按团队支持的系统版本选样本。每个版本保留设备信息和构建号，方便重现差异。模拟器适合重复跑基础流程，真机报告用于证明具体设备上的表现。
选工具时先问什么？
看输入能否稳定取得、输出能否独立验证、异常能否明确停止。固定点击任务用最少的执行能力即可，原生回归需要能读取控件并生成断言的驱动，视觉 Agent 适合控件信息不足且目标会随布局变化的页面。先用一个小场景验证安装要求、连接方式和产物，再决定是否扩展。