19
验证领域
有针对性
按变更选择证据，而不是每次运行所有测试
CI
原生执行与准入控制
审查
验证证据
Verification Engine 的工作方式
Zof 根据变更、System Graph、风险和企业策略确定适当的验证。它不会对每次变更运行所有可能的测试。
- 01
解析变更
System Graph 确定受影响的系统、关键程度、适用控制及事件历史。
- 02
选择所需证据
策略和风险决定此次变更需要哪些验证领域提供证据。
- 03
执行并收集
确定性工具、专用验证系统、客户验证器、现有 CI 结果及获批模型共同生成证据。
- 04
封存并决策
结果封存到证据包中，并交给 Control Plane 作出可强制执行的决策。
将测试作为生成证据的验证
测试仍是起点。在 Zof 内部，每次测试都会成为控制决策可依赖的证据。
- 01
感知变更的选择
验证聚焦变更可能影响的范围，无需每次运行全部检查也能生成合适的证据。
- 02
十九个验证领域
在同一架构下涵盖单元、集成、端到端、API、安全、性能、负载、压力、耐久性、可扩展性、韧性、合规、回归、无障碍等验证。
- 03
确定性优先，仅在获批时使用 AI
确定性工具和专用验证系统提供证据。获批 AI 模型仅在策略允许时对结果和缺口进行推理。
- 04
不只是绿色勾选，更有证据
结构化结果、产物、追踪和日志封存到证据包中，并与决策关联。
团队衡量的成果
测试这个应用
将 Zof 指向一个应用，它便会生成、执行并维护覆盖用户流程、API 和集成的验证。
19
验证领域验证这次发布
每项有实质意义的变更都会在部署关卡放行前生成策略要求的证据。
审查
每次运行的证据对此服务进行压力测试
负载、压力、耐久性和韧性验证会检验普通测试无法触及的故障模式。
CI
原生执行进入生产环境前验证
合规和策略检查与功能验证同时运行，使受监管的变更具备自身的证明材料。
策略
选择执行内容
在团队现有工作环境中运行
Verification Engine 连接代码仓库、CI/CD 流水线和协作工具。现有测试套件及 CI 结果也可作为证据。
CI/CD 流水线
GitHub Actions、GitLab CI、Jenkins、CircleCI 和 Azure DevOps 触发验证并执行控制决策。
现有测试套件
Playwright、Cypress、Selenium 和单元测试框架继续运行，其结果转化为证据。
System Graph
每次运行都以实时架构上下文为依据，让 Zof 知道要验证什么以及为什么。
- 在您的控制层之下持续验证
- System Graph 在变更发布前映射依赖关系
- 用于合规审查的审计级证据
在您的技术栈中体验 Verification Engine
预约 Reliability Sprint：聚焦一个系统，查看它何处失效、何处保持稳定的证据。
- 策略要求时由人工审批
- 支持 Playwright、Cypress、Selenium
- 企业级 RBAC
运行测试，并理解失败的原因
每一次运行都会返回遥测数据、产物和根因分析，而不仅仅是一个绿色对勾。
借助可靠性分析，超越简单的通过/失败结论。
