SSD 不是跑个 FIO 就算测完:一次技术交流,讲透掉电、拉偏、毛刺与协议验证
2026-07-27 17:06:17

很多人第一次接触 SSD 测试时,脑海中的方案往往很简单:

找一台电脑,把 SSD 插进去,跑一遍 FIO,看看顺序读写、随机 IOPS 和时延是否达标,再做几次掉电测试,好像就差不多了。

但在工业控制、航空/航天电子以及其他高可靠应用中,事情远没有这么简单。

一块 SSD 在实验室里连续运行几天没有报错,并不意味着它装进实际设备后仍然稳定。真实系统中的供电波动、异常断电、连接器接触不良、PCIe 信号干扰、高低温变化以及主机侧兼容性问题,都可能成为故障的诱因。

2026年7月21日,我们围绕一套定制化 SSD 测试平台进行了两个多小时的技术交流。讨论从 PCIe 协议分析仪开始,逐步延伸到 NVMe 协议符合性测试、功耗测量、电压拉偏、异常掉电、热插拔、信号毛刺注入、高低温环境以及自动化测试平台的搭建。

整个交流最终落到了一个非常实际的问题上:

对于一块面向航空/航天和工业应用的定制 SSD,究竟应该怎样搭建一套既有标准、又能贴近真实业务场景的测试系统?

一、先从 PCIe 协议分析仪谈起

交流一开始,大家首先讨论的是 PCIe 协议分析仪。

PCIe 协议分析仪的基本作用,是把主机与设备之间传输的 PCIe 数据包完整抓取下来,然后按照物理层、数据链路层、事务层以及上层 NVMe 协议进行解码。

例如,当一块 SSD 突然掉盘时,我们通常会问:

  • 是主机停止发送命令了?
  • 是 SSD 没有返回 Completion?
  • 是链路进入了 Recovery?
  • 是发生了大量 Replay?
  • 是出现了 Correctable Error 或 Uncorrectable Error?
  • 还是主机主动拉动 PERST#,将设备复位了?

这些问题,仅靠操作系统日志往往很难回答。

操作系统只能告诉我们“盘不见了”或者“命令超时了”,但它不一定能够还原掉盘之前几百毫秒内 PCIe 总线上发生了什么。

为什么分析仪的 Interposer 很重要

协议分析仪通常需要在主机和 SSD 之间插入一个 Interposer,也就是协议采集转接治具,需要interposer将PCIe双向差分信号以及sideband等信号全部引入PCIe协议分析仪,所以,分析仪本身是一个旁路设备。

这里有一个很容易被忽视的问题:

Interposer 本身不能明显改变原来的 PCIe 链路。

如果为了抓包而插入的设备对信号进行了重新驱动、重新定时或者过度均衡,那么原来系统中的信号问题可能反而被“修好”了。

最后就会出现一种很尴尬的情况:

不接分析仪时,SSD 经常掉盘; 接上分析仪后,问题却消失了。

这种情况下,分析仪虽然抓不到错误,但并不代表系统真的没有问题,而有可能是测试工具改变了原来的连接状态。

以 SerialTek 的 SI-Fi Interposer 的专利技术的信号高保真为例,其公开资料描述的方式是将每条 Lane 的模拟信号分配到主机、设备和分析仪采集路径,并尽量保持原有链路训练过程;同时,Sideband 信号也可以提供给分析仪进行触发和解码。其设计目标正是减少测试治具对原链路的干扰。

协议分析仪适合解决什么问题

协议分析仪最适合处理的是“根因定位”:

  • SSD 为什么掉盘?
  • 为什么从 PCIe x4 降成了 x2 或 x1?
  • 为什么链路频繁进入 Recovery?
  • 主机和设备是谁先停止响应?
  • PERST#、CLKREQ# 等边带信号是否异常?
  • NVMe 命令为什么超时?
  • 错误发生在 PCIe 层,还是 NVMe 层?

但协议分析仪并不等于完整的 SSD 测试平台。

它更像一台“事故现场记录仪”:当系统已经出现问题时,帮助工程师看清问题发生前后的总线行为。

二、客户真正需要的,不只是一套标准测试用例

随着交流深入,客户逐渐把真实需求讲清楚了。

