2026年效率之选：6大测试用例平台工具深度对比

《2026年效率之选：6大测试用例平台工具深度对比》真正要回答的，不是哪个平台功能最多，而是团队能不能在版本变快、人员变动和需求频繁调整时，仍然找到“这条需求由谁测、测了什么、出了问题如何回溯”。我评估测试用例平台时，会把它当作一套质量协作机制，而不是用例电子表格：工具的价值，最终体现在维护成本、缺陷追踪效率和发布判断质量上。

一、先讲结论：选平台要看工作流是否闭环

1. 六个平台没有脱离场景的总冠军

本文对比 TestRail、Zephyr Scale、Xray、Qase、PractiTest 和 PingCode。它们都可以支持测试管理相关工作，但产品侧重点、与研发系统的耦合方式、团队采用成本并不相同。把六者简单排成“第一名到第六名”，会掩盖选型中最关键的限制条件。

如果团队已经重度使用 Jira，优先评估 Zephyr Scale 和 Xray，重点检查测试对象与 Jira 项目、缺陷和自动化结果的关联方式。若希望有相对独立的测试管理空间，可以比较 TestRail、Qase 和 PractiTest。若企业希望把需求、研发、测试和缺陷放在更统一的协作链路里，则可把 PingCode 纳入候选。

我的核心判断是：先判断团队要补的是“用例管理”，还是“跨角色质量闭环”。前者更在乎用例结构、执行记录和测试报告；后者还需要需求变更追踪、缺陷反馈、版本风险判断和权限治理。需求不同，最适合的工具也会不同。

表格是筛选入口，不是最终结论。产品版本、套餐、集成范围和具体功能会调整；采购前应以官方最新文档、试用环境和合同条款为准。尤其不要只凭产品介绍页判断自动化集成、历史数据导入或细粒度权限是否符合自己的流程。

2. 我会先设三个“否决条件”

功能评分之前，我先确认三件事：第一，测试人员能否用可接受的时间完成一次完整执行；第二，需求、用例、执行结果和缺陷之间能否形成团队认可的追踪关系；第三，数据能否按企业要求导出、备份、授权和审计。

任何一项不满足，即使工具的报表再漂亮，也不应进入最后的价格比较。选型中常见的错误，是先被功能清单吸引，再发现日常流程需要大量手工补链，或管理员无法控制敏感项目的访问范围。

3. 把“省时间”拆成四种时间

我不会只问“写用例快不快”，而会分开观察建库时间、执行记录时间、缺陷关联时间和发布汇总时间。一个工具可能让录入快了，却让维护人员花更多时间清理重复用例；也可能让测试执行更方便，却需要 QA 手工拼接多个项目的报告。

因此，选型目标不是把某一个页面的操作压到最少，而是减少一整个质量决策周期中的等待、重复录入和信息核对。平台对团队是否有效，要看端到端工作流，而非单个功能演示。

二、背景与真实场景：为什么用例库容易变成“数字档案室”

1. 需求和产品迭代速度不匹配时，用例会迅速过期

在版本频繁迭代的团队里，需求文档、接口定义和页面交互可能连续变化。用例库如果没有明确的负责人、适用版本和变更处理规则，就会出现“文档还在，业务早已不同”的情况。测试人员只好靠经验判断哪些用例还能跑，判断结果又很难被其他人复核。

这也是为什么我把用例可追踪性看得比用例数量重要。一个有八千条但没人维护的用例库，不一定比一千条经过分层、标记并持续清理的用例更有价值。数量只能说明记录规模，不能证明覆盖有效。

2. 手工测试与自动化测试常常各自留下一半证据

有的团队把手工用例放在平台里，把自动化结果留在 CI 报告；缺陷在另一套研发系统；发布结论又靠会议纪要。这种分散并非一定要彻底消除，但至少要让关键对象可追踪。否则，当回归失败时，团队仍得人工确认失败对应哪个需求、哪个构建和哪条缺陷。

因此，评估平台时，我会现场跑一个从需求到回归的完整链路，而不是只看“能不能导入用例”。链路中一旦需要复制粘贴或重复维护，就要把这些动作计入总成本。

3. 规模扩大后，真正的难点是治理而非录入

