缺陷报告详解（一）：
一、缺陷报告的要点
1）标题
2）描述：简洁、准确、完整、反映缺陷本质
3）重现步骤
4）严重程度
5）优先级
6）截图
7）编号
8）指派人
二、“5C”原则
资料准确（Correct）：每个组成部分的描述准确，不会引起误解
步骤简洁（Concise）：只包含必不可少的信息，不包括任何剩余的资料
资料清晰（Clear）：每个组成部分的描述清晰，易于理解
结构完整（Complete）：包含复现该缺陷的完整步骤和其他本质信息
风格一致（Consistent）：按照一致的格式书写全部缺陷报告
三、二八定理
在分析、设计、实现阶段的复审和测试工作能够发现和避免80%的缺陷，而系统测试又能找出 其余缺陷中的80%，最终的4%的缺陷可能仅有在用户大范围、长时光使用后才会暴露出来。
四、缺陷报告的组成
1、缺陷编号（Defect ID）：提交缺陷的顺序
2、缺陷的标题（summary）：简明扼要的描述缺陷
3、缺陷的发现者（Defected By）：测试人员
4、缺陷发现的日期（date）：一般为当天
5、缺陷所属的模块（subject）：在测试那个功能模块时发现的bug
6、发现缺陷的版本（Defected in release）：开发的软件的版本
7、指派给谁处理（Assigned to）：测试人员指派给开发经理，开发经理根据缺陷所在的模块，需要再次指派具体的开发人员
8、缺陷的状态（status）：缺陷此时所处的处理阶段或处理情景
（1）测试人员发现缺陷，提交缺陷报告，把缺陷的状态置为new（新）
（2）开发经理验证提交的bug，如果是bug，把状态改为open（打开的bug，开发组承认的bug），指派给具体的开发人员解决；如果不是bug，把状态改为rejected（拒绝的bug）
（3）开发人员看到指派给自我解决的bug，进行缺陷修复，修改完后，把缺陷状态fixed（已经修复的bug，能够返测的bug）
（4）测试人员对修复的bug进行反测，若返测成功，将状态改为closed（关掉的缺陷，归档的bug）；如果返测不成功，把状态改为reopen（重新打开的bug）
五、缺陷报告的深度理解
1、缺陷的严重程度和优先级是不是成正比关系？
界面问题的严重程度一般比较低，担优先级可能很高————立即修复
某些重大的功能问题可能暂时解决不了，但不影响其他功能的使用，这时优先级可能定义的比较低————在发布之前修复
2、缺陷的严重程度和优先级确定好后，还能修改吗？
严重成度不允许改，优先级可能修复。
测试人员确定一个缺陷“立即修复”，但开发组认为这个缺陷不好解决，而这个缺陷又不影响其他功能，这时可能要求在“下一个版本修改”或“发布之前修改”
3、是不是所有一发现的缺陷都会被修复？
有些缺陷修复的成本太高或者由于进度压力可能在发布前得不到修复，这样的缺陷必须要经过项目组的讨论，权衡成本和风险，要确保不会对用户在成重大的影响及法律纠纷。后面再经过升级软件或者打补丁的方式修复缺陷或弥补漏洞
六、缺陷报告的作用
1、记录bug
2、对bug进行分类（模块、bug状态、严重程度、版本）
3、跟踪bug
4、对bug进行分析、统计
缺陷报告详解（二）：
1、标题
应坚持简短、准确，供给缺陷的本质信息，尽量按缺陷发生的原因与结果的方式书写;避免使用模糊不清的词语，例如：“功能中断，功能不正确，行为不起作用”等。应当使用具体文字说明缺陷的症状;为了便于他人理解，避免使用俚语或过分具体的测试细节。
2、复现步骤
应包含如何使别人能够很容易的复现该缺陷的完整步骤。
为了到达这个要求，复现步骤的信息必须是完整的、准确的、简明的、可复现的。
常见问题：
·包含了过多的剩余步骤，且句子结构混乱，可读性差，难以理解;
·包含的信息过少，丢失了操作的必要步骤。
复现步骤的正确书写方式：
·供给测试的环境信息;
·简单地一步步引导复现该缺陷，一个步骤包含的操作不要多;
·每个步骤前使用数字对步骤编号;
·尽量使用短语或短句，避免复杂句型句式;
·复现的步骤要完整、准确、简短;将常见步骤合并为较少步骤;按实际需要决定是否包含步骤执行后的结果。
3、实际结果
实际结果是执行复现步骤后软件的现象和产生的行为。实际结果的描述应像标题信息那样，要列出具体的缺陷症状，而不是简单地指出“不正确”或“不起作用”。
4、期望结果
描述应与实际结果的描述方式相同。通常需要列出期望的结果是什么。
附件：
对缺陷描述的补充说明，能够是以下一些类型：
缺陷症状的截图;测试使用的数据文件;166 199 188。
5、其它：
选择适宜的缺陷严重性属性;按相应的规定，填写相应的字段信息。
缺陷报告详解（三）：
尊敬的领导:
我十分荣幸能够向您汇报我们团队在缺陷维修方面的工作情景。我们团队一向致力于不断提升工作质量和效率，以便能够更好地满足客户需求。以下是我们过去一段时光的工作情景：
一、工作目标
为了提升缺陷维修的工作效率，我们制定了以下工作目标：
1. 优化维修流程，提高维修效率。
2. 提高缺陷维修的准确率和质量。
3. 培养和提高员工维修本事和素质。
二、工作资料
1. 优化维修流程
我们对团队中的维修流程进行了全面的审查，并制定了相应的优化方案。经过优化，我们缩短了缺陷维修的处理时光，提高了维修效率，同时还减少了维修成本。
2. 提高维修准确率和质量
我们对缺陷维修时的服务流程进行了全面的审查，并制定了相应的完善措施，以提高维修准确率和质量。我们为员工供给了必要的培训和技能提高，鼓励员工树立正确的服务态度，增强他们的服务职责感和使命感。经过这些措施，我们已经成功提高了维修准确率和质量，让客户对我们的服务更加满意。
3. 培养和提高员工维修本事和素质
我们注重培养和提高员工的维修本事和素质，促进他们的职业发展，提高团队整体素质。我们为员工供给了完善的培训课程和技能提高，并经过不断追求提高和创新来提高维修流程，提高员工素质。这些措施为员工的个人发展供给了更多的机会和支持，同时也让团队整体更具竞争力。
三、取得成果
经过我们的奋力，我们已经取得了以下成果：
1. 工作效率大幅提高：经过优化后，我们的维修速度得到了大幅提升，对客户和公司都带来了经济效益。
2. 维修准确率和质量有了明显的提高：我们的员工已经对缺陷维修的流程有了更深入的了解，能够更加准确地确定和解决问题，保证了客户的需求得到满足。
3. 员工素质有了显著提高：我们的员工拥有更高的工作热情和职责感，工作态度更加优秀，团队整体素质得到了提高。
四、后续工作
我们将继续奋力，在以后的工作中，持续优化维修流程、提高维修效率和质量，培养和提高员工的维修本事和素质，更好地为客户供给优质服务，实现公司的发展目标。
在此，我代表整个团队向您汇报我们的工作，并向您表示诚挚的感激和敬意。感谢！
此致
敬礼！
报告人：XXX
XXXX年XX月XX日
缺陷报告详解（四）：
一、项目测试的基本流程（步骤）：
1、熟悉需求。
2、编写、阅读《测试计划》
说明：编写《测试计划》一般由测试组长或经理完成
测试人员要阅读并且执行《测试计划》
3、设计测试（编写《测试用例》）
4、执行测试（执行测试用例），并且要记录执行结果
5、记录缺陷结果（缺陷报告），跟踪、管理缺陷
6、测试总结（总结报告）
二、缺陷报告
1、什么是缺陷报告
测试人员发现缺陷，经过缺陷报告记录缺陷将缺陷报告提交给开发方，并跟踪和管理缺陷。缺陷报告是测试人员和开发人员之间重要的沟通工具。
2、缺陷报告如何编写
说明：在企业中为了提高缺陷的管理效率和质量通常会使用管理工具，例如：qc，禅道，bugzilla等，不一样企业使用工具不一样，缺陷管理可能会有差异，可是大同小异。
1）缺陷报告的主要组成：
（1）缺陷编号（defect id）
记录发现缺陷的顺序号，能够经过编号唯一标识每条缺陷。
缺陷的编号是以项目为单位进行的。
在测试管理中，缺陷编号通常是自动生成的。
（2）缺陷标题（summary）
简明扼要的描述该缺陷。（概括）
（3）缺陷发现者（detected by）
就是发现缺陷的测试人员自我。
通常在测试管理工具中会默认当前系统的登录用户
（4）指派给谁（assigned to）
首先测试人员将缺陷报告指派给开发方的负责人（开发经理）
然后再由开发经理将缺陷报告指派给相应的开发人员负责解决缺陷。
（5）提交缺陷的日期（detected on date）
发现缺陷，确认之后，要及时的将缺陷提交给开发方。
在测试管理工具中通常会自动将系统时光默认填入该项。
（6）发现缺陷的功能模块（subject）
方便开发经理确认该缺陷由哪个开发人员负责
能够协助开发人员定位缺陷
（7）缺陷所属的版本（detected in releaseversion）
说明：那里所指的版本不仅仅是最终发布的版本，也包括在软件开发过程中构成的临时版本。
版本的制定不是由测试人员完成的。（通常公司里是产品部门完成）
回归测试：在新版本中对上一个版本中测过的功能重新再测试一遍。
为什么要做回归测试：
1）修改的缺陷有可能会对原有功能带来新的问题
2）新增加的功能有可能会给原有功能带来新的缺陷
在企业中，往往会使用自动化工具来完成回归测试，提高测试效率。
（8）缺陷的状态（status）
描述缺陷当前的情景。
缺陷的处理过程
步骤1：测试人员填写缺陷报告，提交给开发经理，此时状态为：new（新的缺陷）
步骤2：开发经理要验证缺陷，
情景1：缺陷验证经过，开发经理会激活缺陷，并将缺陷指派给相应的开发人员。此时状态为：open（打开激活的缺陷，被开发方承认的缺陷）
情景2：缺陷验证没有经过，开发方会拒绝该缺陷。此时缺陷状态为：rejected（被拒绝的缺陷）
扩展：被拒绝后测试人员首先要确认是否是由于操作或配置错误造成的假缺陷，然后如果是由于对于需求理解不一样造成的能够跟产品部门沟通确认，最终如果是开发方不能重现该缺陷，要尽量沟通、配合重现。
如果还不能确定再去跟测试部门领导沟通反馈问题。经过上述过程如果最终确认是假缺陷，那么由测试人员或组长关掉该假缺陷；如果最终确认是缺陷，那么谁拒绝的谁负责激活，继续完成缺陷处理流程。
步骤3：开发人员负责解决指派给他的缺陷。解决后将缺陷状态设置为：fixed（解决的缺陷，待返测的缺陷）
步骤4：测试人员返测解决的缺陷，
情景1：如果返测经过，测试人员将缺陷关掉。此时状态为：closed（关掉的缺陷，可归档的缺陷）
情景2：如果返测没有经过，测试人员要将缺陷重新激活，此时设置缺陷状态为：reopen（重新激活的缺陷），开发人员继续修改缺陷，修改后再次将缺陷状态设置为：fixed，测试人员再次返测，直到缺陷解决被关掉为止。
问题：缺陷的处理流程
用状态来表示
1、缺陷的基本处理过程
New-->open-->fixed-->closed
2、带有返测失败（1次）的缺陷处理过程
New-->open-->fixed-->reopen-->fixed-->closed
3、被拒绝的缺陷的处理过程
1)假缺陷
New-->rejected-->closed
2)是缺陷
New-->rejected-->open-->fixed-->closed
(9)缺陷的严重程度（severity）
指明缺陷有多糟糕或对程序的影响有多大
缺陷的严重级别的分级定义（以qc为例）：
Urgent：致命的缺陷，例如造成计算机死机，系统崩溃等
Very high：十分严重的缺陷
High：严重的缺陷
Medium：一般的（中等的）缺陷
Low：提示、提议类的缺陷（小问题）
发现问题：缺陷的严重级别的定义是笼统的，在实践中容易造成冲突，所以企业针对每个严重级别制定了详细的说明。工作中要注意参考。（不一样公司或者不一样项目使用的缺陷严重级别定义文档都会不一样）
（10）缺陷的优先级（priority）
期望或提议开发方在什么时候或什么版本解决该缺陷
优先级的级别定义：
Urgent：需要开发人员放下手头的开发任务立即解决的缺陷（通常是不解决会影响整个开发和测试进度的）
Very high：在当前版本内解决
High：在下一个版本中解决（常用）
Medium：在软件发布之前解决
Low：尽量在软件发布之前解决（有可能在软件发布时带有没有解决的bug）
说明：不一样企业，不一样项目组对于软件优先级的定义会不一样，工作中要注意参考。
关于缺陷的严重程度和优先级问题：
1）影响缺陷优先级定义的因素有哪些？
（1）缺陷的严重程度—一般越严重缺陷的优先级越高（有时也会有严重程度低而优先级高的情景）
（2）缺陷影响的范围—影响范围越大，优先级越高
（3）开发人员的开发压力—开发压力越小，解决缺陷的优先级越高
（4）解决缺陷的成本（时光）--成本越低，解决缺陷的优先级越高
2）缺陷的严重程度和优先级是严格的正比关系吗？
不是严格的成正比关系，例如：界面的错误别字，严重程度低，可是优先级高
3）缺陷的严重程度和优先级确定之后能够修改吗？
缺陷的严重程度确定好后一般不改
缺陷的优先级能够修改，并且常常是拖延处理（delay）
4）是否有未解决的缺陷在软件发布版本中存在?
有可能会有发现的但没有解决的缺陷在发布的软件版本中存在。
这类缺陷需要开bug讨论会，讨论投入和风险，权衡利弊后，才能决定。
企业能够经过打补丁或者升级版本的方式在后续将此类缺陷解决。
(11)缺陷描述（description）
说明：将发现缺陷的过程、数据记录下来，让开发人员能够再现该缺陷（就是让开发人员能明白并再现这个缺陷）
缺陷报告详解（五）：
一个高质量缺陷报告要具备哪些要素？大部分测试人员将缺陷报告的目的理解为供给信息，然而一个“好的”或有价值的缺陷报告更进一步，是以高效的方式供给有用的信息。
为了帮忙我们开始编写有价值的缺陷报告，我们先来看一些关键字段：
标题
执行动作（步骤）
预期与实际结果
标题：好、不好、糟糕
缺陷标题是你报告的脸。它是任何人第一眼就会看到的，重要性无需强调。一个好标题能够帮忙减少重复问题，并且能够快速证明缺陷的概要信息。
在标题中最好避免笼统的描述。永久不要采用如下例子：
XYX运行不正确
XYZ有问题
XYZ损坏看起来不正常
上述示例标题在描述问题时根本没有价值。本质上来说，每个缺陷报告都在描述不正常运行的问题。应当明确什么导致了“运行不正常”。
“排序功能没有正常工作”能够改成“排序发生逆转”
“导航条界面出现问题”能够改成“导航条跑到了第二行”
很多时候，Bug（缺陷）会被迁移到可能包含数百甚至数千问题的开发者数据库中。试想象在数据库中搜索“导航栏”，会搜出关于导航栏的每一个问题，而搜索“导航栏跑到了第二行”就能够更有针对性地轻易找出这个缺陷。在当前的测试周期中，一个精悍的标题能够使你的缺陷报告变得更具价值。
执行动作：描述所执行的步骤
这是报告的主体部分，它的目的在于向读者展示如何重现缺陷。由于这部分通常包含缺陷报告最多信息，所以使它简单明了易读是异常重要的。通常能够为步骤编号并保证其简短扼要。
提示：使用前置条件能够减少步骤。
与其列出登录时的每个步骤，不如在步骤前写上“前置条件：用户已登录”。
提示：找出并列上缺陷的直接路径。
很多时候，测试人员会止于他们发现缺陷的位置，并记录最终执行的寥寥几步。然而，那些提取到核心重现步骤的缺陷报告才是最有帮忙性的。按照你所叙述的步骤来重现缺陷，是一个很好的练习。这将有助于确保你已经包含了让客户重现该问题的所需的所有资料。有时缺陷挖掘更深一点，能够附加更多价值。下头是一些关于如何更奋力更具思想地编写出一份更高质量的报告的子。
例1：供给更多的有用的信息
情景：你发现视频不能正确上传。
一般：注明是否所有的视频不能上传，或只是报告中所提及的这个。
良好：在报告里指出是否在多个浏览器上或设备上不能正确上传。
更好：附上上传速度测试，以证明测试的时候带宽是足够的。
教训：尝试在客户询问前，识别并回答可能的后续问题。
例2：报告缺陷，并不是报告缺陷的症状
情景：我们测试地址输入栏，发现它允许“1234567890”和“!@#$%^&*_+”
教训：这是同一个缺陷两种不一样的症状。仔细检查会发现真正的问题是地址栏根本没有做校验，这个问题会比第一种症状描述更加确切。
预期结果：实际结果、可能产生的结果
既然你已经描述了如何重现这个缺陷，此刻你需要说明这个问题和期望表现。
提示：当你描述期望结果时，说明应当发生什么而不是说明什么不应当发生。
用“用户被带到XYZ界面上”代替“应用程序不应当崩溃”
提示：当你描述实际结果时，应当描述发生了什么而不是什么没有发生。
用“用户依然停留在ABC界面上”代替“用户没有到达XYZ界面”
附件：做什么、不做什么
附件经过供给一些缺陷存在的证据，从而增加缺陷的价值，使客户能重现缺陷，或帮忙开发修复缺陷。每个附件至少是以下三种方式之一。
添加来锁定缺陷是一个快速的方式，即使你有视频也要研究添加。
在里高亮显示你所关注的区域。
直接把添加到缺陷报告中，不要把放到一个word文档中或者压缩文件中。
使用来展示静态问题
视频
视频能保证缺陷出现时执行步骤的准确性，例如，错误信息的屏幕截图不如直接看 到是什么造成的错误信息有价值。
视频中的执行步骤应当和缺陷报告里面写的执行步骤一致。
视频应当精简到只展现缺陷。
当执行步骤复杂时供给视频附件。
现场的视频比镜像的视频更加有效，因为你能够看到手势或者在屏幕上触摸一个按钮
日志文件和其他提示
避免专有的文件类型（像.docx），尽量用.txt文档来代替
避免使用压缩文件，除非特殊要求或者已经由测试leader、客户、项目经理同意。