这次要验证的 SSD,并不是直接采购的通用消费级产品,而是面向特定系统使用的定制化 SSD。部分产品采用非标准机械结构和接口定义,需要先通过专门设计的 Adapter 转换成 M.2、U.2或者PCIe AIC等标准接口,才能接入商业测试设备。

需要验证的内容大致分为四类。

第一类:基本功能

包括:

  • SSD 能否正常识别;
  • Namespace 能否创建、删除和格式化;
  • 固件下载与激活是否正常;
  • 读、写、Flush、Compare等命令是否正确;
  • 不同容量、队列深度和数据块大小下是否稳定。

这些属于一块 NVMe SSD 最基本的“入门考试”。

第二类:性能

客户并不满足于简单跑一个顺序读写结果,而是希望按照真实业务负载设计 Workload。

例如:

  • 读写比例是多少;
  • 以4KB小块随机访问为主,还是大块顺序访问为主;
  • 队列深度通常处于什么范围;
  • 是短时间突发写入,还是长时间持续写入;
  • 是否存在周期性大量落盘;
  • 是否要求稳定的尾延迟。

尽管组织方式非常分散的SNIA 的 Solid State Storage Performance Test Specification( SNIA SSS PTS),并不为业内SSD厂家认可,但它提供了预处理、稳态判断、IOPS、吞吐量、延迟和写饱和的一些测试方法,业内还是有些客户拿来作为不同 SSD 之间进行可重复性能比较的基础框架,但真实项目仍需在此基础上加入自己的业务负载。

第三类:协议和兼容性

客户还遇到过一种典型问题:

一块 SSD 在 PCIe Gen3 x4 模式下工作正常,但当链路降到 Gen2 x1、Gen3 x1,或者进入高温、低温条件后,稳定性明显下降。

这类问题既可能与 SSD 固件有关,也可能与:

  • PCIe Lane配置;
  • 链路训练;
  • 均衡参数;
  • 参考时钟;
  • 主机Root Complex;
  • 转接板布线;
  • 连接器接触状态

有关。

因此,除了上层 NVMe 功能验证,还必须保留 PCIe 层面的诊断手段。

第四类:可靠性和环境适应性

这才是本次交流的重点。

客户希望验证:

  • 电压偏高、偏低时SSD是否正常;
  • 供电出现短时跌落时是否掉盘;
  • 读写过程中突然断电是否损坏数据;
  • 重新上电后多长时间能够恢复;
  • PCIe某条Lane受到干扰时如何处理;
  • Sideband信号异常时设备是否会死锁;
  • 在高低温环境中是否还会出现同样的问题。

换句话说,他们真正想要的并不是一台“点一下开始、最后生成一份报告”的设备,而是一套能够围绕自身业务场景持续扩展的测试平台。

三、一体化设备和模块化平台,应该怎样选

接下来的讨论围绕两种技术路线展开。

路线一:购买一体化 SSD 测试系统

一体化设备的最大优点是省事。

设备中通常已经集成:

  • 测试主机;
  • PCIe插槽或SSD接口;
  • 电源控制;
  • Hot Plug;
  • PERST#控制
  • 功耗采集;
  • NVMe命令;
  • 自动化测试脚本;
  • Web管理界面;
  • 测试报告。

工程师选择测试项目、插入 SSD、点击开始,系统就可以自动执行。

这种方式特别适合:

  • SSD主控厂商;
  • SSD成品厂商;
  • 服务器和存储系统厂商;
  • SSD新产品导入部门;
  • 供应商质量管理部门。

当企业同时评估多家 SSD 供应商时,可以让所有产品运行同一套测试用例,最终按照通过、失败、警告和跳过的数量进行横向比较。业内的权威产品是SanBlaze系统,它是NVMe官方组织UNH IOL Labs官方指定的产品,可以唯一可以直接运行UNH IOL Labs的NVMe,NVMe-MI,以及NVMe over Fabric兼容性,是UNH IOL指定的唯一用来测试I2C/I3C的测试工具,也是唯一用来测试OCP认证的产品

路线二:搭建模块化测试平台

模块化方案则是把不同功能拆开:

  • 一个模块负责电压拉偏;
  • 一个模块负责异常断电;
  • 一个模块负责Hot Plug;
  • 一个模块负责PCIe信号毛刺;
  • 一个模块负责功耗监测;
  • 主机负责运行FIO或业务程序;
  • 上层软件负责统一编排。

它的优点是灵活。

