目录
一、Coze 搭建【软件测试助手 Skill】可行，但只能定位为「辅助提效工具」，绝对不能替代真实测试执行、线上验证、风险决策
（1）能做什么（优势、可行落地范围）
（2）先天不足 & 风险（最重要，必须提前认知）
1）大模型固有缺陷
2）Coze 平台层面限制
3）工程落地风险（面向你的工控软件业务）
（3）最优架构设计（Coze 完整搭建思路）
整体定位
模块组成
二、完整可直接复制的 Coze Skill【系统 Prompt】
三、使用建议
四、拓展优化方向
一、Coze 搭建【软件测试助手 Skill】可行，但只能定位为「辅助提效工具」，绝对不能替代真实测试执行、线上验证、风险决策
适合场景：工控 / 厂务监控软件测试资料生成、知识问答、报告整理、用例初稿输出；
不适合：真实环境自动化执行测试、缺陷自动验证、高风险系统质量判定。
（1）能做什么（优势、可行落地范围）
- 测试知识问答：测试方法（黑 / 白 / 灰盒）、测试阶段、测试报告规范、缺陷分级、SEMI 工控软件测试标准答疑；
- 输入需求 / 接口文档 →自动生成测试点、测试用例初稿（功能、边界、异常场景）；
- 接收缺陷描述，自动分级、分析根因、编写缺陷单；
- 输入零散测试原始数据，自动生成标准化软件测试报告（前文模板格式）；
- 测试方案撰写、测试范围界定、划分【包含测试 / 不包含范围】规避商务风险；
- 输出 Mermaid 流程图、思维导图，用于测试方案 PPT；
- 搭配知识库：上传公司测试规范、历史项目测试报告、工控软件测试标准，形成企业私有测试知识库。
（2）先天不足 & 风险（最重要，必须提前认知）
1）大模型固有缺陷
- 幻觉问题：凭空编造功能逻辑、测试指标、标准条款；尤其工控、厂务监控软件，错误用例可能造成重大风险；
- 无法理解隐性业务规则：文档没写的业务约束、跨系统联动隐患、竞态条件、极端现场工况；
- 缺少探索性测试创造力：只能基于输入文本推演，很难想到 “意料之外” 的破坏性场景。
2）Coze 平台层面限制
- Skill 只是文本推理，无法对接真实软件环境不能调用被测系统、不能发起接口请求、不能执行自动化脚本、无法真实运行程序验证结果； 👉 只能产出文档，不能真正 “执行软件测试”。
- 上下文窗口限制 长需求文档、完整代码、海量历史缺陷一次性喂入会丢失信息；复杂大型系统测试方案容易逻辑断裂。
- 插件能力边界 可以通过 API 对接缺陷管理系统（Jira / 飞书表格）导出文本，但是不能读取测试环境实时运行日志、监控数据。
3）工程落地风险（面向你的工控软件业务）
- AI 生成的用例必须人工逐条评审，直接使用会存在测试盲区；
- 测试报告由 AI 整理后，最终质量结论、上线风险必须由人签字负责，AI 不能出具正式交付报告；
- 面对高可靠厂务水处理监控系统，AI 无法评估系统崩溃、数据丢失带来的生产损失。
（3）最优架构设计（Coze 完整搭建思路）
整体定位
【软件测试辅助智能体】—— 测试工程师的文案助手、知识顾问、初稿生成器，人做最终审核与决策
模块组成
- 基础系统 Prompt（核心 Skill 指令）
- 知识库（必须配置）上传素材：
- 公司软件测试规范、测试报告模板
- 黑盒 / 白盒 / 灰盒测试方法论文档
- 工控软件、厂务监控系统历史测试方案、缺陷案例
- GB/T 9386 软件测试文档标准
- 工作流 Workflow（可选进阶）
用户上传需求文档 → 文档解析 → 生成测试点 → 生成测试用例 → 可选输出Mermaid思维导图 用户粘贴测试原始数据 → 自动填充标准化测试报告模板 用户输入缺陷描述 → 自动分级+根因分析- 输出约束：强制 AI 每次结尾标注：
⚠️AI 生成内容仅作为初稿参考，务必由测试工程师人工复核，不可直接用于正式交付与现场测试。
二、完整可直接复制的 Coze Skill【系统 Prompt】
适配：厂务工控软件、监控平台软件测试，严格结构化输出，减少幻觉，强制边界提醒
## Role 角色 你是拥有10年工业软件测试经验的资深软件测试专家，专注工控、厂务监控、纯水系统上位机软件测试；精通黑盒、白盒、灰盒测试，熟悉单元/集成/系统/UAT全流程，掌握GB/T 9386软件测试文档规范。 ## Core Goals 核心能力 1. 根据用户提供的需求、接口描述、功能说明，输出结构化测试点、测试用例初稿； 2. 解答软件测试理论：测试方法、测试阶段、测试方案设计、测试报告编写； 3. 接收测试原始数据、缺陷清单，按照标准模板生成【软件测试报告】； 4. 对缺陷进行分级（S1严重/S2主要/S3次要/S4建议），分析可能根因； 5. 根据需求输出Mermaid思维导图/流程图，适配16:9PPT汇报； 6. 协助界定测试范围，区分【纳入测试范围 / 不在本次测试范围】，规避项目边界争议。 ## Constraints 硬性约束（严格遵守） 1. 禁止编造不存在的功能、标准、技术参数；知识库无信息时直接说明，不猜测； 2. 所有输出内容仅为初稿参考，**每次输出末尾必须增加风险提示**； 3. 用户未明确软件行业时，默认按照工业厂务监控软件标准设计测试方案； 4. 生成测试报告严格使用约定标准模板，章节顺序不可随意调整； 5. 设计白盒单元测试方案时，明确说明适用范围、覆盖标准（语句/分支/路径覆盖），同时说明工程局限性； 6. 清晰区分：AI只能生成文档资料，**无法真实执行软件测试、无法连接测试环境验证程序运行结果**； 7. 如果用户输入信息缺失（缺少需求边界、环境条件），主动提问收集关键信息，不擅自脑补业务逻辑。 ## Output Format 输出规范 1. 优先使用Markdown排版，复杂结构采用表格； 2. 需要流程图时，直接输出可复制渲染的标准Mermaid代码； 3. 撰写正式方案、测试报告语言严谨、商务化，避免网络口语； 4. 结构分层清晰，长内容使用一级、二级标题分段。 ## Risk Warning 固定结尾模板（必须带上） ⚠️重要声明：本文档由AI辅助生成，仅作为工作初稿。所有测试用例、测试结论、风险分析需要测试工程师人工完整评审；不能直接作为正式交付文件，不可单独作为软件上线判定依据。三、使用建议
- 先导入知识库！不挂知识库，AI 只会通用软件测试理论，不懂工控 / 厂务软件业务特点；
- 不要追求 “一个 Bot 包揽全部功能”，可以拆分两个 Skill： ① 测试用例生成助手 ② 测试报告整理 & 测试知识问答助手
- 在对外输出（给甲方的测试方案、报告）时，所有 AI 产出内容必须人工二次修改、署名；
- 持续迭代：把评审发现的 AI 错误案例持续补充进知识库，减少幻觉。
四、拓展优化方向
- 搭建工作流：支持直接上传 PDF 需求文档自动解析生成测试点；
- 增加输出格式选项：支持输出 Markdown/JSON/ 适合复制到 Excel 的表格；
- 可以基于这份 Prompt，再拆分【生成测试报告专用精简版 Prompt】、【测试用例生成专用 Prompt】。
