测试规范 v1.0

QA 工作标准

用于规范需求评审、测试用例设计、测试执行、禅道 Bug 提交、回归验证和版本总结，目标是让问题可复现、可定位、可追溯、可闭环。

• 适用：管理端 / 客户端 / 运营端
• 重点：步骤、结果、期望
• 要求：结果放定位信息，附件传复现视频

快速理解

1. 先确认需求 —— 明确范围、规则、权限、状态和多端一致性，减少后续返工。
2. 再安排轮次 —— 按冒烟、全量、收敛、上线前验证推进，紧急情况按风险取舍。
3. Bug 要可复现 —— 标题清楚，步骤、结果、期望完整，截图和接口信息放在结果中。
4. 回归要闭环 —— 原问题修复后备注已回归；修复引入的新问题必须新建 Bug。

1. 测试流程总览

按阶段推进，先确认需求，再设计用例，最后完成 Bug 闭环和版本总结。

流程：需求评审 → 测试分析 → 用例设计 → 测试准备 → 冒烟测试 → 全量测试 → Bug 跟踪 → Bug 回归 → 测试总结

测试轮次安排

阶段	名称	核心目标	主要内容
第 0 轮	冒烟测试	判断版本是否具备继续测试的条件。	验证核心页面、主流程、关键按钮、关键接口和基础数据；不通过则阻断全量测试。
第 1 轮	全量测试 + 首轮 Bug 回归	全面发现问题，并完成首批修复验证。	按用例执行全量测试，覆盖正常、异常、边界、权限、状态、多端一致性和数据一致性；开发修复本轮 Bug 后，及时回归已修复问题。
第 2 轮	问题收敛测试	确认问题是否明显减少，修复是否稳定。	验证遗留 Bug、重新打开 Bug、修复影响范围、核心链路和高风险模块；如发现新增 Bug，继续提交并回归。
第 3 轮	上线前验证	判断是否具备上线条件。	重点确认核心流程、严重 Bug、遗留风险、配置项、兼容性、上线影响范围和回滚方案。
补充轮次	变更/风险补测	应对临时变更、高风险修复或遗留问题较多的情况。	针对需求变更点、公共组件、接口改动、权限/状态流转和高风险模块追加测试。

2. 需求评审规范

在开发前明确需求范围、业务规则、异常场景和影响范围。

检查项	确认内容
功能范围	本次做什么、不做什么，避免测试范围和产品预期不一致。
页面入口	从哪里进入，涉及哪些页面、按钮、列表和详情。
业务规则	不同状态、不同角色、不同端下的处理逻辑。
数据规则	字段来源、默认值、为空展示、异常值处理、历史数据兼容。
权限规则	不同角色是否可见、可操作，越权时如何提示。
多端一致性	管理端、客户端、运营端或其他业务端展示是否需要保持一致。
影响范围	是否影响已有功能、接口、列表、导出、定时任务等。
上线要求	是否需要灰度、配置开关、回滚方案、兼容旧版本。

执行要求

不明确的地方及时和产品确认，确认后的结论要记录下来；涉及规则变更时，同步更新测试用例。

执行关注点

• 每次评审后整理疑问点和确认结论，避免后续测试口径不一致。
• 对权限、状态、异常、多端一致性等容易遗漏的规则主动追问。
• 需求有变更时，及时同步测试范围、用例和回归重点。
• 评审结论要能支持后续用例设计和 Bug 期望结果判断。

3. 测试用例设计规范

用例不只覆盖正常流程，还要覆盖边界、权限、状态、多端和回归场景。

类型	说明
正常流程	按需求正常操作，功能可正确完成。
异常流程	接口失败、数据为空、权限不足、参数异常。
边界场景	空值、超长、特殊字符、最大值、最小值。
权限场景	超级管理员、普通管理员、运营人员、普通用户、游客等角色差异。
状态场景	未开始、进行中、已结束、禁用、删除等状态。
多端一致性	管理端、客户端、运营端或其他业务端展示是否一致。
数据一致性	页面展示、接口返回、数据库数据是否一致。
历史兼容	老数据、历史版本数据是否正常展示。
回归场景	本次改动是否影响已有功能。

