而现在正规的软件项目已经不会再用这种原始的方式来报 Bug 了,而是会借助测试工具来帮助报告和跟踪 Bug,即使你偶尔能看到有项目还在采用原始方式报 Bug,你肯定也会觉得这样做不专业。文章源自玩技e族-https://www.playezu.com/19106.html
但不知道你有没有仔细想过这个问题,为什么现在不通过 QQ/ 微信 / 邮件报 Bug,又有哪些测试工具可以帮助你更好地发现、报告和跟踪软件中的 Bug 呢?今天我们会展开讨论这个问题。文章源自玩技e族-https://www.playezu.com/19106.html
文章源自玩技e族-https://www.playezu.com/19106.html
文章源自玩技e族-https://www.playezu.com/19106.html
文章源自玩技e族-https://www.playezu.com/19106.html
为什么要使用 Bug 跟踪工具?
- Bug 不能有效被跟踪,不知道一个 Bug 是不是已经被修复了;
- 效率很低,开发人员频繁的被这样的报 Bug 的消息打断,不得不停下手头的工作去甄别 Bug;
- 不能直观的了解当前项目的 Bug 状态,比如说:修复了多少,还有多少没有修复,近期 Bug 数量是增加了还是减少了。
不难看出,通过 QQ 等方式报告的 Bug,都是文字配合图片等信息,很难检索和分类,而 Bug 跟踪工具,采用结构化的数据来定义 Bug,每一个 Bug 都有一些关键的信息可以对 Bug 进行分类和检索。
在 Bug 跟踪工具使用中,一个基本的 Bug 信息包括:
- 标题;
- 描述(包括期望结果、实际结果和重现步骤等关键信息);
- 优先级;
- 指派人;
- 状态(New、Open、 Rejected、Fixed 等);
- 其他。
那这样的话,就很容易的对 Bug 进行分类和检索,比如说:
- 张三想查看所有分配给他的 Bug,那只要列出所有指派人是张三的 Bug;
- 想列出所有未解决的 Bug,只要列出所有状态不是 Close 或 Rejected 的 Bug 即可。
这样对于开发人员来说,可以直观的看到自己有哪些 Bug 需要处理,Bug 的描述信息也可以帮助重现 Bug、快速定位到 Bug 的原因;对于项目经理或者测试人员来说,可以直观的看到哪些 Bug 还没解决,及时了解项目进展。
在软件项目中,要把好的实践流程化,把好的流程工具化。Bug 跟踪工具则很好的贯彻了这一点,将 Bug 的解决过程流程化。
你平时在 Bug 跟踪系统中看到的 Bug 状态,看起来只是一个有限的状态列表,但背后其实是一套解决 Bug 的流程。就像下面这张图表示的这样,一个 Bug 从创建到最后结束,其实是有一个完整的流程的。
通过这样的流程,开发人员就可以集中对 Bug 进行分配、按照优先级分别解决,而测试人员则可以第一时间知道 Bug 处理的状态变化,及时验证,方便跟踪整个过程。
使用 Bug 跟踪工具的注意事项
报告 Bug 的目的是为了能跟踪 Bug,以及帮助开发人员重现直到解决问题。要想做到测试和开发高效协作,这里面有一些需要注意的事项。
首先,所有的 Bug 都应该通过 Bug 跟踪系统管理和跟踪,不应该再通过 QQ/ 微信 / 邮件的方式跟踪 Bug。如果客户、同事通过 Bug 跟踪系统之外的其他途径反馈 Bug,应该统一提交到 Bug 跟踪系统管理跟踪起来。
然后,不能把多条 Bug 合并成一条,一个 Bug 创建一个独立的 Ticket。我遇到过有些测试为了省事,把几条 Bug 合并成一个 Ticket 来报,导致的问题就是,必须这几条 Bug 都修复了,这个 Ticket 才能改变状态,如果其中一个 Bug 没有验证通过,需要 Reopen 整个 Ticket。
再有,描述清楚如何重现 Bug 非常重要。一个 Bug 如果无法重现,也没有日志、截图等辅助信息,那是非常难以定位的,会浪费很多开发人员定位 Bug 的时间。
最后,不要把 Bug 跟踪系统当成讨论板用。在项目中一个常见的场景是,一个 Ticket 下面,跟讨论版一样添加了很多留言,开发认为不是 Bug,测试认为是一个 Bug,开发又觉得是产品设计没定义清楚,应该让产品经理来讲清楚,皮球踢来踢去,最后问题还没解决。
小编总结:工具有很多例如:Bugzilla、Jira、MantisBT,禅道。现在很多公司都用禅道进行项目的管理,之前文章也有发过禅道的相关文章,以及公众号也有提供禅道的安装包,大家可以自行下载,搭建。管理bug的工具初学者只要掌握一个就行了,因为都是大同小异的。了解其流程即可。
北京市 1F
写的不错