例如,在FIO写入到特定数据量时突然切断12V;或者先让SSD进入高负载,再在PCIe Lane 2上导入短时毛刺;也可以在高温环境下反复执行上电、掉电和数据校验。

对于本次客户而言,模块化路线显然更贴近实际需求。

因为他们的重点不是验证所有NVMe可选特性,而是把有限的测试资源集中在真实产品最容易出问题的场景上。这些场景就需要Quarch公司的几大类产品负责测试。

四、NVMe协议符合性,不等于整机可靠性

交流中还专门厘清了NVMe协议符合性测试的定位。

NVMe规范由NVM Express组织维护,而其官方符合性与互操作性测试项目长期与美国新罕布什尔大学互操作实验室UNH-IOL合作开展。通过相应测试的产品,可以进入NVMe Integrator’s List。

UNH-IOL的测试主要关注:

  • Identify;
  • Set/Get Features;
  • Queue创建与删除;
  • Format NVM;
  • Firmware;
  • Dataset Management;
  • Read/Write;
  • Flush;
  • Atomic Write;
  • Power Management;
  • Metadata;
  • End-to-End Data Protection;
  • Namespace及其他NVMe功能。

这些测试很重要,因为它能回答:

这块SSD的行为是否符合NVMe规范?

但它不能完全回答另一个问题:

这块SSD放进我们的设备,在我们的供电、温度、干扰和业务负载下,能不能长期稳定运行?

协议符合性是“基础体检”,场景可靠性则更接近“实战演练”。

两者不能互相替代。

五、电压拉偏不是简单调一下电源旋钮

在明确总体方向之后,交流开始进入具体工具。

首先讨论的是Quarch PPM,也就是Programmable Power Module,可编程电源模块。

PPM在系统中的位置

正常情况下,SSD由主板或背板直接供电:

主机/背板 ↓ SSD

加入PPM后,测试治具会把主机原来提供给SSD的电源切断,再由PPM向SSD提供可编程电压:

主机/背板 ↓ PCIe数据与Sideband信号 Quarch Power Injection Fixture ↓ SSD

同时:

PPM ↓ 12V、5V或3.3V 测试治具 ↓ SSD

数据链路仍然经过原来的主机,只有供电改由PPM控制。

可以模拟哪些供电问题

PPM并不只是把12V改成11V这么简单,而是可以编程输出一段完整的电压波形。

例如:

  • 先输出12.0V;
  • 20微秒后降到11.5V;
  • 保持5毫秒;
  • 再下降到9V;
  • 随后恢复12V;
  • 整个过程重复一万次。

这样便可以模拟:

  • 电压Margin测试;
  • Brownout;
  • 瞬时跌落;
  • 电源抖动;
  • 缓慢上升;
  • 缓慢下降;
  • 突然掉电;
  • 不规范的上电时序。

Quarch官方资料也将PPM定位为面向SSD、HDD及PCIe/SAS/SATA设备的可编程供电和功耗测量工具,可生成Ramp、Glitch、Brownout及Power Failure等波形。

对于航空/航天和工业设备,这类测试比单纯的额定电压测试更有价值。

因为实际系统中的电源问题,往往不是持续输出一个偏低电压,而是偶发、短暂并且难以复现的瞬态变化。

六、不再用手拔插SSD,而是把每个针脚交给脚本

随后演示的是Quarch Hot-Swap/Breaker类模块,以及TestMonkey控制软件。

很多人理解的热插拔测试,是工程师站在设备旁边,不断把SSD拔出来再插进去。

这种做法有三个问题:

第一,连接器有寿命,不可能连续人工插拔几千次。

第二,每个人插拔的速度和动作不同,测试无法重复。

第三,真正的连接器并不是所有针脚同时接通,而是按照长针、短针以及电源、地、Present等不同顺序接触。

自动化Hot-Swap模块的价值,就是把物理插拔转换成可编程的电气插拔。

模拟标准和非标准插入顺序

软件可以把不同针脚划分到多个Sequence Group中。

例如:

  • 第一组立即接通;
  • 25毫秒后接通第二组;
  • 再过25毫秒接通第三组。

这可以模拟标准的连接器插入过程。

更重要的是,工程师也可以故意打乱顺序:

  • 让Present信号提前;
  • 让电源针脚延后;
  • 让某条Sideband最后才接通;
  • 让某个针脚产生Bounce;
  • 让某个针脚接触后又瞬间断开。

