平板压力测试·长测查漏神器

给消费电子测试、质量、产品和项目人员用。把通常需要分别完成的“冻结版本、拆场景、分样机、对日志、写结论”收为两步：提交自己的材料，核对生成的计划或报告。这里的步数是工作组织方式，不是效率实测承诺。

产出是可执行的测试用例表、样机与场景分配、日志段表、异常和缺项清单、结束复验清单；有授权实测记录时再出证据检查报告。没有实测数据，只交付待填骨架，所有结果记“未测”。支持 WorkBuddy、Codex、Claude Code，不依赖专属接口或第三方库。

1. 先定任务与输入边界

• 编计划：读产品能力、软硬件版本、变更点、样机和资源限制，按 用例方法 裁剪。已知内容直接用；缺项标明，仍可先出草稿。
• 查报告：收批准计划和原始记录副本，再按 数据口径 整理为 JSON，运行脚本；不把用户口述“跑完了”当有效监控证据。
• 用户给 Markdown、粘贴文本或 CSV 可先整理。PDF、Excel、Word 由宿主已有读取能力提取；读不到、图片未识别、公式无缓存或表型不明时，请用户提供文本/UTF-8 CSV 或人工确认值。脚本只接收明确 JSON，不会读取 Office、OCR 或重算公式。

一次补问关键缺项：匿名样机与硬件/固件版本；计划覆盖范围与每台每场景的连续时长、累计时长和循环次数；异常类型的容忍次数及批准依据；中断/换版后如何重测；供电、环境、温度停止规则；可写入/可清除数据范围。只问本任务确实缺的。

没有异常容忍口径或换版规则，停止生成最终通过判定，先列问题和可做的准备工作。没有停止规则或清除授权，不给出可直接执行的危险/破坏性操作；可继续出标“待批准”的计划。用户说“先出”也不能把空缺补成零容忍、默认继续跑或最终通过。

2. 冻结版本和测试场景

1. 为每台样机建立匿名号；冻结硬件、固件、资料、测试工具与配置版本、负载素材校验值。记录电源、环境、剩余空间和初始基础功能。检查工具确实在跑且有持续监控记录后才计时。
2. 按准备、重启/恢复/唤醒、随机/定向事件、存储/应用、媒体/通信/热状态、收口复验六组出用例。详细前置、动作、判断依据和记录项见 用例方法。
3. 每条用例必须带：匿名对象、软硬件/资料版本、条目标识、前置与环境、动作、判断依据、实际结果、结论、证据号、执行岗位和时间。计划额外带必测/选测、连续/累计时长、循环次数及停止动作。
4. 分配样机与时段时，标出并发资源冲突；存储写入、摄像文件、无线吞吐与温度监控需各自有记录。音视频标题、步骤和总时长不一致时列冲突，不能默取较短值；脚本不理解自然语言冲突，宿主必须核对。

完整版按本轮批准矩阵完成。快速版只做工具试运行和短程筛查，也保留停止保全及结束复验，不宣称获得长测通过。选测被产品声明、变更或客户要求触发后转为必测；有能力但条件缺失记“阻塞”；信息不足记“待确认”；明确无能力且有依据才记“不适用”，不把它塞进通过样本。

3. 连续监控、异常保全

记录每个运行段的开始/结束（含时区）、固件、负载配置、工具存活证据及中断区间。工具退出、监控失联后没有负载存活证据的时间不计入有效时长；若只知道整段曾退出而不知道退出点，整段暂不计，要求补证据。

异常先按批准安全规则停下并保全：首次时间/轮次、症状、日志副本、最后监控、供电和环境、恢复动作。不要重置后只留下最终成功，也不要自动忽略崩溃继续跑。出现异常发热、异味、鼓胀等情形按产品安全流程停止并交由具备资质的人员处理，不指导拆电池或强行复位。温度线、允许错误数均按产品规格与批准计划，不能继承旧表。

换固件建新目标和新测试段，保留旧段和换版原因；工具恢复新建 run。异常原因不明时先记录，不把猜测写成根因。随机事件记录种子、范围、频率和工具配置；同种子不等于不同设备/固件的运行结果必然一致。Android 工具事实见 一手来源，本技能不安装或调用设备工具。

