使用配置表+Mocha动态生成用例的JSAPI自动化测试

Posted 2023-04-27

参考技术A 一、版本发布前，接口测试之痛

App版本发布前，我们都要手工做接口测试，目的是保证App内部H5页面所使用的JSAPI的功能正常，而对所有H5页面进行的P0级功能测试。为什么要做接口测试呢？因为JSAPI无法抓包，测试难度比较大，所以只能通过对H5页面的功能进行校验。但是手工测试，场景覆盖不全面，且耗时耗力。

二、JSAPI自动化测试方案

首先思考几个问题：一个APP有多少个JSAPI？它的用例场景有多少？如何能做到对用例的高效管理？

答案：对于我们app，有22条JSAPI，每条JSAPI多的话可能有几十个场景。传统的自动化方案，通常是一个场景需要手工编写一条用例，这种自动化的方案成本可以说也是非常高的，好在JSAPI并不常变动。但是，我们想实现一种更高效的自动化方式，不需要编写和管理那么多条用例，提升执行效率，同时降低学习成本。

2.1先来看看JSAPI是什么？

Html通过Jsapi，与app收发数据，形如：WebViewJavascriptBridge.callHandler

("API名称", 调用参数,  <回调函数>); js调用app的指定api，该方法由页面主动触发举个例子：

如上，getMainInfo是html中一个button的响应函数。我们在js中，通过JSBridge实现对相应JSAPI的调用，如下：实现H5页面可以直接获取到APP的maininfo数据。

2.2方案与原理

1、首先要解决用例管理的问题，我们实现了一种基于配置表的自动化测试方案，不需要编写脚本，只需把所有用例（含请求参数及返回参数的预期值），放到excel配置表中，通过解析器把所有的参数读出来，再通过模版字符串自动生成用例集。

2、jsapi不能脱离app执行，因此在app增加彩蛋入口，连接到一个网页，打开网页时，由js文件自动加载用例集去调用相关的jsapi接口，并用chai断言库对结果进行校验。

3、jsapi有两种，一种是有参数返回的，一种是会引发UI变更的，下图分别是两种jsapi的自动化校验方案。第一种在下文进行了详尽的描述，第二种需要基于UI的自动化去实现，解决了h5页面的控件在app中无法识别的问题。采用js定时传参给html，配合前端自动化去触发调用的方式实现。

2.3用例管理

如下图：第一行是参数名，蓝色是请求参数，绿色是所有返回参数，用‘/’分隔。返回参数的预期值，用正则表达式来表达。

2.4用例解析器

将上述表格解析为如下格式，params和result是两个数组，每个sheet有几行，数组就有几个值，表格中每行代表一个场景。解析器基于Node.js，在服务端运行。

2.5使用Node.js+模版字符串动态生成api.js

在解析得到的所有JSAPI名称后，将调用方法以字符串的方式写入文件中，动态生成我们要调用的所有JSAPI的调用方法，再被html所引用即可：

动态生成的api.js文件是下图这样的：

我们的用例配置表中有n个sheet，即有n个JSAPI的用例，我们这里就自动生成这几个JSAPI的调用方法，传入的req就是我们在配置表中读到的每一行用例中的请求参数。拿到回包的res，再去校验是否与解析配置表得到的所有返回参数一致。

2.6使用Node.js+模版字符串动态生成测试用例

Mocha是JavaScript的自动化测试框架，既可以运行在nodejs环境中，也可以运行在浏览器环境中。如下图，通过调用mocha.setup(‘bdd’)，开启 Mocha 的测试功能（testing helpers）。然后，加载需要的测试项和相应测试的文件。最后，调用了 mocha.run() 执行相应测试。

下图所示部分，自动生成测试用例，也是采用解析JSAPIList的同时写test.js文件的形式。

Ps：describe：称为"测试套件"（test suite），表示一组相关的测试。它是一个函数，第一个参数是测试套件的名称，第二个参数是一个实际执行的函数。