实际工程中,主机背板和连接器未必都严格符合标准。SSD厂商即使发现主机存在问题,也经常需要通过修改固件提高兼容性。

因此,能够重现“不标准的主机行为”,本身就是一种非常实用的调试能力。

Quarch的Gen5 U.2 Breaker模块可单独控制电源、Present、Sideband及PCIe数据线,并支持可编程插拔顺序、针脚Bounce和高速Glitch。其官方规格列出的开关控制分辨率为1微秒、Pin Bounce分辨率为100纳秒,并可产生50纳秒级的PRBS或用户定义毛刺。

七、在PCIe Lane上“制造毛刺”,寻找SSD的极限

演示继续深入到PCIe信号故障注入。

测试人员可以选择:

  • 某一条Lane;
  • 某一对差分信号;
  • 差分对中的单独一根;
  • REFCLK;
  • PERST#;
  • CLKREQ#;
  • 其他Sideband信号

进行开路、短时断开或者毛刺注入。

为什么要在FIO运行过程中注入故障

如果SSD处于空闲状态,即使在链路上加入一次很短的毛刺,也可能正好没有数据包经过,最终看不出任何影响。

因此更有意义的测试方式是:

  1. 先运行持续读写;
  2. 确保PCIe链路存在稳定流量;
  3. 在某条Lane上周期性导入毛刺;
  4. 记录吞吐量、错误数量和链路状态;
  5. 逐步提高故障频率;
  6. 观察SSD从重传、降速到最终掉盘的过程。

在错误较少时,PCIe链路可能通过重传机制恢复,应用层只表现为带宽轻微下降。

随着故障增加,可能逐渐出现:

  • Replay数量上升;
  • Correctable Error增加;
  • 链路进入Recovery;
  • 从x4降为x2或x1;
  • 从Gen4降为Gen3;
  • NVMe命令超时;
  • 最终掉盘。

这类测试的目的不是证明SSD在所有干扰下都不会出错。

更现实的目标是测出:

不同SSD面对相同错误时,谁恢复得更快,谁更容易掉盘,谁的固件异常处理更成熟。

八、为什么航空/航天和工业环境更需要故障注入

实验室环境通常非常干净:

  • 温度稳定;
  • 电源稳定;
  • 线缆固定;
  • 电磁环境简单;
  • 设备没有剧烈振动。

但真实设备内部可能完全不同。

在狭小机箱中,电源模块、计算板、交换板、存储板和各种高速接口集中在一起,EMI环境远比普通电脑复杂。

车辆、机载和其他移动平台还会叠加:

  • 持续振动;
  • 连接器接触变化;
  • 瞬态冲击;
  • 高低温循环;
  • 电源切换;
  • 负载突变。

SSD在实验室里运行正常,装进设备后出现间歇性掉盘,并不罕见。

实验室不可能完全复制所有真实环境,但可以通过故障注入,把现场可能出现的影响转化成可控制、可重复的测试条件。

例如,用某条Lane周期性通断来模拟接触不良,用REFCLK毛刺模拟时钟干扰,用电压跌落模拟电源瞬态。

这样,原本“几天才偶发一次”的问题,就可能在几十分钟内稳定重现。

九、PPM、PAM和Hot-Swap模块,分别干什么

交流到这里,几种Quarch工具的分工逐渐清晰。

Hot-Swap/Breaker:负责“断什么、什么时候断”

主要用于:

  • 自动插拔;
  • Surprise Removal;
  • 针脚顺序控制;
  • 单独断开某条Lane;
  • Sideband拉高、拉低;
  • Pin Bounce;
  • Signal Glitch;
  • 连接器接触不良模拟。

PPM:负责“给多少电、怎样变化”

主要用于:

  • 电压拉偏;
  • 上下电时序;
  • 短时掉电;
  • Brownout;
  • 电源噪声;
  • 电源Ramp;
  • 功耗测量。

PAM:负责“真实系统里到底发生了什么”

PAM是Power Analysis Module。

它和PPM最重要的区别是:

PPM主动代替主机给SSD供电,而PAM仍然使用主机或背板原本提供的电源,只在中间进行透明测量。

因此,当用户说:

这块SSD只有装在我的服务器里,运行我的业务程序时功耗才异常。

