Quote
你无法证明系统没有 bug，但通过测试可以发现 bug。
测试说到底就一件事——找出系统哪里不对。不同的场景用不同的方法，有些是贯穿一切的底层思维，有些是拿来就用的具体工具。
一、证伪法——测试的底层思维
什么是证伪法？
定义：假设被测设备/系统功能是正常的，然后通过测试逐步去发现它不正确的地方，从而证伪”系统正常”这个假设。
这个方法源自卡尔·波普尔（Karl Popper）的科学哲学——证伪主义（Falsificationism）。科学理论不能被证实，只能被证伪。
证伪法与反证法的区别
| 方法 | 归属 | 本质 | 示例 |
|---|---|---|---|
| 反证法 | 数学逻辑 | 假设命题为假 → 推导出矛盾 → 证明原命题为真 | 证明 √2 是无理数 |
| 证伪法 | 科学哲学/测试 | 假设系统正常 → 通过测试发现异常 → 证伪假设 | 电脑黑屏排查 |
证伪法在测试中的具体体现
1. 负向测试（Negative Testing）
- 故意输入无效/异常数据，验证系统能否正确处理
- 例：输入框测试中，输入超长字符、特殊字符、空值
- 核心：不验证”正常能不能用”，验证”异常会不会崩”
2. 探索性测试（Exploratory Testing）
- 不预设完整测试用例，边学习边测试，逐步深入
- 例：拿到一个新设备，先试试基本功能，发现问题后深入排查
- 核心：逐步缩小范围，定位根因
3. 失效测试（Failure Testing）
- 刻意制造失效条件，观察系统的失效模式
- 例：给某接口持续输入非法数据，观察程序是否会优雅退出还是直接崩溃
- 核心：不追求复现真实故障，而是验证系统面对异常时的”容错能力”
-
💡 关于”故意让系统出事故”的系统化方法，详见故障注入——第一章侧重”证伪思维”，方法 7 侧重”操作落地”
实战示例：排查电脑无法开机
理论说完了，看一个具体例子。应用证伪法——假设”电脑硬件是正常的”，逐步证伪：
- 假设电源正常 → 拔掉电源再插上，看指示灯 → 灯不亮 → 证伪，电源可能有问题
- 假设电源线正常 → 换一根电源线 → 亮了 → 证伪成功，原电源线坏了
如果没亮：
- 假设电源适配器正常 → 用万用表测电压 → 电压异常 → 证伪，适配器坏了
这种”假设→测试→证伪→缩小范围”的循环，就是证伪法的核心。
二、测试的基石：参照标准（SPEC）
Warning
你测完了，然后呢？——谁来告诉你”对不对”？
测试的本质是把实际结果和预期结果做对比。而这个”预期结果”，就是参照标准——业内通常叫它 SPEC（Specification，规格规范）。
没有 SPEC，测试就失去了意义。你花了一整天测完，最后不知道算通过还是失败。
SPEC 是什么？
SPEC 就是一把”尺子”，告诉你什么东西算”正常”，什么东西算”问题”。
它可以是一份正式文档，也可以是一个口头约定，但核心信息必须明确：
- 测什么（测试项）
- 怎么测（测试条件和方法）
- 什么算通过（判据/阈值）
SPEC 从哪来？
OEM 计算机测试中，SPEC 的来源通常有这几种：
| 来源 | 说明 | 例子 |
|---|---|---|
| 客户需求 | 客户给出的规格要求 | ”待机功耗不超过 xx W” |
| 行业标准 | 行业通用的标准规范 | JEDEC 内存标准、USB 规范 |
| 内部标准 | 公司内部制定的测试规范 | 老化测试标准流程 |
| 设计规格 | 产品设计方案中的目标参数 | USB 规格/TypeC 规格 |
常见的问题
实际工作中，SPEC 本身也经常出问题，而且往往比”测”本身更麻烦：
- SPEC 不完整——要求里没写清楚某个场景，测了也没法判对错
- SPEC 有歧义——“响应速度快”，多快算快？100ms 还是 1s？
- SPEC 变更——测试做到一半，客户要求改了，之前的测试可能白做了
- 没有书面 SPEC——靠口头约定，过段时间人就忘了，出了争议没法扯
所以一个好的习惯是：动手测之前，先把 SPEC 确认清楚，最好落实到文字。
SPEC 在整个流程中的位置
SPEC 不是测试开始才想的事，它贯穿始终：
- 测之前：搞清楚 SPEC，知道”什么算通过”
- 测之中：对照 SPEC 判断每个结果
- 测之后：根据 SPEC 写结论——“符合”还是”不符合”
三、常见测试方法分类
按不同维度划分，帮你从多角度理解测试的覆盖范围。
按测试对象分
| 类别 | 说明 | 示例 |
|---|---|---|
| 黑盒测试 | 不关注内部结构，只测输入输出 | 功能测试、安规认证测试 |
| 白盒测试 | 关注内部逻辑和电路路径 | 信号完整性测试、示波器/逻辑分析仪测量 |
| 灰盒测试 | 介于两者之间，了解部分内部结构 | 电源完整性、EMC 预测试、热设计验证 |
按测试目的分
| 类型 | 说明 |
|---|---|
| 功能测试 | 验证各项功能是否符合规格 |
| 性能测试 | 验证频率、带宽、延迟、帧率等性能指标 |
| 压力/极限测试 | 高负载、高温、极限条件下系统的表现（详见 方法 8） |
| 可靠性测试 | 老化、HALT、MTBF，验证长期稳定运行能力 |
| 环境测试 | 高低温、湿热、振动、跌落等环境适应性 |
| 功耗测试 | 待机功耗、工作功耗、能效转换等指标 |
| 兼容测试 | 不同平台、配件、系统环境下的适配性 |
| 安全测试 | 安规认证（UL/CE/CCC）、固件安全、信息安全 |
| 电磁兼容（EMC） | 辐射发射、抗扰度，满足电磁兼容标准 |
| 回归测试 | 修改/修复后验证原有功能是否正常（详见 方法 9） |
四、测试的通用流程
掌握了思维和方法，还要有一个通用的执行框架。
1. 明确测试目标
- 要测什么？（功能？性能？稳定性？）
- 成功标准是什么？
2. 建立假设
- “这个功能是正常的”
- “这个设备在标准环境下能正常工作”
- “这个操作不会导致崩溃”
3. 依据 SPEC 制定测试步骤
- 根据确认好的 SPEC，逐项列出要测的内容
- 对每一项明确：测试方法、通过判据
- 不事先”设计异常用例”，而是在执行中发现问题时，再用各种方法（控制变量、边界值、二分定位等）去深挖
4. 执行测试
- 逐步测试，从简单到复杂
- 发现问题后，先缩小范围再深入
- 记录每一步的执行过程和结果
5. 分析结果（基于执行记录）
- 回看执行记录，定位是哪一步出现了异常
- 整理：问题是什么？复现步骤是什么？
- 结合记录判断：是配置问题、环境问题还是部件问题？
6. 回归验证
- 修复后，重新测试
- 同时验证相关功能是否受影响
五、实战案例：机器开机后屏幕无显示
💡 本章是完整的实战排查演练。各步骤中会标注运用的测试方法名。读完本案例后，再逐章学习下方方法介绍——每个方法末尾的「开机无显示案例」与本案例形成双向参照。
前提条件
- 测试机器已安装 DDR + SSD + OS，接入电源
- 现象：按电源开机键后屏幕一直无显示
- 前置排查：先检查显示器本身是否正常，重新插拔显示器连接线，若仍无显示，按以下流程逐步分析
步骤 1：检查电源供电
排查策略：排除外部设备 —— 先确认显示器/线材等外部设备正常，再进入内部排查
操作：观察机器电源指示灯状态
现象 → 结论 → 下一步：
| 指示灯状态 | 结论 | 下一步 |
|---|---|---|
| 🔴 完全不亮 | 未供电，无法开机 | 检查电源线/插座 |
| 🟡 先亮后灭 | 供电不足或断电保护 | 更换符合 SPEC 要求的电源适配器再次检测 |
| 🟢 持续亮起 | 电源供电正常 | 进入步骤 2 |
→ 若更换电源适配器后仍异常：联系硬件电源支持团队
步骤 2：检查 BIOS 是否启动
操作：电源指示灯亮起后，在 USB 口接入键盘，切换 Num Lock / Caps Lock 键，观察键盘对应指示灯是否响应
现象 → 结论 → 下一步：
| 键盘指示灯 | 结论 | 下一步 |
|---|---|---|
| ❌ 不切换 | BIOS 尚未启动 | 进入步骤 2a |
| ✅ 正常切换 | BIOS 已启动 | 进入步骤 3 |
步骤 2a：更换 DDR 后重试（→ A/B 对比）
A/B 对比：用已知正常的 DDR 替换可疑 DDR，对比结果
操作：关机断电后，移除原 DDR，换入已知正常的 DDR，重新开机并观察键盘指示灯
现象 → 结论：
| 结果 | 结论 |
|---|---|
| 指示灯可切换 | 原 DDR 存在故障，更换 DDR 解决 |
| 指示灯仍不切换 | 非 DDR 问题，进入硬件开机检测 |
步骤 3：检查无 SSD 时是否能进入 BIOS 页面
方法标签：故障注入 —— 主动移除 SSD，制造”无存储”条件，观察系统行为是否异常
操作：在键盘指示灯可切换（BIOS 已启动）的前提下，关机、断开电源、移除 SSD（仅保留 DDR），再连接电源开机，观察显示器是否显示 BIOS 页面
现象 → 结论 → 下一步：
| 显示器表现 | 结论 | 下一步 |
|---|---|---|
| ❌ 无 BIOS 页面（但键盘指示灯正常） | 问题在 BIOS/显示链路，非 SSD | 联系 BIOS RD 分析 |
| ✅ 可显示 BIOS 页面 | 原 SSD 导致无法显示，SSD 存在故障 | 进入步骤 3a |
步骤 3a：更换新 SSD 后验证（→ 回归验证）
验证：更换部件后，重新验证完整开机流程
操作：更换确认正常的新 SSD，重新开机，观察屏幕显示
现象 → 结论：
| 结果 | 结论 |
|---|---|
| 正常显示 | SSD 故障已排除 |
| 仍无显示，且 BIOS 中可识别 SSD | 非物理故障，联系 RD 分析（固件/兼容性问题） |
排查路径总结
整个流程体现了 「从外部到内部、从简单到复杂」 的排查思维：
排查层级 嫌疑对象 判定方法 体现的测试方法 第一层 显示器/线材 插拔重连 排除法 第二层 电源供电 观察指示灯 证伪法 第三层 DDR 内存 换已知 OK 的 DDR A/B 对比 第四层 SSD 存储 移除 SSD 观察 BIOS 故障注入 验证层 更换部件后 重新跑完整流程 回归验证 每一步都遵循「假设→操作→观察→结论→下一步」的闭环，确保问题可被精确定位到具体部件。
六、OEM 计算机测试中的常用方法
前面的”分类”（第三章）是从理论角度把测试划分成几大类——黑盒白盒、功能性能等。下面这些方法是从实际操作层面展开——每个方法都是工作中可以拿来就用的。
两章的关系：有些方法在 第三章 里作为”类别”出现，在 第六章 作为”具体做法”展开。例如”压力测试”在 第三章 里是一个分类名，在 第六章 的方法 8 里是具体怎么做；“回归测试”同样如此。这里不再重复分类定义，只讲操作。
🤖 注意：第三章的"按测试目的分"涵盖 10 个类型，但并非所有类型都单独对应到第六章的某个方法中。第六章是从实际操作角度选取了最具代表性的方法展开，二者互为补充，但不是一一对应关系。
💡 先通过上方 第五章实战案例 建立整体印象，再来理解每种方法的原理；每个方法末尾的「开机无显示案例」与本案例形成双向参照。
方法速查表
先扫一眼全景，再深入每种方法。点击方法名可跳转到对应章节。
| 方法 | 核心一句话 | 典型场景 |
|---|---|---|
| 控制变量法 | 一次只变一个 | 定位问题根因 |
| 边界值分析 | 测”刚过线”的那一档 | 有范围/阈值的参数 |
| 等价类划分 | 挑代表，别全测 | 测试对象太多 |
| 正交实验法 | 科学抽样，减少组合 | 多参数交叉测试 |
| 二分定位 | 一次砍掉一半范围 | 嫌疑项多，要快速缩小 |
| B 对比 | 同机换件前后对比 | 验证特定部件/版本问题 |
| 故障注入 | 故意让它”出事” | 验证系统健壮性 |
| 极限测试 | 重负载跑够时间 | 挖出”累计型”隐患 |
| 回归测试 | 修好了再跑一遍 | 每次修复后 |
| 用户视角 | 像用户一样去用 | 想发现”设计想不到的问题” |
方法 1：控制变量法
Tip
一次只变一个东西，才能确定是哪个东西导致了问题。
怎么做：出问题后，把所有可能影响结果的因素列出来，每次只改变其中一个，保持其他不变，观察结果变化。
这是定位问题的最基础也最重要的方法。很多人排查问题时”一次换了好几样”，结果换好了也不知道是哪样起了作用。
什么时候用：
- 问题出现后，需要定位是哪个部件/参数导致的
- 多个嫌疑对象，需要逐个排除
开机无显示案例（详见 第五章实战案例）
机器开机后屏幕无显示，排查时依次锁定嫌疑对象：显示器→电源→DDR→SSD。每步只检查或更换一个部件，其他保持不变。例如先确认电源指示灯正常（排除电源），再换已知 OK 的 DDR 看键盘灯是否响应（排除内存），最后移除 SSD 观察 BIOS 是否显示（排除存储）。每一步只改变一个变量，确保问题能被精确定位到具体部件。
方法 2：边界值分析
Tip
问题的答案往往在”刚过线”的那一档。
怎么做：对于有范围/阈值的参数，重点测试边界附近的值，而不是中间那些”显然没问题”的值。
举个例子：某个温度范围是 0°C~60°C，重点测的不是 30°C，而是 -1、0、+1、59、60、61 这几个边界附近的值。
为什么有效：系统的”正常”和”异常”往往就在一根线上，越过线的瞬间最容易出问题。
什么时候用：
- 温度、电压、频率等连续性参数的临界点
- 最小/最大值、空值、超长值
- 额定值附近的上下浮动
开机无显示案例（详见 第五章实战案例）
排查到电源供电环节，更换了标注”19V/3.42A”的电源适配器后机器仍无法开机。怀疑供电不足，改用符合 SPEC 的更高规格适配器（19V/4.74A）测试。如果换高功率适配器能开机，说明问题在电源适配器输出能力不达标——这正是额定电流的边界值。额定值附近的上下浮动区，就是容易出问题的临界点。
方法 3：等价类划分
Tip
几十个测试对象，不需要每个都测，挑几个有代表性的就行。
怎么做：把所有可能的输入/对象按特征分组，同一组里的对象行为应该是相同的，所以每组只测一个代表。
举个例子：测试 32 种内存型号，没必要每种都跑一遍。按容量、频率、品牌分组，每组选一个代表测，能发现问题就说明这一组都可能有问题。
什么时候用：
- 测试对象太多，无法穷举
- 需要快速确定问题是否带有”批次/型号/类型”特征
开机无显示案例（详见 第五章实战案例）
排查 BIOS 是否启动时，并没有直接看屏幕（屏幕无显示），而是用键盘 Num Lock/Caps Lock 指示灯作为”代理信号”来判断。键盘指示灯响应 = BIOS 已启动，不响应 = BIOS 未启动。这是用简单、可观测的代理指标对启动状态做等价划分，不需要完整的 BIOS 显示来确认系统状态，大幅缩小了判断范围。
方法 4：正交实验法
Tip
多参数全组合要测几十组？用正交表，缩到几组就够了。
怎么做：当有多个参数、每个参数有多个取值时，全排列组合的数量会爆炸式增长。正交实验法用一张”正交表”来科学抽样，用尽可能少的组合覆盖尽可能多的参数搭配。
举个例子：测试 CPU（3 种）× 内存（4 种）× 主板（3 种），全组合需要 36 组。用正交实验法，可能只需要 9~12 组就能有效覆盖。
什么时候用：
- 多个参数交叉，组合数量太大
- 需要确认问题是否与”特定参数搭配”有关
- 机时/样机有限，不能穷举
开机无显示案例（详见 第五章实战案例）
某批次多台机器同时出现开机无显示问题，怀疑是多部件组合因素导致。不能逐台逐件全量排查，而是按”批次×DDR 型号×SSD 型号”分组合成几组代表机台，每组跑同一套开机流程，找出问题集中出现在哪个组合。用少量代表性组合覆盖了大多数可能性，快速定位问题是否带有”批次/型号”特征。
方法 5：二分定位
Tip
20 个测试项挂了一半，先测第 10 个，一次砍掉一半的嫌疑范围。
怎么做：把可能有问题的范围一分为二，先测中间点，根据结果决定下一步测哪一半。每次都能砍掉一半的嫌疑范围。
这是 控制变量法 的”加速版”——控制变量一次排除一个嫌疑，二分法一次排除一半。
举个例子：某个测试流程有 16 个步骤，跑完后发现问题。不知道哪一步出的错。二分法：先跑前 8 步 → 有问题？那就问题在前 8 步 → 再跑前 4 步……最多 4 次就能定位到具体步骤。
什么时候用：
- 排查范围大，嫌疑项多
- 每步测试耗时，需要快速缩小范围
开机无显示案例（详见 第五章实战案例）
排查范围涉及显示器、电源线、电源适配器、DDR、SSD、主板多个嫌疑对象，逐一排查太慢。先取中间嫌疑——直接换一根确认 OK 的电源线测试。如果问题还在，说明问题在”机器内部”（排除外部线材）；如果问题消失，说明问题在”外部线材”。一次测试砍掉一半嫌疑范围，从 6 个嫌疑项缩小到 3 个。
方法 6：A/B 对比
Tip
两台机器只差一个部件，同时跑同一个测试，差在哪一目了然。
怎么做：准备两个尽量相同的被测对象，只让其中一个有”嫌疑”的差异，在完全相同的条件下跑同一个测试，对比结果。
关键点：
- 两个对象要”只有一处差异”，否则对比无效
- 测试条件（环境、配置、操作步骤）要完全一致
- 适用于硬件替换验证、版本对比、批次对比
开机无显示案例（详见 第五章实战案例）
BIOS 未启动，键盘灯不响应。关机断电后，移除原 DDR，换入一台已知正常的 DDR重新开机。键盘灯可切换了 → 说明原 DDR 有故障。同一台机器更换 DDR 前后，其余部件完全相同，只变了 DDR 这一个变量，A/B 对比直接锁定了故障部件。这是”只有一处差异，对比结果一目了然”的典型场景。
方法 7：故障注入
Tip
故意让系统”出事”，看看它会不会”崩”。
怎么做：在正常运行的系统中，人为引入异常条件，观察系统能不能正确应对。
常见的故障注入方式：
- 突然断电/断电恢复
- 断开网络连接
- 替换为已知故障的部件（坏件替换）
- 制造高负载、高温度
- 人为触发错误状态
核心思路：系统出故障是迟早的事，不如在测试阶段就让它出事，看看它的表现是不是”优雅地失败”而不是”直接崩溃”。
开机无显示案例（详见 第五章实战案例）
BIOS 已启动（键盘灯可切换）但屏幕不显示。主动制造”无 SSD”条件：关机移除 SSD 只保留 DDR 再开机，结果屏幕正常显示了 BIOS 页面。这是典型的故障注入——人为移除一个部件，看系统能否正常应对。结果显示系统能运行，说明原 SSD 是导致屏幕无显示的”凶手”。
方法 8：压力/极限测试
Info
对应 第三章”按测试目的分”中的压力测试，这里从实际操作展开。
Tip
平时没事，一重负载就出问题——这种隐患要靠压力测试挖出来。
怎么做：让系统在接近或超过设计极限的条件下长时间运行，观察是否会出现平时测不到的问题。
常见形式：
- 满载烤机（CPU/GPU 满负荷运行）
- 长时间老化运行
- 极限温度/电压下运行
- 高频次重复操作
为什么重要：很多硬件问题是”累计”出来的——发热积累、电压波动积累、时序偏差积累。正常测试跑几分钟看不出问题，跑几小时甚至几天才暴露。
开机无显示案例（详见 第五章实战案例）
某批次机器在常温下测试一切正常，但客户反馈”用久了偶尔黑屏”。于是安排机器在满载烤机（CPU/GPU 满负荷）下连续运行 24 小时，结果发现高负载一段时间后屏幕黑屏、重启后恢复。这是长时间重负载下的”累计型”问题——发热或电压波动积累到临界点才暴露，正常短时测试根本测不出来。
方法 9：回归测试
Info
对应 第三章”按测试目的分”中的回归测试，这里从实际操作展开。
Tip
修了一个 bug，顺便再验证一遍之前正常的功能，防止”修好了这个，坏了那个”。
怎么做：修复问题后，不仅重新测试修复项，还要把之前已经通过的关键测试项再跑一遍。
什么时候做：
- 每次修复 bug 后
- 更换了 BIOS/固件版本后
- 更换了关键部件后
开机无显示案例（详见 第五章实战案例）
更换新 SSD 后机器正常开机显示，问题修复。但修复后不能就此结束——重新跑一遍完整开机流程（电源→BIOS→SSD 识别→OS 启动），同时验证显示器连接、USB 功能、音频输出等之前通过的关键项，确认更换 SSD 没有带来任何副作用。这是修复后必要的回归验证，防止”修好了这个，坏了那个”。
方法 10：用户视角
Tip
你测出来的问题，用户也会遇到——那你为什么不从用户的角度去操作一次？
怎么做：放下测试员/工程师的身份，像用户一样去操作产品。用用户的操作习惯、用户的误操作方式、用户不知道原理的状态来使用产品。
核心思路：测试人员往往有”知识优势”——我们知道这个功能是干什么的、内部是怎么设计的。但用户不知道。用户可能会：
- 不按说明书操作（拔插错顺序、先开后关）
- 连续反复操作某个按钮
- 在功能还没完成时就再次触发（双击、连点）
- 用不符合设计预期的方式使用产品
- 同时做多件事，而不是按”标准流程”一步一步来
很多”奇怪”的 bug，不是用户的问题，是设计时没有从用户角度考虑。
举个例子：一个测试项要求”先关机再断电”。标准流程没问题。但用户可能直接拔电源。你能不能直接从用户的角度出发，测一测”用户真的会这么干”？
什么时候用：
- 发现一个”怎么都不会复现”的问题，试着从用户角度重现
- 新产品的初步体验
- 想检查”设计是否真的对用户友好”
开机无显示案例（详见 第五章实战案例）
测试员排查无显示问题时，标准流程是”关机→断电→拔插配件”。但从用户视角想：用户可能直接拔电源再插上就开机，不按断电顺序；也可能显示器线没插紧、显示器没开启。让测试人员以”不知道原理”的状态操作一遍，发现”显示器电源没开”和”视频线松动”两种”低级”原因竟占了近半数的无显示案例。提醒我们在正式排查前先确认这些用户常见操作。