1 学习目标&内容

1.1 bug的类型

1.2 bug的等级

1.3 bug的生命周期

1.4 禅道的使用

2 bug的定义

软件的Bug：狭义概念是指软件程序的漏洞或缺陷，广义概念除此之外还包括测试工程师或用户所发现和剔除的软件可改进的细节或与需求文档存在差异的功能实现等。

测试人员的职责：发现这些Bug,并提交给开发人员，让开发去修改。

3  bug的类型

要确定一个bug的类型，需要对项目（或产品）有比较深刻的理解。这个划分对于开发定位问题影响很小，单对于问题类型的统计就比较重要了。

常见的bug类型划分（禅道系统为例，可自定义）

代码（功能）错误

界面优化

设计缺陷

练习一下：bug的类型及等级的判断

1）用户输入正确的用户名和密码不能登录网址

2）客户需求要有重置功能，但是网站没有做

3）网站充值后，出现金额错误

4）在某购物APP上进行商品搜索时，闪退回到手机桌面

5）在某购物APP上进行商品搜索时，手机卡死

6）关闭按钮在弹窗左侧

7）APP某个图标显示太小或者像素失真

8）某个提示语需要改进一下，用户对专业术语不太懂

9）忘记密码，功能没有实现

4 bug的等级

bug的等级，划分一般分为3级或4级，也有分5级的。如果是等级越高，那么可能被修复的等级也会高一些，然后有些公司还会根据提的bug数量和bug等级来考察测试人员的绩效。很多情况下，我们提交bug大致的等级差不多即可，没有严格区分。
如何来判断bug的等级（严重程度），一般可以参照下面的判断条件。

4.1 致命错误：

1）常规操作引起的系统崩溃、死机、死循环、闪退

2）造成数据泄露的安全性问题，比如恶意攻击造成的账户私密信息泄露

3）涉及金钱的计算

4）阻断性测试，所有测试工作进行不下去（冒烟测试）

4.2 严重错误

1）重要功能不能实现

2）错误的波及面广，影响到其他重要功能正常实现

3）非常规操作导致程序崩溃、死机、死循环、闪退

4）外观（界面）难以接受的缺陷：酒店 价格、图片显示不全裂图

5）密码明文显示：（界面+数据库）

6）偶现的致命性bug

4.3 一般错误

不影响产品的运行，不成为故障起因，单对产品外观和下一道工序影响较大的缺陷

1）次要功能不能正常实现

2）操作界面错误（包括数据窗口内列名定义、含义不一致）

3）查询错误，数据错误显示

4）简单的输入限制未放在前端进行控制

5）删除操作未给出提示

6）偶现的严重性bug

4.4 细微错误

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

1）界面不规范

2）辅助说明描述不清楚

3）提示窗口文字未采用行业术语

4）界面存在文字错误：

      改进建议：可以提高产品质量的建议，包括新需求和对需求的改进

5 bug的生命周期（管理流程）

这个是面试/笔试中经常会被问到的问题。bug的生命周期，就是一个bug被发现到这个bug被关闭的过程。你们觉得这个过程有哪些步骤？

生命周期中一般缺陷的状态：新建（提bug）-> 指派 -> 已解决 -> 待验证 -> 关闭

如果待验的bug在验证时没有解决好，我们需要重新打开（激活） -> 指派 ->已解决->待验，循环这个过程。

中间其他状态：拒绝、延期等

我们来看一个bug的处理流程图（生命周期图），让大家更深刻地理解周期中bug的状态及相应处理。

6 bug的跟踪管理流程

7 bug的跟踪管理-如何提交bug

发现bug后，接下来要提交到bug管理平台，提交一个bug包含哪些内容？

bug标题——标题要清晰简洁、写明bug描述：如果没有选择功能模块，最好在标题中标注功能模块。让查看bug的人员清楚知道所表达的意思。bug的功能模块+bug的操作+bug的结果

重现步骤——详细写下发现bug的测试过程。能指导开发重现这个bug。附上测试数据

实际结果——出现bug的结果，粘贴bug截图、日志截图

预期结果——记得写清楚预期

bug类型和严重程度——便于后续测试结果分析，bug的统计

bug测试环境——例如：什么系统，哪个版本等。兼容性问题、难以重现问题

附件——日志文件，文件测试数据。图片、崩溃日志文件等。

另外，参考公司前辈提交的bug，依葫芦画瓢，拓展测试思维。

8 bug的跟踪管理-状态处理

8.1 已经指派的bug——已经指派给开发的，请注意自己的bug走向，随时关注并进行跟踪！如果一直未修复，提醒开发修改，以免开发忘记；如果已经修复等待测试环境更新后进行验证。催着改bug

8.2 已解决bug——等待测试环境更新后进行验证，验证通过则关闭；验证不通过则重新打开指派给开发

8.3 重复bug——先去查看下是否跟开发指定的bug重复？如果确定是重复则关闭；如果不重复，说明原因，重新打开指派给开发

8.4 不是缺陷——再次依据需求确认，是否是bug，如果依然觉得是缺陷跟开发沟通，列举出来觉得是bug的点，沟通未达一致找产品确认，确认是bug注明情况并再次指派给开发，产品确认不是bug,就不纠结，直接关闭bug，但是，会拿小本本把这个bug记录下来，等到测试任务结束后，再来研究。

8.5 无法重现——确认开发环境是否跟测试环境一致？包括测试步骤、浏览器、环境、特定账号、输入数据等，如果多个版本验证之后，如开发所说重现不了，依据bug的严重程度跟产品、开发一起确认关闭，如果找到重现原因，注明清楚并再次指派给开发

8.6 不予解决——找产品经理进行确认。确认不予解决进行关闭，确认需要解决请备注原因并打开指派给开发

8.7 设计如此——找产品经理进行确认。确认设计如此进行关闭，确认是问题，备注原因重新指派给开发

8.8 延期修改——请看下bug严重程度，是否影响当前版本发布？与产品经理进行确认。不予延期请根据情况进行激活与情况说明；确认延期则做好记录，后续版本进行关注 ——不予关闭