接口测试 [接口测试平台二期] 接口测试服务之建表

bauul · 2018年02月05日 · 最后由 bauul 回复于 2019年07月05日 · 423 次阅读

缘由

之前已经将接口测试参数化做好了,踩了一些坑,现在基本上搞定了。
接下来的计划是做一个接口测试服务,计划的方案是:
前端:VUE+axios ==> 完全没接触到,从头学起
后端:Spring boot + mybatis + REST
数据库:Mysql

所以按着之前的接口测试参数化方案写了几张表

sql

DROP TABLE IF EXISTS `tb_user`;
CREATE TABLE `tb_user` (
    `user_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '用户id,自增主键',
    `account` varchar(64) NOT NULL DEFAULT '' COMMENT '用户名',
    `password` varchar(64) NOT NULL DEFAULT '' DEFAULT '0' COMMENT '密码',
    `email` varchar(256) DEFAULT '' COMMENT '邮箱',
    `role` varchar(16) DEFAULT 'USER' COMMENT '用户权限',

    PRIMARY KEY (`user_id`),
    UNIQUE KEY `UNIQUE_account` (`account`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='用户表';

DROP TABLE IF EXISTS `tb_project`;
CREATE TABLE `tb_project` (
    `project_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增主键',
    `project_name` varchar(64) NOT NULL DEFAULT '' COMMENT '项目名',
    `project_desc` varchar(512) NOT NULL DEFAULT '' COMMENT '项目描述',

    PRIMARY KEY (`project_id`),
    UNIQUE KEY `UNIQUE_project_name` (`project_name`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='测试项目表';

DROP TABLE IF EXISTS `tb_project_global_host`;
CREATE TABLE `tb_project_global_host` (
    `global_host_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增主键',
    `project_id` int(11) unsigned NOT NULL DEFAULT '0' COMMENT '项目id',
    `global_host_desc` varchar(512) NOT NULL DEFAULT '' COMMENT '全局地址描述',
    `global_host_url` varchar(128) NOT NULL DEFAULT '' COMMENT '全局地址',

    PRIMARY KEY (`global_host_id`),
    KEY `idx_project_id` (`project_id`),
    UNIQUE KEY `UNIQUE_global_host_desc` (`global_host_desc`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='项目全局地址表';

DROP TABLE IF EXISTS `tb_project_global_parameters`;
CREATE TABLE `tb_project_global_parameters` (
    `global_parameters_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增主键',
    `project_id` int(11) unsigned NOT NULL DEFAULT '0' COMMENT '项目id',
    `global_parameters_desc` varchar(512) NOT NULL DEFAULT '' COMMENT '全局参数描述',
    `global_parameters` varchar(512) NOT NULL DEFAULT '' COMMENT '全局参数',

    PRIMARY KEY (`global_parameters_id`),
    KEY `idx_project_id` (`project_id`),
    UNIQUE KEY `UNIQUE_global_parameters_desc` (`global_parameters_desc`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='项目全局参数表';

DROP TABLE IF EXISTS `tb_project_global_asserts`;
CREATE TABLE `tb_project_global_asserts` (
    `global_asserts_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '自增主键',
    `project_id` int(11) unsigned NOT NULL DEFAULT '0' COMMENT '项目id',
    `global_asserts_desc` varchar(512) NOT NULL DEFAULT '' COMMENT '全局断言描述',
    `global_asserts` varchar(512) NOT NULL DEFAULT '' COMMENT '全局断言',

    PRIMARY KEY (`global_asserts_id`),
    KEY `idx_project_id` (`project_id`),
    UNIQUE KEY `UNIQUE_global_asserts_desc` (`global_asserts_desc`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='项目全局断言表';

DROP TABLE IF EXISTS `tb_feature`;
CREATE TABLE `tb_feature` (
    `feature_id` int(11) NOT NULL AUTO_INCREMENT,
    `feature_name` varchar(64) NOT NULL DEFAULT '' COMMENT '模块名',
    `feature_desc` varchar(512) NOT NULL DEFAULT '' COMMENT '模块描述',
    `project_id` int(11) NOT NULL DEFAULT '0' COMMENT '项目id',

    PRIMARY KEY (`feature_id`),
    UNIQUE KEY `UNIQUE_feature_name` (`feature_name`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='测试模块表';

DROP TABLE IF EXISTS `tb_api_test_data`;
CREATE TABLE `tb_api_test_data` (
    `data_id` int(11) NOT NULL AUTO_INCREMENT,
    `data_desc` varchar(512) NOT NULL DEFAULT '' COMMENT '数据描述',
    `user_id` int(11) NOT NULL DEFAULT '0' COMMENT '用户id',

    PRIMARY KEY (`data_id`),
    KEY `idx_user_id` (`user_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='测试数据表';

DROP TABLE IF EXISTS `tb_api_test_data_values`;
CREATE TABLE `tb_api_test_data_values` (
    `value_id` int(11) NOT NULL AUTO_INCREMENT,
    `data_id` int(11) NOT NULL DEFAULT '0' COMMENT '数据id',
    `data_value` text NOT NULL COMMENT '数据内容',

    PRIMARY KEY (`value_id`),
    KEY `idx_data_id` (`data_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='测试数据内容表';

DROP TABLE IF EXISTS `tb_api_test_case`;
CREATE TABLE `tb_api_test_case` (
  `case_id` int(11) NOT NULL AUTO_INCREMENT,
  `user_id` int(11) NOT NULL DEFAULT '0' COMMENT '用户id',
  `project_id` int(11) NOT NULL DEFAULT '0' COMMENT '项目id',
  `feature_id` int(11) DEFAULT '0' COMMENT '模块id',
  `case_name` varchar(512) NOT NULL DEFAULT '' COMMENT '用例名',
  `case_desc` varchar(512) NOT NULL DEFAULT '' COMMENT '用例描述',
  `url` varchar(512) NOT NULL DEFAULT '' COMMENT '接口地址',
  `req_content_type` varchar(256) NOT NULL DEFAULT '' COMMENT '请求参数类型,默认json',
  `req_body` text NOT NULL COMMENT '请求体',
  `res_content_type` varchar(256) NOT NULL DEFAULT 'json' COMMENT '响应参数类型,默认json',
  `method` tinyint(1) NOT NULL DEFAULT '0' COMMENT '请求类型,0表示post,1表示get',
  `case_status` tinyint(1) NOT NULL DEFAULT '0' COMMENT '用例状态,0表示在使用,1表示已废弃',
  `case_comment` varchar(512) NOT NULL DEFAULT '' COMMENT '备注信息',
  `update_time` int(10) NOT NULL DEFAULT '0' COMMENT '用例更新时间',
  `res_assert` varchar(2048) NOT NULL DEFAULT '' COMMENT '响应断言',
  `sql_assert` varchar(2048) NOT NULL DEFAULT '' COMMENT 'sql断言',
  `batch_data` varchar(512) NOT NULL DEFAULT '' COMMENT '批量数据',
  `batch_data_use_one` tinyint(1) NOT NULL DEFAULT '0' COMMENT '是否每次使用批量数据中的一个',

  PRIMARY KEY (`case_id`),
  UNIQUE KEY `case_name` (`case_name`),
  KEY `idx_project_id` (`project_id`),
  KEY `idx_feature_id` (`feature_id`),
  KEY `idx_user_id` (`user_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='接口测试用例表';

DROP TABLE IF EXISTS `tb_api_test_sql`;
CREATE TABLE `tb_api_test_sql` (
    `sql_id` int(11) NOT NULL AUTO_INCREMENT,
    `case_id` int(11) NOT NULL DEFAULT '0' COMMENT '接口测试用例ID',
    `column_name` varchar(32) NOT NULL DEFAULT '' COMMENT '如果是查询语句,需要获取的列名',
    `local_json_path` varchar(256) NOT NULL DEFAULT '' COMMENT '接口测试用例的jsonpath',
    `db_url` varchar(512) NOT NULL DEFAULT '' COMMENT '数据库地址',
    `db_user` varchar(64) NOT NULL DEFAULT '' COMMENT '数据库用户名',
    `db_password` char(8) NOT NULL DEFAULT '' COMMENT '数据库密码',
    `sql_type` enum('delete','update','insert','select') NOT NULL DEFAULT 'select' COMMENT 'sql语句类型',
    `sql_statement` varchar(512) NOT NULL DEFAULT '' COMMENT 'sql语句',
    `is_before` tinyint(1) NOT NULL DEFAULT '0' COMMENT '前置sql还是后置sql,0表示前置,1表示后置',

    PRIMARY KEY (`sql_id`),
    KEY `idx_case_id` (`case_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='接口测试用例需要执行的sql表';

DROP TABLE IF EXISTS `tb_api_test_reference_case`;
CREATE TABLE `tb_api_test_reference_case` (
    `rec_id` int(11) NOT NULL AUTO_INCREMENT,
    `case_id` int(11) NOT NULL DEFAULT '0' COMMENT '接口测试用例ID',
    `reference_case_id` int(11) NOT NULL DEFAULT '0' COMMENT '依赖的接口测试用例ID',
    `reference_body_type` tinyint(1) NOT NULL DEFAULT '0' COMMENT '依赖的接口测试用例请求,还是响应,0表示响应,1表示请求',
    `remote_json_path` varchar(256) NOT NULL DEFAULT '' COMMENT '依赖的接口测试用例的jsonpath',
    `local_json_path` varchar(256) NOT NULL DEFAULT '' COMMENT '接口测试用例的jsonpath',

    PRIMARY KEY (`rec_id`),
    KEY `idx_case_id` (`case_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='接口测试用例与依赖用例关系表';

DROP TABLE IF EXISTS `tb_api_test_suite`;
CREATE TABLE `tb_api_test_suite` (
    `suite_id` int(11) NOT NULL AUTO_INCREMENT,
    `suite_name` varchar(512) NOT NULL DEFAULT '' COMMENT '测试用例集名称',
    `test_object` varchar(512) NOT NULL DEFAULT '' COMMENT '测试目的',
    `project_id` int(11) NOT NULL DEFAULT '0' COMMENT '项目id',

    PRIMARY KEY (`suite_id`),
    UNIQUE KEY `UNIQUE_suite_name` (`suite_name`),
    KEY `idx_project_id` (`project_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='接口测试用例集表';

DROP TABLE IF EXISTS `tb_api_test_suite_case_relation`;
CREATE TABLE `tb_api_test_suite_case_relation` (
    `rec_id` int(11) NOT NULL AUTO_INCREMENT COMMENT '测试用例集与用例关系id',
    `suite_id` int(11) NOT NULL DEFAULT '0' COMMENT '测试用例集id',
    `case_id` int(11) NOT NULL DEFAULT '0' COMMENT '测试用例id',

    PRIMARY KEY (`rec_id`),
    KEY `idx_suite_id` (`suite_id`),
    KEY `idx_case_id` (`case_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='接口测试用例集与用例关系表';

DROP TABLE IF EXISTS `tb_api_test_task`;
CREATE TABLE `tb_api_test_task` (
    `task_id` int(11) NOT NULL AUTO_INCREMENT,
    `task_name` varchar(512) NOT NULL DEFAULT '' COMMENT '接口测试任务名称',
    `suite_id` int(11) NOT NULL DEFAULT '0' COMMENT '测试用例集id',
    `global_parameters_id` int(11) NOT NULL DEFAULT '0' COMMENT '全局参数id',
    `user_id` int(11) NOT NULL DEFAULT '0' COMMENT '用户id',

    PRIMARY KEY (`task_id`),
    UNIQUE KEY `UNIQUE_task_name` (`task_name`),
    KEY `idx_suite_id` (`suite_id`),
    KEY `idx_user_id` (`user_id`),
    KEY `idx_global_parameters_id` (`global_parameters_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='接口测试任务表';

DROP TABLE IF EXISTS `tb_api_test_result`;
CREATE TABLE `tb_api_test_result` (
  `result_id` int(11) NOT NULL AUTO_INCREMENT,
  `suite_id` int(11) NOT NULL DEFAULT '0',
  `case_id` int(11) NOT NULL DEFAULT '0',
  `result` enum('Pass','Fail','Skip','') NOT NULL DEFAULT '' COMMENT '用例测试结果',
  `error_info` mediumtext NOT NULL COMMENT '异常堆栈信息',
  `res_body` longtext NOT NULL COMMENT '接口响应内容',
  `case_start_time` bigint(13) unsigned NOT NULL COMMENT '用例开始时间',
  `case_end_time` bigint(13) unsigned NOT NULL COMMENT '用例结束时间',
  `case_run_time` int(13) unsigned NOT NULL COMMENT '用例执行用时',

  PRIMARY KEY (`result_id`),
  KEY `idx_resultId_caseRunTime` (`result_id`,`case_id`,`result`,`case_run_time`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb4 COMMENT='接口测试用例结果表';

DROP TABLE IF EXISTS `tb_feedback`;
CREATE TABLE `tb_feedback` (
    `feedback_id` int(11) NOT NULL AUTO_INCREMENT,
    `feedback_desc` text NOT NULL COMMENT '反馈描述',
    `feedback_status` enum('solved','unsolved','not-solve') NOT NULL DEFAULT 'unsolved'  COMMENT '反馈状态',
    `solution` text COMMENT '解决方案', 
    `user_id` int(11) NOT NULL DEFAULT '0' COMMENT '用户id',

    PRIMARY KEY (`feedback_id`),
    KEY `idx_user_id` (`user_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='反馈表';

DROP TABLE IF EXISTS `tb_image_flow`;
CREATE TABLE `tb_image_flow` (
    `flow_id` int(11) NOT NULL AUTO_INCREMENT,
    `url` text NOT NULL COMMENT '图片链接',
    `frame_len` int(11) NOT NULL DEFAULT '0' COMMENT '流量消耗',
    `image_size` int(11) NOT NULL DEFAULT '0' COMMENT '图片大小',
    `response_time` int(11) NOT NULL DEFAULT '0' COMMENT '响应时间',
    `test_time` int(10) NOT NULL DEFAULT '0' COMMENT '测试时间',

    PRIMARY KEY (`flow_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='app图片大小统计表';

问题

  • 做成服务,也不一定就真的提升了效率,花了很大的时间和精力去做,到头来可能是个鸡肋
  • 接口用例请求,参数等源于 Har 文件,这个文件本身是个 json 数据,用文档型的 mongodb 去存储是不是更好些?
  • 同一条用例可以归属到不同的用例集中,在同一个用例集中也可重复出现同一条用例,这样的关系用 mysql 去存储,我有点不知所措(已解决)
  • 用例 A 依赖用例 B 和用例C的关系,怎么存才好呢(已解决)

自问自答

问:用户 id 和用户名都是唯一的,那么用 user_name 作主键不就好了?
答:1. user_name 在某些场景可能允许修改
2. user_name 是 varchar 型的,判断是否重复需要遍历每个字符,效率上肯定不如 int 型的

其他 mysql 相关知识:

  1. 通用数字就别用字符串,最小的数字占 8 位(tinyint),最大的 64 位(bigint)
  2. 定长或修改较少的列使用 char
  3. BLOB 使用二进制存储字符串;TEXT 使用字符存储,存储的字符很长时,可以按字符的前面多少位来排序,ORDER BY SUSTRING(col, len),或修改配置:max_sort_length

范式

范式 :英文名称是 Normal Form,它是英国人 E.F.Codd(关系数据库的老祖宗)在上个世纪 70 年代提出关系数据库模型后总结出来的,范式是关系数据库理论的基础,也是我们在设计数据库结构过程 中所要遵循的规则和指导方法。数据库的设计范式是数据库设计所需要满足的规范。只有理解数据库的设计范式,才能设计出高效率、优雅的数据库,否则可能会设 计出错误的数据库。目前有迹可寻的共有 8 种范式,依次是:1NF,2NF,3NF,BCNF,4NF,5NF,DKNF,6NF。
满足最低要求的叫第一范 式,简称 1NF。在第一范式基础上进一步满足一些要求的为第二范式,简称 2NF。其余依此类推。通常所用到的只是前三个范式,即:第一范式(1NF),第 二范式(2NF),第三范式(3NF)

第一范式

第一范式是指数据库表中的每一列都是不可分割的基本数据项,同一列中不能有多个值,即实体中的某个属性不能有多个值或者不能有重复的属性。

如果出现重复的属性,就可能需要定义一个新的实体,新的实体由重复的属性构成,新实体与原实体之间为一对多关系。第一范式的模式要求属性值不可再分裂成更小部分,即属性项不能是属性组合或是由一组属性构成。

简而言之,第一范式就是无重复的列。

第二范式

第二范式 (2NF) 是在第一范式 (1NF) 的基础上建立起来的,即满足第二范式 (2NF) 必须先满足第一范式 (1NF)。第二范式 (2NF) 要求数据库表中的每个实例或行必须可以被唯一地区分。为实现区分通常需要为表加上一个列,以存储各个实例的唯一标识。

如果关系模型 R 为第一范式,并且 R 中的每一个非主属性完全函数依赖于 R 的某个候选键,则称 R 为第二范式模式 (如果 A 是关系模式 R 的候选键的一个属性,则称 A 是 R 的主属性,否则称 A 是 R 的非主属性)。

例如,在选课关系表 (学号,课程号,成绩,学分),关键字为组合关键字 (学号,课程号),但由于非主属性学分仅依赖于课程号,对关键字 (学号,课程号) 只是部分依赖,而不是完全依赖,因此此种方式会导致数据冗余以及更新异常等问题,解决办法是将其分为两个关系模式:学生表 (学号,课程号,分数) 和课程表 (课程号,学分),新关系通过学生表中的外关键字课程号联系,在需要时进行连接。

第三范式

如果关系模型 R 是第二范式,且每个非主属性都不传递依赖于 R 的候选键,则称 R 是第三范式的模式。

以学生表 (学号,姓名,课程号,成绩) 为例,其中学生姓名无重名,所以该表有两个候选码 (学号,课程号) 和 (姓名,课程号),故存在函数依赖:学号——>姓名,(学号,课程号)——>成绩,唯一的非主属性成绩对码不存在部分依赖,也不存在传递依赖,所以属性属于第三范式。

BC 范式

它构建在第三范式的基础上,如果关系模型 R 是第一范式,且每个属性都不传递依赖于 R 的候选键,那么称 R 为 BCNF 的模式。
假设仓库管理关系表 (仓库号,存储物品号,管理员号,数量),满足一个管理员只在一个仓库工作;一个仓库可以存储多种物品,则存在如下关系:

(仓库号,存储物品号)——>(管理员号,数量)

(管理员号,存储物品号)——>(仓库号,数量)

所以,(仓库号,存储物品号) 和 (管理员号,存储物品号) 都是仓库管理关系表的候选码,表中唯一非关键字段为数量,它是符合第三范式的。但是,由于存在如下决定关系:

(仓库号)——>(管理员号)

(管理员号)——>(仓库号)

即存在关键字段决定关键字段的情况,因此其不符合 BCNF。把仓库管理关系表分解为两个关系表仓库管理表 (仓库号,管理员号) 和仓库表 (仓库号,存储物品号,数量),这样这个数据库表是符合 BCNF 的,并消除了删除异常、插入异常和更新异常。

反范式

反范式是通过增加冗余数据或数据分组来提高数据库读性能的过程,主要是通过空间来换时间。
在某些情况下, 反范式有助于掩盖关系型数据库软件的低效。关系型的范式数据库即使做过优化, 也常常会带来沉重的访问负载。

范式与反范式的比较

  1. 查询记录时,范式模式往往要进行多表连接,而反范式只需在同一张表中查询,当数据量很大的时候,显然反范式的效率会更好。
  2. 反范式有很多重复的数据,会占用更多的内存,查询时可能会较多地使用 DROUP BY 或 DISTINCT 等耗时耗性能的关键字。
  3. 当要修改更新数据时,范式更灵活,而反范式要修改全部的数据,且易出错。

参考:

https://www.zhihu.com/question/24696366
数据大小定义

附言 1  ·  2018年03月01日

看了一下,beta 环境中的表,有 1000 多张,但是没有一张表有外键,百度了下,外键会影响性能,所以我也移除了外键

附言 2  ·  2018年02月06日

新增了两张表,

  • 接口测试用例需要执行的 sql 表
  • 接口测试用例与依赖用例关系表 解决用例依赖的 sql,用例 a 与用例 b 和 c 的依赖关系问题
如果觉得我的文章对您有用,请随意打赏。您的支持将鼓励我继续创作!
共收到 9 条回复 时间 点赞

刚做完一套类似的,关系是这样:
test_api : 接口信息
test_case: 具体的某一条用例, 与 test_api\ test_suite 均通过外键关联
test_suite: 测试集, 与 test_api\ test_case 均通过外键关联

其中一个 test_suite 下可以关联多个 test_api , 每个 test_api 下面关联多个 test_case

Jerry li 回复

谢谢,关键是用例 A 依赖用例 B 的话,这个关系你怎么解决的?

bauul 回复

用例 A 依赖用例 B ,是指上下文的依赖吗? 比如做查询(用例 B)之前需要先登录(用例 A)拿到 token?

这种场景我们目前没遇到,感觉可以往这方面考虑:

  1. 如果一个前置用例是通用的(例如所有操作都需要先登录), 可以考虑把获取到的用户名、token 等信息保存到公共配置表里,其他用例从配置表里读取这些信息。 这样需要保证执行其他用例前先执行前置用例。
  2. 如果是单个用例之间的依赖,可以考虑在用例表中添加前置用例 ID、参数列表两个字段。 如 用例 B 依赖 用例 A 的 A1、A2 两个字段(可以用 json 存储为同一个字段里),则执行时先执行用例 A ,并通过获取到的 A1、A2 字段,再执行用例 B
Jerry li 回复

是的,上下文依赖,
比如支付的用例前,需要先下单,和添加收货地址,拿到订单号和地址 ID,就是说有时一条用例依赖的数据不止一个,
所以不能用一个字段存一个依赖的用例这样做,需要一个字段中存放依赖的一组用例,
但是这样做的时候,在被依赖的用例被删除或修改的时候,是不是只能遍历整个用例库,去告诉用户,可能影响到的用例了?

bauul 回复

我觉得要看你测试的目的和侧重点:

  1. 如果是侧重业务流程的测试,上面说的方式就需要三个用例串起来执行。 这时可以考虑通过特定用例集的方式结合起来测试。
  2. 如果是侧重接口的回归,那么订单号、收货地址都可以不依赖对应的接口来实现。 例如收货地址,可以直接写死或者配置多个来选择就可以了。业务流程实际上也是三个接口独立保证的,如果验证覆盖全了,三个接口分别测试通过,和把三个接口连起来一起测试通过,效果是一样的。

我是倾向用第二种的,因为保持用例间的独立性,才能保证用例的独立执行。

Jerry li 回复

嗯,我是二种都需要,我增加了一张表:

DROP TABLE IF EXISTS `tb_api_test_reference_case`;
CREATE TABLE `tb_api_test_reference_case` (
  `reference_id` int(5) NOT NULL AUTO_INCREMENT,
  `case_id` int(5) NOT NULL COMMENT '接口测试用例ID',
  `reference_case_id` int(5) NOT NULL COMMENT '依赖的接口测试用例ID',
  `reference_body_type` char(8) NOT NULL COMMENT '依赖的接口测试用例请求,还是响应'
  `remote_json_path` varchar(1024) NOT NULL COMMENT '依赖的接口测试用例的jsonpath',
  `local_json_path` varchar(1024) NOT NULL COMMENT '接口测试用例的jsonpath',  

  PRIMARY KEY (`reference_id`)
) ENGINE=InnoDB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8 COMMENT='接口测试用例与依赖用例关系表';

增加这张接口测试用例与依赖用例关系表就可以了,非常感谢👍

bauul [接口测试平台二期] 批量数据支持 中提及了此贴 06月22日 11:15

大佬 开源没

kada1209 回复

还没有噢

需要 登录 后方可回复, 如果你还没有账号请点击这里 注册