Android稳定性-10-Android 稳定性测试矩阵：整机、专项、高负载、极限和长稳怎么分层

发表于 2026-01-20 分类于 Android稳定性本文字数： 8.6k 阅读时长 ≈ 31 分钟

测试矩阵的价值，不是把所有设备、场景、版本和测试类型排列组合。真实项目里，组合一旦失控，测试团队会被表格拖死，最后每一格都跑得很浅。矩阵分层要解决的是资源分配问题：哪些组合必须全量验证，哪些组合抽样即可，哪些组合只在风险出现时追加。

这一篇专门讲整机、专项、高负载、极限和长稳如何分层。场景仍然放在 Android 项目里：一组手机产品要同时覆盖标准版、Pro 版、不同内存档位、国内和海外区域包，以及 Wi-Fi、蜂窝、蓝牙、相机、定位等能力。

一、矩阵先按风险密度分层

矩阵不是 Excel 技巧，而是风险建模。风险密度高的组合需要更长时间和更多证据，风险密度低的组合适合抽样。比如新 SoC、新内存档位、新相机模组、新运营商配置，都比纯 UI 文案变更更值得投入稳定性资源。

常见错误是把设备型号作为第一维，把测试类型作为第二维，然后把每个格子都填满。这种矩阵看起来完整，实际没有优先级。更实用的写法是先标出主验证线，再列出差异验证线和抽样线。

二、主线设备承担版本结论

主线设备是稳定性结论的基准。它通常选择销量最高、硬件最典型、日志能力最完整的一到两种配置。整机随机、业务遍历、长稳、高负载和关键专项都应该在主线设备上完整执行。

主线设备不等于最高配。很多系统问题在低内存或低速存储上更容易出现。如果项目有 6GB 和 12GB 两档内存，主线至少要包含低内存档。否则测试结论会天然偏乐观。

三、差异设备验证硬件和区域差别

差异设备用于回答“这项变化是否只影响某些配置”。相机模组不同，就增加相机专项；射频方案不同，就增加蜂窝、Wi-Fi 和蓝牙；区域包不同，就增加语言、时区、运营商、权限默认值和预装应用路径。

差异验证不一定复制主线全量任务。它更像有重点的探针，把硬件和配置差异引入可能受影响的测试块。这样矩阵能覆盖风险，又不会把团队拖进无意义的全排列。

四、整机层看系统生存能力

整机层关注的是设备在复杂输入下是否还能持续工作。它适合放 Monkey、轻业务遍历、应用启动切换、通知、设置、媒体、网络和前后台混跑。整机层不追求每条业务路径精确，而是让系统服务、进程管理、输入、窗口、包管理和资源回收被不断扰动。

整机层的异常包括重启、Watchdog、system_server crash、Native crash、黑屏、输入无响应、持续高温、系统存储异常。它给版本提供底盘判断：系统是不是经得住一般扰动。

五、专项层盯模块边界

专项层不适合写得太泛。相机专项要覆盖打开关闭、前后摄切换、拍照录像、权限回收、低电量、来电中断、横竖屏和后台恢复；蓝牙专项要覆盖配对、回连、通话、媒体、通讯录同步和多设备切换。

专项层的目标是把模块边界压到足够深。整机层可能随机碰到一次相机，专项层要把相机放在不同状态、不同打断和不同资源压力下反复验证。

六、高负载层评估系统余量

高负载层不是简单把 CPU 打满。Android 的真实高负载经常来自多资源叠加：后台下载、前台视频、相机预览、定位、蓝牙、I/O 写入、温升降频。矩阵里要明确每个高负载组合的主压力和伴随压力。

高负载层适合主线设备和少量低配设备。它的结论不是“性能好不好”，而是当系统余量被吃掉时，核心能力是否还能恢复，是否出现不可接受的卡死、重启或数据损坏。

七、极限层验证边界恢复