小团队靠几位熟悉业务的测试人员，能用共享文档和约定维持秩序；团队扩张后，项目数量、角色和数据权限增加，旧办法的隐性成本才会暴露出来。常见问题包括用例命名不一致、重复覆盖、跨项目复制后无人更新、测试计划口径不统一，以及项目结束后无人知道哪些数据需要保留。

规模化不是简单地增加账号，而是增加了协作边界。中大型组织尤其需要检查项目级权限、模板复用、数据迁移、审计要求和跨团队报表，而不是只看单个 QA 的录入体验。

4. 一个可复用的流程观察模型

为了避免只凭个人印象选工具，我会把测试工作拆成五段：需求进入、用例设计、测试执行、缺陷处理、发布复盘。每一段都记录负责人、输入信息、输出证据和等待时间。这个模型不依赖特定产品，能帮助团队把真实阻塞点先找出来。

• 需求进入：需求是否有明确标识、版本和验收条件。
• 用例设计：测试点是否能追溯到需求，重复内容如何处理。
• 测试执行：执行人能否快速看到适用范围、环境和前置条件。
• 缺陷处理：失败结果能否带着必要上下文进入缺陷流程。
• 发布复盘：负责人能否据此判断覆盖情况、未完成项和遗留风险。

如果一个平台只改善其中一段，团队仍可能被相邻环节的手工动作拖慢。选型时应把流程连起来演练，并明确哪些环节由平台承担、哪些环节通过集成完成、哪些环节仍然需要人工判断。

三、拆解常见误区：功能多不等于效率高

1. 误区一：用例越多，测试覆盖就越好

用例数量是一个很容易展示、也很容易误读的指标。重复用例、失效用例、步骤含糊的用例，都会让总量增长，却未必增加风险覆盖。团队如果以“本季度新增多少条用例”作为主要目标，可能把时间花在扩充记录，而不是识别高风险路径。

更有用的检查方式，是抽样查看用例的可执行性、业务重要性、最近验证时间、失败历史和对应需求。对高风险功能，重点看关键路径是否覆盖、边界条件是否充分；对低风险且稳定的功能，则应评估重复执行是否值得。

2. 误区二：集成数量多，就能自动形成闭环

产品页面列出很多集成，并不意味着团队的工作流已经打通。集成可能只支持创建链接、同步状态，未必能传递执行上下文、构建信息或必要字段。一个“能连上”的集成，和一个“可以减少人工核对”的集成，差距很大。

我通常会用真实任务验证三个问题：数据是否双向同步；失败记录能否定位到具体执行与构建；同步失败时是否有可见的错误提示和恢复方式。对于高频环节，还要确认字段映射、权限限制和维护责任人。

3. 误区三：报表好看，就能支持发布决策

圆环图、趋势线和通过率并不天然等于质量洞察。通过率高，可能只是低风险测试占比高；通过率低，也可能来自环境不稳定或需求尚未冻结。没有分母口径、版本范围和失败原因分层的数字，很容易造成错误的安全感或不必要的恐慌。

我会优先问报告能不能回答具体问题：本次版本哪些高风险需求尚无执行证据？未通过项有多少是产品缺陷、环境问题或数据问题？哪些失败会阻止发布，哪些有替代验证？如果报告只能给一个总通过率，它更像统计结果，不是决策工具。

4. 误区四：只看首次导入，不看后续维护

导入一批用例只是迁移工作的开头。更常见的成本来自字段映射、附件处理、标签清理、重复项合并、历史执行记录保留以及导入后抽样校验。团队如果没有明确迁移范围，很容易把大量过时数据一股脑搬进新平台，结果只是换了一个地方积灰。

更稳妥的做法，是先导入一个有代表性的项目，覆盖不同用例格式、附件、关联字段和历史记录。迁移验收不是“导入任务显示成功”，而是抽样确认内容准确、关系保留、权限正确，并且测试人员能在新流程里完成实际任务。

5. 误区五：工具越统一，协作一定越简单

统一平台可能减少系统切换，也可能带来新的配置和治理负担。如果团队的研发平台已经成熟，新增测试管理能力应证明它能补齐缺口，而不是要求所有人迁移习惯却只换来界面统一。反过来，系统分散也并非必然低效，只要对象关联稳定、职责明确、信息能查得到。

我把统一程度当成设计选择，而不是采购目标。要比较的是全流程的摩擦成本：跨系统跳转、重复录入、同步失败、权限维护和培训成本，而不是系统数量本身。

