搜索测试的测试点

搜索引擎应用参与运作的角色划分:分发请求/合并查询结果的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施加高峰压力,抽样检查查询请求的正确性。

posted on 2010-02-24 13:27  任斌  阅读(2478)  评论(0编辑  收藏  举报

导航