通常在测试执行阶段产生
 
原文来源：https://www.cnblogs.com/zhouchengzhi/p/8540833.html
 
 
 
 
 
 
 
 
 
一、缺陷的基本概念
 
 
 
关于 BUG
 
Bug的由来
Debug（调试bug的过程）
Bug和Defect
Bug：电脑系统或者程序中存在的任何一种破坏正常运转能力的问题或者缺陷，都可以叫做“Bug”；有时也被泛指因软件产品内部的缺陷引起的软件产品最终运行时和预期属性的偏离。
Defect（缺陷）：既指静态存在于软件工作产品（文档、代码）中的错误，也指软件运行时由于这些错误被激发引起的和软件产品预期属性的偏离现象。
 
 
容易混淆的几个概念
 
常见术语
 
失误（Mistake）：导致软件包含故障的人的行为；
缺陷（Defect）：软件的异常情况；（在实际工作中bug和缺陷可能存为缺陷）
故障（Fault）：引起一个功能组件不能完成所要求的功能的一种意外情况；
失效（Failure）：功能组件执行其规定功能的能力丧失；

 
 
 
 
缺陷定义
 
 
 
 
 
 
 
缺陷（Defect），常常又叫做Bug。
 
计算机软件或程序中存在的某种破坏正常运行能力的问题、错误，或者隐藏的功能缺陷。
 
从产品内部看，缺陷是软件产品开发或维护过程中存在的错误、毛病等各种问题；
 
从产品外部看，缺陷是系统所需要实现的某种功能的失效或违背。
 
 
 
缺陷示例--导弹误炸事件
 
 
 
 
 

 
 
 
 
缺陷来源：
 
 
 
缺陷来源于软件生命周期各个阶段。
 

 
 
 
 
产生原因：
 
1.产品说明书不全，不完整和不准确，修改频繁，沟通不畅和理解不同；
 
2. 软件设计过程中考虑不周到，片面，多变，理解和沟通不足；
 
3. 文档不足，压时间，赶进度，设计和编码错误都会引入缺陷；
 
4. 测试和实施过程中安装环境配置错误等。
 
 
 
缺陷的评价标准：
 
软件未实现需求规格说明书（SRS）要求的功能
软件未实现需求规格说明书（SRS）虽未明确提及但应该实现的目标
软件出现了需求规格说明书（SRS）指明不应出现的错误
软件实现了需求规格说明书（SRS）未提到的功能
软件难以理解、不易使用、运行缓慢，或者从测试工程师的角度来看——最终用户会认为不好
 
 
二、缺陷的属性
 
 
 
缺陷报告的相关属性：
 
 
 
缺陷ID
标题
产生的步骤
所属模块
发现人
发现的时间
严重程度
优先级
类型
状态
可再现性
发现阶段
责任人
所属版本
修改日期
引入原因
备注信息
相关附件
 
 
 
 
缺陷类型
 
 
 
遗漏（Missing）
错误（Error）
额外的实现（Extra）
改进（Enhancement）
 
 
 
 
优先级的划分
 
 
 
表示处理和修正软件缺陷的先后顺序的指标，即哪些缺陷需要优先修正，哪些缺陷可以稍后修正。
 
 
 
 
 
 
 
 
严重程度的划分
 
 
 
指因缺陷引起的故障对软件产品的影响程度
 

 
 
缺陷跟踪的交付物
 
 
 
 缺陷报告单（Bug Report）：也叫缺陷跟踪单。测试执行过程中，发现软件失效后，提出书面的报告，提供给开发人员或者其他负责人员作为定位缺陷的依据，也作为日后缺陷度量的数据依据。（只有提交了报告单才能被记录，方便以后提交报告给上级）
 
 
 
缺陷管理工具中的BUG Report
 
 
 
 
 
 
 
 
 
 
 
三 缺陷的生命周期
 
 
 
缺陷的生命周期
缺陷的生命周期就是指缺陷从开始提出到最后完全解决，并通过验证和确认的过程。在这个过程中缺陷报告的状态不断发生着变化，记录着缺陷被处理的过程。
缺陷的生命周期通过缺陷流程图得以展现
 
 
bug的流程
 
 
 

 
 
 
 
