从新手到专家：2026年测试用例的状态工具选型完全指南

从新手到专家：2026年测试用例的状态工具选型完全指南

团队测试用例从 800 条涨到 8000 条之后，最先失控的往往不是用例数量，而是“通过”这个状态：有人表示本轮执行通过，有人表示历史上通过过，有人把未执行也标成通过，还有人把失败后已修复的用例直接改成通过。选测试用例状态工具，真正要解决的不是状态下拉框够不够多，而是每一次状态变化能不能说清楚：谁在什么版本、什么环境、基于什么证据，做出了什么判断。

一、先讲核心结论：先选状态模型，再选工具

1. 工具的价值不在状态数量，而在状态语义

我判断一套测试用例工具是否适合团队，第一眼不会数它有多少种状态，而会追问：状态描述的是用例本身、评审流程，还是一次具体的执行结果？这三件事经常被混在同一列里，导致管理者看到一片“通过”，却无法判断它指的是用例写得合格，还是某个版本刚刚执行成功。

较稳妥的设计，是把用例生命周期和执行结果分开管理。用例可以经历“草稿、待评审、已批准、已弃用”；执行记录则针对某个版本、环境和执行轮次，记录“未执行、通过、失败、阻塞、跳过”。同一条已批准用例，可以在版本 A 通过、版本 B 失败、版本 C 尚未执行。这不是状态冲突，而是不同执行记录的真实情况。

选型结论可以压缩成一句话：小团队优先避免状态混乱，中型团队优先追踪执行证据，大型团队优先保证权限、集成和审计的一致性。不应为了显得专业，把所有可能的状态都塞进一个下拉框。状态越多，团队理解成本越高；状态越少，若缺少关联字段和历史记录，又会丢失关键决策信息。

对于多数团队，我建议先从两条状态链开始，而不是从工具功能清单开始：

• 用例治理链：草稿、待评审、已批准、已弃用。
• 执行结果链：未执行、通过、失败、阻塞、跳过。
• 执行记录的必要上下文：产品版本、测试环境、执行人、执行时间、测试轮次，以及失败时关联的缺陷或证据。

这套起点并不意味着所有组织都要照搬。安全测试、合规验证、硬件兼容性测试可能需要额外状态或审批门槛；重点是增加状态之前，先明确它代表新的业务含义，而不是给旧含义换个名字。

2. 不要把工具选型变成“功能越多越好”

功能清单很容易制造虚假的确定感。一个工具可以同时有测试计划、用例库、执行面板、缺陷关联、自动化接口和报表，但如果执行记录只能覆盖当前状态、不能还原上一次结果，报表再漂亮也无法回答“上个版本为什么放行”。反过来，轻量工具即使功能不多，只要团队规模小、流程固定、证据要求有限，也可能更省成本。

我通常把选型拆成三个问题：当前最常见的状态失真是什么；哪些人或系统会改变状态；状态变化之后，团队需要据此做什么决策。工具功能只有能解决这三个问题之一，才值得进入试用清单。

3. 先建立最低可用模型

如果团队目前没有统一规则，可以先用四个问题验证模型。第一，是否区分用例是否有效与本轮执行是否成功？第二，失败是否能指向缺陷、日志或复现步骤？第三，未执行和阻塞是否会被错误地算进通过率？第四，状态变化是否有时间、人员和历史记录？至少有一个问题回答不出来，就先补规则，不要急着买更复杂的工具。

二、真实场景：状态混乱通常如何拖慢发布

1. 一条“通过”可能掩盖四种不同事实

设想一个电商团队准备发布支付改版。测试人员打开用例列表，发现 96% 的用例状态是“通过”。但进一步检查后，才发现这个比例混合了四种事实：有些用例本轮执行通过；有些用例上个版本通过、本轮没有执行；有些用例被标为通过但实际只验证了主流程；还有些失败用例修复后没有重新执行，执行状态被手动覆盖。

问题不在于团队不认真，而在于工具只展示一列“当前状态”，没有把版本和执行轮次作为记录边界。测试负责人无法从一个汇总比例判断本次发布的风险；开发人员也无法分辨“失败已修复但待回归”和“仍然失败”。状态字段从辅助信息变成决策噪声。

