4、大型项目的接口自动化实践记录----数据分离

一、为什么做数据分离

前面实现了接口的请求到校验

那么如果要对多个商品价格查询，或者要做对不存在的商品查询之类的反例呢

于是我们再次新建一条case，再次编写了下脚本

 

那如果用例有10条，100条，那这些代码就要写10遍100遍，那么万一它的地址改了，我们就要改10遍100遍。

我们观察这条用例，发现与前面那条用例，只有skuids与预期结果不一样，那么我们是否可以把那些一样的部分提取出来，做成一个类似模板的东西，每次使用的时候套用呢？

二、数据分离实现

1、新建关键字（模板）

右键目录，点击New Resource

 

输入Name，勾选Txt或者ROBOT，点击OK

 

如前面导入库的方式，导入RequestsLibrary

 

新增New User Keyword

 

输入名字，点击OK

 

如下图，点击该关键字，在右侧脚本行把脚本写入，其中${skuIds}， ${except_result}参数化

PS：另外养成良好习惯，在documentation处写上对应的备注

 

以上我们关键字就建好了，要怎么使用呢

2、使用关键字

跟导入库类似，要先导入刚才新建的resource，这样才能使用resource下的关键字

回到suite，点击suite，右侧点击Resource，输入刚才新建的resource文件名（练习flow.txt），点OK

 

回到suite下的测试用例，输入前面新增的user keyword名，可以看到是蓝色字样，后面红色格子代表该方法必传的参数

 

光标在方法名上，按ctrl，可以看到方法说明，可以看到我们前面的备注也有展示

 

把skuids和预期结果再方法后面输入，执行case，可以发现与前面完整case执行的效果一样。

所以我们多个case的时候，通过这种方式，数据分离后，数据只管对应的输入输出，具体执行过程封装到方法中。

 

3、数据维护方式

数据分离实现了，那么数据部分有哪些维护方式呢：

1、一条数据一个case

如下图，每个case对应一条数据

 

2、通过模板在一个case中写所有数据

如下图，通过Template，在一个case中维护所有数据

 

以上数据直接维护在RF的case文件中，除了这种方式，还可以把数据维护在其他地方

3、通过excel、csv等文件维护数据，脚本从文件读取（这块因为作用与前两种方式一样，先不写，以后补充）

4、数据维护在数据库中，脚本从数据库获取（这块是下个方法的简化版）

5、直接获取手工测试后生成的数据，处理后作为测试数据（后面的文章里写这块）

四、其他简单封装

回到我们接口的例子中，一个项目接口执行多个，我们会发现，项目中大多数接口的请求头、请求的过程都相似，因此我们再做一下封装：

在项目下新建一个resource文件（接口基础方法），导入库RequestsLibrary

 

封装方法：获取默认headers

 

封装请求方法：

 

返回码异常，抛异常或者提示

 

返回的结果如果本身就报错，也可以抛异常（视情况使用）

 

这样我们就可以更专注于实际业务

 

当然前面的结果对比，也可以做下封装（这部分比较复杂，可跳过）

判断两个json是否相等，先全文本对比，如果相等则正确，跳过，若不相等则进行深入判断

 

通过递归，逐层进行判断，当找到不同的值时，抛出路径及不等的原因

 

 

上一篇　　3、大型项目的接口自动化实践记录----开放API练习

下一篇　　5、大型项目的接口自动化实践记录----登录