根据我们上一节最后的投票。 引入unittest框架 碾压了第一种。其实我个人也偏向这个。因为我尝试过很多，但是唯独没有引入unittest在接口测试平台中。所以借此机会，也想挑战一下，涨点经验。

请注意：目前博主是完全完全没这个设计和实现过的状态，和正在看此文章的你一样，让我们感受最原始的设计思路。

首先我们打开views.py，找到我们写了个开头的这个实际请求的函数：

既然要引入unittest，那我们这块可能要想到，这么一个测试类，是否应该放在其他文件呢？ 我觉得可以试一试一会。

这里我们从数据库中先拿到所有步骤，然后这些步骤我们利用循环，让其自动生成这个测试类的 子函数。然后运行这个unittest测试类即可。

这个过程如果不经过讲解，很难看明白来龙去脉。

我们先新建一个其他文件，作为unittest的主要运行文件。而当前的这个views.py 就会履行它真正的作为视图逻辑的交互责任，就是整理过滤前端请求数据，传递给业务层。

我们在贴着views.py的位置 创建一个新的文件叫: run_case.py：

好了我们继续，用过unittest的人都知道我下面的写法吧：

非常简单的一个unittest demo。

我们现在就是要想办法，调用这个文件，启动这个unittest

我们现在来想个问题，就是我要怎么调用，并且，还能带着参数-一群步骤

那么现在看这个写法，应该没法带参数，甚至没法调用。因为我们要引入httptestrunner，所以我们正好可以利用起来，具体操作如下：

首先下载并导入这个HTMLTestRunner 文件。

然后代码如下：

这时候我们运行这个run的话，就会执行这个用例，并且生成xxx.html测试报告。

不过我们不在这里运行，而是选择去views.py中调用这个run()函数来运行。

所以这个views.py写法如下：

然后我们重启服务 刷新页面，点击运行按钮 看看效果：

可以看到 成功运行了，并且生成了测试报告：

只是这个报告目前 位置我们还没有设计好，所以默认生成在这了。

右键这个html，选择open in broswer，选择你的浏览器 看看效果：

大家请忽略报告中的一些文案～ 后续我会放上纯净版的这个HTMLTestRunner.py文件。

然后就是我们本节的结尾，就是给这个报告放在指定位置：

在templates包下新建一个名为Reports的包，用来存放我们的测试报告：

然后别忘了删除我们刚刚调试生成的那个报告，记得及时清理这些垃圾。

然后在我们的run函数中，改写这个filename：

然后我们重启服务 再试一次：

发现这次报告生成在了 应该出现的位置。

最后我们顺便再做一下这个查看报告的功能吧，早做出来也早方便我们调试。

打开P_cases.html，找到这个查看报告按钮,给它外面套一层a标签。超链接按图中所写：

然后我们去写好对应的urls.py：

最后去写好对应的views.py中的函数：

我们这时候要思考一个问题，我们怎么来让这些生成的报告文件 能与 用例关联起来而不至于错乱呢？

最简单的办法，我们的html文件就干脆用大用例id来命名即可。所以我们代码如下：

如上图，我直接返回了这个html。

现在我们需要的就是让我们unittest自动生成的这些报告都以大用例的id来命名吧，这也就说了回来，我们一开始要对unittest的run函数传递数据，除了各种小步骤之外，还要传递大数据的id name等。以便生成清晰的报告。

所以这么改 Run_Case函数：

然后去unittest的文件的run函数接收好这俩个参数：

然后再想办法 拼接到生成的报告文件的名称中：

好，我们重启服务，刷新页面再测试：

测试结果显示，这个大用例id为1的 报告生成成功了！

然后我们再点击 页面上的查看报告按钮，看看能否展示：

发现也可以正常展示了！

好了本节内容到此为止。

附上这个文件：

链接: https://pan.baidu.com/s/1culicHiLfXf29O5sAndrMg  密码: 地址有误，请在下节中获取正确的

大家不要忘记分享，点赞，在看 这些啊～