极限层覆盖低电量、弱网、满存储、时钟跳变、频繁插拔、权限变化、账户退出、SIM 热插拔、蓝牙距离变化、Wi-Fi AP 切换等场景。它和高负载不同，高负载强调资源压力，极限层强调条件异常和恢复路径。

极限层最容易被误解成破坏性测试。其实它更接近用户现场：电量会低，网络会抖，存储会满，外设会被拔掉。矩阵里要规定恢复标准，例如网络恢复后多久重新连接，存储释放后服务是否继续工作。

八、长稳层看时间相关问题

长稳层用于发现资源泄漏、句柄泄漏、线程增长、温度漂移、周期性任务堆积、日志膨胀和低频重启。它需要稳定环境和固定采样，不适合在基础功能还大量失败时启动。

长稳矩阵要写明时长、业务组合、采样周期和中断处理。24 小时、48 小时、72 小时的意义不同，不能简单用时长越长越好来决策。

九、矩阵里的时间预算

时间预算要按层分配。早期版本把 60% 时间给整机和关键专项，20% 给业务遍历，20% 给问题复跑；冻结前把更多时间给长稳、高负载和极限恢复。矩阵如果不体现阶段，就会每个版本都跑同一套任务。

时间预算还要包含分析时间。跑 48 小时不是结束，拉日志、初筛、归类、建单和复跑都需要时间。矩阵只写执行时长，会低估项目成本。

十、完整案例：矩阵示例

下面是一张可直接用于项目评审的分层矩阵。它把全量、重点和抽样区分开，避免把所有组合都写成同等权重。

层级	主线设备	差异设备	执行时长	主要输出
整机	全量 Monkey 与轻业务	抽样 4 小时	8 到 12 小时	系统异常列表和日志索引
专项	相机/蓝牙/Wi-Fi/定位全量	按硬件差异选择	每项 2 到 6 小时	模块异常和复现条件
高负载	CPU+I/O+网络+媒体组合	低配设备补充	4 到 8 小时	温度、资源、恢复结果
极限	低电、弱网、满存储、插拔	区域和外设差异抽样	每类 1 到 3 小时	边界恢复记录
长稳	48 到 72 小时	关键差异 24 小时	按阶段设定	趋势图和低频异常

十一、矩阵执行命令

矩阵要能落到命令。下面是一组最小化命令，适合在每个矩阵格开始前采集基线，并在任务结束后归档。

adb shell getprop ro.product.model
adb shell getprop ro.boot.hardware.sku
adb shell getprop ro.build.fingerprint
adb shell dumpsys package com.android.systemui > evidence/pkg_systemui.txt
adb shell dumpsys meminfo > evidence/meminfo_pre.txt
adb shell dumpsys cpuinfo > evidence/cpuinfo_pre.txt
adb shell cmd thermalservice override-status 0 # 仅工程环境使用，量产验证不要伪造温控
adb bugreport evidence/pre_task.zip

十二、常见误判

误判一：矩阵越大越专业。实际矩阵过大时，每个格子都缺少深度，最后只能得到平均化的低价值结果。

误判二：高配设备通过就代表低配通过。低内存、低速存储、不同屏幕和不同射频方案会改变稳定性表现。

误判三：区域包只影响语言。区域包还可能改变权限、预装、运营商配置、后台策略、网络服务和法规开关。

误判四：专项通过就不需要整机。专项验证模块深度，整机验证系统协作，两者看的是不同风险。

十三、矩阵检查清单

是否区分主线、差异和抽样设备。
是否说明每个设备进入矩阵的原因。
是否按版本阶段调整测试层级。
是否给每个层级定义证据和异常判据。
是否保留问题复跑时间。
是否避免所有组合等权。
是否让报告能反推出未覆盖风险。

十四、输出物模板

测试矩阵摘要
版本：<build>
阶段：<daily/beta/rc>
主线设备：<model/sku/memory/region>
差异设备：<reason list>
矩阵层级：整机/专项/高负载/极限/长稳
未覆盖项：<item>，原因 <resource/risk accepted>
阻断项：<issue id>
建议：<继续/补跑/暂停/发布限制>

