移动天网是有赞针对客户端搭建的一套主动防控体系，提高客户端的线上质量与稳定性。

本文主要介绍有赞连锁业务稳定性保障的挑战和一些落地实践。

本文是根据有赞中间件团队多年的TCP网络编程实践经验总结而来，目的是为了避免应用因各种网络异常而出现各种非预期行为，从而造成非预期的影响，影响系统稳定性与可靠性。

本文不会涉及TCP的各个基础知识点，主要是总结一些TCP网络编程实践中可能碰到的一些问题，以及相应的经过实践验证的解决方案等。虽然本文档很多细节主要是针对于Linux系统，不过，大部分建议适合于所有系统。

精选小程序发生了一次线上问题，测试阶段的小程序开发码测试ok，但是小程序正式码由于打包问题，"我的订单"页面文件打包失败，导致线上用户访问我的页面白屏。

当前并不能避免该打包问题，为了规避异常版本发布至线上，需要在预发、体验码发布、正式码发布等各阶段进行主流程回归。手动回归测试非常耗时，在发布前的各阶段，测试人员须重复执行大量测试用例，以确保本次上线功能OK且对其他功能无影响。

一遍又一遍执行相同的测试用例，不仅要花费更多的时间，而且还会降低整体测试效率，因此引入微信小程序自动化以解放重复人力。

随着商家对客户精准运营诉求越来越强烈，有赞客户运营相关的业务产品也在近一年不断推陈出新。

有赞预付卡包装出了会员储值这样一款产品，用户在商家店铺里完成特定金额的充值后，会得到商家赠送的权益，比如积分、会员卡、优惠券等。

Fiber 是对 React 核心算法的重构，facebook 团队使用两年多的时间去重构 React 的核心算法，在 React16 以上的版本中引入了 Fiber 架构，极大的提高了大型react项目的性能，也激发了我对其实现的好奇。在研究源码的过程中，能发现很多比较细的点，有任务单元拆分的细，有任务调度、双缓冲、节点复用等优化的细，都非常值得我们学习，接下来就带大家看看react fiber 到底有多细。

在现有的计算机中，二进制常常以字节数组的形式存在于程序当中。例如在C#里面，就用byte[]，标准C里面没有byte类型，但可以通过typedef把byte定义为unsigned char的别名，效果是一样的。JS设计之初似乎就没想过要处理二进制，对于字节的概念可以说是非常非常的模糊。如果要表达字节数组，那么似乎只能用一个普通数组来表示。

然而随着业务需求的逐渐发展，出现了WebGL这样的技术。所谓WebGL，就是指浏览器与显卡之间的通信接口。为了满足JavaScript与显卡之间大量的、实时的数据交换，它们之间的数据通信必须是二进制的，而不能是传统的文本格式。类型化数组（Typed Array）就是在这种背景下诞生的。而类型化数组是建立在ArrayBuffer对象的基础上的。下面介绍一下Arraybuffer。

业务方应用接入BOS需要依赖于bos-sdk，应用集群在启动时通过bos-sdk将应用指定注解的组件进行收集，收集完成后保存在DB中，集群中的每一台机器在重启时，需要保证入库时只有一条请求的处理能够正确入库，以保证数据不会重复入库以及数据插入冲突的情况，为防止出现上述情况，项目中采用分布式锁，对此我们针对项目中分布式锁的逻辑，以及业务拿到锁的实现进行了CR，CR的最佳指导我们采用结构化方式进行，分别从背景了解、业务场景、逻辑分析、异常分析、编程规范、非功能分析、可测性分析这几个唯度进行CR。

低代码开发平台已经成为现在很多企业开发管理应用程序的重要工具，低代码平台的出现帮助企业降低了软件开发的成本，提高了软件开发的效率，越来越多的公司开始开发低代码平台，甚至基于低代码平台开始商业化，比如微软的Power Platform,Salesforce的Lightning，阿里的星环等，我在这里介绍一下有赞的低代码开发平台-BOS。

Shopify是全球电商SaaS龙头，为各类零售商搭建电商独立站点，管理全渠道的营销、售卖、支付、物流、仓储等一站式服务。公司由Tobias Lutke于2004年创办，总部位于加拿大首都渥太华，前身是一家二手滑板线上零售网站Snowdevil，2006 年转型为SaaS服务商，2015 年实现美股上市。目前公司是为全球规模最大的电商类SaaS 提供商，员工人数达到5000人，业务涵盖美国，英国，加拿大，澳大利亚等175个国家/地区拥有超过100万的企业客户，其中包括Allbirds、Gymshark、PepsiCo、Staples等大型品牌客户。

Shopify发展路线是从网站搭建工具到平台再到电商生态系统，是典型的企业级服务公司发展路线。Shopify基于软件工具，提供包括网站安全、页面设计、销售数据统计分析在内的全方位功能，扩展多元化业务建立属于自己的生态。目前Shopify平台与Amazon、Ebay 等电商合作，同时登陆Facebook、Instagram、Pinterest、Google+等主流社交媒体，已经建立了自己的完整电商生态系统。

随着公司业务的快速发展，需求越来越多、迭代越来越快，在有限的测试人员和时间投入的前提下，如何做好质量防控，如何提高测试效率，是大家持续思考的问题。

公司业务越来越复杂，应用越来越多，接口越来越多，接口的参数也越来越多，如何做好接口测试？如何做全接口的每一个参数的测试？

在测试过程中，测试人员主要面临以下问题：

• 测试人员都把精力放在核心的业务测试上。很少腾出时间来关注接口的各种参数类型的测试。
• 接口越来越多、接口参数也越来越多，很难做到每个接口、每个参数的穷尽测试。
• 针对接口参数设计的测试用例，用例数量通常都很多，如果只靠人工投入，会大大增加测试人员的时间成本，降低测试效率。
• 测试人员核心关注点在正常的业务数据上，非正常业务数据相关的逻辑很少考虑周全，比如最大值、最长字符、特殊值等。

面对以上的问题，如果所有的测试都靠人工来完成，那将是很大的一笔人工和时间开销。是否可以自动化构造测试数据来自动化部分测试类型，将是本文解决的问题。

性能和稳定性一直是App质量体系中最基本和最关键的一环。 而移动端业务快速迭代的过程中，开发同学对性能的关注不足，量变引起质变，App的卡顿严重影响商家的日常经营，商家对性能的吐槽和抱怨越来越严重。而面对商家反馈的性能问题，由于缺乏现场信息，问题的排查既被动又困难。我们急需一个系统化的解决方案，需要有自己的APM（Application Performance Management），可以通过它来发现问题，并且能依靠它的数据来指导我们进行性能优化。

UI 自动化是质量保障的一种重要手段，我们从分层测试金字塔模型可以看出，质量保障更多的应该依靠底层的单元测试和接口集成测试，UI 自动化测试占比是非常小的一部分，众所周知，UI 层的自动化测试稳定性差，成本高。然而我们团队经过一年多的 UI 自动化测试的实践与优化，发现我们 UI 层自动化测试相对性价比是最高的，脚本的稳定性也非常好，误报率降到了 1% 左右，每次上线前能帮助我们回归系统的一些核心业务流程，下面将跟大家分享一些关于我们 UI 自动化测试的实践经验。

在移动开发中，网络层面的监控一直是非常有必要的，比如统计网络接口的失败率、重定向网络请求、网络Request增加公共header头、实现动态域名等等。经常会遇到App某些域名因为一些原因在某些地区DNS解析异常，因此我们需要将这些有问题的域名进行动态替换，让用户可以正常的访问接口，正常使用我们的App。

权限管理是一个几乎所有大中型 B 端系统都会涉及的重要组成部分，其目的是对整个系统进行权限控制，避免造成误操作及数据泄露等风险问题。在充分调研了商家的经营需求后，传统的老板、店长、收银员等角色不足以覆盖商家角色场景。因此，在原有权限系统的基础上，增加了商家自主定义员工权限的能力，满足其细粒度管控员工权限的诉求。任何一家使用有赞开店软件经营店铺的商家，不仅能给员工赋予默认的角色，也可以实时给员工开放特定的权限、修改权限，以此保障店铺运营的安全、健康。