一提到 Agent Workflow，最容易先想到的是多步骤规划、自动拆解任务、串联工具调用和减少人工编排。 这些能力当然重要，但只要它开始执行真实测试任务，问题就会立刻从“会不会规划”变成“出了问题怎么收”。 原因很简单。多步骤测试任务通常同时具备下面几种特征： 步骤之间存在顺序依赖 执行动作会改变环境或业务状态 一次失败可能污染后续上下文 工具调用、模型决策和环境异常会交织出现 补跑和恢复如果没有边界，很容易把现场改得更乱 这意味着...
单设备稳定性测试验证的是脚本能不能跑，多设备并发稳定性测试验证的是平台能不能承受真实实验室。设备会掉线、序列号会变化、任务会抢资源、日志会互相覆盖，最后如果没有归档规范，几十台设备跑出来的结果反而比一台设备更难判断。这篇文章从稳定性测试视角展开，不把它写成工具说明书，而是把问题背景、测试位置、平台设计、命令入口、案例复盘和输出模板放在同一条链路里。读完后，应该能直接拿去设计任务、评审失败、补齐日志和提交缺陷。 一、具体问题背景：先把这类...
做 Android 系统稳定性测试时，CTS、VTS 和 Trade Federation 经常被放在“认证测试”的抽屉里，等到出货前才集中跑一轮。这个做法会错过它们对稳定性工程最有价值的部分：标准化环境、可复跑任务、可归档结果和跨设备执行模型。这篇文章从稳定性测试视角展开，不把它写成工具说明书，而是把问题背景、测试位置、平台设计、命令入口、案例复盘和输出模板放在同一条链路里。读完后，应该能直接拿去设计任务、评审失败、补齐日志和提交缺陷...
专项稳定性测试负责把某个系统能力压深。相机、音视频、通信、定位、蓝牙和 Wi-Fi 都是 Android 设备上高频、跨层、容易受打断影响的能力。整机测试可能碰到它们，但碰得不够深；业务遍历可能使用它们，但不一定覆盖模块边界。 这一篇讲专项怎么拆。案例是一台面向海外市场的手机，近期改动涉及相机 HAL、蓝牙回连、Wi-Fi 漫游和定位权限策略。 一、专项从能力链路开始专项不是按应用拆，而是按能力链路拆。相机链路包括 App、Camera...
在 AI 测试平台里，Function Calling 很容易被误解成一个“把自然语言转成工具调用”的轻量能力。 如果只是做 Demo，这么理解问题不大。但只要它进入测试工具，要求就会立刻变化： 输入不能只是一段模糊提示词，而要变成结构化任务上下文 输出不能只看模型有没有“说对”，而要看参数是否可执行、可审计、可恢复 调用失败不能简单重试，而要先判断失败类型和恢复边界 工具执行结果不能只回给模型，还要沉淀进证据链和结果链 也就是说，测试...
极限场景测试关注 Android 设备在边界条件下的恢复能力。低电量、弱网、存储满、冷热启动、频繁插拔、时间跳变、权限变化，这些场景不一定天天发生，但一旦处理不好，用户会看到黑屏、数据丢失、无法联网、应用反复崩溃或设备需要重启。 这一篇把极限场景拆成可执行的测试设计。案例是一台手持扫码终端，用于仓储现场，要求在低电、弱网、满存储和频繁 USB 扫码枪插拔下保持业务可恢复。 一、极限不是破坏设备极限场景不是为了把设备弄坏，而是模拟用户现场...
高负载稳定性测试不是性能跑分。它关心的是 Android 系统在资源余量变小时是否还能保持核心能力：界面不长时间卡死，服务不崩，温度可控，网络和存储错误可恢复，用户关键路径还能完成。 这一篇讲 CPU、内存、I/O、网络和温升如何组合。案例是一台中端手机，用户在视频通话时后台下载大文件，同时相册同步、定位和蓝牙耳机都在工作。 一、高负载要组合资源真实高负载很少只有 CPU。视频通话会吃 CPU、GPU、相机、音频、网络和温度；...
长稳测试经常被简单理解为“设备连续跑很多小时”。这种理解太粗。长稳真正要看的是时间带来的变化：内存是否缓慢增长，线程和句柄是否累积，温度是否漂移，周期任务是否堆积，日志是否膨胀，系统服务是否在多次休眠唤醒后进入坏状态。 这一篇讨论 Android 长稳怎么设计时长、压力、场景和判断标准。案例是一台智能电视，要求连续播放、投屏、待机唤醒和应用切换 72 小时。 一、长稳测的是趋势长稳不是把短测拉长。短测关注功能是否马上坏，长稳关注系统状态...
业务遍历测试比 Monkey 更接近真实用户，因为它带着目标前进：打开应用、完成路径、校验状态、处理打断、恢复到可继续使用的界面。它不是单纯的 UI 自动化回归，也不是为了证明按钮能点，而是把高频用户路径放进稳定性周期里反复运行，观察状态是否会在多轮、多设备、多打断后变坏。 这一篇重点讲业务遍历如何设计。案例采用一款出行 App：登录后搜索目的地、开始导航、后台播放语音、接电话、切换网络、结束行程并查看历史记录。 一、业务遍历关注路径闭...
第十四章前两篇如果只停留在“AI 测试值不值得做”和“Midscene.js 能解决什么问题”，很容易还是概念层内容。真正能把这一章立住的，还是得回到一个具体仓库，拆它现在已经做到了什么、没做到什么、下一步该优先补什么。 这篇就只看一个项目： Scenix。 这次复盘不是根据宣讲材料写，也不是根据一张架构图去反推，而是直接基于本地仓库 /tmp/scenix 的内容来判断，包括： README.md docs/design.md doc...