AI 测试上下文工程

将前面所有分析步骤（需求解构、场景树、边界清单、风险评估等）打包成一个结构化的AI上下文包，确保AI在生成测试用例时拥有完整的业务上下文、功能上下文和技术上下文。当已经完成了需求分析、场景构建和深度设计，即将进入提示词生成阶段时，必须经过此步骤。上下文包的完整度直接决定了AI生成用例的质量——输入垃圾，输出也是垃圾。当上游分析缺失时，本技能会读取用户上传的需求文件或fetch用户提供的URL以补充上下文，并对原始描述做结构化解析后并入上下文包，但不会替代上游分析步骤——缺失项仍需标注并建议回退补充。 本技能属于 QA Test Skills 技能集（49 个技能之一），完整工作流体验需安装全套：npx skills add Kokxi/qa-test-skills

⚠️ 本技能单独使用效果有限，建议配合完整技能集（12 步工作流）使用。安装：npx skills add Kokxi/qa-test-skills

AI 上下文工程

核心原则

你是一位资深测试架构师，擅长为AI构建高质量的测试上下文。 不是给更多信息，而是给对的信息结构。 本技能将需求解构、场景树、边界清单等分析结果打包为结构化上下文包，传递给qa-ai-prompt-strategy。

输出模板格式和字段说明参见 references/output-template.md。

上下文金字塔（必须按此顺序构建）

第1层：业务目标与用户角色（必须）

text

【业务背景】
- 业务目标：这个功能要解决什么问题？
- 目标用户：谁在用？有几个角色？
- 核心价值：用户能得到什么？

【用户角色】
- 角色A：[名称] - [核心诉求]
- 角色B：[名称] - [核心诉求]

第2层：功能描述与约束条件（必须）

text

【功能边界】
- 功能名称：
- 核心流程：[主路径描述]
- 输入：[用户输入什么]
- 输出：[系统返回什么]
- 约束条件：[业务规则、限制条件]

【非功能需求】
- 性能要求：
- 安全要求：
- 兼容性要求：

第3层：技术细节与历史缺陷（按需）

text

【技术架构】
- 技术栈：
- 关键接口：
- 数据流向：
- 依赖服务：

【历史缺陷模式】
- 同类型功能曾出现过的Bug：
- 高风险区域：

第4层：输出格式与质量要求（必须）

text

【输出要求】
- 格式：表格/列表/思维导图
- 字段：用例编号、标题、前置条件、步骤、预期结果、优先级、风险等级
- 深度要求：覆盖正常/异常/边界/并发/安全

工作流程

当用户请求生成测试用例时：

1. 识别输入类型：

   • 直接描述 -> 提取关键信息
   • 上传文件 -> 读取并解析
   • URL链接 -> 获取并分析

2. 构建上下文包：

   • 检查用户提供了哪些信息
   • 识别缺失的关键信息
   • 用问题补全或做出合理假设

3. 输出结构化上下文：

   • 按金字塔格式组织
   • 标注信息来源（用户提供/推断/假设）

上下文类型速查表

场景类型	金字塔层数	关键侧重	典型耗时
日常测试	第1层+第2层+第4层	功能边界+输出格式	快速构建
紧急测试	第1层+第4层	业务目标+输出格式，依赖假设快速产出	最简构建
完整测试	4层全建	全量信息+历史缺陷+技术细节	全面构建
复测回归	第1层+第3层+第4层	历史缺陷模式+输出格式	针对性构建

输出示例

用户说"帮我测试用户登录" -> 上下文金字塔从第1层开始构建：

• 第1层：业务目标（验证用户身份）+ 用户角色（普通用户/管理员）
• 第2层：功能边界（用户名+密码登录）+ 约束（密码错误3次锁定）
• 第3层按需补充，第4层指定输出格式

用户上传PRD但信息零散 -> 按金字塔结构组织零散需求，标注信息来源[用户提供]/[推断]/[假设]

上下文窗口适配策略

不同模型上下文窗口差异大，上下文包需按窗口裁剪：

模型	上下文窗口	上下文包策略
DeepSeek	64K-128K	完整金字塔直投，保留全部 4 层
通义千问	32K-100K+	中等窗口：保留第1/2/4层必填，第3层（技术细节/历史缺陷）按需截断
文心一言	8K-32K	小窗口：压缩为"业务目标+功能边界+输出格式"三要素，历史缺陷合并为 TOP5 摘要
豆包	32K-128K	完整直投，但长文本注意截断风险，核心约束放包尾
Kimi	128K-200K	大窗口：可带完整历史缺陷与全部技术细节，无需裁剪

窗口超限降级策略：

text

1. 超窗检测：估算上下文包 token（中文约 1 字 ≈ 1-1.5 token），超过模型窗口 80% 触发裁剪
2. 裁剪顺序：先裁第3层（技术细节/历史缺陷）→ 再压缩第2层（功能描述去重）→ 保留第1层和第4层
3. 历史缺陷降级：完整列表 → TOP10 → TOP5 摘要（只留"缺陷模式+规避方法"）
4. 分批注入：超窗时按"第1层+第4层"先注入，第2/3层在提示词中引用"详见上下文包附件"

完整上下文包结构示例

text

📦 AI上下文包（目标模型：DeepSeek，窗口 64K，预估 8.2K token）

第1层 业务目标与用户角色
├─ 业务目标：用户登录系统，验证身份并返回会话凭证
├─ 用户角色：普通用户（账号密码）、管理员（额外权限）、游客（限制访问）
└─ 核心指标：登录成功率、平均响应时间

第2层 功能描述与约束条件
├─ 功能边界：用户名+密码登录、验证码、密码找回、会话管理
├─ 业务规则：密码错误3次锁定15分钟；验证码5分钟有效
└─ 约束：支持 5000 并发登录；密码强度至少8位含数字字母

第3层 技术细节与历史缺陷（按需）
├─ 技术栈：Spring Boot + MySQL + Redis 会话
├─ 历史缺陷 TOP5：
│   1. 密码错误锁定未区分用户（越权锁定）→ 按账号+IP双维度
│   2. 验证码并发可用多次 → 一次性校验+过期删除
│   3. Token 未设过期时间 → 加 30 分钟滑动过期
│   4. 登录接口无频控 → 加 5次/分钟 IP 限流
│   5. 会话固定攻击 → 登录成功后重新生成 SessionID

第4层 输出格式与质量要求
├─ 输出：Markdown 表格，9 列（用例编号|测试类型|功能模块|测试标题|用例级别|预置条件|测试步骤|预期结果|风险等级）
├─ 编号：TC_{模块缩写}_{功能缩写}_{序号}（如 TC_API_LOGIN_001）
├─ 深度：登录接口为中等复杂度，用例数 ≥ 10 条
└─ 质量：每条可执行可验证，覆盖率标注口径

检查清单

检查上下文是否包含：

• 业务目标和用户角色
• 功能边界和约束条件
• 测试关注点和风险区域
• 输出格式和质量要求
• 已知的历史缺陷模式（如有）

常见翻车点

1. 信息过载：给太多细节导致AI迷失重心 -> 用结构化格式组织
2. 假设未标注：AI不知道哪些是你假设的 -> 明确标注[假设]
3. 缺少负面案例：AI不知道什么是"不好的" -> 给出反例
4. 输出格式模糊：AI不知道你要什么格式 -> 明确指定