【测试基础】晕晕乎乎的bug

作为一名软件测试人员，找bug就是我们工作职责所在。

狭义来讲，bug是软件程序的漏洞或缺陷

广义来讲，它是测试工程师或用户所发现和提出的软件可改进的细节或需求文档存在差异的功能实现

不论咋讲，测试人员的工作就是找bug，提给开发，然后让开发修复。

首先，bug类型有:

   代码功能类

   界面优化类

   产品设计缺陷

代码功能类，它是最常见的bug，也是优先级最高的;

界面优化类，在ui测试范畴，优先级相对来说偏低一点;

产品设计缺陷类，对于需求不合理的地方，我们能给出建议，此类问题优先级偏低。

其次，bug也是有一定等级的，开发会依据我们提出bug等级去修复。有：

    致命错误

    严重错误

    一般错误

    改进错误

致命错误通常见于：由常规操作引起的崩溃、闪退、死机循环；由数据泄漏造成的安全问题；进行不下去的测试，就是连冒烟通过不了的

严重错误通常见于：错误涉及面比较广，影响其他重要功能正常使用；非常规操作导致的崩溃、闪退等；界面让人无法接受的；密码明文显示；偶现致命bug

在大田看来，上述两类错误边界可以不用那么明显，只要出现就是需要解决的，用户是没有耐心的。

一般错误常见于：次要功能不正常实现、操作界面功能和语义提示不一致、查询结果和数据不匹配、一些输入未放在前端限制、删除不给出友好提示、

注意：一般错误可以理解为不影响产品运行，不会造成大故障。

改进意见常见于：提高产品质量建议，界面不规范，提示窗口不使用行业用语等

以上说了这些，不知道对你是否有所启发😄

再次，再看下bug生命周期

是指被发现到被关闭的过程

而我们应如何管理bug呢？

当我们发现bug后，去禅道提bug，指派给开发，由开发确认bug，解决bug，开发将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呢？

提bug工具有：禅道（zentao）、bugzilla、jira、bugfree、Readmine、easybug、Mantis、QC(QualityCenter)、TD

以禅道为例，讲下大田每次提bug都会注意的7点有：

【bug标题】标题要清晰简洁， 写明bug描述;如果没有选择功能模块，最好在标题中标注功能模块。让查有bug的人员清楚知道你所表达的意思。bug的功能模块+ bug的操作+ bug的结果。

【重现步骤】详细写下发现bug的测试步骤-结果-预期。能指导开发重现这个bug。附上测试数据。实际结果用截图直观。

【实际结果】出现bug的结果，粘贴bug截图、日志截图--直观，证据(有图有真相)。

【预期结果】记得写清楚预期----参照测试用例的预期结果。

【bug类型和严重程度】便于后续测试结果分析， bug的统计。

【bug测试环境】什么系统，哪个版本等。兼容性问题、难以重现问题。

【附件】日志文件， 文件测试数据。图片、崩溃日志文件等。