HTML5教程

618前端竞品分析研究(互动篇)

本文主要是介绍618前端竞品分析研究(互动篇),对大家解决编程问题具有一定的参考价值,需要的程序猿们随着小编来一起学习吧!

作者:吉玉

智能化测试

在互动中经常需要维护大量的状态,对这些状态进行测试验证成本较高,尤其是当有功能变动需要回归测试的时候。为了降低开发测试的成本,在这方面使用强化学习模拟用户行为,在两个方面提效:

  • mock接口:将学习过程中的状态作为服务接口的测试数据;
  • 回归测试:根据mock接口数据回溯到特定状态,Puppeteer根据强化学习触发前端操作,模拟真实用户行为;

什么是强化学习呢?

强化学习是机器学习的一个领域,它强调如何基于环境行动,获取最大化的预期利益。强化学习非常适用于近几年比较流行的电商互动机制:做任务/做游戏 -> 得到不同的奖励值 -> 最终目标大奖,在这类型的互动游戏中,奖励是可预期的,用户的目标是使得自己的奖励最大化。这个过程可以抽象为马尔科夫决策模型:玩家(agent)通过不同的交互行为(action),改变游戏(environment)的状态(state),反馈给玩家不同的奖励 (reward);这个过程不断循环迭代, 玩家的最终目标是奖励最大化。

接下来,我们使用比较简单的Q-learning,来实现类似的智能化测试目的。

Q-learning

对于不同状态下,Q-learning的Q(s,a)表示在某一个时刻的s状态下,采取动作a可以得到的收益期望,算法的主要思想是将state和ation构建一张Q-table来存储Q值,根据Q值来选取能够获得最大收益的动作。Q值的公式计算如下:

Q值计算公式

其中,s表示state,a表示action,α为学习率,γ为衰减率,r表示action能带来的收益。

这个公式表示当前状态的Q值由“记忆中”的利益(max Q[s',a])和当前利益(r)结合形成。衰减率γ越高,“记忆中”的利益影响越大;学习率α越大,当前利益影响越大。Q-learning的目标是通过不断训练,最后得到一个能拿到最多奖励的最优动作序列。

在赛车游戏中,玩家的交互行为包含购买车厢、合成车厢、做任务获得金币(为了方便理解,此处简化为一个任务);玩家从初始化状态开始,通过重复“action -> 更新state”的过程,以下的伪代码简单的说明我们怎么得到一个尽量完美的Q表格:

// action: [ 购买车厢,合成车厢,做任务获得金币 ]
// state: 包含等级、拥有车厢等级、剩余金币表示

初始化 Q = {}
while Q未收敛:
  初始化游戏状态state
  while 赛车没有达到50级:
    使用策略π,获得动作a = π(S)
    使用动作a,获得新的游戏状态state
    更新Q,Q[s,a] ← (1-α)*Q[s,a] + α*(R(s,a) + γ* max Q[s',a])
    更新状态state
复制代码

简单的demo地址:
github.com/winniecjy/6…

Puppeteer

由上面Q-learning的训练过程,我们可以得到一系列的中间态接口作为mock数据,可以很快的回溯到特定状态进行测试,这一点在回归测试的时候十分有用。但是仅仅只是自动mock数据对效率提升还是有限,在618互动中,友商的互动团队结合Puppeteer对整个流程进行自动化测试。Puppeteer是chrome团队推出的一个工具引擎,提供了一系列的API控制Chrome,可以自动提交表单、键盘输入、拦截修改请求、保存UI快照等。

结合Puppeteer的一系列操作逻辑,部分是可以沉淀成为一个通用的测试环境的,比如:

  • 不同用户类型,如登录、非登录、风险、会员等;
  • 接口拦截mock逻辑;
  • 页面快照留存;
  • 页面性能数据留存;
  • 其他常见的业务逻辑,如互动任务体系,跳转后等几秒后返回,加积分;
  • ...

弹窗规模化

在互动中,弹窗一直是视觉表现的一个重要组成部分,对UI有比较强的定制需求。

友商的思路是将所有的逻辑尽可能的沉淀。对于电商场景来说,弹窗的业务逻辑是可穷举、可固化的,而互动场景之下,UI定制化需求很高,所以将UI层抽离, 仅对可复用的逻辑进行固化,以DSL + Runtime的机制动态下发。

表达层和逻辑层分离

结合这一套逻辑层模型,表达层/UI层也可以相应的结构化。根据项目 > 场景 > 图层的维度,静态配置和动态绑定相结合,搭配对应的配置平台就可以实现动态下发。

总结

对于智能化测试,80%的流程其实成本是相对较低的,从测试用例的生成到puppeteer自动化测试,都是可以参考学习的,图像对比的部分需要较多训练,对于固化的功能可以进行探索,如果是新的模式性价比较低。

对于弹窗规模化,部门内部的做法是将弹窗沉淀成一个通用的组件,只包含通用的兼容逻辑,包括显示/隐藏、弹窗出现底层禁止滚动、多弹窗层级问题等。对于UI和其他业务逻辑,复用性较低,所以每次都是重写。这种做法尽可能地保持了组件的通用性,在会场线比较适用,因为会场线的弹窗一般不包含业务逻辑(如抽奖、PK等),但是对于互动线来说,复用的内容相较于弹窗的“重量”来说显得有些微不足道。 友商的沉淀思路前提在于上游接口的逻辑需要可复用,上游逻辑如果无法固定下来,前端的互动逻辑也较难固化。总体来说,友商在互动方面的沉淀思路大部分是从开发提效出发,主要供给内部使用;京东内部已有类似的互动提效方案终极目标是盈利,如京喜的社交魔方平台和最近正在成型的满天星平台,所以沉淀方式都是以成套的H5。

参考

[1] 生产力再提速,618互动项目进化之路
[2] 机器学习相关教程 - 莫烦
[3] Puppeteer docs


欢迎关注凹凸实验室博客:aotu.io

或者关注凹凸实验室公众号(AOTULabs),不定时推送文章:

image

这篇关于618前端竞品分析研究(互动篇)的文章就介绍到这儿,希望我们推荐的文章对大家有所帮助,也希望大家多多支持为之网!