测试工具使用规范要写清楚五件事：谁在什么阶段、用什么工具、按什么字段和状态、留下什么记录、异常怎么处理。本文给出一份虚构团队“示例项目”的完整规范范例，覆盖缺陷记录、用例维护、执行记录、环境与数据、权限与交接五类条目，并逐项解释填写理由与可迁移规律。规范落地到测试管理平台时，可参考ONES对用例、计划与缺陷流转的承载方式。
要点总览（TL;DR）
- 测试工具使用规范要写清五件事：谁在什么阶段、用什么工具、按什么字段和状态、留下什么记录、异常怎么处理。
- 范例覆盖缺陷记录、用例维护、执行记录、环境与数据、权限与交接五类条目，每类按“对象—字段—状态—责任人—留痕”展开。
- 严重程度与优先级分开填写、用例编号不复用、执行结果限定四种状态并与缺陷双向关联，是范例中值得保留的设计。
- 换团队时保留五要素骨架，按规模调整分级档位、评审环节、轮次命名与状态流转。
- 范例为虚构示例情景，纯执行框架代码写法与现有工具搬迁不在本文范围。
这份规范示例要解决什么问题
这份规范面向一个虚构的“示例项目”团队：测试人员3名、开发人员8名、产品经理1名，按两周一个迭代交付Web端业务系统。团队已经选定一款测试管理工具，但各人填写缺陷、维护用例、记录执行结果的方式不一致，导致回归时找不到依据、缺陷复现困难、人员交接后责任不清。规范的目标，是把这些日常动作统一成可检查的填写要求，让同一份记录在不同人手里读起来含义一致。
规范约束五类条目，每类都按“对象—字段—状态—责任人—留痕”的骨架展开：
- 缺陷记录：缺陷如何命名、分级、描述复现过程、挂接附件与关联用例。
- 用例维护：用例如何编号、写前置条件与步骤、经过评审、记录变更。
- 执行记录：执行轮次如何命名、结果状态如何取值、失败如何转缺陷。
- 环境与数据：环境如何标识、测试数据从哪来、用完如何清理。
- 权限与交接：角色拥有哪些操作权限、离岗与交接如何留痕。
需要区分规范与测试执行框架代码的分工。规范约束的是人在测试管理工具中的记录行为：填什么字段、选什么状态、由谁确认。执行框架代码负责自动化脚本的组织、断言与运行调度，属于工程实现层面。两者可以互相引用，例如规范要求自动化执行结果回写到执行记录，但脚本怎么写、用什么框架不在规范内规定。这样划分的好处是，规范不会因技术栈更换而失效，框架调整也不必同步修改填写要求。
完整示例：示例项目的测试工具使用规范
以下为“示例项目”测试工具使用规范的已填写版本。文中团队名称、人员角色、字段取值均为虚构示例，用于演示填写方式，不代表任何真实客户或实测效果。
一、缺陷记录规范
缺陷在测试管理工具中以缺陷工作项记录，测试人员提交，开发人员处理，测试人员验证关闭。
| 字段 | 填写要求 | 示例值 |
|---|---|---|
| 标题 | “模块-操作-异常现象”，不超过40字，不写“有问题”“不对”这类无信息描述 | 订单列表-按日期筛选-选择跨月区间后结果为空 |
| 严重程度 | 按缺陷对业务的影响定档：阻断、严重、一般、轻微 | 严重 |
| 优先级 | 按本迭代修复的紧迫性定档：P0至P3，由测试提出、开发负责人确认 | P1 |
| 复现步骤 | 编号列出操作路径，每步一个动作，注明测试数据与账号 | 1. 使用测试账号test_03登录；2. 进入订单列表；3. 筛选条件选3月1日至4月15日；4. 点击查询 |
| 预期与实际 | 分两段写，预期引用需求或用例，实际描述观察到的现象 | 预期：返回区间内订单；实际：列表为空且无提示 |
| 附件 | 截图或录屏，文件名含缺陷编号；日志截取相关片段 | BUG-1024-筛选结果.png |
| 关联用例 | 填写触发该缺陷的用例编号，便于回归时定位 | TC-ORDER-018 |
状态流转约定为：新建→已确认→修复中→待验证→已关闭，验证不通过退回“修复中”并补充验证记录。开发人员拒绝的缺陷须填写理由，由测试负责人复核。
二、用例维护规范
用例编号采用“TC-模块缩写-三位序号”，如TC-ORDER-018，编号一经分配不复用。每条用例包含：所属模块、优先级、前置条件、操作步骤、预期结果、关联需求。
- 前置条件：写清进入用例前必须满足的数据与状态，例如“已存在一笔待支付订单”。
- 步骤与预期：步骤与预期一一对应，一步一预期，避免多个断言混在一行。
- 评审：新增或大改用例须经至少一名同组测试人员评审，评审意见记录在用例的评论或评审记录中，评审通过后状态改为“已评审”。
- 变更记录：修改步骤或预期时，在变更说明中写明原因与关联缺陷编号；删除用例改为“已废弃”状态并注明替代用例，不直接物理删除。
三、执行记录规范
执行轮次按“迭代号-轮次”命名，如“S12-R1”表示第12个迭代第一轮。每轮执行前由测试负责人创建测试计划，关联本迭代需求与用例范围。
| 结果状态 | 含义 | 后续动作 |
|---|---|---|
| 通过 | 实际结果与预期一致 | 记录执行人与执行时间 |
| 失败 | 实际结果与预期不一致 | 当轮创建缺陷并回填缺陷编号 |
| 阻塞 | 环境或前置数据不满足，无法判断 | 注明阻塞原因与解除条件 |
| 未执行 | 本轮范围外或时间不足 | 注明原因，进入下轮计划 |
失败用例转缺陷时，在执行记录中填写缺陷编号，缺陷工作项中回填用例编号，形成双向关联。同一用例在多轮中重复失败，须在缺陷中补充轮次信息，避免重复建单。
四、环境与数据规范
环境标识统一为“环境类型-版本号”，如“测试环境-v2.3.1”“预发环境-v2.3.1”。缺陷与执行记录中必须填写发生问题的环境标识，跨环境复现时逐一列出。
- 数据来源：优先使用专门准备的测试数据集，注明数据集名称与版本；临时构造的数据在缺陷中写明构造方式。
- 数据隔离：涉及账号、订单等共享数据时，使用个人测试账号前缀，避免互相覆盖。
- 清理：每轮执行结束后清理本轮构造的临时数据，保留清理记录；需要保留的复现数据标注“保留至缺陷关闭”。
五、权限与交接规范
角色权限按最小必要配置：测试人员可创建和编辑用例、提交缺陷、执行测试计划；开发人员可查看用例、处理分配给自己的缺陷；测试负责人额外拥有用例评审确认、测试计划创建与报告发布权限。用例库与测试计划可按项目单独授权。
人员离岗或转岗时，须在交接单中列出：名下未关闭缺陷、负责的用例模块、进行中的测试计划，逐项指定接收人。交接完成后由测试负责人在工具中调整成员归属并留存交接记录，原责任人不再保留编辑权限。
逐项解释：每条规范为什么这样写
严重程度与优先级分开填写。严重程度描述缺陷本身对业务的影响，由缺陷性质决定，不随排期变化；优先级描述本迭代修复的紧迫性，受发布计划、客户影响面影响。两者合并成一个字段，会出现“影响很大但本迭代修不了”的缺陷被迫降级，掩盖真实风险。分开填写后，测试按影响定严重程度，开发负责人按排期定优先级，各自对判断负责。常见误填是把“客户催得急”写成严重程度高，这类信息应放在优先级或备注中。
用例编号与变更记录服务于回归。固定编号让缺陷、执行记录、自动化脚本都能稳定引用同一条用例，编号复用会导致历史关联指向错误对象。变更记录解决的是“这条用例上次为什么改”的问题：回归失败时，能快速判断是产品变更还是用例本身写错。评审环节的价值在于让预期结果经过第二人确认，减少因个人理解偏差产生的误报。
执行结果状态与缺陷关联保证可追溯。把结果限定为通过、失败、阻塞、未执行四种，是为了让统计口径一致：通过率只统计通过与失败，阻塞和未执行单独说明。失败用例与缺陷双向关联后，可以从缺陷查到哪条用例、哪一轮暴露的问题，也可以从用例查到历史上失败过几次。缺少这层关联，测试报告只能给出数字，无法回答“这个模块为什么不稳定”。
环境标识与数据清理直接影响复现。同一缺陷在不同环境表现可能不同，不写环境标识，开发人员只能反复询问。数据清理看似增加工作量，实际是让下一轮执行从已知状态开始；保留必要的复现数据并标注保留期限，则兼顾了复现需求与数据整洁。
权限与交接留痕明确责任归属。按角色配置权限，减少误改他人用例和误关缺陷的可能；用例库与测试计划单独授权，适合多项目并行时隔离范围。交接留痕的意义在于，人员变动后仍能追溯到谁在何时移交了哪些未完成事项，避免缺陷在人员更替中无声消失。
可迁移规律：换团队时改哪些、留哪些
这份范例可以拆成骨架与可调参数两层。骨架部分建议保留，它决定了规范是否可执行；参数部分按团队实际情况调整，不影响规范的有效性。
| 层次 | 内容 | 调整建议 |
|---|---|---|
| 必须保留 | 对象、字段、状态、责任人、留痕五要素 | 任何一类条目缺少责任人或不留痕，规范都会退化为建议 |
| 可调整 | 严重程度分级档位 | 小团队可用三级，大型多产品线可用四级并附判定示例 |
| 可调整 | 用例评审环节 | 核心模块强制评审，边缘模块可改为抽查 |
| 可调整 | 执行轮次命名 | 按迭代、按版本或按日期命名均可，关键是全团队统一 |
| 可调整 | 缺陷状态流转 | 流程简单的团队可去掉“已确认”，由开发直接处理 |
规范落地到测试管理平台时，承载方式通常是：缺陷、用例、测试计划作为工作项类型存在，字段对应工作项属性，状态对应工作流节点，交接与评审记录以评论或操作日志留存。ONES测试管理支持测试用例与需求、任务关联，测试计划与迭代关联，形成测试流程闭环；支持自定义用例属性以适配不同业务场景；未通过的用例可快速创建缺陷任务，缺陷任务在测试与研发团队间流转；并支持为不同用户组、用例库和测试计划单独配置权限。这些能力对应规范中的关联、字段、流转与权限条目，具体配置方式以实际使用版本为准。
规范本身也需要维护机制。建议在项目启动时评审一次，之后每个季度或每次重大流程变更时复核，复核内容包括：字段是否仍被使用、状态是否有长期滞留、交接记录是否完整。修订由测试负责人发起，变更点在规范文档中记录版本与生效日期，避免口头约定替代书面规范。
适用边界：这份范例不覆盖什么
本文的“示例项目”、人员角色、字段取值与状态流转均为虚构情景，用于演示规范的填写结构，不代表任何真实客户案例，也没有经过实际项目验证或效果统计。读者参照时应替换为自身团队的真实角色与流程。
以下内容不在本文范围：
- 纯测试执行框架的代码写法：自动化脚本组织、断言库选择、持续集成配置属于工程实现，本文只在规范与代码的分工边界处提及。
- 现有工具的搬迁与迁移：从其他工具导入历史用例、缺陷数据的方案与步骤，需要单独评估。
- 具体工具的能力、版本与价格：不同产品、不同版本在字段类型、状态配置、权限粒度上存在差异，选型或采购前应查阅对应产品的官方资料并实际试用确认。
此外，规范的有效性依赖团队执行与定期复核。若团队规模、交付节奏或合规要求发生较大变化，应重新评审条目，而不是直接沿用旧版。
常见问题
团队规模很小，也要按范例写五类条目吗？
条目可以合并，骨架建议保留。两三个人的团队可以把环境与数据规范并入执行记录，把权限与交接简化为一条交接说明，但每类条目仍要写清责任人、字段取值和留痕位置。条目合并后规范篇幅变短，检查时依然能回答“这条记录谁填的、依据是什么”。
缺陷的严重程度和优先级由谁定，出现分歧怎么办？
范例的做法是测试人员按业务影响定严重程度，开发负责人按本迭代排期定优先级，各自对判断负责。出现分歧时，先确认分歧出在影响判断还是排期判断：影响判断以需求文档和用例预期为依据，排期判断以发布计划为依据。两者都成立时，保留原严重程度、调整优先级，并在缺陷备注中写明调整理由，便于复盘时追溯。
执行记录里的“阻塞”和“未执行”容易混，怎么区分？
判断标准是能否得出结果。“阻塞”指用例已经尝试执行，但环境或前置数据不满足，无法判断实际结果是否符合预期；“未执行”指本轮没有开始执行，原因可能是范围外或时间不足。区分清楚后，通过率统计只取通过与失败，阻塞项需要跟进解除条件，未执行项进入下一轮计划，测试报告的统计口径才一致。
规范写好后，怎么保证团队持续执行？
建议把规范评审放进项目启动环节，之后每季度或流程重大变更时复核一次。复核重点看三件事：字段是否仍被使用、状态是否有长期滞留、交接记录是否完整。修订由测试负责人发起，在规范文档中记录版本与生效日期。规范落地到测试管理平台时，字段、状态、权限可以配置在工作项和工作流中，减少靠记忆执行的部分；ONES 测试管理支持为不同用户组、用例库和测试计划单独配置权限，可作为权限条目的承载方式，具体配置以实际使用版本为准。
范例里的用例编号规则能直接照搬吗？
编号格式可以照搬，“TC-模块缩写-三位序号”适合模块划分清晰的团队。需要按自身情况调整的是模块缩写的粒度：模块多、迭代快的团队，缩写过细会导致编号难记，可以按产品线或一级模块取缩写；模块少的团队可以保留细粒度。无论怎么改，编号一经分配不复用这条规则建议保留，否则缺陷、执行记录和历史脚本的关联会指向错误对象。
