Bug编写规范

Bug编写规范

Bug的概述（什么是bug？）

软件缺陷 ：通常又被叫做Defect或者bug，即为软件或程序中存在的某种破坏正常运行能力的问题、错误，其存在会导致软件产品无法使用。

注：1、从产品内部来看，缺陷是软件产品开发或维护过程中存在的错误、异常等各种问题。
	2、从产品外部看，缺陷是系统所需要实现的某种技能功能的失效或者是违背用户的需求
	3、软件中任何不满足客户需求的问题都可以是缺陷

为什么会产生bug？

程序设计错误、工期短，任务大、需求不断变更、文档不完善，沟通交流不够、软件的复杂、软件硬件支持的不完善

bug的特征

1、软件未实现需求说明书要求的功能
2、软件出现了需求说明书指明不该出现的错误
3、软件功能超出需求说明书指明的范围
4、软件未实现需求说明书未明确提及但应该实现的目标
5、软件测试人员认为软件难以理解、不易使用、运行速度慢、或者最终用户认为不好

总结：不满足用户确定的需求都是缺陷

如何判断一个bug？

1、通过技术文档来识别缺陷

需求规格说明书
设计和分析文档
用户指南、帮助手册

2、根据行业标准规范和参考同类型软件来识别缺陷
3、与客户和相关人员沟通来识别

不要只凭借自己的主观臆断去判定缺陷

bug的分布

根据统计：需求阶段的缺陷分布最多

需求60%、设计20%编码15%、其他5%

bug的修复成本

交付阶段的缺陷修复成本最高
需求阶段的缺陷修复成本最低

bug的组成

缺陷编号——》测试管理系统自动生成
缺陷标题——》用简短精确的话语来描述你的bug
缺陷类型——》代码错误、设计缺陷、界面优化…
缺陷等级——》致命性、严重性、一般性、建议性（高中低或1、2、3、4）
缺陷的优先级别——》立即修改、高优先级、正常排队、不紧急
缺陷状态——》新提交的bug一般为新建或打开状态（new/open）
缺陷所属模块——》细分功能模块
发现缺陷的版本——》当前的版本号
缺陷复现的步骤——》操作步骤、预期结果、实际结果
缺陷的发现者、日期——》系统自动生成
备注信息——》截图、视频、log等信息

缺陷类型

对bug的划分，以禅道为例，包括：
1、代码错误
2、设计缺陷
3、界面优化
4、性能问题
5、配置相关
6、安装部署
7、安全相关
8、标准规范
9、测试脚本
10、其他划分：功能类、界面类、性能类、易用性类、兼容性类、其他

缺陷等级

一级bug：致命性错误

1》常规操作引起的系统崩溃、司机、死循环
2》造成数据泄露的安全性问题，如：恶意攻击造成的账户私密信息泄露
3》涉及金钱，如支付软件、金钱计算错误

二级bug：严重错误

1》重要性功能无法实现
2》错误的缺陷涉及面较广，影响到其他重要功能的正常实现
3》非常规操作导致的程序崩溃、司机、死循环（非常规操作指的是用户使用软件时不会进行的操作）
4》外观难以接受的缺陷（如软件封面图失真、变形）
5》密码明文显示

三级bug：一般错误

不影响产品的运行、不会成为故障的起因、但对产品的外观和下道工序有较大影响的缺陷

1》次要功能不能正常实现
2》操作界面错误（如数据窗口内侧的定义与含义不一致，也就是UL和LI的内容不匹配）
3》查询错误，数据错误显示
4》简单的输入限制未放在前端进行控制（各市显示，如登录注册的格式判断可以放在前端进行判断）
5》删除操作未给出提示

四级bug：建议性修改

程序在一些显示上不美观，不符合用户习惯，或者是一些文字的错误

1》界面不规范
2》辅助说明描述不清楚
3》提示窗口文字采用的行业术语
4》界面存在文字错误
5》改进意见（可以提高产品质量的建议，包括新需求和对需求的改进）

缺陷的优先级

立即解决：缺陷必须被立即解决
高优先级：缺陷严重需要优先考虑
正常排队：缺陷需要正常排队等待修复或者列入软件发布清单
不紧急：缺陷可以在方便时去修正

注：缺陷的严重程度与缺陷的优先级成正比关系

缺陷状态

1、激活或打开（New or Open or Active）

新建的bug，等待处理的状态

2、已修复（Fix or Resolved）

开发工程师对缺陷进行修复，需要测试工程师来进行确认

3、以后解决（Later）

缺陷将在以后发布的版本中来解决，当前版本暂不修复

4、重新打开（Reopen）

测试验证后依然存在的bug，等待开发进一步修复

5、关闭（Close）

测试验证问题已经修复成功，就将bugguanbi

6、不修复（wontifix）

报告中描述的缺陷确实存在，但是由于各种原因并不进行修复

7、不是问题（NAB）

报告中描述的缺陷经过确认不存在或者是不是缺陷

8、已重复（Duplicate）

提交的缺陷已经存在，重复缺陷

9、需要更多信息（WorkSforme）

根据报告的描述无法重现的缺陷，需要测试提供更多的信息

如何记录bug？

1、保证缺陷可以重现

判断一个缺陷报告写的好与坏的简单方法就是，让其他技术人员依据报告内容去操作。若能够简单、迅速的重现缺
陷，就是好的缺陷报告。

2、将重现缺陷的操作步骤组织成列表的形式

列表是最便于阅读和执行的组织形式

3、写清楚必要步骤，既不要太啰嗦，也不要太简略

假定阅读缺陷报告的人不熟悉软件

4、每一份报告只描述一个缺陷

一份报告描述多个缺陷，容易造成缺陷遗漏

5、客观、准确、便于阅读和理解

陈述事实，不要做主观臆断

怎样的bug可以报告？（什么样的缺陷可以报告？）

1、可以再现的缺陷，即存在一系列明确的操作步骤、条件和数据似的缺陷，可以稳定的反复出现，一定要报告
2、不可再现的缺陷，即找不到明确的步骤、条件和数据可以让缺陷反复出现，缺陷的出现看起来是随机和不确定的，这种缺陷要慎重处理。

注：不可再现的缺陷如何处理？
    1、记录下来但不要报告，在后续的测试中要特别留意，找到其可能出现的稳定路径
    2、转化为可在现的缺陷时，在报告
    3、千万不要忽视不可再现的缺陷