此时更适合使用PAM。

PAM可以同时记录:

  • 电压;
  • 电流;
  • 功率;
  • 部分Sideband信号状态。

因为电源仍来自真实主机,测到的是SSD在实际系统中的功耗行为,而不是外接实验电源下的结果。

Quarch对PAM的官方定位也是测量主机真实提供给DUT的电压、电流、功耗以及Sideband状态;PAM通过相应Interposer接入系统,问题复现后还可以再使用PPM或Breaker模块进行主动故障构造。

把FIO结果和功耗放到一张图里

Quarch Power Studio可以记录长时间功耗波形。

测试脚本还可以把FIO输出的IOPS、带宽或其他业务指标作为用户数据加入同一条时间轴。

最终工程师可以在一张图中同时看到:

  • SSD功耗突然上升;
  • IOPS开始下降;
  • CLKREQ#发生变化
  • 某个Sideband被拉低;
  • 随后设备掉盘。

PAM最高可按照4微秒间隔采集功耗数据,也就是250KS/s;对于长时间测试,通常会选择更低采样率,以控制数据规模。

这种跨信号关联能力,对于分析偶发故障尤其有价值。

十、生产测试、研发验证和协议测试,不是一回事

交流中还出现了一个常见误区:

看到SSD工厂里摆着大型机柜或高低温箱,里面一次插入几十、几百块SSD,很多人会认为这就是完整的SSD测试。

实际上,这更多属于生产测试、RDT或者老化筛选。

它解决的问题通常是:

  • 焊接是否正常;
  • NAND是否存在明显坏块;
  • 固件和参数是否正确;
  • 容量是否符合要求;
  • 基本读写是否通过;
  • 产品是否能够稳定老化。

而研发阶段的验证更关注:

  • 为什么掉盘;
  • 哪种异常时序会触发Bug;
  • 固件如何处理PCIe错误;
  • 异常掉电后数据是否一致;
  • 不同主机平台为什么表现不同;
  • 设备在边界条件下能否恢复。

此外,协议符合性测试关注的是SSD行为是否符合NVMe规范,性能测试则关注IOPS、吞吐量、延迟和稳态。

这几类测试可以互相补充,但不能画等号。

十一、SANBlaze一体化平台的价值在哪里

交流后半段,现场演示了一套SANBlaze桌面式NVMe SSD测试系统。

它本质上是一台高度集成的测试主机,内部已经包含:

  • NVMe测试环境;
  • 可控PCIe插槽;
  • Power Control;
  • Hot Plug;
  • Surprise Removal;
  • PERST#控制
  • 功耗测量;
  • NVMe命令执行;
  • 自动测试脚本;
  • Web管理界面;
  • 测试报告。

SANBlaze SBExpress-DT5的官方功能也包括Power Up/Down、PERST、Hot Plug、Surprise/Graceful Removal、功耗测量、LTSSM监控以及Python、XML和REST API。

一体化平台最适合当“统一考试系统”

假设需要评估五家SSD供应商。

可以为所有产品选择同一组测试:

  • Identify;
  • Format;
  • Firmware;
  • Read/Write;
  • Data Compare;
  • Power Cycle;
  • Hot Plug;
  • Atomicity;
  • Power Management;
  • OCP或其他企业级特性。

测试结束后,系统自动生成结果:

  • Pass;
  • Fail;
  • Warning;
  • Skip。

这样,采购方或产品导入部门就有了一把统一的尺子。

某家供应商第一次有几十项失败,修改固件后再测试;第二次减少到十几项;第三次全部通过。

这比仅凭厂商提供的宣传参数更有说服力。

SANBlaze现有自动测试体系可提供大量内置测试,并能够实时显示失败、跳过和警告;2025年开始,其平台成为UNH IOL Labs官方指定的唯一可以运行UNH-IOL INTERACT NVMe协议符合性软件。

为什么它仍然不能完全替代模块化平台

SANBlaze也支持Python二次开发,但当测试逻辑涉及大量自定义业务状态、非标准接口、外部温箱和特殊触发条件时,开发复杂度会明显增加。

对于SSD主控和固件团队来说,这些API并不陌生。

但对于以系统应用为主的团队,如果只是想在“写入第100GB时突然切断某个针脚”,使用独立故障注入模块往往更加直接。

