本文共 3045 字，大约阅读时间需要 10 分钟。

前端测试，也就近几年发展出来的概念。相对于后端测试关注的更多是界面交互的场景。对于一些需求快速迭代的也前端自动化测试有时是负收益的，因为测试场景根本跟不上业务的变更。而对于一些业务相对稳定的项目和产品，如内部系统，前端自动化测试显得更有价值。

前端测试框架

不得不说开源社区涌现的开源前端测试框架实在太多了。逐个测试的话，可能项目都要延期了。鉴于Vue技术栈的选择，重点介绍两款：Jest 和 StoryBook（Selenium、Karma显得略重可以留待下次~~）。Jest侧重于功能和接口验证，StoryBook侧重交互性测试。简单来说就是Jest适合简单的单元测试，StoryBook则可以模拟特定业务场景。在实际使用过程中，StoryBook的特性更容易定位业务问题。

Jest是vue-cli内置的测试模块。与其并列的其实还有Mocha + Chai选项。

取舍之间主要考虑了Jest的易用性，关于二者孰优孰劣可以参考社区的各类分析帖子（其实已有替代之势），不再赘述。Jest测试场景为傻瓜式的功能性测试，见官方的例子：

import {
    shallowMount } from "@vue/test-utils";import HelloWorld from "@/components/HelloWorld.vue";describe("HelloWorld.vue", () => {
     it("renders props.msg when passed", () => {
       const msg = "new message";    const wrapper = shallowMount(HelloWorld, {
         propsData: {
    msg }    });    expect(wrapper.text()).toMatch(msg);  });});

HelloWorld组件props有个msg属性，测试用例断言了赋值时和展示时的值是否相等。执行成功会提示耗时。

测试通过：

可能这种测试的收益不大，但用于却是比较合适的。统计接口请求耗时和测试接口超时的情形。如：

import axios from 'axios';describe('账单api接口测试', () => {
       expect.assertions(1);	axios.get('http://api.sample.com/bill/1')      .then(res => {
           expect(res.data.vendorCode).toBe('10086');      })      .catch(error => console.log(error));})

使用swagger或apiggs批量导出api接口生成接口测试接口健康度。虽然后端测试也有类似的功能，但调用场景不同还是有测试的价值。也能

很多时候，接口层面正常但业务数据异常导致页面各种离奇古怪的报错或崩坏。如接口返回特殊字符，前端无法解析；数据量过大页面渲染变形等等等；这种情况就是侧重的交互式场景测试。

Storybook，原意故事书，可以引申为剧本，是React旗下的测试神器。近年开始逐步支持其他主流框架，Vue也是受益者之一。其初衷是为了更好地进行组件化测试，类似后端的集成测试。页面和接口集成后展示的效果，这对通用组件显得尤为重要。

前端对于组件的概念就比较广泛了，如同后端Spring中的Component。可以定义得很大，如一个复杂的查询报表，也可以定义得很小，如一个按钮或是一个标签。各类组件又可以存在组合关系，所以StoryBook测试的对象需要有针对性。通常选择一些复用度高或许业务影响大的组件。

StoryBook安装

强烈建议参考GitHub上的或官网的，各类博客上的坑实在太多。特别是vue-cli升级3.x之后，Storybook 4.x就不支持vue-cli 2.x项目了。vue-cli 2.x生成的项目需要手动退回Storybook 3.4.11。

基本上的操作为，全局安装CLI工具：

npm i -g @storybook/cli --registry=https://registry.npm.taobao.org

然后进入已有前端项目执行

cd my-project-directorynpx -p @storybook/cli sb init

生成器会生成.storybook目录并在package.json里插入storybook的依赖包。由于我是基于vue-cli 2.x生成的项目需要把storybook的版本号手动刷回3.4.11。

一并生成还有官方的例子

运行npm run storybook命令

storybook使用的是默认的webpack配置，需要配置插件的话可以新建.storybook/webpack.config.js文件将配置merge进去。如merge将一些通用配置，确保vue能正常编译（plugins和module节点只是样例，可按需加）。

const path = require('path')const webpack = require('webpack')function resolve (dir) {
     return path.join(__dirname, '..', dir)}module.exports = {
     resolve: {
       extensions: ['.js', '.vue', '.json','.jsx'],    alias: {
         'vue$': 'vue/dist/vue.esm.js',      '@': resolve('src')    }  },  plugins: [    new webpack.ProvidePlugin({
           $: 'jquery',        jquery: 'jquery',        'window.jQuery': 'jquery',        jQuery: 'jquery'    }),  ],  module: {
       rules: [      {
           test: /\.css$/,        use: [ 'style-loader', 'css-loader' ]      }    ]  }}

StoryBook测试用例

前面的工作完成后剩下的就是定制自身的业务测试场景。比如我的账单展示页面很重要。我会针对账单组件调整传参，然后测试各个类型的账单的账单展示。

哈哈，这个例子略显苍白无力。想表达的内容是可以将不同的业务主键聚合在同一个用例上进行测试。对于数据来源可以写在测试用例上，也可以通过mock.js模拟接口或是调用测试的后端接口进行场景测试。配合的用法可以写出更灵活的测试用例（没错，你可以写出页面自动登录）。再有一点就是，实际上Storybook也可以作为用户手册。执行npm run build-storybook可以导出静态文档。对于懒于写文档的开发人员来说，可以完成测试用例时顺便把文档写了。

转载地址：https://blog.csdn.net/vipshop_fin_dev/article/details/84504643 如侵犯您的版权，请留言回复原文章的地址，我们会给您删除此文章，给您带来不便请您谅解！