执行弹性

测试用例根据项目节奏和实际情况编写；如果时间紧急，可以不完整编写用例，但需优先明确核心流程、重点风险、冒烟范围和回归范围。

可复制 Excel 用例模板

用例编号	所属模块	测试场景	前置条件	操作步骤	预期结果	优先级	是否冒烟	测试类型
TC-001		输入测试场景	输入前置条件	1、xxx 2、xxx	输入预期结果	P0 / P1 / P2	是 / 否	功能 / 接口 / 权限 / 展示 / 回归

推荐用例格式

字段	填写说明	示例
用例编号	保持唯一，方便引用和回归。	TC-ORDER-001
所属模块	填写到具体功能模块。	订单管理 / 订单详情
测试场景	描述要验证的业务场景。	已支付订单状态展示
前置条件	执行用例前需要准备的账号、数据或状态。	存在一笔已支付订单
操作步骤	按 1、2、3 写清楚入口和操作。	进入订单列表，打开订单详情
预期结果	写清楚页面、接口或数据应表现为什么。	支付状态显示为“已支付”
优先级	标识执行优先级。	P0 / P1 / P2
是否冒烟	标识是否纳入冒烟测试。	是 / 否
测试类型	标识用例覆盖方向。	功能 / 接口 / 权限 / 展示 / 回归

用例展示示例

用例编号	模块	测试场景	前置条件	操作步骤	预期结果	优先级	冒烟	类型
TC-ORDER-001	订单管理	已支付订单状态展示	存在一笔已支付订单	进入订单列表，打开订单详情	支付状态显示为“已支付”	P0	是	功能 / 展示
TC-ORDER-002	订单管理	无权限查看订单详情	使用无订单查看权限账号	进入订单列表，打开订单详情	无权限访问，并给出明确提示	P1	否	权限 / 异常

执行关注点

• 核心流程必须有 P0 用例，并纳入冒烟测试范围。
• 重要功能至少覆盖正常、异常、边界、权限、状态和回归场景。
• 涉及多端展示或数据流转时，用例中要明确对比端和对比字段。
• 历史高发问题要沉淀为固定回归用例，避免同类问题反复出现。

4. 测试执行规范

先做冒烟判断版本是否可测，再按用例执行全量测试。

冒烟测试

页面能打开，核心按钮可点击，主流程能走通，关键接口正常返回，基础数据能展示。冒烟不通过时，及时反馈开发并阻断全量测试。

全量测试

覆盖主流程、分支流程、异常场景、边界数据、权限控制、多端展示、接口返回、数据一致性和历史功能回归。

执行要求

• 按测试用例执行，执行结果及时记录。
• 发现问题保留环境、账号、数据、接口信息。
• 关键问题在结果中补充截图、curl、接口返回；有复现视频时上传附件。
• 涉及多端展示时，对比管理端、客户端、运营端或其他业务端。

轮次要求

• 常规需求至少包含第 0 轮冒烟测试、第 1 轮全量测试 + 首轮 Bug 回归、第 2 轮问题收敛测试和第 3 轮上线前验证。
• 第 1 轮重点是发现问题和验证首批修复，不能只提交 Bug 不回归。
• 第 2 轮重点是问题收敛、修复稳定性、影响范围和高风险模块验证。
• 第 3 轮重点是上线风险确认，不建议再做大范围需求变更。
• 需求变更、核心链路改动、公共组件改动时，需要增加补充测试轮次。
• 每轮测试都要明确测试范围、测试结果、遗留问题和下一步处理动作。
• 上线前最后一轮测试要重点确认核心流程、严重 Bug、遗留风险和回滚方案。

执行关注点

