oh-xts-generator-template

Compare original and translation side by side

🇺🇸

Original

English

🇨🇳

Translation

Chinese

oh-xts-generator-template

OpenHarmony XTS 测试用例通用生成模板

Universal Generation Template for OpenHarmony XTS Test Cases

技能概述

Skill Overview

oh-xts-generator-template 是一个通用的 OpenHarmony XTS 测试用例生成模板，设计为可配置、可扩展的通用框架，适用于各个子系统的测试用例生成。

oh-xts-generator-template is a universal OpenHarmony XTS test case generation template, designed as a configurable and extensible general framework suitable for test case generation in various subsystems.

核心特性

Core Features

通用测试生成流程 - 提供完整的测试用例生成工作流
模块化架构 - 四层模块化设计（L1/L2/L3/L4），按需加载
分层配置系统 - 通用配置 + 子系统特有配置
灵活扩展机制 - 支持各子系统添加特有配置和模板

Universal Test Generation Workflow - Provides a complete test case generation workflow
Modular Architecture - Four-layer modular design (L1/L2/L3/L4), loaded on demand
Layered Configuration System - General configuration + subsystem-specific configuration
Flexible Extension Mechanism - Supports adding subsystem-specific configurations and templates

核心功能

Core Functions

功能	说明
API定义解析	解析 `.d.ts` 文件，提取接口、方法、参数、返回值、错误码
测试覆盖分析	分析现有测试文件，识别已覆盖和未覆盖的API
智能测试生成	根据测试策略自动生成符合 XTS 规范的测试用例
测试设计文档生成	同时生成结构化的测试设计文档，包含测试用例说明、预期结果等
ArkTS 静态语言语法规范校验	校验 ArkTS 静态语言语法规范，包括类型注解、字段初始化、语法兼容性等
代码规范检查	确保生成的代码符合 XTS 测试规范
编译问题解决	subagent 执行编译，自动修复语法错误，监听编译完成状态

Function	Description
API Definition Parsing	Parse `.d.ts` files, extract interfaces, methods, parameters, return values, and error codes
Test Coverage Analysis	Analyze existing test files, identify covered and uncovered APIs
Intelligent Test Generation	Automatically generate test cases compliant with XTS specifications based on test strategies
Test Design Document Generation	Simultaneously generate structured test design documents, including test case descriptions, expected results, etc.
ArkTS Static Language Syntax Specification Validation	Validate ArkTS static language syntax specifications, including type annotations, field initialization, syntax compatibility, etc.
Code Specification Checking	Ensure generated code complies with XTS test specifications
Compilation Issue Resolution	Use subagent to execute compilation, automatically fix syntax errors, and monitor compilation completion status

适用场景

Applicable Scenarios

✅ 为新 API 生成完整的测试套件
✅ 同时生成测试用例和测试设计文档
✅ 分析现有测试的覆盖情况
✅ 补充缺失的测试用例和测试设计
✅ 验证测试代码规范性
✅ 各子系统定制化测试生成

✅ Generate complete test suites for new APIs
✅ Generate test cases and test design documents simultaneously
✅ Analyze coverage of existing tests
✅ Supplement missing test cases and test designs
✅ Verify test code standardization
✅ Customized test generation for each subsystem

快速开始

Quick Start

📖 详细使用方式: docs/USAGE.md

📖 Detailed Usage: docs/USAGE.md

三种使用方式概览

Overview of Three Usage Methods

方式	适用场景	链接
方式1：通用模板	新手、简单任务	USAGE.md
方式2：子系统配置	大多数任务（推荐）	USAGE.md
方式3：自定义配置	高级用户、特殊需求	USAGE.md

Method	Applicable Scenario	Link
Method 1: General Template	Beginners, simple tasks	USAGE.md
Method 2: Subsystem Configuration	Most tasks (Recommended)	USAGE.md
Method 3: Custom Configuration	Advanced users, special requirements	USAGE.md

核心工作流程

Core Workflow

1. 确定子系统配置
    ├─ 检查是否存在子系统配置文件
    ├─ 加载通用配置 (_common.md)
    └─ 加载子系统配置 ({Subsystem}/_common.md)

2. 解析 API 定义 (.d.ts + 文档)
    ├─ 读取 API 声明文件 (.d.ts)
    ├─ 查找并解析 API 文档
    └─ 综合分析

