1.什么是缺陷报告，缺陷报告的作用，缺陷报告的要点
(1)缺陷报告是描述软件缺陷现象和重现步骤的集合。软件缺陷报告 Software Bug Report(SBR)或软件问题报告 software Problem Report(SPR)。
(2)缺陷报告是软件测试人员的工作成果之一，体现软件测试的价值缺陷报告可以把软件存在的缺陷准确的描述出来，便于开发人员修正缺陷报告可以反映项目/产品当前的质量状态，便于项目整体进度和质量控制软件测试缺陷报告是软件测试的输出成果之一，可以衡量测试人员的工作能力。
(3)标题(Title)简洁、准确、完整、反映缺陷本质、方便查询前缀+标题正文，标题正文采用结果和动作，或者现象和位置的方式表达;步骤(Steps)可复现、完整、简洁、准确按数字编号;实际结果(Actual results)准确、详细描述软件的现象和特征;期望结果(Expected results)准确、丰富、有理有据;平台(Platforms)准确;截图(Sereenshots)准确反映缺陷特征;注释(Notes)关于缺陷的辅助说明
2.软件测试缺陷报告的 5C 原则
Correct(准确)：每个组成部分的描述准确，不会引起误解;
Clear(清晰)：每个组成部分的描述清晰，易于理解;
Concise(简洁)：只包含必不可少的信息，不包括任何多余的内容;
Complete(完整)：包含复现该缺陷的完整步骤和其他本质信息;
Consistent(一致)：按照一致的格式书写全部缺陷报告。
3.软件缺陷的生命周期?
测试人员提交新的 Bug 入库，错误状态为 New。 高级测试人员验证错误，如果确认是错误，分配给相应的开发人员，设置状态为 Open。如果不是错误，则拒绝，设置为 Declined(拒绝)状态。开发人员查询状态为 Open 的 Bug，如果不是错误，则置状态为 Declined;如果是 Bug 则修复并置状态为 Fixed。不能解决的 Bug，要留下文字说明及保持 Bug 为 Open 状态。对于不能解决和延期解决的 Bug，不能由开发人员自己决定，一般要通过某种会议(评审会)通过才能认可。 测试人员查询状态为 Fixed 的 Bug，然后验证 Bug 是否已解决，如解决置 Bug 的状态为Closed，如没有解决置状态为 Reopen。
4.缺陷描述(报告单)中应该包括哪些内容?
缺陷的标题，简要描述。缺陷的类型。缺陷的详细步骤描述。缺陷的实际结果。期望结果。有的缺陷需要上传截图，日志信息。缺陷的等级。缺陷指派给开发同事。(开发主管)
5.如何提高缺陷的记录质量?
通用 UI 要统一、准确;尽量使用业界惯用的表达术语和表达方法;使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化;每条缺陷报告只包括一个缺陷;不可重现的缺陷也要报告;明确指明缺陷类型;明确指明缺陷严重等级和优先等级;描述 (Description) ，简洁、准确，完整，揭示缺陷实质，记录缺陷或缺陷出现的位置;短行之间使用自动数字序号，使用相同的字体、字号、行间距; 每一个步骤尽量只记录一个操作;确认步骤完整，准确，简短;根据缺陷，可选择是否进行图象捕捉; 检查拼写和语法缺陷;尽量使用短语和短句，避免复杂句型句式;缺陷描述内容。
6.如果一个缺陷被提交后，开发人员认为不是问题，怎么处理
a)首先，将问题提交到缺陷管理库里面进行备案。
b)然后，要获取判断的依据和标准：
v.根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确
认的直接依据;
vi.如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷;
vii.根据用户的一般使用习惯，来确认是否是缺陷;
viii.与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷;
c)合理的论述，向测试经理说明自己的判断的理由，注意客观、严谨，不掺杂个人情绪。
d)等待测试经理做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级
做出决定。
7.缺陷的优先级划分和描述
一般来说按照下面的来分，具体的是由每个公司而定。
软件缺陷有四种级别，分别为：致命的(Fatal)，严重的(Critical)，一般的(Major)，微小的(Minor)。
A 类—致命的软件缺陷(Fatal):造成系统或应用程序崩溃、死机、系统挂起，或造成数据丢失，主要功能完全丧失，导致本模块以及相关模块异常等问题。如代码错误，死循环，数据库发生死锁、与数据库连接错误或数据通讯错误，未考虑异常操作，功能错误等
B 类—严重错误的软件缺陷(critical)：系统的主要功能部分丧失、数据不能保存，系统的次要功能完全丧失。问题局限在本模块，导致模块功能失效或异常退出。如致命的错误声明，程序接口错误，数据库的表、业务规则、缺省值未加完整性等约束条件
C 类—一般错误的软件缺陷(major)：次要功能没有完全实现但不影响使用。如提示信息不太准确，或用户界面差，操作时间长，模块功能部分失效等，打印内容、格式错误，删除操作未给出提示，数据库表中有过多的空字段等
D 类—较小错误的软件缺陷(Minor):使操作者不方便或遇到麻烦，但它不影响功能过的操作和执行，如错别字、界面不规范(字体大小不统一，文字排列不整齐，可输入区域和只读区域没有明显的区分标志)，辅助说明描述不清楚
E 类- 建议问题的软件缺陷(Enhancemental)：由问题提出人对测试对象的改进意见或测试人员提出的建议
网友评论