AutoGLM的的部署、自动执行用例、测试工程师的要求 一、从 部署到报告 的全流程总结，把 AutoGLM 的自动化测试能力串成一条完整链路。 --- 🖥️ 1. 部署环境 · 快速体验：手机安装 AutoGLM App + Shizuku，配置云端 API Key，无需电脑。 · 本地部署：USB 连接电脑，配置 ADB、Python 环境，安装 ADB Keyboard，可接本地/云端模型。 · 通用前提：开启开发者模式、USB 调试，安卓 7.0+。 📋 2. 测试需求分析 · 用自然语言描述测试目标，无需编程。 · 套用公式：动作 + 目标对象 + 场景/条件 + 预期结果。 · 嵌入容错规则（弹窗、等待、失败重试），让需求天然具备可测试性。 ✍️ 3. 测试用例编写（自动生成） · AutoGLM 自动将自然语言解析为结构化用例： · 前置条件 · 原子操作序列（点击、输入、滑动、验证） · 内嵌断言（“验证出现‘提交成功’”） · 清理/恢复步骤 · 用户只需按模板写出清晰的意图，模型负责拆解。 ⚙️ 4. 测试执行 · 基于 “看 → 想 → 做” 循环： · 看：截取屏幕 + 布局信息 · 想：VLM 分析界面，生成下一步操作 · 做：模拟点击、滑动、输入 · 遇到弹窗、加载异常会自动闭环处理，执行长链路任务（50+ 步）。 ✅ 5. 测试结果（自动标注） · 视觉断言：将实际截图与预期描述做语义比对，自动判定 PASS / FAIL。 · 失败时自动记录： · 失败步骤编号 · 屏幕截图 · 失败原因摘要（如“预期‘账户锁定’，实际提示‘账号受限’”） · 具备 反思能力，可自动修正误报，优化后续执行。 📊 6. 测试报告 · 执行完毕后自动汇总： · 用例列表及各自状态（PASS/FAIL/ERROR） · 失败步骤详情与截图证据 · 整体通过率 · 可生成修正建议，让自然语言用例库持续进化，越测越准。 --- 一句话总结：AutoGLM 让自动化测试从“写代码”变成“说人话”，覆盖 部署→分析→生成用例→执行→判分→报告 全流程，形成一套自我优化的测试闭环。 二、要让 AutoGLM 的自动化测试真正跑得稳、看得清，每个环节都要在“可执行性”（执行顺畅、减少中断）和“可观测性”（过程透明、问题可定位）上做针对性加强。以下是各环节的关键技巧： --- 1. 部署环境 · 可执行性 · 关闭手机的自动锁屏、省电模式，屏幕设为常亮（最长超时）。 · USB调试保持稳定连接，使用优质数据线；无线ADB用固定IP，防掉线。 · 提前将相关App登录态准备好，避免中途出现登录或验证码打断流程。 · 开启“禁止权限弹窗”或预先授予所有必要权限（如悬浮窗、通知监听）。 · 可观测性 · 在开发者选项里开启指针位置和显示触摸操作，让屏幕上可以看到模拟操作的轨迹。 · 用ADB实时投屏到电脑（如scrcpy），执行时同步观看屏幕动态。 · 手机和电脑的日志都开启详细打印（例如 adb logcat 或 AutoGLM 的 debug 日志）。 --- 2. 测试需求分析 · 可执行性 · 用结构化公式写需求：动作 + 目标 + 场景/条件 + 预期结果，越具体模型越容易规划。 · 把容错规则写进需求：如“遇弹窗点关闭”、“等待超时重试一次”。 · 避免模糊词，全部换成机器可判定的量化描述（“3秒内”、“出现‘成功’二字”）。 · 可观测性 · 需求里就指定关键检查点的截图要求：“到达结算页时，请截取整屏保留”。 · 每条需求设一个唯一标识（如编号），便于在日志和报告里追溯。 · 要求模型在执行前先输出解析后的步骤清单，你可以提前审查意图是否正确。 --- 3. 测试用例编写（自动生成） · 可执行性 · 每个操作后紧跟一个可验证的断言，形成“操作-验证”对，让步骤自身就是判断点。 · 对可能发生变化的 UI，使用通用特征描述（如“右上角分享图标”）而非精确坐标或易变文本。 · 规定明确的结束条件：“完成下单且出现‘支付成功’即停止，超时5分钟则退出并标记失败”。 · 可观测性 · 为关键步骤加上中间截图指令：“点击确认后，保存当前页面截图命名为‘step3_confirmation’”。 · 用例里直接写明失败后的信息收集要求：“任何断言失败时，记录当前屏幕、预期文本和实际识别到的文本”。 · 设定过程日志粒度：“每步操作前打印当前屏幕关键元素”。 --- 4. 测试执行 · 可执行性 · 利用 AutoGLM 的自循环处理能力处理弹窗、加载延迟，不需要每条都写死异常分支。 · 对非关键步骤设置较短的最大步数（如“最多5步完成搜索”），防止死循环。 · 复杂任务拆成多个小用例顺序执行，降低单次执行的环境状态复杂度。 · 可观测性 · 开启步骤级日志：每执行一个动作就打印“动作内容 + 当前活动Activity + 截图”。 · 保留完整执行录像或每步截图序列，用于回放复盘。 · 实时监听性能指标（CPU、内存），若有泄漏可提前预警。 --- 5. 测试结果（自动标注） · 可执行性 · 用明确的布尔断言：PASS 的条件是“出现A且不出现B”，模型直接判断，减少模糊语义。 · 给断言加容忍度：“‘提交成功’字样可在2秒内延迟出现”，避免因动画导致的瞬间误判。 · 定义全局失败规则：“同一类异常出现3次，直接标为FAIL并跳出后续用例”。 · 可观测性 · 失败时输出的报告必须包含截图对比、预期值 vs 实际值的差异描述。 · 添加模型判定的置信度分数，低于阈值的标记为“可疑”而非直接PASS。 · 汇总页展示每步的验证状态，而不仅是最终结果，可一眼定位失败步骤。 --- 6. 测试报告 · 可执行性 · 自动生成可落地的修正建议，如“将预期词‘账户锁定’改为‘账号受限’即可通过”，减少人工分析时间。 · 报告里对重复失败的模式归类（如“所有支付类用例在‘确认支付’步骤失败”），直接指向共性原因。 · 可观测性 · 报告附带可交互的故障回溯：点击失败步骤直接打开对应截图和日志片段。 · 展示执行热图：哪类页面、哪类操作失败率高，一目了然。 · 输出环境快照：执行的手机型号、系统版本、App版本、网络状态，方便还原现场。 三、即便 AutoGLM 已经把环境部署好，并能自动执行测试，测试工程师的角色并没有消失，而是转向了更高价值的“设计、守护、分析和优化”工作。你需要深度参与以下几个核心环节： --- 🧭 1. 需求与场景设计（核心价值） 这是系统无法替代的，决定了“测什么”和“为什么测”。 · 业务场景翻译：将产品需求文档（PRD）里的模糊描述，转化为 AutoGLM 能执行的、结构化的自然语言测试需求。 · 测试策略制定：决定哪些用例适合让 AI 跑（冒烟、回归），哪些仍需人工探索（新功能、易用性）。 · 测试数据构造：设计并准备执行所需的账号、商品、优惠券等测试数据，确保数据状态符合用例的前置条件。 --- 👁️ 2. 用例审核与校准（质量把关） AI 自动生成的用例不一定完美，你需要做最后的“质量守门员”。 · 意图对齐：检查模型生成的步骤清单，确认它理解的需求和你一致，没有遗漏或曲解关键路径。 · 断言增强：补充 AI 容易忽略的隐性检查点。比如 AI 只检查了“支付成功”文字，你需要补上“金额计算正确”“优惠已抵扣”的验证。 · 容错规则复核：审视你写的容错描述，确保足够健壮，不会因一个无关弹窗导致整个测试中断。 --- 🔬 3. 执行过程监控与干预（守护者） 全程“无人值守”在复杂场景下仍不现实，你需要实时关注运行状态。 · 异常实时决策：当 AutoGLM 遇到它无法自行处理的异常（如人脸识别、滑块验证）而暂停并请求接管时，由你快速判断并干预。 · 卡顿/死循环监控：观察执行日志或投屏画面，如果模型在一个页面反复操作无进展，你需要手动终止并分析原因。 · 环境维护：确保手机网络、登录状态、弹窗权限等运行环境在长时间测试中保持稳定。 --- 🧐 4. 结果分析与归因（深水区工作） 自动标注只是第一步，真正的价值在于你对结果的深度分析。 · 失败用例复核：AI 标记的“FAIL”可能是误报。你需要对比截图和日志，确认是 “产品Bug”、“用例描述不准确” 还是 “模型识别错误”。 · 缺陷定位与提交：将确认的Bug，结合AI给的失败截图和步骤，整理成规范的缺陷报告，提交给开发。 · 模式发现：分析测试报告中的失败聚类（如所有支付类用例都在某一步失败），快速定位共性问题根因，而不是逐个处理。 --- 🔄 5. 用例库与模型优化（持续建设） 你的工作是让这个系统越用越聪明，形成正向循环。 · 用例修正维护：针对确认由描述歧义导致的失败，利用 AI 的“反思”建议或手动修改自然语言用例，并回归验证。 · 测试库版本管理：随着产品迭代更新用例，剔除过时场景，维护一套高质量的自然语言测试资产。 · 反馈模型效果：如果用的是云端模型，你积累的“模型识别不准”的典型案例，是反馈给模型团队优化模型的宝贵素材。 简单说，你的角色从“测试执行者”转变为“测试设计者、守护者和分析师”。工作重心从“手动重复执行”转移到“策略设计、质量把关和深度分析”上。