← ClaudeAtlas

dolphindb-testlisted

dolphindb 测试方案、测试文档及测试用例生成;用户提到“测试用例”或“测试文档”时触发;测试脚本使用 `.txt`后缀
dolphindb/DolphinX_Skill · ★ 8 · Testing & QA · score 63
Install: claude install-skill dolphindb/DolphinX_Skill
# DolphinDB 测试方案和用例生成 ## 1. 目标 - 为 DolphinDB 的计算函数、SQL 语句、存储引擎、流引擎、插件等功能生成测试方案和完整测试用例。 - 生成结果应符合现有项目风格,测试脚本通常使用 `.txt` 后缀。 - 先确认信息和规则来源,再生成内容。 - 除非用户明确要求“草案 / 骨架 / 代表性用例 / 主干用例”,否则默认输出完整版测试方案和完整版测试用例,不得降级为概括性结果。 ## 2. 输入信息(不全就先追问) - 待测对象:函数名 / SQL / 模块名。 - 设计文档:用户提供路径,或明确“无”。 - 测试文档:用户提供路径(若已提供则直接用于生成测试用例)。 - 输出路径:目标目录。 若信息不足,继续追问,直到能唯一定位函数并确定生成规则。 ## 3. 执行流程(按顺序) ### 步骤 1:确认设计文档 - 先确认用户是否已提供设计文档。 - 已提供:先读取并提炼规则。 - 未提供:在[参考文档](references/dolphindb_docs) 中查找是否存在函数对应文档 - 若两者都没有:先不要输出,向用户确认接口用法 - 若用户已提供测试文档(测试场景文档/测试要点文档),则直接进入“步骤 6:生成测试用例”;步骤 2-5 改为按需校验,不作为阻塞前置。 ### 步骤 2:理解待测对象行为 - 读取完整待测对象实现,判断待测对象属于计算函数、SQL、存储引擎、流引擎、插件中的哪一类。 - 判断各个参数之间是否存在依赖关系,用于后续的测试场景设计(如参数间的依赖关系、排序、分区、键值列等)。 - 明确输入类型、返回值、异常条件、副作用和隐含约束。 - 思考是否有其他语言或系统中类似功能的测试可以参考。 - 不清楚时先补读调用方或现有测试,禁止猜测。 ### 步骤 3:参考既有测试 - 根据步骤 2 的判断,在 [代码示例](#6-代码示例) 模块中查找相关测试。 - 优先参考:同名函数旧测试、同模块测试、同类型函数测试模板。 - 提炼命名、断言、数据准备、异常校验模式。 ### 步骤 4:设计覆盖场景 - 先列出要覆盖的场景,并按“异常场景在前、正常场景在后”的固定顺序组织。 - 测试要点清单中的每一条都必须在场景设计阶段映射为至少一个原子场景;若某条无法落地,必须标记原因并列入“待确认项”,不得静默省略。 - 将测试要点拆成“不可再拆”的原子场景。禁止把多个异常测试点写到一个场景里;每个场景只验证一个明确行为。 - 在开始设计任何正常场景前,必须先列完全部异常场景;异常场景与正常场景不得交错排列。 - 生成测试用例前,必须先在内部完成“参数-类型-结构-值域-联动约束”覆盖矩阵;若该矩阵未完成,不得输出最终测试用例。 - 若部分行为文档未明确: 1. 对文档已能确认的非法输入、边界输入、支持输入,照常生成完整用例。 2. 对无法确认预期的行为,单列“待确认项”。 3. 不得因为局部不确定而省略其他已知应覆盖场景。 - 若待测对象属于计算函数 1. 获取函数使用说明并判断函数类型(标量函数、聚合函数、窗口函数、序列函数等)。 2. 列出测试要点,遵循以下步骤:(1)参数数量校验(2)对每一个参数逐一列出异常情况,包括NULL、数据类型错误、数据形式错误、不满足设计文档的输入(3)正确性用例,对每一个参数逐一列出正确性场景,对函数整体列出正确性场景(4)参考[计算函数测试要点](references/test_docs/computational_function_tes