在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会返回结果：

　　用户尝试登录，登录页面显示失败。等类似的结果。

　　在解决问题之后，我不仅反省，在新的解决方案中，即没有用到高新技术，也没有复杂算法，

　　是什么让我们时隔这么久，才发现并解决这个问题呢？