本节开始前我们处理一个小bug：
就是上图这样的排版问题。
这是因为我们右侧的div的高度是固定的，所以导致五个多行文本框超出了。我们现在来修改一下右边这个div 的高度，打开P_cases.html:
把这个高度100% 改成最小高度100% ，min-height：
看看效果：
然后我们再在这个最后一个多行文本框后 加4个
来换行 撑一下：
看看效果：
现在看起来好多了。
好了，今天的内容到此结束，欢迎继续关注。
开玩笑的～
让我们看一下多用例模块目前剩余功能：
4.步骤详情页的提取返回值功能
5.步骤详情页的断言返回值功能
9.用例实际执行的后台实现
10.报告的生成和保存
11.报告的展示
12.报告的word导出
13.步骤的mock功能
关于提取返回值和 断言返回值 我们的前端已经写完。具体的后台实现，得等到用例实际执行的代码写完后再加入了。
所以本节我们先去写好 这个执行函数吧。
在P_cases.html中找到每条大用例的 运行按钮,给他写好onclick属性。
然后去下面找个风水宝地，写好这个函数：
在这个函数中，我们对后台发出了 指令，让其开始运行这条大用例。
然后我们再 写俩句能让人看出正在运行的代码，就是反馈效果。比如点击运行按钮，运行按钮就变成：正在运行，运行结束后再变成：运行
为了精准的控制这个运行按钮，所以我们给每个运行按钮都加了id, 区分不同的大用例，所以id中必须有变化的部分-用例id
然后我们补充Run_Case函数：
写完了这块，我们去写urls.py：
然后去写views.py：
现在我们要开始构思一下这个Run_Case函数了。它都要做什么？
它已经获取到了 要运行的大用例的id。
然后可以去 数据库中 拿到 这个大用例下的所有 小步骤，这些小步骤按执行顺序排好，然后按个执行，最终把结果生成报告即可。
这里我们有俩种设计：
-
很简单的循环执行所有小步骤的接口。然后把结果保存到数据库，等前端点击查看报告的时候，调取数据库结果组成自行设计的测试报告。
-
引入如unittest这样的单测框架，让这个大用例下的所有小步骤动态组成unittest的一个大测试类，然后依次运行，最后生成html的测试报告，前端点击查看报告就直接展示这个html的测试报告。
在这俩个设计内，我们的提取返回值 和 断言返回值 的算法会有略微不同。而从本身来说，第一种非常简单明了，自由度高。第二种正规可靠，可学到更多奇招巧术。要怎么选，欢迎投票：
好的 欢迎讨论：
