- Bug的基本概念
- Bug的生命周期
- BUG的描述规范
- BUG的跟踪规范
1.Bug的基本概念
1.1 BUG的含义：
BUG是一个英文单词，本意是缺陷、损坏等意思。现在人们将在电脑系统或程序中，隐藏着的一些未被发现的缺陷或问题统称为bug（漏洞）。
狭义的讲，在手机软件测试中，BUG是指手机的软件所隐藏的一些未被发现的缺陷或问题。
1.2 BUG表现
现象一：功能没有实现或与规格说明不一致；
现象二：不能工作(死机、没反应) ；
现象三：不兼容
现象四：边界条件未做处理
现象五：界面、提示、帮助不正确或不够准确
现象六：尚未完成的工作
1.3 Bug报告
BUG报告是软件测试过程中最重要的文档。它记录了Bug发生的环境，如各种资源的配置情况，Bug的再现步骤以及Bug性质的说明。
更重要的是它还记录着Bug的处理过程和状态。Bug的处理进程从一定角度反映了测试的进程和被测软件的质量状况以及改善过程。
1.4 判断Bug的规则
软件未达到产品规格说明书或需求标明的功能。
软件出现了规格说明书指明不会出现的错误。
软件功能超出规格说明书指明的范围。
软件未达到规格说明书虽未指出但应达到的目标（隐含需求）。
软件测试员认为软件难以理解、不易使用、运行速度缓慢，或者最终用户认为不好。
需要注意的是，测试人员报告Bug时，应当保证Bug是可以重现的。对于有时不可重现的Bug，应当反复测试，直到最终确定Bug的发生场景为止。
1.5报告Bug的基本原则
尽快报告Bug;
有效描述Bug;
2.Bug的生命周期
Bug的生命周期就是指Bug从开始提出到最后完全解决，并通过复查的过程。在这个过程中Bug报告的状态不断发生着变化，记录着Bug的处理进程。
3. BUG的描述规范
3.1 通用要求：
1）每条错误报告只包括一个错误；
若同一个问题在多处菜单存在，可以在同一BUG中描述，具体做法为：先对问题进行详细描述，在问题下面注明：“在**菜单、**菜单存在此现象，请一并修改。”
2）使用业界惯用的表达术语和表达方法，保证表达准确，体现专业化。3）不要使用感叹号或其他表现个人感情色彩的词语或符号；
3.1 通用要求：
4）不要使用含糊的词语（例如，好像，似乎，有问题，出现错误）和容易产生争执和歧义的词来描述现象；
5）段落之间使用统一的序号、相同的字体、字号、行间距，保证各条记录格式一致，做到规范专业。
6）在提交每条缺陷或错误之前，反复阅读BUG描述，检查拼写和语法，确保内容正确，正确的描述错误。
3.2 在JIRA中描述BUG的规范：
3. 2.1 概要（必填项），要求如下：
1）标题要简洁、准确、完整、揭示错误实质、记录缺陷或错误出现的位置 。若问题路径较长，直接使用功能的名称，在详细描述中阐述路径。
2） 为了便于在软件错误管理数据库中寻找制定的测试错误，包含错误发生时的用户界面（UI）是个良好的习惯。例如记录对话框的标题、菜单、按钮等控件的名称 ；
3）重启死机功能不能实现的bug，需表明出现概率，以免其他人员无法判断问题的严重性
3. 2.2 bug severity：
BUG等级分为S/A/B/C四个等级
3. 2.5 复现概律，要求如下：
对于不稳定的问题，应尽量多验证重现BUG，如果找不出BUG产生的原因，一般要求测试20次，比较重要的问题需要进行压力测试来确认，根据测试的实际情况进行选择，不允许为“无”。
无
必现
复现概率＞50%
复现概率＞10%
复现概率＞5%
复现概率＜1%
无规律复现
3. 2.6 上一版状态（必填项），要求如下：
上一版状态需按照实际情况进行填写，若无法判定是本版本的问题，还是上一版的问题，且需将版本下载上一版的软件进行验证，严禁不确定的情况下进行选择“不存在”，以下是各个选项在什么情况下进行选择的简单介绍：
无：此项为未选择时的状态，BUG提交时不允许出现该状态；
存在：上一版软件存在此问题，选择“存在”；
不存在：上一版无此问题，为新版本才存在的BUG，选择“不存在”；
无上一版软件：首版软件测试时，因无上一版软件，可以选“无上一版软件”；
上一版无此功能：新版本添加的功能，选择“上一版无此功能”
原型版本存在：若在订单项目上发现原型版本即存在的问题，选此项
3.2.7 模块：选择BUG对应的模块。
3.2.8 影响版本：选择BUG发生的版本号。
3.2.9 修复版本：选择BUG在哪一版上解决，一般由开发人员选择。
3.2.10环境，要求如下：
BUG发生时的网络情况、手机硬件情况，SIM卡状态、手机待机模式是卡1，卡2还是双卡都有，单卡模式是否有问题，双卡又如何？
3.2.11 描述，要求如下：
描述必须包含以下几个要点，操作步骤、问题现象、期望结果和备注。
操作步骤：
1）每一个步骤尽量只记录一个操作；
2）保证简洁、条理井然；
3）保证快速准确的重复错误，“完整”即没有缺漏，“准确”即步骤正确，“简短即没有多余的步骤；
4）BUG如果在特定条件下产生的，必须写明BUG产生的条件。
BUG的跟踪规范：
4.1 测试人员要不断跟踪Bug，直到Bug修正，问题解决为止。在最后的DCC版本需对所有已关闭的BUG进行回归测试，验证是否在软件修改过程中导致原本已修改的BUG重新出现；
4.2 在BUG跟踪过程中，需对BUG状态及时更新，以下为BUG状态的说明：
新建状态（ open ）: Bug创建后的初始状态。
已解决待验证状态（RESOLVED）: 开发部门对软件问题进行处理或修改后的状态。
重新打开状态（REOPENED）: 对开发部门修改后软件问题，经过验证，如果仍然存在，则将其状态改为“重新打开”状态。对于“关闭/延迟修改”状态的软件问题，如果时机成熟，需要重新开发，则将其状态改为“重新打开”状态。
关闭状态（CLOSED）：验证为已修改的问题，需及时进行关闭。
不解决状态（Won’ fix）：评审为不修改的BUG，此类BUG需组长进行确认，若确认不需要修改则关闭，若需要修改则重新开启。
4.3 对已修改问题进行验证时，不仅应验证该问题是否修改，还应验证修改此问题后对本模块或其它模块的影响，是否有引起的新的问题，若改动较大时，应和组长征询验证方案。