此时团队通常会采取两种临时办法：在状态名里追加“本轮”“历史”“待回归”等字样，或在备注中写自由文本。短期看似解决了沟通问题，长期却会形成几十种近义状态和无法统计的备注。如果状态表达的是时间、版本或原因，就应考虑把它拆成执行轮次、版本或阻塞原因，而不是继续扩充状态枚举。

2. 版本、环境和轮次，是执行结果的边界

“用例通过”并不是完整结论。更完整的说法应类似：“结账流程用例 TC-PAY-018，在 5.4.2 候选版本、预发布环境、Chrome 桌面端、本轮回归中通过，执行人于 14:32 完成，证据链接已保存。”团队不一定需要把每个字段都写进状态标签，但工具必须能把这些信息放在同一条执行记录中。

不同业务还会有不同的边界条件。移动端可能要记录系统版本和设备型号；数据产品可能要记录数据批次与时间窗口；嵌入式产品则可能需要固件版本、硬件批次和实验室设备。选型时先列出会改变测试结论的上下文，才能判断工具的数据模型是否够用。

3. 测试对象不同，状态治理重点也不同

这些场景说明，工具选型的关键不只是“支持测试用例管理”，而是它如何描述团队实际验证的对象。一个字段模型若无法表达测试上下文，团队就会被迫在标题、标签和备注里创造第二套数据库。

三、常见误区：看起来省事，后续却更难治理

1. 误区一：把所有状态塞进同一个下拉框

“待编写、待评审、已评审、待执行、执行中、通过、失败、阻塞、已修复、待回归、已关闭、废弃”看上去覆盖全面，实际把用例生命周期、执行进度、执行结果、缺陷处理状态混在一起。一个用例同时是“已评审”和“失败”并不矛盾，但单选下拉框要求它只能选一个，最终必然丢信息。

我会先给每个候选状态做语义归类：它描述内容质量、审批进度、执行结果，还是缺陷生命周期？若一个词无法明确归类，通常意味着定义不清，应该先删除或重写。状态枚举是团队契约，不是术语收纳盒。

2. 误区二：把“未执行”从报表里隐藏

未执行不是失败，但也不是通过。把它从分母中排除，可能会让通过率显得异常漂亮；把它算作失败，又会混淆执行质量与覆盖缺口。更好的报表至少并列显示通过、失败、阻塞、跳过和未执行的数量，并明确通过率的计算口径。

例如，若 100 条计划用例中 70 条通过、10 条失败、5 条阻塞、15 条未执行，不能只报告“通过率 87.5%”，因为这个数字可能是 70 除以已执行的 80 条。它可以作为“已执行用例通过率”，但不能代替“计划覆盖完成度”或“发布风险”。报表标题和分母定义必须同时出现。

3. 误区三：把缺陷状态复制到测试用例上

缺陷可以是新建、处理中、已修复、已关闭；测试执行可以是失败、阻塞或通过。修复完成并不等于回归通过。若缺陷一关闭，关联用例自动变成通过，团队就失去了“修复之后是否重新验证”的证据。

建议保持三层关系：用例定义验证什么；执行记录说明某版本实际结果；缺陷记录说明已发现的问题如何处理。三者可以互相关联，但不应互相覆盖状态。这样既能查看未关闭缺陷，也能识别“缺陷已修复但回归尚未完成”的发布风险。

4. 误区四：自动化测试有结果，手工测试就可以共用同一套规则

自动化流水线常常可以提供提交号、构建号、开始和结束时间、运行环境、日志地址等上下文；手工执行则需要测试人员补充步骤、观察结果、截图或数据样本。如果工具只围绕自动化结果设计，手工测试可能只能留下一个“通过”；如果只围绕表单设计，自动化结果则会因为录入成本过高而无人维护。

试用时要分别走一遍手工执行与自动化回传。检查自动化失败是否能关联到具体用例而非只关联到整条流水线；检查重跑是否会保留第一次失败；检查手工执行是否支持批量分配、快速录入和必要证据附件。

5. 误区五：把自定义能力当成成熟度

自定义状态、自定义字段和自定义工作流确实有价值，但自由度越大，越容易产生各团队各自为政。A 团队的“关闭”是作废，B 团队的“关闭”是执行结束；总部报表把两者合并后，数字看起来统一，含义却已经不统一。

