缺陷和缺陷报告
一 缺陷的基本概述
-
缺陷的定义
-
软件未实现产品说明书要求的功能
-
软件出现了产品说明书指明不应该出现的功能
-
软件实现了产品说明书中未提到的功能
-
软件未实现产品说明书虽未明确提及但应该实现的目标
-
软件难以理解、不易使用、运行缓慢或者（从测试的角度看）最终用户认为不好
-
注意：需求分析、设计阶段，文档类型的缺陷多；集成测试阶段，一般接口类型的缺陷多；系统测试阶段，功能、界面类型的缺陷多。验收测试阶段，更多的关注性能缺陷；实施过程，可能会遇到一些软件包的缺陷。
注意：结合缺陷的影响，结合软件的具体功能（业务或者流程）
注意：优先级的衡量，一般可以根据测试测试的软件系统的全业务流程划分，软件的基本功能的缺陷，优先级高，甚至需要立即解决。软件的备选流、基本功能测试中的反向测试的内容，优先级较低，甚至有些可改可不改
二 缺陷的生命周期
-
发现缺陷。由测试人员。开发也能知道自己哪里写错了，但不会广而告之
-
提交缺陷。由测试人员。开发更不可能提交bug
-
确认缺陷。一般由测试主管、或质量保证（QA）、由产品经理进行确认
-
分配缺陷。经确认后，有效的缺陷会指派给相关人员进行处理。一般由谁确认的缺陷，就由谁分配。分配的对象可能是开发、也可能是UI、也可可能是产品经理
-
修复缺陷。主要由开发修复，也有可能是产品经理修复问题，也有可能是UI修复问题
-
验证缺陷。测试去验证缺陷有没有修复成功
-
关闭缺陷。只能说测试人员进行。否则出了问题，测试人员一律不背锅
三 缺陷的识别
依据：需求文档、设计文档、产品原型、测试用例，都是客观的依据
同行业的类似成熟软件，和开发人员沟通，跟有经验的测试人员沟通，同行业隐形需求，都是带有主主观色彩的依据
四 缺陷报告
缺陷报告的填写目的：
-
展现缺陷的详细信息
-
展现缺陷的影响程度和方式
由于缺陷报告的读者很多：开发、质量管理、市场人员、运维人员
所以缺陷报告要写的很直白、清晰、明了
报告编写的准则：准确、清晰、一致、简洁、完整
缺陷描述的准则：单一准确、可以再现（针对大多数的缺陷都是如此。但是由一些小部分的缺陷是难以做到<类似闪退、崩溃这种不可再现的缺陷，无需做到。针对一些可以重复出现的闪退缺陷，也要进行步骤的详细描述>）、完整统一、短小简练、特定条件、补充完善、不做评价（不对缺陷的出现的严重成都和缺陷表现出来的效果进行主观臆断）
缺陷报告本身要保证没有任何表述性的错误
测试需求和测试用例、缺陷报告的关系？
测试的基本流程：获取测试需求——编写测试计划——制定测试方案——设计和开发测试用例——执行测试——提交缺陷——测试分析和评审——测试总结——准备下一版本的测试
获取测试需求是测试工作的重点，也是第一步。通过需求的分析，了解和掌握测试方向和内容。例如：
-
分析出系统的模块和组织结构
-
分析出软件的基本功能和运行流程。（业务分析）包括可能会有哪些人或者哪些角色要用
-
识别出软件的重要功能和次要功能
获取测试需求的过程中，测试人员就要哟见相应的分析成果。一般用xmind这样的思维导图工具进行分析，或者使用需求跟踪矩阵来完成测试需求的获取和分析
测试设定中需求的正、反向，和优先级。
当有了测试需求之后，就开始针对每一个需求点进行测试用例的设计。也就是，每一个需求点，都要被测试。
因此测试的过程中，衡量需求的覆盖程度，就非常重要。使用：
需求的覆盖程度=被测试用例覆盖的需求数/需求点总数
进行计算和说明。
如果需求覆盖度<100％，那一定说明了测试的覆盖度不够。
