测试平台系列(119) 优化测试报告跳转用例功能

一起养成写作习惯！这是我参与「掘金日新计划 · 4 月更文挑战」的第9天，点击查看活动详情。

大家好~我是米洛！
我正在从0到1打造一个开源的接口测试平台, 也在编写一套与之对应的教程，希望大家多多支持。
欢迎关注我的公众号米洛的测开日记，一起交流学习!

上一节我们优化了返回值相关的内容，今天我们就顺藤摸瓜，以一个产品经理的角色，来找找自己的问题。

其实很多时候都是当局者迷，所以如果各位有兴趣，也可以参与到需求收集的过程中来。这里感谢大家提出的一些建议，我都有记录。

可以看到，需求还是挺多的。由于都是私下抽时间来写，所以效率比较低。今天我们就来完成这个小功能点: 测试报告跳转到对应的case。

在做之前，我们先捋一捋如今的情况。我们的用例是有一个唯一的id的，但由于历史原因，当初设计的时候在用例的url加上了用例目录id（这个是借鉴的yapi）。

之所以人家这么做，是为了能在url里面直接快速找到对应的目录，并且他们的目录需要支持url访问。但我们如今是不能做到这个效果的，举个例子:

不管我们如何切换左侧的目录，url都不会变化，但yapi是支持的，它切换目录的时候，对应的url也会发生变化。

我们再来看看我们的用例的url:

目前是根据目录id/用例id来确定数据的，但由于我们测试报告里头只存储了用例id，并没有存储目录id，所以导致我们暂时无法跳转到具体的用例页面:

这就很尴尬了，思考了一段时间以后，我本来打算去掉url里面的目录id，但我又发现，新增测试用例时，它归属于哪个目录，我是记录在url里面的，所以这就很尴尬了。那就暂时不去吧，我们换个思路，获取测试报告数据的时候，我们把用例目录一并查出来。

修改报告查询方法，注意，这里使用了join查询，将TestCase的directory_id也查了出来，由于sqlalchemy的join结果是分开的，不是在一个model对象里面，我们来看看.all()返回了什么。

可以看出的是，它是一个元祖，也就是这样的数据:

[(PityTestResult, directory_id)]
复制代码

所以我们才需要把它遍历并拆开，但是由于TestResult里面又没有directory_id字段，那该咋整呢？所以我们还需要修改下这个model:

我们在PityTestResult对象里面多加一个directory_id字段，只要不是Column类型的，对数据库就不会有影响，也就是说数据库不会映射这个字段。

最后我们把查出来的directory_id重新赋予这个对象即可。

来看看结果:

可以看到里面已经有directory_id了，说明查询成了，接着我们就去修改前端代码。

看看效果:

今天的内容比较简短，主要是因为博主最近核酸抽了不少，下次补多一点。也希望大家多多参与pity的讨论之中呀~