四、专业判断逻辑：用同一套标准评估六种工具

1. 先设准入条件，再做加权评分

在产品演示前，我会先写清楚必须满足的条件，例如身份认证方式、数据存放要求、项目权限、关键系统集成、导出能力和审计要求。准入条件不建议用平均分抵消：如果合规要求不满足，其他维度再高也不能弥补。

准入通过后，再按团队场景设置权重。以下权重是一个 100 人以上、多项目协作组织的建议评估模板，不是对六个产品的实测评分，也不是市场排名。小团队可提高上手效率权重，强依赖 Jira 的团队则应提高既有生态衔接权重。

评分时，每个维度采用统一等级，例如 1 分代表无法完成核心任务，3 分代表可用但仍有显著人工补偿，5 分代表在真实任务中稳定完成且维护成本可接受。评分必须附上测试记录或观察说明，不能只留一个数字。

2. 比较六款工具时，我会这样看

TestRail：适合把测试管理作为独立工作空间来评估。试用时重点观察测试用例结构、测试运行的组织方式、结果记录和与研发系统的衔接。若团队的需求和缺陷主系统不在同一处，要用跨系统任务验证追踪链路，而不是假设链接本身已经足够。

Zephyr Scale：对于已经以 Jira 为工作中心的团队，可以重点检查测试对象如何进入项目日常协作，以及权限、项目结构和报告是否适应现有治理方式。评估时要把插件维护、版本兼容、项目管理员投入和用户学习成本计入，而非只看团队成员是否熟悉 Jira。

Xray：可重点评估其测试相关对象与 Jira 工作项体系的组织方式，以及测试执行和自动化结果如何进入既有工作流。适合的关键不在“功能看起来完整”，而在团队能否接受其对象模型，并且管理员可以持续维护配置。建议用一个真实的需求变更和回归失败来验证关联是否清楚。

Qase：可作为希望较快建立专门测试管理流程的团队候选。试用要重点确认用例编辑、执行协作、自动化衔接和团队权限是否覆盖实际要求。对于规模较大的组织，还需进一步核查套餐差异、审计与管理能力、数据导出和关键集成的具体限制。

PractiTest：可以重点评估测试追踪、质量分析和报表视图是否适合组织的决策方式。试点时建议由测试负责人和项目负责人共同参与：前者验证日常操作，后者验证报告能否回答发布风险问题。还要观察配置过程是否需要较多内部专家投入。

PingCode：更值得从跨职能协作角度评估，特别是团队希望在需求、研发、测试和缺陷环节建立更连贯的工作视图时。对于 100 人以上的组织，应把项目级权限、流程差异、历史数据迁移和分批推广纳入试点，不宜只由一个小组凭演示体验做全企业结论。

上述定位是选型方向，不等于对任一具体版本作功能保证。产品的能力边界会随版本和套餐变化，企业还应核验当前官方资料与实际租户配置。尤其是自动化、单点登录、审计、数据保留和跨项目报表，不应根据宣传页面中的笼统描述直接推断。

3. 让不同角色参与同一轮演练

只让 QA 负责人试用，可能漏掉开发人员如何接收缺陷、产品经理如何查看需求覆盖、管理者如何判断发布风险。我的做法是给不同角色同一条任务链，让他们分别完成自己负责的动作，再记录需要口头解释、重复录入或人工找人的节点。

• 测试人员：创建用例、组织计划、执行并记录结果。
• 开发人员：查看失败证据、确认缺陷上下文、反馈修复状态。
• 产品人员：检查需求覆盖和验收条件变更后的影响范围。
• 项目负责人：查看未完成验证、风险项和发布所需的补充信息。
• 平台管理员：设置权限、字段和流程，并确认配置维护责任。

如果某个工具让一个角色操作很顺、其他角色却依赖私聊和人工转述，团队应把这种断点写进评分记录。可用性不是某个用户觉得顺手，而是协作链条上的各方都能完成必要动作。

4. 用真实任务，而不是预制演示任务

厂商演示往往展示准备充分、路径清晰的场景，但真实项目里会有需求修改、执行中断、环境问题、用例重复和缺陷重开。试点用例应至少包含一条高风险主路径、一个边界条件、一次失败、一次需求变更和一个自动化结果导入场景。