3. 参考已有用例（强制）
    ├─ 扫描指定路径的已有测试文件
    ├─ 分析代码风格和规范
    └─ 提取共性模式

4. 分析现有测试（可选）
    ├─ 扫描测试文件
    ├─ 识别已覆盖的API
    └─ 计算测试覆盖率

5. 生成测试用例
    ├─ 应用子系统特有规则
    ├─ 使用子系统特有模板
    └─ 应用已有用例的代码风格

6. 同步生成测试设计文档（强制）
    ├─ 为每个测试用例生成详细设计说明
    ├─ 包含测试场景、测试步骤、预期结果
    ├─ 生成结构化 Markdown 文档
    └─ 与测试用例文件对应命名

7. 添加 @tc 注释块（强制）
    ├─ @tc.name：小驼峰命名，与 it() 参数一致
    ├─ @tc.number：{describe名}_{序号}
    ├─ @tc.desc：{API名} {错误码/场景} test.
    └─ 验证字段值与 it() 参数的一致性

 8. 格式化和验证
     ├─ 应用代码模板
     ├─ 检查语法规范
     │   ├─ 8.1 动态语法检查（生成动态 XTS 用例时）
     │   │   └─ 参考规范文档：`references/ArkTS_Dynamic_Syntax_Rules.md`
     │   └─ 8.2 静态语法检查（生成静态 XTS 用例时）
     │       └─ 参考规范文档：`references/arkts-static-spec/`
     ├─ 验证断言方法
     └─ 输出校验结果和修改建议

9. 注册测试套（新增文件时必须）
    ├─ 查找 List.test.ets 文件
    ├─ 添加 import 语句
    └─ 在 testsuite() 函数中调用

 10. 编译验证（重要）
     ├─ 检测运行环境（Linux/Windows）
     ├─ 根据环境选择编译方案
     ├─ Linux 环境：使用 subagent 执行编译，监听进程，自动修复语法错误
     ├─ Windows 环境：根据关键词自动选择动态或静态编译模式
     └─ **详细编译流程**：参见注意事项第7条"编译环境检测"

11. 输出更新文件列表、测试设计文档和覆盖率对比

> 📖 **详细的工作流程说明请查看**: [docs/ARCHITECTURE.md](./docs/ARCHITECTURE.md)

1. Determine Subsystem Configuration
    ├─ Check if subsystem configuration file exists
    ├─ Load general configuration (_common.md)
    └─ Load subsystem configuration ({Subsystem}/_common.md)

2. Parse API Definitions (.d.ts + Documentation)
    ├─ Read API declaration files (.d.ts)
    ├─ Find and parse API documentation
    └─ Comprehensive analysis

3. Reference Existing Cases (Mandatory)
    ├─ Scan specified paths for existing test files
    ├─ Analyze code style and specifications
    └─ Extract common patterns

4. Analyze Existing Tests (Optional)
    ├─ Scan test files
    ├─ Identify covered APIs
    └─ Calculate test coverage

5. Generate Test Cases
    ├─ Apply subsystem-specific rules
    ├─ Use subsystem-specific templates
    └─ Apply code style from existing cases

6. Synchronously Generate Test Design Documents (Mandatory)
    ├─ Generate detailed design descriptions for each test case
    ├─ Include test scenarios, test steps, and expected results
    ├─ Generate structured Markdown documents
    └─ Use corresponding naming with test case files

7. Add @tc Comment Block (Mandatory)
    ├─ @tc.name: camelCase naming, consistent with the it() parameter
    ├─ @tc.number: {describe_name}_{sequence_number}
    ├─ @tc.desc: {API_name} {error_code/scenario} test.
    └─ Verify consistency between field values and it() parameters

 8. Formatting and Validation
     ├─ Apply code templates
     ├─ Check syntax specifications
     │   ├─ 8.1 Dynamic Syntax Check (when generating dynamic XTS cases)
     │   │   └─ Reference specification document: `references/ArkTS_Dynamic_Syntax_Rules.md`
     │   └─ 8.2 Static Syntax Check (when generating static XTS cases)
     │       └─ Reference specification document: `references/arkts-static-spec/`
     ├─ Validate assertion methods
     └─ Output validation results and modification suggestions

