搜索引擎应用参与运作的角色划分：分发请求/合并查询结果的merger，以及查询服务的searcher。
搜索引擎系统部署可以划分为：
A、1个Merger带N个searcher，searcher上数据一样 (分布式单个集群多台机器) ，N>=1且为整数。
B、1个机器同时充当Merger以及searcher (单机版)。
C、为避免2)单点故障，几台机器同时为merger/searcher，机器的数据一样。
D、M个分布式单个集群多台机器组成1个大型的分布式多集群多机器的复杂环境。
实践中C、D两种部署模式都是存在的。
大数据量、高吞吐率的都采用D，避免单点故障。小型的数据采用C，节约成本。
单机上搜索引擎的模块划分一般有：
1、索引模块：为海量数据（数据库导出的文件数据）建立索引文件（依照一定数据结构格式保存为二进制文件）。
2、查询模块：接收http请求，查询本机硬盘上的索引文件，返回文档ID以及第二次查询时返回具体的内容。
3、即时更新模块：加入新的数据，可以从0开始重新建索引，也可以在原有基础上增加索引。
4、分布式模块：merger/searcher多台机器的网络通信。
5、CACHE模块：这里可以做查询请求的缓存，也可以做查询结果的缓存，但缓存后者的话，将极大消耗系统内存。
6、其他管理模块。
7、外部接口。
基于如上复杂的系统架构，尤其是D模式，我们在测试当中也碰到相当多棘手的技术问题：
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施加高峰压力，抽样检查查询请求的正确性。