三层架构下，优酷视频搜索测试体系很复杂吗？ _架构

作者| 阿里文娱测试开发专家熙闫责编 | 夕颜简介
优酷搜索承担着内容分发场的头部兵的重任，海量的视频内容都要依赖搜索触达和呈现给用户，而且逐渐扩大范围，开始向阿里文娱全系产品提供搜索服务和能力。
面对如此复杂且对稳定性、精准性要求极高的系统，质量保障工作显得尤为重要和极具挑战性。本文将为大家介绍视频搜索的质量体系是如何构建和发挥作用的。

业务特点1. 视频搜索架构特点

支持复杂多样的上层业务场景，业务逻辑复杂；
从搜索开始到结果返回的整个业务链路长，涉及的模块及外部依赖多；
算法依赖数据，底层数据变更会引起上层算法结果变化。

2. 测试难点

业务链路长且复杂，用例覆盖率等难以进行有效度量；
离线和实时数据变更如何影响业务，数据质量的监控如何和业务紧密结合；
算法模块存在复杂性及不可解释性，算法效果难以进行有效评估；
海量数据中单个 badcase 无法说明问题，如何有效发掘共性的 badcase 。

3. 质量保障方案

文章插图
工程质量1．回归
回归测试主要是上线发布前的测试，目的在于提前发现 bug ，保证发布质量。目前各模块的回归测试均已作为研发流程的一环，交由研发自行进行冒烟，不管是否走提测流程，均能在一定程度上把控业务质量。
我们根据链路的分层，针对各层模块进行了各模块自身的功能回归建设。各模块测试用例的自动化回归依托于冒烟平台，其可实现任意环境的快速回归，目前已积累回归用例 5000+ ，定时线上巡检，分钟级发现问题。

2．监控1）功能监控仍然是根据链路的模块划分，进行分层监控。监控仍依托于冒烟平台，并存储各模块日常。
冒烟监控数据以及真实 bug 数据。目前通过巡检已累计发现线上 bug50+ 。具体冒烟监控数据大盘如下图所示。

文章插图
2）效果监控线上效果监控的目的在于快速发现线上效果问题，保证线上质量；此外通过固化每次效果
监控数据，监控线上效果问题的长期变化趋势，以辅助研发进行算法迭代优化，最大化利用人工评测数据。已经形成了生成监控集合->定时监控->发现问题->解决问题闭环的处理机制。

文章插图
算法质量
1．数据1）离线
借助集团已有平台的监控能力，定制业务细则，监控流程基本分为几个阶段：存在原始表，创建对应表的分区及监控规则，订阅分区规则，原始表周期任务执行结束自动触发 dqc 上对应表的对应分区的规则，如果异常会根据订阅内容报警。
step1: 确定监控哪些表。比如我们监控 A 表，该节点监控规则一旦失败是否要中断后续的生产流程，如果需要中止后续的生产流程，那 stepn 配置强规则即可,此时要保证监控规则是业务合理的，当然一旦中止数据生产流程，我们要承受住多方的考验，节点多次失败账号健康分会受影响，任务的执行也会受影响；如果不需要中止后续的生产流程，有两种方案，一是创建影子表，监控影子表(浪费一个存储周期的空间)；二是所有规则置为弱规则(短信告警无法判断报警的严重程度) 。实践中，重要的宽表数据我们采用了监控影子表方案，次重要的表采用了对原始表全部配置弱规则的方案。
step2：在监控平台创建分区，用来指定是要监控哪天的数据。
step3:配置规则，规则可分为通用规则和特性规则。数据量重要度属于 P0 级，采用数据量绝对值>阈值；同时采用了 7 天趋势绝对值变动在预警值在 10% ， 20%(不同业务阈值根据业务需要设定) 。表数据量突增和突降在优酷场都不合理，所以采用了 7 天平均值波动+绝对值模式。通用规则是各字段通用的规则，基本包含是否非空，是否为 0 等等，体现在数据监控上面就是非空的数据量|数据占比变化趋势是否符合预期，值域非 0 的的数据量|数据占比变化趋势是否符合预期。特性规则需要视业务特性而定，采取单字段 max、min、均值、总量，组合特征数量、变化率、空置率等个性化定制规则。