內核測試策略

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中的度量標準。按照所描述的做法，團隊得到快速可靠的反饋，發布變得可預測和安全。