执行前的基线记录

测试矩阵分层在真正开跑之前，需要先建立一份基线。基线不是形式化截图，而是把不同设备、区域包和硬件配置当时的状态固定下来：版本指纹、启动时间、账号状态、网络状态、权限状态、后台进程、外设连接、温度、电量和存储余量都要留下。后续出现某配置独有的重启、卡死或能力失效时，分析人员才能判断这是任务引入的变化，还是设备在任务开始前已经处于异常边缘。

基线记录还有一个作用，是让不同轮次可比较。比如同样是主线低内存设备加海外区域包抽样，第一轮在 38 摄氏度、Wi-Fi 满格、存储剩余 20GB 下运行，第二轮在 47 摄氏度、弱信号、存储剩余 800MB 下运行，两轮结果不能直接并排解释。稳定性结论最怕把不同条件下的数据混在一起，最后看似样本很多，实际每个样本都不可比。

执行同学可以把基线做成固定脚本，但脚本输出不能只扔在日志目录里。日报和问题单至少要引用基线摘要：设备、版本、环境、关键开关和任务入口。版本质量负责人拿到问题后，第一眼应当知道这台设备在进入任务时是否健康。

运行中的心跳和哨兵

测试矩阵分层运行时间越长，越需要心跳。心跳不是简单打印“脚本还活着”，而是周期性确认不同设备、区域包和硬件配置仍在执行预期工作。对于主线低内存设备加海外区域包抽样，心跳可以包含前台包名、关键服务状态、网络连通性、最近一次业务动作、最近一次截图和设备在线状态。

哨兵指标用于提前发现坏趋势。覆盖深度、异常密度和差异设备命中率如果连续多个采样点朝坏方向移动，就算还没有形成最终失败，也应当在日报里标黄。很多严重问题不是突然出现的，而是先有资源斜率、恢复变慢、错误码增多、温度升高或重试次数变多。把这些早期信号记下来，问题定位会比事后翻大包快很多。

心跳还负责区分脚本失败和产品失败。脚本进程退出但设备业务仍正常，这通常是自动化问题；设备输入无响应、服务异常、日志出现系统错误，而脚本只是最后感知到失败，这就不能简单归为脚本问题。稳定性执行需要这种区分，否则真实风险会被噪声掩盖。

异常发生后的第一分钟

某配置独有的重启、卡死或能力失效刚出现后的第一分钟最宝贵。此时日志还没有被大量覆盖，系统状态也没有被人为操作改变。执行规范里应该要求先保存现场，再尝试恢复。现场保存包括截图、录屏、logcat 时间窗口、矩阵覆盖表、设备基线和任务日志、前台 Activity、关键 dumpsys、进程列表和任务控制台输出。

不要一看到异常就重启设备。重启确实能让下一轮继续跑，但也会抹掉很多状态：进程关系、窗口层级、binder 等待、音频焦点、网络连接、挂载状态都可能消失。除非设备已经完全无法连接，否则先抓证据，再恢复任务。

第一分钟还要写清人工动作。如果执行者点击了返回、插拔了外设、切了网络、接了电话，必须写进记录。否则研发看到日志时会误以为这些动作来自系统或脚本。稳定性现场的每个人工干预都可能改变因果链。

复跑策略和样本解释

复跑不是机械重复。测试矩阵分层的复跑至少分三类：同条件复跑、缩小范围复跑、交叉条件复跑。同条件复跑确认问题是否稳定；缩小范围复跑找最小触发路径；交叉条件复跑判断是否和设备、区域、外设、网络或温度相关。

如果问题只出现一次，也不能直接删除。要看它的影响面和证据强度。一次某配置独有的重启、卡死或能力失效如果涉及系统重启、数据丢失、核心能力不可恢复，就值得进入风险列表；反过来，某个轻微 UI 问题重复很多次，也未必比一次系统级异常更严重。样本解释要看影响，不只看次数。