9. Register Test Suite (Mandatory for New Files)
    ├─ Find List.test.ets file
    ├─ Add import statement
    └─ Call in testsuite() function

 10. Compilation Validation (Important)
     ├─ Detect runtime environment (Linux/Windows)
     ├─ Select compilation scheme based on environment
     ├─ Linux environment: Use subagent to execute compilation, monitor process, automatically fix syntax errors
     ├─ Windows environment: Automatically select dynamic or static compilation mode based on keywords
     └─ **Detailed Compilation Process**: See Note 7 "Compilation Environment Detection"

11. Output updated file list, test design documents, and coverage comparison

> 📖 **Detailed Workflow Description**: [docs/ARCHITECTURE.md](./docs/ARCHITECTURE.md)

配置扩展

Configuration Extension

📖 详细配置说明: docs/CONFIG.md

📖 Detailed Configuration Instructions: docs/CONFIG.md

配置优先级

Configuration Priority

用户自定义配置 > 子系统配置 > 通用配置

User-defined Configuration > Subsystem Configuration > General Configuration

输出规范

Output Specifications

测试用例编号(

@tc.number

)

Test Case Number(

@tc.number

)

格式: SUB_[子系统]_[模块]_[API]_[类型]_[序号]

类型标识：
- PARAM    参数测试
- ERROR    错误码测试
- RETURN   返回值测试
- BOUNDARY 边界值测试

Format: SUB_[subsystem]_[module]_[API]_[type]_[sequence_number]

Type Identifiers：
- PARAM    Parameter Test
- ERROR    Error Code Test
- RETURN   Return Value Test
- BOUNDARY Boundary Value Test

测试设计文档规范（强制）

Test Design Document Specifications (Mandatory)

文件命名规则：

格式: {测试文件名}.design.md
示例: Component.onClick.test.ets -> Component.onClick.test.design.md

文档模板和生成规则：

标准版模板：

modules/L3_Generation/design_doc_generator.md

简化版模板：

modules/L3_Generation/design_doc_templates.md

File Naming Rule：

Format: {test_file_name}.design.md
Example: Component.onClick.test.ets -> Component.onClick.test.design.md

Document Templates and Generation Rules：

Standard Template:

modules/L3_Generation/design_doc_generator.md

Simplified Template:

modules/L3_Generation/design_doc_templates.md

测试设计文档生成规则

Test Design Document Generation Rules

1. 同步生成原则

生成每个测试用例时，必须同步生成对应的测试设计文档
测试设计文档与测试用例一一对应
文档内容必须与测试用例实现保持一致

2. 文档内容完整性

必须包含所有测试场景的详细说明
必须包含测试步骤和预期结果
必须说明测试环境和前置条件
必须记录变更历史

3. 文档格式规范性

使用 Markdown 格式
遵循统一的模板结构
使用表格组织关键信息
保持版本信息更新

4. 文档更新机制

测试用例修改时，必须同步更新测试设计文档
文档版本号必须递增
变更内容必须记录在变更记录中

1. Synchronous Generation Principle

When generating each test case, must synchronously generate corresponding test design document
Test design documents correspond one-to-one with test cases
Document content must be consistent with test case implementation

2. Document Content Completeness

Must include detailed descriptions of all test scenarios
Must include test steps and expected results
Must explain test environment and preconditions
Must record change history

3. Document Format Standardization

Use Markdown format
Follow unified template structure
Use tables to organize key information
Keep version information updated

4. Document Update Mechanism

When modifying test cases, must synchronously update test design documents
Document version number must be incremented
Changes must be recorded in the change log

任务完成输出

Task Completion Output

每次完成任务后，必须输出：

markdown

undefined

After each task is completed, must output：

markdown

undefined

任务完成摘要

Task Completion Summary

新增测试文件

New Test Files

```
path/to/file1.test.ets
```
- 文件说明

```
path/to/file1.test.ets
```
- File description

新增测试设计文档

New Test Design Documents

```
path/to/file1.test.design.md
```
- 设计文档说明

```
path/to/file1.test.design.md
```
- Design document description

修改文件

Modified Files

```
path/to/file2.ets
```
- 修改说明

```
path/to/file2.ets
```
- Modification description

测试覆盖统计

Test Coverage Statistics

新增测试用例数：XX 个
新增测试设计文档：XX 个
覆盖的 API：XX 个


