1-测试 - 缺陷管理

目录

• 重点
• 什么是缺陷？
• 软件缺陷的表现形式
• 软件缺陷产生的原因
• 软件缺陷的根源
• 软件缺陷修复的费用
• 缺陷分类标准
  • 缺陷属性
  • 缺陷类型（bug类型）
  • 软件缺陷严重性与优先级
  • 缺陷状态
  • 缺陷的起源/来源/根源
• bug
• 缺陷报告
  • 软件缺陷的信息
  • 软件缺陷报告的主要信息
  • 缺陷报告中的状态与bug处理意见
  • 缺陷报告书写规范
  • 缺陷处理流程
  • 缺陷跟踪
  • 缺陷统计
  • bug统计
  • 缺陷密度
• 缺陷修改说明
• 缺陷数据分析
  • 缺陷数据分析的重要性
  • 缺陷数据分析关注的问题
  • 缺陷数据分析的数据指标
• 常用缺陷识别方法
• 不同软件组织的缺陷管理过程
• 缺陷管理工具

• 返回测试目录
• 返回随笔目录

重点

你应该记住的：

• 缺陷产生的原因。
• 缺陷的严重性与优先级。
• 如何编写缺陷报告。
• 缺陷的处理流程。

什么是缺陷？

软件缺陷的定义
IEEE 1983 of IEEE Standard 729中对软件缺陷作了一个标准的定义：

• 从产品内部看，软件缺陷是软件产品开发或维护过程中所存在的错误、毛病等各种问题。
• 从外部看，软件缺陷是系统所需要实现的某种功能的失效或违背。

软件缺陷是指存在于软件（程序、数据、文档）中的那些不符合用户需求的问题。

• 软件未达到需求规格说明书表明的功能。（计算器说明书一般声称该计算器将准确无误地进行加、减、乘、除运算。如果测试人员或用户选定了两个数值后，随意按下了“+”号键，结果没有任何反应。）
• 软件出现了需求规格说明书指明不会出现的错误。（假如计算器说明书指明计算器不会出现崩溃、死锁或者停止反应，而在用户随意按、敲键盘后，计算器停止接受输入或没有了反应。）
• 软件的功能超出了需求规格说明书指明的范围。（若在进行测试时，发现除了规定的加、减、乘、除功能之外，还能够进行求平方根的运算，而这一功能并没有在说明书的功能中规定。）
• 软件未达到需求规格说明书虽未指明而应该达到的目标。（若在测试过程中发现，每当计算器重启后，计算值就出现偏差，但软件需求规格说明书未能指出在此情况下应如何进行处理。）
• 软件测试人员认为软件难以理解、不易使用、运行速度慢、或者最终用户认为不好。（测试人员或最终用户发现计算器某些地方不好用，比如，按键太小、显示屏在亮光下无法看清等。）

因此软件缺陷就是软件产品中所存在的问题，最终表现为用户所需要的功能没有完全实现，没有满足用户的需求。
所以，缺陷不仅仅是程序出了bug。缺陷>=bug。

软件缺陷的表现形式

• 功能、特性没有实现或部分实现。
• 设计不合理，功能特性不明确，逻辑不清楚或存在矛盾。
• 产品实际结果和所期望的结果不一致。
• 没有达到需求规格说明书所规定的性能指标等。
• 运行出错，包括运行中断、系统崩溃、界面混乱等。
• 数据不正确、精度不够、不完整或格式不统一。
• 用户不能接受的其他问题，如存取时间过长、界面不美观。
• 硬件或系统软件上存在的其他问题

软件缺陷产生的原因

软件缺陷产生是不可避免的，造成软件缺陷产生的原因主要归纳如下：

• 需求解释或者记录错误
• 用户需求定义错误
• 设计说明存在错误
• 编码说明、程序代码有误
• 硬件或者软件系统上存在错误
• 其他，如文档错误、内容不正确或拼写错误

需求说明书：需求说明书的错误或不清楚引起的错误，是缺陷第一大的来源；
设计文档：设计文档描述不准确、以及与需求说明书不一致，是缺陷的第二大来源；
编码：纯粹是由编码的问题引起；
其他：系统集成、测试等引起；

传话游戏

营长对值班军官:明晚大约八点钟左右,哈雷慧星将可能在这个地区看到,这种慧星每隔七十六年才能看见。命令所有士兵着野战服在操场上集合,我将向他们解释这一罕见的现象。如果下雨的话,就在礼堂里集合,我为他们放一部有关慧星的影片。
值班军官对连长:根据营长的命令,明晚八点哈雷慧星将在操场上空出现如果下雨的话,就让士兵穿着野战服列队前往礼堂,这一罕见的现象将在那里出现。
连长对排长:根据营长的命令,明晚八点,非凡的哈雷慧星将身穿野战服在礼堂中出现。如果操场上下雨的话,营长将下达另一个命令,这种命令每隔七十六年才会出现一次。
排长对班长:明晚八点,营长将带着哈雷慧星在礼堂中出现,这是每隔七十六年才会有的事。如果下雨的话,营长将命令慧星穿上野战服到操场上去。
班长对士兵:在明晚八点下雨的时候,著名的七十六岁的哈雷将军将在营长的陪同下身穿野战服开着他那辆"慧星"牌汽车经过操场前往礼堂。

