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

大家好~我是米洛！

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

欢迎关注我的个人龚仲耗测试开发坑货，获取最新文章教程!

回顾

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

新的篇章

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

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

最终效果大概会长这样:

image

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

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

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

相关改造

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

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

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

image

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

这就是预览图

调整获取用例列表方法

image

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

调整获取单个case的方法

可以看到改动还是挺多的

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

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

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

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

---

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