软件测试基础 - 缺陷管理

 

一、基本术语

  常见术语：bug  defect  issue

  严重程度：Mistake→defect&bug→fault→failure

 

二、缺陷报告单

 

*Bug title/summary：标题  对问题的简单概要描述

描述的问题，实际结果（不等于/有偏差）预期

如:视频播放的进度条挡住主界面

 

测试绩效考核：  bug数量，有效的bug率=(总bug-重复bug-不重现的bug)/总bug量

 

*Bug reproduce steps:重现步骤

1)按照重现步骤执行，可以看到描述的缺陷：

       a.如果bug是执行用例发现的，--用例执行步骤

       b.详细的实际结果 

       c.期望结果

2)Bug重现率：bug不是每次重现，一般重现3次再提交，例如10次中6次重现，重现率6%

3)附件：图片格式gif,jpg,jpge一般不用bmp太大，同时给图片命名

4)缺陷原因分析：缺陷产生的可能原因。

 

三、缺陷管理的基本流程

流程梳理：

1.测试人员在发布服务器上拿到最新版本的软件，开始测试（手动或自动化测试），执行测试过程中，发现bug,记录到BMS缺陷管理系统中；
2.测试人员会发送邮件给开发人员，开发人员得到最新bug后，定位bug，寻找原因，若问题简单直接解决，若问题较复杂（比如一个bug可以采取三个修改方案，三个方案各有利弊），开发人员会发送邮件给评审专家，共同商讨采用哪种方案；
3.经讨论确认方案后，开发人员进行修改，修改完毕后把修改后的源代码check in 到源代码服务器上，这个服务器上有软件对代码进行管理，该软件就是配置管理软件；
4.开发人员check in 后，Builder（每日构建技术人员）会从源代码服务器上获取最新的源代码，并且进行编译，编译之后把软件最新版本发布到服务器上；
5.测试人员再把新版本下载下来，并验证该版本是否修复了之前版本中发现的缺陷，这就是一个回归测试的过程。

   上面就是一个简单的缺陷管理流程，通过这样一个完整的流程，以bug为驱动，对软件的缺陷记录、提交、修改、验证有了一个很好的管理流程，因为一个完整的缺陷管理过程是贯穿测试、开发、builder的全过程。

 

四、缺陷管理的目的

1.缺陷跟踪

      保证缺陷得到有效的跟踪和解决。

2.缺陷分析

      获取正确的bug信息，用作缺陷分析和产品度量。

 

五、缺陷管理相关工具

      软件缺陷跟踪过程需要有软件工具支持：

1.付费工具有：Mercury Quality Center(简称TD)\ Rational ClearQuest(简称CQ)\ HP Quality Center(简称QC)

2.免费开源工具有：Bugzilla\ Mantis\ Jira

     如何选择工具，建议根据公司财力来，如果公司财力比较雄厚，可以采用付费工具，可用性和易用性较好，同时还有相关技术支持服务；若公司较小，建议使用免费工具，节省开支。

 

六、缺陷管理相关角色

   软件开发人员，测试人员，开发经理，测试经理，CCB变更控制委员会（开发和测试的协调）、配置管理员（软件版本管理）

 

七、缺陷管理的相关属性

1.缺陷发现人：可以据此对测试人员进行绩效考核

2.缺陷发现时间

3.缺陷所属版本：避免开发和测试产生混乱。

4.缺陷修改日期：可以据此对开发人员进行绩效评估。

5.软件缺陷的状态 state

软件缺陷状态
New	缺陷的初始状态
Open	开发人员开始修改缺陷
Fixed	开发人员修改缺陷完毕
Closed	回归测试通过
Reopen	回归测试失败
Postpone	推迟修改
Rejected	开发人员认为不是程序问题，拒绝缺陷
Duplicate	与已提交的Defect重复
Abandon	被 Reject和Duplicate的Defect，测试人员确认后的确不是问题，改为此状态

6.severity 软件缺陷严重程度

严重程度：致命→严重→一般→提示

1) 严重性（bug修改的顺序  站在项目的角度综合权衡项目时间、进度、技术和风险）

     高：当天修改  0~8h内

     中：2~4天

     低：一周内或者本发布周期

2）priority 优先级  P0~p4级别（BUG出现对于系统造成的影响，站在用户角度）

     P0：block issue导致测试挂起  尽快修改（代码回滚，回到前一个版本）

     P1：当天修改  0~8

     P2：功能相关

     P3：主要配置环境的UI

     P4：可以不修改

 

判断：严重等级比较高的bug优先级别一定高？

N 。若 bug很严重但是重复率很低，或者影响项目发布，或当前技术有限，或当前bug修改会产生更大的风险，优先级别可以降低。

 

7.Issue type 缺陷类型

a.  功能角度

-----error 错误

-----missing 功能遗漏

-----extra 多余的

-----improvement 需优化的，建议修改

b.  质量特性

-----功能性

-----性能

-----安全性

-----配置

-----可靠性

c. 缺陷产生的原因

DCR→design change request设计变更、Perf→性能、Spec→需求、Test→测试

 

8.bug管理流程图

 9.缺陷状态迁移矩阵