状态说明：
 
 
 
新建（new）：测试人员提交新问题标识的状态
打开（open）：已经确认为是BUG的状态
已修复（fixed）：为开发人员修改问题后所标志的状态，等待测试验证。
重新打开（reopen）：测试人员对修改问题进行验证后没有通过所标志的状态或者已经修改正确的问题又重新出现错误，由测试人员改变。
已关闭（closed）：为测试人员对修改问题进行验证后通过所标志的状态。由测试人员改变。
拒绝（rejected）：开发人员认为不是BUG、描述不清、重复、不能复现、不采纳所提意见建议、或虽然是个错误但还没到非改不可的地步故可忽略不计、或者测试人员提错，从而拒绝的问题。由BUG分配人或者开发人员来设置。
重复（duplicated）：表示该BUG已经被其他测试人员找出来了，或者开发认为原因是相同的（但从测试来看，认为出现的地方有所不同、表现有所不同等）
延期（postponed）：由于时间、进度、重要程度或者技术/需求等方面的原因，认为不能解决、须延期解决、或者本版不做留待到后续版本解决的BUG。
 
 
 
 
缺陷沟通：
 
 
 

 
 
 
 
 
 
一个简单的bug跟踪流程
 
 
 

 
 
 
 
BMS:缺陷管理工具
 
 
 
 
 
缺陷报告的状态：
 
 
 

 
 
 
 
 
 
缺陷状态迁移矩阵
 

 
 
 
 
rejected、duplicate 开发人员同意就跳转到reopen
 
不同意就跳转到abandon
 
 
 
软件测试缺陷管理流程
 
 
 

 
 
 
 
缺陷管理中的常见问题
 
 
 
