基准测试集有三部分构成：DocumentSet、QuerySet、RelevantJudgement。在比较多个IR系统孰优孰劣的时候，要做的就是：使用统一的DecumentSet建立索引，然后使用统一的QuerySet去进行查询，最后使用统一的judgement进行评判到底哪个IR系统更优秀。

国外有个专门的组织是干这个事情的，他叫TREC(TextRetrievalConference)。这个会议一直在致力于这样一个基准测试集的维护。当然它维护的是一个英文的文档集，并且是通用的，不适用于中文。但是他的方法和思想我们是可以借鉴的。

我们可以这么做！

个人认为，对于我们这边IR系统的性能测试，可以考虑这么构造我们的测试集：

1、DocumentSet固定一定数量集的offer或者日志等信息；

2、QuerySet这个是关键问题，会很大程度影响到最终结果。我认为可以从下面两个角度来考虑构造这个QuerySet：

● 黑盒的用户角度从使用的角度来考虑可能会影响到性能的地方，比如：输入的查询词数量、返回结果结果的数据量等等。这种方式比较方便，便于实施。但是对于一些有可能会影响系统性能的特定逻辑就考虑不到，比如：一些算法里对于没有结果的Query要做重写，重写的方式可能又有很多等，这种就照顾不到。

● 白盒的工程师角度首先分析线上系统响应时间的log，把响应时间按照长短分成几个大类。比如20ms以上的，10-20ms的等等。然后使用profile工具去分析这些Query的响应时间不一致的根本原因在什么地方。通过这一系列的rootcauseanalysis的分析就能够得到影响性能的几个关键因素。剩下的事情就是构造一些列的Query去诱发这些因素的发生。这些Query就是我们要的QuerySet。

3、RelevantJudgement就是响应时间或者QPS。

建立好这种“基准测试集”以后，我想我们的性能可以尝试这么来做：

● typeⅠ测试(性能测试)对于我们构造好的有限个数的QuerySet，每个Query去做10次查询，取平均值作为该Query的响应时间。这样，如果QuerySet有5种类型的50个Query，那么就有50个结果，代表了在这5种情况下系统的一个性能情况。把这个结果作为性能测试的结果，让大家都看到系统的性能在各种不同情况下的一个表现和变化。

● typeⅡ测试(稳定性测试)为了确保系统能够在线上无故障的运行，我们再做一组稳定性的测试。这种稳定性的测试必须是使用线上Query、多线程的、长时间的、但不需要是“没有思考时间的全压力下”的那种。之所以这样做也是为了真实的模拟线上情况，因为线上运行的时候系统面对的就是这种多线程、时间长度不足24小时(每天要重新build索引，然后重启)、qps也就是有100的这么一种压力。

ProsandCons？

我们采用这样一种方法的好处有：

● 让我们对于IR系统的性能表现和软肋有了更加深刻的认识这点我想无需解释，构造Queryset和执行测试的过程就能够淋漓尽致的体现这一点。

● 彻底解决机器资源的争用问题按照上面的方法来做typeⅠ的测试，很快就能完成，很快就能够出结果。机器资源很好协调。对于typeⅡ的测试，可以在在一台机器上同时运行多个，因为我们的重点是系统长时间运行的可用性，并发数可以是8，但是qps能在一两百就好了，这样来执行测试，即便是有四五个项目在做这种typeⅡ的测试也不会给系统带资源带来多么大的消耗。多条产品线有一套性能测试环境就能满足需求。

● 可以提升后台算法和引擎性能测试的专业化程度我们常说性能测试的初级阶段是施压工具和性能指标收集工具的使用;进阶阶段是系统指标的分析和问题定位;中高阶段就是结合应用的特性，综合考虑系统和应用的监控指标，来综合制定测试方案和分析定位问题了。这样做未尝不是一个好的方向。

这样做的唯一难处就是：我们需要再次拥抱变化。不过，我们是aliren，相信如果大家在权衡利弊后只要相信一件事情是有价值的，那么剩下的就是开搞啦~。

写到最后想起一句话，就把这句话作为结语吧——“工程师的存在价值是：要么把枯燥单调的事情变得自动化起来，要么就是把他们变得的有趣和刺激。”

感谢每一个认真阅读我文章的人，礼尚往来总是要有的，虽然不是什么很值钱的东西，如果你用得到的话可以直接拿走：

 

这些资料，对于【软件测试】的朋友来说应该是最全面最完整的备战仓库，这个仓库也陪伴上万个测试工程师们走过最艰难的路程，希望也能帮助到你!有需要的小伙伴可以点击下方小卡片领取