测试平台系列(61) 重构用例详情页面

2021年09月16日 阅读数:3
这篇文章主要向大家介绍测试平台系列(61) 重构用例详情页面,主要内容包括基础应用、实用技巧、原理机制等方面,希望对大家有所帮助。

你们好~我是米洛


这是一个完整的接口测试平台系列教程,但愿能和你们一块儿学习,从0到1打造一个开源平台。



欢迎关注个人公众号测试开发坑货,获取最新文章教程!前端

回顾

上一节咱们插入了题外话: 部署相关的内容,让咱们这节继续回到case相关的话题。redis

新的篇章

其实在以前的用例编写相关页面废弃之后,我一直在思考怎么去构建一个合理的,人性化的用例编写页面。数据库

但其实也没有找到好的解决方案,期间也参考过一些其余优秀的开源项目。最终呢,我仍是回归到了Tab模式:后端

最终效果大概会长这样:异步

主要分为2块,上面是用例相关的数据,下面是编写用例的核心地方,分为常见的模块。学习

下方分为4个步骤,数据构造器(前置条件)-> 接口请求 -> 断言 -> 数据清理。测试

符合人体工学设计的setUp -> test -> assert -> tearDown设计

相关改造

这些基本上算是前端页面的改造,可是后端接口也会有一些变化。因此咱们得对接口作一些适配。code

查询单个项目的时候,咱们把case信息获取步骤删掉,加快接口响应速度

编写根据用例id获取前置条件的方法

注意这里有一个伏笔: 咱们的前置条件确定是有顺序去执行的,但我这边按照建立时间排序,显然是不友好的,但后面咱们会支持变动前置条件执行顺序的功能。排序

这就是预览图

调整获取用例列表方法

改成异步执行,而且支持根据目录获取case,减小大规模查询case的次数。

调整获取单个case的方法

能够看到改动仍是挺多的

之前只拿testcase,如今须要拿到case的基本信息前置条件,断言信息,最后封装到一个字典里面返回,后面还会有后置条件

这边没有选择用join,由于涉及的表比较多,因此咱们查询屡次,后续咱们能够把查询好的数据都放入redis,减轻数据库的压力。

为何要花这么多时间进行这块的改造,实际上是由于以前确实太难用了。

好比我本身都以为添加一个前置条件特别费劲,添加后还不能展现出来。


今天的内容就介绍到这里,下一节讲如何控制前置条件的执行顺序