61.重构用例详情页面

大家好~我是米洛

这是一个完整的接口测试平台系列教程,希望能和大家一起学习,从0到1打造一个开源平台。

欢迎关注我的公众号测试开发坑货,获取最新文章教程!

📒 回顾

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

📒 新的篇章

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

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

最终效果大概会长这样:

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

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

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

📒 相关改造

这些基本上算是前端页面的改造,但是后端接口也会有一些变化。所以我们得对接口做一些适配。

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

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

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

这就是预览图
这就是预览图

🍦 调整获取用例列表方法

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

🍦 调整获取单个case的方法

可以看到改动还是挺多的
可以看到改动还是挺多的

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

这边没有选择用join,因为涉及的表比较多,所以我们查询多次,后续我们可以把查询好的数据都放入redis,减轻数据库的压力。

为什么要花这么多时间进行这块的改造,其实是因为之前确实太难用了。

比如我自己都觉得添加一个前置条件特别费劲,添加后还不能展示出来。


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