今天完成的事情：

今天提交了任务

明天计划的事情：

开始任务三，复习之前的知识点
遇到的问题：

没有
收获：

bug等级

致命（一级bug）

通常表现为:主流程无法跑通，系统无法运行，崩溃或严重资源不足，应用模块无法启动或异常退出，主要功能模块无法使用。

比如：1.内存泄漏；2.严重的数值计算错误；3.系统容易崩溃；4.功能设计与需求严重不符；5.系统无法登陆；6.循坏报错，无法正常退出。

严重（二级bug）

通常表现为：影响系统功能或操作，主要功能存在严重缺陷，但不会影响到系统稳定性。

比如：1. 功能未实现；2.功能存在报错；3.数值轻微的计算错误。

一般（三级bug）

通常表现为：界面、性能缺陷。

比如：1.边界条件下错误；2.容错性不好；3.大数据下容易无响应；4.大数据操作时，没有提供进度条。

4

提示（四级bug）

通常表现为：易用性及建议性问题

比如：1.界面颜色搭配不好；2.文字排列不整齐；3.出现错别字，但是不影响功能；4.界面格式不规范。

bug管理流程

    1. 关键角色及职责

角色

职责

测试工程师

1. 根据规范提交bug；

2. 及时验证bug是否已解决；

3. 及时关注开发拒绝bug，和相关人员沟通讨论解决方式；

测试经理

1. 审核测试工程师提交的bug；

2. 定期review bug，报告现状，并给出解决意见；

开发工程师

1. 以优先级为依据分析解决bug

开发主管

1. 定期 review bug，对bug多的模块加强code review和单元测试；

2. 分析bug解决进度，对产品质量及进度进行风险评估；

产品

1、当开发和测试存在意见分歧时，进行需求确认

2、从产品角度划分bug修改的优先级；

2.   Bug书写规范

 2.1主题

1.  以一个简短的句子描述某个模块存在的问题；或者某个操作导致了什么问题；

2. 描述问题时要简练、直接切入主题，但是要抓住要点；

3.   偶现bug在主题前标注出现的次数；

4.   有些模块功能比较多，可以在主题描述前标注上具体得操作；

示例：

     【偶现3次】【账号切换】登录非本机手机号，切换回本机号码登录后，收不到消息

     【偶现2次】添加载体库时程序停止运行

2.2描述

  说明区域包括：步骤、预计结果、实际结果、测试环境、bug出现时间、截图、日志

1.  用数字编号，一步步的描述问题的重现步骤；

2.   不同的操作步骤产生不同的问题，需分别报bug；尽量做到一个bug汇报一个问题；

3.   偶现问题必须明确bug出现的时间、提供截图以及日志；

3     Bug跟踪类别

bug：测试人员判定为bug的问题；

优化：功能已实现，需要做性能优化的问题；

建议：测试对于产品的一些改进建议；

需求：需要产品重新梳理的需求问题；

4   Bug状态

新建：测试人员新提交的bug、优化或者建议的问题状态；

进行中：开发人员已确认是bug，需要修改的问题状态；

已解决：开发人员已修复的问题状态；

已关闭：测试验证，确定已解决的问题状态；

已拒绝：开发认为不是bug，拒绝给测试的问题状态；

反馈：反馈给产品确认的问题状态；

公认：确认是bug，但是无法解决的问题状态；

打回：测试验证已解决bug，仍然没有修复的问题状态；

5     Bug严重程度

致命：不能执行正常的功能操作，或者因产品原因导致系统死机，需马上修复的问题

示例：

       程序无法启动，或者登录；

       程序崩溃、停止运行，系统死机，无法进行下一步的操作

严重：部分功能存在严重缺陷，尚可继续测试，不影响产品稳定性；

示例：

      偶现的程序崩溃、停止运行

      功能未实现

      数据不同步

      功能错误，无法进行后续操作

一般：次要功能或者界面存在的一些错误，不影响正常测试；

示例：

      界面UI显示和效果图不一致；

      提示语不正确；

      错别字；

      查询结果显示错误

建议：测试对于产品的一些改进建议；

6.   Bug优先级

低：对产品的影响比较小，在时间不允许的情况下可以暂时不修改；

中：必须修改，不一定马上修改，需讨论确定在某个特定的里程碑前修改完；

高：必须在版本发布之前修改完；

紧急：影响测试，需立即或者下一个版本修复；

