git add sources/ tests/
git commit -m "Improve test coverage for <module>"

Sui 覆盖率技能

通过安全分析来分析和自动改进 Sui Move 测试覆盖率。

GitHub:

前提条件

安装 Sui CLI

bash

macOS（推荐）

brew install sui

其他平台：请参阅官方文档

https://docs.sui.io/guides/developer/getting-started/sui-install

验证：
bash
sui --version

快速参考

bash

工具位置（根据你的技能安装路径进行调整）

SKILL_DIR=<你的工作空间>/skills/sui-coverage

完整工作流程

cd /path/to/move/package sui move test --coverage --trace python3 $SKILLDIR/analyzesource.py -m <模块> -o coverage.md

工作流程：自动改进测试覆盖率

步骤 1：运行覆盖率分析

bash
cd <包路径>
sui move test --coverage --trace
python3 $SKILLDIR/analyzesource.py -m <模块名> -o coverage.md

步骤 2：阅读覆盖率报告

阅读生成的 coverage.md 以识别：

• - 🔴 未调用的函数 - 从未执行的函数
• 🔴 未覆盖的断言 - 未测试的 assert!() 失败路径
• 🔴 未覆盖的分支 - 未执行的 if/else 路径

步骤 3：编写缺失的测试

针对每个未覆盖项编写测试：

A. 未调用的函数

move #[test] fun test_<函数名>() { // 设置 let mut ctx = tx_context::dummy(); // 调用未覆盖的函数 <函数名>(...); // 断言预期行为 }

B. 断言失败路径（expect_failure）

move #[test] #[expectedfailure(abortcode = <错误码>)] fun test<函数>当<条件>时失败() { let mut ctx = tx_context::dummy(); // 设置触发断言失败的状态 <应失败的函数调用>(); }

C. 分支覆盖率（if/else）

move #[test] fun test<函数>当<条件为真>时() { ... }

#[test]
fun test<函数>当<条件为假>时() { ... }

步骤 4：验证覆盖率已改进

bash
sui move test --coverage --trace
python3 $SKILLDIR/analyzesource.py -m <模块名>

---

工具

1. analyze_source.py（主要工具）

bash
python3 $SKILLDIR/analyzesource.py --module <名称> [选项]

选项：
-m, --module 模块名（必填）
-p, --path 包路径（默认：.）
-o, --output 输出文件（例如 coverage.md）
--json JSON 输出
--markdown 输出 Markdown 到标准输出

2. analyze.py（LCOV 统计）

bash
sui move coverage lcov
python3 $SKILL_DIR/analyze.py lcov.info -f <包> -s sources/

选项：
-f, --filter 按路径模式过滤
-s, --source-dir 用于上下文的源目录
-i, --issues-only 仅显示有问题的文件
-j, --json JSON 输出

3. parse_bytecode.py（底层）

bash
sui move coverage bytecode --module <名称> | python3 $SKILLDIR/parsebytecode.py

---

常见模式

测试断言失败

move
// 源代码：
public fun withdraw(balance: &mut u64, amount: u64) {
assert!(*balance >= amount, EInsufficientBalance); // ← 此失败路径
balance = balance - amount;
}

// 测试失败路径：
#[test]
#[expectedfailure(abortcode = EInsufficientBalance)]
fun testwithdrawinsufficient_balance() {
let mut balance = 50;
withdraw(&mut balance, 100); // 应失败：50 < 100
}

测试所有分支

move
// 源代码：
public fun classify(value: u64): u8 {
if (value == 0) {
0
} else if (value < 100) {
1
} else {
2
}
}

// 测试所有分支：
#[test]
fun testclassifyzero() {
assert!(classify(0) == 0, 0);
}

#[test]
fun testclassifysmall() {
assert!(classify(50) == 1, 0);
}

#[test]
fun testclassifylarge() {
assert!(classify(100) == 2, 0);
}

测试对象生命周期

move
#[test]
fun testfulllifecycle() {
let mut ctx = tx_context::dummy();

// 创建
let obj = create(&mut ctx);
assert!(get_value(&obj) == 0, 0);

// 修改
increment(&mut obj);
assert!(get_value(&obj) == 1, 0);

// 销毁
destroy(obj);
}

---

错误码参考

编写 #[expected_failure] 测试时，使用错误常量名：

move
// 如果模块定义了：
const EInvalidInput: u64 = 1;
const ENotAuthorized: u64 = 2;

// 在测试中使用：
#[expectedfailure(abortcode = EInvalidInput)]
fun testinvalidinput() { ... }

// 或使用模块限定的名称：
#[expectedfailure(abortcode = my_module::EInvalidInput)]
fun testinvalidinput() { ... }

---

示例：完整自动覆盖率会话

bash

1. 分析当前覆盖率

cd /path/to/my_package
sui move test --coverage --trace
python3 $SKILLDIR/analyzesource.py -m my_module -o coverage.md

2. 审查缺失内容

cat coverage.md

显示：

- decrement() 未被调用

- assert!(value > 0, EValueZero) 失败未测试

3. 向 sources/mymodule.move 或 tests/mymodule_tests.move 添加测试

（编写缺失的测试）

4. 验证改进

sui move test --coverage --trace python3 $SKILLDIR/analyzesource.py -m my_module

5. 重复直到 100% 覆盖率

---

与代理工作流程的集成

当被要求改进测试覆盖率时：

1. 1. 运行分析 - 获取当前覆盖率状态
2. 阅读源代码 - 理解模块的逻辑
3. 识别差距 - 列出未覆盖的函数/分支/断言
4. 安全审查 - 在编写测试时分析漏洞
5. 编写测试 - 为每个差距 + 安全边界情况创建测试
6. 报告发现 - 记录发现的任何安全问题
7. 验证 - 重新运行覆盖率以确认改进

始终提交测试改进：
bash
git add sources/ tests/
git commit -m 改进 <模块> 的测试覆盖率

---

测试期间的安全分析

编写测试 = 理解合约 = 发现漏洞

在编写测试时，主动查找以下问题：

1. 访问控制

要问的问题：

• - 谁可以调用此函数？
• 是否应有所有者/管理员检查？
• 未经授权的用户能否操纵状态？

危险信号：

• - 修改关键状态且无检查的公共函数
• 缺少能力/见证模式

2. 整数溢出/下溢

要问的问题：

• - 在 u64::MAX 时会发生什么？
• 从 0 中减去时会发生什么？
• 算术运算是否经过检查？

测试模式：
#[test]
fun testoverflowboundary() {
// 使用最大值进行测试
}

3. 状态操纵

要问的问题：

• - 状态是否会处于不一致状态？
• 所有状态更改是否都是原子性的？
• 部分失败是否会损坏数据？

危险信号：

• - 无回滚的多个状态更改
• 无适当锁定的共享对象

4. 经济利用

要问的问题：

• - 有人能否提取比存入更多的价值？
• 是否存在可被利用的舍入错误？
• 闪电贷攻击向量？

危险信号：

• - 无滑点保护的价格计算
• 对用户控制数据的无界循环

5. 拒绝服务

要问的问题：

• - 有人能否阻止合法用户？
• 是否存在无界操作？
• 存储是否可能被恶意填充？