测试

[Genluo]

前端测试调研

对于一次性的项目，建议不用接入单测的，但只要是需要维护和反复迭代半年以上的项目，这绝对是一个去测试化，减少代码review，减少手动回归的好方式。可以极大效率的提升代码质量和稳定性。如果已经产生问题，尽快补充相关问题代码的测试用例，修复后防止下次发生。前端层面的代码测试分为四个阶段，每个阶段都有不同解决方案，但是对于业务项目而言的前端测试都很“尴尬”。如果是开发工具库，那可以通过单元测试来保证质量，如果是开发 UI 组件库，可以通过 Storybook 来进行视觉与快照测试。所以之前每每想到业务项目如何集成自动化测试都感觉无从下手，具体可以了解下前端测试四部分，我们可以在业务开发过程接入部分测试方法：

静态代码扫描

静态代码扫描主要在写代码的过程中发挥作用，由于 JavaScript 是动态语言，静态代码扫描功能无法像在 Java 等静态语言上一样发挥100%的作用，但是对于一些基础的语法问题，静态代码扫描还是能准确的识别出来。常用的静态类型检查有两种：

1. Eslint
2. TypeScript

功能测试/单元测试

单元测试是指为检测特定的目标是否符合标准而采用专用的工具或者方法进行验证，并最终得出特定的结果，对于前端开发过程来说，这里的特定目标就是指我们写的代码，而工具就是我们需要用到的测试框架(库)、测试用例等。检测处的结果就是展示测试是否通过或者给出测试报告，这样才能方便问题的排查和后期的修正，目前来看前端的的单元测试的意义主要在于下面几点：

1. 保证前端代码的健壮性与易维护性，前端的JS问题及早发现；
2. 提高代码质量，规范代码，提高产品质量;
3. 单个应用涉及其他应用变更，能迅速反馈错误;
4. more, more, more...

除了这些单元测试带来的好处，为什么我们开发还需要花费时间去编写单元测试：

1. 驱动开发，指导设计：代码被测试的前提是代码本身的可测试性，那么要保证代码的可测试性，就需要在开发中注意API的设计，TDD将测试前移就是起到这么一个作用。
2. 保证重构：互联网行业产品迭代速度很快，迭代后必然存在代码重构的过程，那怎么才能保证重构后代码的质量呢？有测试用例做后盾，就可以大胆的进行重构。

// TODO: 介绍如何编写一个前端的单元测试

UI测试

前端UI需求变化快，很多时候单元测试还没有写好，需求就变了，所有的测试代码都不能继续使用。这还是好的，更恐怖的是需求变了代码变了测试没变，重新跑一边全是报错，还不如不写测试！不是特别稳定的业务不需要接入UI测试，在UI测试部分，包括了兼容性测试、性能测试、质量测试、界面样式测试

1. 界面样式测试
   • 固定界面样式测试：主要针对文字内容不变的区域，例如页面的页头，页脚这类结构、内容不变的区域，而测试一般通过截图对比解决。
   • 结构不变界面样式测试：主要针对结构不变的区域，例如新闻区域这类结构不变，内容变化的区域，这类测试一般通过DOM元素对比解决。
   • 计算样式测试：主要针对计算样式不变的区域，这类测试一般通过比较计算样式解决，但是这种测试不推荐，因为测试成本比较大。
2. 兼容性测试
   • 多浏览器测试：基于界面样式测试、功能测试的基础上来进行不同浏览器的的测试
3. 性能测试
   • 白屏时间：用户浏览器输入网址后至浏览器出现至少1px画面为止。
   • 首屏时间：用户浏览器首屏内所有的元素呈现所花费时间。
   • 页面回归时间：用户浏览器非第一次加载所有的元素呈现所花费时间。
   • 用户可操作时间(dom ready) ：网站某些功能可以使用的时间。
   • 页面总下载时间(onload):网站中所有资源加载完成并且可用时间。
4. 质量测试
   • 雅虎网站优化规则

但是什么样的前端项目适合UI测试：

1. 需求稳定，不会频繁变更 自动化测试最大的挑战就是需求的变化，而自动化脚本本身就需要修改、扩展、debug，去适应新的功能，如果投入产出比太低，那么自动化测试也失去了其价值和意义； 折中的做法是选择相对稳定的模块和功能进行自动化测试，变动较大、需求变更较频繁的部分用手工测试；
2. 多平台运行，组合遍历型、大量的重复任务 测试数据、测试用例、自动化脚本的重用性和移植性较强，降低成本，提高效率和价值；
3. 软件维护周期长，有生命力 自动化测试的需求稳定性要求、自动化框架的设计、脚本开发与调试均需要时间，这其实也是一个软件开发过程，如果项目周期较短，没有足够的时间去支持这一过程，那自动化测试也就不需要了；
4. 被测系统开发较为规范，可测试性强 主要出于这几点考虑：被测试系统的架构差异、测试技术和工具的适应性、测试人员的能力能否设计开发出适应差异的自动化测试框架；

// TODO: 介绍如何做UI测试，内网中存在的技术框架

线上监控

线上监控可以让我们方便的了解到业务产品的真实指标，如访问量、用户交互数据、页面错误、性能等关键信息。对于应用的体验优化和用户精细化运营至关重要。

线上监控是个比较复杂的体系，包括数据采集、处理计算、可视化等方面。这里篇幅和知识所限，只说端上的数据采集方面。

目前集团里面中有三种前端线上监控系统：

1. jstracker

目前JSTracker平台已经覆盖了前端全链路监控, 包含WEEX，H5，三方小程序场景，并和搭建端（方舟、斑马）、DEF发布链路完成打通。支持自定义报警规则，报警消息多端同步等功能，覆盖权益资损、性能、报错、接口成功率等一系列场景，日志数据聚合、模式挖掘以及源码定位等分析功能。

jstracker 能够帮你记录用户浏览器中的各种报错，并记录当前用户的旺旺名、操作系统、浏览器、页面加载完成到错误出现的总耗时、屏幕滚动的 offset 甚至是报错文件的名称及行号。有了这么详细的信息，你就可以很方便的定位并找出问题了。

2. clue

• 支持捕获异常的堆栈
• 支持 SourceMap 映射
• 智能报警

3. RetCode

retcode http://retcode.alibaba-inc.com 主打用户端体验数据的监控，通过页面打开速度（测速）&页面稳定性（Js Error）&外部服务调用成功率（API）三叉戟组合来监测前端页面的健康度，发生异常的时候及时推送预警。同时平台不仅仅是技术质量监控，还提供轻量级对用户交互行为进行分钟级别实时统计功能，可辅助发现业务问题，并为业务决策提供数据支持。

// TODO: 集团中平台监控的对比

前端自动化测试&持续集成

持续集成指的是只要代码有变更，就自动运行构建和测试，反馈运行结果。确保符合预期以后，再将新代码"集成"到主干。

持续集成的好处在于，每次代码的小幅变更，就能看到运行结果，从而不断累积小的变更，而不是在开发周期结束时，一下子合并一大块代码。

目前做的比较出名的持续集成平台是Travis ，并且只支持GITHUB，aone基本不支持前端的持续集成，感觉这是一个缺口，如果集团中项目开始接入相关测试，那么肯定需要一个平台来持续集成前端项目

// TODO: 持续集成的了解

参考

• 浅谈前端代码质量保障

[Genluo]

• 羚珑项目自动化测试方案实践 - 主要是API的测试

[Genluo]

集成测试和单元测试

GitLab中的持续集成