7.  其他注意事项

1)   开发人员没有关闭bug的权限，所有问题均需经过测试验证无误后才可关闭；

2)   开发、测试双方有争议的bug，必须经过产品的确认才可进行下一步的操作；

3)   测试需及时验证已修复bug；

4)   产品人员可以根据产品的阶段性需求重新分配bug解决的优先级；

5)   重新指派bug后，需要口头或者QQ告知对方；

6)   bug的优先级划分比较重要；

bug生命周期的状态

所有软件开发过程的目的都是为客户（软件产品的终端用户）提供一个解决问题的方案（软件产品），以帮助客户更加高效地工作或生活（从时间和费用上来讲）。一个成功的软件开发过程就是为客户提供了所有他所要求的需求。

　　一个没有软件测试的软件开发过程是不完善的。软件测试是为了寻找并修复软件中的bug/错误，它可以帮助提高软件的质量，以保证用户可以正常使用软件产品。

　　什么是一个bug/错误？

　　软件中的bug或者错误就是所有会影响软件整体或者部分功能的正常运行的软件行为。

　　怎样找到bug/错误？

　　我们主要依靠运行测试脚本或用例来找出那些软件产品中的不想看到的行为。

　　什么是测试用例？

　　测试用例是一类文档，测试用例中包含有用于执行的步骤或行为，而我们需要严格地按照这些步骤来执行以确认软件是否按照我们对它的期望执行。

　　发现bug或者错误后该怎么办？

　　一般在我们发现bug或者错误后，应该和开发人员交流以修复它。

　　从一个bug被发现到这个bug被关闭这一段时间，bug可能会有以下状态：new ，open Postpone，Pending Retest，Retest,Pending Reject,Reject,Deferred,closed.(请注意这里有很多种状态，我们需要根据不同情况来决定怎样或者是否需要跟开发人员沟通)

　　下面就对这几种状态进行以下解释：

　　New:（新的）

　　当某个“bug”被发现的时候（第一次），测试人员需要与项目负责人沟通以确认发现的的确是一个bug，如果被确认是一个bug，就将其记录下来，并将bug的状态设为New

　　Assigned（已指派的）

　　当一个bug被指认为New之后，将其将给开发人员，开发人员将确认这是否是一个bug，如果是，开发组的负责人就将这个bug指定给某位开发人员处理，并将bug的状态设定为“Assigned”

　　Open（打开的）

　　一旦开发人员开始处理bug的时候，他（她）就将这个bug的状态设置为“Open”，这表示开发人员正在处理这个“bug”

　　Fixed（已修复的）

　　当开发人员进行处理（并认为已经解决）之后，他（她）就可以将这个bug的状态设置为“Fixed”并将其提交给开发组的负责人，然后开发组的负责人将这个bug返还给测试组

　　Pending Reset（待在测试的）

　　当bug被返还到测试组后，我们将bug的状态设置为“Pending Reset”

　　Reset（再测试）

　　测试组的负责人将bug指定给某位测试人员进行再测试，并将bug的状态设置为“Reset”

　　Closed（已关闭的）

　　如果测试人员经过再次测试之后确认bug已经被解决之后，就将bug的状态设置为“Closed”

　　Reopen（再次打开的）

　　如果经过再次测试发现bug（指bug本身而不是包括因修复而引发的新bug）仍然存在的话，测试人员将bug再次传递给开发组，并将bug的状态设置为“Reopen”

　　Pending Reject（拒绝中）

　　如果测试人员传递到开发组的bug被开发人员认为是正常行为而不是bug时，这种情况下开发人员可以拒绝，并将bug的状态设置为“Pending Reject”

　　Rejected（被拒绝的）

　　测试组的负责人接到上述bug的时候，如果他（她）发现这是产品说明书中定义的正常行为或者经过与开发人员的讨论之后认为这并不能算作bug的时候，开发组负责人就将这个bug的状态设置为“Rejected”

　　Postponed（延期）

　　有些时候，对于一些特殊的bug的测试需要搁置一段时间，事实上有很多原因可能导致这种情况的发生，比如无效的测试数据，一些特殊的无效的功能等等，在这种情况下，bug的状态就被设置为“Postponed”

　　Deferred（延期的）

　　有些情况一些特殊的bug显得不那么重要，同时也是可以消除的，这个时候我们可以将bug的状态设置为“Deferred”