内核测试策略

1）原则

金字塔奖杯平衡。基地-快速模块化和合同测试；上面-组件和集成；顶部-最小但有价值的e2e层。
Shift-left.越早捕捉缺陷（linter、静态分析、基于属性的）就越便宜。
Deterministic by design.管理时间、网络、随机和外部依赖关系。
质量经济学。任何测试都是"保险"：目标是尽量减少总成本（缺陷+伴随测试）。
风险导向。覆盖范围集中在业务不变性和协议（合同，平均性，一致性）上。

2）测试级别和责任区

2.1单位（模块化）

检查没有I/O的纯逻辑。
仅使用边框（端口/适配器）,将工厂用于数据。
快速（≤50 -100毫秒/测试），并行。

2.2合同（供应商↔消费者）

捕获服务之间的API合同（HTTP/gRPC/event）。
使用消费者驱动的方法：合同存储在VCS,在供应商CI中验证。
减少整合e2e的脆弱性。

2.3组件（在模块上方,带有实际存储）

我们使用容器中的实际DB/缓存 （Testcontainers）启动部分服务。
验证模式迁移、索引、事务、锁定。

2.4整合/系统（跨服务端到端路径）

在孤立的环境中提升服务集。
我们检查端到端不变性：事务性，逆向性，幂等性，错误处理。

2.5 E2E（最小"有价值"层）

现实生活中的协议和环境"如销售"，但场景集有限：付款→确认→布线；注册→验证→登录。
用于发布高风险幻灯片的发行和倒退。

3）可测试体系结构

端口/适配器（Hexagonal）。业务核心不知道HTTP/SQL。依赖项是通过接口实现的。
时间/随机注射。"Clock"，"Random"-成瘾；在测试中，锁定。
可配置的I/O抽象。队列，DB，KMS-通过具有测试实现的接口。
功能不变量。我们明确地表述后置条件和谓词-它们更容易测试和监测。

4）测试数据

工厂/售票员代替静态JSON fixtur：减少易碎性。
在测试之前（migrations → truncate → seed），偶数苹果酒和reset-hook DB。
案例目录："规范"，"边缘"，"错误"，"混乱"。
合成代替真实的PD：生成器，蒙面，隐私概况。

5）竞争和平均水平

比赛测试（种族）：竞争记录/储备/锁定。
检查等效密钥（例如'（operation, external_id）'：重复调用不会改变状态。
Retrai和taymauts：确保时间错误时的正确性。

dedupe_key = hash(op + external_id)
if exists(executions, dedupe_key): return previous_result else:
reserve(dedupe_key)
result = do_operation()
store(executions, dedupe_key, result)
return result

6）时间,时间,时区

所有存储时间均为UTC；测试使用"FixedClock"。
我们测试DST桉例（双打/跳过时钟），"本地日"窗口。
Taymauts用单调时钟进行测试；模拟NTP抖动。

7）可持续性和混乱

故障注射：网络错误、5xx、延迟、部分降级（缓存不可用）。
pre-prod环境中的混沌测试：关闭节点，超载队列，BGP/Anycast断裂（仿真）。
Fallback策略和UX降解：测试必须确认正确的"graceful degradation"。

8）生产力

用于关键算法的微型基准（带有CPU/alloc固定）。
负载配置文件：baseline （p50/p95）、压力（峰值）、延长（soak）用于内存泄漏。
倒退门：如果p95潜伏期比基线>X%差,则构建失败。

9）安全性和合规性

SAST/Lint：查找漏洞/反模式。
DAST/IAST：展位上的基本脚本（XSS/SQLi/SSRF样本）。
秘密扫描：代码和工件中没有密钥/密码。
隐私测试：在日志/跟踪中缺乏PD,遵守"同意管理",上载的匿名配置文件。

10）质量指标和SLO

Test pass rate和flaky index（不稳定测试/周数）。

• 90-100%用于关键核心模块，
• 外围设备70-80％（专注于不变量）。
• 发行风险评分：总和：关键文件的变化×基准的下降× 新的flaky。
• 预算错误：prod-SLO（上标/错误）捆绑与实验和发布频率。

11） CI/CD和门户

1.Lint/Format/TypeCheck

2.Unit + Property-based

3.Contract provider/consumer

4.Component (Testcontainers)

5.Integration + Perf smoke

6.Security (SAST/Secrets)

7.Build/Package + SBOM

8.Deploy to pre-prod + e2e + chaos smoke

门户：停止合同下降，潜伏期增加，新的关键漏洞。

缓存和缓存：通过并发和增量运行（通过修改的模块）加速管道。

12）Flaky测试： 检测和治疗

自动压制+法定人数（2/3运行）。
法拉克模式检测器：时间依赖性/随机/隐式期望。
SLA检疫：测试不会阻止发布，但必须在N日进行修复/重写。
临界路径的"核心"对小叶的零容忍度。

13）基于属性的突变和阶段测试

基于属性的：表达属性（可交换性、幂等性、单调性）,边界数据生成器。
Mutation testing：我们测量测试的"力量"（它们是否杀死所施加的突变）。
Fuzzing：协议/解析器/格式（JSON，Protobuf，CSV），尤其是在安全边界上。

prop "serialize/deserialize roundtrip":
forAll(randomModel()):
decode(encode(model)) == model

14）可观察性和与测试的联系

测试跟踪（在日志中为trace-id）：方便地回放到pre-prod中。
在表演运行中，指标的snapshots-作为人工制品存储。
记录控制：没有敏感字段,记录大小在SLO内。

15）文件和程序

测试手册：在哪里运行测试,如何编写工厂,如何更新合同。
Runbooks：事件中继、快速诊断、发布回滚。
不变量目录：系统保修和参考相关测试/异构体的列表。

16）建筑师支票清单

1.描述了核心不变性和关键路径?

2.有测试级别矩阵及其SLO（时间、稳定性）?

3.合同是否在供应商和消费者的CI中进行审查和验证?

4.在测试（FixedClock, Fault injector）中控制时间/咆哮/网络?

5.配置了Testcontainers/隔离的 DB,迁移是否经过验证?

6.有性能基线和回归门吗？

7.包括SAST/Secrets-scan和privacy log检查?

8.flaky记录在桉，是否有SLA要修复？

9.测试与prod-SLO和有缺陷的预算之间的关联是否透明?

10.记录了运行手册和不变量目录？

二.结论

内核测试策略不是工具列表，而是体系结构能力：可测试的设计，严格的层级层次结构，可管理的数据，容错性以及内置在CI/CD中的度量标准。按照所描述的做法，团队得到快速可靠的反馈，发布变得可预测和安全。