我会把自定义能力分成两类来评估：允许团队在不破坏公共统计口径的范围内扩展，通常是优势；允许每个空间随意重定义核心状态且没有治理机制，则是风险。问供应商“能不能配置”不够，还要问“谁有权限配置、变更如何审批、旧数据如何迁移、跨团队报表怎样归一”。

四、专业判断逻辑：用六个维度做选型

1. 先做状态字典，而不是先做产品演示

选型之前，我建议团队用一页纸写出状态字典。每个状态至少要有名称、定义、进入条件、退出条件、能否回退、是否参与统计、谁可以修改。写不清的状态先不要进入工具配置，否则演示时的流畅感会掩盖后续治理成本。

状态字典不是一份永久不变的制度。团队可以在试运行后调整，但每次调整都应说明是修正定义、增加业务场景，还是解决工具限制。否则，状态名变化本身会成为数据迁移和历史报表的负担。

2. 六个维度分别打分，避免被演示效果带偏

评分表的用途不是制造绝对精确的总分，而是防止团队只因界面顺眼或某项功能亮眼，就忽略基本能力。建议把每项按 1 到 5 分评分，并给“1 分、3 分、5 分”写出可观察的锚点。无法在试用中验证的项目，不要给满分。

权重可以调整。例如，受审计要求约束的团队应提高权限与证据留存权重；自动化占比高的团队应提高集成能力权重；刚起步的小团队则应更关注学习成本和数据导出。关键不是分数看起来精确，而是评审者能解释为什么这个维度重要。

3. 设置不可妥协项，避免总分掩盖硬伤

有些能力不适合被其他高分抵消。例如，合规场景不能因为界面易用、报表丰富，就接受没有状态变更审计；自动化规模很大的团队，也不能用漂亮的手工页面补偿无法保留运行历史。评审前应列出不可妥协项，一旦不满足就进入淘汰或风险评估，而不是继续加权计算。

• 执行结果是否保留轮次、版本或等价上下文。
• 关键变更是否可以追溯到用户、时间和变更内容。
• 失败、阻塞和跳过是否能够与通过清晰区分。
• 核心数据是否可按约定格式导出，迁移是否存在可行路径。
• 权限控制是否足以阻止非授权人员覆盖关键结果。

4. 用任务脚本做演示，不看供应商预制样例

演示环境里的“点击即可完成”不能证明工具适合团队。用自己的复杂场景来测试：导入一组旧用例、建立测试轮次、执行一条失败用例、关联缺陷、重新执行、查看历史结果、导出报表。每一步都记下操作耗时、是否需要管理员、是否产生重复录入、能否从结果回到证据。

同一套脚本要给不同角色试用。测试人员关心执行速度；测试负责人关心分配、覆盖和风险汇总；开发人员关心缺陷关联与复现；管理员关心权限、模板和维护；管理者关心报表定义和审计。任何一个角色只能靠线下表格补齐关键工作，都应被记录为真实成本。

五、案例与数据观察：一次试点应该怎么验证

1. 情景设定：先说明什么是真实、什么是推演

下面用一个虚构的 B2B 产品团队做情景模拟，目的是展示评估方法，不代表行业统计，也不暗示某个具体产品的实测结果。团队有 12 名测试人员、3 个业务小组，维护约 2400 条用例；每两周发版，部分核心流程由自动化执行，剩余部分以手工回归为主。

试点前，团队发现三类信号：不同小组对“阻塞”和“跳过”的定义不一致；执行记录中的版本信息有时写在备注里；失败用例修复后，原来的失败状态常被直接覆盖。管理者无法快速区分“未执行”与“已通过”，测试人员则需要在工具和共享表格之间反复核对。

试点不以“用了新工具”为成功标准，而设定四个可验证目标：提高执行记录上下文完整度；降低人工汇总时间；保留失败到回归的历史链路；让发布报表中的分母可以复核。目标数字是这个虚构案例内部预先设定的试点门槛，不是行业基线。

2. 试点基线要从可复核的记录中来

先抽取最近两个发布周期的数据，检查用例、执行记录和缺陷关联。不要只看仪表盘总数，还要抽样查看原始记录：状态是谁改的，版本是否明确，失败有没有证据，修复后有没有新一轮执行。若工具无法直接导出这些信息，可以用有限样本手工抽查，但必须标记样本量和抽样方式。