因此,本次交流形成的判断是:

  • SANBlaze适合作为标准化入场测试平台;
  • Quarch模块适合作为定制化可靠性测试组件;
  • PCIe分析仪用于失败后的深度定位。

三者并不是互相取代,而是处于不同层级。

十二、高低温测试,关键是把什么放进温箱

客户还关心,这些测试模块能否直接放进高低温箱。

通常不建议把包含控制器、CPU和复杂管理电路的一体化测试主机直接放进温箱。

更常见的方式是:

  • 测试主机放在温箱外;
  • SSD放在温箱内;
  • 通过PCIe延长线、MCIO线缆或者专用转接治具连接;
  • 必要时把小型Fixture放在温箱内;
  • 控制模块和数据采集设备留在外部。

这样既能保证测试设备正常工作,又能让SSD处于目标温度。

不过,延长线和转接板本身也会改变信号质量。

尤其在PCIe Gen4、Gen5环境中,线缆长度、连接器、转接板和背板损耗都有可能引入新的问题。

因此,高低温测试不能只记录“是否掉盘”,还应该同时记录:

  • 当前PCIe速率和宽度;
  • Recovery次数;
  • Correctable Error;
  • AER记录;
  • NVMe超时;
  • 功耗;
  • 温度;
  • 发生错误时的具体时间点。

十三、为什么测试SSD时,有时反而要加入PCIe Switch

交流接近尾声时,又讨论了一个很实用的问题:

在普通PC或服务器主板上直接测试SSD,主板本身的信号质量可能就不够好。

如果SSD发生掉盘,很难立刻判断究竟是:

  • SSD有问题;
  • CPU Root Complex有问题;
  • 主板走线有问题;
  • 背板有问题;
  • 转接卡有问题;
  • 连接器有问题。

一种常用的隔离方法,是在测试系统中加入PCIe Switch卡。

Switch会将一条链路变成两段:

CPU/Root Complex ↓ PCIe Switch ↓ SSD

如果SSD接在Switch后工作稳定,直接接主板却频繁进入Recovery,问题就可能更多集中在原主板链路上。

当然,加入Switch也改变了原来的拓扑,它不能代替最终真实环境测试。

它的价值在于“隔离变量”:

先建立一个信号质量较好的基准环境,确认SSD本身是否稳定;随后再回到真实系统,比较两个环境之间的差异。

当两种环境表现不同,再使用协议分析仪抓取链路训练和错误过程,定位效率会高很多。

十四、最终方案:不是寻找一台万能设备,而是搭建五层测试平台

经过两个多小时讨论,一套适合本项目的SSD测试平台逐渐清晰。

第一层:测试主机与负载

采用Linux测试主机,运行:

  • FIO;
  • nvme-cli;
  • 数据写入和校验程序;
  • 用户自己的业务负载;
  • 温度、性能和系统日志采集程序。

第二层:故障注入

加入Quarch Hot-Swap/Breaker类热插拔/故障注入工具,完成:

  • 自动插拔;
  • Surprise Removal;
  • PERST#控制
  • Lane通断;
  • Sideband故障;
  • Pin Bounce;
  • Signal Glitch;
  • 接触不良模拟。

第三层:供电与功耗

使用PPM完成:

  • 电压拉偏;
  • 上下电时序;
  • Brownout;
  • 电源毛刺;
  • 异常掉电。

使用PAM完成:

  • 真实主机供电监测;
  • 电压、电流、功耗记录;
  • Sideband状态记录;
  • 功耗与IO负载关联。

第四层:标准化验证

使用SANBlaze或者同类平台完成:

  • NVMe基本功能;
  • 协议符合性预检;
  • OCP及企业级特性;
  • 标准Power Cycle;
  • Data Integrity;
  • 固件、Namespace和管理功能;
  • 供应商横向比较。

正式的NVMe协议符合性和互操作性认证,可根据项目需要通过UNH-IOL体系完成。

第五层:深度诊断

当测试出现以下问题时,再接入SerialTek PCIe协议分析仪:

  • 掉盘;
  • 降速;
  • 降Lane;
  • Recovery频繁;
  • 命令超时;
  • 主机和设备互相等待;
  • PERST#或其他Sideband异常
  • 无法判断是主机问题还是SSD问题。

这样可以避免把昂贵的协议分析仪用于每一次普通测试,同时又保留最终定位复杂问题的能力。

