【测试基础第六篇】bug定义及生命周期

• bug定义
  • 狭义：软件程序的漏洞或缺陷
  • 广义：测试工程师或用户所发现和提出的软件可改进的细节（增强型、建议性）或需求文档存在差异的功能实现
  • 职责：发现bug，提给开发，让其修改
• bug类型--了解
  
  • 代码（功能）错误---最常见--优先级偏高
  • 界面优化--UI测试--优先级偏低
  • 设计缺陷--优化建议：需求就不合理--优先级偏低
• bug的等级--优先级
  
  • 致命错误--blocker
    • 常规操作引起的系统崩溃、死机、死循环、闪退
    • 造成数据泄露的安全性问题，比如恶意攻击造成的账户私密信息泄露
    • 涉及金钱计算--公司巨大损失、业务
    • 阻断性测试，所有测试工作进行不下去（冒烟测试）
    • 权限问题--爱奇艺会员
  • 严重错误--critical
    • 重要功能不能实现
    • 错误的涉及面广，影响到其他重要功能正常时间
    • 非常规操作导致的程序崩溃、死机、死循环、闪退
    • 外观（界面）难以接受的缺陷
    • 密码明文显示
    • 偶现的致命性bug
  • 一般错误--major--会遇到最多
    • 注意：不影响产品的运行、不会成为故障起因，但对产品外观和下道工序影响较大的缺陷
    • 次要功能不能正常实现
    • 操作界面错误（功能与列明定义、含义不一致）
    • 查询结果、数据错误显示
    • 简单的输入限制未放在前端进行控制
    • 删除操作未给出提示---友好一点
    • 偶现的严重性bug
  • 细微错误--minor
    • 注意：程序在一些显示上不美观、不符合用户习惯、一些文字错误--用户体验
    • 1.界面不规范
    • 2.辅助说明描述步清除
    • 3.提示窗口文字未采用行业术语
    • 4.界面存在文字错误
  • 改进建议--enhancement--新需求下一个版本
    • 可以提高产品质量的建议，包括新需求和对需求的改进
• bug生命周期（管理流程）---重点
  
  • Bug生命周期：被发现到被关闭的过程
  • 一般缺陷状态：发现--新建（提bug）--指派--已解决--待验--关闭
  • 注意：若bug没有解决好，需要重新打开（激活）--指派--已解决--待验，循环这个过程。中间其他状态：拒绝、延期等。
  • bug跟踪管理流程
    • 流程图
    • 状态处理
    • 梳理
      • 【发现bug】要先确认，防止环境问题、操作问题等一些外因引起的bug。会被开发认为是无效Bug。
      • 【新建（new）】提bug的人或测试老大指派（开发或开发老大），跟进bug，推进开发修复Bug
      • 【重复bug（duplicated）】要求开发备注一下重复bug的 id，方便测试人员确认是不是一个问题，如果是重复的，要加备注，关闭。如果不是一个bug，重新激活（reopened），重新指派开发。
      • 【不是缺陷（invalid）】（1）By design设计如此（2）对需求理解不一致导致操作失误--要讨论一下：①拿到需求，再次需求分析，从用户角度开发，找到证据，罗列证据，尝试说服开发。②无果，找产品或项目经理确认，若是bug，开发修复，不是bug，别纠结，但也留好证据（邮件截图，备注到bug里）。
      • 【无法复现（un-reproduced）】（1）开发无法复现：确认测试环境可否再复现，若可以复现，帮助开发复现，仍无法复现，让他到测试环境调试定位（2）测试和开发都无法复现，要尝试跟踪3-5个版本，每个版本复现超过10次，仍然无法复现，在Bug中加备注(我复现的次数、跟踪版本数)，关闭该bug，记录到自己的笔记中。
      • 【开发确认Bug后，不予解决（wontfix）】原因bug级别低（建议性Bug、ui的bug），（1）首先要站在用户角度，说服开发，无果的话（2）找产品确认（3）加备注留证据，最后关闭bug
      • 【延期（delayed）】（1）建议性的bug，作为下一个版本的需求（2）上线之前，修复影响较大（性价比低），此时，要分析①对用户的影响，影响用户体验，就要修复②bug严重级别高，找项目经理、产品拍板确认。若不修复，备注（留证据）。---延期bug不关闭--挂起状态
      • 【已修复（resolved-fixed）】开发修复后，指派给测试，测试验证（bug步骤、结果重新操作一遍），验证后（1）已验证（verified）加备注--项目结束（closed）（2）仍然存在，reopened重新激活，指派开发，开发确认bug，解决Bug。加备注
    • 加备注：方便跟踪、查阅bug
• bug跟踪管理--缺陷管理工具
  
  • 工具
    • 禅道（zentao）、bugzilla、jira、bugfree、Readmine、easybug、Mantis、QC(QualityCenter)、TD
  • 提bug
    • 所属产品、项目、模块、影响版本（主干、分支）、当前指派、截止日期（测试不填）、bug类型、操作系统、浏览器、bug标题【重要】、严重程度、优先级（测试不填）、重现步骤（实际结果、期望结果）、抄送、附件
  • 提交bug包含内容
    • 【bug标题】标题要清晰简洁， 写明bug描述;如果没有选择功能模块，最好在标题中标注功能模块。让查有bug的人员清楚知道你所表达的意思。bug的功能模块+ bug的操作+ bug的结果。
    • 【重现步骤】详细写下发现bug的测试步骤-结果-预期。能指导开发重现这个bug。附上测试数据。实际结果用截图直观。
    • 【实际结果】出现bug的结果，粘贴bug截图、日志截图--直观，证据(有图有真相)
    • 【预期结果】记得写清楚预期----参照测试用例的预期结果
    • 【bug类型和严重程度】便于后续测试结果分析， bug的统计
    • 【bug测试环境】什么系统，哪个版本等。兼容性问题、难以重现问题
    • 【附件】日志文件， 文件测试数据。图片、崩溃日志文件等
  • 注意
    • 参考公司前辈写的bug,依葫芦画瓢，拓展测试思维。
    • 偶现Bug的复现率也可以写一下。
• 常见笔试面试题
  
  • 1:有没有你印象深刻的bug? bug的原因/bug当时怎么解决?
  • 2: bug的生命周期? (笔试)
    • 指被发现到被关闭的过程。一般缺陷状态：发现--新建（提bug）--指派--已解决--待验--关闭。延期、不予解决。
  • 3:当你开了一个bug,但是开发不认为是bug,如何处理?
    • （1）By design设计如此（2）对需求理解不一致导致操作失误--要讨论一下：①拿到需求，再次需求分析，从用户角度开发，找到证据，罗列证据，尝试说服开发。②无果，找产品或项目经理确认，若是bug，开发修复，不是bug，别纠结，但也留好证据（邮件截图，备注到bug里）。
  • 4:你在发现bug并确认bug的过程中，对于复现率不高的bug怎么处理?
    • 无法复现（un-reproduced）：（1）开发无法复现：确认测试环境可否再复现，若可以复现，帮助开发复现，仍无法复现，让他到测试环境调试定位（2）测试和开发都无法复现，要尝试跟踪3-5个版本，每个版本复现超过10次，仍然无法复现，在Bug中加备注(我复现的次数、跟踪版本数)，关闭该bug，记录到自己的笔记中。