商城的前端质量保障系统建设如何才能做到位？（下）

草帽路飞UU

三、单元测试　　



单元测试在测试分层中处于金字塔最底层的位置，单元测试做的比较到位的情况下，能过滤掉大部分的问题，并且提早发现 bug，也可以降低 bug 成本。推行一段时间的单测后发现，在有赞的 Node 框


架中，业务层的server端只做接口组装，client 端面向浏览器，都不太适合做单元测试，所以我们只针对基础框架和通用组件进行单测，保障基础服务可以通过单测排除大部分的问题。比如基础


框架中店铺通用信息服务，单测检查店铺信息获取；比如页面级商品组件，单测检查商品组件渲染的 html 是否和原来一致。

　　比较推荐的是 Jest 方案，它支持 Matchers 方式断言；支持 Snapshot Testing，可测试组件类代码渲染的 html 是否正确；支持多种 mock，包括 mock 方法实现、mock 定时器、mock 依赖的


module 等；支持 istanbule，可以方便的获取覆盖率。

　　总之，前端的单测方案也越来越成熟，需要前端开发人员更加关注 js 单测，将 bug 扼杀在摇篮中。

四、基础库变更报警

　　上面我们已经对基础服务和基础组件进行了单元测试，但是单测也不能完全保证基础库的变更完全没有问题，伴随着业务层引入新版本的基础库，bug 会进一步带入到业务层，最终影响 C 端用户的正常


使用。那如何保障每次业务层引入新版本的基础库之后能做到全面的回归？如何让业务测试同学对基础库变更更加敏感呢？针对这种情况，我们着手做了一个基础库版本变更的小工具。实现思路如下：

　　1. 对比一次 master 代码的提交或 merge 请求，判断 package.json 中是否有特定基础库版本变更

　　2. 将对应基础库的前后两个版本的代码对比发送到测试负责人

　　3. 根据 changelog 判断此次回归的用例范围

　　4. 增加 gitlab webhook，只有合并到合并发布分支或者 master 分支的代码才触发检查

　　这个小工具的引入能及时通知测试人员针对什么需求改动了基础组件，以及这次基础组件的升级主要影响了哪些方面，这样能避免相对黑盒的测试。

　　第一版实现了最简功能，后续再深挖需求，可以做到前端代码变更的精准测试。



五、sentry报警

　　在刚接触前端测试的时候，js 的报错没有任何追踪，对于排查问题和定位问题有很大困扰。因此我们着手引入了 sentry 报警监控，用于监控线上环境 js 的运行情况。

　　sentry是一款开源的错误追踪工具，它可以帮助开发者实时监控和修复崩溃。

　　开始我们接入的方式比较简单粗暴，直接全局接入，带来的问题是报警信息非常庞大，全局上报后 info、warn 信息都会打出来。

　　更改后，使用 sentry 的姿势是：

　　sentry 的全局信息上报，并进行筛选

　　错误类型: TypeError 或者 ReferenceError

　　错误出现用户 > 1k

　　错误出现在 js 文件中

　　出现错误的店铺 > 2家

　　增加核心业务异常流程的主动上报

　　最终将筛选后的错误信息通过邮件的形式发送给告警接收人，在固定的时间集中修复。




六、业务报警

　　除了 sentry 监控报警，Node 接口层的业务报警同样是必不可少的一部分，它能及时发现 Node 提供的接口中存在的业务异常。这部分是开发和运维同学做的，包括在 Node 框架底层接入日志系统；在


业务层正确的上报错误级别、错误内容、错误堆栈信息；在日志系统增加合理的告警策略，超过阈值之后短信、电话告警，以便于及时发现问题、排查问题。

　　业务告警是最能快速反应生产环境问题的一环，如果某次发布之后发生告警，我们第一时间选择回滚，以保证线上的稳定性。

七、约定规范

　　除了上述的一些测试和告警手段之外，我们也做了一些流程规范、用例维护等基础建设，包括：

　　发布规范

　　多个日常分支合并发布

　　限制发布时间

　　规范发布流程

　　整理自测核心检查要点

　　基线用例库

　　不同业务 P0 核心用例定期更新

　　项目用例定期更新到业务回归用例库

　　线上问题场景及时更新到回归用例库

　　目前有赞的前端测试套路基本就是这样，当然有些平时的努力没有完全展开，例如接口测试中增加返回值结构体对比；增加线上接口或页面的拨测[8]；给开发进行自测用例设计培训等等。也还


有很多新功能探索中，如接入流量对比引擎，将线上流量导到预上线环境，在代码上线前进行对比测试；增加UI自动化的截图对比；探索小程序的UI自动化等等。