关于javascript: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 值的公式计算如下：

其中，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 地址：
https://github.com/winniecjy/…

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 互动我的项目进化之路](https://mp.weixin.qq.com/s/oe…
[[2] 机器学习相干教程 – 莫烦](https://github.com/MorvanZhou…
[[3] Puppeteer docs](https://github.com/puppeteer/…

欢送关注凹凸实验室博客：aotu.io

或者关注凹凸实验室公众号（AOTULabs），不定时推送文章。