聊聊提交缺陷需要注意哪些事项

作为测试工程师，提交缺陷（Bug）是核心工作之一。一份清晰、准确、完整的缺陷报告能极大提高开发修复效率，减少沟通成本，促进项目进度。从一份缺陷提交记录中，可以准确地判定测试从业者的熟练程度，对系统的了解程度等。在进行提交缺陷的过程中，有些地方需要简要描述，有些地方需要体现出它的操作步骤，还有的地方需要体现缺陷的截图，交互日志信息（含有问题的日志较为重要），缺陷的等级，指派给对应的开发人员或项目开发负责人让其分配等等，总之要体现出缺陷描述清晰、准确、完整、可复现、客观。

一、缺陷标题

简洁精准： 用一句话概括缺陷的核心现象（“是什么”）及其影响（“导致什么后果”），避免模糊不清。

信息丰富： 包含关键元素，如：模块/功能名称 + 具体现象 + 严重程度提示。

避免： 过于笼统（如：“功能有问题”）、主观判断（如：“这个设计太烂了”）、不包含具体功能点。

好例子： “【购物车】商品数量修改为0并点击更新后，商品未被移除且订单总价计算错误”

差例子： “购物车功能异常” 或 “更新数量有问题”

二、缺陷描述

清晰陈述问题： 详细描述你观察到的现象，与预期结果的偏差。使用明确的语言。

客观中立： 只描述事实，避免情绪化语言、指责或主观猜测原因（除非有明确证据）。

聚焦用户视角： 说明这个缺陷对用户的实际影响是什么（影响用户体验、数据丢失、功能不可用等）。

三、复现步骤 （这是最重要的一点！）

精确详细： 提供一步步的操作指南，让开发人员（或其他测试人员）能够100%复现该缺陷。像教一个新手操作一样写。

顺序清晰： 步骤编号，逻辑清晰，不要跳跃。

输入数据具体： 指明使用的测试数据（用户名、商品ID、特定文件、输入值等）。如果数据敏感，用占位符但说明其特性（如“使用超长字符串（>1000字符）”）。

前置条件： 明确复现前必须满足的条件（如：特定用户角色、特定配置、需要先完成某个操作、特定环境状态等）。

避免歧义： 使用明确的界面元素名称或标识符（按钮文本、字段ID等）。

最小化步骤： 尽量提供最简化的复现路径，剔除无关步骤。

四、预期结果

清晰定义： 根据需求、设计文档或用户合理期望，明确指出在正确执行复现步骤后，系统应该发生什么。

可衡量： 结果应该是具体的、可观察的（如：“应显示成功提示消息‘保存成功’”、“订单总价应更新为$XX.XX”、“用户应被重定向到个人主页”）。

四、实际结果

准确描述： 明确指出在执行复现步骤后，系统实际发生了什么。这必须与预期结果形成鲜明对比。

包含错误信息： 如果系统显示了错误提示、日志、崩溃信息等，必须完整、一字不差地记录下来。

描述异常现象： 如界面错乱、数据未更新、功能无响应、性能缓慢、崩溃退出等。

五、环境信息 

明确具体： 缺陷是在什么环境下发现的？必须包含：

操作系统及版本： Windows 11 22H2, macOS Ventura 13.4, Android 14, iOS 17.1

浏览器及版本（Web）： Chrome 118.0.5993.88, Firefox 118.0.2, Safari 16.6

设备信息（移动端/硬件相关）： iPhone 15 Pro, Samsung Galaxy S23, 特定型号的打印机/扫描仪

应用/软件版本： 被测应用的精确版本号或构建号 (e.g., App v2.1.3, Build #20231025.1)

网络环境： Wi-Fi, 4G/5G, 特定代理设置

特定配置： 语言/区域设置、分辨率、是否开启无障碍模式、特定的功能开关状态等。

原因： 很多缺陷是环境依赖的。

六、附件一图/一视频胜千言

截图（Screenshots）：

清晰展示问题现象（如界面错误、错误提示框）。

标注关键问题点（使用箭头、方框、高亮）。

包含必要的上下文信息（如整个界面、URL）。

屏幕录像（Screen Recordings）： 对于动态问题、复杂交互或偶现问题，录屏是最佳证据。保持录像简短聚焦。

日志文件（Logs）： 如果可能且允许，附上应用程序日志、服务器日志、浏览器控制台日志（F12 Console/Network标签页的错误信息）。注意脱敏。

测试数据文件： 如果问题与特定输入文件相关，附上该文件（注意安全性和脱敏）。

命名清晰： 给附件起有意义的名字（如“错误弹窗截图.png”、“复现视频.mp4”、“console_errors.log”）。

七、严重程度和优先级

严重程度： 客观评估缺陷对系统功能、用户、数据或业务的影响程度（如：崩溃（Blocker）、主要功能失效（Critical）、次要功能失效（Major）、轻微问题（Minor）、界面优化（Trivial））。

优先级： 结合项目进度和资源，评估修复该缺陷的紧急程度（如：立即修复（High）、尽快修复（Medium）、下一版本修复（Low）、不修复（Deferred））。通常由测试经理或项目经理设定，但测试工程师需提供初步建议和依据（基于严重程度和影响范围）。

注意： 严重程度高不一定优先级高（例如一个非常严重的崩溃但只在极其罕见的配置下发生），反之亦然（例如一个低严重性的拼写错误出现在首页关键按钮上，优先级可能很高）。清楚说明你判断的依据。

八、针对偶现缺陷

尽最大努力记录所有可能的线索（操作、环境、时间点、日志片段）。

在描述中明确说明是“偶现”。

分析是否有规律可循（特定操作序列后？特定数据？特定负载下？）。

尝试增加复现步骤中的操作次数或范围。

强调其对用户或系统稳定性的潜在风险。

九、其他注意事项

避免重复： 提交前，务必在缺陷管理系统中搜索是否已有类似缺陷报告。如果是重复缺陷，应在原缺陷上补充信息（如新的复现步骤、环境）或投票/关联，而不是新建。

主观描述:❌ 错误：“这个功能太难用了！”✅ 正确：“搜索功能输入关键词后无结果返回，但数据库存在匹配数据。”

步骤遗漏或模糊：避免使用“然后”“接着”等模糊词汇，确保步骤可完全复现。

报告及时性： 发现缺陷后尽快提交，避免遗忘细节或环境发生变化。

清晰分类： 正确选择缺陷所属的模块/组件/功能区域。

明确责任人（Assignee）： 如果清楚应该由哪个开发人员或团队负责，可以指定（遵循团队规范）；否则通常由测试负责人或项目经理分配。

使用标准模板： 遵循团队或公司定义的缺陷报告模板，确保信息完整性和一致性。

沟通与跟进： 提交缺陷不是终点。积极与开发人员沟通，提供更多信息，协助复现，验证修复，及时更新缺陷状态（如：Reopen 如果修复不彻底）。

提交缺陷时，要时刻想着：“我要让一个从未见过这个问题的开发人员，仅凭我提供的信息，就能快速、准确地复现问题，并理解它的严重性和影响。”