一篇关于前端测试质量保证之路的探索

主要想分享一下有关前端测试的探索之路上遇到的难点和收获

作者：变优秀的小白

Github：关注YX-XiaoBai

爱好：Americano More Ice !

QQ学习交流群(new): 811792998

前言

自从进入新的项目组后，最近几个月大部分迭代在做一些相关前端的测试，从页面迭代–>埋点测试–>SDK测试过程，由于之前对新项目架构及细节没有足够熟悉，只能一遍踩坑一遍沉淀，将一些没有考虑到的易错点和功能细节慢慢形成了一套新的测试体系，最终沉淀了目前对前端测试质量保证的方案。在此，会根据沉淀下来的 前端测试质量保证方案不断推进，以尽可能的保证前端测试质量，也可能有考虑不周到或不全面的地方，希望可以和大家分享交流。

先全局看下整个数据流的架构和层次结构，现在主要做了哪方面的质量保障:

SDK由前端WEB-SDK和后端SDK构成，主要做了两件事情，前者主要提供了页面渲染，用于和C端用户交互，其中包括了样式、行为js等等；后者主要提供了封装好的接口供前者使用，用于组装backend提供的各种接口，完成面向C端的接口封装。

下面就详细的铺开讲述各个维度的质量保证工作及完成情况

质量保证

• 单元测试（数据处理层）：指对软件中最小的可测试单元进行检查和验证

  • 单元测试框架: 如前端使用的Jest框架及后端使用go内置的testing内置单测框架

• 接口测试（业务逻辑层）：主要检查验证模块间的调用返回以及不同系统、服务间的数据交换

  • 单接口测试: 如常用的工具postman等
  • 接口压力测试: 如常用的工具jemter，常用的测试框架locust-boomer、locust等
  • 接口自动化测试: 如常用的自动化框架，httprunner、pytest等

• UI测试（GUI界面层）：UI层是用户使用产品的入口，所有功能通过这一层提供给用户，前端测试工作大多集中在这一层

  • UI交互测试: 如常用工具charles、mock等
  • UI自动化测试: 如常用的测试框架puppeteer、cypress、selenium等

以上的性价比：按照测试金字塔模型以及投入/产出比，越向下，回报率越高；但是当项目趋于稳定后，在接口测试和单元测试完善度较高时，最上层的UI测试占比将逐步扩大

UI自动化

误区

UI自动化维护成本高、性价比低，不对项目进行UI自动化

为什么需要UI自动化

• 前端重在用户交互，单纯的接口测试、单元测试不能真实反映用户的操作路径
• 单纯的接口测试、单元测试不能真实反映用户的操作路径，存在发布A功能影响B功能的场景
• 随着业务迭代不断累积，回归测试场景越来越多，回归测试工作量巨大(如现在的沙盒项目，项目稳定且回归场景过多)

具体为什么需要UI自动化的例子，可以参考待分享

UI自动化的痛点、难点

维护成本过高，每次迭代改动页面时，就可能需要重写UI自动化脚本

框架的选择

如今项目中的UI自动化测试选择使用的框架为 puppeteer，它是由 Chrome 维护的 Node 库，基于 DevTools 协议来驱动 chrome 或者 chromium 浏览器运行，支持 headless 和 non-headless 两种方式。官网提供了非常丰富的文档。

• 优点
  • 相比selenium更轻量级，增加npm包即可使用
  • 基于事件驱动，比selenium等待轮询更稳当、性能更佳
  • chrome原生支持，支持所有chrome的api

UI自动化测试用例设计思路

• 1.减少外部依赖
  • 尽量考虑通过预生成的数据来替代调用外部接口生成数据在用例中使用
• 2.预置数据代替创建过程
  • 由于UI自动化脚本实现交互操作越多则稳定性越低，尽量使用预置数据而不是实时生成它，速度更快，稳定性更高
• 3.使用不同课程场景进行用例场景隔离
  • 通过用例场景隔离，有助于A用例执行失败的脏数据就不会影响B用例的执行
• 4.用例调优：超时、等待时间。
  • 线上环境超时或等待时间可以设置相对比较短，因为测试环境的机器配置不如线上环境，需要适当增加超时和等待时间来保证接口调用不会超时和交互组件已经准备好

UI自动化测试落地

• UI自动化测试平台
  

接口自动化

前因

虽然 SDK 中不做复杂的业务逻辑处理而且后端层面已实现API自动化测试，但是 SDK 将提供的多个 http 接口进行二次转换，转化过程就带来了各种数据的获取、组合、转换形成了一个新的 end-to-end 的接口，仅仅后端的接口自动化已经不可保障对上层接口的全覆盖，所以需要针对SDK转化实现的接口进行自动化测试，才能做到更好的查漏补缺。

痛点

• 如何去评判SDK层面接口测试的质量?
• 如何去判断是否将SDK转化实现的接口完全覆盖业务逻辑?
• 请求SDK接口是通过http方式到达SDK后端，非js单元测试，也非browser功能测试，如何保证SDK层面接口的覆盖率?

