关于那些重复的缺陷报告
作者:网络转载 发布时间:[ 2012/5/18 9:37:12 ] 推荐标签:
在softwaretestingclub上,看到一篇文章“the duplicate paradox",文中提到:
作为一个测试员,我们花时间发现,钻研,进而找到问题;
为其编写缺陷报告,重现步骤,验证方法。
而当一切都做完提交给研发人员后,得到的答复是:这东西有人报告过了!
真上火啊!
碰巧前一阵子,我也发现了类似的问题,于是把自己的想法写下来跟大家分享。
我的故事是这样的:
作为一个测试员,我经常被分配到不同的组里,每个组呆的时间都很短??短到我没空去熟悉已经存在的几千个缺陷库??所以在测试过程中,一半左右我发现的问题,在跟研发人员沟通后,被归类为已知问题。
在记录并深入研究这些问题后,才被告知,“这事儿我们知道,是没修,低优先级”,是一件很让人灰心丧气的事儿;但是如果不沟通,直接提交缺陷报告,会给研发人员造成很大的负担,他们要找到重复的一个或几个问题,将他们放在一起修好。
于是我每次找到新问题,去询问研发人员,但后来发现,这也不行。
在缺陷库里有几十个记录的时候还好,但我们的缺陷库里有几千条记录,没人能够全部记住。于是我得到答案越来越多地变成了:”你先搜索一下,看看有没有重复的,没有再提交“。
这可为难我了。因为提交缺陷报告的人不同,其风格五花八门,表述不清楚是主要问题;我们的缺陷库管理系统并没有提高非常好的搜索功能。
深入思考之后,我把问题归纳为2点:1缺陷报告的格式不统一;2缺陷库系统的搜索功能不完善。
因为这两个原因,导致了测试员很难方便地在提交缺陷报告前,搜索到前面提交过的类似记录。
找到问题,解决起来相对容易。
在跟测试员协商后,我们决定将缺陷报告的格式统一起来。
新格式将满足所有可能的客户及需求,我们列举如下:
客户1:研发人员,在收到报告后,会尝试重现以确定问题
客户2:测试员,在收到修正过的版本后,会试图验证
客户3:产品经理,通过报告的严重程度标签,来判断对客户的影响
客户4:未来的研发或测试员,将需要用到若干关键字对该问题进行搜索
有了需求,我们进而将新格式定义如下:
1、重现步骤
2、不合理之处
3、合理之法
4、影响之坏
5、搜索之猜测
通过1和2,研发人员可以了解该报告所揭示的问题;
加上3,测试人员可以很容易的在新版中验证对该问题的修复;
通过4,产品经理可以很好的评估该问题对客户的影响;
通过5,留待搜索之用。(搜索的关键字,可以参考回归测试笔记中,关键字一节)
第一个问题解决后,我们再来看搜索功能缺失。
在原有系统上做插件,将搜索范围模糊化,是我们的第一个方案。
如:搜索: 登录 失败,翻译成:*登录*失败*,以此类正则表达式提供给缺陷管理系统。
但尝试后,发现大范围的搜索会导致系统性能降低,从而倒是搜索效率低,不实用。
于是,作为替代方案,我们想到了GDS - Google Desktop Search。
它可以将本地文本文件进行索引,而后提供类似Google网页搜索的功能。
一个新的缺陷搜索引擎这么诞生了,我们将缺陷库里的资料导出成文件,一个报告对应一个文本文件。
在本地只需要搜索关键字:登录 失败,GDS会返回结果:
用户尝试登录,登录页面显示失败。等类似的结果。
在解决问题之后,我不仅反省,在新的解决方案中,即没有用到高新技术,也没有复杂算法,
是什么让我们时隔这么久,才发现并解决这个问题呢?
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11