十五、一套更适合落地的测试流程

结合本次交流,建议把测试流程分成八个阶段。

阶段一:建立基线

在常温、额定电压和稳定PCIe链路下,确认:

  • SSD正常识别;
  • 固件版本正确;
  • 容量和Namespace正确;
  • PCIe速率与Lane宽度正确;
  • 基本读写无误;
  • SMART和错误日志正常。

阶段二:业务性能测试

按照实际应用建立Workload,而不是只看厂商标称参数。

记录:

  • IOPS;
  • 带宽;
  • 平均延迟;
  • P99、P99.9尾延迟;
  • 功耗;
  • 温度;
  • 稳态表现。

阶段三:电压Margin

分别测试:

  • 额定电压;
  • 上限电压;
  • 下限电压;
  • 缓慢升降;
  • 短时跌落;
  • 周期性波动。

阶段四:异常掉电和恢复

在不同写入阶段切断电源:

  • 空闲;
  • 顺序写;
  • 随机写;
  • Flush前;
  • Flush后;
  • 固件更新过程中;
  • Metadata更新过程中。

重新上电后检查:

  • 能否识别;
  • 恢复时间;
  • 数据是否完整;
  • 是否出现只读状态;
  • SMART和错误日志是否异常。

阶段五:PCIe故障注入

逐Lane执行:

  • 短时断开;
  • 周期性毛刺;
  • 单边差分信号异常;
  • REFCLK异常;
  • PERST#异常
  • Sideband异常。

记录SSD的容错边界和恢复能力。

阶段六:环境组合测试

把温度、供电和IO组合起来:

  • 高温+持续写;
  • 低温+频繁上电;
  • 高温+电压下限;
  • 低温+Hot Plug;
  • 温度循环+周期性故障注入。

很多问题只有在两个或三个条件同时出现时才会暴露。

阶段七:标准符合性

要求供应商提供正式测试报告,或者使用统一平台进行复测。

标准测试不用全部自行开发,但必须作为供应商准入的基础门槛。

阶段八:自动回归

所有出现过的问题都应转化为自动化回归用例。

第一次定位问题可能需要几天;一旦问题被理解,就应该把触发条件固化到脚本中。

之后每次更新SSD固件,都自动重跑。

这样,测试平台才会随着项目积累逐渐变得有价值,而不是每次遇到问题都从头分析。

写在最后

这次交流最重要的结论,不是哪一家设备功能最多,也不是哪一台设备能够包办所有测试。

真正重要的是先把测试目标分清楚。

  • 性能测试回答“跑得快不快”;
  • 协议符合性回答“行为是否符合规范”;
  • 功耗测试回答“电从哪里消耗掉了”;
  • 故障注入回答“出现异常时能不能扛住”;
  • 环境测试回答“换到真实条件下是否仍然稳定”;
  • 协议分析仪回答“问题到底是谁造成的”。

对于航空/航天、工业和其他高可靠应用来说,SSD测试绝不能停留在“能识别、能读写、能跑FIO”的阶段。

真正可靠的测试平台,应该能够主动制造问题、稳定复现问题、记录问题,并最终把一次偶发故障变成一条可以重复运行的自动化测试用例。

不是等SSD在现场掉盘以后再去猜原因,而是在它交付之前,就尽可能把那些最难看的错误提前逼出来。

这才是SSD可靠性验证真正的价值。

本文根据2026年7月21日SSD测试技术交流整理。文中涉及的产品功能和技术规格,已结合Quarch、SANBlaze、SerialTek、NVM Express、UNH-IOL及SNIA公开资料进行核对;具体配置仍应以厂商最新版本、许可证和对应接口模块为准。

更多PCIe5&6.0, CXL, NVMe SSD, SAS/SATA, NVMe over Fabric (NVMoF), NAND, UFS, 新型存储技术NVM(RRAM/ReRAM, FRAM/FeRAM, MRAM, PCM, 3D-NOR, SRAM/DRAM等) DDR5/LPDDR5以及UFS测试方面的问题想咨询,可以查看Saniffer公司2026.2.24最新更新的测试工具白皮书15.1版本,我们已经整理收录在Saniffer公众号的【白皮书】菜单中。

欢迎关注Saniffer公众号,点击底部菜单栏即可免费获取。如有任何技术问题,也可直接在公众号内留言交流。