测试工具评估清单用于在选型评审会上逐项判断一款测试管理平台是否可用。它把“感觉功能挺全”拆成可核验的检查项，每项写明通过标准、所需证据和负责人，并标出影响上线决策的阻断项。本文按准备、功能核验、集成与数据、试点验证四个阶段给出可直接使用的检查表，覆盖用例、计划执行、缺陷关联与报告等管理动作，ONES 的相关能力会在对应检查项中说明。纯测试执行框架的代码用法、现有工具的搬迁执行步骤不在本文范围内。
要点总览（TL;DR）
- 清单按准备、功能核验、集成与数据、试点验证四个阶段组织，每个检查项写明通过标准、所需证据和负责人，可直接在评审会上逐项打勾。
- 使用对象是测试负责人、测试架构师、研发效能人员和采购评审人；使用时点从需求确认后延伸到上线决策前，不同节点用清单的不同部分。
- 功能核验以“能否现场走通一次完整闭环”为判断口径，用例、计划、执行记录、缺陷关联、报告之间断链的位置就是需要追问的点。
- 集成与运行条件检查要把已确认、待验证、未确认分开记录，数据导出要实际试导一批真实数据，只看到导出按钮不算通过。
- 阻断项不通过就不能进入下一阶段；所有阻断项通过、非阻断项均有明确结论和负责人，评审才算完成，结论页与证据一并归档。
谁在什么时点使用这份清单
这份清单服务于选型评审，使用对象包括测试负责人、测试架构师、研发效能人员和采购评审人。不同角色关注的检查项不同：测试负责人对用例组织、执行闭环和报告可用性负责；测试架构师判断集成方式与数据可迁移性；研发效能人员关注部署形态、账号体系对接和长期运维成本；采购评审人核对约束条件、证据完整性和结论签署。清单在评审会上由主持人逐项过，不由厂商演示节奏决定顺序。
使用时点分为四个节点，每个节点用清单的不同部分：
| 评审节点 | 使用清单部分 | 产出 | 主要责任人 |
|---|---|---|---|
| 需求确认后 | 准备检查项 | 需求与约束清单、演示脚本 | 测试负责人 |
| 候选初筛 | 功能核验检查项 | 候选产品功能对照结论 | 测试架构师 |
| 试点前 | 集成、数据与运行条件检查项 | 集成方式确认单、待验证项列表 | 研发效能人员 |
| 上线决策前 | 试点验证记录、阻断项与完成条件 | 评审结论页与签署记录 | 采购评审人牵头 |
范围边界需要在使用前说清楚：清单只评估测试管理平台，即覆盖用例管理、测试计划与执行记录、缺陷关联、报告与度量的平台。纯测试执行框架的脚本编写、断言库选择、持续集成中的代码级用法属于另一类评估，不放进这份清单，否则评审会容易被技术细节带偏，管理能力反而没核验到。现有测试工具向新平台的搬迁属于迁移类工作，按迁移流程单独处理，本文只检查“数据能否导出、历史用例能否导入”这类可行性问题，不展开搬迁步骤。
评审前的准备检查项
准备阶段的目的是让评审有本方节奏。厂商演示通常按自家产品亮点组织，如果评审方没有预设场景，很容易看完一圈演示却说不清哪款更贴合流程。准备检查项在发出演示邀请前完成，全部通过才进入功能核验。
| 检查项 | 通过标准 | 所需证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 测试流程现状梳理 | 写明用例规模量级、执行频次（如每迭代一轮回归）、缺陷流转路径（发现—指派—修复—验证—关闭） | 一页流程说明，含各环节使用的现有工具 | 测试负责人 | 是 |
| 必须满足的约束 | 部署方式（公有云、私有化或混合）、账号与权限要求（是否对接企业账号体系）、数据存放要求、预算区间均有书面结论 | 约束清单，经 IT 与采购确认 | 研发效能人员 | 是 |
| 候选名单 | 候选产品数量与入围理由明确，排除项写明原因 | 候选名单表 | 测试架构师 | 是 |
| 演示脚本 | 按本方真实流程编写演示场景，要求厂商按脚本操作，而非自由演示 | 演示脚本，含预期看到的操作步骤 | 测试负责人 | 是 |
| 评审角色与决策人 | 业务侧、测试侧、IT、采购的角色到人，最终决策人明确 | 评审角色表 | 采购评审人 | 是 |
| 通过标准与证据形式 | 每项检查事先约定“看到什么算通过”和“留下什么证据”，避免会后各说各话 | 本清单填写完整，证据栏写明形式 | 测试架构师 | 否 |
演示脚本是准备阶段最容易被省略、又最影响结论的一项。脚本应包含一条完整链路：从需求或用户故事出发，建立用例、编排一轮测试计划、记录执行结果、提交缺陷并回填验证结论、最后查看覆盖率与进度报告。厂商按这条链路演示，评审人才能在同一口径下比较候选产品。
功能核验阶段检查项
功能核验把测试管理的核心能力拆成可观察的检查项。判断方式统一为“在演示或试用环境中能否完成指定动作”，而不是听厂商介绍功能列表。以下检查项按能力分组，每项给出通过标准示例，评审时可据本方流程调整细节。
| 能力组 | 检查项 | 通过标准示例 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|---|
| 用例管理 | 分层组织 | 能按产品、模块、功能点建立层级，并在层级间移动用例 | 演示录屏或试用截图 | 测试架构师 | 是 |
| 用例管理 | 版本与复用 | 用例修改留痕，可引用公共用例步骤，避免同一操作在多处重复维护 | 操作截图与厂商书面说明 | 测试架构师 | 否 |
| 用例管理 | 批量维护 | 支持批量导入、批量修改属性、批量归档 | 现场操作 | 测试负责人 | 否 |
| 计划与执行 | 计划编排 | 能把用例集编排进一轮测试计划，指定执行人与时间范围 | 演示录屏 | 测试负责人 | 是 |
| 计划与执行 | 执行记录 | 逐条记录通过、失败、阻塞及备注，失败时可直接发起缺陷 | 现场完成一次执行并提交缺陷 | 测试负责人 | 是 |
| 计划与执行 | 结果回填 | 缺陷修复后能回到原执行记录标记验证结果，执行状态自动更新 | 演示录屏 | 测试负责人 | 是 |
| 缺陷关联 | 双向追溯 | 从用例可查到关联缺陷，从缺陷可回到来源用例与需求 | 现场双向点击验证 | 测试架构师 | 是 |
| 报告与度量 | 覆盖率与通过率 | 按计划、迭代或版本查看用例覆盖率、执行通过率 | 报告截图 | 测试负责人 | 否 |
| 报告与度量 | 视图可配置 | 能按本方关注维度调整统计口径与展示字段 | 现场配置演示 | 测试负责人 | 否 |
| 权限与角色 | 项目级与角色级权限 | 不同项目可见范围隔离，角色决定可执行的操作 | 用两个账号现场验证 | 研发效能人员 | 是 |
功能核验的判定原则是“闭环优先”。单项功能看起来齐全，但用例、计划、执行、缺陷、报告之间断链，实际使用中就要靠人工搬运数据。评审时至少要求厂商现场走通一次完整闭环，闭环中断的位置就是需要追问的点。以 ONES 为例，其测试管理覆盖测试用例、测试计划与执行、缺陷关联与测试报告，用例可关联需求和缺陷，执行结果回填后进入报告统计；评审时可把这条链路作为演示脚本的一部分，核验各环节是否在同一平台内衔接。具体能力以实际演示和官方资料为准。
集成、数据与运行条件检查项
功能核验回答“能不能用”，这一阶段回答“能不能长期用”。集成方式、数据可迁移性和运行条件往往决定上线后是否返工，检查时要把已确认项与待验证项分开记录，未确认的写成待验证，不写成不支持。
| 检查项 | 通过标准 | 证据 | 负责人 | 阻断 |
|---|---|---|---|---|
| 需求与缺陷系统集成 | 与现有需求管理、缺陷跟踪系统的对接方式明确（原生集成、开放接口或中间同步），并完成一次数据互通验证 | 接口文档、联调记录 | 研发效能人员 | 是 |
| 代码与流水线集成 | 能接收流水线回传的构建或自动化执行结果，并与测试计划关联 | 联调截图或厂商书面方案 | 研发效能人员 | 否 |
| 开放接口 | 提供 API 文档，覆盖用例、计划、执行记录、缺陷的读写 | API 文档 | 测试架构师 | 是 |
| 数据导入导出 | 历史用例与执行结果可按约定格式导出；导入模板可用，试导一批真实数据成功 | 试导结果与字段映射表 | 测试负责人 | 是 |
| 部署形态 | 部署方式符合准备阶段确认的约束，升级方式与频率明确 | 部署方案说明 | 研发效能人员 | 是 |
| 备份与账号体系 | 备份策略明确；账号可对接企业统一身份体系或满足权限管理要求 | 方案说明与配置截图 | IT | 是 |
| 性能与容量 | 约定验证方式，例如以本方最大项目的用例量和并发执行人数做压测或参考同类规模案例 | 压测报告或案例说明 | 测试架构师 | 否 |
| 安全与合规材料 | 按本方要求索取权限审计、操作日志留存等证明材料，材料齐备且可核验 | 厂商提供的书面材料 | 采购评审人 | 是 |
这一阶段的常见问题是把“厂商说可以”当成已确认。处理办法是给每项标注状态：已确认（有文档或联调记录）、待验证（有方案但未验证）、未确认（尚无答复）。待验证项进入试点阶段补证，未确认项在评审结论中单独列出，不能默认通过。数据导出尤其要实际试一次，只看到导出按钮不算通过，要确认导出文件包含用例步骤、执行结果和缺陷关联关系。
试点验证与证据留存
试点把前几阶段的判断落到真实数据上。范围不宜大，选一条真实产品线的一个迭代即可，关键是覆盖完整链路：用例维护、计划执行、缺陷提交与验证、报告查看。试点前把观察指标和记录格式定好，试点中只记录事实，结论留到复评会。
| 记录项 | 内容要求 | 负责人 |
|---|---|---|
| 试点范围 | 产品线名称、迭代周期、纳入的用例数量与参与人数 | 测试负责人 |
| 用例维护耗时 | 试点前后同类用例的新建与修改耗时对比，记录测量方式 | 测试侧执行人 |
| 执行记录完整率 | 计划内用例有执行结果的比例，未执行原因分类 | 测试侧执行人 |
| 缺陷追溯可查率 | 抽查缺陷能回到来源用例与需求的比例 | 测试架构师 |
| 集成运行情况 | 需求、缺陷、流水线对接是否按预期工作，异常记录 | 研发效能人员 |
| 证据留存 | 演示录屏、试点数据截图、厂商书面答复统一归档位置 | 采购评审人 |
| 试点结论 | 按“通过、有条件通过、不通过”三档记录，附理由与待补证据 | 评审组共同确认 |
观察指标要事先约定口径，例如“执行记录完整率”按计划内用例条数计算，还是按执行步骤计算，两种口径结果差别很大。试点结束后由业务侧、测试侧、IT 或采购侧分别给出意见，再合并为试点结论。有条件通过的项要写明补证内容和复评时间，避免结论悬空。
阻断项与完成条件
阻断项是那些不通过就不能进入下一阶段的检查项。设置阻断项的目的是防止带着关键缺口推进上线，把返工成本压到最低。以下为常见阻断项示例，评审组可结合本方约束增补，但增补后要在评审前公布，不能会后追加。
- 核心用例与执行流程无法闭环：用例、计划、执行记录、缺陷、报告之间存在断链，需要人工搬运数据。
- 关键集成方式无法确认：与需求或缺陷系统的对接只有口头承诺，没有接口文档或联调记录。
- 数据无法导出：历史用例与执行结果不能按可用格式导出，存在锁定风险。
- 部署形态或账号体系不符合已确认约束。
- 安全与合规材料缺失且无法在约定期限内提供。
有条件通过项的处理规则是限期补证：写明补证内容、责任方和复评日期，到期未补证自动转为不通过。完成条件分两层：所有阻断项通过；非阻断项均有明确结论和负责人，待验证项已安排验证计划。两层都满足，评审才算完成。
评审结论页应包含候选产品、各阶段通过情况、阻断项处理结果、有条件通过项及复评安排、最终建议和签署人。结论页与证据材料一并归档，作为后续采购和上线决策的依据。清单本身也应在每次评审后复盘一次，把反复出现的争议项补充为新的检查项，让下一轮评估更省力。
常见问题
评审会上厂商演示很流畅，但会后说不清哪款更合适，清单能怎么用？
问题通常出在演示按厂商节奏走，评审方没有预设场景。准备阶段先按本方真实流程写一份演示脚本，要求厂商按脚本操作，脚本里包含一条完整链路：从需求出发建立用例、编排一轮测试计划、记录执行结果、提交缺陷并回填验证结论、最后查看覆盖率与进度报告。评审时主持人按清单逐项过，每项当场记录“看到什么、留下什么证据”，会后对照同一口径比较候选产品，结论就不会被演示观感左右。
试点范围选多大合适，观察指标怎么定才不至于各说各话？
试点选一条真实产品线的一个迭代即可，范围小但链路要完整，覆盖用例维护、计划执行、缺陷提交与验证、报告查看。指标口径必须在试点前写清楚，例如“执行记录完整率”是按计划内用例条数计算还是按执行步骤计算，两种口径结果差别很大。试点中只记录事实，结论留到复评会，由业务侧、测试侧、IT 或采购侧分别给出意见后合并为通过、有条件通过或不通过。
厂商口头承诺可以对接现有缺陷系统，这项算通过吗？
不算。集成类检查项的通过标准是有接口文档或联调记录，口头承诺只能记为待验证。处理办法是给每项标注状态：已确认（有文档或联调记录）、待验证（有方案但未验证）、未确认（尚无答复）。待验证项进入试点阶段补证，未确认项在评审结论中单独列出，不能默认通过。如果关键集成方式在约定期限内仍无法确认，按阻断项处理。
有条件通过的项到期没补上证据，后续怎么处理？
按清单规则自动转为不通过。有条件通过项在记录时就要写明补证内容、责任方和复评日期，到期未补证即视为不通过，避免结论悬空。转为不通过后，如果该项属于阻断项，评审不能进入下一阶段；如果属于非阻断项，则在结论页中记录为不通过并说明影响范围，由评审组决定是否重新安排评估。
这份清单和现有测试工具的搬迁工作怎么衔接？
清单只检查可行性问题，例如历史用例与执行结果能否按约定格式导出、导入模板是否可用、试导一批真实数据是否成功，不展开搬迁步骤。搬迁的执行方案、切换顺序和回滚安排按迁移流程单独处理。这样分工的好处是评审会聚焦在平台是否可用，迁移细节由专项工作推进，两边结论互相引用而不互相拖累。