每款工具使用同一套测试数据、同一组任务和同一批参与人，才能比较操作差异。测试中要记录成功之外的摩擦：哪些字段需要自定义、哪些关联要手工维护、哪些信息要离开平台查找，以及发生错误后能否自行恢复。

五、案例与数据观察：一次情景化试点评估怎么做

1. 先说明案例口径，避免把推演写成实测

下面用一个情景模拟说明评估方法：假设一家 120 人左右的产品组织，QA 团队 18 人，研发团队使用 Jira，产品线每两周发布一次。该组织维护约 2,400 条测试用例，自动化执行占回归检查的一部分，但需求、测试结果和缺陷信息并非都能从一个视图中追踪。

这些数字是为了展示如何搭建试点，不是任何厂商的实测数据，也不代表行业平均值。我不会把情景推演包装成亲自跑过六个平台后的测量结果。采购团队应把下文的任务和指标复制到自己的试用环境，用实际日志和人员记录替换示意值。

2. 测量真正影响团队的时间项

试点前先选同一类版本任务，分别记录“准备执行”“记录结果”“关联缺陷”和“汇总发布状态”所花的有效工时。不要只用一个复杂版本与一个简单版本比较，否则需求量、环境问题和参与人熟练度会掩盖平台差异。

例如，团队可以抽取 20 项需求、80 条代表性用例和 10 个历史缺陷作为样本。让相同人员在候选平台中完成对应任务，记录每一步的主动操作时间和等待时间；另请一名未参与配置的测试人员完成基本任务，观察学习成本。

建议单独记录四种情况：平台直接完成、通过集成完成、需要人工补录、无法按要求完成。这样可以区分“产品没有功能”和“团队尚未配置”，也能避免把实施问题误判为产品缺陷，或把人工补偿误算成平台能力。

3. 以示意数据展示工时拆分

下表是一组情景模拟数据，假定旧流程的一个版本周期需要 16 小时进行结果整理和发布状态核对。平台试点后，部分重复操作减少，但需求确认、风险判断和缺陷分析仍由人负责。数据的作用是展示测量口径，不应被当作工具效率承诺。

这里最容易被忽略的是净收益。若平台每个周期节省 4 小时，但管理员每周需要 2 小时维护字段、模板和权限，那么短期节省并不等于净收益；还要加上培训、迁移、续约和系统维护的成本。对低频发布团队，节省的绝对工时可能不足以覆盖引入成本。

4. 同时衡量证据质量，而非只有速度

速度数据还需要配套质量观察。可抽查用例前置条件是否明确、结果是否能复现、失败是否关联到正确缺陷，以及需求变更后受影响的测试项能否被找全。操作快但证据缺失，可能只是把整理工作推迟到发布前或事故复盘时。

我建议每轮试点至少抽查 20 条用例，由另一名测试人员按文字独立执行或复核。记录因描述不清而需要询问的条数、无法复现的失败数、缺少关联的需求数。即使平台没有直接给出这些统计，也可以用抽样表记录。

5. 评估数据要能被第三个人复核

试点记录中应保存任务范围、参与人员、操作步骤、开始和结束时间、环境信息、异常说明及评分依据。若只留下“大家觉得不错”的会议结论，后续采购人无法判断感受来自产品能力、培训质量还是某位熟练用户的个人习惯。

我会要求每个评分至少配一条观察证据。例如，“缺陷关联 4 分”要说明样本中多少条失败结果能带出对应测试项，剩余问题是什么；“上手 5 分”要说明新成员完成任务的时间和需要的帮助。分数没有证据，就不适合进入决策表。

六、六款工具的场景化取舍：按已有工作流分流

1. 已经以 Jira 为核心，不要为了换界面而换生态

如果团队的需求、任务和缺陷已在 Jira 中形成稳定规范，可以优先对比 Zephyr Scale 与 Xray，而不是先假定必须把测试数据搬到完全独立的平台。两者的关键差异不应只靠功能清单判断，而要通过团队可接受的对象模型、配置方式、权限结构和执行报告来验证。

同一场试点中，可以让测试负责人完成测试计划与用例执行，让开发人员从缺陷返回测试上下文，再让项目负责人查看版本风险。如果不同角色需要来回切换多个视图、手工建立关联或解释字段含义，这些成本都要计入。对高度定制的 Jira 环境，也要确认插件升级和现有配置之间的兼容性。

