Q1 · 测试、质量与可靠性
测试、质量与可靠性
9 年考了 6 次，2025 上 / 2025 下 / 2026 上 连续三场都出——测试类是最大缺口。
一句话：用测试金字塔分层投入（底层便宜跑得快、顶层贵跑得慢），
再以故障注入验证系统在真实故障下的可靠性，
把缺陷挡在上线之前——而不是上线之后靠人工回归。
会考什么
六份真题原文
本页覆盖 9 年里的 6 处题目：测试与质量保障 5 次 + 可靠性 1 次。 近年趋势是连续三场都考（2025上、2025下、2026上），但考法在换壳： 通用测试方法 → 单元测试 → 性能测试 → 多模态智能测试。题目换名词，内核都是测试策略 + 质量度量 + 可靠性。
| 真题出处 | 题名 | 考查落点 |
|---|---|---|
| 2020 试题二 | 软件测试中缺陷管理 | 缺陷种类/级别/流程/度量 |
| 2023 试题二 | 软件的可靠性评价 | 可靠性模型与选择、MTBF/可用度 |
| 2024上 试题三 | 单元测试方法 | 静态/动态测试、覆盖标准、回归 |
| 2025上 试题二 | 软件测试方法 | 黑/白/灰盒、分层策略、混沌工程 |
| 2025下 试题三 | 软件系统的性能测试 | 测试类型、性能指标、瓶颈定位 |
| 2026上 试题四 | 多模态大模型智能测试（降权） | 页面识别/路径规划/执行/分析 |
权重依据 docs/真题分析.md：「测试与质量保障」9 年 5 次，2025上/2025下/2026上 连续 3 次；
「可靠性」1 次（2023）。两者的结论都归到本页。
2020 试题二 · 逐字原文
论软件测试中缺陷管理及其应用
围绕"论软件测试中缺陷管理及其应用"论题，依次从以下三个方面进行论述。
- 概要叙述你参与管理和开发的软件项目以及承担的工作。
- 详细论述常见的缺陷种类及级别，论述缺陷管理和基本流程。
- 结合你具体参与管理和开发的实际项目，说明是如何进行缺陷管理的。请具体说明实施过程及应用效果。
2023 试题二 · 逐字原文
论软件的可靠性评价
软件可靠性评价是软件可靠性活动的重要组成部分，既适用于软件开发过程，也可针对最终软件系统。
请围绕"论软件的可靠性评价"论题，依次从以下三个方面进行论述。
- 概要叙述你参与开发的软件项目以及你在其中所承担的主要工作。
- 说明可靠性模型有哪些，以及如何选择合适的可靠性模型。
- 具体阐述你参与开发的项目如何对选用的可靠性模型进行分析来进行可靠性评价的。
2024上 试题三 · 逐字原文
论单元测试方法及应用
单元测试（Unit Testing）是指对软件中的最小可测试单元或模块进行检查和验证，通过测试来发现该单元的功能不符合/不满足期望的情况和编码错误。单元测试中经常采用的测试方法包括静态测试、动态测试等。单元测试的工作一般由程序员自己完成。单元测试的要点是进行单元所有数据项的正确性、完善性测试，主要关注单元的算法细节和单元接口间流动的数据。
请围绕"单元测试方法及其应用"论题，依次从以下三个方面进行论述。
- 概要叙述你参与管理和开发的软件项目，以及你在其中所担任的主要工作。
- 结合你具体参与管理和开发的实际项目，详细论述单元测试中静态测试、动态测试方法的基本内容。
- 结合你具体参与管理和开发的实际项目，说明在单元测试过程中，如何确定白盒测试的覆盖标准，如何组织实施回归测试。
2025上 试题二 · 逐字原文
论软件测试方法及应用
软件测试是保证软件质量的重要手段，其目的是在软件投入运行之前，尽可能多地发现软件中的错误。随着软件系统的复杂度不断增加，软件测试方法也在不断发展和完善。常见的软件测试方法包括黑盒测试、白盒测试、灰盒测试等，测试类型涵盖单元测试、集成测试、系统测试、验收测试等多个层次。近年来，随着人工智能技术的发展，AI驱动的测试用例生成和智能化测试方法也逐渐成为研究和实践的热点。
请围绕"论软件测试方法及应用"论题，依次从以下三个方面进行论述。
- 概要叙述你参与管理和开发的软件项目以及你在其中所承担的主要工作。
- 详细论述常见的软件测试方法及其特点，说明如何根据项目特点选择合适的测试策略。
- 结合你具体参与的项目，说明在测试过程中采用了哪些测试方法，遇到了哪些问题以及如何解决的。
2025下 试题三 · 逐字原文
论软件系统的性能测试
软件系统的性能测试是验证系统在不同负载条件下的响应能力、稳定性和资源利用情况的关键质量保障活动。性能测试包括负载测试、压力测试、容量测试、稳定性测试等多种类型，通过模拟真实用户场景，发现系统性能瓶颈，为性能优化提供数据支撑。
请围绕"论软件系统的性能测试"论题，依次从以下三个方面进行论述：
- 概要叙述你参与管理和开发的软件项目以及你在其中所承担的主要工作。
- 详细论述性能测试的主要类型及其目的，说明性能测试的关键指标和测试方法。
- 结合你具体参与的项目，说明性能测试的实施过程、发现的性能瓶颈及优化措施。
2026上 试题四 · 逐字原文（降权保留）
论多模态大模型在移动智能测试框架中的应用
- 概要叙述你参与管理和开发的软件项目以及你在其中所承担的主要工作。
- 从框架的页面识别、规划测试路径、执行交互和分析几个层次说明各层作用。
- 阐述在管理和开发该系统过程中遇到的问题及解决办法。
2026上 刚考过，按「考试会避开重复」的规律降权——
不要把宝押在"移动端多模态测试框架"上，它只是包装。
真正反复考的是第一问（项目）+ 第三问（实践与问题解决），这两问任何一年都躲不开。
一句话讲清
内核只有三件事
不管题干是缺陷管理、单元测试、性能测试还是智能测试，论文要证明的都是同一件事： 我用一套分层的测试体系，在有限的人力下把缺陷尽量挡在上线之前，并用可度量的指标证明它有效。 测试金字塔决定"在哪一层投入"，缺陷管理与可靠性评价决定"怎么度量"，故障注入决定"可靠性不是嘴上说的"。
机制讲解
测试金字塔：为什么底层要多、顶层要少
测试金字塔的核心不是形状，是单位成本与反馈速度。同一批缺陷， 在单元测试层发现只需毫秒级的一行断言；拖到端到端层才被发现，要起完整环境、走完整链路， 耗时几十秒还可能因为环境抖动误报。越往上，单次执行越贵、定位越慢、越不可靠。 所以合理的策略是：底层用例铺得最广，往上一层比一层少。
反过来的形状叫"冰淇淋甜筒"：单元测试稀稀拉拉，端到端用例堆成山。 表面看覆盖率数字不低，实则回归一次要几十分钟，失败后要人工翻日志才能定位， 最后团队干脆不敢跑回归——测试体系名存实亡。
下面这个模拟器把三种投入方案的缺陷检出率、回归耗时和相对成本摆在一起对比。 拖动滑块，或者直接点下面的预设，看"不这么做会怎样"。
测试金字塔投入模拟
模型假设：缺陷分三类（逻辑 60%、接口 30%、流程 10%），各层按饱和曲线各自捕获对应类别
单元测试
0
契约/集成
0
端到端
0
缺陷检出率
0%
缺陷逃逸率
0%
单次回归耗时
0s
相对成本
0
这个模拟器是怎么算的代码
三行模型，每行对应一个真实机制：
// ① 每一层按饱和曲线捕获对应类别的缺陷：用例越多，边际收益越低
检出(层) = 1 − e^(−用例数 ÷ 该层系数)
// ② 各层独立，未捕获的部分就是逃逸到线上或人工回归的缺陷
逃逸率 = 0.6 × 逻辑未捕获 + 0.3 × 接口未捕获 + 0.1 × 流程未捕获
// ③ 越上层越贵：单次执行成本与定位成本都随层次上升
回归耗时 = 单元×0.02s + 契约×0.6s + 端到端×25s点"冰淇淋甜筒"会看到：检出率反而更低，回归耗时和成本却成倍上涨—— 这就是"用例堆在顶层"的代价。
注意：这是教学模拟，系数是示意值不是实测。论文里只能引用真实测得的数字， 不能引用本页模拟器里的数字。
不这么做会怎样
| 方案 | 缺陷检出率 | 回归耗时 | 后果 |
|---|---|---|---|
| 合理金字塔 | ~91% | ~3 分钟 | 回归敢跑、失败能快速定位 |
| 冰淇淋甜筒 | ~39% | ~10 分钟 | 检出更低、更慢、更贵，团队弃跑回归 |
| 几乎不测 | ~0% | — | 缺陷全部逃逸到线上，修复成本按阶段放大 |
缺陷发现得越晚，修复越贵。业界经验是：需求阶段一个缺陷的修复成本记为 1，
编码阶段约 6~10，上线后可能到 100。测试金字塔的全部意义，就是把缺陷往左边推。
落到我们平台
映射到 fazi 的取舍
| 测试层次 | 落在 fazi 哪里 | 取舍 |
|---|---|---|
| 单元测试 | 存证哈希校验、报名库存扣减、权限判定的纯逻辑（Go testing） | 核心模块要求分支覆盖 ≥80%，其余不设硬门限 |
| 契约测试 | 前后端之间锁死 Gin 接口的请求/响应结构 | 共享一份接口样例，任一方破坏即失败 |
| 性能测试 | 抢课秒杀、法律问答读并发（自研 Go 压测工具分阶段加并发） | 不引入重型压测平台，一人全栈维护不动 |
| 故障注入 | 预发环境杀容器实例、注入连接超时与网络延迟 | 验证网关的超时/重试/快速失败是否真生效 |
两个必须写进论文的取舍：
- 不追覆盖率数字。整体自动化覆盖率不足 60% 是主动接受的不足， 与其写一堆无断言的形式化用例凑数，不如把覆盖压到真正会出事的模块上。
- 测试工具不选商业重型。没有专职测试团队，落地的只有 Go 原生 testing + httptest、 Vue 侧单测、契约测试和混沌注入，够用且一人能维护。
完整论文
六段全文
摘要 300–330 字，正文 P1–P6 合计 2000–2500 纯汉字。P1 逐字抄 essay-common.md，P6 换展望句。
软件测试与质量保障 · 全文（点击展开）
摘要
2025年3月，我作为河南省法律咨询协会唯一的全栈架构师，主导建设了协会数字平台。该项目面向协会500名常用会员及未来3000名潜在用户，涵盖信息发布、社交系统、电子存证、培训报名、法律智能咨询五大模块。我在项目中承担需求分析、架构设计、编码实现、部署运维的全部技术职责。
本文以该项目为例，讨论了软件测试与质量保障在实际项目中的应用。文章首先介绍项目背景和软件测试与质量保障的基本概念，然后详细阐述我们在架构设计、技术选型、问题解决等方面的具体实践，最后总结项目经验和不足。
通过软件测试与质量保障的有效应用，平台于2026年6月上线，法律问答Recall@20达0.92，P95响应380毫秒，缓存命中率92%，可用性99.95%，MTTR从45分钟降至8分钟。实践表明，在协会资源支持下，一人全栈架构师借助云托管服务和AI辅助开发，可以交付生产级法律数字化平台。
一、项目背景
河南省法律咨询协会成立于2004年，现有理事119名、法学专家62名、律师团成员78名、讲师团成员69名，承担法制宣传、法律培训、法律咨询、调解仲裁等职能。协会原有官网仅能发布新闻，会员管理、法律咨询、电子存证依赖线下和微信群，数据分散、效率低下。协会服务对象中有大量基层群众和中小微企业，法律术语看不懂、流程搞不清、律师咨询门槛高，维权成本居高不下。
2025年3月，协会理事会决定建设数字平台，并给予充分资源支持。我作为协会唯一的全栈架构师，承担从需求分析、架构设计、编码实现到部署运维的全部技术职责。平台以"fazi协会数字平台"为中心，涵盖信息发布、社交系统、电子存证、培训报名、法律智能咨询五大模块。前端采用 Nuxt 4 SSR + Vue 3.5 + Tailwind 4，后端采用 Go 1.26 + Gin + pgx 手写 SQL，数据库 PostgreSQL 18，部署在云托管容器服务上。平台常用用户500人，未来半年潜在用户3000人，峰值QPS约800。
技术选型上，我基于"一人全栈、生产级标准"原则做了三个关键决策：一是采用云托管服务替代自建中间件，把运维精力留给业务；二是以 PostgreSQL 18 + pgvector 作为统一数据平台，同时承载关系数据、向量检索、JSONB 文档和全文检索；三是引入 Claude Code / Vibe Coding 辅助开发，提升一人开发效率。协会在法律知识库、律师资源、经费预算上给予全力支持，使我能够专注于架构决策和业务实现。
二、理论概述
软件质量是软件满足规定需求和隐含需求的能力总和，质量保障贯穿需求、设计、编码、测试到运维的全生命周期，核心是尽可能早地预防和发现缺陷。测试是最直接的手段，目的不是证明程序正确，而是在投产前尽可能多地暴露错误。按是否可见内部结构，测试分为黑盒、白盒和灰盒：黑盒基于规格设计用例，常用等价类划分、边界值分析和场景法；白盒基于代码结构，追求语句、判定、条件、路径乃至 MC/DC 覆盖；灰盒兼顾接口与集成点。按被测对象的层次，又分为单元、集成、系统、验收四类，共同构成测试金字塔——底层用例最多、执行最便宜、反馈最快，越往上用例越少、单次越贵、定位越慢。此外，可靠性评价用 MTTF、MTBF 和可用度衡量系统在规定条件下持续无失效运行的能力，并可用 GO 模型等可靠性增长模型拟合测试期故障数据，预测是否达到发布门限。测试策略的制定应基于风险，把有限用例优先投到变更频繁、故障影响大的模块；缺陷管理则需明确发现、提交、确认、分配、修复、回归、关闭的流程，并按致命、严重、一般、提示四级设定处理时效与责任人。
三、实践一 · 分层测试与回归
在平台建设中，我以测试金字塔指导分层投入，把测试尽量左移。后端基于 Go 原生 testing 与 httptest 编写表驱动单元测试，覆盖存证哈希校验、报名库存扣减、权限判定等纯逻辑；前端基于 Vue 3.5 组件测试覆盖表单校验和状态流转；前后端之间用契约测试锁定 Gin 接口的请求响应结构。覆盖率分两档：核心模块要求分支覆盖不低于 80%，其余模块不设硬门限，以免为凑数写无断言的形式化用例。回归测试分两级，提交前只跑受影响包的单元与契约用例，控制在两分钟内；发版前跑完整套件。契约测试共享一份接口样例，任一方破坏约定立即失败，解决了接口改了而消费方不知情的问题。静态测试方面，关键提交必须经过代码审查，并接入静态检查扫描编码规范与潜在缺陷；动态测试方面，核心逻辑除分支覆盖外还补充边界值与异常路径用例，确保报满、超时、并发扣减等分支都被真正执行。存在的问题是，整体自动化覆盖率仍不足 60%，部分一次性脚本和运维代码未纳入，只能靠人工回归兜底。
四、实践二 · 性能测试与瓶颈定位
平台中最可能被压垮的是培训报名的抢课场景和法律问答的读并发。我没有引入重型压测平台，而是用自研的 Go 压测工具，按 50、100、200、400 并发分阶段递增，记录 P95、P99、吞吐和错误率，坚持先测出干净基线再定位瓶颈。第一轮压测暴露三个问题：抢课接口在名额报满后仍反复回源数据库，慢 SQL 拖长响应；问答检索每次重新计算向量近似，占用大量 CPU；网关到上游的连接未复用，产生无谓的建连开销。针对它们我做了三件事：用唯一约束加乐观更新实现库存扣减，把超卖交给数据库保证；对热点问答结果引入进程内缓存并设置短过期时间；给网关配置全局连接池并复用 Transport。性能测试按类型分工：用负载测试确认预期负载下 P95 达标，用压力测试找出系统崩溃点，用稳定性测试长时间运行观察内存与连接是否泄漏。优化后 P95 稳定在 380 毫秒，缓存命中率 92%。这套方法让我们在优化前后拿到同口径的对照数据，避免把环境波动误当成优化效果。
五、实践三 · 可靠性评价与故障注入
可靠性不能只靠上线前的测试拍胸脯，我把它做成可度量的闭环。参照可靠性评价流程，先设定核心接口可用度不低于 99.9% 的目标，再收集测试期故障数据，用 GO 模型拟合当前可靠性水平与发布门限的差距。为验证真实故障下的表现，我在预发环境做混沌注入：随机杀掉一个容器实例，注入数据库连接超时和网络延迟，观察网关的超时、重试与快速失败是否按预期生效。第一次注入时，单实例宕机造成约 5 秒窗口内近半请求失败，这正是后来补齐重试与熔断的依据。缺陷管理上，我按致命、严重、一般、提示四级定义缺陷，约定致命当日响应、严重当迭代修复，并跟踪缺陷密度、检出率与逃逸率。在模型选择上，我按假设与项目特征的匹配度、可用数据类型、预测精度和参数可行性四项原则权衡，最终选用基于非齐次泊松过程的 GO 模型，而非假设初始故障数固定、每修复一个故障可靠性等量增长的 JM 模型。平台上线后，线上缺陷逃逸率保持在较低水平，MTTR 从 45 分钟降至 8 分钟，可用性达到 99.95%。
六、总结展望
本项目让我深刻体会到，在资源受限、单人全栈的现实约束下，架构决策的核心不是"用什么最先进的技术"，而是"在约束下做什么取舍"。通过云托管服务、PostgreSQL 统一数据平台和 AI 辅助开发，我把有限的精力集中在业务架构和核心模块上，交付了生产级平台。
不足与改进：一是自动化测试覆盖率不足 60%，回归测试依赖手工，计划引入 AI 辅助测试生成；二是告警体系仍依赖规则阈值，计划引入 AIOps 做智能降噪和根因分析；三是部分业务模块仍为单体，计划按 DDD 限界上下文逐步拆分。
未来，我将继续完善测试与质量保障体系，把覆盖率、缺陷逃逸率和可用度纳入每次迭代的度量，为协会会员和基层群众提供更稳定、更高质量的法律服务。
逐段拆解
每段写什么、写多长
| 段 | 讲什么 | 字数（纯汉字） |
|---|---|---|
| 摘要 | 项目一句话 + 【主题】做法 + 效果数据 | 300–330 |
| 一、项目背景 | 逐字抄定稿：协会职能、平台模块、技术栈、三个决策 | 459（定稿） |
| 二、理论概述 | 质量定义、测试分类（黑/白/灰盒）、测试层次、可靠性指标与模型 | 320–440 |
| 三、实践一 | 单元测试 + 契约测试 + 覆盖率标准 + 两级回归 | 320–440 |
| 四、实践二 | 性能测试执行、三个瓶颈、三项优化与结果 | 320–440 |
| 五、实践三 | 可靠性目标与模型拟合、混沌注入、缺陷分级与度量 | 320–440 |
| 六、总结展望 | 定稿总结 + 三条不足 + 主题展望句 | 200–300 |
三段实践 = 题干三问的地基。本题的实践一讲"怎么测"，实践二讲"性能怎么测"，
实践三讲"可靠性怎么评价、缺陷怎么管"。三问无论怎么组合，都能从这三段里取料重组。
答题要点
加分与扣分
题干三问 → 本文段落
| 题干问法 | 对应本文段 |
|---|---|
| 第 1 问：概要叙述项目与本人工作 | 第一段（项目背景） |
| 第 2 问：论述测试方法 / 可靠性模型 / 性能测试类型 | 测试方法→第二段；可靠性模型→第五段；性能测试类型→第四段 |
| 第 3 问：结合项目说明采用的方法、遇到的问题与解决办法 | 第三、四、五段（实践一/二/三） |
分年份对齐
| 真题 | 第 2 问（真题原文）→ 段 | 第 3 问（真题原文）→ 段 |
|---|---|---|
| 2020 试题二 缺陷管理 |
详细论述常见的缺陷种类及级别，论述缺陷管理和基本流程。 → 第二段（缺陷管理流程：发现→提交→确认→分配→修复→回归→关闭；四级分级与处理时效）＋第五段（四级定义、时效与密度·检出率·逃逸率）〔缺陷种类本文未单列〕 |
结合你具体参与管理和开发的实际项目，说明是如何进行缺陷管理的。请具体说明实施过程及应用效果。 → 第五段（四级分级、致命当日响应与严重当迭代修复、三项度量与逃逸率结论） |
| 2023 试题二 可靠性评价 |
说明可靠性模型有哪些，以及如何选择合适的可靠性模型。 → 第五段（GO 模型与 JM 模型对比枚举；按假设匹配度、可用数据类型、预测精度、参数可行性四原则选择） |
具体阐述你参与开发的项目如何对选用的可靠性模型进行分析来进行可靠性评价的。 → 第五段（设 99.9% 目标、收集测试期故障数据、GO 模型拟合与发布门限差距） |
| 2024上 试题三 单元测试 |
结合你具体参与管理和开发的实际项目，详细论述单元测试中静态测试、动态测试方法的基本内容。 → 第三段（静态：代码审查＋静态检查；动态：边界值与异常路径用例） |
结合你具体参与管理和开发的实际项目，说明在单元测试过程中，如何确定白盒测试的覆盖标准，如何组织实施回归测试。 → 第三段（核心模块分支覆盖≥80%、其余不设硬门限；回归两级：提交前跑受影响包两分钟内、发版前跑完整套件） |
| 2025上 试题二 软件测试方法 |
详细论述常见的软件测试方法及其特点，说明如何根据项目特点选择合适的测试策略。 → 第二段（黑/白/灰盒及其特点、按风险选策略）＋第三段（测试金字塔分层投入的落地） |
结合你具体参与的项目，说明在测试过程中采用了哪些测试方法，遇到了哪些问题以及如何解决的。 → 第三、四、五段（三类实践及各自的问题与解决） |
| 2025下 试题三 性能测试 |
详细论述性能测试的主要类型及其目的，说明性能测试的关键指标和测试方法。 → 第四段（负载测试/压力测试/稳定性测试及其目的；P95·P99·吞吐·错误率；分阶段递增压测） |
结合你具体参与的项目，说明性能测试的实施过程、发现的性能瓶颈及优化措施。 → 第四段（三个瓶颈、三项优化、P95 380ms） |
| 2026上 试题四 多模态测试（降权） |
从框架的页面识别、规划测试路径、执行交互和分析几个层次说明各层作用。 → 本文无对应材料（缺口，见下） |
阐述在管理和开发该系统过程中遇到的问题及解决办法。 → 第三、四、五段（通用「问题与解决」，非该框架专属） |
2026上 第 2 问在本页无对应材料。它问的是移动端多模态测试框架里「页面识别 / 规划测试路径 / 执行交互 / 分析」四层各自的作用，
与本人法律平台项目没有交集，P2–P5 都接不上，不能硬指到第三段。本页与
d02-AI应用架构与治理.html（AI 线，已并 2026上 试题四）均未备此素材；
真担心考到，须在 AI 线另补一段该框架的分层说明。
- 把测试金字塔的取舍写出来（为什么底层多、顶层少），这是区分"背书的"和"做过项目的"。
- 写出覆盖率的两档标准和"为什么整体不到 60%"——主动承认不足比假报 90% 可信。
- 性能段写出先测干净基线再优化的方法论，以及瓶颈的具体定位路径（慢 SQL、连接未复用）。
- 可靠性段写出故障注入的实测发现（5 秒窗口近半失败），再引出重试与熔断。
- 缺陷管理写出四级分级 + 处理时效 + 三个度量指标，并给出逃逸率结论。
- 技术栈严格落在 Go testing + httptest / Vue 单测 / 契约测试 / 混沌注入，别写没落地的商业工具。
- 写成"我们用了 JUnit、Selenium、Jenkins 搭 CI"——本平台没有这些，会露馅。
- 把可靠性、性能、功能测试各写一段却不提取舍和问题，三段变成产品说明书。
- 摘要效果句的指标与正文对不上，或编造没测过的技术数字（如虚假的覆盖率、QPS）。
- 第一段改动定稿一个字——校验脚本会直接判不合格。
背诵清单
考场上直接默这几句
- 测试的目的不是在投产前证明程序正确，而是尽可能多地暴露错误。
- 测试金字塔的核心是单位成本与反馈速度：越往上层，单次执行越贵、定位越慢、越不可靠。
- 核心模块要求分支覆盖不低于 80%，其余模块不设硬门限，避免为凑覆盖率写无断言用例。
- 回归分两级：提交前只跑受影响包，控制在两分钟内；发版前跑完整套件。
- 性能测试坚持先测出干净基线，再分阶段递增压力、定位瓶颈。
- 可靠性不靠拍胸脯，靠故障注入验证：杀实例、注入超时和延迟，看熔断重试是否真生效。
- 缺陷按致命、严重、一般、提示四级管理，跟踪密度、检出率、逃逸率三个指标。
- 缺陷发现得越晚，修复成本越高——测试体系的意义就是把缺陷往左推。
数据来源
哪些是真、哪些是固化取值
| 数据 | 来源 |
|---|---|
| 本页无实验数据 | 测试质量主题未建实验场，不编造没测过的具体数字 |
| 测试金字塔的检出率/耗时/成本 | 教学模拟（示意系数），非实测，不得写进论文 |
| 可用性 99.95%、MTTR 45→8 分钟 | 固化取值（essay-common.md 效果数据表，全页一致） |
| Recall@20 0.92、P95 380ms、缓存命中率 92% | 固化取值（同上；技术指标本可用实验场测真值，本题无实验场，仍沿用定稿） |
| 单实例宕机约 5 秒窗口近半失败 | 机制描述（与 demo1 端口耗尽实验的故障窗口同量级），不计入论文数字 |
论文里的技术细节要写成"机制"而非"数字"：说不清真值的地方，
写怎么做、为什么这么做、遇到什么问题，比编一个具体数字安全得多。