假设在 300 条近期执行记录的人工抽查中，团队发现 72 条没有清楚的版本或轮次，45 条将阻塞和未执行混在备注中，38 条失败记录没有可定位的复现信息。这里的数字属于情景模拟，用来说明基线分析方法；真正实施时，应替换成团队从系统记录里获得的实测结果。

这种抽查比直接看“用例通过率”更能定位工具问题。若记录本身缺少上下文，再精美的趋势图也只是把不完整数据画得更清楚。先验证源数据质量，再讨论指标变化，顺序不能颠倒。

3. 试点过程要覆盖失败路径，而非只跑顺利流程

试点期间，选一条正常通过用例、一条执行失败用例、一条环境阻塞用例和一条不适用而跳过的用例。再故意进行一次修复后回归，确认系统保留初次失败和后续结果，而不是只展示最后一次状态。若工具能轻松记录通过，却无法解释失败和阻塞，试点并没有验证最关键的风险路径。

另外要测试边界操作：用例内容修改后，旧执行记录是否仍能追溯当时的内容；测试计划复制到新版本后，历史结果是否被错误继承；自动化重试是否覆盖首次失败；导出报表是否能解释跳过的理由。真实选型的价值，经常藏在这些“不顺利”的操作里。

4. 指标要分成效率、质量和风险三组

试点不建议只盯着“执行耗时”。录入变快可能是因为证据写得更少，也可能是因为状态被简化到无法审计。至少要同时观察效率、数据质量和风险暴露，才能判断工具是否真的改善工作，而非把成本转移给下游。

5. 指标提升之后，还要验证有没有副作用

如果上下文完整率提升，可能是工具支持结构化字段，也可能只是把大量无意义内容复制进必填项。需要抽查字段内容是否能帮助复现和决策。若执行录入时间大幅下降，也要确认失败证据、跳过理由和回归链路没有被省略。

还要留意组织侧的隐性成本：管理员每周花多少时间维护模板；测试人员是否需要重复录入；开发人员是否仍通过聊天询问环境信息；管理者是否另外维护表格。工具带来的净收益，应该扣除配置、培训、集成、迁移和持续治理成本，而不是只比较订阅价格。

六、按团队阶段和约束制定行动方案

1. 新手团队：先统一三个关键定义

如果团队只有少量测试人员，且用例规模还不大，别一开始就配置复杂审批链。先让每个人对“已批准”“本轮通过”“阻塞”有相同理解，并确保执行记录不覆盖旧轮次。用一份共享状态字典配合轻量工具，通常比直接引入多层工作流更能解决问题。

1. 挑选近期使用频率最高的 30 至 50 条用例。
2. 为每条用例明确唯一标识、预期结果、适用版本或环境条件。
3. 把用例治理状态与执行结果拆开记录。
4. 每次发布结束后抽查失败、阻塞和跳过记录。
5. 当现有方式无法保留历史或持续产生重复录入时，再扩大工具评估。

新手团队最常见的失误，是还没形成稳定流程就追求自动化率和高级仪表盘。先证明状态的含义一致，再自动化采集和汇总；否则只是更快地传播错误口径。

2. 中型团队：围绕版本和协作链路选型

当多个小组并行开发、一个版本有多轮回归时，工具需要支持团队级模板、权限边界、缺陷关联和跨版本历史。此时可以把试点范围设为一个产品线或一个发布周期，明确谁负责状态字典、谁维护集成、谁审核报表定义。

中型团队尤其要看工具是否能同时容纳通用规则与局部差异。核心状态最好统一，业务特有信息则通过字段或测试维度表达。不要为每个小组创建一份完全不同的状态模型，否则跨团队数据很快失去可比性。

3. 大型或高合规团队：重点验证权限、审计和变更治理

团队越大，状态模型的治理成本越容易超过工具许可成本。选型要验证角色权限能否分层，关键结果能否限制覆盖，配置变更是否留痕，历史数据能否按规则保留，报告能否从聚合值回溯到单条记录。还应在试点中加入审计或质量负责人，而不只是让执行人员评价操作体验。

如果外部审计、客户验收或安全要求规定了证据保留期限，应把期限、访问控制和导出能力作为硬性需求。不能仅凭“支持附件”就认定证据管理合格；要实际确认附件能否与版本、执行记录和审批结果保持关联，离职或权限变更后是否仍可检索。