it：称为"测试用例"（test case），表示一个单独的测试，是测试的最小单位。

所有测试用例均为动态生成，如下图：

2.7Mocha框架自动化执行测试用例集

JSAPI的测试页面已经完成了，我们需要把它放到app中才能执行。在app的彩蛋页面放一个入口，加载这个html，当打开这个html的时候，服务自动的去执行并展示结果。如图，执行12条用例，只用了0.14s。

2.8自动化效果

目前，jsapi覆盖率已达70%，用例场景171个，执行耗时1.98s，Android和iPhone两个平台发现bug16个，涉及场景共35个，必现crash2个。

三、效果分析

在h5高产的今天，JSAPI的接口自动化测试解决了手工测试低效且覆盖不完全的苦恼，该方案在复用程度上也是非常友好的高度可复用的。只需创建自己的用例配置表，修改html中JSAPI的连接方式即可。

如何在多个文件中设置mocha测试用例的执行顺序

【中文标题】如何在多个文件中设置mocha测试用例的执行顺序

【英文标题】：How to set execution order of mocha test cases in multiple files

【发布时间】：2015-03-29 13:07:50

【问题描述】：

我有两个包含 mocha 测试用例的 javascript 文件。

//----------abc.js -------------

describe("abc file", function()
  it("test 1" , function()
    assert.equal(20 , 20); 
  );
); 

//---------xyz.js--------------
describe("xyz file", function()
      it("test 1" , function()
        assert.equal(10 , 10); 
      );
    );

我已将它们放在名为test 的文件夹中，当我执行mocha 命令时，第一个文件(abc.js) 总是在xyz.js 之前执行。 我认为这可能是由于字母顺序并将文件重命名为

abc.js => xyz.js
xyz.js => abc.js

但是，xyz.js（以前是 abc.js）的内容仍然首先执行。如何更改这些测试文件的执行顺序？

【参考方案1】：

mocha-steps 允许您编写以特定顺序运行的测试，在第一次失败时中止运行。它为it 提供了一个替代品，称为steps。

示例用法：

describe('my smoke test', async () => 
  step('login', async () => )
  step('buy an item', async () => throw new Error('failed'))
  step('check my balance', async () => )
  xstep('temporarily ignored', async () => )
)

该 repo 三年来没有太多活动，但它与 Mocha 9 配合得很好。

【参考方案2】：

我正在导出一个包含所有必需文件的数组，这就是我通过包含所有测试文件的文件夹中的 index.js 文件告诉 mocha 执行顺序的方式：

const Login = require('../login');
const ChangeBudgetUnit = require('./changeBudgetUnit');
const AddItemsInCart = require('./addItemsInCart'); 

// if the order matters should export array, not object
module.exports = [
    Login,
    ChangeBudgetUnit,
    AddItemsInCart
];

【参考方案3】：

按特定顺序执行我的测试的方法是创建一个单独的 test.js 文件，然后为我想要执行的每个 mocha 测试文件添加一个describe。

test.js：

describe('test file 1', function() 
  require('./test1.js')
)

describe('test file 2', function() 
  require('./test2.js')
)

然后只需运行mocha test.js

【参考方案4】：

我对此采取了完全独立的解决方案。

将所有测试放在名为 test/ 的文件夹中，然后 在根目录下按执行顺序创建文件tests.js

--- tests.js ---
require('./test/one.js')
require('./test/two.js')
require('./test/three.js')

在测试文件 one.js、two.js 等中编写你的简单 mocha 测试

如果你想按照你定义的顺序运行它们，那么只需运行mocha tests.js

【参考方案5】：

由于 mocha 按字母顺序对文件进行排序，我通常在测试文件名称前加上数字，例如：

0 - util.js 1 - something low level.js 2 - something more interesting.js

等等

