1、 缺陷跟踪管理的目标
缺陷能够引起软件运行时产生的一种不希望或不可接受的外部行为结果,软件测试过程简单说就是围绕缺陷进行的,对缺陷的跟踪管理一般而言需要达到以下的目标:
确保每个被发现的缺陷都能够被解决;这里解决的意思不一定是被修正,也可能是其他处理方式(例如,在下一个版本中修正或是不修正),总之,对每个被发现的BUG的处理方式必须能够在开发组织中达到一致;
收集缺陷数据并根据缺陷趋势曲线识别测试过程的阶段;决定测试过程是否结束有很多种方式,通过缺陷趋势曲线来确定测试过程是否结束是常用并且较为有效的一种方式。
收集缺陷数据并在其上进行数据分析,作为组织的过程财富。
上述的第一条是最受到重视的一点,在谈到缺陷跟踪管理时,一般人都会马上想到这一条,然而对第二和第三条目标却很容易忽视。其实,在一个运行良好的组织中,缺陷数据的收集和分析是很重要的,从缺陷数据中可以得到很多与软件质量相关的数据。
2、 缺陷的描述
对缺陷的描述应该包含以下的内容:
可追踪信息 |
缺陷ID |
唯一的缺陷ID,可以根据该ID追踪缺陷 |
缺陷基本信息 |
缺陷状态 |
缺陷的状态,分为“待分配”、“待修正”、“待验证”、“待评审”、“关闭” |
缺陷标题 |
描述缺陷的标题 | |
缺陷的严重程度 |
描述缺陷的严重程度,一般分为“致命”、“严重”、“一般”、“建议”四种 | |
缺陷的紧急程度 |
描述缺陷的紧急程度,从1-4,1是优先级最高的等级,4是优先级最低的等级 | |
缺陷提交人 |
缺陷提交人的名字(邮件地址) | |
缺陷提交时间 |
缺陷提交的时间 | |
缺陷所属项目/模块 |
缺陷所属的项目和模块,最好能较精确的定位至模块 | |
缺陷指定解决人 |
缺陷指定的解决人,在缺陷“提交”状态为空,在缺陷“分发”状态下由项目经理指定相关开发人员修改 | |
缺陷指定解决时间 |
项目经理指定的开发人员修改此缺陷的deadline | |
缺陷处理人 |
最终处理缺陷的处理人 | |
缺陷处理结果描述 |
对处理结果的描述,如果对代码进行了修改,要求在此处体现出修改 | |
缺陷处理时间 |
缺陷处理的时间 | |
缺陷验证人 |
对被处理缺陷验证的验证人 | |
缺陷验证结果描述 |
对验证结果的描述(通过、不通过) | |
缺陷验证时间 |
对缺陷验证 |
缺陷的详细描述 |
对缺陷的详细描述;之所以把这项单独列出来,是因为对缺陷描述的详细程度直接影响开发人员对缺陷的修改,描述应该尽可能详细 | |
测试环境说明 |
对测试环境的描述 | |
必要的附件 |
对于某些文字很难表达清楚的缺陷,使用图片等附件是必要的 |
3、 缺陷管理的一般流程
缺陷管理的流程比较简单,图1是一个缺陷状态图。 流程中的角色:
1、 测试人员:进行测试的人员,缺陷的发起者;
2、 项目经理:对整个项目负责,对产品质量负责的人员;
3、 开发人员:执行开发任务的人员,完成实际的设计和编码工作;
4、 评审委员会:对缺陷进行最终确认,在项目成员对缺陷达不成一致意见时,行使仲裁权力。
缺陷的状态
1、 初始化:缺陷的初始状态;
2、 待分配:缺陷等待分配给相关开发人员处理;
3、 待修正:缺陷等待开发人员修正;
4、 待验证:开发人员已完成修正,等待测试人员验证;
5、 待评审:开发人员拒绝修改缺陷,需要评审委员会评审;
6、 关闭:缺陷已被处理完成。
4、 缺陷数据统计
如前所述,缺陷数据统计也是缺陷跟踪管理系统的目标。一般而言,生成的缺陷数据统计图表包括缺陷趋势图、缺陷分布图、缺陷及时处理情况统计表等。
5、 缺陷跟踪管理系统
目前已有的缺陷跟踪管理软件包括Compuware公司的TrackRecord软件(商业软件)、Mozilla公司的Buzilla软件(免费软件),以及国内的微创公司的BMS软件,这些软件在功能上各有特点,可以根据实际情况选用。当然,也可以自己开发缺陷跟踪软件,例如基于Notes或是ClearQuese开发缺陷跟踪管理软件。我公司采用的是自己开发的基于Notes的缺陷跟踪系统,除了具有上述功能外,还能够通过Notes的邮件系统方便地向相关人员发送提醒信息(缺陷处理超时提醒、缺陷待处理提醒等)。
除此之外,作为一个缺陷跟踪管理系统,还必须注意权限分配的问题。缺陷记录作为软件开发过程中的重要数据,不能轻易被删除;对于已经关闭的缺陷,也不能随意进行修改。因此,缺陷跟踪管理系统必须设置严格的管理权限,非相关人员不得进行相应操作,修改相应数据。在这一点上,通过Notes也很容易控制。
文章来源于领测软件测试网 https://www.ltesting.net/