bug的原则

一、 Bug报告

BUG报告记录了Bug发生的环境，如各种资源的配置情况，Bug的再现步骤以及Bug性质的说明。更重要的是它还记录着Bug的处理过程和状态。Bug的处理进程从一定角度反映了测试的进程和被测软件的质量状况以及改善过程。

二、 判断Bug的规则

• 软件未达到产品规格说明书或需求标明的功能。
• 软件出现了规格说明书指明不会出现的错误。
• 软件功能超出规格说明书指明的范围。
• 软件未达到规格说明书虽未指出但应达到的目标（隐含需求）。
• 软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
• 需要注意的是，测试人员报告Bug时，应当保证Bug是可以重现的。对于有时不可重现的Bug，应当反复测试，直到最终确定Bug的发生场景为止。

三、报告Bug的基本原则

尽快报告Bug;
有效描述Bug;

四、BUG的描述规范

1、通用要求：

• 每条错误报告只包括一个错误；
  若同一个问题在多处菜单存在，可以在同一BUG中描述，具体做法为：先对问题进行详细描述，在问题下面注明：“在XX菜单、XX菜单存在此现象，请一并修改。”
• 使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。
• 不要使用感叹号或其他表现个人感情色彩的词语或符号。
• 不要使用含糊的词语（例如，好像，似乎，有问题，出现错误）和容易产生争执和歧义的词来描述现象；
• 段落之间使用统一的序号、相同的字体、字号、行间距，保证各条记录格式一致，做到规范专业。
• 在提交每条缺陷或错误之前，反复阅读BUG描述，检查拼写和语法，确保内容正确，正确的描述错误。

2、在JIRA中描述BUG的规范：

概要（必填项），要求如下：

• 标题要简洁、准确、完整、揭示错误实质、记录缺陷或错误出现的位置 。若问题路径较长，直接使用功能的名称，在详细描述中阐述路径。
• 为了便于在软件错误管理数据库中寻找制定的测试错误，包含错误发生时的用户界面（UI）是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称 。
• 重启死机功能不能实现的bug，需表明出现概率，以免其他人员无法判断问题的严重性。

3、复现概律，要求如下：

对于不稳定的问题，应尽量多验证重现BUG，如果找不出BUG产生的原因，一般要求测试20次，比较重要的问题需要进行压力测试来确认，根据测试的实际情况进行选择，不允许为“无”。
无
必现
复现概率＞50%
复现概率＞10%
复现概率＞5%
复现概率＜1%
无规律复现

4、上一版状态（必填项），要求如下：

• 上一版状态需按照实际情况进行填写，若无法判定是本版本的问题，还是上一版的问题，且需将版本下载上一版的软件进行验证，严禁不确定的情况下进行选择“不存在”，以下是各个选项在什么情况下进行选择的简单介绍：
  • 无：此项为未选择时的状态，BUG提交时不允许出现该状态；
  • 存在：上一版软件存在此问题，选择“存在”；
  • 不存在：上一版无此问题，为新版本才存在的BUG，选择“不存在”；
  • 无上一版软件：首版软件测试时，因无上一版软件，可以选“无上一版软件”；
  • 上一版无此功能：新版本添加的功能，选择“上一版无此功能”；
  • 原型版本存在：若在订单项目上发现原型版本即存在的问题，选此项；
• 模块：选择BUG对应的模块。
• 影响版本：选择BUG发生的版本号。
• 修复版本：选择BUG在哪一版上解决，一般由开发人员选择。
• 环境，要求如下：
  • BUG发生时的网络情况、手机硬件情况，SIM卡状态、手机待机模式是卡1，卡2还是双卡都有，单卡模式是否有问题，双卡又如何？

五、BUG的跟踪规范：

• 测试人员要不断跟踪Bug，直到Bug修正，问题解决为止。在最后的DCC版本需对所有已关闭的BUG进行回归测试，验证是否在软件修改过程中导致原本已修改的BUG重新出现；
• 在BUG跟踪过程中，需对BUG状态及时更新，以下为BUG状态的说明：
  • 新建状态（ open ）: Bug创建后的初始状态。
  • 已解决待验证状态（RESOLVED）: 开发部门对软件问题进行处理或修改后的状态。
  • 重新打开状态（REOPENED）: 对开发部门修改后软件问题，经过验证，如果仍然存在，则将其状态改为“重新打开”状态。对于“关闭/延迟修改”状态的软件问题，如果时机成熟，需要重新开发，则将其状态改为“重新打开”状态。
  • 关闭状态（CLOSED）：验证为已修改的问题，需及时进行关闭。
  • 不解决状态（Won’ fix）：评审为不修改的BUG，此类BUG需组长进行确认，若确认不需要修改则关闭，若需要修改则重新开启。
• 对已修改问题进行验证时，不仅应验证该问题是否修改，还应验证修改此问题后对本模块或其它模块的影响，是否有引起的新的问题，若改动较大时，应和组长征询验证方案。

本文仅为参考，更加详细的原文链接