1. 信创测试里的异常场景到底在测什么1.1 从一次真实故障说起先讲个我最近遇到的案例。某个单位做信创迁移把一套OA系统从x86Windows迁移到了麒麟V10鲲鹏920的国产化环境迁移完成后功能测试、性能测试全部通过系统顺利上线。结果上线第三天机房的一次例行UPS切换测试直接把这套系统打挂了。重启之后数据库连接池拒绝连接缓存服务无法恢复前端登录页一直转圈最后花了四十多分钟才人工恢复。这个案例非常典型。功能测试和性能测试都过了为什么一次电源切换就能把系统打垮原因其实不复杂信创迁移验收时几乎所有测试用例都聚焦在“正常情况下系统能不能跑”没有人认真设计过“异常情况下系统能不能扛”。UPS切换导致电力短暂中断服务器重启数据库和缓存之间发生了一次时序错乱——这个场景在功能用例里根本不存在于是恢复机制形同虚设。这里要明确一个概念软件测试里的异常场景指的是系统在非预期条件、故障条件、极端负载或外部干扰下表现出来的行为和恢复能力。信创测试中的异常场景则是在国产化软硬件栈国产CPU、国产操作系统、国产数据库、国产中间件之上重复叠加这些故障条件验证整个技术栈在“出问题时”是否还能守住底线。1.2 为什么信创测试尤其看重异常场景我接触过不少做信创适配的团队大家普遍的困惑是功能测试用例靠业务需求说明书就能梳理性能测试也有压测工具可以量化但异常场景总是感觉很虚不知道测什么、怎么测、测到什么程度算通过。这种困惑是正常的因为异常场景测试本来就比功能测试难设计、难执行、难量化。而在信创背景下又叠加了三层特殊矛盾第一国产化软硬件生态的成熟度还在爬坡期。国产CPU、操作系统、数据库在长期稳定性上与经过数十年打磨的传统成熟产品仍有差距。这不是说国产不行而是说测试策略要更保守、更严密。你在x86上跑三年不重启都没事的系统迁移到信创环境可能半年就会出现一次诡异的内存问题异常场景测试就是提前把这些风险挖出来的手段。第二信创栈的组合复杂度是乘数级的。CPU有鲲鹏、飞腾、龙芯、海光、兆芯、申威操作系统有麒麟、统信UOS、中科方德数据库有达梦、人大金仓、GaussDB、OceanBase中间件有东方通、宝兰德、金蝶天燕。每一层都有多种选择组合起来是一个巨大的矩阵。不同组合下同样的故障表现可能完全不同异常场景测试帮你搞清楚“这套组合的脆弱点在哪里”。第三信创项目通常涉及关键信息基础设施。政务、金融、能源、交通领域的信创系统本质上都是“不能停”的业务。停机十分钟可能就是生产事故。异常场景测试的目标不是“不出问题”而是“出了问题知道会发生什么、知道怎么快速恢复、知道数据不会丢”。所以我把信创测试中异常场景设计的目标概括成一句话在故障发生时系统能不能给出可预期的、安全的、可恢复的响应。2. 异常场景的分类体系先建立框架再动手2.1 按故障注入层次分类做异常场景设计最怕的就是想到什么测什么今天测个断网明天测个杀进程用例之间没有体系。我用下来的经验是先按故障注入的层次建立分类框架再往每个框架里填具体场景。常用的分类方式是五层模型基础设施层故障电源中断、网络分区、磁盘IO异常、物理机宕机、时钟跳变、虚拟化层故障。操作系统层故障系统资源耗尽CPU、内存、句柄、线程数、内核Panic、关键进程被杀、文件系统只读、系统服务异常退出。中间件与应用服务器层故障应用容器崩溃、连接池耗尽、线程池拒绝、JVM堆内存溢出OOM、GC停顿过长。数据层故障数据库连接中断、主备切换失败、表空间满、事务回滚异常、数据文件损坏、缓存服务崩溃。依赖与外部接口故障第三方接口超时、下游服务不可用、消息队列积压、鉴权服务异常、文件传输中断。这个分类的好处在于故障注入点清晰责任边界也清晰。基础设施层故障通常要在机房或虚拟化平台层面模拟操作系统层故障需要在节点上执行特定命令数据层故障则集中在数据库和缓存层面。每一类故障都有对应的模拟工具和注入手法。2.2 按业务影响程度分类另一个维度是按故障对业务的影响程度来分类这个维度决定了用例的优先级和验收标准。我通常把异常场景分成三个量级可容忍级故障发生后系统能自动恢复或在秒级内完成切换业务基本无感知。比如某个非核心接口超时后自动重试成功、某个缓存节点宕机后其他节点接管。可恢复级故障发生后业务短暂中断但系统能在人工介入后恢复数据不丢失。比如应用进程崩溃后由守护脚本拉起、数据库主备切换后业务重新连通。不可恢复级故障发生后系统无法自动恢复必须依赖备份或者灾难恢复方案。这种场景在测试中也要测主要目的是验证容灾能力是否真正有效而不是期待系统能做到无缝恢复。这两个维度交叉起来就形成了一张异常场景设计矩阵。对每一类具体故障先确定注入层次再确定期望的业务影响等级最后针对性设计验证手段和通过标准。没有这个框架很容易出现“测了一堆场景但没有覆盖关键风险”的情况。3. 异常场景设计的方法与实操套路3.1 故障注入工具的选型设计异常场景之前先解决工具问题。做信创环境下的故障注入工具要能在国产CPU架构和国产操作系统上正常运行这一点是很多团队踩坑的重灾区。很多成熟的混沌工程工具依赖特定的内核模块或者x86指令集在鲲鹏或者飞腾上装不上或者装了之后某些能力失效。我实际用下来比较顺手的组合如下ChaosBlade阿里开源的混沌工程工具支持多架构和多平台在麒麟V10和统信UOS上都可以跑。它的CPU满载、内存占用、磁盘IO异常、网络延迟、丢包、进程杀灭、应用异常退出都做得比较成熟对主流中间件和数据库也有专门的故障注入能力。系统层操作命令用Linux原生的fork炸弹模拟进程数耗尽、dd模拟磁盘写满、tc模拟网络问题、kill杀进程。这些命令虽然“原始”但在信创环境下反而最可靠因为它不依赖第三方编译环境。数据库自带的高可用演练工具达梦的DMSQL、人大金仓的sys_switch等用于触发主备切换场景。自研脚本和探针针对具体业务场景写一些注入脚本比如向数据库连接池不断发起请求直到连接耗尽、向后端服务发送畸形报文触发解析异常。这类自研脚本虽然工程量大但最贴合业务场景。工具选型的核心原则是先保证能在目标环境上安装、运行、复现再追求功能的丰富性。我在一个项目里试过某款老牌混沌工程平台界面很漂亮功能很强大但在兆芯的机器上装完依赖库就缺了一大堆最后只能放弃改用脚本方式实现同样的效果。3.2 异常场景设计的六个维度有了工具之后异常场景怎么设计我总结出六个维度的设计思路每个场景至少要覆盖其中一个维度大多数有价值的场景是多个维度的组合资源耗尽CPU满载、内存耗尽、磁盘空间不足、文件句柄耗尽、连接池耗尽、线程池打满。这类场景的结果通常是服务不可用、新请求被拒绝或排队而系统应该保证不会因此崩溃或数据错乱。网络异常网络中断、网络延迟、丢包、抖动、DNS解析失败、带宽受限或拥塞。在信创环境中要特别注意国产中间件和数据库的通信方式差异有时网络异常会导致客户端与服务端之间的状态不一致。依赖故障下游接口超时、下游服务返回错误码、依赖组件如Redis、消息队列、NFS宕机。验证系统是否具备降级能力、熔断能力、超时兜底能力。数据异常脏数据、重复数据、超长数据、非法字符、空值、字段类型不匹配、主键冲突、数据文件损坏。这些数据层面的异常是测试中容易被忽略但影响极大的场景。进程与生命周期异常关键进程被误杀、进程僵死Zombie、进程启动失败、重复启动、系统的服务管理器如systemd无法拉起服务。实测中常见的问题是服务脚本没写对导致进程崩溃后拉不起来。时序与并发异常并发请求乱序、事务超时、分布式锁失效、消息重复消费、启动时多个组件同时抢同一资源。信创栈上由于组件版本差异时序问题尤其隐蔽。3.3 业务场景深挖异常场景从哪里来框架有了工具有了最终还是要往业务系统里灌。这个环节的核心是梳理业务的依赖链路和关键节点沿着链路逐一寻找“如果这里出了问题会发生什么”。具体操作时我习惯先拿到业务系统的架构图和核心业务流程然后逐层梳理依赖关系。比如一个典型的办公系统用户登录后发起一个审批流程这个流程依赖的可能是应用服务器、统一认证服务、消息队列、缓存、数据库、文件存储服务。那么异常场景就围绕这些依赖来设计用户登录时认证服务挂了系统能不能给出友好提示用户稍后重试能不能恢复审批流程提交时数据库连接失败业务是直接报错还是自动重试如果自动重试幂等性怎么保证缓存服务崩溃后系统是降级查数据库还是直接抛异常文件存储服务不可用时附件上传下载会怎样消息队列积压时业务流程还能不能继续还是被阻塞每个问题对应至少一条异常场景用例。这个环节不需要很高深的技术但对业务理解要求很高。我自己的做法是拉上业务负责人、开发负责人一起开“故障推演会”把关键业务流程在白板上逐条过一遍每条流程旁边写清楚“这一环挂了会怎样”。这样产出的异常场景用例比坐在工位上凭想象设计出来的用例扎实得多。4. 异常场景验证的完整流程设计与执行4.1 异常场景用例设计模板异常场景用例和功能用例最大的差异在于除了输入和预期结果它还要明确规定故障注入方式、故障持续时间、恢复步骤和验收指标。我在项目中使用的用例模板包含以下字段可以参考并根据实际项目调整。字段说明示例用例编号唯一标识AC-014场景名称简明描述场景数据库连接池耗尽后的服务降级验证前置条件环境、数据、状态准备系统已完成部署存在500个活跃用户在线业务正常运行故障描述注入什么故障数据库连接池最大连接数调低到50并通过并发查询快速占满连接池故障注入方法使用什么工具/命令数据库侧通过脚本发送200个并发查询请求占满连接池故障持续时间维持多久持续5分钟预期业务影响系统可接受的表现新增请求返回“系统繁忙请稍后重试”已登录用户的存量会话不受影响无数据丢失恢复步骤如何恢复关闭并发脚本等待连接池释放验证可以重新建立连接验收指标量化标准恢复时间不超过5分钟恢复后业务功能完整数据库数据一致性校验通过实际结果测试执行后填写实际为连接池占满后新请求报错超时持续约80秒但无数据错误恢复后功能正常这套模板的关键在于“预期业务影响”和“验收指标”这两个字段。很多团队在写用例时只关心“会不会挂”不明确挂到什么程度算可接受导致执行完的结果没法判定通过还是不通过。4.2 信创环境下的测试环境准备异常场景测试的环境准备和普通功能测试有明显区别因为故障注入本身会对环境造成破坏所以环境准备的第一原则是独立于日常开发测试环境并且具备可快速重建的能力。我在信创项目中通常采用虚拟机方式准备异常测试环境。在鲲鹏或飞腾的物理机上部署虚拟化平台为每套被测系统建立可快照的虚拟机。每次异常测试前做一个快照测完直接回滚保证环境的一致性。这种方式比物理机重建快得多也方便反复验证同一场景。环境准备的具体清单包括被测系统完整部署包括数据库、缓存、中间件、应用服务等组件。监控工具部署到位。至少要有系统资源监控CPU、内存、磁盘、IO、应用日志收集、数据库会话监控、网络连通性监控。没有监控数据异常测试做完都不知道当时发生了什么。数据准备。每个场景执行前恢复一套基线数据保证测试的独立性。特别是数据库停机类的场景数据备份和恢复脚本必须提前准备好。监控和压测工具的客户端单独部署不能和被测系统放在同一台机器上避免故障注入影响到测试工具本身。还有一个很容易忽略的点异常测试环境一定要和生产环境保持软件版本一致。我遇到过一套系统测试环境用的是补丁较新的版本在异常场景下表现良好但生产环境还是老版本同样场景下直接崩溃。版本不一致会让测试完全失去参考价值。4.3 分阶段执行的实操流程信创环境下的异常场景测试我通常按四个阶段推进第一阶段基线确认。先不在系统上做任何故障注入完整跑一遍核心业务的冒烟用例确认当前状态下系统正常运行、监控数据正常采集、数据基线已就绪。这一步花不了多少时间但非常关键。如果基线本身就不稳定后面所有异常测试的结果都没法归因。第二阶段单点故障注入。按用例逐个执行一次只注入一种故障。比如先测CPU满载对系统的影响测完恢复再测磁盘写满测完恢复再测数据库连接中断。单点故障的测试是基础能帮你定位每个单点风险的具体表现。第三阶段组合故障注入。两个或三个故障同时注入或者按顺序叠加。比如数据库主备切换的同时网络发生抖动CPU满载的情况下应用进程被误杀。组合故障更接近真实的生产事故但定位问题也更难。这个阶段一定要有快速恢复预案一旦系统起不来能及时回滚环境不影响整体测试进度。第四阶段恢复验证与回归。每个场景执行完毕后必须验证系统恢复到正常状态并且数据一致性校验通过。数据一致性的校验方法根据业务来定一般包括数据库对比关键表记录数、业务链路跑通、日志不再报错。这个阶段做完一个场景才算真正闭环。按照这个流程执行异常测试的节奏会非常清晰。我有一个项目执行异常场景测试用了大概六周时间前面两周做框架和用例设计中间三周执行最后一周做问题复测和总结。如果跳过设计阶段直接开始测大概率会在执行中不断返工反而更慢。5. 典型信创异常场景实战案例5.1 场景一国产数据库主备切换后的应用恢复验证这个场景在信创测试中出现频率极高。国产数据库普遍以主备模式部署主库故障后触发备库接管但应用侧能否在切换过程中保持可用或者快速恢复才是关键问题。我们的设计思路是在业务正常运行状态下通过达梦数据库的管理命令直接切换主备角色模拟主库异常。同时提前在应用侧发起一组业务操作比如连续提交表单观察切换过程中请求的响应情况。切换完成后验证应用是否能够自动重新建立与数据库的连接数据库两端的数据是否一致。实测中比较容易发现的问题有三个一个是应用侧数据库连接池对主备切换的感知能力不足切换后连接池仍持有旧的主库连接需要重启应用才能恢复一个是切换过程中新提交的事务出现丢失原因是应用的提交逻辑没有做事务超时和重试处理还有一个是主备切换后数据校验发现部分自增主键冲突这是两个节点分别生成了相同的ID序列导致的。针对这些问题我们的修复方向是应用侧数据库连接池配置增加探活和重建机制事务提交增加超时重试和幂等控制数据库侧检查自增主键的步进和偏移配置是否跨节点一致。每条修复对应一条回归用例验证修完之后同样的切换场景不会再引发同类问题。5.2 场景二国产操作系统下磁盘写满的连锁反应磁盘写满是一个很朴素的异常场景但在信创环境下引发的连锁反应远比想象中严重。我们在麒麟V10环境下模拟磁盘空间耗尽把日志分区写满观察系统的表现结果触发了三张问题清单。第一个问题是一条链式的日志分区写满后应用服务写入日志失败日志系统开始报错并占用更高CPU随后整个应用进程被拖垮。这里暴露的是日志组件的容错能力太差没有对磁盘写入失败做出降级处理。第二个问题是数据库服务在磁盘写满情况下直接进入只读模式并拒绝所有写操作。从数据库安全角度看这是合理的但应用侧并没有针对写入失败做任何感知大批业务请求出现超时错误前端页面加载时间骤增。第三个问题比较隐蔽由于日志和数据混放在同一个磁盘分区日志写满直接挤占到了数据库的有效空间导致数据库的可用空间比预期少了很多。在设计分区时没有做空间隔离这个风险就一直埋在那里。这个案例的教训是两方面的运维层面磁盘空间的分区规划要隔离日志、数据、临时文件应用层面每个组件都要对磁盘写入失败做好降级预案。异常测试的价值不在于验证系统“完美应对”故障而在于把“出问题时到底会发生什么”彻底搞清楚。5.3 场景三信创中间件的线程池异常与恢复东方通TongWeb、宝兰德这类国产中间件在信创项目中越来越常见但团队对它们的底层调优经验往往不如对Tomcat熟悉。我们曾经遇到过一个中间件线程池异常的案例过程非常有代表性。当时业务应用部署在东方通TongWeb上测试执行了一个“慢SQL导致线程池耗尽”的异常场景。我们通过构造一个耗时超过60秒的慢查询持续往中间件发送请求每个请求都会占用一个工作线程等待SQL返回。大约几百个请求发完中间件的线程池被打满后面所有请求都排队等待整个应用表现为“挂死”。恢复操作也比预想中费劲。我们一开始以为杀掉中间件进程重启就行但杀完进程后应用服务的状态文件没有清理干净重启后的中间件在恢复会话时反复报错最后只能把部署目录下的缓存和状态文件一并删除才恢复。这个恢复过程总共花了二十多分钟。后续我们基于这个场景做了两个改进一是应用侧为所有数据库访问配置了超时时间慢SQL不再无限期占用线程二是中间件增加了线程池满的告警并且约束了最大排队等待时间超过时间直接拒绝请求并返回友好错误。同时把恢复操作的步骤写得更为保守避免因为残留状态文件导致恢复时间失控。6. 验证结果判定与问题分析6.1 通过判定的三个层次异常场景测试跑完之后最重要的问题是“这个场景算过了还是没过”。我看到很多团队用“系统没死”作为唯一判定标准这远远不够。我个人在做验证结果判定时通常分三个层次来看第一层是安全性层即故障发生时系统有没有出现数据丢失、数据错乱、越权处理等安全性问题。这一条是硬底线任何涉及数据安全的问题都是一票否决。第二层是可用性层即故障发生期间系统的可用性下降到了什么程度。这里要区分“完全不可用”和“部分降级可用”。比如数据库挂了但缓存还在只读了服务还能用比如认证服务超时但允许已登录用户继续操作。部分降级可用在很多业务场景里是完全可以接受的。第三层是恢复性层即故障消除后系统能不能在预期时间内恢复到正常状态。恢复时间、恢复过程中是否需要人工干预、恢复后数据一致性是否保持都是判定要看的指标。一个异常场景的最终判定不是简单的通过与不通过而是基于这三个层次的综合评价。如果数据安全没问题可用性虽然下降但业务可接受恢复时间也满足要求这个场景就算通过。如果数据安全没问题但恢复需要重启所有应用、耗时超过预期那虽然算通过也要提出改进项。6.2 问题定位的排查思路异常场景测试中发现的问题往往带有环境因素和版本因素定位起来比普通功能缺陷更复杂。我把它分为三步走第一步看监控和日志。出现异常后第一件事不是翻代码而是对照时间线把监控指标和日志中对应的告警点标出来。例如CPU满载场景哪个时间段CPU达到峰值哪个服务在这个时间窗口报了什么错误日志里有没有堆栈信息。第二步复现与隔离。把同样的故障注入到独立环境按时间顺序逐步缩小范围。比如先怀疑是中间件配置问题就只替换中间件配置保留其他条件不变测试结果若有变化就能确认部分因果关系再怀疑是应用代码问题就把目标切换放在应用层。第三步定位根因与制定修复方案。这一步需要开发和运维协同。异常场景测试最忌讳的是只看表面现象就提修复措施。比如“系统变慢了”就直接加机器不一定能解决问题。需要分析出变慢是连接池问题、锁竞争问题、GC问题还是外部依赖问题再对症下药。6.3 异常测试报告怎么写才有价值异常场景测试报告和普通测试报告的差异在于它不只是记录“测了什么、过了没有”更重要的是明确风险边界、给出改进建议、沉淀恢复经验。我写报告的习惯是每个异常场景按这样组织场景说明故障是什么、在什么层次注入、环境是什么版本组合。实际表现故障发生到系统响应的完整时间线包括监控指标的峰值、错误日志的关键告警。影响评估数据安全影响、业务可用性影响、恢复难度和恢复耗时。根因初步分析导致异常表现的直接原因和根本原因判断。改进建议针对根因的修复手段、运维优化建议、需要重点回归的地方。遗留风险当前无法解决或者尚未验证的风险项后续怎么办。报告中最有价值的部分是“恢复经验”和“遗留风险”。恢复经验是指当线上真的出现同类故障时运维团队应该按照什么顺序、执行哪些命令、等待哪些指标恢复来快速止损。这部分在平时容易被忽略但在真正出事故时价值巨大。遗留风险则是让管理层清楚知道当前系统的哪些薄弱环节还在还需要多少投入来补齐。7. 常见问题排查与避坑指南7.1 信创环境下做异常测试最容易踩的坑异常场景测试做了几年踩的坑积累了不少分享几个印象最深的。第一个坑是环境差异导致测试结果失真。信创环境是多样性最强的环境CPU架构不一样、操作系统版本不一样、数据库小版本不一样同一个故障的表现可能完全不同。比如同一条网络丢包注入命令在x86环境和鲲鹏环境下的表现就有差异。要保证测试结论可用所有异常测试必须跑在与生产一致的架构和版本组合上这一点没有妥协空间。第二个坑是故障注入工具不支持目标架构强行安装导致环境损坏。有些混沌工具在x86上能正常编译到了ARM架构上就有兼容性问题。处理办法有两个优先选择跨平台支持成熟的开源工具比如ChaosBlade对实在无法适配的工具用原生命令直接替代效果往往更稳定。第三个坑是故障恢复了但数据一致性没校验直接把环境交给下一组测试。这种情况在高强度测试周期里经常发生。数据库经历了异常切换、应用经历了强制重启表面上都正常了但表数据可能已经出现了不一致。每个场景结束后一定要把数据校验和业务链路冒烟放在环境交接之前形成习惯动作。第四个坑是预期业务影响定义得太模糊。我在评审用例时经常会问一个问题这个场景的预期结果到底是什么如果回答只是“系统别挂”那这条用例的质量就很低。预期结果应该具体到比如“单次事务超时后可自动重试成功且无重复数据”“连接池占满后新请求在5秒内返回友好提示已受理业务不中断”。有明确的预期执行和判定才有依据。7.2 压测工具与监控工具的配套使用异常场景测试不是简单把故障注入进去看看反应它的执行质量很大程度取决于监控数据的完整度。没有监控做支撑你只能看到“系统崩了”这个结论看不到崩溃的过程和原因。我推荐的监控配套方案是三层系统层常用命令包括top查看CPU和内存、iostat查看磁盘IO、free查看内存使用、sar做历史性能数据采集、netstat和ss查看网络连接状况。这些命令在国产操作系统上都可以正常使用。应用层要看应用日志、访问日志、GC日志。特别是JVM应用的GC日志异常场景下很容易出现GC时间过长导致应用假死但普通的监控工具未必能看到需要提前开启日志输出。数据库层要看会话数、锁等待、慢查询、主备复制状态。达梦和人大金仓都有自己的管理工具和系统视图在执行故障注入前先搭好这些监控的采集通道。工具就位的方法是做异常测试前先跑一遍监控工具的验证用例确认在故障注入过程中监控数据能持续产出而且数据落盘的位置和被监控系统不在同一个磁盘分区避免磁盘满了之后连监控数据都丢。7.3 一份可以直接抄的避坑清单根据多个信创项目的执行经验我整理了一份高频异常测试避坑清单。这份清单不必照单全收但每一条背后都是实际踩过的坑。故障注入前先对被测系统做快照故障注入后优先回滚避免环境持续污染。磁盘分区隔离数据、日志、临时文件和监控采集避免单一分区的空间问题引发连锁故障。应用侧所有对外部依赖的访问都要配超时时间连接池配探活和重建机制。关键数据库服务切换类场景验证完成后必须做双向数据校验不能用单节点自检代替。中间件和服务实例的进程守护策略要提前验证不能只验证业务功能而忽略进程拉起逻辑。每类场景的执行时间要预留充足的恢复窗口不要排得太密场景之间至少要留出数据校验和日志归档的时间。异常测试过程中要安排专人盯监控发现系统进入异常状态时及时记录时间点不可等到场景结束了再补记录。测试用例的设计需要覆盖故障的检测、恢复、恢复后的回归验证三个环节少一个环节都不完整。日志采集级别适当提高特别要保留故障发生前后的完整堆栈和错误上下文。测试结束后错峰再分析不必现场深挖先把现场数据完整保留下来。最终输出物中除了缺陷清单还要包含每个场景的恢复步骤说明与验证报告这些后续可转化为运维应急手册体系化防范生产环境风险。最后再分享一个个人体会。异常场景测试在整个信创测试体系里表面上看起来是“制造问题”但本质上是在花小成本避免大事故。每次测试注入的故障都相当于提前预演一次生产事故把不可控的未知变成可控的预案。我见过不少团队在项目初期觉得异常场景测试“性价比不高”但经历过一次生产环境事故后的深夜紧急修复态度基本都会有转变。信创软件栈的稳定性和成熟度会持续迭代提升但变化本身就是风险来源异常场景测试不是一个阶段性的任务而是这套系统长期运行中应该一直保持的能力。 
长河君 · 2026/10/10 14:45:53 · 阅读 1.2k 信创测试中的异常场景设计与故障注入实战
1. 信创测试里的异常场景到底在测什么1.1 从一次真实故障说起先讲个我最近遇到的案例。某个单位做信创迁移把一套OA系统从x86Windows迁移到了麒麟V10鲲鹏920的国产化环境迁移完成后功能测试、性能测试全部通过系统顺利上线。结果上线第三天机房的一次例行UPS切换测试直接把这套系统打挂了。重启之后数据库连接池拒绝连接缓存服务无法恢复前端登录页一直转圈最后花了四十多分钟才人工恢复。这个案例非常典型。功能测试和性能测试都过了为什么一次电源切换就能把系统打垮原因其实不复杂信创迁移验收时几乎所有测试用例都聚焦在“正常情况下系统能不能跑”没有人认真设计过“异常情况下系统能不能扛”。UPS切换导致电力短暂中断服务器重启数据库和缓存之间发生了一次时序错乱——这个场景在功能用例里根本不存在于是恢复机制形同虚设。这里要明确一个概念软件测试里的异常场景指的是系统在非预期条件、故障条件、极端负载或外部干扰下表现出来的行为和恢复能力。信创测试中的异常场景则是在国产化软硬件栈国产CPU、国产操作系统、国产数据库、国产中间件之上重复叠加这些故障条件验证整个技术栈在“出问题时”是否还能守住底线。1.2 为什么信创测试尤其看重异常场景我接触过不少做信创适配的团队大家普遍的困惑是功能测试用例靠业务需求说明书就能梳理性能测试也有压测工具可以量化但异常场景总是感觉很虚不知道测什么、怎么测、测到什么程度算通过。这种困惑是正常的因为异常场景测试本来就比功能测试难设计、难执行、难量化。而在信创背景下又叠加了三层特殊矛盾第一国产化软硬件生态的成熟度还在爬坡期。国产CPU、操作系统、数据库在长期稳定性上与经过数十年打磨的传统成熟产品仍有差距。这不是说国产不行而是说测试策略要更保守、更严密。你在x86上跑三年不重启都没事的系统迁移到信创环境可能半年就会出现一次诡异的内存问题异常场景测试就是提前把这些风险挖出来的手段。第二信创栈的组合复杂度是乘数级的。CPU有鲲鹏、飞腾、龙芯、海光、兆芯、申威操作系统有麒麟、统信UOS、中科方德数据库有达梦、人大金仓、GaussDB、OceanBase中间件有东方通、宝兰德、金蝶天燕。每一层都有多种选择组合起来是一个巨大的矩阵。不同组合下同样的故障表现可能完全不同异常场景测试帮你搞清楚“这套组合的脆弱点在哪里”。第三信创项目通常涉及关键信息基础设施。政务、金融、能源、交通领域的信创系统本质上都是“不能停”的业务。停机十分钟可能就是生产事故。异常场景测试的目标不是“不出问题”而是“出了问题知道会发生什么、知道怎么快速恢复、知道数据不会丢”。所以我把信创测试中异常场景设计的目标概括成一句话在故障发生时系统能不能给出可预期的、安全的、可恢复的响应。2. 异常场景的分类体系先建立框架再动手2.1 按故障注入层次分类做异常场景设计最怕的就是想到什么测什么今天测个断网明天测个杀进程用例之间没有体系。我用下来的经验是先按故障注入的层次建立分类框架再往每个框架里填具体场景。常用的分类方式是五层模型基础设施层故障电源中断、网络分区、磁盘IO异常、物理机宕机、时钟跳变、虚拟化层故障。操作系统层故障系统资源耗尽CPU、内存、句柄、线程数、内核Panic、关键进程被杀、文件系统只读、系统服务异常退出。中间件与应用服务器层故障应用容器崩溃、连接池耗尽、线程池拒绝、JVM堆内存溢出OOM、GC停顿过长。数据层故障数据库连接中断、主备切换失败、表空间满、事务回滚异常、数据文件损坏、缓存服务崩溃。依赖与外部接口故障第三方接口超时、下游服务不可用、消息队列积压、鉴权服务异常、文件传输中断。这个分类的好处在于故障注入点清晰责任边界也清晰。基础设施层故障通常要在机房或虚拟化平台层面模拟操作系统层故障需要在节点上执行特定命令数据层故障则集中在数据库和缓存层面。每一类故障都有对应的模拟工具和注入手法。2.2 按业务影响程度分类另一个维度是按故障对业务的影响程度来分类这个维度决定了用例的优先级和验收标准。我通常把异常场景分成三个量级可容忍级故障发生后系统能自动恢复或在秒级内完成切换业务基本无感知。比如某个非核心接口超时后自动重试成功、某个缓存节点宕机后其他节点接管。可恢复级故障发生后业务短暂中断但系统能在人工介入后恢复数据不丢失。比如应用进程崩溃后由守护脚本拉起、数据库主备切换后业务重新连通。不可恢复级故障发生后系统无法自动恢复必须依赖备份或者灾难恢复方案。这种场景在测试中也要测主要目的是验证容灾能力是否真正有效而不是期待系统能做到无缝恢复。这两个维度交叉起来就形成了一张异常场景设计矩阵。对每一类具体故障先确定注入层次再确定期望的业务影响等级最后针对性设计验证手段和通过标准。没有这个框架很容易出现“测了一堆场景但没有覆盖关键风险”的情况。3. 异常场景设计的方法与实操套路3.1 故障注入工具的选型设计异常场景之前先解决工具问题。做信创环境下的故障注入工具要能在国产CPU架构和国产操作系统上正常运行这一点是很多团队踩坑的重灾区。很多成熟的混沌工程工具依赖特定的内核模块或者x86指令集在鲲鹏或者飞腾上装不上或者装了之后某些能力失效。我实际用下来比较顺手的组合如下ChaosBlade阿里开源的混沌工程工具支持多架构和多平台在麒麟V10和统信UOS上都可以跑。它的CPU满载、内存占用、磁盘IO异常、网络延迟、丢包、进程杀灭、应用异常退出都做得比较成熟对主流中间件和数据库也有专门的故障注入能力。系统层操作命令用Linux原生的fork炸弹模拟进程数耗尽、dd模拟磁盘写满、tc模拟网络问题、kill杀进程。这些命令虽然“原始”但在信创环境下反而最可靠因为它不依赖第三方编译环境。数据库自带的高可用演练工具达梦的DMSQL、人大金仓的sys_switch等用于触发主备切换场景。自研脚本和探针针对具体业务场景写一些注入脚本比如向数据库连接池不断发起请求直到连接耗尽、向后端服务发送畸形报文触发解析异常。这类自研脚本虽然工程量大但最贴合业务场景。工具选型的核心原则是先保证能在目标环境上安装、运行、复现再追求功能的丰富性。我在一个项目里试过某款老牌混沌工程平台界面很漂亮功能很强大但在兆芯的机器上装完依赖库就缺了一大堆最后只能放弃改用脚本方式实现同样的效果。3.2 异常场景设计的六个维度有了工具之后异常场景怎么设计我总结出六个维度的设计思路每个场景至少要覆盖其中一个维度大多数有价值的场景是多个维度的组合资源耗尽CPU满载、内存耗尽、磁盘空间不足、文件句柄耗尽、连接池耗尽、线程池打满。这类场景的结果通常是服务不可用、新请求被拒绝或排队而系统应该保证不会因此崩溃或数据错乱。网络异常网络中断、网络延迟、丢包、抖动、DNS解析失败、带宽受限或拥塞。在信创环境中要特别注意国产中间件和数据库的通信方式差异有时网络异常会导致客户端与服务端之间的状态不一致。依赖故障下游接口超时、下游服务返回错误码、依赖组件如Redis、消息队列、NFS宕机。验证系统是否具备降级能力、熔断能力、超时兜底能力。数据异常脏数据、重复数据、超长数据、非法字符、空值、字段类型不匹配、主键冲突、数据文件损坏。这些数据层面的异常是测试中容易被忽略但影响极大的场景。进程与生命周期异常关键进程被误杀、进程僵死Zombie、进程启动失败、重复启动、系统的服务管理器如systemd无法拉起服务。实测中常见的问题是服务脚本没写对导致进程崩溃后拉不起来。时序与并发异常并发请求乱序、事务超时、分布式锁失效、消息重复消费、启动时多个组件同时抢同一资源。信创栈上由于组件版本差异时序问题尤其隐蔽。3.3 业务场景深挖异常场景从哪里来框架有了工具有了最终还是要往业务系统里灌。这个环节的核心是梳理业务的依赖链路和关键节点沿着链路逐一寻找“如果这里出了问题会发生什么”。具体操作时我习惯先拿到业务系统的架构图和核心业务流程然后逐层梳理依赖关系。比如一个典型的办公系统用户登录后发起一个审批流程这个流程依赖的可能是应用服务器、统一认证服务、消息队列、缓存、数据库、文件存储服务。那么异常场景就围绕这些依赖来设计用户登录时认证服务挂了系统能不能给出友好提示用户稍后重试能不能恢复审批流程提交时数据库连接失败业务是直接报错还是自动重试如果自动重试幂等性怎么保证缓存服务崩溃后系统是降级查数据库还是直接抛异常文件存储服务不可用时附件上传下载会怎样消息队列积压时业务流程还能不能继续还是被阻塞每个问题对应至少一条异常场景用例。这个环节不需要很高深的技术但对业务理解要求很高。我自己的做法是拉上业务负责人、开发负责人一起开“故障推演会”把关键业务流程在白板上逐条过一遍每条流程旁边写清楚“这一环挂了会怎样”。这样产出的异常场景用例比坐在工位上凭想象设计出来的用例扎实得多。4. 异常场景验证的完整流程设计与执行4.1 异常场景用例设计模板异常场景用例和功能用例最大的差异在于除了输入和预期结果它还要明确规定故障注入方式、故障持续时间、恢复步骤和验收指标。我在项目中使用的用例模板包含以下字段可以参考并根据实际项目调整。字段说明示例用例编号唯一标识AC-014场景名称简明描述场景数据库连接池耗尽后的服务降级验证前置条件环境、数据、状态准备系统已完成部署存在500个活跃用户在线业务正常运行故障描述注入什么故障数据库连接池最大连接数调低到50并通过并发查询快速占满连接池故障注入方法使用什么工具/命令数据库侧通过脚本发送200个并发查询请求占满连接池故障持续时间维持多久持续5分钟预期业务影响系统可接受的表现新增请求返回“系统繁忙请稍后重试”已登录用户的存量会话不受影响无数据丢失恢复步骤如何恢复关闭并发脚本等待连接池释放验证可以重新建立连接验收指标量化标准恢复时间不超过5分钟恢复后业务功能完整数据库数据一致性校验通过实际结果测试执行后填写实际为连接池占满后新请求报错超时持续约80秒但无数据错误恢复后功能正常这套模板的关键在于“预期业务影响”和“验收指标”这两个字段。很多团队在写用例时只关心“会不会挂”不明确挂到什么程度算可接受导致执行完的结果没法判定通过还是不通过。4.2 信创环境下的测试环境准备异常场景测试的环境准备和普通功能测试有明显区别因为故障注入本身会对环境造成破坏所以环境准备的第一原则是独立于日常开发测试环境并且具备可快速重建的能力。我在信创项目中通常采用虚拟机方式准备异常测试环境。在鲲鹏或飞腾的物理机上部署虚拟化平台为每套被测系统建立可快照的虚拟机。每次异常测试前做一个快照测完直接回滚保证环境的一致性。这种方式比物理机重建快得多也方便反复验证同一场景。环境准备的具体清单包括被测系统完整部署包括数据库、缓存、中间件、应用服务等组件。监控工具部署到位。至少要有系统资源监控CPU、内存、磁盘、IO、应用日志收集、数据库会话监控、网络连通性监控。没有监控数据异常测试做完都不知道当时发生了什么。数据准备。每个场景执行前恢复一套基线数据保证测试的独立性。特别是数据库停机类的场景数据备份和恢复脚本必须提前准备好。监控和压测工具的客户端单独部署不能和被测系统放在同一台机器上避免故障注入影响到测试工具本身。还有一个很容易忽略的点异常测试环境一定要和生产环境保持软件版本一致。我遇到过一套系统测试环境用的是补丁较新的版本在异常场景下表现良好但生产环境还是老版本同样场景下直接崩溃。版本不一致会让测试完全失去参考价值。4.3 分阶段执行的实操流程信创环境下的异常场景测试我通常按四个阶段推进第一阶段基线确认。先不在系统上做任何故障注入完整跑一遍核心业务的冒烟用例确认当前状态下系统正常运行、监控数据正常采集、数据基线已就绪。这一步花不了多少时间但非常关键。如果基线本身就不稳定后面所有异常测试的结果都没法归因。第二阶段单点故障注入。按用例逐个执行一次只注入一种故障。比如先测CPU满载对系统的影响测完恢复再测磁盘写满测完恢复再测数据库连接中断。单点故障的测试是基础能帮你定位每个单点风险的具体表现。第三阶段组合故障注入。两个或三个故障同时注入或者按顺序叠加。比如数据库主备切换的同时网络发生抖动CPU满载的情况下应用进程被误杀。组合故障更接近真实的生产事故但定位问题也更难。这个阶段一定要有快速恢复预案一旦系统起不来能及时回滚环境不影响整体测试进度。第四阶段恢复验证与回归。每个场景执行完毕后必须验证系统恢复到正常状态并且数据一致性校验通过。数据一致性的校验方法根据业务来定一般包括数据库对比关键表记录数、业务链路跑通、日志不再报错。这个阶段做完一个场景才算真正闭环。按照这个流程执行异常测试的节奏会非常清晰。我有一个项目执行异常场景测试用了大概六周时间前面两周做框架和用例设计中间三周执行最后一周做问题复测和总结。如果跳过设计阶段直接开始测大概率会在执行中不断返工反而更慢。5. 典型信创异常场景实战案例5.1 场景一国产数据库主备切换后的应用恢复验证这个场景在信创测试中出现频率极高。国产数据库普遍以主备模式部署主库故障后触发备库接管但应用侧能否在切换过程中保持可用或者快速恢复才是关键问题。我们的设计思路是在业务正常运行状态下通过达梦数据库的管理命令直接切换主备角色模拟主库异常。同时提前在应用侧发起一组业务操作比如连续提交表单观察切换过程中请求的响应情况。切换完成后验证应用是否能够自动重新建立与数据库的连接数据库两端的数据是否一致。实测中比较容易发现的问题有三个一个是应用侧数据库连接池对主备切换的感知能力不足切换后连接池仍持有旧的主库连接需要重启应用才能恢复一个是切换过程中新提交的事务出现丢失原因是应用的提交逻辑没有做事务超时和重试处理还有一个是主备切换后数据校验发现部分自增主键冲突这是两个节点分别生成了相同的ID序列导致的。针对这些问题我们的修复方向是应用侧数据库连接池配置增加探活和重建机制事务提交增加超时重试和幂等控制数据库侧检查自增主键的步进和偏移配置是否跨节点一致。每条修复对应一条回归用例验证修完之后同样的切换场景不会再引发同类问题。5.2 场景二国产操作系统下磁盘写满的连锁反应磁盘写满是一个很朴素的异常场景但在信创环境下引发的连锁反应远比想象中严重。我们在麒麟V10环境下模拟磁盘空间耗尽把日志分区写满观察系统的表现结果触发了三张问题清单。第一个问题是一条链式的日志分区写满后应用服务写入日志失败日志系统开始报错并占用更高CPU随后整个应用进程被拖垮。这里暴露的是日志组件的容错能力太差没有对磁盘写入失败做出降级处理。第二个问题是数据库服务在磁盘写满情况下直接进入只读模式并拒绝所有写操作。从数据库安全角度看这是合理的但应用侧并没有针对写入失败做任何感知大批业务请求出现超时错误前端页面加载时间骤增。第三个问题比较隐蔽由于日志和数据混放在同一个磁盘分区日志写满直接挤占到了数据库的有效空间导致数据库的可用空间比预期少了很多。在设计分区时没有做空间隔离这个风险就一直埋在那里。这个案例的教训是两方面的运维层面磁盘空间的分区规划要隔离日志、数据、临时文件应用层面每个组件都要对磁盘写入失败做好降级预案。异常测试的价值不在于验证系统“完美应对”故障而在于把“出问题时到底会发生什么”彻底搞清楚。5.3 场景三信创中间件的线程池异常与恢复东方通TongWeb、宝兰德这类国产中间件在信创项目中越来越常见但团队对它们的底层调优经验往往不如对Tomcat熟悉。我们曾经遇到过一个中间件线程池异常的案例过程非常有代表性。当时业务应用部署在东方通TongWeb上测试执行了一个“慢SQL导致线程池耗尽”的异常场景。我们通过构造一个耗时超过60秒的慢查询持续往中间件发送请求每个请求都会占用一个工作线程等待SQL返回。大约几百个请求发完中间件的线程池被打满后面所有请求都排队等待整个应用表现为“挂死”。恢复操作也比预想中费劲。我们一开始以为杀掉中间件进程重启就行但杀完进程后应用服务的状态文件没有清理干净重启后的中间件在恢复会话时反复报错最后只能把部署目录下的缓存和状态文件一并删除才恢复。这个恢复过程总共花了二十多分钟。后续我们基于这个场景做了两个改进一是应用侧为所有数据库访问配置了超时时间慢SQL不再无限期占用线程二是中间件增加了线程池满的告警并且约束了最大排队等待时间超过时间直接拒绝请求并返回友好错误。同时把恢复操作的步骤写得更为保守避免因为残留状态文件导致恢复时间失控。6. 验证结果判定与问题分析6.1 通过判定的三个层次异常场景测试跑完之后最重要的问题是“这个场景算过了还是没过”。我看到很多团队用“系统没死”作为唯一判定标准这远远不够。我个人在做验证结果判定时通常分三个层次来看第一层是安全性层即故障发生时系统有没有出现数据丢失、数据错乱、越权处理等安全性问题。这一条是硬底线任何涉及数据安全的问题都是一票否决。第二层是可用性层即故障发生期间系统的可用性下降到了什么程度。这里要区分“完全不可用”和“部分降级可用”。比如数据库挂了但缓存还在只读了服务还能用比如认证服务超时但允许已登录用户继续操作。部分降级可用在很多业务场景里是完全可以接受的。第三层是恢复性层即故障消除后系统能不能在预期时间内恢复到正常状态。恢复时间、恢复过程中是否需要人工干预、恢复后数据一致性是否保持都是判定要看的指标。一个异常场景的最终判定不是简单的通过与不通过而是基于这三个层次的综合评价。如果数据安全没问题可用性虽然下降但业务可接受恢复时间也满足要求这个场景就算通过。如果数据安全没问题但恢复需要重启所有应用、耗时超过预期那虽然算通过也要提出改进项。6.2 问题定位的排查思路异常场景测试中发现的问题往往带有环境因素和版本因素定位起来比普通功能缺陷更复杂。我把它分为三步走第一步看监控和日志。出现异常后第一件事不是翻代码而是对照时间线把监控指标和日志中对应的告警点标出来。例如CPU满载场景哪个时间段CPU达到峰值哪个服务在这个时间窗口报了什么错误日志里有没有堆栈信息。第二步复现与隔离。把同样的故障注入到独立环境按时间顺序逐步缩小范围。比如先怀疑是中间件配置问题就只替换中间件配置保留其他条件不变测试结果若有变化就能确认部分因果关系再怀疑是应用代码问题就把目标切换放在应用层。第三步定位根因与制定修复方案。这一步需要开发和运维协同。异常场景测试最忌讳的是只看表面现象就提修复措施。比如“系统变慢了”就直接加机器不一定能解决问题。需要分析出变慢是连接池问题、锁竞争问题、GC问题还是外部依赖问题再对症下药。6.3 异常测试报告怎么写才有价值异常场景测试报告和普通测试报告的差异在于它不只是记录“测了什么、过了没有”更重要的是明确风险边界、给出改进建议、沉淀恢复经验。我写报告的习惯是每个异常场景按这样组织场景说明故障是什么、在什么层次注入、环境是什么版本组合。实际表现故障发生到系统响应的完整时间线包括监控指标的峰值、错误日志的关键告警。影响评估数据安全影响、业务可用性影响、恢复难度和恢复耗时。根因初步分析导致异常表现的直接原因和根本原因判断。改进建议针对根因的修复手段、运维优化建议、需要重点回归的地方。遗留风险当前无法解决或者尚未验证的风险项后续怎么办。报告中最有价值的部分是“恢复经验”和“遗留风险”。恢复经验是指当线上真的出现同类故障时运维团队应该按照什么顺序、执行哪些命令、等待哪些指标恢复来快速止损。这部分在平时容易被忽略但在真正出事故时价值巨大。遗留风险则是让管理层清楚知道当前系统的哪些薄弱环节还在还需要多少投入来补齐。7. 常见问题排查与避坑指南7.1 信创环境下做异常测试最容易踩的坑异常场景测试做了几年踩的坑积累了不少分享几个印象最深的。第一个坑是环境差异导致测试结果失真。信创环境是多样性最强的环境CPU架构不一样、操作系统版本不一样、数据库小版本不一样同一个故障的表现可能完全不同。比如同一条网络丢包注入命令在x86环境和鲲鹏环境下的表现就有差异。要保证测试结论可用所有异常测试必须跑在与生产一致的架构和版本组合上这一点没有妥协空间。第二个坑是故障注入工具不支持目标架构强行安装导致环境损坏。有些混沌工具在x86上能正常编译到了ARM架构上就有兼容性问题。处理办法有两个优先选择跨平台支持成熟的开源工具比如ChaosBlade对实在无法适配的工具用原生命令直接替代效果往往更稳定。第三个坑是故障恢复了但数据一致性没校验直接把环境交给下一组测试。这种情况在高强度测试周期里经常发生。数据库经历了异常切换、应用经历了强制重启表面上都正常了但表数据可能已经出现了不一致。每个场景结束后一定要把数据校验和业务链路冒烟放在环境交接之前形成习惯动作。第四个坑是预期业务影响定义得太模糊。我在评审用例时经常会问一个问题这个场景的预期结果到底是什么如果回答只是“系统别挂”那这条用例的质量就很低。预期结果应该具体到比如“单次事务超时后可自动重试成功且无重复数据”“连接池占满后新请求在5秒内返回友好提示已受理业务不中断”。有明确的预期执行和判定才有依据。7.2 压测工具与监控工具的配套使用异常场景测试不是简单把故障注入进去看看反应它的执行质量很大程度取决于监控数据的完整度。没有监控做支撑你只能看到“系统崩了”这个结论看不到崩溃的过程和原因。我推荐的监控配套方案是三层系统层常用命令包括top查看CPU和内存、iostat查看磁盘IO、free查看内存使用、sar做历史性能数据采集、netstat和ss查看网络连接状况。这些命令在国产操作系统上都可以正常使用。应用层要看应用日志、访问日志、GC日志。特别是JVM应用的GC日志异常场景下很容易出现GC时间过长导致应用假死但普通的监控工具未必能看到需要提前开启日志输出。数据库层要看会话数、锁等待、慢查询、主备复制状态。达梦和人大金仓都有自己的管理工具和系统视图在执行故障注入前先搭好这些监控的采集通道。工具就位的方法是做异常测试前先跑一遍监控工具的验证用例确认在故障注入过程中监控数据能持续产出而且数据落盘的位置和被监控系统不在同一个磁盘分区避免磁盘满了之后连监控数据都丢。7.3 一份可以直接抄的避坑清单根据多个信创项目的执行经验我整理了一份高频异常测试避坑清单。这份清单不必照单全收但每一条背后都是实际踩过的坑。故障注入前先对被测系统做快照故障注入后优先回滚避免环境持续污染。磁盘分区隔离数据、日志、临时文件和监控采集避免单一分区的空间问题引发连锁故障。应用侧所有对外部依赖的访问都要配超时时间连接池配探活和重建机制。关键数据库服务切换类场景验证完成后必须做双向数据校验不能用单节点自检代替。中间件和服务实例的进程守护策略要提前验证不能只验证业务功能而忽略进程拉起逻辑。每类场景的执行时间要预留充足的恢复窗口不要排得太密场景之间至少要留出数据校验和日志归档的时间。异常测试过程中要安排专人盯监控发现系统进入异常状态时及时记录时间点不可等到场景结束了再补记录。测试用例的设计需要覆盖故障的检测、恢复、恢复后的回归验证三个环节少一个环节都不完整。日志采集级别适当提高特别要保留故障发生前后的完整堆栈和错误上下文。测试结束后错峰再分析不必现场深挖先把现场数据完整保留下来。最终输出物中除了缺陷清单还要包含每个场景的恢复步骤说明与验证报告这些后续可转化为运维应急手册体系化防范生产环境风险。最后再分享一个个人体会。异常场景测试在整个信创测试体系里表面上看起来是“制造问题”但本质上是在花小成本避免大事故。每次测试注入的故障都相当于提前预演一次生产事故把不可控的未知变成可控的预案。我见过不少团队在项目初期觉得异常场景测试“性价比不高”但经历过一次生产环境事故后的深夜紧急修复态度基本都会有转变。信创软件栈的稳定性和成熟度会持续迭代提升但变化本身就是风险来源异常场景测试不是一个阶段性的任务而是这套系统长期运行中应该一直保持的能力。