搜索测试的测试点

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