为了让开发及相关人员查看 Bug 记录时有一个高效、赏心悦目的感受，现制订以下书写规范，望遵守践行。
1.项目
• 原则上是发现者提测至本人所在的组
• 如果遇到一个Bug 不是本组的开发范畴，可以告之相关组的测试人员
2.问题类型
• 针对 Bug，统一选择『缺陷』，前面有一个 虫子图标
3.概要 ::格式：【功能模块】【客户端】页面字体显示与设计不符
• 第一个【】填写 此问题所在的功能模块信息
• 第二个【】填写 此问题所在的客户端（iOS/Android/Web 前端/Web 后台）
• 问题描述要简洁概要，见字明意（一般控制在__15__个汉字以内）
4.报告人
• 谁提交的就填写谁
• 无特殊情况，Bug 的报告人负责 Bug 修复的验证事宜
• 报告人，尽量上传一张本人的近期头像，方便别人一看头像就知道是谁（这一点很适合新来的员工快速认识人）
• 报告人的名字请填写中文全名，不要以拼音或简称代替
5.描述 :: 一般包含五项内容：【前置条件】【重现步骤】【实际结果】【期望结果】【复现率】，以颜色、【】进行标识，换行对齐::
• __【前置条件】__
▪ 如果 Bug 是在特定的环境、机器上发现的，请明确标识
▪ 前置条件，应该放置在描述的最顶端进行书写
▪ 书写内容与标题相比，缩进一个 Tab 键间隔
• __【重现步骤】__
▪ 以项目编号标识，进行分步骤书写（不可所有步骤书写在一起）
▪ 步骤应该简洁，一个操作一个步骤，每一个步骤占一行并以项目编号开始，上下保持对齐
▪ 不易表述的操作，要录屏，以mp4格式上传附件，操作步骤间的时间间隔不能太长也不能太短（录屏时间1分钟至10分钟之间较好）
▪ 书写内容与标题相比，缩进一个 Tab 键间隔
• __【实际结果】__
▪ Bug出现时的具体现象，避免模糊词汇，直接描述实际现象
▪ 这个描述应该遵循『眼见为实』，不可描述自己想象到的
▪ 书写内容与标题相比，缩进一个 Tab 键间隔
• __【期望结果】__
▪ 以需求、用户体验为前提进行期望，做到有理有据
▪ 有好的改善意见，可以谦逊的提出来，最好不要语气强硬
▪ 书写内容与标题相比，缩进一个 Tab 键间隔
• __【复现率】__
▪ 如果 Bug并不能百分百复现，这时要给出复现的频率
▪ 复现率的写法采用分子/分母的形式，不可约分（例如 6/8 ,代表测试8次，出现了6次）
▪ 书写内容与标题相比，缩进一个 Tab 键间隔
*注，当一个问题需要他人（例如 PO/UI）进行确认、协助时，要使用『提及用户』的功能，@到专人
066B1692-9A07-482C-9A99-D6DF4F8CAD17.png
6.优先级
• 要根据问题进行实际选择，不可使用默认值
• 此级别站在测试员角度所得出的优先级，不是开发人员眼中的优先级
7.标签
• 如果有，就选填一下
8.附件 :: 多数情况下是图片、视频、日志::
• 移动端，选用手机截图功能保存图片，非拍照（截图可以保证工整标准平面化视觉的）
• 优先选用 jpg/jpeg 格式，这种格式保存的质量是显著小的
• 如果是透明的，要使用 png 格式
• 对于问题点，画框、箭头、文字说明进行显著标注
• 图片内容清晰可见
• 图片质量不超过1MB，开发人员打开图片，即可呈现（避免加载费时）
• 图片的名称要见名知意，不可随意（这张图片是反映什么的，要填写一下图片的名称）
• 多个附图时，图片要根据步骤先后，有序显示
• 如果是 UI设计稿对比实际图，要将其拼接成一张图片进行上传
9.问题
• 选择此 Bug 所属于的故事
10.经办人
• 一般情况下，填写此 Bug 的开发者
• 如果是需求、UI方面的问题，可以指给相关人员（这些人有可能不常看 Jira，要做好线下通知）
11.Epic Link
• 填写拆分故事时的 Feature
12.Sprint
• 填写当前的迭代
• 如果是集成测试的 Bug，届时填写到集成测试的项目迭代
书写参照.jpg
jira.jpg
