电脑稳定性测试必须嵌入研发日常流程，在需求评审、Daily Build、Code Review三个节点硬性介入；研发需提供内核调试节点、ACPI校验码、规范超时等待及串口日志等四项可测性支持；故障定位遵循保存日志、复现验证、vmcore分析、调用栈追溯、最小用例复现五步标准动作。
电脑稳定性测试不是测试工程师关起门来跑几个压力工具就能交差的事，它必须嵌入研发日常开发节奏中，否则测出的问题要么复现不了、要么修复无从下手、要么上线前才暴露出根本来不及改。
明确测试介入研发流程的三个硬性节点
在需求评审阶段，测试必须拿到技术方案文档，重点确认硬件兼容范围、驱动依赖版本、电源管理策略是否写入设计；没有这份文档，后续所有稳定性用例都是空中楼阁。
在每日构建（Daily Build）完成后的30分钟内，稳定性测试环境必须自动拉取新镜像并启动基础压力套件（CPU满载+磁盘IO+内存分配循环），这一步不能等人工触发——【超时未执行即视为构建失败】。
在Code Review环节，测试人员需同步审查与电源状态切换、外设热插拔、异常断电恢复相关的代码变更，重点关注是否新增裸指针操作、是否绕过系统电源策略API、是否在中断上下文中调用阻塞函数。
研发提供可测性支持的四项具体要求
方法一：内核模块必须导出/sys/kernel/debug/下的运行时状态节点，例如thermal_zone、cpu_hotplug、pm_trace，且节点权限为644，禁止仅限root读取。
方法二：BIOS固件更新包需附带配套的ACPI AML校验码清单，测试端通过md5sum比对后才允许加载，避免因固件微码不匹配导致休眠唤醒失败被误判为OS问题。
方法三：驱动代码中所有超时等待逻辑必须使用msleep_interruptible()而非while循环+udelay()，否则稳定性压测中无法捕获死锁点，日志里只显示“task hung”而无堆栈。
方法四：在UEFI启动阶段启用Serial Port Console输出，并将波特率固定为115200，禁用自动协商——这是唯一能在蓝屏或卡死瞬间抓到最后一行内核打印的通道。
联合定位故障的标准化动作序列
第一步：当稳定性测试发现偶发性宕机，测试立即保存dmesg -T输出、/sys/firmware/acpi/interrupts内容、以及最后一次成功执行的stress-ng命令完整参数。
第二步：研发收到数据后，30分钟内反馈是否复现；若无法复现，必须提供相同内核配置的.config文件和build-id，由测试在相同硬件上重放构建过程。
第三步：双方共同检查kdump生成的vmcore是否完整，重点验证crashkernel=参数是否预留足够内存（建议≥512M），【低于256M时vmcore常被截断，无法解析panic上下文】。
第四步：确认vmcore可用后，研发使用crash工具加载符号表，执行bt -v查看完整调用栈，定位到最深一层非内核通用函数的调用者，该函数所在模块即为第一责任方。
第五步：测试基于该模块编写最小复现用例（如单线程反复触发PCIe设备reset），提交至研发Git仓库的test/reproduce目录下，PR描述中必须包含硬件型号、固件版本、内核commit ID三要素。
