EffortlessMetrics/ripr
GitHub: EffortlessMetrics/ripr
ripr 是一款面向 Rust 的静态测试预言机缺口分析器,通过 RIPR 模型在不运行变异体的情况下快速评估代码变更是否被现有测试有效区分。
Stars: 0 | Forks: 0
# ripr
[](docs/BADGE_POLICY.md)
[](docs/BADGE_POLICY.md)
[](https://github.com/EffortlessMetrics/ripr/actions/workflows/ci.yml)
[](https://codecov.io/gh/EffortlessMetrics/ripr)
[](https://crates.io/crates/ripr)
[](https://crates.io/crates/ripr)
[](https://docs.rs/ripr)
[](https://marketplace.visualstudio.com/items?itemName=EffortlessMetrics.ripr)
[](https://open-vsx.org/extension/EffortlessMetrics/ripr)
[](Cargo.toml)
[](https://www.rust-lang.org/)
`ripr` 帮助 Rust 开发人员和编程智能体回答一个起草阶段的测试
问题:
```
For the behavior changed in this diff, do the current tests appear to contain
a discriminator that would notice if that behavior were wrong?
```
`ripr` 是一个针对 Rust 工作区的静态 **Reachability-Infection-Propagation-Revealability (RIPR)**
暴露分析器。它读取已更改的 Rust 代码,构建
变异形态的静态探针,并报告现有测试是否看起来能够
到达、影响、传播、观察和区分已更改的行为。
它是 alpha 阶段的软件。当前版本可用于在
Pull Request 推进过程中提供快速反馈。它不是一个证明系统,
也不能替代真正的变异测试。
## 问题所在
覆盖率能告诉你代码执行了。
变异测试能告诉你测试套件是否捕获了代码的具体变异版本。
在日常开发中,团队通常需要更早地回答一个成本更低的问题:
```
This behavior changed. Do the nearby tests actually check the thing that changed?
```
这正是 `ripr` 的用武之地。
它旨在发现微弱或缺失的测试区分器,例如:
- 没有等值边界断言的边界更改
- 仅使用 `is_err()` 检查的错误路径更改
- 仅被冒烟断言覆盖的返回值更改
- 没有字段或对象断言的字段构造更改
- 没有 mock、事件、状态、持久化或指标预言机 的副作用
## ripr 的功能
`ripr` 分析 diff 并对已更改
行为的静态暴露证据进行分类。
它会寻找:
```
Reachability:
can a related test reach the changed code?
Infection:
could the changed expression alter local state or control?
Propagation:
could that altered state reach a visible boundary?
Revealability:
does a test oracle appear to observe the affected behavior?
```
然后报告当前测试是否似乎将更改的行为暴露给了
有意义的区分器。
## ripr 不做什么
`ripr` 不运行变异体。
它不报告 `killed` 或 `survived`,不证明测试的充分性,
不替代覆盖率,也不替代真正的变异测试。
将 `ripr` 用于快速、静态、起草阶段的预言机缺口反馈。当更改准备好
进行基于执行的确认时,请使用真正的变异运行器,
例如 `cargo-mutants`。
## ripr 的定位
```
coverage:
did this code execute?
ripr:
does changed behavior appear exposed to a meaningful test oracle?
mutation testing:
did tests fail when a concrete mutant was run?
```
`ripr` 是中间层:比变异测试更快、更有针对性,
比覆盖率更具有预言机意识。
## 覆盖率
上面的 Codecov 徽章仅指示执行表面的证据:即测试期间是否执行了代码路径。覆盖率不能证明测试的充分性、正确性、安全性或完整性。有关覆盖率信号测量内容和未涵盖的范围,请参阅 [覆盖率](docs/ci/coverage.md)。
## 快速入门
大多数用户从他们已经熟悉的界面开始。CLI 是每条路径背后的
共享引擎,但它不是编辑器或 CI 用户的必需首选界面。
| 用户类型 | 首次操作 | 主要文档 |
| --- | --- | --- |
| VS Code 用户 | 安装 `EffortlessMetrics.ripr`,打开一个 Rust 工作区,然后使用状态栏、问题、悬停和接缝操作。 | [快速入门](docs/QUICKSTART.md#vs-code-first-hour) |
| CI 用户 | 生成或复制建议的 GitHub 工作流。 | [快速入门](docs/QUICKSTART.md#ci-first-hour) |
| CLI 用户 | 运行 `ripr pilot --root .` 并为顶部接缝添加一个针对性测试。 | [快速入门](docs/QUICKSTART.md#cli-first-hour) |
| 智能体或审查者 | 从 `ripr agent status --root .` 或选定接缝的工作流数据包开始。 | [LLM 操作指南](docs/LLM_OPERATOR_GUIDE.md) |
要获取包含故障排除和已知限制在内的完整首小时路径,请阅读
[快速入门](docs/QUICKSTART.md)。
### VS Code
从 VS Code Marketplace 或 Open VSX 安装 `EffortlessMetrics.ripr`,然后
打开一个 Rust/Cargo 工作区。正常的编辑器安装不需要
`cargo install ripr`;扩展会从配置、捆绑或缓存的资源、GitHub Releases 或 PATH 解析服务器。
首先使用 `ripr` 状态栏项或 `ripr: Show Status`。然后检查 RIPR
问题诊断、悬停证据、`Write targeted test` 操作、智能体
交接命令以及 `Open Best Related Test`。
### CI
```
ripr init --ci github
```
生成的工作流默认是建议性的。它运行 `ripr pilot`,编写
RIPR 建议摘要,上传 pilot/workflow/agent/report/review 产物,
编写徽章 JSON,可选地上传 SARIF,并且不运行变异测试。
### CLI
从 crates.io 安装:
```
cargo install ripr
```
链接:
- crates.io:
- docs.rs:
用于从本仓库进行本地开发:
```
cargo install --path crates/ripr
```
`ripr` 目标是 Rust 2024 版本并需要 Rust `1.93` 或更新版本。
运行一个零配置的 pilot 数据包:
```
ripr pilot --root .
```
阅读 `target/ripr/pilot/pilot-summary.md`,为最顶部的
缺失区分器添加一个针对性测试,然后比较前后快照:
```
ripr check --root . --mode ready --format repo-exposure-json > target/ripr/pilot/after.repo-exposure.json
ripr outcome --before target/ripr/pilot/repo-exposure.json --after target/ripr/pilot/after.repo-exposure.json
```
对于智能体交接或审查自动化,编写匹配的验证数据包
和专注的回执:
```
mkdir -p target/ripr/agent
ripr agent verify --root . --before target/ripr/pilot/repo-exposure.json --after target/ripr/pilot/after.repo-exposure.json --json > target/ripr/agent/agent-verify.json
ripr agent receipt --root . --verify-json target/ripr/agent/agent-verify.json --seam-id --json --out target/ripr/agent/agent-receipt.json
```
对于本地智能体交接状态,请从以下开始:
```
ripr agent status --root .
ripr agent start --root . --seam-id --out target/ripr/workflow
ripr agent review-summary --root .
```
如果首次运行出现意外行为:
```
ripr doctor
```
`ripr.toml` 是可选的。当团队希望审查、版本化和调整它时,
`ripr init` 会实体化仓库本地策略;它不会解锁基础实用性。
## 示例发现
```
WARNING src/pricing.rs:88
Static exposure: weakly_exposed
Probe: predicate
Changed behavior:
if amount >= discount_threshold {
Evidence:
Reachability: related tests found
Infection: changed predicate can alter branch behavior
Propagation: branch appears to influence returned total
Revealability: tests assert returned values, but no equality-boundary case was found
Gap:
No detected test input for amount == discount_threshold.
Recommended next step:
Add below, equal, and above-threshold tests with exact assertions.
```
措辞是故意保守的。静态分析可以识别证据
和缺口;它不应该声称是真正的变异结果。
## 分类
| 分类 | 含义 |
| --- | --- |
| `exposed` | 静态证据表明存在通向强预言机的完整 RIPR 路径。 |
| `weakly_exposed` | 存在路径,但感染或区分显得微弱。 |
| `reachable_unrevealed` | 相关测试似乎可达,但未找到有意义的预言机。 |
| `no_static_path` | 未找到已更改所有者的静态测试路径。 |
| `infection_unknown` | 存在可达性,但输入或装置证据不透明。 |
| `propagation_unknown` | 更改的行为越过了不透明的传播边界。 |
| `static_unknown` | 静态分析无法做出可信的判断。 |
除非在特定校准上下文中报告真实的变异数据,否则 `ripr` 不应使用变异运行时的结果语言,如 `killed` 或 `survived`。
## 当前范围
当前的 alpha 生产线有意保持狭窄:
- 一个已发布的包:`ripr`
- 一个 CLI 二进制文件:`ripr`
- 一个共享分析引擎
- 基于语法的统一 diff 分析
- 基于解析器的 Rust 函数、测试、断言、所有者和探针事实,带有词汇回退
- 人类可读、JSON 和 GitHub 输出
- 实验性 LSP sidecar
该包未拆分为 `ripr-core`、`ripr-cli` 或 `ripr-lsp`。如果外部使用者
需要,可以稍后添加公开的 crate 边界。
## 当前能力概览
`ripr` 目前最强之处是作为具有一流仓库接缝证据的快速、基于语法的草案信号。
当前能力:
| 能力 | 当前状态 | 下一检查点 |
| --- | --- | --- |
| 分发 | `0.4.0` 已发布在 crates.io、GitHub Releases、VS Marketplace 和 Open VSX 上,包含服务器归档、VSIX 打包、生成的 CI 工作流产物、发布就绪证明以及已安装的编辑器-智能体循环冒烟检查。 | 发布后维护;保持注册表、服务器和市场表面对齐。 |
| Diff 分析 | 证据优先的 Voice A 发现,包含基于语法的已更改行探针、探针相对预言机强度、本地流汇点、观察到/缺失的激活值以及明确的停止原因。 | 维护;无活动的分析器重构车道。 |
| 仓库接缝清单 | 一流的 `RepoSeam` 模型,带有确定性接缝 ID、缓存的接缝事实层、跨五个 RIPR 阶段的测试抓取证据以及 11 类 `SeamGripClass` 分类。 | 维护;无活动的分析器重构车道。 |
| 测试发现 | 基于解析器的测试和断言事实,包括精确、宽泛、关系、快照、mock、冒烟、自定义辅助、副作用观察者和未知预言机类型;带有冒烟/宽泛/断开/不透明/循环/可能空洞原因和重复区分器组的每测试效率台账。 | 维护;无活动的分析器重构车道。 |
| 输出 | 人类可读、JSON、上下文和 GitHub 格式呈现带有停止原因的优先证据发现;`ripr pilot` 编写零配置的首次运行数据包;`ripr outcome` 比较前后的仓库暴露快照;仓库暴露报告和 v2 智能体接缝数据包呈现分类的接缝证据;公开的 `ripr` 和 `ripr+` Shields 徽章发布接缝原生的未解决缺口计数,而 diff 徽章产物仍基于发现暴露。 | 输出合约维护。 |
| LSP | 实验性的 `tower-lsp-server` sidecar,带有感知证据的发现诊断、相关测试链接、悬停、服务器端上下文数据包、接缝原生诊断 + 悬停,以及用于复制数据包/断言和打开相关测试的接缝代码操作。保存的工作区诊断仍为建议性;未保存的缓冲区覆盖不是默认行为。 | 编辑器合约维护。 |
| 智能体上下文 | 紧凑的上下文数据包,加上每个接缝的 `write_targeted_test` 和 `inspect_static_limitation` 数据包,包含推荐的测试放置位置、要模仿的最近测试、候选值、缺失的区分器、要模仿/避免的模式以及断言模板。`ripr agent start --root . --seam-id --out target/ripr/workflow` 编写一个无源代码编辑的工作流数据包,`ripr agent status --root . --json` 报告本地 LLM 循环产物状态和下一个命令而无需重新运行分析,`ripr agent receipt` 发出来源及有界的下一操作指导,以及 `ripr agent review-summary --root .` 将现有循环产物合并为紧凑的审查 Markdown 或 schema `0.1` JSON。 | 智能体循环维护。 |
| 首个有效操作 | `ripr first-action` 根据明确的 PR 指导、助手证明、PR 证据台账、基线增量、回执、可选关卡、可选覆盖率/抓取前沿和编辑器上下文输入,编写建议性的 `first-useful-action.{json,md}`,没有隐藏分析、源代码编辑、生成的测试、提供者调用、变异执行或默认的 CI 阻断;生成的 CI 将报告投影为建议性摘要/产物内容,并且 VS Code 状态/Show Status 可以投影工作区匹配报告而无需新的诊断。 | `docs/first-useful-action-workflow` |
| 仓库配置 | 仓库根目录的 `ripr.toml` 可以设置分析模式、预言机策略、严重性映射、抑制路径、报告相关测试上限以及 LSP 接缝诊断默认值。显式的 CLI 标志和 LSP 初始化选项仍然优先。 | 采用后的策略反馈。 |
| SARIF 和 CI 策略 | `ripr check --format sarif` 发出 diff 范围的发现 SARIF,而 `--format repo-sarif` 发出带有已配置严重性、抑制元数据、稳定规则 ID 和稳定指纹的仓库接缝 SARIF。`ripr init --ci github` 生成一个非阻塞的 GitHub Actions 报告工作流,包含 pilot/report 产物、仓库徽章 JSON 和可选的 SARIF 渲染/上传;`cargo xtask sarif-policy` 仅在明确请求时将当前 SARIF 与基线进行比较。 | 采用后的建议性策略反馈。 |
| 校准 | 建议性的 `ripr calibrate cargo-mutants` 和仓库本地的 `cargo xtask mutation-calibration` 通过 `seam_id` 或明确的文件/行将导入的 cargo-mutants 运行时数据加入到静态接缝证据中;不明确的文件/行候选项保持未分配状态。`fixtures/CALIBRATION_CORPUS.md` 将当前的 fixture 映射到受控的校准场景,`fixtures/EXAMPLE_CORPUS.md` 将已检查的边界缺口校准样本链接到操作员循环中,并且 `fixtures/boundary_gap/calibration/runtime-fixtures-v1/` 固定了主要的静态/运行时一致性桶。 | 维护;运行时变异语言保留在校准/运行时报告中。 |
Campaigns 5A、5B、6、7、8、9、10 和 11 已完成。Campaign 7 关闭了
默认优先的采用通道:`ripr pilot`、`ripr outcome`、建议性
校准导入、操作员控制台、生成的 GitHub Action
入口点、文档化的 VS Code 安装路径、公开示例语料库 和
发布/安装证明已就绪。Campaign 8 保持运行时校准的
提供和可选。Campaign 9 使编辑器/操作员热路径得到衡量和限制。
Campaign 10 将保存的工作区编辑器循环与来自诊断到证据、数据包或简报、针对性测试、结果、智能体验证、智能体回执、控制台、CI 产物和发布就绪证明的智能体 CLI 循环保持一致。
Campaign 11 在 LLM 工作循环获得只读产物状态、
集中化命令模板、工作流清单、带来源的回执、
有界的下一操作指导、审查者摘要、fixture、生成的 CI 数据包
上传和 LLM 操作指南后关闭。然后 Campaign 12 关闭了首小时 UX
通道:编辑器首次运行状态路径、意图命名的代码操作、生成的
CI 建议摘要、生成的工作流冒烟 fixture 以及按用户类型划分的首小时文档已固定。接着 Campaign 13 关闭了 PR 审查指导:
`ripr review-comments` 编写建议性审查报告,生成的 CI 在发出建议性摘要和检查注解之前运行它,
放置和抑制情况已通过 fixture 固定,并且 [PR 审查指导](docs/PR_REVIEW_GUIDANCE.md) 记录了该命令、CI 行为、仅摘要回退和行内评论选择加入边界。Campaign 14 关闭了建议校准:已检查的建议性 `cargo xtask recommendation-calibration` 报告现在衡量 PR 时的建议是否有用、是否安全放置、是否正确抑制、是否指向预期的测试目标,以及是否与静态移动的前后状态相关联。[建议校准工作流](docs/RECOMMENDATION_CALIBRATION.md) 记录了如何阅读该报告。Campaign 15 作为已校准关卡策略关闭:RIPR-SPEC-0014 固定了可选的关卡合约,`ripr gate evaluate` 编写只读决策报告,生成的 CI 仅在显式配置 `RIPR_GATE_MODE` 时运行它,并且 [已校准关卡策略](docs/CALIBRATED_GATE_POLICY.md) 记录了操作员工作流。[基线台账工作流](docs/BASELINE_LEDGER_WORKFLOW.md) 展示了如何在迈向 RIPR 0 的过程中创建、比较和缩减已审查的行为抓取债务基线。随后 Campaigns 20 和 21 使测试预言机助手证明循环和只读证明报告生成器成为一流的建议性产物。Campaign 22 作为首个有效操作关闭:`ripr first-action` 现在编写只读建议性报告,生成的 CI 将其作为建议性摘要/产物内容投影,VS Code 状态路径可以显示现有的工作区匹配报告而无需添加诊断或编辑器装饰,并且已检查的 dogfood 回执固定了文档化的路由情况。默认生成的工作流仍然是建议性的。
更深层的能力状态位于 [能力矩阵](docs/CAPABILITY_MATRIX.md) 和 [指标](docs/METRICS.md) 中。
## 编辑器扩展
VS Code 扩展启动 `ripr lsp --stdio` 并且可以从以下位置解析服务器:
```
1. explicit ripr.server.path
2. bundled server binary, if present
3. downloaded cached server binary
4. verified first-run GitHub Release download
5. ripr on PATH
6. actionable error
```
正常的编辑器安装不应需要 `cargo install ripr`。Cargo 安装
路径仍可用于离线、固定或受控环境。`v0.4.0` 发布线
包括此默认路径所需的服务器清单、每个目标的服务器
归档、校验和以及 VSIX。
参见:
- [编辑器扩展](docs/EDITOR_EXTENSION.md)
- [服务器配置](docs/SERVER_PROVISIONING.md)
- [Marketplace 发布](docs/RELEASE_MARKETPLACE.md)
- [PR 审查指导](docs/PR_REVIEW_GUIDANCE.md)
## 面向贡献者
大多数贡献者应该使用仓库自动化,而不是手动记住关卡顺序。
```
cargo xtask shape
cargo xtask fix-pr
cargo xtask check-pr
cargo xtask pr-summary
```
有用的证据命令:
```
cargo xtask fixtures
cargo xtask goldens check
cargo xtask golden-drift
cargo xtask test-oracle-report
cargo xtask evidence-health
cargo xtask dogfood
cargo xtask reports index
cargo xtask receipts
cargo xtask receipts check
cargo xtask check-allow-attributes
cargo xtask check-local-context
cargo xtask metrics
```
一个良好的 `ripr` PR 应以生产风险为范围,而不是代码行数:
```
small production delta
complete evidence package
clear spec-test-code-output-metric trail
```
当大型 fixture、golden、spec、docs、metrics 或可追溯性 diff 能够使一个生产行为变得可审查时,我们同样表示欢迎。
参见:
- [范围限定的 PR 合约](docs/SCOPED_PR_CONTRACT.md)
- [PR 自动化](docs/PR_AUTOMATION.md)
- [工程规则](docs/ENGINEERING.md)
- [智能体工作流](docs/AGENT_WORKFLOWS.md)
- [Codex Goals](docs/CODEX_GOALS.md)
## 支持文档
从这里开始:
| 需求 | 文档 |
| --- | --- |
| 按用户类型选择首小时路径 | [快速入门](docs/QUICKSTART.md) |
| 了解模型 | [静态暴露模型](docs/STATIC_EXPOSURE_MODEL.md) |
| 了解 JSON/上下文输出 | [输出 schema](docs/OUTPUT_SCHEMA.md) |
| 将接缝证据转化为测试 | [针对性测试工作流](docs/TARGETED_TEST_WORKFLOW.md) |
| 采用基线债务台账 | [基线台账工作流](docs/BASELINE_LEDGER_WORKFLOW.md) |
| 了解简单启动默认值 | [默认优先采用规范](docs/specs/RIPR-SPEC-0009-defaults-first-adoption.md) |
| 查看当前产品方向 | [路线图](docs/ROADMAP.md) |
| 查看活跃的 campaigns | [实施 campaigns](docs/IMPLEMENTATION_CAMPAIGNS.md) |
| 查看实施检查点 | [实施计划](docs/IMPLEMENTATION_PLAN.md) |
| 运行 Codex Goals | [Codex Goals](docs/CODEX_GOALS.md) |
| 查看行为合约 | [规范](docs/specs/README.md) |
| 查看设计决策 | [ADRs](docs/adr/README.md) |
| 添加或审查 fixture | [测试](docs/TESTING.md) 和 [测试分类](docs/TEST_TAXONOMY.md) |
| 了解仓库自动化 | [PR 自动化](docs/PR_AUTOMATION.md) |
| 推出 Droid 审查 | [推出 Factory Droid 审查](docs/how-to/roll-out-droid.md) 和 [Droid 推出清单](docs/agent-context/droid-rollout.md) |
| 了解架构 | [架构](docs/ARCHITECTURE.md) |
| 审查能力状态 | [能力矩阵](docs/CAPABILITY_MATRIX.md) 和 [指标](docs/METRICS.md) |
| 贡献范围限定的 PR | [贡献](CONTRIBUTING.md) 和 [范围限定的 PR 合约](docs/SCOPED_PR_CONTRACT.md) |
| 了解 CI | [CI 策略](docs/CI.md) |
| 了解 Dogfooding | [Dogfooding](docs/DOGFOODING.md) |
| 了解文档组织 | [文档系统](docs/DOCUMENTATION.md) |
| 捕获仓库知识 | [经验总结](docs/LEARNINGS.md) |
| 发布 crate 或扩展 | [发布](docs/RELEASE.md)、[出版](docs/PUBLISHING.md) 和 [Open VSX](docs/OPENVSX.md) |
| 处理扩展资产 | [品牌资产](assets/logo/README.md) |
| 查找面向智能体的仓库说明 | [智能体说明](AGENTS.md) |
## 开发
运行正常的本地关卡:
```
cargo xtask check-pr
```
直接运行完整的 Rust 检查:
```
cargo fmt --check
cargo check --workspace --all-targets
cargo test --workspace
cargo clippy --workspace --all-targets -- -D warnings
cargo doc --workspace --no-deps
```
发布/包检查:
```
cargo package -p ripr --list
cargo publish -p ripr --dry-run
```
有用的示例命令:
```
cargo run -p ripr -- check --diff crates/ripr/examples/sample/example.diff
cargo run -p ripr -- check --diff crates/ripr/examples/sample/example.diff --json
```
标签:Anchore, pocsuite3, Rust, Rust测试, SOC Prime, TDD, VS Code, VSCode插件, 云安全监控, 代码安全, 代码审查, 变异测试, 可视化界面, 图数据库, 威胁情报, 开发工具, 开发者工具, 开源框架, 持续集成, 测试缺口, 测试自动化, 测试覆盖率, 测试预言机, 漏洞枚举, 编辑器插件, 缺陷检测, 网络流量审计, 质量保证, 软件测试, 通知系统, 错误基检测, 静态代码分析, 静态分析