分类: 测试

  • E2E 测试用例的一般要求

    E2E 测试用例的一般要求

    周会上,聊到我们需要普及自动化 E2E 测试,用自动化 E2E 测试回归降低研发成本。老板问:

    测试同学已经准备了不少 E2E 测试用例,能否直接用上?

    这个问题需要具体来看。

    0. E2E 测试

    E2E 测试即端到端测试,一般用来描述一套完整的用户交互行为,要求在这一系列操作中,所有环节工作正常。E2E 测试比较关注操作的完整性,不太关注边界条件的覆盖范围。

    前端代码、重前端的产品比较适合用 E2E 测试,因为模仿的是用户实际操作,所以往往能比较好的照顾到主要使用场景,性价比比较高。

    之前在 OR 厂,我负责的产品就跟 E2E 测试有关,在几年时间里很好的保障了 OR 厂各商业产品的产品质量。本着拿着锤子找钉子的原则,我也想在我厂推广这种做法。

    1. E2E 测试用例

    下面示范一下 E2E 测试用例。比如我们要基于 WordPress 博客软件写一个发布文章的测试用例,那么用伪代码描述大概如此:

    打开网站后台 https://blog.meathill.com/wp-admin
    输入用户名
    输入密码
    点击登录按钮
    从菜单里打开文章列表页
    新建文章
    填写随机标题
    填写随机内容
    点击发布
    回到列表页
    查看内容是否存在

    2. 自动化 E2E 测试用例的要求

    上面这个测试用例放在自己的环境里跑就没有问题,但是如果要自动化运行,往往还有一些特殊的要求。

    一般来说,自动化测试更关注效率,尽量在最短的时间内完成全部测试。所以通常来说,自动化测试一般会多任务并行测试;甚至会部署多个节点一起跑。那么产生以下要求就很合理:

    • 独立性
      每个测试用例要能够独立运行,不依赖其它测试用例产生的环境,也不能因为其它测试产生的环境而失败。
    • 随机性
      为了能够独立运行,很多时候我们要给测试用例增加足够的随机性,比如上面例子里的标题,就应该是随机的,这样我们多个用例一起跑的时候,不会互相冲突。
    • 完整闭环
      为了不影响其它用例,E2E 测试用例一般要实现完整闭环。比如创建了文章,最后要把这篇文章删掉。这样一方面可以测试“删除功能”;另一方面不会产生太多垃圾,影响后面的测试。
    • 尽量不依赖非软件功能
      有时候我们会写一些清理、重置脚本,跑完几个测试或者开始跑测试之前制备环境。这样的做法也不好,因为这部分脚本没有被测试覆盖,可能产生新的问题。

    3. 总结

    所以,最后回到老板的问题上,我的答案是:

    可以尝试,但恐怕不行。


    希望今年我厂能扛住,希望我也能扛住,把自动化测试体系搭建起来。如果大家对自动化测试、E2E 测试有什么想法,欢迎留言与我交流。

  • 解决 mocha 测试时 `cannot use import statement outside a module` 错误,以及配置 travis

    解决 mocha 测试时 `cannot use import statement outside a module` 错误,以及配置 travis

    前些天同事突然发现一个库项目的测试无法运行,报错的内容大概是:cannot use import statement outside a module "should",即无法在模块外使用 import 导入内容。这个错误比较奇怪,简单 Google 之,基本上大家的解决方案都是使用 <script type="module"> 即在浏览器里用 ESM 加载 JS,这明显和我们的环境不同。

    Node.js 当然也支持 ESM,不过这应该也不是问题症结。大体上我可以判断,因为测试集(JS 文件)用到 import 语法,而且用 mocha --require @babel/register 启动测试,所以应该是 Babel 没有正确转译导致的问题。

    检查 Babel 的相关配置,发现同事为了能同时编译现代浏览器和 IE 两个版本的库,.babelrc 大概是这样的:

    {
      "env": {
        "default": {
          "presets": [],
        },
        "withie": {
          "presets": [],
        }
      }
    }

    猜测 mocha 走了 default 分支,然后没有转译,所以出错。解决方案就是添加 node 分支,以当前 node 版本为 target,这样该转译就转译,不转译就用原生,性能更好,修改好的配置大概是这样的:

    {
      "env": {
        "default": {"presets": []},
        "withie": {"presets": []},
        "node": {
          "presets": [
            [
              "@babel/preset-env",
              {
                "targets": {
                  "node": "current"
                },
                "useBuiltIns": false
              }
            ]
          ]
        }
      }
    }

    使用时,需要增加环境变量用来切换配置:BABEL_ENV=node mocha --require @babel/register。比较奇怪的是,其他脚本使用 BROWSERSLIST_ENV 切换,这里只能使用 BABEL_ENV,我暂时不知道为什么。

    修改之后的脚本就可以正常测试了。接下来我打算给它加上 Travis,这样就能自动 lint + 测试,比较方便控制质量。加 Travis 很简单,拷过来一个 .travis.yml 改吧改吧就行了,但是第一次运行失败了,而且是超时。经过研究,原来 mocha 从 v4 开始,完成测试后不会自动退出,除非手动指定,方法是增加 --exit 参数。

    所以最终的测试脚本是(其它配置略去):

    {
      "scripts": {
        "test": "BABEL_ENV=node mocha --require @babel/register --exit",
      }
    }

    最终 Travis 配置是:

    sudo: required
      dist: trusty
     
    
      language: node_js
      node_js:
        - 14
     
    
      branches:
        only:
          - master
     
    
      cache:
        directories:
          - ~/.npm # cache npm's cache
          - ~/npm # cache latest npm
     
    
      install:
        - npm ci
     
    
      script:
        - npm run lint
        - npm run test
  • 使用 Webpack + Mocha 进行单元测试(一)

    使用 Webpack + Mocha 进行单元测试(一)

    我厂产品经过两年的打磨,目前功能基本稳定了,接下来的工作重点是用测试保证质量。除了继续丰富 E2E 测试,我还计划添加一些单元测试,用来确保一些重要函数和类正常工作。

    所以就要选择框架。开始想试试近期比较热门的 Jest,找了些文章看了看,发现也没啥吸引我的特色,E2E 和 UI 我厂的 Navlang 目前独步江湖,无出其右者,考虑到以前用 Mocha 写过一些单元测试,所以决定继续用 Mocha。

    但是已经很长时间没写了,所以想先研究下工具链。如果只是单文件的话,直接 mocha test.js 就好;如果测试文件用了 ESM,那么加上 @babel/register 也就够了,mocha —require @babel/register test.js

    但是我们项目用到了 Vue,还用 Webpack 里的 resolve 定义了很多目录,所以为了能够兼容项目代码,我必须要 Mocha 结合 Webpack,用这个关键词一搜索,得到两个结论:mocha-webpack 和 mocha-loader。

    前者已经一年多没更新了,而且要求 mocha@5,所以我就不想用了。转过头研究 mocha-loader,经过反复试验,加上阅读源码,我得出结论:

    mocha-loader 的目标是在 Webpack 里集成测试,比如边开发边测试,并不是我想要的。我想要的是:打包测试内容,整合测试框架,方便用户在 CI 系统里集中进行测试。

    所以我真正需要的,其实是:

    1. 创建一个独立的 webpack 配置文件,用来打包单元测试
    2. 打包后执行测试,返回测试结果

    基本上,今天大半天的工作是白费了。mocha-loader 的作者应该把目的写在 README 里的……