复跑结论建议写成四种状态：已稳定复现、条件相关复现、暂未复现但证据有效、证据不足关闭。这样比简单写“复现/不复现”更适合稳定性问题，因为许多问题本来就依赖长时间、环境和状态累积。

问题单应该怎么写

测试矩阵分层发现的问题单要让版本质量负责人能直接进入分析。标题里写清现象和场景，不要只写“稳定性异常”。正文第一段说明版本、设备、任务、轮次、发生时间和用户可见影响；第二段列出复现路径或触发条件；第三段给证据索引；最后写当前恢复方式和复跑状态。

证据索引要比附件名更细。比如 bugreport.zip 太粗，应该写 bugreport.zip: SYSTEM LOG 14:32:10 附近出现关键异常，或者 traces.txt: main thread waiting binder reply。这样研发不用先花半小时找入口。

问题单也要避免过度归因。测试侧可以提出怀疑方向，例如矩阵覆盖表、设备基线和任务日志显示异常集中在某个服务，但不要在证据不足时直接写“某模块代码错误”。好的问题单给入口、给影响、给条件、给证据，让模块负责人继续收敛。

数据看板该展示什么

测试矩阵分层的数据看板不应只展示通过率。通过率适合管理视角，但稳定性分析还需要异常类型分布、设备分布、版本分布、任务分布、发生时间分布和复跑状态。特别是覆盖深度、异常密度和差异设备命中率，最好用趋势线展示，而不是只给平均值。

看板的第一屏可以放阻断问题、今日新增、长期未关闭、复跑失败和环境异常。第二屏放任务覆盖和资源趋势。第三屏放证据归档完整率。如果证据归档完整率很低，异常数量再漂亮也不值得相信。

对于多 SKU 手机项目，还建议加一个“现场相似度”字段：实验室条件和用户现场差多少。比如车载高温、海外运营商、仓库弱网、会议室蓝牙密集环境都可能让实验室结论偏离真实使用。看板能提醒团队补足这些差距。

和研发评审时的沟通方式

稳定性问题评审不要从“谁负责”开始，而要从时间线开始。把主线低内存设备加海外区域包抽样中的动作、系统状态、异常日志和用户现象按时间排出来，先让所有人看到同一条线。时间线清楚后，再讨论可能归属。

评审时测试需要坚持两件事：一是用户影响不能被技术细节稀释，二是证据边界不能被猜测扩大。比如某配置独有的重启、卡死或能力失效可能只出现一次，但如果用户需要重启才能恢复，它就是高风险；同时，如果现有日志只能说明某服务异常，就不要把根因直接推到驱动。

每次评审结束都要留下动作项：谁看哪份日志，谁补哪轮复跑，谁提供带符号栈，谁确认是否已有补丁，下一次同步时间是什么。没有动作项的评审只是在交换观点，不会推动版本风险下降。

发布决策中的表达边界

测试矩阵分层最终服务于发布决策，但测试结论要有边界。可以说“在这些设备、这些场景、这些时长内未再触发同类异常”，不要把结论扩大到所有用户、所有地区和所有外设。边界写得清楚，项目管理才能知道哪些风险已覆盖，哪些风险只是接受。

如果仍有未关闭问题，报告要写影响路径、触发条件、规避方式、修复计划和灰度建议。比如某配置独有的重启、卡死或能力失效只在某个低频组合出现，且有明确规避，可以进入有条件发布；如果它影响核心路径且无恢复手段，就应当暂停。稳定性测试不是替项目做商业决定，而是把技术风险讲清楚。

发布会上的表达要避免两种极端：一种是只报喜，另一种是把所有观察项都说成阻断。成熟做法是把问题分成阻断、需签字接受、继续观察和已关闭四类，并给出证据链接。

现场经验：小问题如何变成大事故

