4. 目录

4.7 如何理解 evidence_level

在 Treeify 的部分生成结果中，你会看到一个名为 evidence_level 的字段。

这个字段用于标识：当前内容与输入材料之间的依据强度。
它可以帮助你快速区分：

哪些内容是需求文档中明确写出的
哪些内容是根据上下文合理推导出的
哪些内容是基于需求类型或通用测试经验补充出来的

理解 evidence_level，可以帮助你更高效地审查 AI 生成结果，并判断哪些内容可以直接采纳，哪些内容需要进一步确认，哪些内容更适合作为补充参考。

为什么需要 `evidence_level`

在 AI 参与测试设计时，并不是所有生成内容都具有同样强的来源依据。

有些内容直接来自需求文档本身。
有些内容虽然没有被原文逐字写出，但可以根据上下文合理推出。
还有一些内容则更接近于某类需求常见的测试方向，或者某个领域中的通用测试关注点，但并不一定是当前项目中已经确认的事实。

Treeify 使用 evidence_level，就是为了把这种差异明确标出来。

这样做可以帮助你：

更快地审查生成结果
识别哪些内容直接来源于需求材料
发现哪些内容可能需要补充确认
降低把“推测内容”误当成“明确需求”的风险

`evidence_level` 的可选值

目前，Treeify 使用以下四种取值：

explicit
implied
inferred_type
domain_common

它们分别代表不同层级的依据强度。

1. `explicit`

explicit 表示：当前内容在输入材料中被明确写出。

这是依据最强的一类。
如果某个规则、字段、角色、状态、条件或约束，在需求文档中已经被直接说明，那么对应生成内容通常就应标记为 explicit。

示例

需求文档中写明：

提交请假申请后，状态变为“待审批”。
只有主管角色可以执行审批或驳回操作。

生成结果中：

提交申请后状态变为“待审批” → explicit
只有主管可以审批或驳回申请 → explicit

如何理解

当你看到 explicit 时，说明这部分内容应当能够直接回溯到输入材料。
审查时，重点是确认 AI 提取是否准确，而不是确认它是否“猜对了”。

2. `implied`

implied 表示：当前内容没有被原文直接写成一句完整结论，但可以根据上下文合理推出。

这种情况通常出现在：需求文档通过流程、页面行为、示例描述、规则组合等方式间接表达了某些信息，但没有专门把它单独写成一句明确陈述。

示例

需求文档中写明：

员工可以在审批完成前撤回请假申请。

文档里未必直接写了：

撤回操作仅在“待审批”状态下可用。

但根据业务流程，Treeify 可能生成：

仅在审批完成前允许撤回申请 → implied

如何理解

当你看到 implied 时，应检查这项结论是否真的被上下文支持。
如果结论与需求描述一致、推导过程合理，就可以保留。
如果上下文支撑不足，或者存在多种解释方式，就应当谨慎处理，必要时补充需求说明或手动修正。

3. `inferred_type`

inferred_type 表示：当前内容并未直接出现在输入材料中，而是基于需求类型推导出的常见测试方向。

这种情况通常出现在 Treeify 识别出某类典型需求结构后，例如：

状态流转
审批流程
权限控制
表单输入
增删改查
文件上传下载
API 请求与响应

在这些场景中，即使需求没有逐条写出所有测试点，Treeify 也可能根据该类需求的典型特征，补充一些通常需要关注的测试方向。

示例

需求文档中写明：

用户可以提交报销单。

文档中没有明确写“必填校验”或“金额格式校验”，但 Treeify 可能生成：

检查提交前的必填项校验 → inferred_type
检查金额格式不合法时的提示与拦截 → inferred_type

这些内容并不是需求中明确承诺的业务规则，但在“表单提交类需求”中通常具有较高的测试相关性。

如何理解

当你看到 inferred_type 时，应当把它理解为：
这是 AI 基于需求类型补充出的测试方向，可能很有价值，但不应直接视为已经被需求确认的事实。

它通常适合用于扩展测试覆盖，但在正式采纳前，仍应结合当前项目实际进行判断。

4. `domain_common`

domain_common 表示：当前内容主要来自领域常识或通用测试经验，而不是当前输入材料中的直接依据。

这是四类中依据最弱的一类。
它通常适合作为提示性补充，用于提醒你关注某些领域中常见但当前文档未明确涉及的风险点。