4. 自动化占比高的团队：关注结果回传和重跑语义

自动化团队要验证工具与持续集成流程的边界。每次构建是否创建独立执行记录；同一用例重试是新记录还是覆盖旧记录；测试脚本改名后如何匹配用例；流水线失败究竟代表产品缺陷、测试基础设施故障，还是测试脚本自身问题。工具若无法表达这些差异，报表会把环境噪声误判成产品质量趋势。

自动化结果通常适合通过接口批量回传，但回传成功不等于数据质量合格。需要监控未匹配用例数、重复回传数、无版本号运行比例和日志缺失率。接口故障时应有补偿机制，避免测试结果只留在流水线日志里。

5. 预算有限或迁移受限的团队：先算总拥有成本

预算评估不能只看每个账号的费用。完整成本还包括初始配置、数据清理、旧记录导入、接口开发、培训、管理员时间、报表维护和未来退出迁移。即使工具本身费用较低，若每个版本都需要人工修正状态或对照多份表格，长期运营成本也可能更高。

建议把成本估算放到至少一个完整发布周期里。统计每次发布的手工汇总时间、状态修正时间、重复录入时间和管理员维护时间，再估算未来版本数量。估算不需要假装精确，但应透明记录假设，避免只比较采购报价。

七、工具取舍：不同选择各自牺牲什么

1. 轻量表格与专用测试用例工具

表格中的类别是能力取舍，不是产品排行榜。实际产品可能跨越多种类别，名称也不如数据模型和执行细节重要。试用时应围绕任务脚本逐项验证，而不是根据产品页面上的功能名称推断适配度。

2. 自由配置与统一治理

更自由的配置适合流程差异大、需求变化快的团队，但必须有配置负责人、变更记录和公共统计映射。更统一的状态模型有利于跨团队对比，却可能无法表达每个业务的例外。我的建议是：统一核心定义，允许有限扩展；扩展字段必须说明业务含义，新增核心状态则经过评审。

3. 自动化深度与手工体验

自动化集成越深入，越能减少重复录入，但团队需要维护接口、匹配规则和异常处理。手工执行体验越简单，执行人员越容易上手，但也可能缺少自动采集的环境信息。若团队两种测试方式并存，选型不要只让自动化负责人或手工测试负责人单独拍板，要用同一组场景分别验证。

4. 快速迁移与历史可信度

把旧用例导入新工具，不等于历史迁移成功。若原数据里的“通过”没有版本和轮次信息，导入后不应假装这些记录拥有完整执行上下文。可以把旧数据标记为历史存档或低可信度来源，并从明确的切换日期开始建立新口径。保留旧记录的可查性，比制造虚假的历史连续性更重要。

5. 试点范围与代表性

试点太小，无法暴露权限、集成和跨角色问题；试点太大，失败成本又高。较好的做法是选一个真实产品线、一个完整发布周期和多种执行路径，既包含常规通过，也包含失败、阻塞、修复后回归和跳过。若试点只挑最配合的人员和最简单的用例，结论很可能过度乐观。

八、实施与迁移：避免把旧问题原样搬进新系统

1. 先清理状态，再迁移记录

导入前先统计旧系统里的状态名称、数量和实际用法。对每种状态指定去向：映射到新状态、作为历史备注保留、归档为废弃值，或暂不迁移。不能仅凭字面相似就映射，例如旧系统里的“关闭”可能是用例作废，也可能是执行完成，需要抽样核验。

迁移规则要记录旧字段、新字段、映射逻辑、无法映射的处理方式和责任人。对缺少版本、环境或执行人的历史记录，应保留其原有可信边界，不要自动填入当前版本或默认执行人。

2. 设定切换日和并行期

双系统并行太久会造成状态分叉，完全突然切换又可能影响正在进行的发布。可选一个版本或发布周期作为切换边界：在边界前的记录只读保留，边界后的执行统一进入新工具。并行期只用于核验迁移和流程，不宜让同一条执行结果长期要求人工录入两处。

切换后要明确旧系统由谁维护只读访问、哪些数据仍需查询、出现迁移错误时如何纠正。计划退出旧系统之前，先做一次完整导出和抽样回查，确认关键关系没有丢失。

3. 用培训和抽样审查替代一次性宣讲

