测试平台系列(36) 使用全局变量

大家好，这里是老克，一个想和大家一起分享测试开发相关的技术，面试经验和成长经历的博主！

欢迎大家关注我的公众号: 测试开发坑货。

回顾

上篇我们已经编写好了全局变量的页面，今天我们就来学习怎么使用他。

Windows下的环境变量

其实说白了，全局变量也就是一个参数的读取->替换的过程。所以我们得先补习一下el表达式的知识。（关于jsonpath，这个我不太熟悉，我不太算Java技术栈的）

我们都知道，在Windows等操作系统里面会有环境变量的概念，比如:

image

当我们echo %JAVA_HOME%的时候，为什么输出的不是"%JAVA_HOME%"呢？因为windows有相关的约定，当字符串被%%包裹的话，意味着取值会从环境变量里面寻找，如果找不到，就不进行替换:

这个变量不存在，所以不进行任何替换操作

EL表达式

这是我当时在上上家公司设计的一套变量表示语法，但是意外撞了EL表达式。我约定的是用${}包裹起来的内容都算作变量，这样在接口测试中如果有需要传递变量的情况，就可以用这个方式来解决。

EL表达式源自我现在正在维护的一个JSP的项目，也算是一种猿粪吧！

思路

我们现在支持3种变量类型: JSON/YAML/STRING。我们的步骤也很简单:

1. 拿到变量的值（取值）
2. 替换变量为对应的真实值(替换)

编写变量解析器

• 编写解析器基类

image

基类有2个方法:

• 解析

• 取值

  解析是一个待实现的方法，因为不同的类型解析器不一样，未来如果需要支持XML类型，那也要重写这个方法。

  取值比较通用，目前来讲，我们解析完yaml以后也是一个json对象，所以可以写在基类中。

  我们来仔细看看这段代码:

参数部分

parse接受2个参数，data是解析后的数据（一般是JSON对象），key是el表达式的路径如: JAVA_HOME。但是我们不能只做最简单的，我们还需要获取深层次路径的值。

举个例子:

全局变量INFO的值是个JSON类型:

{
  "name": "wc",
  "age": 19,
  "hobby": "play game"
}

我们如果只通过INFO取到JSON对象，那是远远不行的，我们还需要能够通过INFO.age取到对应的年龄。所以我们这里编写了get方法。

实现过程

其实道理很简单，我们先通过.去分割字符串，如果是INFO.age，那么字符串就会成为: ["INFO", "age"]数组。接着我们从数组的第2个元素去遍历，如果取到的是数字，那么我们就按照数组索引去取值，如果是普通的key，就按照map来取值。

最后做一个异常捕获，防止那种乱写变量的情况出现。如果result是字符串，我们直接返回。如果是数字类型，那我们就将它转为字符串类型。

思考

因为我们现在是取值，后期替换的时候是用replace把${INFO.age}替换为对应的值，如果你的age是19这个数字的话，想一下replace会出错吗？

分别实现3种解析器

image

先看string类型，因为他自己不可能再去深层次取值了。

说到这里，我突然想到它可以直接索引去取对应的字符串子串，但是我不太建议支持这样的功能。因为索引需要2个值，1个的话比较鸡肋。这样对于我们的el表达式来说不是太统一。

所以我们直接return value，也就是不需要进行更深层次取值了。

再看JSON和yaml类型，其实就是load了一下数据（将字符串数据转为JSON对象）。

编写GConfigDao获取key的方法

之前我们的查询变量的方法，都是批量的，或者说是查询一个列表。我们需要一个更精确的搜索，只要一条变量的数据。

image

接受key的名字和对应的环境，如果环境不传的话，则不根据环境去查询。因为目前我们用例执行的时候没有跟环境绑定，所以暂时先不传入env，后续备用的字段。

这里想到了小方的疑惑，之前可能go写多了，下意识会把err return回去，现在改成Python的写法了。

改写用例的执行部分

在我的理解里面，用例的变量替换是在用例执行的第一步，并且替换的地方只有那几处:

• url
• request_header
• body

因为目前还没有前后置条件，所以后续再补充，断言里的内容也如此，它们独立于用例之外了。

改造Executor类

image

• 新增fields字段，存放需要替换变量的字段。

• 编写parse_gconfig方法

  依次去修改各个字段中的变量。

• 编写get_parser

  这个是根据gconfig类型来获取对应的解析器，如果0则为String解析器，1则是JSON解析器，2则是Yaml解析器。

• parse_field

  这个方法是先获取原始字段里面的el表达式，然后依次去解析到真实数据，最后再修改TestCase的字段（注意只是临时修改，不修改数据表）。

目前代码优化点### 在run方法加上有2处:

1. 通过key获取配置的时候，一旦一个字段里面出现2个参数的时候，会获取2次key，也就是查询db2次，这样开销很大
2. 每次跑都会执行db，开销巨大，可以考虑本地缓存或者redis缓存。

修改run方法

image

--

看下效果

image

可以看到参数都已经进行了替换，我们再来看看变量BASIC_CONFIG的内容:

image

image

--

那么，本期内容到这里就结束了。

在线演示地址: http://47.112.32.195/

前端代码仓库: https://github.com/wuranxu/pityWeb

后端代码仓库: https://github.com/wuranxu/pity