搜索引擎测试难点

《搜索引擎测试难点》由会员上传分享，免费在线阅读，更多相关内容在行业资料-天天文库。

1、衡量搜索引擎系统功能质量方面有2大指标，查询率、查准率。　　性能方面从吞吐率、响应时间、系统资源消耗等多方面综合考虑。　　搜索引擎应用参与运作的角色划分：分发请求/合并查询结果的merger，以及查询服务的searcher。　　搜索引擎系统部署可以划分为：　　1)1个Merger带N个searcher，searcher上数据一样(分布式单个集群多台机器)，N>=1且为整数。　　2)1个机器同时充当Merger以及searcher(单机版)。　　3)为避免2)单点故障，几台机器同时为merger/searcher，机器的数据一样。　　4)M个分布式单个集群多台机器组成1个大型的分

2、布式多集群多机器的复杂环境。　　实践中3)、4)2种部署模式都是存在的。　　大数据量、高吞吐率的都采用4)，避免单点故障　　小型的数据采用3)，节约成本。　　单机上搜索引擎的模块划分一般有：　　●索引模块：为海量数据（数据库导出的文件数据）建立索引文件（依照一定数据结构格式保存为二进制文件）　　●查询模块：接收http请求，查询本机硬盘上的索引文件，返回文档ID以及第二次查询时返回具体的内容　　●即时更新模块：加入新的数据，可以从0开始重新建索引，也可以在原有基础上增加索引。　　●分布式模块：merger/searcher多台机器的网络通信。　　●CACHE模块：这里可以做查询

3、请求的缓存，也可以做查询结果的缓存，但缓存后者的话，将极大消耗系统内存。　　●其他管理模块　　●外部接口　　基于如上复杂的系统架构，尤其是4)模式，我们在测试当中也碰到相当多棘手的技术问题：　　1)海量数据是否都按预期的分词算法建立索引了呢？　　2)机器分词的效果与手工分词相差有多大呢？　　3)海量查询的返回结果是否多查了？　　4)海量查询的返回结果是否漏查了？　　5)海量查询的返回结果的加亮、标注如期加了？　　6)海量查询的返回结果中相关性分数计算是否正确？　　7)海量查询的返回结果积分计算是否正确了呢？　　8)海量查询的返回结果积分相同时，排序的先后依据唯一么？　　9)加入

4、即时更新模块后，每次查询结果都不同，新建的索引内容是否都反馈到查询结果里面了呢？　　10)海量数据时CACHE是否预期CACHE该cache的内容？　　11)海量数据时CACHE是否依照一定的过时算法令cache的内容失效呢？　　12)应用程序在32位LINUX操作系统和64位的LINUX的索引、查询结果是否依然一样？　　13)应用程序在不同的OS上索引、查询结果是否依然一样？　　我们在实践中，针对查询结果正确性有3类方法处理以上问题：　　第一类，基于人工肉眼对比，极度耗费脑细胞。　　1)少量数据单机测试准确性　　2)少量数据1个集群，搭建1merger1searcher测试准

5、确性　　3)少量数据1个集群，搭建1merger多searcher测试准确性　　4)少量数据多个集群，搭建1merger多searcher测试准确性　　第二类，经过人工对比确认基本功能无大问题后，开发linuxshell脚本或者loadrunner脚本比较部署方式不同但测试返回结果理当相同的。这个方法也帮我们发现了一些BUG　　第三类方法，直接测试大量数据多个集群，搭建1merger多searcher测试准确性。　　这个时候采用loadrunner施加高峰压力，抽样检查查询请求的正确性。　　对于分词结果、相关性的结果，有人可能建立另外按照同样的算法以及输出格式，由2个不同的开发

6、工程师实现，再对比同样的数据分词、相关性是否相同。在项目开发时间从容的情况下，可以考虑这么做的，但现实中有几个项目时间从裕？呵呵，我没有这么好运气遇上。