> 📖 **完整的使用方式请查看**: [docs/USAGE.md](./docs/USAGE.md)

Number of new test cases: XX
Number of new test design documents: XX
Covered APIs: XX


> 📖 **Complete Usage Guide**: [docs/USAGE.md](./docs/USAGE.md)

重要注意事项

Important Notes

1. @tc 注释块规范（强制）

1. @tc Comment Block Specifications (Mandatory)

所有测试用例（
```
it()
```
函数）必须在前面添加标准的
```
@tc
```
注释块
```
@tc.name
```
：必须使用小驼峰命名（camelCase），必须与
```
it()
```
第一个参数完全一致
- 详见：references/subsystems/_common.md 命名规范
```
@tc.number
```
：格式为
```
{describe名}_{序号}
```
，序号从001开始补零对齐

@tc.desc

：格式为

{API名} {错误码/场景} test.

，必须以

结尾

```
@tc.type
```
、
```
@tc.size
```
、
```
@tc.level
```
：必须与
```
it()
```
第二个参数中的值一致

All test cases (
```
it()
```
functions) must have a standard
```
@tc
```
comment block before them
```
@tc.name
```
: Must use camelCase naming, must be exactly the same as the first parameter of
```
it()
```
- See: Naming specifications in references/subsystems/_common.md
```
@tc.number
```
: Format is
```
{describe_name}_{sequence_number}
```
, sequence numbers start from 001 with zero padding

@tc.desc

: Format is

{API_name} {error_code/scenario} test.

, must end with

```
@tc.type
```
,
```
@tc.size
```
,
```
@tc.level
```
: Must be consistent with the values in the second parameter of
```
it()
```

2. hypium 导入规范（强制）

2. hypium Import Specifications (Mandatory)

基本导入：
```
describe, it, expect
```
（必需）
类型导入：
```
TestType, Level, Size
```
（必需）
条件导入：
```
beforeAll, afterAll
```
（根据代码需要）
自动检测并补充缺失的导入

Basic imports:
```
describe, it, expect
```
(required)
Type imports:
```
TestType, Level, Size
```
(required)
Conditional imports:
```
beforeAll, afterAll
```
(based on code needs)
Automatically detect and supplement missing imports

3. 工程文件修改限制（强制）

3. Project File Modification Restrictions (Mandatory)

严格禁止修改工程目录中的配置文件
仅允许修改：
```
entry/src/ohosTest/ets/test/
```
目录中的测试文件
违反限制的后果：可能导致工程结构被破坏、编译失败

Strictly prohibited from modifying configuration files in the project directory
Only allowed to modify: Test files in the
```
entry/src/ohosTest/ets/test/
```
directory
Consequences of violation: May cause project structure damage, compilation failure

4. 清理操作安全注意事项（强制）

4. Cleanup Operation Safety Notes (Mandatory)

⚠️ 关键警告：预编译清理操作必须谨慎执行，避免误删系统编译环境。

安全清理要求：

确认当前目录：执行清理命令前必须确认当前工作目录

bash

cd {OH_ROOT}/test/xts/acts/testfwk/{test_suite}
pwd  # 必须确认当前目录

使用显式路径删除：删除命令必须使用显式路径（

./

前缀或绝对路径）

bash

# ✅ 正确：使用显式相对路径
rm -rf ./.hvigor ./build ./entry/build ./oh_modules
rm -f ./oh-package-lock.json5 ./local.properties

# ❌ 错误：不使用路径前缀（可能误删 OH_ROOT/build）
rm -rf build

分步清理验证：
- 步骤1：清理测试套缓存并验证
- 步骤2：清理 OH_ROOT/out 目录
- 步骤3：验证 OH_ROOT/build 目录安全
禁止操作：
- ❌ 在 OH_ROOT 目录执行
```
rm -rf build
```
- ❌ 一次性清理多个目录
- ❌ 不验证当前目录就执行删除

参考文档：

modules/L4_Build/linux_prebuild_cleanup.md

1.3 节

⚠️ Critical Warning: Pre-compilation cleanup operations must be performed carefully to avoid accidental deletion of the system compilation environment.

Safety Cleanup Requirements:

Confirm Current Directory: Must confirm the current working directory before executing cleanup commands
bash
```
cd {OH_ROOT}/test/xts/acts/testfwk/{test_suite}
pwd  # Must confirm current directory
```

