有赞前端质量保障体系

前言

最近一年多一直在做前端的一些测试，从小程序到店铺装修，基本都是纯前端的工作，刚开始从后端测试转为前端测试的时候，对前端东西茫然无感，而且团队内没有人做过纯前端的测试工作，只能一边踩坑一边总结经验，然后将容易出现问题的点形成体系、不断总结摸索，最终形成了目前的一套前端测试解决方案。在此，将有赞的前端质量保障体系进行总结，希望和大家一起交流。

先来全局看下有赞前端的技术架构和针对每个不同的层次，主要做了哪些保障质量的事情：

有赞的 Node 技术架构分为业务层、基础框架层、通用组件和基础服务层，我们日常比较关注的是基础框架、通用组件和业务层代码。Node 业务层做了两件事情，一是提供页面渲染的 client 层，用于和 C 端用户交互，包括样式、行为 js 等；二是提供数据服务的 server 层，用于组装后台提供的各种接口，完成面向 C 端的接口封装。

对于每个不同的层，我们都做了一些事情来保障质量，包括：

针对整个业务层的 UI 自动化、核心接口|页面拨测；
针对 client 层的 sentry 报警；
针对 server 层的接口测试、业务报警；
针对基础框架和通用组件的单元测试；
针对通用组件变更的版本变更报警；
针对线上发布的流程规范、用例维护等。
下面就来分别讲一下这几个维度的质量保障工作。

一、UI自动化

很多人会认为，UI 自动化维护成本高、性价比低，但是为什么在有赞的前端质量保证体系中放在了最前面呢？

前端重用户交互，单纯的接口测试、单元测试不能真实反映用户的操作路径，并且从以往的经验中总结得出，因为各种不可控因素导致的发布 A 功能而 B 功能无法使用，特别是核心简单场景的不可用时有出现，所以每次发布一个应用前，都会将此应用提供的核心功能执行一遍，那随着业务的不断积累，需要回归的测试场景也越来越多，导致回归的工作量巨大。为了降低人力成本，我们亟需通过自动化手段释放劳动力，所以将核心流程回归的 UI 自动化提到了最核心地位。

当然，UI 自动化的最大痛点确实是维护成本，为降低维护成本，我们将页面分为组件维度、页面维度，并提供统一的包来处理公用组件、特殊页面的通用逻辑，封装通用方法等，例如初始化浏览器信息、环境选择、登录、多网点切换、点击、输入、获取元素内容等等，业务回归用例只需要关注自己的用例操作步骤即可。

1.框架选择

– puppeteer[1]，它是由 Chrome 维护的 Node 库，基于 DevTools 协议来驱动 chrome 或者 chromium 浏览器运行，支持 headless 和 non-headless 两种方式。官网提供了非常丰富的文档，简单易学。

UI 自动化框架有很多种，包括 selenium、phantom；对比后