搜索引擎测试难点.docVIP

  1. 1、原创力文档(book118)网站文档一经付费(服务费),不意味着购买了该文档的版权,仅供个人/单位学习、研究之用,不得用于商业用途,未经授权,严禁复制、发行、汇编、翻译或者网络传播等,侵权必究。。
  2. 2、本站所有内容均由合作方或网友上传,本站不对文档的完整性、权威性及其观点立场正确性做任何保证或承诺!文档内容仅供研究参考,付费前请自行鉴别。如您付费,意味着您自己接受本站规则且自行承担风险,本站不退款、不进行额外附加服务;查看《如何避免下载的几个坑》。如果您已付费下载过本站文档,您可以点击 这里二次下载
  3. 3、如文档侵犯商业秘密、侵犯著作权、侵犯人身权等,请点击“版权申诉”(推荐),也可以打举报电话:400-050-0827(电话支持时间:9:00-18:30)。
  4. 4、该文档为VIP文档,如果想要下载,成为VIP会员后,下载免费。
  5. 5、成为VIP后,下载本文档将扣除1次下载权益。下载后,不支持退款、换文档。如有疑问请联系我们
  6. 6、成为VIP后,您将拥有八大权益,权益包括:VIP文档下载权益、阅读免打扰、文档格式转换、高级专利检索、专属身份标志、高级客服、多端互通、版权登记。
  7. 7、VIP文档为合作方或网友上传,每下载1次, 网站将根据用户上传文档的质量评分、类型等,对文档贡献者给予高额补贴、流量扶持。如果你也想贡献VIP文档。上传文档
查看更多
搜索引擎测试难点

衡量搜索引擎系统功能质量方面有2大指标,查询率、查准率。   性能方面从吞吐率、响应时间、系统资源消耗等多方面综合考虑。   搜索引擎应用参与运作的角色划分:分发请求/合并查询结果的merger,以及查询服务的searcher。   搜索引擎系统部署可以划分为:   1) 1个Merger带N个searcher,searcher上数据一样 (分布式单个集群多台机器) ,N=1且为整数。   2) 1个机器同时充当Merger以及searcher (单机版)。   3) 为避免2)单点故障,几台机器同时为merger/searcher,机器的数据一样。   4) M个分布式单个集群多台机器组成1个大型的分布式多集群多机器的复杂环境。   实践中3)、4) 2种部署模式都是存在的。   大数据量、高吞吐率的都采用4),避免单点故障   小型的数据采用3),节约成本。   单机上搜索引擎的模块划分一般有:   ● 索引模块:为海量数据(数据库导出的文件数据)建立索引文件(依照一定数据结构格式保存为二进制文件)   ● 查询模块:接收http请求,查询本机硬盘上的索引文件,返回文档ID以及第二次查询时返回具体的内容   ● 即时更新模块:加入新的数据,可以从0开始重新建索引,也可以在原有基础上增加索引。   ● 分布式模块:merger/searcher多台机器的网络通信。   ● CACHE模块:这里可以做查询请求的缓存,也可以做查询结果的缓存,但缓存后者的话,将极大消耗系统内存。   ● 其他管理模块   ● 外部接口   基于如上复杂的系统架构,尤其是4)模式,我们在测试当中也碰到相当多棘手的技术问题:   1) 海量数据是否都按预期的分词算法建立索引了呢?   2) 机器分词的效果与手工分词相差有多大呢?   3) 海量查询的返回结果是否多查了?   4) 海量查询的返回结果是否漏查了?   5) 海量查询的返回结果的加亮、标注如期加了?   6) 海量查询的返回结果中相关性分数计算是否正确?   7) 海量查询的返回结果积分计算是否正确了呢?   8) 海量查询的返回结果积分相同时,排序的先后依据唯一么?   9) 加入即时更新模块后,每次查询结果都不同,新建的索引内容是否都反馈到查询结果里面了呢?   10) 海量数据时CACHE是否预期CACHE该cache的内容?   11) 海量数据时CACHE是否依照一定的过时算法令cache的内容失效呢?   12) 应用程序在32位LINUX操作系统和64位的LINUX的索引、查询结果是否依然一样?   13) 应用程序在不同的OS上索引、查询结果是否依然一样?   我们在实践中,针对查询结果正确性有3类方法处理以上问题:   第一类,基于人工肉眼对比,极度耗费脑细胞。   1) 少量数据单机测试准确性   2) 少量数据1个集群,搭建1merger 1searcher测试准确性   3) 少量数据1个集群,搭建1merger多searcher测试准确性   4) 少量数据多个集群,搭建1merger多searcher测试准确性   第二类,经过人工对比确认基本功能无大问题后,开发linux shell脚本或者loadrunner脚本比较部署方式不同但测试返回结果理当相同的。这个方法也帮我们发现了一些BUG   第三类方法,直接测试大量数据多个集群,搭建1merger多searcher测试准确性。   这个时候采用loadrunner施加高峰压力,抽样检查查询请求的正确性。   对于分词结果、相关性的结果,有人可能建立另外按照同样的算法以及输出格式,由2个不同的开发工程师实现,再对比同样的数据分词、相关性是否相同。在项目开发时间从容的情况下,可以考虑这么做的,但现实中有几个项目时间从裕?呵呵,我没有这么好运气遇上。

文档评论(0)

peain + 关注
实名认证
文档贡献者

该用户很懒,什么也没介绍

1亿VIP精品文档

相关文档