Use Explicit Path for Deletion: Delete commands must use explicit paths (prefix with

./

or absolute path)

bash

# ✅ Correct: Use explicit relative path
rm -rf ./.hvigor ./build ./entry/build ./oh_modules
rm -f ./oh-package-lock.json5 ./local.properties

# ❌ Incorrect: No path prefix (may accidentally delete OH_ROOT/build)
rm -rf build

Step-by-Step Cleanup and Validation:
- Step 1: Clean test suite cache and validate
- Step 2: Clean OH_ROOT/out directory
- Step 3: Validate safety of OH_ROOT/build directory
Prohibited Operations:
- ❌ Execute
```
rm -rf build
```
  in OH_ROOT directory
- ❌ Clean multiple directories at once
- ❌ Execute deletion without verifying current directory

Reference Document: Section 1.3 of

modules/L4_Build/linux_prebuild_cleanup.md

5. XTS Wiki 文档参考（强制）

5. XTS Wiki Document Reference (Mandatory)

生成 XTS 测试用例时，必须参考 Wiki 文档中的规范
Wiki 文档规范 > Template 配置 > 通用模板

When generating XTS test cases, must refer to specifications in Wiki documents
Wiki document specifications > Template configuration > General template

6. ArkTS 语法类型识别（重要）

6. ArkTS Syntax Type Identification (Important)

API 类型判断：必须读取
```
.d.ts
```
文件中最后一段 JSDOC 的
```
@since
```
标签
工程类型识别：读取
```
build-profile.json5
```
检查
```
arkTSVersion
```
字段
兼容性检查：生成测试用例前，必须检查工程语法类型与 API 类型是否匹配

API Type Judgment: Must read the
```
@since
```
tag in the last JSDOC section of the
```
.d.ts
```
file
Project Type Identification: Read
```
build-profile.json5
```
to check the
```
arkTSVersion
```
field
Compatibility Check: Must check if project syntax type matches API type before generating test cases

7. ArkTS 静态语言语法规范校验（可选）

7. ArkTS Static Language Syntax Specification Validation (Optional)

触发条件：用户明确要求生成静态 XTS 用例时自动启用

规范文档：

references/arkts-static-spec/

Trigger Condition: Automatically enabled when user explicitly requests static XTS case generation

Specification Document:

references/arkts-static-spec/

8. 编译环境检测（强制）

8. Compilation Environment Detection (Mandatory)

7.1 Linux 环境编译

7.1 Linux Environment Compilation

基础要求：

使用
```
build.sh
```
脚本编译，不要使用
hvigorw
环境检测：
```
uname -s
```

编译流程：

预编译清理（强制）：
- 使用
```
cleanup_group.sh
```
  脚本
- 清理目的：确保编译结果包含所有最新代码
- ⚠️ 安全注意事项：见第 3.1 节清理操作安全说明
静态测试套预置条件（编译静态套时）：
- 校验 hvigor 版本：
```
"6.0.0-arkts1.2-ohosTest-25072102"
```
- 版本匹配：跳过工具替换；版本不匹配：执行替换流程
- 工具替换：清理 SDK 缓存 → 清理旧工具 → 下载新工具 → 移动到预置目录
编译执行：
- 使用 general subagent 执行（避免主流程中断）
- 监听编译进程直至完成
- 语法错误：自动分析并修复，重试编译
- 配置错误：暂停并向用户确认后才修改

Basic Requirements:

Use
```
build.sh
```
script for compilation, do not use
hvigorw
Environment detection:
```
uname -s
```

Compilation Process:

Pre-compilation Cleanup (Mandatory):
- Use
```
cleanup_group.sh
```
  script
- Cleanup purpose: Ensure compilation results include all latest code
- ⚠️ Safety Notes: See Section 3.1 Cleanup Operation Safety Instructions
Preconditions for Static Test Suites (when compiling static suites):
- Validate hvigor version:
```
"6.0.0-arkts1.2-ohosTest-25072102"
```
- Version match: Skip tool replacement; Version mismatch: Execute replacement process
- Tool replacement: Clean SDK cache → Clean old tools → Download new tools → Move to preset directory
Compilation Execution:
- Use general subagent for execution (avoid main process interruption)
- Monitor compilation process until completion
- Syntax errors: Automatically analyze and fix, retry compilation
- Configuration errors: Pause and confirm with user before modification

