缺陷 bug

缺陷 bug

1.软件bug的生命周期

测试人员提交新的 Bug 入库，错误状态为 New。 高级测试人员验证错误，如果确 认是错误，分配给相应的开发人员，设置状态为 Open。如果不是错误，则拒绝，设置为 Declined(拒绝)状态。 开发人员查询状态为 Open 的 Bug，如果不是错误，则置状态为 Declined；如果是 Bug 则修复并置状态Fixed。不能解决的 Bug，要留下文字说明及保持 Bug 为 Open 状态。对于不能解决和延期解决的 Bug，不能由开发人员自己决定，一般要通 过某种会议（评审会）通过才能认可。测试人员查询状态为 Fixed 的 Bug，然后验证 Bug 是否已解决，如解决置 Bug 的状态为 Closed，如没有解决置状态为 Reopen。

2.缺陷描述中应该包含哪些内容？

缺陷的标题，简要描述，缺陷的类型。缺陷的详细步骤描述。缺陷的实际结果。期望结果。有的缺陷需要上传截图，日志信息。缺陷的等级。缺陷指派给开发同事。

3.如何提高缺陷的记录质量？
通用 UI 要统一、准确；尽量使用业界惯用的表达术语和表达方法；使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化；每条缺陷报告只包括一个缺陷；不可重现的缺陷也要报告；明确指明缺陷类型；明确指明缺陷严重等级和优先等级；描述 (Description) ，简洁、准确，完整，揭示缺陷实质，记录缺陷或缺陷出现的位置；短行之间使用自动数字序号，使用相同的字体、字号、行间距； 每一个步骤尽量只记录一个操作；确认步骤完整，准确，简短；根据缺陷，可选择是否进行图像捕捉； 检查拼写和语法缺陷；尽量使用短语和短句，避免复杂句型句式；缺陷描述内容。

4.如果一个缺陷被提交后，开发人员认为不是问题，怎么处理？
首先，将问题提交到缺陷管理库里面进行备案。然后，要获取判断的依据和标准：
￥根据需求说明书、产品说明、设计文档等，确认实际结果是否与计划有不一致的地方，提供缺陷是否确认的直接依据；
￥如果没有文档依据，可以根据类似软件的一般特性来说明是否存在不一致的地方，来确认是否是缺陷；
￥根据用户的一般使用习惯，来确认是否是缺陷；
￥与设计人员、开发人员和客户代表等相关人员探讨，确认是否是缺陷；
合理的论述，向测试主管说明自己的判断的理由，注意客观、严谨，不参杂个人情绪。
等待测试主管做出最终决定，如果仍然存在争议，可以通过公司政策所提供的渠道，向上级反映，并有上级做出决定。

5.测试与开发如何相处？

1. 反映问题时，多说客观描述，告诉他现象结果，也可以少加入一些你的分析猜想；尽量不要说太多主观上的东西，避免冲突。
2. 如果报BUG时，尽量写上测试依据，解释说明为什么它是BUG；如果没有文档依据，最好先找产品人员确认，这样，可也以避免一些测试人员与开发人员间的直接冲突。