bug组成

• 缺陷编号-测试管理系统自动生成
• 缺陷标题->用简短精确的话语来描述你的bug
• 缺陷类型--代码错误(功能--预期结果--Bug/未做功能---bG)/设计缺陷(需求不全面,考虑的场景遗漏)/界面优化(U-—致,去检查ui)
• 缺陷等级-->致命(系统瘫痪、环境出错、无法进入下一步测试)/严重（某一功能没有完成）/一般（提示信息有误、页面跳转出错）/建议(易用性、友好性）
• 缺陷优先级别->立即修改/高优先级/正常排队/不紧急(1/2/3/4)
• 缺陷状态->新提交的bug般为新建或激活状态new/open
• 缺陷所属的模块->细分功能模块(每个开发负责的模块不一样-开发模块)
• 发现缺陷的版本-->当前版本号(V0.0.1V0.0.2)
• 缺陷复现的步骤->操作步骤、预期结果、实际结果
• 缺陷的发现者、日期系统自动生成
• 备注信息->截图、视频、log等信息

bug判断的依据

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

• 需求规格说明书-产品
• 设计和分析文档-开发、产品
• 用户指南、帮助手册产品

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

总之:不要只凭自己的主观臆断去判定缺陷!

bug的特征

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

怎么规范记录Bug?

1.保证缺陷可以重现

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

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

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

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

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

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

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

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

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

禅道上bug跟踪处理

1.激活或打开:( New or Open or Active ) : 新建的bug ,等待处理状态

2.已修复(Fix or Resolved ):开发工程师对缺陷进行了修复,需要测试工程师进行确认3.以后解决(Later ):缺陷将在以后发布的版本中解决,当前版本暂不修复

4.重新打开(Reopen ):测试验证后依然还存在的缺陷,等待开发进一步修复

5.关闭(Close ):测试验证问题已经修复成功,就把bug关闭

6.不修复(Wontfix ):报告中描述的缺陷确实存在,但是由于各种原因并不进行修复7.不是问题(NAB):报告中描述的缺陷经过确认不存在或不是缺陷

7.不是问题(NBA):报告中描述的缺陷经确认不存在或者不是bug

8.已重复(Duplicate ):提交的缺陷已经存在,重复缺陷

9.需要更多信息(Worksforme ):根据报告的描述无法重现的缺陷,需要测试提供更多的信息