第 1 章 业务背景：游戏策划文档与测试用例
本章目标：读懂游戏公司里"策划文档 → 测试用例"这条业务线。学完你能回答：
策划文档里有什么？测试要点和测试用例的区别是什么？什么是四象限？人工做这件事为什么慢、LLM 为什么合适？
1.1 策划文档：游戏的"需求说明书"
游戏公司和一般软件公司一样，先有需求文档再有开发。只不过游戏圈的需求文档叫策划文档（策划案），
写它的人叫策划（游戏设计师）。本系统处理的全部输入就是这类文档，所以先花点时间认识它。
一份典型的策划文档包含：
| 内容形态 | 例子 | 对测试的意义 |
|---|---|---|
| 正文规则 | "队伍上限为 3 人，队长退出后队伍解散" | 功能逻辑，测试的主要对象 |
| 数值表格 | 掉落率表、经验加成表、技能伤害表 | 边界值测试的来源 |
| 界面截图 | 队伍界面的 UI 设计图 | UI 布局与交互的验证依据 |
| 流程图 | 捉鬼玩法的分支流程 | 分支覆盖测试的依据 |
| 版本说明/设计意图 | "本期相对一期的改动点……" | 回归测试的范围圈定 |
| 模板章节 | "设计目的""表结构""数值设定" | ⚠️ 不是功能，是填表模板的固定栏目 |
最后两行值得注意：文档里相当一部分内容不是功能定义——版本说明是给项目组看的背景信息，
模板章节是 SVN 填表规范留下的固定骨架。它们混在正文里，如果一股脑喂给 LLM，会把"设计目的"这种
标题也当成功能提取出来（本工程真实踩过的坑，第 4 章详讲"模板章节守卫"）。
来源与格式：策划文档主要是 Word（.docx），少量是 Excel（.xlsx，通常是纯数值配置表如《BOSS 技能设计》）。
Word 文档内部是复杂的 XML（OOXML 格式）——标题、列表、表格、图片都以特定 XML 标签编码，
这是第 3 章 convert2md 要解决的核心问题。
1.2 测试用例：测试工程师的产出物
1.2.1 两级结构：测试要点（TP）与测试用例（TC）
成熟的测试团队不会直接从需求文档跳到具体步骤，而是分两级：
- 测试要点（Test Point / Test Dimension，本工程缩写 TP）：要测什么。 一条要点对应一个可验证的检查面，例如"验证队伍人数上限为 3 人"。 要点像是测试大纲——先保证想全了，再展开细节。
- 测试用例（Test Case / Test Scenario，本工程缩写 TC）：怎么测。 一条用例包含前置条件、逐步操作（test_steps）、每步的期望结果（expected_results）。 例如："创建队伍 → 邀请 2 人 → 邀请第 3 人 → 期望提示队伍已满"。
一条要点通常展开成多条用例（从不同角度验证同一要点）。本工程的 A3 批次实测：642 条要点 → 8863 条用例。
1.2.2 四象限：用例的四种视角
只写"正常操作能通过"的用例是不合格的测试。本工程强制每条要点从四个视角生成用例，
称为四象限（quadrant）：
| 象限 | 英文契约值 | 问的问题 | 例子（队伍人数上限） |
|---|---|---|---|
| 正向 | positive |
正常路径走不走得通 | 3 人正常组队成功 |
| 边界 | boundary |
边界值上行为对不对 | 恰好第 3 人加入成功；第 4 人被拒 |
| 反向 | negative |
异常输入/违规操作挡不挡得住 | 离线时邀请、重复邀请同一人 |
| 非功能 | non_functional |
性能/兼容/易用等横切面 | 3 人满员时队伍界面帧率、多语言显示 |
positive/boundary/negative/non_functional 这四个英文单词是跨模块的数据契约（生成端写、
评估端读、前端展示），全工程统一，不许改拼写。
术语盒：为什么叫"象限"？ 把"是否符合预期路径"作横轴、"输入是否正常"作纵轴画个坐标系，
用例就落在四个象限里。这个提法来自测试工程实践，强制四象限的意义是让 LLM 不偷懒——
大模型默认倾向生成正向用例（训练语料里最多），不强迫它就只想一半。
1.3 人工的痛点与 LLM 方案
1.3.1 人工怎么做，慢在哪
传统流程里测试工程师拿到策划文档后：通读 → 划功能清单 → 逐功能写要点 → 逐要点写用例。
痛点全是"人力密度"：
- 阅读负荷：60 页文档，混合着规则、数值、图、模板垃圾，人工剥离很费神；
- 覆盖遗漏：人会把注意力放在主流程上，反向和非功能象限系统性不足；
- 机械劳动：把一条规则翻译成"步骤 + 预期结果"的用例格式是纯模板活；
- 周期压力：版本迭代快，测试设计时间被压缩，质量让步。
1.3.2 LLM 为什么合适，以及它带来的新问题
前三条痛点恰好是 LLM 的强项：读长文档、按指令穷举视角、按格式模板产出。
但 LLM 不是银弹，它带来三类新的工程问题——本工程的大部分"机制"，都是为了对付这三类问题：
| LLM 的新问题 | 本工程的对策（教程对应章节） |
|---|---|
| 输出不可靠：会缺漏（漏象限、漏字段）、会编造（幻觉出不存在的数值） | 完整性门 + 有界重试（第 5 章）；faithfulness 评估（第 7 章） |
| 输出不规范：要求 JSON 它给你带围栏的散文；要求动词开头它写形容词 | safe_json_loads 四级修复 + 步骤契约（第 5、9 章） |
| 缺领域记忆：不知道这个项目以前的用例长什么样、什么算好 | few-shot 样例库 + RAG 检索注入（第 6 章） |
一句话总结本工程的哲学：让 LLM 做语义判断（读文档、写用例），让确定性代码做一切校验与兜底
（格式修复、完整性检查、层级修复、覆盖率计算）。后面每一章都会看到这个哲学的具体化身。
1.4 小结
- 策划文档 = 游戏的需求说明书，混合了规则、数值、图、以及不是功能的模板章节与版本说明；
- 测试产出分两级：测试要点（测什么）→ 测试用例（怎么测），用例分四象限（正/边/反/非功能）；
- 被测对象是原子功能实体，从文档里提取实体树是一切的起点；
- LLM 擅长读文档写用例，但带来不可靠/不规范/缺记忆三个新问题——本工程的核心机制基本都是对这三件事的工程化对策；
- 产物是五件套 JSON（SRC/ENT/PNT/CAS/EVAL），目录与命名契约第 2 章展开。