软件测试笔记-如何高效填写软件缺陷报告

• 缺陷报告是测试工程师与开发工程师交流沟通的重要桥梁，也是测试工程师日常工作的重要输出。
• 缺陷报告本身的质量将直接关系到缺陷被修复的速度以及开发工程师的效率，同时还会影响测试工程师的信用、测试与开发人员协作的有效性
• 好的缺陷报告不是大量信息的堆叠，而是以高效的方式提供准确有用的信息

一、缺陷标题

概括性描述，“在什么情况下发生了什么问题”

• 对“什么问题”简洁，具体，不能笼统
  反例：用户不能正常登陆 搜素功能有问题 （说了等于没说，可能被拒绝，管理困难，过程低效）
• 描述问题本质
  反例：商品金额输入框，可以输入英文字母和其他字符
  榜样：商品金额输入框，没有对输入内容做校验
• 标题不易过长

二、缺陷概述

缺陷概述通常会提供更多概括性的缺陷本质与现象的描述

• 清晰简短的语句描述本质
• 延展部分（比如可能出现的所有场景，是否会在之前版本遇到？避免以缺陷重现步骤形式描述，应该使用概括性语句）

三、缺陷影响

缺陷引起的问题对用户或者对业务的影响范围以及严重程度

• 缺陷影响决定缺陷的优先级和严重程度，开发经理以此为依据决定修改该缺陷的优先级，产品经理来决定严重程度，并决定是否要等该缺陷被修复后才能发布产品
• 前提是对软件的应用场景和需求的深入理解

四、环境配置

详细描述测试环境的配置信息，为缺陷的重现提供必要的环境信息（操作系统的版本、被测软件版本、浏览器种类和版本、被测软件的配置信息
集群的配置参数、中间件的版本信息等等）

• 按需描述，只描述重现缺陷的环境敏感信息
  例子： 条目缺失只在Chrome浏览器发生，Chrome浏览器就是环境敏感信息，必须描述，操作系统不重要

五、前置条件

测试步骤开始前的系统状态，较少重现步骤的描述，排除不必要的干扰，使其更有针对性

六、缺陷重现步骤

整个缺陷报告中最核心的内容，目的在于用简洁的语言向开发工程师展示缺陷重现的具体操作步骤

• 从用户角度出发，每个步骤都是可操作并是连贯的，往往采用步骤列表的形式
• 写之前，反复执行3次以上（确保可重现，找最短的重现路径，过滤非必要步骤，避免不必要的干扰）
  避免

1. 笼统，缺乏可操作的具体步骤
2. 出现于缺陷重现不相关的步骤
3. 缺乏对测试数据的相关描述

七、期望结果和实际结果

• 期望结果：应该发生什么
• 实际结果：发生了什么

八、优先级和严重程度

缺陷的优先级指缺陷必须被修复的紧急程度，而缺陷严重程度是指因缺陷引起的故障对软件产品的影响程度

• 严重程度是缺陷本身的属性，通常确定后不再变化
• 优先级是缺陷的工程属性 随着项目进度、解决缺陷的成本等因素而变动

1. 缺陷越严重，优先级越高
2. 缺陷影响的范围越大，优先级也会越高
3. 有的用户角度不严重，妨碍测试或者自动化测试的执行（严重程度低，优先级高）
4. 严重程度高，修复成本技术难度也高，优先级可能会低

九、变通方案

• 提供一种临时绕开当时缺陷不影响产品功能的方式，测试工程师或者开发工程师共同决定或完成
• 变通方案的有无以及实施的难易程度，决定缺陷优先级和严重程度的重要依据

十、根原因分析（Root Cause Analysis）

• 最好能定位问题的根原因，清楚描述之，开发效率上去了，影响力也上去啦

十一、附件（Attachment）

• 证据支持，常见有界面截图、测试用例日志、服务器端日志、GUI测试的执行视频等
• 截图加高亮，有图有真相