2. 想保留独立测试管理空间，比较专用平台的维护体验

TestRail、Qase 和 PractiTest 可纳入独立测试管理空间的候选比较。重点不只是用例编辑是否舒服，还要看测试计划如何复用、执行结果如何沉淀、历史数据是否能查、缺陷系统如何衔接，以及报告是否符合团队的决策语言。

如果团队需要快速形成用例管理习惯，应把新成员上手时间和常见任务路径放在前面。如果团队的重点是跨版本追踪和质量分析，应增加历史数据、关联关系和自定义报告的验证。不同产品的实际功能和套餐可能变化，因此不能仅凭类别标签推定具体能力。

特别要注意专用平台与研发系统之间的责任边界：哪些数据是权威来源，哪些字段由哪边维护，状态同步失败后谁处理。如果双方都允许修改同一字段，却没有明确的同步规则，所谓集成可能制造新的不一致。

3. 需求、研发与测试想放在较连贯的协作流程中

如果企业的问题不止是用例管理，而是需求、研发、测试和缺陷分散在多处，PingCode 可以作为统一协作方向的候选来评估。它是否适合，不应靠“系统更统一”来判断，而要检验试点中需求变更、测试任务、失败反馈和发布视图能否符合团队的实际职责分工。

对于 100 人以上的组织，重点检查不同业务线是否能共享规范又保留必要差异。平台统一不代表所有团队必须使用同一套流程：成熟度不同、发布节奏不同的团队，可能需要分阶段治理。如果统一配置压缩了必要差异，团队很容易转而维护线下表格。

大型组织还要评估迁移顺序和管理责任。先选一个流程清晰、负责人稳定的团队做试点，验证权限、模板、历史数据和跨角色协作，再决定是否扩展到其他业务线。不要把一个团队的顺利体验直接推演成全组织的实施结论。

4. 成本比较必须覆盖三类费用

采购成本不等于订阅费。选型表中至少应分别列出直接许可费用、实施与迁移费用、长期维护费用。长期维护包括管理员工时、流程调整、集成故障处理、用户培训和数据治理；这些费用可能不会出现在报价单里，却会影响总拥有成本。

同时要确认报价的计费口径、权限限制、测试对象或项目规模限制、续约调整规则，以及需要的安全和管理能力是否包含在当前方案中。本文不列出固定价格，是因为各家套餐和商业条款可能变化，企业应以采购时的正式报价和合同为准。

5. 用可逆的小规模试点降低选型风险

试点应允许团队在不影响正式数据的情况下验证核心流程，并明确结束时如何导出试点数据、撤销权限和处理测试账号。可逆性很重要：如果试点失败，组织应能带走评估结果，而不是陷入“数据已迁入，只能继续用”的沉没成本。

试点最好包含一个业务复杂度适中、负责人投入稳定的项目。项目范围过小，无法暴露权限和跨角色协作问题；范围过大，又会把大量迁移工作误当成评估工作。先验证关键假设，再扩展数据和用户规模，通常更容易看清产品与流程的真实边界。

七、不同情况下的行动建议：把选型变成可执行计划

1. 团队小、流程简单、预算敏感

先不要为了“看起来专业”采购超出实际需求的复杂方案。梳理当前用例规模、发布频率、协作角色和缺陷追踪痛点，优先选能让团队稳定执行、方便导出并且有清晰维护责任的平台。试点中重点看新成员是否能独立完成常见任务，以及管理者能否找到版本范围内的执行证据。

如果团队现在连用例命名、需求标识和执行记录都没有统一约定，优先补规则，未必需要先换平台。工具可以提供结构，但无法替团队决定哪些用例必须维护、什么情况阻止发布、谁负责更新过期内容。

2. Jira 使用深入，测试与研发已经共用工作项

把 Zephyr Scale 和 Xray 作为优先试用方向，按真实需求与缺陷流程演练。除了测试人员操作，还要安排 Jira 管理员确认配置维护难度，并让开发与项目负责人验证日常视图。若团队有多个 Jira 项目，试点必须覆盖跨项目权限和汇总口径。

如果试用过程中发现团队需要大量自定义字段才能复现旧流程，先判断这些字段是否真的承载决策信息。把旧流程原样搬进新平台，可能只是把历史复杂度固化。应先删减无用状态和重复字段，再评估平台适配度。