状态规则讲过一次，不代表团队已经形成共同理解。可以用几个有歧义的案例做短练习：环境不可用应选阻塞还是未执行；缺陷修复但未复测应如何记录；本轮不执行的用例如何说明。两周后抽查实际记录，发现问题就更新示例，而非单纯责怪执行人不按流程。

4. 建立轻量治理节奏

状态模型不需要天天开会治理，但应有明确维护责任。建议每个发布周期检查未执行、阻塞、失败未回归和证据缺失；每季度检查重复状态、长期无人维护字段和报表口径变化；每次重大流程变更时重新评估权限和迁移规则。

• 测试负责人维护状态字典和核心统计口径。
• 工具管理员维护字段、权限、接口和配置变更记录。
• 各业务小组负责人确认本组执行上下文和例外规则。
• 质量或审计角色抽查关键发布记录的证据完整性。

九、选型清单：从候选工具走到可执行决策

1. 需求澄清清单

• 团队维护多少条有效用例？过去一年增长速度如何？
• 一个版本通常有几轮测试，是否需要并行环境或设备矩阵？
• 哪些字段会改变测试结论，例如版本、设备、数据批次或构建号？
• 通过、失败、阻塞、跳过、未执行分别如何定义？
• 失败是否必须关联缺陷、日志、截图或复现步骤？
• 自动化结果如何匹配用例，重跑是否保留历史？
• 谁有权改状态、改定义、关闭用例或豁免执行？
• 报表需要支持什么决策，分母和时间范围如何定义？
• 数据保留、审计、导出和退出迁移有什么硬性约束？

2. 试用验收清单

• 能否建立并维护用例治理状态与执行结果两套语义？
• 同一用例能否保留多个版本或轮次的执行记录？
• 修复前失败和修复后回归是否可以同时追踪？
• 未执行、阻塞、跳过能否与通过单独统计？
• 报表是否显示计算口径，并支持回到原始执行记录？
• 核心字段能否导出，历史数据能否按规则迁移？
• 常见操作是否需要重复录入，管理员是否成为唯一依赖？
• 不同角色能否在真实任务脚本中独立完成工作？

3. 决策会议应该讨论分歧，而非只看总分

候选工具评估结束后，把总分、不可妥协项和分歧最大的三项一起呈现。测试人员认为操作顺手、管理员认为治理风险高时，不要用平均分抹平意见，而要找出冲突背后的场景：是流程定义不清，还是产品能力不足，抑或是角色权限配置不合理。

决策记录应写明选择理由、已知限制、试点范围、风险负责人和复核日期。这样即使未来业务变化、工具更换或组织扩张，团队也能知道当初的选择基于什么假设，而不是重新从零争论。

十、最终判断：把状态当作证据链，而不是颜色标签

1. 专家级选型的标志，是能够解释“为什么”

新手容易问“这个工具有多少状态”；进阶团队会问“能不能统计”；成熟团队会继续追问“统计口径是什么，数据来自哪里，谁能修改，失败如何回归，哪些情况不能据此下结论”。差别不在工具名字，而在团队是否把状态视为有上下文、有责任人、可复核的证据。

一个可靠的测试用例状态体系，不会承诺“通过率更高”，也不会把每种流程例外都变成一个状态。它的作用是让团队更早发现执行缺口、准确识别发布风险，并让事后复盘能够回到当时的版本、环境、记录和判断。

2. 下一步行动：用一周完成最小评估

1. 第 1 天：抽取近期真实用例，整理当前状态词及其实际含义。
2. 第 2 天：将用例生命周期、执行结果和缺陷状态拆分，形成状态字典。
3. 第 3 天：列出不可妥协项、六维评分权重和真实演示脚本。
4. 第 4 至 5 天：让不同角色用同一组成功与失败场景试用候选工具。
5. 第 6 天：抽查记录质量、报表口径、导出能力和维护成本。
6. 第 7 天：决定继续试点、调整流程或更换候选方案，并记录取舍理由。

最后，我会把选择标准收敛为三个问题：状态是否有明确含义，执行是否保留完整上下文，汇总是否能回溯到证据。如果候选工具在这三件事上表现可靠，再比较体验、集成和价格；如果这三件事答不清楚，更多功能通常只会让混乱更隐蔽。真正值得选的不是状态最多的工具，而是能让团队在发布前看清哪些结果可信、哪些风险仍未关闭的工具。