算法测试之实践与小结

阿凡达2018-08-14 09:03
因项目需要,我从上半年开始接触算法测试。本文主要对于算法测试的类型和方法这里做一下总结。在项目中,所接触算法测试的类型主要包括如下图所示的几个方面
一,算法模型
根据之前的调研,在测试阶段,对于新采用的算法模型,比如协同过滤,机器学习算法等的测试,很多项目上只是回归下功能和流程,不对具体的算法模型进行评测;一般会通过线上或者灰度发布的推荐效果来评测算法模型。
那么,在测试阶段有没有什么方案可以评测算法模型呢?当然有,但是要结合项目情况,具体问题具体分析。
以下是我们在一次大改版中的实践:
  1. 首先需要制定评测标准,和产品方沟通后了解他们的期望,并把产品方的期望量化成一条条评测的约束条件
  2. 然后约定通过测试的标准即:算法结果能满足约束条件的最低比例
  3. 最后准备测试数据,统计计算结果能达到各项约束条件的比例
具体实现方案可参考我的另一文章: 《算法测试之算法模型评测实践》 ,下面是部分结果展示:
        
二,需求规则
项目中的算法任务,往往包含一些明确的需求规则。比如一个推荐给用户的内容列表,可能要求:分页加载过程中内容不能有重复;过滤掉屏蔽的或者特定的内容;按照某个字段大小排序;推荐总数量的限制等等。
对于这些比较明确的规则,我们一般通过接口来测试,可以调用算法的接口或者直接调用服务端的接口,对返回结果校验是否符合规则;如果符合则通过,不符合则不通过。比如,以下是验证推荐过滤规则的一个接口用例的例子:
       
三,算法数据
算法的测试的过程中,我们往往需要接触到一些算法计算的结果数据,比如资源的热度分,或者相似度分数等。这些数据一般通过算法计算后存放到数据库中,很多情况会回流到服务端数据库中。
对于这些数据的测试,可直接从数据库表中取数据校验,主要测试两个方面,以热度分为例:
  1. 检查热度分的结果,是否符合热度计算的规则;
  2. 检查数值本身的规范,比如不能为负数;保留小数点几位等。

四,功能测试
在项目中,算法任务有时也会和一些客户端的功能相结合,举几个例子
  1. 负反馈过滤如用户选择不喜欢后不再出现;
  2. 曝光过滤如规定出现几次后不再出现;
  3. 刷新规则如规定刷新后推荐数据的变化;
  4. 还有一些如关注等操作后对于算法的实时影响等。
对于这部分的测试,我们一般和客户端的功能测试结合起来,手动操作客户端,并检查后续反馈的算法结果。

五,推荐效果的测试
推荐算法的效果一般有推荐准确率、召回率等指标。离线的推荐算法效果的评测,一般会把线上用户已有的操作数据,按照一定比例分为两部分,大部分用于算法的输入数据,通过算法得到推荐结果,再利用剩下的小部分数据来检验推荐效果。但是,实际项目中,往往存在已有操作数据量不够大、用户未看到真实推荐等因素,导致离线效果评测的不准确,难以信服。
所以项目中,一般在算法上线后,通过实际线上数据的点击率、uv点击率、次日回访率等指标来衡量推荐算法的效果。而具体的评测,一般通过ABTest来对比算法的效果。
首先,简单介绍下ABTest的引入实现:,
  1. 给每个算法定义一个算法id;
  2. 确定分流方式,比如随机分流或者用户分流等;
  3. 确定每个算法之间的分流百分比;
  4. 根据用户id或者设备id等通过一定算法计算得到一个分流分数;
  5. 根据分流分数和分类百分比,来确定采用的算法id。
然后,经过埋点统计等,可以计算得到每个算法对应的点击率等指标,统计结果可记录如下例子:
刚开始接手ABTest的报告,我们是采用手动统计的方式,然而在这些指标数据已经存放到数据库的情况下,每次的统计其实是手动把数据填到表格中并计算变化比例,大部分都是重复劳动。于是,做了一个自动生成ABTest报告的工具,减少QA的工作量。如下图所示:  
 
选择指标,算法和时间后,即可得到下图的结果:
       

六,降级方案及性能优化
算法的引入有可能会带来一些性能问题,为了保证服务质量,一般会设计针对特定场景的降级方案。目前我所接触到的降级方案主要以设置缓存为主,包括两个层次:
  1. 算法缓存,针对实时性要求不强的场景,比如搜索算法,设定缓存的关键字或者具体资源,以及缓存时间等;
  2. 服务端缓存,针对有性能问题的算法接口,服务端做的缓冲,在算法服务取数据失败的情况下,依然可以正常提供给用户数据,比如缓存第一页数据,缓冲热门内容等。
那么,针对降级方案的测试,主要从以下几个方面开展:
  1. 针对服务端缓存,可以手动停止算法服务,查看服务端是否切换到缓冲;
  2. 不管是算法缓存还是服务端缓存,都可以准备缓存数据,模拟用户可到达的缓存场景,验证方案
  3. 功能和流程的回归测试,不管做了哪种降级方案,都需要保证原有产品的功能
  4. 性能测试,显然,针对有性能问题的接口,在做了缓存之后性能会大幅提高,比如下图是个算法接口压测的例子,可以看出:同一环境和并发数的情况下,前几分钟性能较差,后几分钟开始走缓存了,TPS明显升高,RT降低:
       
当然,还有一些其他的性能优化的任务的测试,关于具体性能测试这里就不展开论述了,相信很多童鞋都比我有经验。

七,接口联调
在项目中,服务端接口和算法接口往往是独立的模块,对于前端的请求,服务端需要调用算法接口,再返回给前端。因此,在这条链路里,服务端和算法的接口联调也是很重要的部分。
对于这部分的测试,往往需要具体问题具体分析,这里总结两个测试方向:
  1. 造算法数据,因为在测试阶段,受到测试数据等限制,往往不能完全模拟线上的链路环境,因此,需要我们造一些算法数据来测试;
  2. 接口健壮性的测试,比如做一些异常测试,保障链路的通畅。

八,测试工具开发
算法的测试,因其测试的特殊性,往往需要开发一些测试工具,帮助测试或者评估风险。比如,进来实现的搜索结果对比工具,具体参考这篇文章 《算法测试之搜索结果对比工具》

本文先总结以上,后续会持续关注并研究算法测试。

网易云新用户大礼包:https://www.163yun.com/gift

本文来自网易实践者社区,经作者陈天昊授权发布。