4. 复算记录与收口

先确认 Python 3 可用：python3 --version；Windows 按环境选 python 或 py -3，后续始终用同一解释器。无解释器时仍交付计划和待填表，明确“未完成脚本核算”，不手算充作校验。

python3 -I "<技能目录>/scripts/stress_audit.py" --selftest
python3 -I "<技能目录>/scripts/stress_audit.py" --input "<任务目录>/records.json" --output "<任务目录>/压力测试检查.md"

输入文件旁放授权证据副本；脚本只读取输入所在目录及其子目录中的证据，不向外找日志。输出须指定尚不存在的文件，保留原文件。运行失败退出码 2 表示输入/输出阻塞；退出码 0 仅代表报告生成成功，不代表测试通过。缺文件、坏 JSON、未知状态或坏时间不得填零跳过。

脚本按样机、版本、场景分别算区间并集，扣除中断，同一个 run 内才合并连续片段。跨 run、跨样机、跨固件不拼连续时长；并发场景也不相加当整机连续时长。循环次数另列，不能折算小时。输入和可读证据的 SHA-256 用于副本追溯，哈希一致不证明日志真实或完整。

交付报告按以下顺序写：

1. 已知输入、批准依据、假设和缺项，标清“计划草稿/快速筛查/完整版记录”。
2. 原样引用脚本结论；脚本无疑点也仅表示可进入人工证据评审，人工还须核实原日志内容、负载真实性、规格和矩阵完整性。
3. 每台每版本每场景的目标与实际累计/最长连续时间、计划/实际次数、首次异常时间及轮次；异常分类型计数。
4. 用例覆盖表：通过、失败、未测、阻塞、不适用（附依据），排除项、中断及版本变化说明。未测/阻塞不算完成；失败按批准口径处理，不能用“总时长够”覆盖失败。
5. 结束复验：启动、触控、充电、音视频、无线、摄像、存储完整性及本次变更功能；每项有实际结果与证据。脚本只检查复验状态和文件是否存在，不代替逐项判读。
6. 待执行项与问题单：补什么、由哪个岗位完成、复测范围与所需证据；无明确期限就写“待安排”，不编执行时间和人员。

示例与自测

从 examples/request.md 开始：完整虚构项目、埋点列表及期望时长在 examples/expected.md，按流程完成的交付见 examples/delivery.md。records.json 是故意含问题的记录；incomplete.json 演示必须补问的输入。evidence.txt 是虚构日志摘要，不代表真机验证。

不做什么

不驱动设备、不自行运行重启/恢复/擦除/写满负载；不访问内网或账号，不上传日志，不改原始记录。不设计破坏性试验、不替代电池安全、可靠性认证、量产签字或现场安全负责人。用自己的表结构重建方法，真实公司、型号、身份和客户资料不进入公开示例。

相关技能与分工

• hardware-five-gates：接收本技能的有效覆盖、证据缺口和结论，管理项目关口；本技能不重做总表。
• quality-8d-review：重大/重复失败转原因闭环；本技能保留复现条件，不代写未经验证的根因。
• spec-sheet-reviewer：核对规格与判定依据的来源，本技能不审完整规格书。
• lulu-office-diagram：需要流程图时再用，本技能默认文本表格即可。
• tablet-battery-test、tablet-wireless-test、tablet-display-test、tablet-camera-test：分别做单项能力验证，本技能引用其证据并安排并发持续负载。
• tablet-ota-test：升级路径与回退专项；本技能只处理换版后的分段与长测回归。
• testcase-tiering、issue-pool-closure、lulu-handover-pack：分别承接测试分层、问题关闭与交接，不在此重复实现。相关技能未安装时直接交付相应待办，不自动安装。

方法来源

路路有为团队成员多年消费电子产品线一线实践总结，示例均为虚构

关于路路有为

本技能由路路有为（广州路路有为人工智能科技有限责任公司）出品。我们专注把 AI 接进真实的工作和生意，每个技能发布前都经过脚本自测和实测。想按你们的流程、模板和数据定制，在 SkillHub 搜索「路路有为」进入团队主页联系我们。