小公司的前端质量保障体系

生产阶段

1、轮询首页访问

2、线上的js报错追踪

3、页面加载时间监控

4、错误日志监控

5、用户反馈

线上的js报错追踪和页面加载时间监控

开源方案有Sentry，共道使用的是阿里云ARMS。

直接全局接入，会带来非常庞大的报警信息进行钉钉提示，需要做筛选。

共道现在的报错筛选策略是：

1、页面完全加载完成时间超过4.5s报警

2、js错误/pv超过50%报错

3、如果5分钟没报警信息，表示错误修复

错误日志监控

主要用于node端。

监控node服务机器的错误日志。

一旦有新增内容，便通过钉钉提醒相关人员。

预发阶段

1、UI自动化端测

2、手动功能测试和回归测试

UI自动化端测

Selenium和puppeteer的区别？

• 原理区别

  
  
  
  

  Selenium是对 DevTools Protocol 二次封装后的 Protocol的实现。
  而 puppeteer 是直接的实现了 DevTools Protocol 的 node 客户端。
  pyppeteer是python端的puppeteer实现。

• 应用场景区别
  puppeteer可以监听和控制chrome浏览器的网络请求。Selenium做不到。
  服务器端puppeteer运行机制和本地运行一致。Selenium在服务器运行和本地运行机制不一致，导致代码维护困难。
  因为少包装一层协议，puppeteer的性能更好。

并且puppeteer能提供所有 chrome 支持的 api。

puppeteer基础工作

前端这边会封装好以下方法，方便前端和测试同学使用自动化UI测试工具。

• 封装浏览器的初始化过程
• 封装账号登录的统一处理
• 封装输入框，下拉框，日期选择框，地址选择框等等组件的统一操作方法
• 封装基于“html标签 > 页面文字”的新选择器方法
• 封装用例开始和结束的统一操作方法
• 封装断言日志操作
• 封装业务流程操作，并提供配置驱动测试。

执行时机

• 代码合并 master 时自动在预发环境执行
• 测试用例变更时自动在预发环境执行

测试用例管理

基于git来管理。

分公共的测试用例和每次需求迭代的测试用例，需要开发和测试同学共同维护。

手动功能测试和回归测试

这一块基本是测试的体力活了。

不过测试可以更进一步，比如：线上接口或页面的拨测，给前端开发进行自测用例设计培训等等。

开发阶段

开发阶段的质量保障主要有以下三方面：

1、code review

2、单元测试

3、接口测试

因为在开发阶段，测试很难介入，基本是开发同学自己来保障。

code review

1、所有前端项目没有code review通过都无法上线

2、分配策略是leader手工分配

该功能是基于代码提交时的事件，git的diff和commit来实现。

代码量巨大时，需要作者召集相关人员去小房间讲解主要代码逻辑，然后大家一起来找茬。

单元测试

一般来说业务页面不适合做单元测试。

基础框架和通用业务组件适合单测。

angular自带的是Jasmine 测试框架。

接口测试

1、功能可用性

2、异常数据

3、压力测试

接口是根据每次需求迭代动态产生。

这个过程测试同学服务无法覆盖到，只能开发同学自己管理。

接口的可用性跟项目环境关系很大。

当下前端使用postman管理接口，包括接口的分类，自动化测试。

对于接口返回的异常数据，因为有约定好的响应格式，框架层面统一捕获处理。

对于接口的压力测试，大部分业务接口没这个需求。