7.2 Windows 环境编译

7.2 Windows Environment Compilation

根据关键词自动选择编译模式：

Automatically select compilation mode based on keywords:

7.2.1 ArkTS 动态 XTS 编译（默认）

7.2.1 ArkTS Dynamic XTS Compilation (Default)

编译方式：DevEco Studio IDE 或
```
hvigorw.bat
```
编译目标：
```
Build → Build OhosTest Hap(s)
```

参考文档：

modules/L4_Build/build_workflow_windows.md

第三章

Compilation Method: DevEco Studio IDE or
```
hvigorw.bat
```
Compilation Target:
```
Build → Build OhosTest Hap(s)
```

Reference Document: Chapter 3 of

modules/L4_Build/build_workflow_windows.md

7.2.2 ArkTS 静态 XTS 编译（arkts-sta）

7.2.2 ArkTS Static XTS Compilation (arkts-sta)

适用场景：基于 ArkTS 静态强类型语法的 XTS 测试工程

触发关键词：当用户提到以下任一关键词时自动启用：

技术术语：

arkts-sta

、

ArkTS静态

、

arkts static

、

ArkTS static

通用表述：

静态xts

、

静态 XTS

、

static arkts

、

static xts

操作描述：

编译静态

、

静态编译

、

静态工程编译

、

Windows静态编译

编译方式：PowerShell 脚本或
```
hvigorw.bat
```
命令行工具
Java 环境：必需配置 JAVA_HOME 环境变量
编译特点：
- 严格的静态类型检查
- 所有类型必须有显式注解
- 禁止使用 any 类型
- 所有字段必须初始化

参考文档：

modules/L4_Build/build_workflow_windows.md

第十章

⚠️ 重要提示：

默认使用动态编译模式

仅在用户明确提到静态相关关键词时启用静态编译模式

静态编译需要配置 Java 环境变量（JAVA_HOME）

📖 详细的编译文档: modules/L4_Build/

Applicable Scenario: XTS test projects based on ArkTS static strong-type syntax

Trigger Keywords: Automatically enabled when user mentions any of the following:

Technical Terms:

arkts-sta

ArkTS static

arkts static

ArkTS static

General Expressions:

static xts

static XTS

static arkts

static xts

Operation Descriptions:

compile static

static compilation

static project compilation

Windows static compilation

Compilation Method: PowerShell script or
```
hvigorw.bat
```
command-line tool
Java Environment: Must configure JAVA_HOME environment variable
Compilation Features:
- Strict static type checking
- All types must have explicit annotations
- Prohibit use of any type
- All fields must be initialized

Reference Document: Chapter 10 of

modules/L4_Build/build_workflow_windows.md

⚠️ Important Note:

Dynamic compilation mode is used by default

Static compilation mode is only enabled when user explicitly mentions static-related keywords

Static compilation requires configuring Java environment variable (JAVA_HOME)

📖 Detailed Compilation Documents: modules/L4_Build/

故障排除

Troubleshooting

📖 详细故障排除指南: docs/TROUBLESHOOTING.md

常见问题：

Q1: 生成的测试用例无法编译
Q2: 测试用例命名不符合规范
Q3: 测试设计文档与测试用例不一致
Q4: Linux 环境编译失败
Q5: 测试用例执行失败
Q6: 子系统配置文件未找到
Q7: 测试覆盖率分析不准确

📖 Detailed Troubleshooting Guide: docs/TROUBLESHOOTING.md

Common Questions:

Q1: Generated test cases cannot be compiled
Q2: Test case naming does not comply with specifications
Q3: Test design documents are inconsistent with test cases
Q4: Compilation fails in Linux environment
Q5: Test case execution fails
Q6: Subsystem configuration file not found
Q7: Test coverage analysis is inaccurate

版本信息

Version Information

当前版本: 1.20.2
创建日期: 2025-01-31
最后更新: 2026-02-12
兼容性: OpenHarmony API 10+
基于: OH_XTS_GENERATOR v1.7.0

Current Version: 1.20.2
Creation Date: 2025-01-31
Last Updated: 2026-02-12
Compatibility: OpenHarmony API 10+
Based On: OH_XTS_GENERATOR v1.7.0

版本历史

Version History

详细的版本历史记录请查看 CHANGELOG.md