软件缺陷的根源

缺陷根源：指造成缺陷的根本因素，以寻求软件开发流程的改进、管理水平的提高，软件缺陷根源如上。

• 交流不充分：客户与开发人员、开发人员与测试人员等，沟通太少。
• 软件的复杂性：功能复杂、开发复杂、测试复杂。
• 开发人员的错误：对需求的理解、开发压力、能力与经验。
• 需求的变化：需求说明书、设计文档、程序的变更。
• 进度压力：项目周期比较紧，比如由原定3周改为1周。

软件缺陷修复的费用

软件在从需求、设计、编码、测试一直到交付用户公开使用后的过程中，都有可能产生和发现缺陷。随着整个开发过程的时间推移，更正缺陷或修复问题的费用呈几何级数增长。
某些缺陷检测方法的成本比其他方法要高。最经济的方法应该是找出缺陷的成本最低，而在其他方面同别的方法并无二致。后一个条件很重要，因为查找缺陷的成本受到了很多因素的影响，例如特点的缺陷检测技术所能找到的缺陷总量，缺陷被发现时所处的开发阶段，以及经历因素之外的其他因素。
大部分研究都发现，检查比测试的成本更小。NASA软件工程实验室的一项研究发现，阅读代码每小时能够检测出的缺陷要比测试高出80%左右（Basili and Selby 1987），另一个组织则发现使用测试来检测缺陷的成本是检查的6倍（Ackerman，Buchwald and Lewski 1989）。后来，IBM的一项研究又发现，检查发现一个错误只需要3.5个工作时，而测试则需要花费15~25个工作时（Kaplan 1995）。

缺陷分类标准

缺陷属性

属性名称	描述
缺陷标识	标记每一个缺陷的符号，具有唯一性
缺陷类型	缺陷种类
缺陷严重程度	因缺陷引起的故障对软件产品的影响程度
缺陷优先级	缺陷必须被修复的紧急程度
缺陷状态	跟踪缺陷修复的进展情况
缺陷起源	引起故障或第一次被检测到所处的软件阶段
缺陷来源	缺陷起因
缺陷根源	引起缺陷的根本原因

缺陷类型（bug类型）

系统缺陷

• 由于程序所引起的司机，异常退出。
• 程序死循环。
• 程序错误，不能执行正常工作或重要功能，是系统崩溃或资源不足。

数据缺陷

• 数据计算错误。
• 数据约束错误。
• 数据输入、输出错误。

严重地影响系统要求或基本功能的实现，且没有办法更正（重新安装或者重启不属于更正的方法）。

数据库缺陷

• 数据库发生死锁。
• 数据库的表、缺省值为加约束条件。
• 数据库连接错误。
• 数据库中的表由过多的空字段。

接口缺陷

• 数据通信错误。
• 程序接口错误。

功能缺陷

• 功能无法实现。
• 功能实现错误。

严重地影响系统要求或基本功能的实现，且没有有合理的办法更正（重新安装或者重启不属于更正的方法）。
安全性缺陷

• 用户权限无法实现。
• 超时限制错误。
• 访问控制错误。
• 加密错误。

兼容性缺陷

• 与需求规定配置兼容性不符合。

性能缺陷

• 未达到预期的性能目标。
• 性能测试中出错，导致无法继续进行测试。

界面缺陷

• 操作界面错误。
• 打印内容、格式错误。
• 删除操作未给出提示。
• 长时间操作未给出提示。
• 界面不规范。

用户操作不方便或者遇到麻烦，但不影响执行工作功能的实现。

软件缺陷严重性与优先级

严重性和优先级是表征软件测试缺陷的两个重要因素，它影响软件缺陷的统计结果和修正缺陷的优先顺序，特别在软件测试的后期，将影响软件是否能够按期发布与否。
对于软件测试初学者而言，或者没有软件开发经验的测试工程师，对于这两个概念的理解，对于它们的作用和处理方式往往理解的不彻底，实际测试工作中不能正确表示缺陷的严重性和优先级。这将影响软件缺陷报告的质量，不利于尽早处理严重的软件缺陷，可能影响软件缺陷的处理时机。

什么是缺陷的严重性和优先级
严重性(Severity)顾名思义就是软件缺陷对软件质量的破坏程度，即此软件缺陷的存在将对软件的功能和性能产生怎样的影响。

