一 背景
随着推荐策略不断地迭代更新，网易新闻的内容形态逐渐增加，内容特征更加精细化，用户特征不断丰富，对应的推荐策略也愈加复杂，保障线上推荐服务的稳定性成为质量保障团队工作的重要组成部分。通过逐步摸索、探索，质量保障团队根据新闻推荐系统业务的特点，总结出一套较为适应新闻推荐系统业务迭代的测试方法，从而提高业务测试的质量与效率。
本文大致阐述当前新闻推荐业务测试主要方案，主要有：
新闻推荐系统的基本特点及测试难点；
为应对上述业务测试难点，测试团队的应对方案；
为提高业务测试效率做的应对方案；
业务测试未来努力方向。
二 新闻推荐业务测试难点
1 推荐整条链路环节多
一条用户请求通过客户端达到推荐系统后，首先召回模块需要根据用户的画像、行为等结合相关召回策略召回内容数篇，再经过一系列的过滤规则筛选出可以推荐的内容，接着这些文章经过粗排、精排打分得到各自分数，最后各内容分数结合重排策略选出本次请求最终的推荐结果。每一个环节推荐系统会根据用户特征针对各类内容特征做多种策略调整，各环节的策略都会影响到最后的推荐结果。测试时如果只在最后结果中判断往往无法验证中间环节策略的有效性。![]()
2 用户画像特征复杂
推荐策略根据不同用户特征维度制定不同的推荐策略，用户画像特征多种多样，比如基本的用户信息（用户基本信息等），基于用户点击、浏览等多种行为划分不同用户活跃度、用户偏好等特征，在做业务测试时，根据策略针对的具体用户受众，选取符合条件的用户画像进行校验。3 内容形态多样，内容特征多
新闻内容的形式除了普通的图文和视频类型，还有各类UGC内容形式，不同的文章样式对应的不同推荐策略；除了内容形态，通过模型识别、人工打标等多种方式赋予文章不同维度的特征属性，推荐策略会根据不同的文章特征制定不同的推荐策略。4 上线迭代周期短速度快
由于为纯服务端工程，需求大多不需跟随客户端大版本，平均周需求数10+，产品迭代速度快，平均测试时间1.5h/需求，测试时间短。三 质量保障改进
针对推荐业务测试的难点，结合业务测试现状，具体问题具体分析，在业务测试、性能测试上分别做了不同维度的测试方法改进，以求提高测试质量。1 业务测试改进
1.1 增加各环节日志输出
在业务测试中，需求可能是对召回、过滤、排序等任意中间环节进行策略调整，其逻辑实现的结果无法直观的在最后推荐结果中展示，可能存在：- 对于一些文章提权、降权、截断的逻辑无法测试实际是否符合逻辑；
- 问题定位只能依赖开发同学debug调试，效率较低；
针对这类问题，在需要精细验证的环节增加日志，根据每个环节的逻辑特性增加详细日志，规定日志的统一格式，便于新功能后续解析。
![]()
1.2 测试可控化
测试文章召回可控制
推荐系统各环节逻辑都是针对本次请求召回的内容做处理，要验证后续逻辑是否符合预期，召回内容匹配测试需求便极为重要。而召回模块是根据用户特征及其本次请求参数来做内容的召回，召回的内容量较大，且召回逻辑复杂，许多测试场景需要经过多次构造请求才可触发，测试同学无法自行构造召回的内容数据，不能控制测试数据源，在验证一些特定内容推荐处理逻辑中，如果召回中没有此类文章，便无法验证后续逻辑是否符合。所以针对这一问题，在召回中增加自定义文章编辑，测试同学可以将需要验证的文章通过配置，写入本次请求中，从而验证对应逻辑。![]()
测试用户特征可控制
在用户画像方面，可以通过重写特征构造测试所需的用户模型。![]()
在用户行为上，可以通过向redis中写入推荐历史、点击历史等，模拟用户行为，构造所需的用户请求。![]()
1.3 控制变量
由于推荐各环节策略较多，同篇文章可能会命中多种处理逻辑，在这种情况下就很难确定是需要测试的逻辑是否真正生效。比如过滤、权重修改等环节，同篇文章可以命中同一模块多种逻辑，很难确定被测逻辑是否生效。针对这一情况，将过滤器等需要控制变量的逻辑在测试过程中调整为配置化。例如过滤环节有过滤器A、B、C等，增加过滤逻辑黑名单、白名单，黑名单可以做到不走某一指定过滤器（例如不走A、B过滤器），白名单可以做到只走某一指定过滤器（例如只走C过滤器）。本条请求是否走哪条逻辑测试QA可以自己指定，这样就可以准确将被测的逻辑分离出来，验证其是否符合预期。1.4 内容强推
由于推荐结果不固定，在与后台客户端联调的时候，如果只依靠正常推荐的结果，会存在前端同学想验证的内容形态推不出的情况，所以针对这一情况，做了内容结果强推，只需要配置指定文章和展示样式，就可以在配置的账号中推出，并集成到测试平台中，前端同学可自己操作，不需要费时费力刷数据。![]()
2 性能测试改进
2.1 压测数据改造
最初的性能测试，采用的是各参数自行构造后随机组合构成压测请求，以便于覆盖多种业务场景。但真正使用一段时间后，发现对场景、各类用户的覆盖能力还是存在较大缺陷，而且灵活度低，新增参数、版本号更新都需要将配置文件进行同步更新。所以后续在压测请求的构建上采用引入线上真实流量，提高了测试场景的覆盖率，针对一些特定少数用户群体的策略，针对性构造压测数据。![]()
2.2 推荐质效平台-性能测试平台落地
之前的性能测试在日常应用中主要存在以下问题：
针对这些问题推荐质效平台-性能测试平台结合推荐性能测试的基本需求，将NPT压测触发与哨兵平台数据进行整合，不同栏目通过配置将任务id映射到NPT对应任务，并将压测接口所需参数、性能衡量标准配置化。压测时，通过压测平台调用NPT接口实现自动触发。完成压测后，自动从哨兵中获取对应栏目配置的监控项，并将所有压测数据保存至数据库中。同时，将本次压测的所有监控数据格式化返回到前端进行展示，并将数据是否在各栏目规定阈值内予以标注。
![]()
- 操作便利化。只需要输入必要项（服务器IP、时间、并发数）就可以进行对应栏目的性能测试。
![]()
- 各个服务性能测试标准化、个性化。在数据收集上，采用配置化，可以根据每个栏目的具体需求选择需要收集的哨兵监控项及判断阈值，制定性能测试通过的标准阈值，压测结束后自动生成测试报告，对于超过标准的数据予以提醒，开发自测时也可以直接查看性能数据是否测试通过。
![]()
- 性能测试报告输出更具灵活性。对于一些超过标准的压测数据可以根据具体情况修改其是否符合预期。压测过程中出现的异常，判断是否符合预期，可通过平台进行忽略或者标注。
![]()
- 性能测试数据对比可视化。自动将本次压测配置的监控项数据写入数据库中，查看时生成生成图标，便于查询及对比。
![]()
- 性能测试结果和需求单打通。针对具体需求的性能测试不再需要手动记录性能测试结果与数据，压测通过后可直接同步至对应JIRA，便于查看及后续复盘。
![]()
四 效能提升
除了对业务测试质量进行提升，效率的提升也尤为关键。对此质量保障团队针对测试效率痛点做出切实有效的改进。1 测试用例配置化、自动化
由于推荐需求的特殊性，大多数策略是通过ab实验的模式进行，且有些ab实验之间是互斥的，测试中频繁在昆仑平台修改实验配置低效且易出错；引擎迁移至诺亚容器以后，接口地址不再为以前固定的物理机地址，而是不固定实例IP，现有测试架构不支持对不同IP进行快速响应测试，要修改测试代码，同时也无法灵活随客户端版本升级修改版本号等其他参数等；针对一系列的测试问题，对现有构建参数方式进行改造，部分变动类参数例如version等提取出，不再写死在代码中，改造为可配置化，实现参数可配置化，对于ab实验的配置上，也和开发商议对测试接口进行改造，新增参数，通过参数直接将需要验证、排除的实验配置，输出测试结果，极大的提高了测试效率，缩短了测试时间。![]()
2 需求管理集中化
推荐系统的每个需求正式上线前，一般需要在线上进行ab测试，数据符合全量条件后，除了工程代码需要全量，测试case也相应需要加入到回归case中，但由于需求量大，很容易在增加全量回归case时遗漏部分需求，所以为使需求管理更明确，避免漏掉某些全量需求，结合推荐测试现状在测试中增加需求管理，清晰直观的展示目前case现状。![]()
3 提供自测工具，释放测试人力
对于部分模块测试，每周需求迭代较多，QA人力紧张，比如召回模块，之前平均每周的需求10+，天均需求达到8+，且存在冒烟case 跑不通的提测情况，反复沟通QA和开发都耗时耗力。针对这一情况，结合具体项目的测试现状与项目逻辑的具体情况，开发测试自测工具提供给开发同学，制定自测通过的衡量标准，尽可能释放测试人力。召回栏目提供自测工具后，极大释放了QA人力，显著提升了测试效率。![]()
五 未来规划
后续在新闻推荐业务系统的测试上，重点依旧倾向于测试效率和测试质量的提升，将还未测试全面的业务场景逐步挖掘进行深入测试，尽可能保证各环节逻辑都应测尽测，提升整体测试质量；提取更多需求测试共性，将这些共性结合推荐系统特点开发自动化测试工具，提高测试效率，不断优化及完善推荐业务测试架构。