提交缺陷指引说明

写在前面：如何确定发现了一个缺陷？

1. 被测结果明显与需求描述不一致。

2. 测试用例描述需求中虽未言明，但是明显不合理。

3. 功能正常，但是实现方式可能会造成资源浪费，或不良好的体验。

4. 即便只在单个帐号或设备出现的问题，也应当缺陷处理。

在提单前，需要排除：

1. 帐号和设备是否有其它测试环境干扰；

2. 执行的测试用例是否是更新到最新的。

 

一、地址&权限

提单地址：http://tapd.oa.com/Project_CAT/bugtrace/bugreports/my_view

权限开通：alvinshen

注意！能打开上述地址并可点击“创建缺陷”，则代表已经有权限了~

 

二、提单规范

 

 

 

 

1. 标题描述格式：

【关键字】标题描述。

1. 模块名命名规范：

测试阶段	关键字命名规范
新功能测试阶段	要求： 简洁，具有标志性，能快速通过改标志筛选缺陷。 每个新功能需求，所有权限单关键字唯一。 正确实例： 用测试的范围命名，如【登录】、【直播间】 用功能点命名，如【弹幕优化】、【兑换宝石】 用活动名命名，如【2019盛典活动】
系统测试阶段	用测试的范围命名，如【登录】、【直播间】、【弹幕】

 

2. 标题描述规范：

• 言简意赅：不做大量操作过程描述，操作过程去内容中描述。

• 突出重点：什么出现了问题？出现了什么问题？问题情况怎样？

例如：

【登录】登录按钮必现无法点击

【直播间】点击全屏按钮必现crash

【关注】主播帐号首次进入关注页，未提示登录。

存在二义性的描述：

【注册】username可以设置字符超过25个，与需求描述不符。---到底能不能超过25个？

可改为：【注册】username设置字符超过25个，未提示报错。

 

2. 内容描述格式：

1. 设备信息：

只有在单个设备或浏览器上出现的问题，才备注设备或浏览器信息。

测试设备	填写信息
单个移动端出现	例如： 移动设备名称： 华为 nova 3e                        移动设备操作系统版本：android 9.1.0
单个浏览器出现	例如： 浏览器名称：  edge                                       浏览器版本： 44.18362.449.0

 

2. 操作步骤：

• 操作步骤需提供：能够复现该问题的完整步骤，或者提供准确的场景信息，以及错误的准确描述。

• 描述步骤不冗余，尽量使用专业术语。

• 如果有录屏或日志，请在步骤中提示开发“查阅附件”。

 

3. 截图或链接：

• 所有bug必须配错误截图链接，并在截图中，明确指出错误位置。（除无法截图的场景外）

• 描述步骤不冗余，尽量使用专业术语。

• 如果有录屏或日志，请在步骤中提示开发“查阅附件”。

4. 期望结果：

• 已有的需求描述，或者建议修改成的结果。

• 注意：在不清楚预期的时候，一定要跟产品人员商量，测试不随便提需求！！

• 可以贴产品在群中发的消息，作为证据。

 

3. 信息字段描述填写格式：

 

字段	内容介绍
关联需求	新功能测试bug一定要关联需求！ 系统测试或其他工具途径提单，可不关联需求。
发现版本	新功能测试选择与需求单对应的版本。 系统测试或其他工具途径提单，选择迭代发布的版本号。
重现规律	必现：一定出现。单个帐号和设备一定出现，也是必现！！ 大概率出现：10次只有1~2次不出现。 偶现：10次只出现1~2次。
优先级	紧急： 发布前2天发现严重程度中及以上的问题； 提测后开发不及时解决，就无法测试的bug。 后台服务器挂了，现网不能使用。 高: 严重问题。 一般问题但是发布前确定必改的。 中： 不严重的问题。 发布前确认可不改的bug 低： 产品暂时未提出合理解决方案的体验问题，且不影响现网使用。
严重程度	致命：导致设备卡死、死机、crash，完全不可测的情况。 严重：主要功能逻辑，P0/P1级用例不通过。 一般：一般功能逻辑，UI异常，兼容性，数据上报等不通过。 提示：提示不友好，文字问题等体验类问题。 建议：需求未言明的体验问题，不影响产品需求决策。
软件平台	web端:web前端出现的bug 移动端：任何移动端app或其内的H5都出现 iOS端：只有iOS端的bug Android端：只有Android端出现 不区分平台：比如后台数据等
模块	模块和特性选择正确即可。 如果没有对应的模块和特性，联系alivnshen添加，不要乱选。
特性
测试阶段	新功能测试：所有阶段间发现的新功能问题，都提新功能。 合入验证：只要开发合入出错，在主流验证时发现问题才提。 系统测试：系统测试期间测试非新功能发现的问题。 老版本移入：只是测试负责人版本发布后处理
测试类型	手工测试:测试人员手工发现的问题。 自动化测试：通过自动化测试发现的问题。 freetest：不存在用例，随机使用时发现的问题！（要补充用例） 用户反馈：发布后发现的问题，不需要替换包解决！ 线上缺陷：发布后发现的问题，需要替换包解决！ 工具提单：通过codedog、monkey等工具执行发现的问题
缺陷类型	UI问题：界面UI异常的问题。 功能逻辑：功能逻辑异常。 性能问题：性能指标超标、慢、卡顿、黑屏等 体验问题：体验问题 后台问题：后台问题
开发人员	明确知道谁来解决的，直接提给对应的开发！ 没有明确开发人员的情况，提给接口人！
处理人
测试人员	填写测试自己

 

三、提单要求

1. 发现问题，第一时间提单。

2. 有严重影响体验和测试的问题，第一时间群里通知。

3. 测试验证状态的缺陷，及时验证关单！