十多年前,客户在使用过程中遇到了错误,直接就截个图,或者是用词文档整理在一起,从QQ或者邮件上把错误信息发送给开发,开发收到后再修复更新上线。
而现在正规的软件项目已经不会再用这种原始的方式来报错误了,而是会借助测试工具来帮助报告和跟踪错误,即使你偶尔能看到有项目还在采用原始方式报错误,你肯定也会觉得这样做不专业。
但不知道你有没有仔细想过这个问题,为什么现在不通过QQ/微信/邮件报错误,又有哪些测试工具可以帮助你更好地发现,报告和跟踪软件中的Bug呢?今天我们会展开讨论这个问题。
我想你对与错误这个词一定不陌生,它是我们软件中的缺陷或错误。这个词的诞生也很有意思.1947年9月9日,一只小飞蛾钻进了哈佛大学的一台计算机电路里,导致系统无法工作,操作员把飞蛾贴在计算机日志上,写下了“首个发现错误的实际案例”。
虽然Bug的历史已经有60多年了,然而错误跟踪工具却没有出现太久。软件项目中最早也是通过邮件,即时通讯等原始方式报告Bug,直到1992年才有第一个专业的错误跟踪软件琐事。
在这之后才逐步有了像Bugzilla, Jira, MantisBT等专业的错误跟踪工具。而现在,虫子跟踪工具已经成为软件项目中必不可少的工具之一。那么,虫子跟踪工具是怎么逐步替代QQ,邮件等方式来处理Bug的呢?
我们在上一篇学习了软件测试相关的理论知识,软件测试的主要工作就是发现错误,报告Bug和跟踪Bug。测试人员发现错误只是第一步,还需要报告Bug让开发人员可以知晓和定位,并且跟踪整个Bug修复的过程。
用QQ或者邮件报错误的这种方式,看起来快捷简单,但是问题很多:
-
<李>错误不能有效被跟踪,不知道一个错误是不是已经被修复了,李
<李>效率很低,开发人员频繁的被这样的报错误的消息打断,不得不停下手头的工作去甄别错误;李
<李>不能直观的了解当前项目的虫状态,比如说:修复了多少,还有多少没有修复,近期错误数量是增加了还是减少了。
不难看出,通过QQ等方式报告的错误,都是文字配合图片等信息,很难检索和分类,而虫子跟踪工具,采用结构化的数据来定义错误,每一个错误都有一些关键的信息可以对问题进行分类和检索。
在错误跟踪工具使用中,一个基本的缺陷信息包括:
-
<李>标题;李
<李>描述(包括期望结果,实际结果和重现步骤等关键信息);李
<李>优先级;李
<李>指派人,李
<李>状态(新的、开放、拒绝、固定等);李
<李>其他。
那这样的话,就很容易的对错误进行分类和检索,比如说:
-
<李>张三想查看所有分配给他的错误,那只要列出所有指派人是张三的Bug;李
<李>想列出所有未解决的错误,只要列出所有状态不是关闭或拒绝的缺陷即可。
这样对于开发人员来说,可以直观的看到自己有哪些错误需要处理,Bug的描述信息也可以帮助重现错误,快速定位到错误的原因,对于项目经理或者测试人员来说,可以直观的看到哪些虫子还没解决,及时了解项目进展。
在软件项目中,要把好的实践流程化,把好的流程工具化.Bug跟踪工具则很好的贯彻了这一点,将错误的解决过程流程化。
你平时在错误跟踪系统中看到的虫状态,看起来只是一个有限的状态列表,但背后其实是一套解决Bug的流程。就像下面这张图表示的这样,一个错误从创建到最后结束,其实是有一个完整的流程的。
通过这样的流程,开发人员就可以集中对错误进行分配,按照优先级分别解决,而测试人员则可以第一时间知道缺陷处理的状态变化,及时验证,方便跟踪整个过程。
报告Bug的目的是为了能跟踪错误,以及帮助开发人员重现直到解决问题。要想做到测试和开发高效协作,这里面有一些需要注意的事项。
首先,所有的Bug都应该通过虫子跟踪系统管理和跟踪,不应该再通过QQ/微信/邮件的方式跟踪Bug。如果客户,同事通过虫子跟踪系统之外的其他途径反馈错误,应该统一提交到虫子跟踪系统管理跟踪起来。