搭配istanbul保证接口覆盖率

istanbul: 是业界比较易用的 js 覆盖率工具，它利用模块加载的钩子计算语句、行、方法和分支覆盖率，以便在执行测试用例时透明的增加覆盖率。它支持所有类型的 js 覆盖率，包括单元测试、服务端功能测试以及浏览器测试。得到的覆盖率结果类似下图所示。

单元测试

单元测试在测试分层中处于金字塔最底层的位置，单元测试做的比较到位且完整的情况下，能过滤掉大部分的问题，这部分主要由开发负责编写

单元测试框架

目前公司使用的是Jest单测框架

• 优点
  • 它支持 Matchers 方式断言
  • 支持 Snapshot Testing，可测试组件类代码渲染的 html 是否正确
  • 支持多种 mock，包括 mock 方法实现、mock 定时器、mock 依赖的 module 等
  • 支持 istanbul，可以方便的获取覆盖率

Web安全测试

常见测试场景

XSS跨站脚本攻击

• 定义: XSS与SQL注入相似，XSS是通过网页插入恶意JS或者H5脚本，主要用到的技术也是前端的HTML和JavaScript脚本。当用户浏览网页时，实现控制用户浏览器行为的攻击方式

主要分为了下面三种类型

• 存储型(持久性XSS): 如数据输入框插入js脚本
• 反射型(非持久性XSS): 与前者不同，接受者是后端，输出到前端。如url插入js脚本
• DOM型: 前端js直接拿到参数输出到前端，未经过后端

具体测试中发现的例子

在测试中，使用h5脚本<img src="#" onerror=alert(document.cookie)>运行代码，点击分享，发现页面源代码可以被修改，直接获取到了cookie，这就是个明显XSS漏洞的例子。get与post请求的xxs漏洞测试方法类似类似

v-html指令最终调用的是innerHTML方法将指令的value插入到对应的元素里。这就是造成xss攻击的‘漏洞’了。下面是v-html的源码:

// /vue/src/platforms/web/compiler/directives/html.js
export default function html (el: ASTElement, dir: ASTDirective) {
    if (dir.value) {
        addProp(el, 'innerHTML', `_s(${dir.value})`)
    }
}

导致xxs的一些原因:

• 没有将cookie标记为http only, 标记后Js中的document.cookie语句就不能获取到cookie了
• 没有限制用户输入我们期望的数据。 例如：手机输入框，只允许用户输入数字，而数字之外的字符都过滤掉
• 没有过滤或移除特殊的Html标签， 例如常见的h5标签: <script>, <iframe> , &lt; for <, &gt; for >等等
• 过滤js事件的标签。例如 onclick=, onfocus，onerror等等

sql注入

• 定义: SQL注入是通过把SQL命令插入到Web表单递交或输入域名或页面请求的查询字符串，最终达到欺骗服务器执行恶意的SQL命令

• 危害: 网页、数据被篡改，核心数据被窃取，数据库所在的服务器被攻击，变成傀儡主机

• 测试方法: 在用到查询的页面，输入查询条件and 1=1等简单sql，如果查询条件返回结果一致，标明未进行过滤，初步断定存在sql注入漏洞等

此场景在现在是比较少见。

越权操作

通过查看URL的get参数对那些类似明显的顺序数字 进行修改，看是否能越权访问。

基础库变更

前因

单测也不能完全保证基础库的变更完全没有问题，伴随着业务层引入新版本的基础库，bug 会进一步带入到业务层，最终影响 C 端用户的正常使用

问题

如何保障每次业务引入新版本基础库或升级版本做到全面回归，如何对基础库变更更加敏感

针对问题现有方法

每次向 master 代码的提交或 merge 请求，针对关注 package.json 中是否有某个基础库版本变更，以便更精确的对版本库升级影响的功能着重地进行测试，做到前端代码变更的精确测试，可以避免相对黑盒测试

进一步想法

是否需要实现一个diff小工具，在每次master有package.json的改动时及时通知测试负责人

线上业务报警

如今有专门的报警钉钉群来实时监控线上问题，监控沙盒报警情况，如超过阀值报警、沙盒异常报警等，以便于及时发现问题、排查问题，以保证线上的稳定性

总结

目前前端测试基本就是这样，UI自动化、Web安全测试、接口自动化等都已经实施落地了，当然也有些部分(如SDK层面接口测试)没有完全展开，需要后续不断地完善往更精确测试推进，才能更好的保证测试质量。测试过程中难免会有部分特殊场景没办法完全覆盖，或有不足的地方，只能逐步探索和沉淀来更全量的保证前端测试质量。

结束语：如果遇到什么疑问或者建议的，可直接留言评论！作者看到会马上一一回复

如果觉得小白此文章不错或对你有所帮助，期待你的一键三连💫！❤️ni