“缺陷管理工具”禅道—升华Bug处理流程与相关属性
“缺陷管理工具”禅道—升华Bug处理流程与相关属性
作为一个软件测试工程师，对缺陷管理工具（缺陷：Bug）的认识和准确操作是有所必要的，缺陷管理工具现在行业中有很多：禅道、QC、Clear Quest、TestLink、Bugfree、Bugzilla、Jira等。本文选择根据禅道带大家认识Bug处理流程以及Bug的相关属性：Bug标题、重现步骤、Bug类型、Bug严重程度、Bug优先级、Bug来源、Bug根因等重大属性。
- “缺陷管理工具”禅道—升华Bug处理流程与相关属性
- 1 BUG处理流程
- 2 Bug相关属性
- 2.1 产品模块
- 2.2 所属项目
- 2.3 影响版本
- 2.4 当前指派
- 2.5 Bug标题
- 2.6 重现步骤
- 2.7 缺陷类型
- 2.8 缺陷严重程度
- 2.9 缺陷优先级
- 2.10 缺陷来源
- 2.11 缺陷根因
- 2.12 系统/浏览器
- 2.13 抄送
- 2.14 关键词
- 2.15 附件
1 BUG处理流程
打开缺陷管理工具——禅道，软件测试工程师选择在“测试”视图页，选择好测试项目后，点击“Bug”，会看到测试流程状态：指派给我、由我创建、由我解决、未指派、未解决、未关闭、久未处理、被延期、需求变动等。
针对测试工程师的Bug状态：激活中、已解决、已关闭等。
针对开发工程师的Bug解决方案：已解决、延期处理、重复Bug、外部原因、无法重现、不予解决、设计如此等。
根据状态，我们来熟悉下Bug处理流程（即：缺陷生命周期）。
Bug处理流程（Bug的生命周期）：
- （1）测试工程师发现Bug，查证Bug无重复提交过，然后尽可能完善Bug的相关属性，接着再提交Bug，把缺陷的状态置为：new；
- （2）开发工程师确认提交的Bug，进行Bug的重现与分析，如果不是Bug，拒绝Bug,把状态置为：rejected；如果是Bug，指派给具体的开发人员解决，把状态置为：open；
- （3）开发人员看到指派给自己解决的Bug，进行修改Bug，修改完后提交给测试工程师进行返测，开发人员自己把Bug状态置为：fixed；
- （4）测试工程师对修改的Bug进行返测，如果返测成功，则关闭Bug,把Bug状态置为：closed；如果返测不成功，则重新激活Bug,让开发工程师修改，把Bug状态改为：reopen。
- （5）若经过多次返测后，测试工程师与开发工程师对该Bug有一定程度的争议，则测试工程师决策是否让项目经理来校验下是不是Bug,如果是Bug,则开发工程师必须进行修改；如果不是Bug，则测试工程师关闭Bug。
在Bug处理过程中，项目中不同的角色应该关注的相应状态与处理态度不一样。
针对开发工程师，应关注测试工程师所置状态：new、reopen、closed。new:开发工程师要对激活状态的Bug进行处理，根据处理过程，将其状态置为rejected、open、fixed以及“已解决”、“延期处理”、“重复Bug”、“外部原因”、“无法重现”、“不予解决”、“设计如此”等；reopen：重新打开的Bug是经过处理修改后的Bug通过测试工程师返测后表明没有修改正常，进而需要继续做相应的修改；closed：表明修改Bug成功，无缺陷。
针对测试工程师，应关注开发工程师所置状态：rejected、open、fixed以及“已解决”、“延期处理”、“重复Bug”、“无法重现”、“外部原因”、“不予解决”、“设计如此”等，根据不同状态做出响应反馈操作。特别说明下，对于开发工程师说明由于外部原因、设计如此，甚至不予解决的Bug，要及时决策通知到项目经理那里，由项目经理来决定修改与否。
2 Bug相关属性
禅道缺陷管理工具中，从测试人员界面可以很清楚的知道Bug的相关属性：产品模块、所属项目、影响版本、当前指派、Bug标题、重现步骤、相关需求、相关任务、缺陷类型、缺陷严重程度、缺陷优先级、缺陷来源、缺陷根因、系统/浏览器、抄送、关键词、附件。
2.1 产品模块
测试出的Bug所在的系统模块，如：职工管理系统 — 系统设置。
2.2 所属项目
测试的软件产品所属的项目名称。
2.3 影响版本
当前的测试版本。如：Trunk。
2.4 当前指派
当清楚该产品模块是哪个开发人员的情况下，直接指派到相应的开发人员；不清楚时，则直接指派给开发经理，由开发经理进一步分配指派。
2.5 Bug标题
Bug标题的确定，以产品模块 + 问题的简要描述。如：职工登录界面——登录出现问题，错误账号或密码也能登录。
2.6 重现步骤
从重现操作步骤、操作结果以及预期期望等3个方面去重现Bug。部分Bug能够容易的重现，但部分Bug则需要通过截图、打断点、日志、抓取网络包等去捕获有助于重现Bug的信息，尽可能的为Bug所属产品模块的开发工程师提供有效信息。在重现Bug描述过程中，应该精准定位Bug、准确列出操作的所有步骤、准确解释必须条件，甚至列举出示例。
尽量排除无效的Bug，避免误报Bug。考虑Bug是不是程序所引起的？Bug征兆是不是假象？是不是网络问题导致数据不能连接？是不是应用软件的配置错误而导致数据不能连接？是不是外部特殊原因引起的问题？等方面去考虑，尽可能缩小出错的范围。
2.7 缺陷类型
根据测试的Bug，明确其类型，便于问题类型的统计、项目的总结。点击禅道的“缺陷类型”下拉菜单，可以列举出以下的缺陷类型：
- 功能问题：功能错误、功能缺失、功能超越、设计二义性、算法错误
- 接口问题：模块间接口、模块内接口、公共数据使用
- 逻辑问题：分支不正确、重复的逻辑、忽略极端条件、不必要的功能、误解、条件测试错误、错误的变量检查、计算顺序错误、逻辑顺序错误、公共数据使用
- 计算错误：等式错误、缺失运算符、错误的操作数、括号用法不正确、精度不够、舍入错误、符合错误
- 收费问题：初始化错误、存取错误、引用错误的变量、数组引用越界、不一致的子程序参数、数据单位不一致、数据维数不正确、变量类型不正确、数据范围不正确、操作符数据错误、变量定位错误、数据覆盖、外部数据错误、输出数据错误、输入数据错误、数据检验错误
- 用户界面问题：界面风格不统一、屏幕上的信息不可用、屏幕上的错误信息、界面功能布局和操作不合常规
- 文档问题：描述含糊、项描述不完整、项描述不正确、项缺少或多余、项不能验证、项不能完成、不符合标准、与需求不一致、文字排版错误、文档信息错误、注释缺陷
- 性能问题：严重、一般、轻微
- 配置问题：配置管理问题、编译打包缺陷、变更缺陷、纠错缺陷
- 标准问题：不符合编码标准、不符合软件标准、不符合行业标准
- 环境问题：设计与编译环境、运行环境
- 兼容问题：严重、一般、轻微
- 其他问题：严重、一般、轻微
2.8 缺陷严重程度
不同的公司划分的缺陷严重程度不同，大致划分为3-5个级别，具体的等级划分可灵活调整。现在按照个人所处的环境进行5类划分，大致如下：
| 严重级别：轻微 |
|---|
| 增加用户使用体验的建议性问题 |
| 风格不统一，例如：相近流程的页面布局不统一、相同问题点的提示信息不一致，但对用户的操作习惯或操作方法不会造成影响 |
| 对齐方式不一致，例如：文字对齐以及页面挂列项不一致 |
| 界面错误，例如：显示格式不规范、页面描述显示错误、字体错误等 |
| 长时间操作的功能未给用户进度提示 |
| 按钮或标签上有拼写错误的字符，例如：汉字、单词、字母等错误拼写 |
| 错误定位及信息提示不准确，例如：出错后前台后台的信息提示错误、错误判断的顺序、错误出现的光标定位等 |
| 严重级别：一般 |
|---|
| 业务流程对应的功能未实现，但在不影响实际使用的前提下有替代方法解决 |
| 简单业务的功能实现错误，例如：默认显示内容的错误、辅助说明描述不清楚、查询匹配的错误、查询列表初始查询条件的错误等 |
| 页面输入限制错误，例如：文本框输入长度以及字符的限制错误、文件图片上传格式大小的限制错误，以及特殊输入要求判断的错误等 |
| 日期和时间初始值错误，以及业务操作流程先后时间判断的错误 |
| 严重级别：严重 |
|---|
| 业务流程的功能未实现，但不影响到系统稳定性 |
| 操作正确性不受影响，但影响到系统性能和响应时间 |
| 功能实现与需求不一致，但影响流程中其他模块 |
| 数据库建库或升级的脚本错误，丢失相关表或字段，影响系统正常运行 |
| 存储过程不能正常执行对应的设计功能 |
| 性能测试过程中，大数据量和并发压力大时，系统处理缓慢、网络异常以及少量数据丢失（低于0.5%）等情况 |
| 严重级别：非常严重 |
|---|
| 系统中未实现相应需求，以及密码明文显示 |
| 业务流程对应的功能未实现，且无任何替代方法 |
| 数据连接未释放，以及与其它模块接口的调用错误 |
| 产生错误的结果，进而致使系统不稳定 |
| 页面出现编译错误，甚至404页面 |
| 性能测试过程中，大数据量和并发压力大时，系统停止处理，甚至大量数据丢失（大于0.5%）等情况 |
| 严重级别：致命 |
|---|
| 功能设计与需求设计严重不符 |
| 主流程无法跑通，系统无法正常运行 |
| 正常的用户操作流程，导致系统崩溃或者严重资源不足 |
| 内存泄漏，数据泄漏的安全性问题 |
| 应用模块无法启动或者非法退出 |
| 致使通讯中断 |
| 循环报错，使得无法正常退出 |
2.9 缺陷优先级
缺陷严重程度和缺陷优先级是2个含义不同但又密切联系的概念，分别从不同方面去描述软件缺陷对软件质量和最终用户的影响程序和处理方式。缺陷的严重程度与缺陷优先级不一定是一一对等。
- 优先级别：低
适当考虑，延迟处理，尽可能在发布前进行修复 - 优先级别：中
在软件开发工程师的阶段性任务完成后进行修复 - 优先级别：高
任务正常排队，但又不会影响到开发测试的工作进度 - 优先级别：非常高
软件开发工程师如果当前开发任务不是特别紧急的情况下，应该优先修复该缺陷；如果当前开发任务相对重要，则在完成这个开发模块后，应该优先修复该缺陷 - 优先级别：紧急处理
软件开发工程师必须先停止当前的开发任务，修复好该缺陷
2.10 缺陷来源
有需求、设计、编码、测试、集成、用户、其他等7个方面。
2.11 缺陷根因
有需求、设计、编码等3个方面。
2.12 系统/浏览器
操作系统（OS，Operating System），基本上是所有软件产品必须依赖的。软件所需求的操作可能存在差异，则需要针对性的设计开发。有如下操作系统：Windows、Linux、Unix、MAC、CentOS linux以及相应的不同版本。
B/S（Browser/Server，浏览器/服务器结构），在互联网产品中，浏览器的兼容性显得十分重要，不同浏览器之间（IE、Firefox、Chrome、Opera、Safari等以及相应不同的版本）都可能存在兼容性问题，所以浏览器环境也是Bug重现的前提条件之一。
2.13 抄送
根据项目情况，选择抄送。
2.14 关键词
提炼出该Bug的几个重要关键词，以便后期查询、验证。
2.15 附件
重要的日志、文件、截图包等选择性的以附件提交，有助于开发工程师重现Bug。
- 致谢
若对大家有用，感谢点赞或评论；若有不足或补充之处，也感谢大家评论进行指正，后期我将对本文进行补充完善。相信这是互相进步的开始！