配置测试测什么
为「配置正确性」建立测试：渲染校验、启动自检、生产同构的集成冒烟，把配置错误挡在发布前。配置错误的特点是「测试全绿但部署就挂」——单测覆盖不到，必须在流水线里专门建三层验证。配置测试要和配置代码放在同一仓库、同一评审流程里。
基本信息
| 渲染层 | helm template / kustomize build 输出后跑 kubeconform 与策略检查 |
|---|---|
| 启动层 | 应用启动即校验配置（必填/范围/连通性），失败快速退出 |
| 集成层 | 用生产同构模板跑冒烟用例（登录、核心路径、依赖连通） |
| 负向用例 | 缺键、超范围、不可达依赖时的报错与退出码 |
| 归属 | 配置测试与被测配置同仓库评审 |
典型使用场景
- 渲染校验：模板与字段问题在 CI 拦住
- 启动自检：部署即验证必填与连通性
- 集成冒烟：真实路径走一遍
- 配置变更回归：改 values 即触发相关用例
- 新环境上线：先跑一遍同构校验再切流量
- 事故复盘：把犯过的配置错误补成用例
流水线组合
流水线组合
helm template app ./chart -f values-prod.yaml | kubeconform -strict -summary
./app --config-check # 应用自带的自检模式
# 负向用例：故意缺键、超范围，确认报错清晰且退出码非零三层验证对照
| 层 | 做法 | 拦截的问题 |
|---|---|---|
| 渲染层 | 渲染 + kubeconform/策略检查 | 模板与字段错误 |
| 启动层 | 自检模式 | 必填、范围、连通性 |
| 集成层 | 冒烟用例 | 拼装后的真实行为 |
配置的「错误分支」也要测：缺键、超范围、不可达依赖时的报错是否清晰。
退出码约定：自检失败必须非零退出，流水线才能拦得住。
测试与配置同源：用例引用同一份模板与默认值，避免两套真相。
配置测试也要能本地跑：开发者一条命令可以复现，才不会全靠 CI 排队等待。