• 冒烟不通过时，优先反馈阻塞点，不继续投入全量测试。
• 全量测试优先执行高风险模块、核心链路和历史问题较多的功能。
• 测试过程中发现需求不清或规则冲突时，及时拉齐产品和开发结论。
• 测试记录要能支撑后续 Bug 提交、回归验证和测试总结。

5. 禅道 Bug 提交规范

字段填完整，标题说清楚，步骤可复现，证据能定位，版本可追溯。

字段	填写要求
所属产品	选择实际问题所属产品。
所属模块	选择具体模块，尽量不要只选 “/”。
影响版本	填写 Bug 出现的版本，便于追溯和回归。
当前指派	指派给对应开发；不确定时指派模块负责人。
Bug 标题	按“模块路径 + 问题现象”填写。
Bug 类型	根据问题选择，如代码错误、设计缺陷、配置问题等。
严重程度	根据影响范围判断。
优先级	根据修复紧急程度判断。
重现步骤	必须包含步骤、结果、期望；结果中可补充截图、curl、接口返回等定位信息；如问题只在个别机型、账号、角色、环境或数据状态下出现，需要在步骤前补充前置条件。
附件	仅用于上传复现视频。

执行关注点

• Bug 标题必须体现端、模块、功能点和问题现象。
• 重现步骤必须包含步骤、结果、期望，结果中补充截图、curl、接口返回等定位信息。
• 个别手机型号、个别账号、指定角色、特定环境或特定数据才出现的问题，需要先写清楚前置条件。
• 影响版本、环境、账号角色、数据对象等定位信息要尽量补充完整。
• 偶现问题需要标明“偶现”，并补充复现概率、出现时间和可用证据。

6. Bug 标题规范

标题要让开发一眼看出问题发生在哪、是什么问题。

标题格式

【端】【一级模块】【二级模块】【页面/入口】【功能点】问题现象

示例

【管理端】【订单管理】【订单列表】【订单详情】【支付状态】已支付订单状态显示为“待支付”，未显示“已支付”

• 写清楚端：管理端 / 客户端 / 运营端
• 写清楚模块路径
• 写清楚具体功能点
• 写清楚实际现象
• 偶现问题标明“偶现”

7. 重现步骤模板

前置条件、步骤、结果、期望要描述清楚，让开发可以照着复现。

通用模板

[前置条件]

如涉及个别手机型号、个别账号、指定角色、特定环境或特定数据状态，需要在这里说明。

[步骤]

1、点击左侧菜单栏【一级模块】
2、进入【二级模块/页面】
3、点击【按钮/入口】
4、执行【具体操作】
5、查看【页面/列表/字段/接口结果】

[结果]

xxx

截图：粘贴在结果中，标注异常位置
curl：粘贴在结果中
接口返回：粘贴关键响应字段或错误信息
复现视频：如有则上传到附件

[期望]

应正确展示/返回 xxx。
如涉及多页面或多端展示，相关展示结果应保持一致。

示例

Bug标题：
【管理端】【订单管理】【订单列表】【订单详情】【支付状态】已支付订单状态显示为“待支付”，未显示“已支付”

[前置条件]

存在一笔已支付订单。

[步骤]

1、点击左侧菜单栏【订单管理】
2、进入【订单列表】页面
3、搜索并点击目标订单的【详情】按钮
4、查看订单详情中的【支付状态】字段

[结果]

该订单已完成支付，但管理端订单详情中的支付状态显示为“待支付”，未显示“已支付”。

截图：
粘贴在结果中，标注支付状态异常位置。

curl：
粘贴在结果中。

接口返回：
粘贴关键响应字段或错误信息。

复现视频：
如有则上传到附件。

[期望]

已支付订单在管理端订单详情中应显示为“已支付”。
客户端订单详情、管理端订单列表等相关页面的支付状态应保持一致。

8. 证据材料规范

明确截图、curl、接口返回和复现视频分别放在哪里，避免 Bug 信息分散。

