这个怎么用的

缺陷管理

Posted on 2022-03-30 17:26  DawnDuke  阅读(74)  评论(0)  编辑  收藏  举报

缺陷类型

  1. 遗漏（Missing）

  2. 错误（Error）

  3. 额外的实现（Extra）

缺陷报告单写作原则：5C原则

  1. Correct（准确）
    每个组成部分的描述准确，不会引起误解

  2. Clear（清晰）
    每个组成部分的描述清晰，易于理解

  3. Concise(简洁)
    只包含必不可少的信息，不包括任何多余的内容

  4. Complete（完整）
    包含复现该缺陷的完整步骤和其他本质信息（例如无法删除，要说明什么情况下删除不了）

  5. Consistent（一致）
    按照一致的格式书写全部缺陷报告（格式一致，前后内容一致，对应）

缺陷报告单的组成

  1. 缺陷的编号；
  2. 缺陷的标题；
  3. 复现缺陷的操作步骤；
  4. 缺陷的实际结果描述；
  5. 期望的正确结果描述；
  6. 所属模块
  7. 发现版本：测试的软件版本；
  8. 缺陷的严重程度；
  9. 缺陷的处理优先级。
  10. 指定处理人
  11. 附件：注释文字和截取的缺陷图像。
  12. 提交人
  13. 提交日期
  14. 缺陷的类型；
  15. 硬件平台和操作系统
    测试应用的硬件平台（Platform），通常选择“PC”。
    测试应用的操作系统平台（OS）
  16. Bug状态

缺陷的严重程度

  1. 致命：例如，软件的意外退出升值操作系统奔溃，造成数据丢失（一般非常少会出现，一般出现致命问题，会停止测试，影响非常严重）
  2. 严重：例如，由于单功能失效导致多个相关功能均失效。
  3. 一般：例如，软件的单个功能失效。（出现的最多）
  4. 提示：软件界面的细微缺陷，例如,某个控件没有对齐，某个标点符号丢失等。

不确定是否是缺陷

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

开发人员说不是BUG时，你如何应付？

开发人员说不是bug，有2种情况，一是需求没有确定，所以我可以这么做，这个时候可以找来产品经理进行确认，需不需要改动，3方商量确定好后再看要不要改。二是这种情况不可能发生，所以不需要修改，这个时候，我可以先尽可能的说出是BUG的依据是什么？如果被用户发现或出了问题，会有什么不良结果？程序员可能会给你很多理由，你可以对他的解释进行反驳。如果还是不行，那我可以给这个问题提出来,跟开发经理和测试经理进行确认,如果要修改就改,如果不要修改就不改。其实有些真的不是bug，我也只是建议的方式写进TD中，如果开发人员不修改也没有大问题。如果确定是bug的话，一定要坚持自己的立场，让问题得到最后的确认。

当你发现bug怎么办，你怎么确认是bug，如果是偶尔出现的bug你怎么处理？

缺陷状态迁移

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

  1. NEW（新建）
    缺陷的初始阶段

  2. Open（打开）
    开发人员开始修改缺陷

  3. Fixed（修复）
    开发人员修改缺陷完毕

  4. Closed（验证通过）
    回归测试通过

  5. Reopen（重新打开）
    回归测试失败

  6. Postpone（推迟修改）
    推迟修改

  7. Rejected（拒绝）
    拒绝，开发人员认为不是程序问题，拒绝缺陷

  8. Duplicate（重复）
    重复，与已经提交的defect重复

  9. Abandon（确认不是问题）
    被reject和duplicate的defect，测试人员确认后的确不是问题，将defect置为此状态，Abandon是一种特殊意义的closed

image

这个也是这样的？