一份合格的Bug报告通常包含标题、环境、复现步骤、预期结果、实际结果、严重程度与优先级、附件证据和补充说明八个部分。本文给出一份填写完整的示例，并逐项解释写法依据，帮助读者把这套结构迁移到自己的缺陷记录中。示例中的产品、版本、设备和操作路径均为虚构演示情景，不代表真实项目数据或实测结果。
要点总览（TL;DR）
- 一份完整的Bug报告包含标题、环境、复现步骤、预期结果、实际结果、严重程度与优先级、附件证据、补充说明八个部分，本文给出一份填写完整的示例。
- 标题写清“在什么条件下、哪个功能、出现什么异常”，复现步骤按可执行顺序编号并写明输入值与时间条件，预期与实际结果分开写。
- 严重程度只描述影响范围，优先级描述处理顺序；先定严重程度再结合版本计划定优先级，两个字段各管一件事。
- 示例中的产品、版本、设备和操作路径均为虚构演示情景，适用于常规功能缺陷记录；服务事件受理与分级标准制定属于其他主题。
示例目标：这份Bug报告要解决什么问题
这份示例要回答一个具体问题：一份信息完整的缺陷记录长什么样。很多Bug报告的问题不在描述长短，而在关键信息缺失——测试人员写了“登录有问题”，开发人员打开后不知道在哪个环境、用什么账号、点了哪几步。示例的作用是把八个字段填满、填自洽，让接手的人不必先来一轮追问就能开始定位。
演示情景设定如下：虚构产品“星舟协作平台”，虚构版本 V3.2.1，虚构操作路径为“登录页 → 输入手机号 → 获取验证码 → 提交登录”。缺陷现象是验证码在有效期内被提示失效。这个情景贴近常见的登录类功能缺陷，字段之间的因果关系容易看清，便于读者对照理解。
读者可以从示例中迁移三样东西：一是字段结构，即一份报告需要覆盖哪些信息块；二是写法，即每个字段用什么句式、写到什么颗粒度；三是判断依据，即严重程度和优先级为什么取这个值。示例本身不需要照抄，需要照抄的是填写时的思考顺序。
完整Bug报告示例：登录页验证码失效
以下是一份填写完整的Bug报告示例，各字段内容相互对应，可直接作为填写模板参照。
| 字段 | 填写内容 |
|---|---|
| 标题 | 登录页输入正确验证码后提示“验证码已失效”，导致手机号登录失败 |
| 环境信息 | 产品版本：星舟协作平台 V3.2.1（演示版本号）；设备：某品牌手机，6.1英寸屏；操作系统：Android 13；浏览器/客户端：星舟 App Android 端；网络：Wi-Fi；账号类型：未注册手机号与已注册手机号均出现 |
| 复现步骤 | 1. 打开星舟 App，进入登录页；2. 选择“手机号登录”；3. 输入手机号 138****0000（演示号码）；4. 点击“获取验证码”；5. 在收到短信后 30 秒内输入 6 位验证码；6. 点击“登录” |
| 预期结果 | 验证码校验通过，进入工作台首页 |
| 实际结果 | 页面提示“验证码已失效，请重新获取”，停留在登录页；重新获取后再次输入，仍在 30 秒内提示失效 |
| 复现频率 | 连续尝试 5 次，5 次均复现 |
| 严重程度 | 严重：手机号登录主路径不可用，影响该登录方式下的全部用户 |
| 优先级 | 高：登录是进入产品的前置环节，需在本次迭代内处理 |
| 附件与证据 | 登录失败页面截图 1 张；操作录屏 1 段（约 20 秒，含获取验证码到提示失效的完整过程）；客户端日志片段 1 份（含验证码校验请求与返回码） |
| 补充说明 | 同一账号在网页端使用验证码登录正常，问题仅出现在 Android 客户端；iOS 客户端未验证；关联需求为“手机号快捷登录改版” |
这份示例的完整之处在于：开发人员读到标题知道问题类别，读到环境知道去哪里复现，读到步骤可以照着操作，读到预期与实际知道偏差在哪，读到严重程度和优先级知道该多快处理，附件则提供了文字之外的直接证据。补充说明里的“网页端正常”是一条有价值的对比信息，它把排查范围缩小到了客户端侧。
逐项解释：每个字段为什么这样写
下面逐字段说明示例中的写法选择。同样的字段，写法不同，接手人的处理成本差别很大。
| 字段 | 示例写法要点 | 判断依据与常见问题 |
|---|---|---|
| 标题 | 条件（输入正确验证码后）+ 功能（登录页）+ 异常（提示已失效、登录失败）+ 影响（手机号登录不可用） | 标题是列表页和搜索结果里唯一可见的信息，写清条件、功能、异常三个要素才能被检索到。常见问题是只写“登录bug”或“验证码有问题”，同类缺陷多了以后无法区分 |
| 环境信息 | 版本、设备、系统、客户端、网络、账号类型逐项列出 | 环境决定能否复现。同一缺陷在不同系统或客户端上表现可能不同，缺一项就可能让开发在错误的环境里白试。账号类型也重要，未注册与已注册用户走的分支往往不同 |
| 复现步骤 | 按操作顺序编号，每步一个动作，包含具体输入值和时间条件 | 步骤要能被另一个人照着执行。“30 秒内输入”是时间条件，去掉它复现可能失败。常见问题是把多个动作挤在一行，或省略输入值导致无法还原 |
| 预期结果 | 一句话写清正确行为：校验通过并进入首页 | 预期结果是判断“这是不是缺陷”的基准。写得太笼统（如“应该能登录”）会让争议落在需求理解上，而不是缺陷本身 |
| 实际结果 | 写清页面提示原文、停留位置，以及重复尝试的表现 | 实际结果要与预期结果一一对应。引用界面原文提示比转述更准确；补充“重新获取后仍失效”说明问题稳定存在，而非偶发 |
| 严重程度 | 严重，理由是主路径不可用、影响该登录方式下全部用户 | 严重程度只描述影响范围与破坏力，不描述处理顺序。判断时看受影响的用户面、功能重要性和是否有绕行方案 |
| 优先级 | 高，理由是登录为前置环节，需在本次迭代内处理 | 优先级描述处理顺序，取决于版本计划、发布节点和资源安排。同一缺陷在不同迭代里优先级可以变化，严重程度通常不变 |
| 附件与证据 | 截图、录屏、日志各一份，注明内容与时长 | 证据按“能证明现象”取舍，不必把所有材料都传上去。录屏适合展示时序性操作，日志适合展示请求与返回，截图适合定格提示文案 |
| 补充说明 | 对比网页端表现、标注未验证范围、关联需求 | 补充说明放无法归入上述字段但有助于定位的信息。写明“iOS 未验证”是诚实的边界交代，避免开发误以为全端都有问题 |
严重程度与优先级的区分值得单独强调。示例中严重程度取“严重”，依据是影响范围；优先级取“高”，依据是处理时机。如果这个缺陷出现在一个即将下线的旧版本上，严重程度仍是严重，优先级可能降为中。反过来，一个界面文案错别字严重程度低，但如果出现在对外发布的引导页上，优先级可能被临时调高。两个字段各管一件事，混在一起写会让排期失去依据。
当缺陷记录进入团队的工作项系统后，字段结构会直接影响后续流转。以ONES Project为例，其缺陷管理场景支持一键提交Bug至对应项目或迭代，并跟踪修复情况；ONES TestCase中未通过的用例也可快速创建缺陷任务，在测试与研发团队间流转。这意味着示例中的环境、复现步骤、预期与实际结果等字段，最好在提交环节就填写完整，而不是等到开发追问时再补。字段的具体配置项以团队实际使用的系统为准。
可迁移规律：换一个缺陷也能照着写
示例针对的是登录类缺陷，但填写规律适用于大多数常规功能缺陷。把规律提炼出来，换一个功能模块也能照着写。
标题的通用形式是“在什么条件下 + 哪个功能 + 出现什么异常 + 造成什么影响”。影响部分在标题过长时可以省略，但条件、功能、异常三个要素建议保留。例如“在弱网环境下 + 附件上传 + 进度条卡在 99% + 文件实际未上传成功”。
复现步骤的通用结构是：起点（从哪个页面或状态进入）→ 前置条件（账号、数据、权限）→ 操作序列（编号的动作）→ 触发点（哪一步之后出现异常）。每一步只写一个动作，涉及输入值时写出具体值或取值范围。
严重程度与优先级的判断可以按顺序进行：先判断影响范围（多少用户、哪个功能、有无绕行方案）定严重程度，再结合版本计划和处理资源定优先级。先定严重程度再定优先级，可以避免因为“最近很忙”而把严重问题写轻。
信息不足时，补充提问要指向具体字段，而不是笼统地问“能再详细点吗”。可以这样问：“这个问题在网页端是否也能复现？”“使用的账号是未注册还是已注册？”“提示原文是什么？”每个问题对应一个待填字段，回答后记录即可补齐。
第二个简短示范，换一个不同缺陷类型——列表导出功能：
- 标题：在筛选结果超过 500 条时导出 Excel，文件仅包含前 100 条数据
- 环境：星舟协作平台 V3.2.1（演示版本）；Windows 11；Chrome 120；网页端
- 复现步骤：1. 进入“任务列表”页；2. 将筛选条件设为“全部项目”；3. 确认结果数为 500 条以上；4. 点击“导出 Excel”；5. 打开下载的文件并核对行数
- 预期结果：导出文件包含全部筛选结果
- 实际结果：导出文件仅包含前 100 条，第 101 条起缺失
- 严重程度：严重，数据不完整可能导致基于导出结果的决策出错；优先级：高，需在本次迭代内修复
- 附件：导出文件 1 份、筛选结果页截图 1 张
- 补充说明：筛选结果少于 100 条时导出正常；未测试其他导出格式
这个示范沿用了同一套字段和判断顺序，说明规律可以跨缺陷类型使用。区别只在于证据形式：登录类缺陷靠录屏和日志，数据导出类缺陷靠导出文件本身。
适用边界：示例不能覆盖的情况
这套示例适用于常规功能缺陷的记录，即用户或测试人员在使用产品功能时发现的、可通过操作步骤复现的异常。它帮助把“现象”整理成“可处理的记录”，但不负责缺陷之外的管理动作。
服务事件的受理与升级属于服务事件与问题管理的范围。当问题表现为线上服务中断、需要按服务级别响应和通知时，记录的重点是影响范围、响应时限和恢复过程，与功能缺陷的字段结构不同。
严重程度分级标准的制定属于缺陷分类与分级主题。本文示例给出了一个具体取值的理由，但一个团队如何划分等级、每级对应什么响应要求，需要单独设计分级体系，不能直接从单个示例推导。
部分缺陷类型需要补充额外信息。涉及安全的缺陷，建议补充影响面判断、复现所需权限和是否已在外部暴露；涉及数据问题的缺陷，建议补充数据范围、时间窗口和是否可回滚；涉及性能的缺陷，建议补充数据量、并发条件和耗时数据。这些补充项不改变八个基本字段的结构，而是在其基础上增加证据维度。
最后需要再次说明：本文所有产品名、版本号、设备型号、账号和操作路径均为演示情景，用于展示填写方式，不代表真实项目数据、实测结果或客户案例。读者在实际填写时，应以自己项目的真实环境和可核验的证据为准。
常见问题
复现步骤写到多细才算够？
判断标准是另一个人能否照着步骤独立复现。起点页面、前置条件（账号、权限、数据）、每一步动作和关键输入值都要写出来，涉及时间窗口或数据量的条件也要注明，比如“30 秒内输入验证码”“筛选结果超过 500 条”。如果开发照着操作后还要回来问“你用的哪个账号”“点的是哪个按钮”，说明步骤还缺信息。
同一个缺陷，严重程度和优先级可以一个高一个低吗？
可以，而且这种情况很常见。严重程度看影响范围与破坏力，比如主路径不可用、影响全部用户；优先级看处理顺序，取决于版本计划、发布节点和资源安排。一个即将下线旧版本上的严重缺陷，严重程度仍是严重，优先级可能降为中；一个对外引导页上的文案错误，严重程度低，优先级可能被临时调高。两个字段分开判断，排期才有依据。
偶发缺陷复现不了，Bug报告还值得提交吗？
值得提交，但要把“偶发”本身作为事实写清楚。记录已观察到的次数与比例、发生时的环境与操作路径、是否有日志或录屏，并在补充说明里标注尚未确认的触发条件。这样接手人知道问题真实存在，也能根据已有线索设计排查方向。把偶发缺陷写成稳定复现，反而会误导排查。
团队已经有缺陷模板，还需要按这套示例逐字段填写吗？
模板决定有哪些字段，示例提供的是每个字段写到什么颗粒度。团队模板字段较少时，优先保证标题、环境、复现步骤、预期与实际结果这几项写完整；模板字段更多时，按模板要求补充，但不必为了填满而堆砌无关信息。示例中的写法规律可以迁移，字段清单以团队实际使用的模板为准。
缺陷提交到工作项系统后，还需要在报告里保留完整信息吗？
需要。缺陷进入系统后会在测试、研发、验收等环节多次流转，每个接手人都可能只看到记录本身。以ONES Project为例，其缺陷管理场景支持一键提交Bug至对应项目或迭代并跟踪修复情况，ONES TestCase中未通过的用例也可快速创建缺陷任务在测试与研发团队间流转，这意味着环境、复现步骤、预期与实际结果等信息最好在提交环节就填写完整，减少后续追问。字段的具体配置以团队实际使用的系统为准。