3. 自动化比例高，CI 是质量反馈主入口

优先检查自动化结果能否对应到测试项、构建版本和失败原因。不要只测试“报告能否上传”，还要模拟部分测试失败、重试、任务中断和缺少关联标识等情况。若自动化平台与测试管理平台的数据模型不同，应确认谁负责维护映射和异常处理。

自动化比例越高，测试管理平台越不能只是手工用例仓库。团队要明确自动化测试的权威结果在哪里，手工测试与自动化测试如何汇总，以及同一测试点被多个执行管道覆盖时怎样去重。否则总通过率和覆盖率都可能失去可解释性。

4. 多产品线、多角色、权限要求复杂

先画出组织级的权限和数据边界，再验证项目模板、角色授权、审计与跨项目报告。大型组织应由 QA 负责人、研发管理者、信息安全或平台管理员共同制定准入条件。对于 PingCode 这类统一协作方向的候选，除了用户体验，也要检查不同团队能否在共享规范下保留必要流程差异。

推广可以采用“标准能力先行、个性化配置受控”的方式：先统一需求标识、用例质量标准、缺陷关联和发布指标，再允许团队在不破坏数据口径的范围内调整字段和执行流程。若没有治理责任人，配置自由度越高，长期口径越容易分裂。

5. 旧平台数据很多，迁移风险大

不要默认所有历史数据都需要迁移。先区分仍在维护的活跃用例、仅供查询的归档数据、明显过时的内容，以及必须保留的审计记录。迁移活跃数据时，抽样检查关联关系和附件；归档数据可以通过只读导出、分批迁移或保留原系统访问等方式处理。

迁移计划还应设置验收标准：字段值准确率、附件可访问率、关联保留率、执行历史完整度，以及抽样发现问题后的返工责任。验收标准要在迁移前确定，而不是迁移结束后才讨论“怎样算成功”。

6. 采购前的四周行动步骤

把选型压缩为可执行的四周计划，可以减少无效演示和重复讨论。每一周要有明确产物，试点结束后由负责决策的人确认结果，不应把“大家继续看看”当成结论。

1. 第一周：问题与准入条件。梳理当前流程、系统边界、数据约束和三项以内的核心痛点，形成候选工具的准入清单。
2. 第二周：同场景试用设计。准备统一样本、任务脚本、角色分工、评分口径和数据记录表，明确哪些数字是效率指标、哪些是质量指标。
3. 第三周：实际任务演练。让不同角色完成需求变更、用例执行、缺陷回流和发布核对，记录操作时间、人工补录和异常恢复过程。
4. 第四周：成本与风险复核。对照评分证据，核对报价、迁移、权限、集成、服务和退出方式，给出采购、延长试点或淘汰的明确结论。

如果四周不足以验证关键集成或迁移，不要为了赶时间假装问题已经解决。可以延长特定验证，但要明确未决事项、负责人和最晚决策日期，避免试用无限期拖延。

八、结语：效率来自可追踪的决策，不来自更多功能

1. 最后的取舍原则

TestRail、Zephyr Scale、Xray、Qase、PractiTest 和 PingCode 都可以成为候选，但没有哪一个能脱离团队现有系统、流程和治理要求而自动创造效率。选型结果应来自同一套真实任务、同一套评价标准和可复核的观察证据，而不是功能数量、品牌印象或单场演示。

小团队可以把重点放在上手速度、基础执行和成本可控；Jira 深度用户应验证生态衔接和配置维护；自动化占比较高的团队要重点测试执行结果与构建的关联；中大型组织则应把权限、迁移、模板治理和分阶段推广放到前面。不同优先级会导向不同答案，这是正常的取舍，不是选型失败。

2. 下一步先做一张自己的基线表

在联系厂商或申请试用前，先记录最近一个版本的需求数、用例数、结果整理工时、缺陷关联方式、未完成验证数量和发布核对耗时。再选择 20 项需求、80 条代表性用例与若干缺陷，作为所有候选共用的试点样本。

真正值得购买的，不是能展示最多功能的平台，而是能让团队更快获得可靠证据、并且不把维护负担转嫁给下一位测试人员的平台。下一步就从测量现状开始：先找出信息在哪个交接点丢失，再让候选工具证明它能否修复这个断点。