很多多 SKU 手机事故最初都像小问题。一次偶发日志写入失败、一次音频焦点没有恢复、一次网络切换后重试慢、一次进程被杀后页面空白，如果只看单次，都容易被认为影响有限。但稳定性测试要问的是：它在长时间、多设备、多人使用和边界条件下会不会放大。

例如主线低内存设备加海外区域包抽样中某个后台任务失败，如果用户马上重试能恢复，风险不高；如果失败会堆积队列、占满存储、拖慢启动，几小时后就可能演变成系统级问题。稳定性分析要关心这种链式后果。

所以报告里最好写“后续影响”。异常发生后系统是否自动恢复，是否留下脏状态，是否影响下一轮任务，是否需要清数据或重启，是否会让日志和存储继续膨胀。这些内容比单纯描述弹窗更有决策价值。

把经验固化成资产

每轮测试矩阵分层结束后，都应该沉淀三类资产。第一类是可复用脚本，包括任务启动、采样、异常抓取和清理。第二类是案例库，包括某配置独有的重启、卡死或能力失效的时间线、证据和根因。第三类是规则库，包括准入条件、停止条件、阈值和误判处理。

资产沉淀的关键是可检索。问题标题、模块、设备、版本、关键词、日志特征和修复提交都要能被搜索。下一次出现相似日志时，测试和研发可以迅速查到历史案例，而不是重新走一遍弯路。

稳定性体系不是靠某一次大测试建立的，而是靠每个版本把经验留下来。矩阵库和设备选择规则如果能持续积累，团队会越来越快地区分新问题、已知问题、环境问题和可接受风险。

资源不足时怎么取舍

测试矩阵分层经常会遇到资源不足：设备不够、实验室窗口不够、研发希望尽快出结论、项目又希望覆盖所有风险。这个时候不能平均砍任务，而要按影响路径取舍。优先保留主线设备的整机、关键专项和长稳，其次保留能暴露系统级异常的组合，最后才考虑低风险抽样。

取舍要写进报告，而不是在执行过程中口头决定。比如取消了海外低内存设备的 Wi-Fi 漫游抽样，就要说明取消原因、影响风险和后续补偿方式。否则最终结论会显得很完整，实际缺了一块关键覆盖。

资源取舍还要考虑问题密度。如果某一类任务连续发现严重问题，就应暂停同类扩展覆盖，把资源转向复跑和归因。继续铺更多样本只会制造重复问题单。

环境陷阱和规避方式

测试矩阵分层最容易被环境影响。区域配置、供电、温度、账号、服务端、外设、SIM 卡、AP、蓝牙对端都会改变结果。环境问题不能简单算失败，也不能完全忽略，必须单独标记并判断它是否接近用户现场。

规避方式是给环境也建立版本。AP 型号和固件、SIM 卡运营商、蓝牙耳机版本、测试账号状态、服务端环境、供电方式都要可追溯。一次同一专项失败如果只在某个 AP 固件下出现，它仍然可能是真问题，只是触发条件更窄。

实验室还要避免多个任务互相污染。高吞吐下载会影响弱网测试，蓝牙密集扫描会影响回连，日志服务器慢会拖垮归档脚本。环境共享时要有排班和隔离。

如何把一次失败拆成时间线

稳定性分析最有用的中间产物是时间线。时间线从任务开始写起，包含环境状态、脚本动作、系统日志、用户现象、自动恢复、人工干预和证据文件。对于矩阵格失败，时间线能把表面现象和底层证据放在一起。

写时间线时不要只摘异常行。异常前的 30 秒到 5 分钟往往更重要：是否刚切网络，是否刚进入后台，是否刚触发温控，是否刚完成大量 I/O，是否刚接入外设。很多根因藏在异常之前。

时间线也是跨团队沟通的共同语言。应用、Framework、HAL、驱动、测试和项目管理可以围绕同一条线讨论，而不是各自拿着不同日志争论。

验收口径要避免含混

测试矩阵分层的验收口径要写得足够具体。不能只写“无严重问题”，而要写哪些问题算阻断、哪些算重大、哪些进入观察。核心设备组合下的系统重启这类现象如果影响核心路径、需要重启、造成数据丢失或安全风险，应直接进入阻断。