材料类型	放在哪里	说明
截图	重现步骤的「结果」中	用于标注页面异常位置、字段显示问题或错误提示。
curl / 请求参数	重现步骤的「结果」中	用于接口类问题定位，方便开发复现请求。
接口返回	重现步骤的「结果」中	粘贴关键响应字段、错误码或错误信息。
业务数据标识	重现步骤的「结果」中	如订单号、用户 ID、记录 ID 等，方便开发查询数据。
复现视频	附件	仅复现路径较长、问题偶现或截图难以说明时上传。

执行关注点

• 截图、curl、接口返回和关键数据统一放在重现步骤的结果中。
• 附件只上传复现视频，不放截图、curl 或接口返回。
• 复现视频用于说明较长流程、偶现问题或截图难以表达的问题。

9. 严重程度与优先级规范

严重程度看影响有多大，优先级看修复有多急。

严重程度

级别	判断标准
1	系统崩溃、核心流程不可用、数据严重错误。
2	重要功能不可用，影响主流程或核心业务。
3	一般功能异常，有替代方案，不阻塞主流程。
4	文案、样式、展示、小体验问题。

优先级

级别	判断标准
1	阻塞测试或阻塞上线，必须立即修。
2	影响核心功能，本版本应修复。
3	普通问题，可按计划修复。
4	优化类、低影响问题，可后续处理。

10. Bug 回归规范

回归完成后，在 Bug 备注中简单说明已回归。

回归模板

备注：已回归

重要规则

如果因当前 Bug 修复导致出现新的问题，需要重新提交新 Bug，不在原 Bug 上备注或修改为新问题。

执行关注点

• 回归时先验证原问题是否已修复。
• 确认修复后，在备注中填写“已回归”。
• 如果未修复或仍有异常，重新打开 Bug 并说明当前问题。
• 涉及公共逻辑、接口、权限、状态流转时，适当验证关联功能。

11. 测试总结规范

每个版本测试完成后，简要说明测试结论、覆盖范围、关键数据、遗留问题和上线建议。

可复制总结模板

[测试结论]
测试结论：建议上线 / 有条件上线 / 暂缓上线
说明：

[测试范围与数据]
测试范围：
测试版本：
测试环境：
执行用例数：
新增 Bug 数：
已修复 Bug 数：
遗留 Bug 数：

[遗留问题]
遗留问题：
影响范围：
是否影响上线：是 / 否

[上线建议]
上线建议：

[后续改进]
后续改进：

测试结论

项目	填写内容
测试结论	建议上线 / 有条件上线 / 暂缓上线。
说明	简要说明给出该结论的主要原因。

测试范围与数据

项目	填写内容
测试范围	本次覆盖的需求、模块或功能点。
测试版本	版本号、构建号、提测时间或上线批次。
测试环境	测试环境 / 预发环境 / 线上验证环境。
执行用例数	本次实际执行的用例数量。
新增 Bug 数	本轮测试新提交的 Bug 数量。
已修复 Bug 数	已完成回归且确认修复的 Bug 数量。
遗留 Bug 数	未修复、部分修复或暂不处理的 Bug 数量。

遗留问题与上线建议

项目	说明
遗留问题	列出未修复、部分修复或暂不处理的问题。
影响范围	说明影响的功能、用户、数据或流程。
是否影响上线	是 / 否，并说明原因。
上线建议	建议上线 / 有条件上线 / 暂缓上线。

后续改进

类型	影响范围	后续处理
需求/用例	需求遗漏、用例遗漏或未覆盖场景。	补充评审检查项或回归用例。
Bug / 回归	Bug 定位信息不足或回归范围不足。	后续补充定位材料，扩大关联回归。

测试复盘关注点

• 测试总结要先给结论，再补充范围、数据和风险。
• 遗留问题要说明影响范围，以及是否影响上线。
• 后续改进只记录关键问题，避免总结过重。