前端测试的质量保障体系之UI自动化

前端测试的质量保障体系之UI自动化

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

概览项目流程

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

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

·针对整个业务层的 UI 自动化、核心接口|页面拨测;

·针对 client 层的 sentry 报警;

·针对 server 层的接口测试、业务报警;

·针对基础框架和通用组件的单元测试;

·针对通用组件变更的版本变更报警;

·针对线上发布的流程规范、用例维护等。

下面就来分别讲一下这几个维度的质量保障工作。

一、UI自动化

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

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

1.框架选择

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

UI 自动化框架有很多种，包括 selenium、phantom;对比后发现 puppeteer 比较轻量，只需要增加一个 npm 包即可使用;它是基于事件驱动的方式，比 selenium 的等待轮询更稳当、性能更佳;另外，它是 chrome 原生支持，能提供所有 chrome 支持的 api，同时我们的业务场景只需要覆盖 chrome，所以它是最好的选择。

-- mocha[2] + mochawesome[3]，mocha 是比较主流的测试框架，支持 beforeEach、before、afterEach、after 等钩子函数，assert 断言，测试套件，用例编排等。

mochawesome 是 mocha 测试框架的第三方插件，支持生成漂亮的 html/css 报告。

js 测试框架同样有很多可以选择，mocha、ava、Jtest 等等，选择 mocha 是因为它更灵活，很多配置可以结合第三方库，比如 report 就是结合了 mochawesome 来生成好看的 html 报告;断言可以用 powser-assert 替代。

2.脚本编写

封装基础库

· 封装 pc 端、h5 端浏览器的初始化过程

· 封装 pc 端、h5 端登录统一处理

· 封装页面模型和组件模型

· 封装上传组件、日期组件、select 组件等的统一操作方法

· 封装 input、click、hover、tap、scrollTo、hover、isElementShow、isElementExist、getElementVariable 等方法

· 提供根据 “html 标签>>页面文字” 形式获取页面元素及操作方法的统一支持

· 封装 baseTest，增加用例开始、结束后的统一操作

· 封装 assert，增加断言日志记录

业务用例

· 安装基础库

· 编排业务用例

3.执行逻辑

分环境执行

增加预上线环境代码变更触发、线上环境自动执行。

监控源码变更

增加 gitlab webhook，监控开发源码合并 master 时自动在预上线环境执行。

增加 gitlab webhook，监控测试用例变更时自动在生产环境执行。

每日定时执行

增加 crontab，每日定时执行线上环境。