前言
工作多年,发现诸多测试新人对缺陷分析了解甚少,市面上也很少有书籍专门对缺陷分析方法进行介绍。故在此总结一些自己的经验,希望能提供一些思路:
内容提要
对于如何有效分析缺陷,本文将分三个部分向大家介绍:
(一)BUG属性分解:我们首先一起来解读BUG的诸多属性,为何我们需要这些属性,这些属性对我们后续的分析有何帮助?在这一部分会为大家做一定解析。
(二)单项目BUG分析与质量评估:获取BUG后如何解读缺陷,如何通过这些缺陷了解项目质量和风险?本文将以改编的案例形式重点介绍。
(三)综合分析与数据度量:放大自己的视角,把缺陷全局化,用管理者的眼光建立基线指标,指导后续项目提升与改进。将此作为真正意义上缺陷分析工作的扩展。
关键词:缺陷分析;质量评估;数据度量;
正文
(一)BUG属性分解
1、BUG属性
所谓BUG属性,其实简单讲就是我们日常提报BUG时要求填写的内容,每个公司都有自己的填写标准,内容会有所差异,这里向大家介绍一些基础字段
属性 | 描述 |
项目名称 | 由公司自行定义,用于区分本次测试与其他测试项目 |
项目所属模块 | 由公司自行定义,用于标识本次测试范围 |
BUG标题 | 一般是对BUG的简要描述,依据各公司要求规范填写 |
BUG类型 | 需求错误,设计错误,编码错误,其他参考2章节 |
BUG严重程度 | 致命,严重,一般,建议参考3章节 |
BUG优先级 | 高优先级,中优先级,低优先级参考4章节 |
缺陷描述: | 描述重现步骤,预期结果和实际结果 |
缺陷状态: | 活动,已解决,已关闭,待决定参考5章节 |
BUG提出者 | 缺陷提出者,一般为项目测试人员 |
BUG制造者 | 缺陷制造者,一般为程序开发人员 |
BUG版本号 | 一般分为BUG发现版本和BUG修复版本两类 |
BUG解决者 | 缺陷解决这,通常为缺陷制造者本人 |
2、BUG类型
例如:
编号 | 类型 | 描述 |
1 | 需求错误 | 需求本身不符合逻辑导致的错误 |
2 | 设计错误 | 因设计文档和需求不符导致的错误 |
3 | 编码错误 | 程序和需求不符导致的错误 |
4 | 其他 | 其他错误 |
……………………
查看全文请点击下载:http://www.51testing.com/html/11/n-832511.html
(二)单项目BUG分析与质量评估
单项目BUG分析是日常工作中最常见的分析指标,可以通过缺陷在项目各环节的变化来了解项目质量和项目进度,并预估项目风险。
项目缺陷分析有很多入手点,下面有三个案例,针对短期维护类项目,小型工程类项目和中小型重构项目,以部分BUG属性作为分析依据。
1、短周期维护类项目缺陷分析
案例一:通过三个基础指标(BUG类型/BUG严重程度/BUG缺陷状态)分析项目缺陷,假设人力,时间等因素均正常。
项目类型 | 某网站市场活动 | |
功能描述 | 情人节即将来临,某网站针对一些特定产品策划了情人节促销活动 | |
项目周期 | 10个工作日 | 需求分析与评审2个工作日,设计与编码 3个工作日测试4个工作日,验收与发布1个工作日 |
人力投入 | 5.5人 | 项目经理 1人,需求分析师1人,UI设计1人,开发人员1人,测试人员1.5人 |
Point1: