产品解决方案安全专区定价 WeTest生态支持与服务关于WeTest

关于小程序质量保障的那些事

安全专区 2024-04-10 17:47 30

至今，小程序已经发展成日活用户超6亿，拥有超过700万的小程序，超过300万的开发者的一个强大生态。其中关于小程序的质量保障一直是开发者所必须关心的

2016年11月，微信小程序开启开放测试，2017年1月9日，第一批微信小程序上线，至今，小程序已经发展成日活用户超6亿，拥有超过700万的小程序，超过300万的开发者的一个强大生态。

前言

首先，介绍一下大家经常谈到的小程序的时候，都涉及什么

如上图展示的，可以大致划分为几大块：

1、小程序管理端

用来完成小程序的注册、基础信息设置，进行版本管理、人员信息管理，开通、设置小程序平台提供的丰富的开放能力，查看小程序的运营数据等；

2、小程序的运行环境

客户端/SDK，小程序需要运行在终端上，这里就需要各平台的微信客户端或者是支持小程序的SDK，提供小程序的运行环境，小程序包下载等，同时让小程序可以使用到微信强大的开放能力；

基础库，小程序运行的基础，包含了小程序的核心机制，包括：通信模型、生命周期模型、事件系统、渲染机制、组件系统、插件系统等等；

开放API、组件，小程序提供的各种开放能力；

3、开发配套

为了帮助开发者简单和高效地开发和调试微信小程序，还需要相关的开发配套设置。

开发者工具，帮助开发者可以完成小程序的 API 和页面的开发调试、代码查看和编辑、小程序预览和发布等功能；

开发者社区，包括交流专区、服务市场、微信学堂、开发文档等，是开发者分享学习小程序开发经验、反馈问题等活动的重要渠道；

云开发，无需搭建服务器，可免鉴权直接使用平台提供的 API 进行业务开发，帮助开发者快速开发小程序、小游戏、公众号网页等，并且原生打通微信开放能力；

云托管，以云原生为基础的，免运维、高可用服务上云解决方案，无需服务器，1分钟即可部署小程序/公众号服务端；

4、后台服务

小程序业务后台，包括小程序基础后台、编译后台、小程序包管理、开发者工具后台等；

小程序双线程模型

小程序双线程模型，现在大家都已经很熟悉了，小程序在当时是一种新的产品形态，在小程序技术方案设计时，有一个很重要的点，就是要求安全、可管控，为了是实现这个要求，设计了双线程模型，将小程序分成了渲染层和逻辑层，在这基础上衍生出了小程序特有的通信模型、生命周期、事件系统、渲染机制等核心机制，后来为了解决双线程模型的一些性能限制、丰富开发生态等，衍生出了组件系统和插件系统。同时还涉及小程序的WXML、WXSS语言、编译、小程序的包管理等部分。

因此这是一个复杂的业务系统。如何保障这样一个复杂系统的质量是一个复杂的挑战。

早期研发模式

在小程序发展早期，需求是用git issue管理，用milestone管理版本，当时的研发模式比较简单。到后期随着业务的发展，逐渐暴露出一些问题。

第一，是代码合入没有管控和检查，还有一些开发直接在发布用的分支上进行开发，容易出现代码漏合、夹带的问题；

第二，版本没有一个固定周期，经常出现测试过程中有新需求合入的情况，导致版本越积越大，整体测试时间拉长，质量很难保障；

第三个问题，灰度没有控制，直接按百分比灰度用户，并且灰度的速度也没有标准，容易出现灰度过快的情况，当我们感知到有会影响用户的问题时，影响的范围已经很大。

还有就是，前面有提到到，小程序除了基础库，还涉及客户端、开发者工具、核心后台等产品的联动，原先在版本发布过程中，主要是靠人工沟通来进行流程的扭转，成本高且容易出现失误。

研发模式优化

为了解决研发过程中的这些问题，我们设计了一套研发模式的优化方案：

首先是将研发流程细化，增加新功能测试阶段，新功能需要测试完成之后，通过mr合入release分支，同时对新开发、底层机制改动等情况引入code review机制；另外就是引入了开发者灰度，我们认为开发者对自身的小程序的问题是比较敏感的，反馈问题的意愿也比较高，平常也会调试自己的小程序，会更容易发现基础库潜在的问题，并且开发者拥有过开发者社区作为渠道进行反馈，反馈会更加的及时和准确。

同时在整个流程的各阶段分别整合、使用Bg内外的一些平台和能力，研发阶段利用蓝盾流水线、aflow等提高效率，开始灰度后利用ifeedback、ilogs等系统提升问题发现的能力，达到提升整体质量效能的目的。

具体措施

具体优化工作可以分为研发流程改进、测试效果及效率提升、问题发现能力提高等几个方面，本文主要介绍测试效果及效率部分。

流程方面主要就是规范化和标准化并增加相关监测：

Issue&代码关联
Issue状态监测
milestone状态管理
电子流通知
根据issue数量计算观察时间
可放量时间窗口

自动化完善及测试效率提升

在自动化完善的过程中，我们遇到了一些痛点：原自动化框架对小程序的场景覆盖能力不足，自动化效率低，小程序场景复杂、需要回归的用例多等。

针对场景覆盖能力不足

我们基于小程序调试协议新建了一套小程序测试框架minium，这么做有以下好处：

与小程序基础库进行通信，拥有支持用例多端执行，解决业务测试跨平台需求
可直接用接口获取、设置小程序页面数据，可以进行数据测试和更高效的数据校验
可以直接触发小程序事件和jsapi，可以单独进行JSAPI的测试，也可以更高效的进行测试场景的构造和进入

针对执行时间长

对测试框架进行进行了wetest云真机的支持改造，在集成时可以多任务、多机器并行执行，提高执行效率。

针对小程序场景复杂，需回归用例多的特点

利用分而治之的思想，根据小程序的特点，将UI/接口/核心机制的用例进行分层设计和组织，同时对研发流程的不同阶段，拆分不同粒度的测试任务，使自动化可以在更早的研发阶段跑起来，更早的发现问题，降低问题修复成本，针对集成阶段，对渲染自动化、组件自动化等耗时更长的任务，分配更多的机器，达到缩短整体执行时间的效果。

自动化完善及效率优化效果

通过上面的改进措施，小程序基础库的自动化覆盖度达到了80%，全量用例回归的时间，也从48人时提升到只需要2.5小时，提高了整体的效率。

基础库用户体验保障

小程序的启动性能是影响用户体验的一项重要因素，为了优化启动性能，业务团队专门成立了一个专项组，在优化的过程中，我们遇到了启动性能获取不准确，常规性能测试工具无法分析性能瓶颈，发现了性能恶化，定位和验证困难等问题。

为了能够准确的获取到启动过程中各阶段的耗时，我们细化了启动过程，采取客户端+基础库协议上报的方式进行性能数据获取。

然后划分启动场景制定启动自动化用例，建立了一套机制自动拉取协议数据，并计算不同阶段耗时，对比各个阶段的历史执行数据，生成测试报告以及可视化启动时序图，可以详细分析每个流程中的所有耗时细节，用来发现性能瓶颈。当出现性能异常时，利用二分思想采取自动构建、编包的方式，辅助定位导致异常的提交。每季度进行基准小程序+多类目小程序的方式进行启动性能竞品对比，保证微信小程序的用户体验。

智能monkey效果优化

为了能够更多的覆盖线上场景，发现潜在问题，我们会对线上的小程序进行monkey探索，目标是可以覆盖尽可能多的页面，发现js error/黑白屏/crash等，小程序运行过程中的页面可能会出现多种元素类型包括原生元素、小程序元素、以及canvas组件等特殊组件，怎样获取有效的操作元素，是保障monkey效果的前提。