测试BUG描述标准规范

对于软件测试来说，发现、提交、跟踪验证bug是软件测试中最基本的工作。然而测试中发现bug后bug描述的清楚与否，可以很好的帮助开发人员快速定位、解决问题，而且还可以提高测试人员基本测试技能。因此，建立标准的bug描述规范是十分重要、也是十分必要的。

首先清晰的bug描述可以帮助开发人员快速定位、解决问题。软件测试部门中员工的水平各有不一，对于bug的认知、描述侧重面也会存在不同。因此，如同一个问题，由不同测试人员描述bug，就有可能会存在描述不一致的问题。这就会造成让开发人员理解不清晰，从而延误解决问题的周期，造成项目的delay问题，无法使我司产品按时上市。

其次标准的bug描述可以提供测试人员的基本测试技能。如我们测试部有新入职员工，他可以先从bug库中查找bug了解我司产品的整个开发、研制中产生的问题。而标准清晰的bug描述可方便快速的使其尽早、尽快的融入我测试部门。另外，对于bug的追踪验证时，由于是不同测试人员进行验证，所以规范的bug描述，可以提高测试人员验证问题的效率。而且对于测试人员来说，每个人的测试思路、方式不同，所以标准的bug描述对于测试部门内部员工的技术沟通也有很好的帮助。

标准的bug描述应有以下三方面组成：

1. Bug发现位置：应说明操作进行的位置，通常是系统中的某一模块。另外是具体的出错位置，可能是某一字段、某一页面；

2. Bug的操作步骤：详细的、有次序的、每一步的操作步骤，包括输入的数据

3. Bug的表象：具体的错误描述，包括界面显示、错误信息；即bug的具体描述，以及期望结果等；

因此，对于我们测试时发现bug描述，应尽量做到以下几点：

1. Bug的描述要声明前提条件：例如bug产生的时间、地点等因素，是产生BUG的静态条件；

2. Bug的描述步骤要按条理、清晰、简单明了：分清1/2/3等条目；

3. Bug的描述中追加bug产生过程中的截图、trace等帮助信息；

4. 尽可能使用“客户系统”自行分辨BUG为终端问题还是平台问题。

5. 严格按照“BUG级别定义”中的规范定义BUG级别。

6. BUGLIST中的备注，产生BUG时一些其他的条件及现象，此条件与现象与BUG无强烈联系，确在产生BUG时发生。用于比BUG主体进行提炼，将多余条件及现象添加至备注，供参考

应有以下两点：

1、基本要求：需要让开发人员能根据描述理解这个bug。

2、最好能让开发人员能明确这个bug在哪可以找到（定位）、需要怎样修复。

3、BUG描述简单明了，条件清晰，步骤分明，重点明确

因此我对bug描述的建议就是：

1. 有条理的把每个小问题列出来，分123，不要怕条目多。

2. 描述问题时一定要把背景交代清楚，即在哪些操作后或者什么环境中会出现，不要忽视那些你看来可能不会引起问题的操作，越细致越好。

3. 善于使用截图和视频录制，这些可以更直观的说明bug的产生过程和结果。

4.再现：尽量三次再现故障。如果问题是间断的，那么最好报告问题发生的概率；例如，每3次出现一次，每3次出现2次等；

5.推广：确定系统其他部分是否可能出现这种错误，以及使用不同的数据是否可能出现这种问题，特别是那些存在严重影响的问题。

6.使用清晰的语言，尤其要避免使用那些有多个不同或相反含义的词汇，使人产生歧义的词汇尽量避免使用。

7.中立：公正地表达自己的意思，对错误及其特征的事实进行描述，避免夸张或忽略的语句，引起过度的注意力或忽视。

8.走察：在你提交测试报告或测试评估报告之前先自己读一遍，最好是另有一个有测试工程师或测试经理走察一遍。

9.凝炼：写完BUG描述后，将按照条件及步骤进行压缩，减少冗余的条件及步骤，多余的条件和步骤，对于研发人员的干扰非常严重，易使其找不到重点及方向。

注：故障描述应该包括十个基本部分：

1. ID:自动生成,CQ系统会自动生成最新的ID编号,提交人无法修改.

2. State:BUG的状态,新提交的BUG为Submitted状态.(如下)

BUG状态描述如下：

New 为测试人员新问题提交所标志的状态。

Open 为开发人员对该是问题准备修改所标志的状态。BUG解决中的状态，由任务分配人改变。

Reopen 为测试人员对修改问题进行验证后没有通过标志的状态，或者已修改正确的问题，又重新出现错误，由测试人员改变。

Fixed 为开发人员修改问题后所标志的状态，修改后还未测试，在新中进行验证。 Closed 为测试人员对修改问题进行验证后通过所标志的状态，由测试人员改变。

Notbug 开发人员认为不是BUG，描述不清，重复，不采纳所提意见建议，或虽然是个错误但还没到非改不可的地步故可忽略不计，或者测试人员提错，从而拒绝的问题。

3. Headline:问题概括,用简短的语句把问题描述清楚。

4. Project：项目名称，在下拉列表中选择对应的项目名称。

5. Severity：严重程度。分为AA，A，B，C。（BUG严重程度参考“BUG级别定义）

6. Priority：修改优先级。

7. Owner：提交者姓名。登录的CQ用户名会默认为提交者。

8. 提交类型：终端BUG 平台BUG 终端平台都需要修改 不能确定。

9. 软件版本号：问题发现对应的终端版本号。

10. Description：见下述标准模板

版本号：QG_EBAO_V1.0_101201_TEST 提交人：霍光明

模块：闹钟设置 概率：100%

IMEI:110020101202010 SIM:13011575831

前提：

测试步骤：

1.IDLE-闹钟设置-提醒方式，设置闹钟提醒方式为铃声或振动（非系统默认的混合），点击保存退出

2.设置闹钟开关为关闭状态

3.重启终端，至闹钟提醒方式界面，观察

实际结果：闹钟关闭状态不能保存更改闹钟提醒方式 预期结果：闹钟关闭状态能保存更改的闹钟提醒方式