验收口径还要包含恢复能力。有些边界条件下短暂失败可以接受，但必须自动恢复，并且恢复时间、用户提示和数据完整性满足要求。没有恢复定义，开发和测试会对同一个现象给出完全不同的判断。

口径最好在测试前评审，而不是报告时临时解释。测试前确认口径，执行中按口径分类，报告时才不会因为标准变化产生争议。

从个人经验到团队流程

早期项目里，测试矩阵分层往往依赖少数有经验的人。熟悉的人知道该看哪个日志、遇到差异设备独有异常该抓什么证据、哪些现象可能是环境问题。但这种经验如果不固化，换人或多项目并行时很快失效。

团队流程可以从三个小动作开始：固定命令模板、固定目录结构、固定问题单字段。不要一开始就追求大平台，先让每个人产出的证据长得一样。证据一致后，自动化归档、报表和趋势分析才有基础。

当流程跑顺后，再把历史问题沉淀为规则。例如某类日志关键字出现时自动补抓 dumpsys，某类任务失败时自动暂停同设备后续任务，某类环境异常自动从有效时长中扣除。

复盘时要问的五个问题

每轮测试矩阵分层结束后，复盘不要只问发现了几个问题。更值得问五个问题：第一，哪些风险被验证充分；第二，哪些风险没有覆盖；第三，哪些异常证据不足；第四，哪些任务性价比低；第五，下一轮应该调整什么。

如果一次测试发现很多配置相关问题，但大部分无法复现、证据缺失、归类混乱，那么复盘重点不是庆祝发现数量，而是修执行体系。稳定性测试的成熟度体现在下一轮能不能更快、更准、更少噪声。

复盘还应把关闭的问题拿出来看。关闭原因是修复、规避、误报、环境问题还是风险接受？不同关闭原因代表不同质量含义。把它们混在一起，会让版本风险被低估。

一份更细的现场记录示例

下面是测试矩阵分层现场记录可以达到的细度：10:00 设备刷入版本并校验指纹；10:12 完成账号和网络准备；10:20 采集基线；10:30 启动主线设备的整机、关键专项和长稳；11:05 第一次出现轻微错误码但自动恢复；11:40 触发核心设备组合下的系统重启；11:41 自动抓取矩阵格失败；11:45 人工确认用户现象；12:10 同条件复跑开始。

这样的记录看起来麻烦，但它能节省后续大量沟通成本。研发不用追问“当时在干什么”，测试不用反复回忆，项目也能判断任务中断时间是否计入有效时长。

现场记录还可以帮助识别非产品问题。如果每次失败都发生在日志上传、脚本重启或服务端维护附近，就要先清理环境变量，再判断产品风险。

和后续章节的衔接

测试矩阵分层不是孤立能力。它需要和问题分析、日志分析、报告系统、设备管理和准入评审连接起来。前面执行得再好，如果后面没有问题跟踪和趋势复盘，稳定性风险仍然会在版本末期反复出现。

建议把本文中的任务、命令、表格和模板都接入统一编号。任务编号进入日志目录，日志目录进入问题单，问题单进入日报和准入报告。链路一旦打通，稳定性测试就不再是单次活动，而是版本质量管理的一部分。

对于长期项目，最有价值的不是某一轮结论，而是跨版本对比。配置相关问题是否减少，同一专项失败是否还在同类设备出现，差异设备独有异常是否有新变体，这些问题只有连续数据才能回答。

验收示例：通过不是一句话

矩阵验收可以写得很短，也可以写得足够有用。短句通常是“本轮通过”，但这句话对后续复盘帮助有限。更好的写法是说明覆盖了哪些主线设备、差异设备、抽样设备，触发过哪些轻微异常，哪些异常完成复跑，哪些风险仍然保留。

