skills/ohos-test-fuzz-generation/SKILL.md
为 C/C++ 项目生成 LLVM libFuzzer FUZZ 测试用例、执行 26 条安全规范审查、生成语义化种子数据。 兼容 OpenHarmony / Linux / Android 构建系统。 触发关键词:fuzz 测试、生成 fuzzer、创建 fuzz 用例、fuzz 规范检查、fuzz_test、LLVMFuzzerTestOneInput、种子数据/corpus
npx skillsauth add openharmonyinsight/openharmony-skills ohos-test-fuzz-generationInstall this skill globally with one command. Works with Claude Code, Cursor, and Windsurf.
3 of 9 scanners reported clean
Some scanners were skipped, did not run, or reported a non-clean status. Review each row below.
用户输入需求
↓
[决策点] 用户意图是什么?
├─ 给类名要求生成测试 → 进入完整工作流
├─ 给现有文件要求检查 → 跳至阶段 5(规范审查)
├─ 要求生成种子 → 跳至阶段 4(种子语义生成)
└─ 要求生成报告 → 跳至阶段 5 后生成报告
↓
[阶段 1] 代码分析 —— 解析目标 API 类结构、方法签名、参数类型
↓
[阶段 2] 骨架生成 —— 创建 5 文件标准化工程(.cpp/.h/BUILD.gn/project.xml/corpus)
↓
[阶段 3] 实现填充 —— 模板替换为实际 API 职责与数据构造逻辑
↓
[阶段 4] 种子语义生成 —— 基于参数类型/名称特征生成高价值初始 corpus
↓
[阶段 5] 规范审查 —— 26 条规则逐一验证,输出合规报告
**加载触发**:仅加载违规规则的 rules/SecurityCodeReview_FuzzCheck_XXX.md
**必须加载**:规则 005 详细说明(复杂参数构造,误报高发区)
**不要加载**:未违规规则、规则速查表(`references/rules-overview.md` 仅在审查时加载)
↓
[阶段 6] 自动修复 —— 可自动修复规则执行修复(最多 3 轮)
↓
交付生成文件 + 审查报告 + 人工确认项清单
异常处理决策树:
| 工具 | 用途 | 命令示例 |
|------|------|----------|
| tools/fuzz_generator.py | 生成 FUZZ 测试用例 | python tools/fuzz_generator.py -n XxxXxx_fuzzer -N Namespace -c ClassName -H header.h -p output_path |
| tools/fuzz_check.py | 规范审查(26 条规则) | python tools/fuzz_check.py --dir fuzzer_dir [--fix] |
| tools/seed_generator.py | 生成语义化种子 | python tools/seed_generator.py --dir fuzzer_dir [--api ApiName] |
| tools/generate_report.py | 生成合规报告 | python tools/generate_report.py --dir fuzzer_dir |
开始生成前,先确认:
IRemoteBroker / 含 DECLARE_INTERFACE_DESCRIPTOR → 必须生成 IPC stub fuzzer(LLVMFuzzerInitialize 初始化全局 g_stub,LLVMFuzzerTestOneInput 用 code % CODE_MAX 驱动),sptr<T> 参数写入 WriteRemoteObject(nullptr)(规则 007)| 类型类别 | 消费代码 | 说明 |
|----------|----------|------|
| 标识符类型(大驼峰非枚举) | fdp.ConsumeIntegral<uint64_t>() | 如 ScreenId/NodeId,底层是 uint64_t typedef |
| 进程/用户标识 | fdp.ConsumeIntegral<uint32_t>() | 如 ProcessId/Uid |
| 文件描述符 | fdp.ConsumeIntegral<int32_t>() | 如 Fd |
| 枚举类型 | static_cast<EnumType>(fdp.ConsumeIntegral<uint8_t>() % ENUM_SIZE) | 必须用 uint8_t(规则 013) |
| 字符串 | fdp.ConsumeRandomLengthString(256) | 限制最大长度防止内存爆炸 |
| 容器 | 先消费长度 uint8_t count = fdp.ConsumeIntegral<uint8_t>() % 32,再循环消费 | 适用于 std::vector<T> |
关键区分:大驼峰命名不一定是枚举,可能是 typedef 别名。必须检查 ENUM_SIZE_MAP 确认是否为枚举。
未知类型处理策略:
TYPE_CONSUMER_MAP 中 → 直接使用映射ENUM_SIZE_MAP → 是枚举则 uint8_t % ENUM_SIZEstd::vector<T> → 是则循环消费tools/fuzz_generator.py 查看 COMPLEX_TYPE_MAP 或构造自定义消费逻辑rand() / random() —— 不可重现,丧失覆盖率追踪意义(规则 017)size 参数当作变异数据传入 API —— fuzz 引擎无法有效变异长度(规则 010)data 指针 —— 可能包含非法地址,100% 触发 SIGSEGV(规则 018)auto 声明 fuzz 变量 —— 无法人工验证类型匹配性(规则 016)uint32_t —— 1 字节变异效率远高于 4 字节(规则 013)根据任务按需加载:
references/rules-overview.md — 26 条规则速查表(名称/严重度/自动检查/自动修复)
rules/SecurityCodeReview_FuzzCheck_XXX.md — 违规规则详细说明(正误示例 + 豁免条件)
rules/SecurityCodeReview_FuzzCheck_005.md — 复杂参数构造规则详解
tools/fuzz_generator.py — 用例生成器源码
TYPE_CONSUMER_MAP、ENUM_SIZE_MAP、COMPLEX_TYPE_MAPtemplates/fuzzer.cpp — 代码生成模板
官方文档:
testing
--- name: ohos-req-value-decision description: Use after review meeting to record decision and route to next step. Triggers: 评审决策纪要, 评审结论回流, value decision, 评审接纳, 评审不接纳, 评审退回, 下次重新上会. Do NOT use for feature baseline (ohos-req-feature-baseline), review gate checks (ohos-req-review-gate), or IR generation (ohos-req-feature-to-ir). metadata: author: openharmony scope: common stage: requirements capability: value-decision version: 0.3.0 status: draft tags: - sdd - requirements
development
Use when converting an OpenHarmony requirement document, spec, or design proposal into an OpenHarmony review slide deck (需求评审 / 需求变更评审 / 设计评审 PPTX) — produces the fixed OpenHarmony-branded review-deck structure (OH logo on every page) with architecture/flow diagrams and field tables. Triggers on "需求评审PPT", "需求变更评审", "把需求文档转成评审PPT", "spec转评审PPT", "requirement/spec to review deck". NOT for arbitrary or generic slide decks unrelated to OpenHarmony requirement/design review.
testing
Use when performing the Phase 0 Step 0.5 Review Ready Gate on a 04-feature.md, especially when the user says "evaluate gate", "review readiness", "feature ready?", "should we generate IR", or when the ohos-req-intake-orchestration main session needs a structured Ready / Conditional Ready / Not Ready judgment instead of doing the check inline. Reads 01-04, runs seven fixed checks plus a conditional-items check, and returns a machine-readable JSON summary plus a human-readable table that the main session can route on. Do NOT use for feature baseline generation (ohos-req-feature-baseline), value decision recording (ohos-req-value-decision), or IR generation (ohos-req-feature-to-ir).
testing
--- name: ohos-req-requirement-intake description: Use when importing an OHOS requirement into Phase 0.1, especially for 01-requirement.md, requirement intake, background, user value, scenarios, scope, FR/NFR, affected modules, or priority. Triggers: 需求导入, 01-requirement, 需求基线, RR单号. Do NOT use for feasibility analysis (ohos-req-feasibility-analysis), architecture decision (ohos-req-arch-decision), or feature baseline (ohos-req-feature-baseline). metadata: author: openharmony scope: common