除了非常易于维护（无需 gulp grunt 或任何废话，无需编辑您的 package.json...），它还提供以下好处：

阅读您的源代码的人会了解您的程序结构，从不太有趣的部分开始，一直到业务层 当测试失败时，你有一些因果关系的迹象（如果在1 - something.js 中失败但在0 - base.js 中没有失败，那么它可能是1 - something.js 覆盖的层的错误

如果您在进行真正的单元测试，当然顺序应该无关紧要，但我很少能够一直进行单元测试。

【讨论】：

这是最准确的答案。我最终这样做了。虽然不优雅是确保特定执行顺序的最佳方式，因为默认情况下文件是按字母顺序测试的。谢谢djfm！！

这样做的问题是 10 运行在 2 之前。

@Matt 我相信作者的意思是为“级别”而不是“步骤”提供数字。我最终也给我的步数编号，现在面临同样的问题 - 在 2 之前运行 10 次。

用零填充（如 001-067）有帮助

【参考方案6】：

如果您喜欢特定的顺序，您可以将文件（按顺序）列为mocha 的命令行参数，例如：

$ mocha test/test-file-1.js test/test-file-2.js

为避免每次运行时都输入大量内容，您可以在 package.json 中将其转换为 npm 脚本：

  // ...
  "scripts": 
    "test": "mocha test/test-file-1.js test/test-file-2.js"
  
  // ...

然后从命令行运行你的套件：

$ npm test

或者，如果您使用 Gulp，您可以在 gulpfile.js 中创建一个任务：

var gulp = require('gulp');
var mocha = require("gulp-mocha");

gulp.task("test", function() 
  return gulp.src([
      "./test/test-file-1.js",
      "./test/test-file-2.js"
    ])
    .pipe(mocha());
);

然后运行$ gulp test。

【讨论】：

我不确定这是不是真的。我通过在命令行中传入 3 个文件来测试这一点，然后 mocha 以非顺序执行它们。

它试图将它们全部作为一个文件读取，这对我不起作用。 警告：找不到任何匹配模式mocha test1.js test2.js“未找到测试文件”的测试文件

嗯，可能是 Mocha 的行为发生了变化。也有可能我误解了它的行为，而这只是发生对我有用。

【参考方案7】：

Mocha 有一个--sort（简称-S）选项可以对测试文件进行排序：

$ mocha --help

[...]
    -S, --sort                              sort test files
[...]

【讨论】：

按文件名字母顺序排列。

谢谢，我假设但想确认。

如果我不对它们进行排序，你能告诉我这些文件的执行顺序吗？

@Alexander，可能 «目录顺序» 非常依赖于您的文件系统。在 Linux 下，可能是创建文件的顺序。在 MS-Windows 上，它可能是随机的（好吧，可能不是，但我不确定 NFS 目前做了什么）。在 Mac OS/X 上，它将被排序。文件系统会自动执行此操作以加速 Finder。

记住：1、11、2、3、4

【参考方案8】：

在第二个文件中，需要第一个：

--- two.js ---
require("./one")

Mocha 将按照describe 调用的执行顺序运行测试。

【讨论】：

我喜欢这个，干净多了。将对此进行测试。这样做有什么影响吗（测试文件之间的变量范围？）

对于那些和我问同样问题的人：“如果所需的测试已经与 mocha 运行选项匹配，是否会执行两次？”，答案是“否”。所以这个解决方案似乎比执行随机的字母顺序要好得多。

@Gnucki 按字母顺序，根据定义，不是随机的。

这里的随机是指字母顺序没有理由与测试顺序匹配（除非您在文件名前加上前缀，这肯定是一件坏事）。

这是最好的解决方案，因为它允许您自动将事物按依赖顺序排列。我要问的唯一问题是，您是否可以做些什么来利用它来使运行测试取决于（一个或多个？）所需文件中的测试的成功（我可能不需要测试拉取数据例如，如果我的登录测试失败）。