示例

对于一个支付相关需求，Treeify 可能生成：

检查支付场景下的重复提交处理 → domain_common
检查交易超时后的重试行为 → domain_common

这些内容在很多支付系统中都很重要，但如果当前需求材料并没有写明相关机制，也没有从上下文中体现出来，那么它们就不属于当前项目中已确认的事实。

如何理解

当你看到 domain_common 时，不应默认它已经属于当前需求范围。
更合适的做法是将其视为一种“可参考的测试建议”。

如果它确实符合你的项目和测试边界，可以保留并细化；
如果它超出了当前需求范围，则可以删除，或者留待后续补充确认。

如何审查不同 `evidence_level` 的内容

一个较实用的审查顺序是：

先看 explicit
确认需求中明确写出的信息是否被准确提取。
再看 implied
确认上下文是否足以支持这项结论。
再看 inferred_type
判断这些基于需求类型补充的测试方向是否适用于当前场景。
最后看 domain_common
将其视为补充性建议，结合当前项目边界决定是否保留。

这种方式可以帮助你把“来源明确的事实”和“AI 扩展出的建议”区分开来，更有针对性地进行审查。

在编辑和修正时如何使用 `evidence_level`

当你发现某条生成内容看起来不太确定时，evidence_level 可以帮助你决定下一步应该怎么处理。

如果是 `explicit`

回到原始输入材料，确认提取内容是否准确。

如果是 `implied`

检查上下文是否真的支持这个结论。
如果支撑不足，应修正或删除。

如果是 `inferred_type`

判断这类测试方向是否适合当前需求。
如果适合，可以保留作为扩展覆盖；如果不适合，可以删除或改写。

如果是 `domain_common`

把它当作提示性建议，而不是默认需求。
只有在确认它符合当前项目边界时，才建议正式保留。

示例：同一条需求下的不同 `evidence_level`

需求内容

提交请假申请后，申请进入“待审批”状态。
主管可以审批通过或驳回申请。
员工可以在审批完成前撤回申请。

可能的生成结果

提交申请后进入“待审批”状态 → explicit
只有主管可以执行审批或驳回操作 → explicit
撤回操作仅在审批完成前有效 → implied
检查重复审批操作的处理逻辑 → inferred_type
检查并发更新下的状态冲突问题 → domain_common

如何理解这个结果

前两项直接来自需求原文，因此是 explicit。
第三项虽然不是原文逐字表达，但可以从业务规则中合理推出，因此是 implied。
第四项体现的是审批流类需求中常见的测试方向，因此是 inferred_type。
第五项则属于更广义的系统风险和测试经验补充，因此是 domain_common。

通过这种区分，你可以更清楚地知道：哪些内容是需求事实，哪些内容是合理推导，哪些内容是测试扩展建议。

一个重要提醒

evidence_level 并不表示：

这条内容一定正确或一定错误
这条内容一定应该保留或删除
这条内容一定有用或没有用

它只表示：这条内容与输入材料之间的依据强度有多高。

较低的 evidence_level 不等于内容错误。
较高的 evidence_level 也不代表无需审查。

evidence_level 的作用，是帮助你更透明地理解生成依据，从而更高效、更安全地完成结果审查。

推荐的使用方式

在日常使用 Treeify 时，你可以这样理解这四类内容：

explicit：明确来自需求文档的内容
implied：可由上下文合理推出的内容
inferred_type：基于需求类型补充的测试方向
domain_common：基于领域经验或通用测试知识的建议

如果你的项目更强调需求追溯性，可以优先关注 explicit 和 implied。
如果你的目标是尽可能扩大测试覆盖，也可以结合 inferred_type 和 domain_common 一起使用，但应保留必要的审查和确认步骤。

总结

evidence_level 用于帮助你理解：Treeify 生成的每一条内容，和输入材料之间到底是什么关系。

explicit = 输入材料中明确写出的内容
implied = 根据上下文合理推出的内容
inferred_type = 根据需求类型推导出的常见测试方向
domain_common = 基于领域经验或通用测试知识补充的建议

正确理解 evidence_level，可以帮助你更高效地审查结果，提升需求追溯性，并更清楚地决定哪些内容应保留、确认、修改或删除。

4.6 技能中心

上一页

5.1 提升 AI 理解效果的输入建议

下一页