在软件测试中，软件缺陷的严重性的判断应该从软件最终用户的观点做出判断，即判断缺陷的严重性要为用户考虑，考虑缺陷对用户使用造成的恶劣后果的严重性。

优先级是表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。

确定软件缺陷优先级，更多的是站在软件开发工程师的角度考虑问题，因为缺陷的修正顺序是个复杂的过程，有些不是纯粹技术问题，而且开发人员更熟悉软件代码，能够比测试工程师更清楚修正缺陷的难度和风险。

缺陷的严重性和优先级的关系

缺陷的严重性和优先级是含义不同但相互联系密切的两个概念。它们都从不同的侧面描述了软件缺陷对软件质量和最终用户的影响程度和处理方式。

一般地，严重性程度高的软件缺陷具有较高的优先级。严重性高说明缺陷对软件造成的质量危害性大，需要优先处理，而严重性低的缺陷可能只是软件不太尽善尽美，可以稍后处理。

但是，严重性和优先级并不总是一一对应。有时候严重性高的软件缺陷，优先级不一定高，甚至不需要处理，而一些严重性低的缺陷却需要及时处理，具有较高的优先级。

修正软件缺陷不是一件纯技术问题，有时需要综合考虑市场发布和质量风险等问题。例如，如果某个严重的软件缺陷只在非常极端的条件下产生，则没有必要马上解决。另外，如果修正一个软件缺陷，需要重新修改软件的整体架构，可能会产生更多潜在的缺陷，而且软件由于市场的压力必须尽快发布，此时即使缺陷的严重性很高，是否需要修正，需要全盘考虑。

另一方面，如果软件缺陷的严重性很低，例如，界面单词拼写错误，但是如果是软件名称或公司名称的拼写错误，则必须尽快修正，因为这关系到软件和公司的市场形象。

处理缺陷的严重性和优先级的常见错误

正确处理缺陷的严重性和优先级不是件非常容易的事情，新手很可能会出现下面的情形：

1. 将比较轻微的缺陷报告成较高级别的缺陷和高优先级，夸大缺陷的严重程度，经常给人“狼来了”的错觉，将影响软件质量的正确评估，也耗费开发人员辨别和处理缺陷的时间。
2. 将很严重的缺陷报告成轻微缺陷和低优先级，这样可能掩盖了很多严重的缺陷。如果在项目发布前，发现还有很多由于不正确分配优先级造成的严重缺陷，将需要投入很多人力和时间进行修正，影响软件的正常发布。或者这些严重的缺陷成了“漏网之鱼”，随软件一起发布出去，影响软件的质量和用户的使用信心。

因此，正确处理和区分缺陷的严重性和优先级，是软件测试人员和开发人员，以及全体项目组人员的一件大事。处理严重性和优先级，既是一种经验技术，也是保证软件质量的重要环节，应该引起足够的重视。

扯了这么多理论，那我们如何将缺陷的严重性和优先级表示出来呢？

**如何表示缺陷的严重性与优先级 **

陷的严重性和优先级通常按照级别划分，各个公司和不同项目的具体表示方式有所不同。

为了尽量准确的表示缺陷信息，通常将缺陷的严重性和优先级分成4级。如果分级超过4级，则造成分类和判断尺度的复杂程度，而少于4级，精确性有时不能保证。

具体的表示方法机可以使用数字表示，也可以使用文字表示，还可以数字和文字综合表示。使用数字表示通常按照从高到底或从低到高的顺序，需要软件测试前达成一致。例如，使用数字1，2，3，4分别表示轻微、一般、较严重和非常严重的严重性。对于优先级而言，1，2，3，4可以分标表示低优先级、一般、较高优先级和最高优先级。

软件缺陷的严重性参考：

严重等级	描述
5-Critical	系统瘫痪、异常退出、死循环、严重的计算错误等
4-VeryHigh	频繁的死机，系统大部分功能不可用
3-High	a.功能点没有实现，或不符合用户需求 b.数据丢失
2-Medium	a.影响一个相对独立的功能 b.仅仅在特定条件上发生 c.与产品需求定义不一致 d.断断续续的出现问题
1-Low	表面性错误（如错别字）

软件缺陷的优先级参考：

优先级别	描述
5-Urgent	最高优先级。在这个错误影响下，系统几乎不可用。
4-VeryHigh	高优先级。错误对这套系统的能力产生严重的影响。
3-High	中优先级。如果这个错误存在与系统中，会制约开发和测试的活动的进行，如果先前没有修复它，那么需要在发布前修复它。
2-Medium	低优先级。不会延迟发布，但是会在以后修正这个错误。
1-Low	最低优先级。时间和资源允许时修正。

缺陷状态

编号	缺陷状态	描述
1	提交（submited）	已提交的缺陷
2	打开（open）	确认“提交缺陷”，等待处理
3	拒绝（rejected）	拒绝“提交缺陷”，不需要修复或不是缺陷、重复缺陷、无法重现
4	修复（resolved）	缺陷被修复
5	关闭（closed）	确认缺陷已修复，将其关闭
6	推迟（later）	可以在以后解决，但要确定修复日期或版本