最近更新：

v1.20.2 (2026-02-12): 简化重复内容，优化文档结构
v1.20.1 (2026-02-12): 优化核心工作流程和注意事项的重复内容
v1.20.0 (2026-02-11): 强化清理操作安全注意事项
v1.19.0 (2026-02-11): 强化预编译清理的强制执行
v1.18.0 (2026-02-11): 添加 hvigor 工具版本校验机制

Detailed version history can be found in CHANGELOG.md

Recent Updates:

v1.20.2 (2026-02-12): Simplified duplicate content, optimized document structure
v1.20.1 (2026-02-12): Optimized core workflow and duplicate content in notes
v1.20.0 (2026-02-11): Enhanced safety notes for cleanup operations
v1.19.0 (2026-02-11): Enhanced mandatory pre-compilation cleanup
v1.18.0 (2026-02-11): Added hvigor tool version validation mechanism

参考文档

Reference Documents

详细文档

Detailed Documents

模块化架构详解: docs/ARCHITECTURE.md
配置扩展机制: docs/CONFIG.md
使用方式详解: docs/USAGE.md
故障排除: docs/TROUBLESHOOTING.md

Modular Architecture Details: docs/ARCHITECTURE.md
Configuration Extension Mechanism: docs/CONFIG.md
Usage Details: docs/USAGE.md
Troubleshooting: docs/TROUBLESHOOTING.md

子模块文档

Submodule Documents

L1_Framework: modules/L1_Framework/
L2_Analysis: modules/L2_Analysis/
L3_Generation: modules/L3_Generation/
L4_Build: modules/L4_Build/

L1_Framework: modules/L1_Framework/
L2_Analysis: modules/L2_Analysis/
L3_Generation: modules/L3_Generation/
L4_Build: modules/L4_Build/

通用配置

General Configuration

通用配置: references/subsystems/_common.md

General Configuration: references/subsystems/_common.md

oh-xts-generator-template

Original

Translation

oh-xts-generator-template

oh-xts-generator-template

技能概述

Skill Overview

核心特性

Core Features

核心功能

Core Functions

适用场景

Applicable Scenarios

快速开始

Quick Start

三种使用方式概览

Overview of Three Usage Methods

核心工作流程

Core Workflow

配置扩展

Configuration Extension

配置优先级

Configuration Priority

输出规范

Output Specifications

测试用例编号(@tc.number)

Test Case Number(@tc.number)

测试设计文档规范（强制）

Test Design Document Specifications (Mandatory)

测试设计文档生成规则

Test Design Document Generation Rules

任务完成输出

Task Completion Output

任务完成摘要

Task Completion Summary

新增测试文件

New Test Files

新增测试设计文档

New Test Design Documents

修改文件

Modified Files

测试覆盖统计

Test Coverage Statistics

重要注意事项

Important Notes

1. @tc 注释块规范（强制）

1. @tc Comment Block Specifications (Mandatory)

2. hypium 导入规范（强制）

2. hypium Import Specifications (Mandatory)

3. 工程文件修改限制（强制）

3. Project File Modification Restrictions (Mandatory)

4. 清理操作安全注意事项（强制）

4. Cleanup Operation Safety Notes (Mandatory)

5. XTS Wiki 文档参考（强制）

5. XTS Wiki Document Reference (Mandatory)

6. ArkTS 语法类型识别（重要）

6. ArkTS Syntax Type Identification (Important)

7. ArkTS 静态语言语法规范校验（可选）

7. ArkTS Static Language Syntax Specification Validation (Optional)

8. 编译环境检测（强制）

8. Compilation Environment Detection (Mandatory)

7.1 Linux 环境编译

7.1 Linux Environment Compilation

7.2 Windows 环境编译

7.2 Windows Environment Compilation

7.2.1 ArkTS 动态 XTS 编译（默认）

7.2.1 ArkTS Dynamic XTS Compilation (Default)

7.2.2 ArkTS 静态 XTS 编译（arkts-sta）

7.2.2 ArkTS Static XTS Compilation (arkts-sta)

故障排除

Troubleshooting

版本信息

Version Information

版本历史

Version History

参考文档

Reference Documents

详细文档

Detailed Documents

子模块文档

测试用例编号(
`@tc.number`
)

Test Case Number(
`@tc.number`
)