提交的缺陷开发人员不认可怎么办？(给出提交缺陷的依据，如果还是不行，向上级或有经验的人员寻求帮助）
如何处理不能重现的缺陷？(出现缺陷必须立马截图记录，以防之后无法找到)
如何处理好与开发人员及其他相关人员的关系？(多沟通）
缺陷太多怎么办？（先打回让开发自己解决）
找不到缺陷怎么办？（分析代码质量真的太高还是用例设计不够全面）
缺陷得不到及时修复怎么办？（及时告知上级，与开发协调解决）
如何处理缺陷级别定义之争？（根据客观实际情况和项目组划分的范围定义）
如何处理缺陷跟踪中的扯皮现象？（针对主要负责人）
 
 
 
 
四 缺陷报告的书写
 
 
 
缺陷报告单书写准则 5C
 
 
 
Correct（准确）
   每个组成部分的描述准确，不会引起误解
 
Clear（清晰）
   每个组成部分的描述清晰，易于理解
 
Concise（简洁）
   只包含必不可少的信息，不包括任何多余的内容
 
Complete（完整）
   包含复现该缺陷的完整步骤和其他本质信息
 
Consistent（一致）
   按照一致的格式书写全部缺陷报告
 
 
 
缺陷报告的写作要点
 
 
 
再现：一般是尽量三次再现故障，如果问题是间断的，那要报告问题发生频率。
初步定位：可能影响再现的变量，例如配置变化、工作流、数据库，这些都可能改变错误的特征。
推广：确定系统其他部分是否可能出现这种错误，以及使用不同的数据时是否存在这种问题等等，特别是那些可能存在更加严重特征的部分。
压缩：精简任何不必要的信息，特别是冗余的测试步骤。
去除歧义：使用清晰的语言，尤其是避免使用那些有多个不同或相反含义的词汇。
中立：公正的表达自己的意思，对错误及其特征的事实进行陈述，避免夸张、幽默或讽刺。
评审：至少有一个同行，最好是一个有经验的测试工程师或测试经理，在递交错误报告之前自己先阅读一遍。
 
 
 
 
缺陷报告单基本内容
 
 
 
 
 
 
 
 
 
  Bug的摘要是要用一句话的形式简明扼要地将Bug描述出来，要清晰指出Bug所在部位以及其错误类型，不能太笼统。如“页面对非法输入有问题”可以修改为“流量信息查询页面对于非法输入没有进行校验”
 
 
 
 
 
缺陷描述举例
 
 
 
• 简单描述
 
  • Arial、Wingdings和Symbol字体会破坏新文件。
 
• 详细描述
 
  • 软件测试环境为windows 2000 sp4
 
  • 启动WordEdit编辑器，然后创建新文件。
 
  • 输入四行文本，重复输入”The quick fox jumps over the lazy brown dog”。
 
  • 选中所有四行文本，然后选择字体下拉菜单，并选择Arial。
 
  • 所有文本被转换成控制字符、数字和其它明显的随机二进制数据。
 
  • 重复三次，结果都一样。
 
• 相关附件
 
  • 附件1：变换格式之前的文档
 
  • 附件2：变换格式之后的文档
 
• 软件缺陷初步分析：
 
  • 粗略估计是格式问题，保存文件，关闭WordEdit并重新打开文件，但是数据仍
 
  然被破坏
 
  • 在改变字体前保存文件防止错误。
 
  • 对现存文件，错误不再发生。
 
  • 只在WINDOWS 2000下发生，而不出现在Solaris、Mac和其他Windows系
 
  统。
 
 
 
 
 
含糊不完整的缺陷描述
 
 
 
 
 
• 简要描述
 
  • WordEdit处理Arial字体有问题。
 
• 详细描述
 
  • 1、打开WordEdit。
 
  • 2、输入一些文本。
 
  • 3、选择Arial。
 
  • 4、文本被破坏
 
• 软件缺陷初步分析：
 
  • N/A
 
 
 
 
 
冗余混淆的缺陷报告
 
 
 
• 简要描述
 
  • 我在Solaris、Windows 98和Mac上运行WordEdit，当使用某些字体时，好
 
  像会破坏一些数据。
 
 
 
• 详细描述
 
  • 1、在Windows 98上打开WordEdit，然后编辑两个现有文件。这些文件包含
 
  一些字体的混合。
 
  • 2、文件正常打印。
 
  • 3、创建并打印一张图表，工作正常。但是有些内容不是很清楚。
 
  • 4、之后，创建了一个新文件。
 
  • 5、然后，输入了一大堆随机文本。
 
  • 6、在输入了文本之后，选中一些行。然后，拉下字体菜单并选择Arial。
 
  • 7、改变的文本被破坏了。
 
  • 8、重复三次，每次结果都一样。
 
  • 9、我在Solaris上重复步骤1-6，没有发现任何问题。
 
  • 10、我在Mac上重复步骤1-6，没有发现任何问题。
 
• 缺陷原因分析：
 
  • 我尝试选择其他字体，但是只有Arial出现这个错误。但是，其他没有测试的字
 
  体仍然有可能出错。
 
 
 
 
 
五 常用管理工具
 
 
 
缺陷管理的目的
 
 
 
• 保证信息的一致性
 
• 保证缺陷得到有效的跟踪，缩短沟通时间，解决问题更高效
 
• 利于缺陷分析、产品度量，使项目情况可视化加强
 
 
 

 
 
 
 
常用的缺陷管理工具
 
 
 
1. QC（QC（quality control）是TD的升级版，QC的升级就是ALM）
 
2. 禅道(bugfree升级版）
 
3. Mantis
 
4. JIRA
 
5. TestLink
 
6. Bugzilla
 
7. Redmine（开源，基于敏捷开发模型）
 
 
 
常用工具说明
 
 
 
1. QC 商业购买 --基于Web的测试管理工具，可以组织和管理应用程序测试流程的所有阶段，包括指定测试需求、计划测试、执行测试和跟踪缺陷。此外，通过Quality Center还可以创建报告和图来监控测试流程。
 
2. 禅道 国产开源 -- 本地化做的比较好。禅道是为研发类项目/团队量身定制的一款管理软件，覆盖产品开发的整个生命周期，页面简洁、流程清晰。
 
3. Mantis 开源 -- 是一个基于PHP技术的轻量级的开源缺陷跟踪系统，以Web操作的形式提供项目管理及缺陷跟踪服务。
 
4. TestLink 开源，可以与Mantis集成；是sourceforge的开放源代码项目之一，作为基于web的测试管理系统。
 
5. JIRA 开源，可二次开发，是Atlassian公司出品的项目与事务跟踪工具。
 
6. Bugzilla 是Mozilla公司提供的一款开源的免费Bug（错误或是缺陷）追踪系统，用来帮助你管理软件开发，建立完善的BUG跟踪体系
 
7. Redmine 是一个开源的、基于web的项目管理和缺陷跟踪工具。它用日历和甘特图辅助项目及进度可视化显示，同时它支持多项目管理。Redmine是一个自由开放源码软件的解决方案，它提供集成的项目管理功能，问题跟踪，并为多个版本控制的选项的支持。
 
 
 
六  缺陷分析
 
 
 
识别BUG
 
 
 
• BUG是由于软件开发者的疏忽和失误造成的。
 
• BUG是软件生命周期内发现和未被发现的所有问题总和。
 
• 全面质量管理和全程软件测试：
 
BUG不单指软件测试阶段发现的软件系统的功能性错误，还应包括软件开发过程中需求、设计、开发等阶段评审过程发现的问题，以及软件发布后客户发现并反馈的问题，同时还包括那些隐藏在软件内部未被发现的问题。（总结经验教训，改进软件开发过程）
 
 

 
目录
 
1 引言
2 缺陷记录
2.1 哪些缺陷该被记录？
2.2 工具
2.3 模版
  
3 缺陷流转
3.1 迭代内缺陷流转过程
3.2 生产缺陷流转过程
  
4 缺陷分析
4.1 分析周期
4.2 分析角度
4.3 分析工具
  
 

 
1 引言
 
敏捷测试原则中有一条是：预防缺陷，而不是关注缺陷的数量。敏捷团队中是整个团队为质量负责，团队追求的是整个产品质量的提升，而非传统的开发人员追求零缺陷，测试人员追求找到更多的缺陷。在敏捷开发中，虽然我们采取各种措施预防缺陷的发生，例如精准的自动化测试、代码检视、故事卡验收等等，但是并不能保证没有缺陷发生，一个零缺陷的产品也不现实。既然无法完全阻止缺陷的出现，那如何管理发生的缺陷，如何利用已有缺陷来指导质量内建过程，是我们需要考虑的。
 
本文以博主在实际项目中的经验，讲述缺陷的记录、流转和分析，每个模块的内容会分别讲述迭代内缺陷和生产缺陷的管理。
 
2 缺陷记录
 
2.1 哪些缺陷该被记录？
 
在记录缺陷前，我们要理清楚我们需要记录的缺陷有哪些，是不是每一个缺陷都应该被记录。敏捷项目是以迭代为交付周期，一个迭代周期从两周到一个月甚至2个月不等，每个迭代都会有新功能的上线。一般来讲，缺陷分为两类：一类是迭代内缺陷，即在迭代新功能开发时，故事验收或测试阶段发生的缺陷；另一类则是生产缺陷，我们是允许生产缺陷的存在的，但前提是缺陷影响范围可控，或者可以在用户发现前发现缺陷（测试右移），并且要具备快速修复或者回滚的能力。
 
对于迭代内缺陷，一般发现阶段分为故事卡验收阶段，测试阶段，回归测试阶段。对于故事卡验收阶段发现的缺陷，是否需要记录可视情况而定，一般而言，可以不需要记录，因为此时故事卡仍在开发阶段，开发同学仍然工作在这张卡上，其上下文充足，修复缺陷成本较低，可以直接备注在卡片上，等下一次故事卡验收的时候再验证是否修复。对于测试阶段和回归测试阶段的缺陷，建议记录下来，因为此时开发这张卡片功能的开发同学已工作在其他卡片上，没有办法及时修复该缺陷，或者修复该缺陷的或许是其他开发人员，那么就需要将缺陷记录下来便于跟踪。
 
2.2 工具
 
在选择缺陷记录工具的时候，要考虑以下几点：
 
该工具是否支持协同工作？
 缺陷和故事卡一样重要，是各个角色都需要关心的事情，即意味着各个角色都需要能够查看、操作缺陷记录工具，所以缺陷记录工具需要支持协同工作。
该工具是否容易学习？
 基于第一点，团队成员均需要操作该工具，不管是否有技术背景，所以该工具一定是需要学习成本较低的。
该工具是否易于跟踪缺陷状态？
 缺陷和故事卡一样，是存在流转状态的，也会有不同的人员工作在该缺陷上（开发人员、测试人员），所以记录工具最好具有状态流转标识，当然你也可以手动记录其状态，但能让工具帮你做的事情为什么不利用工具呢？
该工具是否清晰记录缺陷？
 下一小节会讲到缺陷记录的要素，选择的工具需要能清晰表达这些要素。
该工具是否便于统计？
 缺陷管理中很重要的一部分是缺陷分析，缺陷分析当然是基于数据的，这些数据可以手动收集，如果工具能自动帮你做一些统计那是最好的。
 
所选择的工具不一定需要具备以上提到的所有特征，但是支持协同工作和清晰记录缺陷是必不可少的，其余特征可根据项目情况而定。
 
博主所在的项目选择的工具是jira，jira是一款协同办公软件，在敏捷项目中通常被用来记录故事卡。它支持协同办公，而且我们项目也使用jira记录故事卡，我们在故事卡的泳道下面新建了一个跟踪缺陷卡的泳道，一个缺陷记录一张卡片，这样大家就可以像操作故事卡一样操作缺陷卡。它也支持添加自定义标签的，标注卡片优先级，添加附件，充分满足缺陷关联的内容。它也支持导出卡片数据，对之后的缺陷分析十分有帮助。博主也推荐使用trello，和jira的功能大同小异，当然在线wps的excel也是不错的选择。
 
使用jira记录缺陷，主要是为了便于查看缺陷状态，但会随着迭代的完成，缺陷卡片会被归档，每张卡片也是独立的，不利于集中查看和查询。这样的流转方式对迭代内缺陷是没有问题的，因为迭代内缺陷一旦修复，后续基本不会有人再去查看关注。但对生产缺陷却不一样，每一个生产缺陷都应该被认真对待分析，我们可以将其统一记录在某个地方，用于之后回顾。博主项目组的做法是将生产缺陷统一记录在confluence，便于集中查看。
 
2.3 模版
 
记录缺陷有两个原则：
 
描述完整，清晰易读懂
 记录的缺陷卡和故事卡一样，需要给团队成员看，所以缺陷卡需要描述完整清晰。
规范化，便于缺陷分析
 分析统计总是基于规划的数据结构，所以在记录缺陷的时候就需要考虑之后缺陷分析需要什么，以此去规范户记录缺陷。
 
以博主的项目为例，我们记录缺陷的模版主要有以下要素：
 
标题
 简述缺陷内容，清晰明了。
描述
 缺陷发生环境（DEV/ST/UAT/PRD），相关测试数据（用户名/订单号等），复现步骤，期望结果，实际结果，备注（截图、日志等）。
优先级
 在卡片上（jira/trello）备注缺陷的优先级，可以是高、中、低，可以自定义。
标签
 便于之后的缺陷分析，可以给缺陷打上标签。以博主项目为例，针对生产缺陷，会标注以下标签：所属功能模块（根据系统自定义）、可识别阶段（需求阶段/开发阶段/测试阶段/难以识别）、缺陷类型（功能/性能/安全）、影响范围（大/中/小）。
 
3 缺陷流转
 
每个缺陷也应该像故事卡一样，有它完整的生命周期，本节以博主项目组为例详解迭代内缺陷和生产缺陷的流转过程，当然每个组情况不一样，读者可视自身项目组情况而定。
 
3.1 迭代内缺陷流转过程
 
上文讲到，迭代内缺陷和故事卡记录在同一jira面板的不同泳道，那么缺陷卡的生命周期和故事卡自然是一样的，如下图所示：
 
 
针对迭代内的缺陷应该在什么时候修复，我们的处理原则有以下几点：
 
如果是阻碍开发/测试进度的缺陷，应该被立即修复；
如果是本迭代必须交付的功能相关缺陷，且修复成本高或影响范围大的缺陷，应该被立即修复；
如果是本迭代必须交付的功能相关缺陷，但修复成本或影响范围较小的缺陷，留到迭代后期修复。
 
3.2 生产缺陷流转过程
 
生产缺陷总是值得被引起重视的，我们对其处理流程如下图所示：
 
 
4 缺陷分析
 
敏捷测试原则说我们应该预防缺陷而不是关注缺陷的数量，所以对于缺陷分析，我们的出发点是：对已发生的缺陷进行深入分析，从中找到问题所在，以达到预防缺陷的目的。
 
4.1 分析周期
 
迭代内缺陷的数量比较多，而且一般大多数都是开发逻辑错误造成的，一般而言分析价值不大。如果每个迭代平稳运行，缺陷数量平稳，建议不用特意分析，毕竟分析缺陷是耗时的。如果某个迭代明显感觉缺陷数量增长，可以针对性对本迭代缺陷进行分析。当然，如果你有充分的时间，可以将缺陷分析作为一项日常工作。而对于生产缺陷，每一个都值得被重视。3.2节讲述的流转过程，其中我们就已经对其进行分析了，分析其问题出在哪儿，然后补充相应的测试。如果想要对生产缺陷进行归类、趋势分析，那么就需要有一定的数据才可以，而生产缺陷不常有。所以其分析周期建议是1个月，或者3个月，甚至6个月，视各个项目组的情况而定。
 
4.2 分析角度
 
我们项目组常用的分析角度有以下几个，不同的项目侧重点会有所不同。
 （1）缺陷根因
 可以将缺陷一一分析后进行归类，根因可以分类为：需求缺失或者不清晰、技术方案设计问题、代码逻辑错误、测试未覆盖、环境相关（硬件、软件、第三方等）。分类后如果某一类问题较突出，则可以针对性产出改进事项。
 （2）缺陷发现阶段
 缺陷发现阶段可以归类为：故事验收阶段、功能测试阶段、回归测试阶段。我们知道缺陷越早发现修复成本越低，如果分析后发现某一阶段出现的缺陷较多，应该去反思是哪个环节错了，我们是否可以更早的暴露缺陷。
 （3）缺陷所属功能模块
 功能所属模块根据系统不同而不同，这一类分析帮助我们思考，某一块存在的缺陷多是因为存在技术债还是测试覆盖不够，可以帮助我们改进质量策略。
 （4）缺陷数量趋势
 如果可以，对于迭代内缺陷可以维护一份数量趋势图，就不需要我们靠直觉去感受哪个迭代缺陷多，而是有真实的数据作为依据，更具说服力。对于生产缺陷，建议可以维护一份数量趋势图，因为生产缺陷数量走势也是反应我们产品质量的一个重要维度。
 （5）缺陷可识别阶段
 这一分类主要针对生产缺陷，缺陷可识别阶段可以归类为：需求分析阶段、开发阶段、测试阶段、发布阶段，难以识别。这样分类的初衷不在于归过于某一角色，某一人，而是为了进一步分析是哪一阶段的实践有缺失，需要进一步改善。
 （6）缺陷类型
 缺陷类型可以归类为：功能缺陷，性能缺陷，安全缺陷。敏捷项目QA需要关注产品各个方面的质量，包括性能、安全等，将缺陷类型划分清楚，可以指导我们补充我们薄弱的地方。
 
4.3 分析工具
 
数据有了，就需要将数据可视化出来，便于分析，便于展示给团队。博主曾使用过的可视化工具有：
 
jira
 jira根据卡片自动生成图标，饼图、趋势图都可以，但好像只有企业定制版才可以。
ppt
 将jira数据导出，然后导入ppt画图。只要记录的缺陷卡片规范，也不是很费时，但没办法展示趋势，只能展示导出阶段的数据。
tableau
 可以画各种图，对于展示趋势图也很方便，但是一款商业工具，而且上手成本并不低，它主要的功能是进行数据分析，画图只是它的九牛一毛，用它做缺陷分析有点大材小用的意思了。
 
所以呢，其实我也没有特别好的工具推荐，大家如果有更好的，欢迎交流呀。

 
 
什么是软件质量
 
软件的质量就是软件的生命，为了保证软件的质量，人们在长期的开发过程中积累了许多经验并形成了许多行之有效的方法。但是借助这些方法，我们只能尽量减少软件中的错误和不足，却不能完全避免所有的错误。
 
如果把所开发出来的软件看作一个企业生产的产品，那么软件测试就相当于该企业的质量检测部分。简单地说，我们在编写完一段代码之后，检查其是否如我们所预期的那样运行，这个活动就可以看作是一种软件测试工作。新的测试理论、测试方法、测试技术手段在不断涌出，软件测试机构和组织也在迅速产生和发展，由此软件测试技术职业也同步完善和健全起来。
 
什么是软件缺陷
 
软件缺陷（Defect），常常又被叫做Bug。从产品内部看，缺陷
 
是软件产品开发或维护过程中存在的错误、毛病等各种问题；
 
从产品外部看，缺陷是系统所需要实现的某种功能的失效或违
 
背。在软件开发生命周期的后期，修复检测到的软件错误的成
 
本较高。
 
对于软件缺陷的准确定义，通常有以下5条描述：
 
（1）软件未实现产品说明书要求的功能。
 
（2）软件出现了产品说明书指明不会出现的错误。
 
（3）软件超出实现了产品说明书提到的功能。
 
（4）软件未实现产品说明书虽未明确指出但应该实现的目
 
          标。
 
（5）软件难以理解，不易使用，运行缓慢或者终端用户认
 
          为不好
 
缺陷的分类
 
1.缺陷（defect）产品设计与需求设计部符合
 
2.错误（error）没有定义的或者未知的错误信息
 
3.故障（fault）由于一些原因导致产品失效，重新启动调整后可以恢复用户使用
 
4.失效（failure）由于一些原因产品失效，无法自行恢复
 
bug管理的目的
 
1.保证每个缺陷都被修改
 
2.保证每个缺陷都被回归
 
3.缺陷的完整性和一致性
 
4.避免纠纷，降低沟通成本
 
缺陷管理的意义
 
1.提高工作效率（BUG分类，状态负责人）
 
2.记录唯一的缺陷信息，保证BUG完整一致（通过设置权限实现）
 
3.记录中间环节，是BUG可追溯
 
4.为测试报告提供数据
 
参与缺陷管理的角色
 
测试工程师：发现和回归BUG
 
测试经理：判断BUG的有效性
 
开发经理：分配BUG
 
开发工程师：修改BUG
 
评审：解决矛盾
 
缺陷报告的要点
 
发现了软件缺陷，需要记录下来，不但要记录结果，同时需要详细描述发现的步骤，以备程序员重现问题，并解决它。
 
要求报告写的清楚明了和准确。有时利用截屏技术把当时的情况保存成图片，可以达到一图胜千言的效果。 
 
软件缺陷的种类
 
软件缺陷表现的形式有多种，不仅仅体现在功能的失效方面，还体现在其他方面。软件缺陷的主要类型有：
 
1、功能、特性没有实现或部分实现。
 
2、设计不合理，存在缺陷。
 
3、实际结果和预期结果不一致。
 
4、运行出错，包括运行中断、系统崩溃、界面混乱。
 
5、数据结果不正确、精度不够。
 
用户不能接受的其他问题，如存取时间过长、界面不美观。
 
缺陷来源
 
1.Requirement：由于需求的问题引起的缺陷(需求不完全或逻辑错误)
 
2.Architecture：由于构架的问题引起的缺陷（登录session失效）
 
3.Design：由于设计的问题引起的缺陷（图片大小，页面元素显示问题等
 
4.Code：由于编码的问题引起的缺陷
 
5.Test：由于测试的问题引起的缺陷（软件测试的设计与实施发生错误。特别是系统级的功能测试，要求复杂的测试环境和数据库支持，还需要对测试进行脚本编写。因此软件测试自身也可能发生错误。另外，如果测试人员对系统缺乏了解，或对规格说明书做了错误的解释，也会发生许多错误。）
 
6.Integration：由于集成的问题引起的缺陷
 
缺陷分析主要参数
 
状态：缺陷的当前状态（打开的、正在修复或关闭的等）。

 
优先级：必须处理和解决缺陷的相对重要性。
 
严重性：缺陷的相关影响。对最终用户、组织或第三方的影响等等。
 
起源：导致缺陷的起源故障及其位置，或排除该缺陷需要修复的构件
 
缺陷状态
 
1.New：测试人员提交Bug
 
2.Open：确认“提交的Bug”等待处理
 
3.Assigned：相关人员分配Bug
 
4.Fixed：缺陷被修复
 
5.Closed：确认缺陷被修复，关闭缺陷
 
6.Reopen：缺陷被修复后，重新开启
 
7.Reject：Bug描述不清晰，被拒绝
 
8.Invalid：确认不是Bug，无需修复
 
9.Later：可以以后修改，但要明确日期
 
10.Postpone：延迟修改，未明确日期
 
11.Wontfix：被发现的Bug无法修改
 
12.Duplicate：重复的Bug
 
13.Abandon：被reject，invalid，duplicate后的Bug经测试人员确认没有问题，修改为该状态
 
14.Renew：被reject，invalid，duplicate后的Bug经测试人员确认Bug有效，修改为该状态
 
15.Typical：多次出现，具有代表性，可以提醒其他人注意
 
16.Remind：由于功能的变动，Bug无法验证，修改为此状态
 
缺陷优先级
 
按优先级别分类：P1----P5(同意 BUG可能会变)
 
缺陷的严重性分类
 
blocker阻碍的（不修改该BUG之后的开发测试无法执行）
 
Critical崩溃（系统部能用）  
 
major严重的（严重影响功能使用流程）  
 
anormal一般的（不会影响主要的功能流程）  
 
minor轻微的（不会2影响业务流程也不影响使用）  
 
trvival界面的 
 
suggestion建议（可用性，易用性，侧重用户体验）
 
缺陷管理流程图
 

 
测试工程师（2个）
 
      New
 
      Fixed->Reopen
 
      Fixed->Closed
 
测试经理（1个）
 
      New->Open
 
      New->Abandon
 
开发工程师（2个）
 
      Open->Fixed
 
      Reopen->Fixed
 
      Assign->Fixed
 
开发经理（1个）
 
      Open->Postpone
 
      Postpone->Assign
 
      Open->Assign
 

 

 

 

 
缺陷分析报告
 
1、可以将缺陷计数作为时间的函数来报告，即创建缺陷趋势图或报告；
 
2、也可以将缺陷计数作为一个或多个缺陷参数的函数来报告，如作为缺陷密度报告中采用的严重性或状态参数的函数。
 
3、这些分析类型分别为揭示软件可靠性的缺陷趋势或缺陷分布提供了判断依据
 
BUG单写作准则（5C）
 
correct(准确)每个组成部分的描述准确，不会引起误解
 
clear(清晰)每个组成部分的描述清晰，易于理解
 
concise(简洁)只包含必不可少的信息，不包括任何多余的内容
 
complete(完整) 包含复现改缺陷的完整步骤和其他本质信息
 
consistent(一致)按照一致的格式书写全部缺陷报告
 

 
BUG描述的注意事项
 
1一定可以重现的BUG可以不写“重复几次操作，出现几次，我认为，标题里不能写步骤，不能用主观的话描述，我在。。。。的，不确定语句：某些好像，禁止使用”之后”，然后之类的语句”之类的话
 
2需求规格说明书以外的错误可以当建议报告，不当BUG报告，开发可以改，也可以不改
 
3若是随机出现的BUG，要写出操作几次，出现几次
 
4若被测软件是跨平台软件，要写上在其他平台下无误
 
5禁止写冗余的操作的步骤。常识性的步骤不用写进缺陷操作步骤
 
6写明环境数据，如何选择数据，数据如何被破坏