缺陷的起源/来源/根源

简单来说，就是我们要了解从哪发现的缺陷？该缺陷的来源是哪？以及该缺陷产生的根源？
起源

缺陷起源	描述
需求	在需求阶段发现的缺陷
架构	在架构阶段发现的缺陷
设计	在设计阶段发现的缺陷
编码	在编码阶段发现的缺陷
测试	在测试阶段发现的缺陷

来源

缺陷来源	描述
需求	由于需求的问题引起的缺陷
架构	由于架构的问题引起的缺陷
设计	由于设计的问题引起的缺陷
编码	由于编码的问题引起的缺陷
测试	由于测试的问题引起的缺陷
集成	由于集成的问题引起的缺陷

根源

缺陷根源	描述
目标	如：错误的范围，误解需求
过程、工具和方法	如：需求收集过程、风险管理过程、变更管理过程等
人	职责交叉、团队经验不足
沟通	如：缺乏用户参与、管理沟通不顺畅
软件	如：编辑工具的错误、服务器自身的错误
环境	如：人员调整、工作环境

bug

说完了缺陷，让我们深入缺陷中，来聊聊bug。

什么是bug

• bug泛指软件程序的漏洞和缺陷。
• 测试工程师或用户发现与提出的，软件可以改进的细节部分、或者与需求文档存在功能偏差的实现。
• 测试工程师主要职责就是发现bug，提交bug信息给研发人员，研发人员修复bug。

案例
例如登录时，要求输入账号密码。
输入正确的账号密码:
结果提示：用户名/密码不存在
再三确认账号密码是否错误，可以重新再注册一个账号进行登录
如新账号也是账号不存在，此登录已经是bug了！

bug的类型
想要确定bug的类型，需要对产品有较深的理解。
禅道系统中对bug定义划分如下：

• 代码错误(研发代码有误，功能未实现)
• 设计缺陷
• 界面优化
• 性能问题
• 配置相关
• 安装部署
• 安全相关
• 标准规范
• 测试脚本
• 其他(功能类、界面类、性能类、易用性类、兼容性类、其他)

bug等级划分

根据bug等级划分为三级或四级。
等级越高，可能被修复的等级也越高，公司也会根据测试提交的bug数量以及bug等级作为绩效考核标准。
判断bug的等级，如下分类：

