搜索的测试，KPI驱动？上面需求驱动？这只是一个方向，表明测试的必要，覆盖率的必要。
针对具体场景其实需要针对性处理的，完全“照做”其实不会探测到搜索的“骨子里”。
那什么是搜索的“骨子”呢。下面YY下，当然仅供参考，因为所处角度不同，理解不同。

1.架构层
a.框架的联动性、集群的最大张力、极端情况的适应性
框架联动性是说，各个模块之间的通信和确认是否靠谱，并且多大机器集群的上限上靠谱，靠谱率多大。
集群最大张力是说，针对某个需求的尖端需求满足性，例如某个应用查询大，某个应用索引数据大，是否会出现大应用的堵塞其他小应用，或者小应用出现饥饿。

极端情况适应性是说，在后端那些模块彻底挂了时候，前端影响的评估和防范


b.回归+自动化
对于框架基本上回归一次，下一次间隔会更长。并且要求全自动化还是比较难的。

2.核心模块
a。核心模块，query、dump、build、监控三大块。
对于query的覆盖其上没必要和框架耦合起来测，将query模块独立覆盖、回归
对于dump也是如此。
对于build，功能测试只是一方面，重要的是兼容性测试。
对于监控，重在试运行。

3.排序质量
a。排序模型和样本集的构建
b。周期性对排序调整后排序质量的自动化量化