缺陷 告描述的正确姿势

好的 告不是大量信息的堆叠，而是高效的方式提供准确有用的信息

缺陷标题

1. “在什么情况下发生了什么”格式
2. 尽可能描述其本质，而不是现象。
   eg：“商品金额能输入英文字母和其他字符”。“商品金额可输入内容未作校验”
3. 标题不易过长，详细的描述放在”缺陷概述”里

缺陷概述

1. 概括性的缺陷本质与现象的描述，是标题细化。
2. 要清晰、简短的描述清楚
3. 问题延展：上版本有没有发生

缺陷影响

1. 对用户或业务影响范围和严重程度
2. 要对软件应用场景和需求有深入的理解

环境配置

1. 系统版本、软件版本、浏览器版本、配置信息、参数、中间件版本信息等
2. 按需描述
   eg：“菜单栏上某个条目缺失的问题”只会发生在Chrome浏览器，而其他浏览器都没有类似问题。那 么，Chrome浏览器就是环境敏感信息，必须予以描述，而至于Chrome浏览器是运行在什么操作系统 上就无关紧要了，无需特意去描述了。

前置条件

测试步骤前应该处在的状态
eg：业务需要先登录，描述直接使用前置条件”用户已完成登录”

复现路径

1. 以用户角度出发，每个步骤可操作且连贯
2. 先自测复现3次以上，保证可复现、然后找到最短路径
3. 要避免的注意事项

• 笼统的描述
• 出现与复现不相关的步骤
• 缺乏对测试数据的描述

期望结果&&实际结果

期望结果：应该发生什么是什么不应该发生
实际结果：发生了什么是什么没有发生

优先级&&严重程度

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

1. 缺陷越严重，优先级越高
2. 缺陷影响范围越大，优先级越高
3. 从用户角度不严重，但是妨碍测试工作。严重程度低，优先级高
4. 虽然有的缺陷严重程度高，但是考虑修复成本和技术难度，优先级可能较低

变通方案

• 临时绕开缺陷而不影产品功能的方式
• 如果没有任何变通方案，不管修复代价多大，也要优先级最高

根原因分析RCA

定位bug产生原因。要有代码阅读和debug能力

附件

截图、日志、录屏等