例如可以写：“本轮覆盖 6 台设备、3 类任务、2 个区域配置，未发生系统重启、Watchdog 和核心路径不可恢复；发现 2 个配置相关异常，其中 1 个已由补丁验证关闭，1 个因证据不足进入下一轮观察。”这样的表述既能给项目结论，也保留了边界。

验收示例还要写未覆盖项。未覆盖不是失败，但必须透明。资源不足、环境缺失、外设未到、服务端不可用都可以成为未覆盖原因，只要报告里说明影响和补偿计划。

日志索引要能被别人复查

日志索引的最小要求，是别人不问作者也能找到入口。目录名包含版本、设备、任务和时间；文件名包含日志类型；索引文件写明异常时间、关键字、相关进程和设备选择理由。如果只有一堆压缩包，后续复盘会非常痛苦。

建议每个任务目录放一个 index.md。第一页写任务摘要，第二页列证据文件，第三页列异常时间点。异常时间点不要只写本地时间，还要写设备时间和日志时间，避免电脑时区、设备时区、脚本时间不一致造成误读。

对于跨天任务，日志切分更重要。长时间 logcat、周期 dumpsys、截图、录屏和 bugreport 要按时间段归档。问题单引用证据时，直接指向某个时间段，而不是让研发下载几十 GB 文件慢慢找。

为什么要保留失败样本

矩阵失败样本即使暂时无法复现，也有保留价值。它可能包含未来同类问题的第一条线索。很多系统问题第一次出现时证据不完整，第二次出现时如果能对照历史样本，就能更快发现共同条件。

保留失败样本不等于把所有问题都长期挂起。可以给样本设置状态：待复跑、证据不足、历史参考、已合并到主问题。这样问题列表不会膨胀，案例库也不会丢失。

失败样本还可以反过来改进测试。某次配置相关异常如果发现日志缺少关键 dumpsys，下一轮就把该 dumpsys 加入自动抓取；如果发现环境条件没记录，下一轮就把环境字段加入基线。

面向新人的执行说明

如果一个新人接手矩阵，他需要的不是厚厚的理论文档，而是一张能照着执行的说明：准备哪些设备，检查哪些环境，运行哪些命令，看到什么现象停下来，异常后先抓什么，最后把文件放到哪里。

执行说明要避免隐含知识。例如“确认网络正常”太含糊，应写成“连接指定 AP，ping 网关 20 次，记录丢包和平均延迟”；“抓日志”也太含糊，应写清 logcat buffer、bugreport、dumpsys 和专项日志。

新人能稳定执行，说明流程已经足够工程化。只有资深同学才能跑通的稳定性测试，很难支撑多版本、多设备和长周期交付。

最后一次人工复核

在报告发出前，建议做一次人工复核。复核内容包括：front matter 或文档元信息是否正确，任务数据是否和日志目录一致，异常数量是否和问题单一致，设备选择理由是否能追到原始证据，禁用或不推荐的结论表述是否被清理。

人工复核不是重复分析，而是检查报告有没有给决策者造成误导。比如把中断时间算入有效时长，把环境失败算成通过，把未复跑问题写成已关闭，都会直接影响发布判断。

复核还要看文字是否过度模板化。稳定性报告和文章一样，应该围绕本轮真实风险展开。结构可以固定，内容不能空泛。每个结论都要让读者知道它来自哪次任务、哪个样本和哪份证据。

结论前的针对性复核

矩阵最后还要做一次反向阅读：如果我是项目负责人，只看这张表，能不能知道哪些设备没有跑、为什么没有跑、遗漏风险由谁接受。矩阵不是为了证明测试团队忙过，而是为了让版本风险透明。如果表里每一格都写“通过”，但看不出主线和抽样的差别，这张矩阵仍然不合格。反向阅读能逼着作者把设备选择、任务深度、样本数量和风险接受写清楚。

十五、小结

矩阵分层的核心，是让有限资源压到高风险处。它不追求把表格填满，而是追求每一格都有清楚的验证意图和证据出口。