• 致命错误
  • 常规操作缺引起系统崩溃、死机、死循环
  • 造成数据库泄露的安全问题，如恶意攻击造成的账户私密信息泄露
  • 涉及金钱隐患，金钱计算bug(如金额不足，还可以购买产品，对公司金额造成重大损失
• 严重错误
  • 重要功能未实现，如点击注册无反应，无法登录
  • 非常规操作（误操作）导致程序崩溃、死机、死循环
  • UI界面的严重问题
  • 密码明文显示，数据库泄露
• 普通错误
  • 不影响产品运行，不会影响故障，但对产品外观界面影响较大，如删除了好友，好友却未消失
  • 功能无法正常显示功能
  • 操作界面错乱
  • 查询数据错误
  • 页面未做输入格式限制
  • 删除错误未给与提示

缺陷报告

接下来，我们聊聊缺陷报告，那什么是缺陷报告？什么是报告缺陷呢？

报告缺陷的重要性

软件缺陷的描述是软件缺陷报告的基础部分，需要使用简单、准确、专业的术语来描述缺陷。否则，它就会含糊不清，可能会误导开发人员，影响开发人员的效率，也会影响测试人员自身的声誉，准确报告缺陷是非常重要的。

• 清晰准确的软件缺陷描述可以减少开发人员退回来的缺陷数量，可以节省开发人员和测试人员的时间。
• 提高软件缺陷修复的速度，使项目组能够有效地工作。
• 提高测试人员的可信任程度，可以得到开发人员对有效缺陷的及时响应。
• 加强开发人员、测试人员和管理人员的协同工作，让他们更好的工作。

报告缺陷注意事项

尽量确保缺陷可以重现。

• 如果提交的缺陷无法重现，会影响开发人员的工作效率。

简洁、准确、完整。

• 测试人员在提交缺陷报告时，要站在开发人员的角度上思考问题，要确保开发人员能迅速定位问题，而不会产生理解上的歧义。

一个缺陷一个报告，有的测试人员喜欢在一个缺陷报告里提交多个缺陷，这种习惯不提倡，原因有以下两点：

• 不便于分配，比如缺陷报告有2个缺陷，分别属于不同的开发人员，到底该分配给谁呢？
• 不便于验证，比如一个缺陷报告里面有2个缺陷，缺陷1已经解决，缺陷2还没有解决，那么这个缺陷报告该不该关闭呢？

软件缺陷的信息

为了便于缺陷的定位、跟踪和修改，要对所发现的缺陷，按照缺陷的严重程度、优先级、发现阶段、修复阶段、缺陷的性质、所属功能模块、系统环境等方面进行分类和统计。

软件缺陷报告的主要信息

编号	属性名称	描述
1	缺陷ID	唯一的缺陷ID，可以根据该ID追踪缺陷
2	缺陷状态	缺陷状态指缺陷通过一个跟踪修复过程的进展情况
3	缺陷标题	描述缺陷的标题
4	缺陷的严重程度	对软件产品的影响程度，分致命、较严重、严重、一般、低
5	缺陷的优先级	缺陷修复的先后顺序，即哪些缺陷优先修正，哪些稍后修正
6	缺陷所属模块	缺陷所属的项目和模块，要能较精确的定位至模块
7	缺陷记录者	提交缺陷的人员姓名
8	缺陷提交时间	缺陷提交的时间
9	缺陷处理人	处理缺陷的处理人
10	处理结果描述	对处理结果的描述，描述处理情况和代码修改说明
11	缺陷处理时间	缺陷处理的时间
12	缺陷验证人	对被处理缺陷验证的验证人（回测者）
13	验证结果描述	对验证结果的描述（通过、不通过）
14	缺陷详细描述	缺陷的重现步骤
15	缺陷环境说明	对测试环境的描述
16	必要的附件	如涉及到附件的或错误现象的图片等

为了便于缺陷的定位、跟踪和修改，要对所发现的缺陷，按照缺陷的严重程度、优先级、发现阶段、修复阶段、缺陷的性质、所属功能模块、系统环境等方面进行分类和统计。

缺陷报告中的状态与bug处理意见

再来简单聊聊关于缺陷报告中的缺陷状态与一般的bug处理意见：
此时该缺陷处于什么状态：

• 待确认的（Unconfirmed）
• 新提交的（New）
• 已分配的（Assigned）
• 问题未解决的（Reopened）
• 待返测的（Resolved）
• 待归档的（Verified）
• 已归档的（Closed）

关于该缺陷或者说bug的处理意见：

• 已修改的（Fixed）
• 不是问题（Nvalid）
• 无法修改（Wontfix）
• 以后版本解决（Later）
• 保留（Remind）
• 重复（Duplicate）
• 无法重现（Worksforme）

缺陷报告书写规范

标题：应保持简短、准确，提供缺陷的本质信息。

• 尽量按缺陷发生的原因与结果的方式书写。
• 避免使用模糊不清的词语，例如：“功能中断，功能不正确，行为不起作用”等。应该使用具体文字说明缺陷的症状。
• 为了便于他人理解，避免使用俚语或过分具体的测试细节。
  复现步骤：应包含如何使别人能够很容易的复现该缺陷的完整步骤。为了达到这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。常见问题：
• 包含了过多的多余步骤，且句子结构混乱，可读性差，难以理解。
• 包含的信息过少，丢失了操作的必要步骤。

复现步骤的正确书写方式：

• 提供测试的环境信息。
• 简单地一步步引导复现该缺陷，一个步骤包含的操作不要多。
• 每个步骤前使用数字对步骤编号。
• 尽量使用短语或短句，避免复杂句型句式。
• 复现的步骤要完整、准确、简短。
• 将常见步骤合并为较少步骤。
• 按实际需要决定是否包含步骤执行后的结果。

实际结果：是执行复现步骤后软件的现象和产生的行为。

• 实际结果的描述应向标题信息那样，要列出具体的缺陷症状，而不是简单地指出“不正确”或“不起作用”。

期望结果：描述应与实际结果的描述方式相同。通常需要列出期望的结果是什么。
附件：对缺陷描述的补充说明，可以是以下一些类型：

• 缺陷症状的截图。
• 测试使用的数据文件

其它：

• 选择合适的缺陷严重性属性。
• 按相应的规定，填写相应的字段信息。

避免常见的错误：

• 避免使用我、你等人称代词，可以直接使用动词或必要时使用“用户”代替
• 避免使用情绪化的语言和强调符号；
• 避免使用诸如“似乎”、“看上去可能”等含义模糊的词汇，而需要报告确定的缺陷结果；
• 避免使用自认为比较幽默的语句，只需客观地描述缺陷的信息；
• 避免提交不确定的测试问题，自己至少需要重现一次再提交。

反面的示例：

• 上海人：哪能查询到的结果和查询条件不搭噶的。
• 北京人：哥们好不容易输入一堆个人详细信息后，点击保存后全瞎了。

缺陷处理流程

缺陷跟踪

新提交的缺陷为新建状态，确认有效后为打开状态，经开发人员修改后，缺陷变为已修复（待验证）状态。此时就需要测试人员对缺陷进行回归测试，验证问题是否修复。

• 如果问题仍然存在，则测试人员将该缺陷的状态修改为重新打开。
• 如果问题已经修复，则测试人员将该缺陷的状态置为关闭状态（验证通过），同时添加回测说明如“该缺陷已解决”。

还有一种情况：开发人员认为缺陷在当前版本可以暂不修改，而考虑在后续版本中再做修正，缺陷的对应状态为延期。对于这种情况，项目负责人应召集开发人员、测试人员和其他项目相关人员进行讨论，如果讨论结果为同意则延期，如果不同意，则重新打开缺陷。

缺陷统计

• 对软件问题的功能域分布进行分析，找出系统的薄弱环节。
  • 要详细采集每个功能模块或系统构件的缺陷数据，并按功能、错误类型、严重程度等分类。
  • 二八定理：80%的软件问题总是发生在大约20%的功能模块中。
• 对缺陷的注入阶段的分布进行分析，并与历史数据相比较。应按不同的开发阶段详细采集缺陷的数据。
• 应对软件缺陷类型进行分析，以便针对各自的特点，先修复严重缺陷。
• 应动态采集每个测试周期中发现的缺陷数，并有效地控制缺陷的修复率。
• 应密切观察缺陷的状态，并及时跟踪其状态的变化，以检查测试和开发人员的工作情况。

bug统计

缺陷按活动分布：

缺陷密度

基本的缺陷测量是以每千行代码的缺陷数(个/KLOC)来测量的。称为缺陷密度，其测量单位是defects／KLOC。可按照以下步骤来计算一个程序的缺陷密度：

• 累计开发过程中每个阶段发现的缺陷总数。
• 统计程序中新开发的和修改的代码行数。
• 计算每千行的缺陷数=1000*缺陷总数/代码行数。

例如：一个132.2万行的源程序总共有210个缺陷，那该程序的缺陷密度是：

缺陷密度 = 1000 * 210  / 1322000 = 0.15个/KLOC

PS：KLOC，千行代码

缺陷修改说明

现在，我们再来聊聊缺陷修改中碰到的一些情况。
开发人员拒绝修改的缺陷

• 程序员无法重现或者现象难以捕捉
• 没有明确的报告以说明重现缺陷的步骤
• 程序员无法读懂的缺陷报告
• 用户很少使用或者不符合用户使用习惯的操作出错
• 由不受信任的测试人员提出

不是所有缺陷都会修改

• 市场的压力使得产品最终发行有时间限制
• 测试人员错误理解或者不正确操作引出的缺陷(FAQ)
• 错误的修改影响的模块较多，带来的风险较大(遗留)
• 修改性价比太低
• 缺陷报告中提出的问题很难重现

缺陷数据分析

在这块我们主要关注：

• 缺陷数据分析关注的问题
• 缺陷数据分析的重要性
• 缺陷数据分析的数据指标

缺陷数据分析的重要性

• 统计未修复的缺陷数目（特别是严重性高的缺陷），预计软件是否可以如期发布。
• 分析缺陷的类型分布，发现存在较多缺陷的程序模块，找出原因，进行软件开发过程改进。
• 根据测试人员报告缺陷的数量和准确性，评估测试有效性和测试技能。
• 根据报告的缺陷修复是否及时，改进软件开发与测试的关系，使测试与开发更有机的配合。

了解了缺陷数据分析的重要性，来看，在数据分析中，我们主要关注的问题。

缺陷数据分析关注的问题

• 正在测试的软件哪个模块的问题最多
• 测试人员中谁报告的软件缺陷最多
• 各类缺陷所占的数量百分比分别是多少
• 开发人员能及时修复软件缺陷吗
• 开发人员一次正确修复缺陷的百分比是多少
• 正在开发的软件能否在计划的时间内正常发布

缺陷数据分析的数据指标

• 每天/周报告的新缺陷数目。
• 每天/周修复的缺陷数。
• 累计报告的缺陷数目。
• 累计修复的缺陷数。
• 不同严重性类型的缺陷数。
• 程序模块与发现的缺陷的对应关系。

常用缺陷识别方法

• 通过技术文档识别缺陷
• 设计和分析文档
• 用户使用手册，帮助手册
• 通过行业标准规范识别缺陷
• 与专业人员来沟通识别缺陷

注意：不得站在自己主观意识去判断缺陷

来列举一些例子：

• 页面大小
  • 在B/S结构的软件系统中，当一个页面元素太多，未作精简时，在打开该页面时可能需要较长的加载时间，这对于软件性能是一个不小的影响，既增加了服务器的压力，又容易引起用户的反感。例如：
    • 图片未经压缩、格式不正确。比如采用BMP。
    • 代码冗余，存在太多无用代码。
    • 页面元素太多，太过复杂。
• 界面文字
  • 页面信息描述不清楚，有语病，错别字。简单语言复杂化，描述不正确，不符合当前页面。错误的帮助信息，乱码等。
• 容错处理（功能缺陷）
  • 容错处理在软件系统中占据十分重要的地位。所谓容错，就是容忍错误的能力。当用户在使用软件过程中发生错误后，软件应该能给出引导信息，指应用户进行正确的操作。例如：
    • 用户输入错误，系统无提示，无响应，用户不能清晰知道系统不处理的原因。
    • 给出信息提示，用户接受后无法继续操作，不给用户“改过自新”的机会。
    • 用户输入不合法的信息后，系统给出提示，用户确定后，系统仍能处理错误的信息。
    • 取消功能不能取消，比如删除，系统给出提示，是否确定删除，用户否认后仍执行了删除。
• 性能缺陷
  • 这里所说的性能问题不需专业的工具就能发现的问题，这类问题在平常做黑盒测试的时候就能发现。例如：
    • 打开文档，10秒应该可以完成的，却花了3分钟。
    • 启动软件，CPU长时间100%，内存消耗过多。
    • 5个用户可以正常使用，20个用户使用时系统崩溃。打开一个登录页面花了1分钟。
    • 完成一个查询功能，花了2分钟。

接下来，就考验个人情商环节了，因为一不小心，可能面临挨打的风险！接下来的一些列举项，通常都由专业的人员完成，比如UI的设计师，DBA，人家是专业，你在人家的领域小心指手画脚啊，比如你跟UI说这个页面设计的真丑，那UI的小暴脾气上来，不用小拳锤胸口咋地！

你要是跟DBA说什么SQL有问题：

• 数据转换
  • 软件中的功能主体一般由等组成。例如：增加、修改、删除、查询。
    • 无法增加记录，比如点击新增，页面自动关闭。
    • 增加记录后无显示，但提示增加成功。
    • 增加记录后显示不正确，显示为乱码，信息显示不全。
    • 增加记录后多出记录。
    • 无法修改记录。修改后不能自动更新，需手工更新。
    • 无法删除记录，无法全部删除。
    • 删除不成功，但相应的记录已被删除。
    • 无法查询、查询结果错误。
• UI用户界面
  • 色彩：色彩的搭配无序、混乱是软件图形界面设计的大忌，图形界面应尽量设计得温和些。这类缺陷主观类强，个人美感占据主动，所提交的缺陷一般严重程度不可定得太高。例如：
    • 整体页面色彩单调，无变化，仅使用一种色彩，且篇幅较大，可提交建议性的缺陷，即使是简单的界面，宁可采用无色，也不可使用鲜艳的单色，如红色，黄色、绿色等。
    • 背景色与界面字体色彩相近，不能清晰区分，色彩搭配混乱、复杂，且不符合软件标准。
• 功能结构布局
  • 功能结构布局主要从界面的功能区域划分来考虑。相同的、类似的功能应该放在邻近的区域。例如：
    • 记录添加功能界面，添加按钮未放在醒目的位置。
    • 导航功能位于界面的右则。
    • 整体功能区域分布混乱。
• 图片
  • 图片选用不合理，与当前软件类型不符，无法正确体现当前界面功能性含义。图片不规范、不清晰。例如：
    • 图片色彩过于艳丽或黯淡，模糊不清。
    • 图片变形。
    • 图片不符合当前界面的主题，图片与描述性文字不符。
• 字体
  • 字体在软件界面中尤其重要，字体的使用要符合软件开发规范。例如：
    • 字体过大，与其他页面信息脱节，无法形成主体。
    • 字体过小，无法看清楚。
    • 字体不符合当前界面风格。
• 窗体大小
  • 窗体的设计要有层次感，父窗口、子窗口应该有所区别。窗口不应该有太多空白处，功能区域充实。例如：
    • 窗口太大，功能按钮分散，间隔太大。
    • 窗口太小，功能按钮过于集中，间隔太小，或控件显示不全。
    • 弹出窗口未能定于屏幕居中位置。

不同软件组织的缺陷管理过程

• 个体行为
  • 处于CMM第一级（或称为初始级）的软件组织，对软件缺陷的管理无章可循。工程师们只是在发现缺陷后，修改相应的软件。通常，没有人会去记录自己发现的缺陷。也没有人知道在新的软件版本里，究竟纠正了哪些缺陷，还有哪些缺陷未被纠正。而且，只有在下一轮测试中才有可能知道那些所谓已被纠正了的缺陷是否真的被纠正了，更重要的是纠正过程是否引入了新的缺陷。
  • 所以这样的软件组织的项目交货期（Release Date）表现出强烈的不可预测性。并且， 为了获得一个高质量的软件产品（如果能够的话），通常要在测试上花费大量的人力。
• 项目行为
  • 在CMM第二级（或称为可重复级）的软件组织中，软件项目会从自身的需要出发，制定本项目的缺陷管理过程。一个完备软件缺陷管理过程通常会包括如下几个方面：
    • 提交缺陷。
    • 分析和定位缺陷。
    • 提请修改相应的软件。
    • 修改相应的软件。
    • 验证修改。
  • 项目组会完整地记录开发过程中的缺陷，监控缺陷的修改过程，并验证修改缺陷的结果。
• 组织行为
  • CMM第三级（或称为已定义级）的软件组织会汇集组织内部以前项目的经验教训，制定组织级的缺陷管理过程。并且，要求项目根据组织级的缺陷管理过程定制本项目的缺陷管理过程。
  • 从而，整个软件组织中的项目都遵循类似的过程来管理缺陷。好的缺陷管理实践成为所有项目的实践，而教训也为所有项目所了解。更重要的是，随着组织的不断发展完善，组织的过程会得到持续性的改进，所有项目的过程也都会相应的改进。
• 持续优化
  • 与CMM第四级相比，CMM第五级（或称为持续优化级）更强调对组织的过程进行持续性改进，从而使过程能力得到不断的提升。
  • 就缺陷管理而言，软件组织应当在量化理解其过程能力的基础上，持续地改进组织级的开发过程、缺陷发现过程，引入新方法、新工具，加强经验交流，从而实现缺陷预防（Defect Prevention）。
  • 缺陷预防的着眼点在于缺陷的共性原因（Common Cause）。通过找寻、分析和处理缺陷的共性原因，实现缺陷预防。

缺陷管理工具

以前，我们用Word文档来管理缺陷，但慢慢的发现Word文档管理缺陷较为麻烦不够灵活。后来就慢慢有了专门的工具：

• Quality Control（QC）：是Mercury Interactive 公司（软件版权属于惠普公司）推出的一个基于 Web（伪） 且支持测试管理的所有必要方面的应用程序。该软件提供统一、可重复的流程，用于收集需求、计划和安排测试、分析结果并管理缺陷和问题。组织可使用该软件在较大的应用程序生命周期中实现特定质量流程和过程的数字化。该软件还支持在 IT 团队间进行高水平沟通和协调。功能真的很强大（收费版），但是要花钱........

• Bugzilla：Bugzilla 是一个开源的缺陷跟踪系统（Bug-Tracking System），它可以管理软件开发中缺陷的提交（new），修复（resolve），关闭（close）等整个生命周期，功能较少，专门用来管理缺陷。

• Bugfree：除了管理缺陷，也可以管理用例，但不能管理需求.......

• Mantis：缺陷管理平台Mantis，也做MantisBT，全称Mantis Bug Tracker。Mantis是一个基于PHP技术的轻量级的开源缺陷跟踪系统，以Web操作的形式提供项目管理及缺陷跟踪服务。在功能上、实用性上足以满足中小型项目的管理及跟踪。更重要的是其开源，不需要负担任何费用。

• JIRA：JIRA是集项目计划、任务分配、需求管理、缺陷跟踪于一体的软件。它基于Java架构的管理系统，被广泛应用于缺陷跟踪、客户服务、需求收集、流程审批、任务跟踪、项目跟踪和敏捷管理等工作领域。

  JIRA创建的问题类型包括New Feature（新功能）、Bug（缺陷）、Task（任务）和Improvement（改进）四种，还可以自定义，所以它也是一个过程管理系统。同时融合了项目管理、任务管理和缺陷管理。JIRA功能强大，可配合着一些组件及工具一起使用，如： Confluence 用于 wiki 管理需求，JIRA管理任务、进度和 Bug 。

  JIRA设计以项目为主线，产品、测试结合管理，通过issues控制管理。因此它的核心诉求还是围绕issue展开的，以issue驱动管理、分工、以及团队协作，进而实现项目的规划、建设，终完成产品开发。

• 禅道：禅道项目管理软件（简称：禅道）集产品管理、项目管理、质量管理、文档管理、组织管理和事务管理于一体，是一款功能完备的项目管理软件，完美地覆盖了项目管理的核心流程。

  禅道的主要管理思想基于国际流行的敏捷项目管理方式—Scrum。Scrum是一种注重实效的敏捷项目管理方式，它规定了核心的管理框架 ，但具体的细节还需要团队自行扩充。禅道在遵循其管理方式基础上，又融入了国内研发现状的很多需求，比如bug管理，测试用例管理，发布管理，文档管理等。因此禅道不仅仅是一款scrum敏捷项目管理工具，更是一款完备的项目管理软件。基于scrum，又不局限于scrum。

  禅道最大的特色是创造性的将产品、项目、测试这三者的概念明确分开，互相配合，又互相制约。通过需求、任务、bug来进行交相互动，最终通过项目拿到合格的产品。

目前，禅道（市场占有率50%+）和JIRA（市场占有率30%+，剩下就其他的）用的人较多。禅道和JIRA功能有很多的通用性，所以，学会一门另一门就会了。

我们这里以禅道为例。

---

欢迎斧正，that's all