开始本节主要内容：
还是打开我们昨天研发到一半的views.py和run函数：
如图：
我们虽然成功的传入了 Case_id,Case_name，但是这都不是主要的，主要的内容是所有步骤。所以我们这里加上各种步骤：
然后去 run_case.py中去写run函数：
让我们输出一下，看看能不能正常传递过来：
看来是正常传递过来了。
紧接着就是，我们要动态生成测试脚本函数。大家注意看下图中的红线部分，是我们一个小用例的demo 函数，这是unittest的标准写法。
而我们正式运行的时候，是要依靠这个demo的，然后根据我们传递过来的steps小步骤集合，来按照这个demo的格式循环生成真正的这些小用例函数。首先我们把这个demo改动一下，让它不要叫test开头的函数(unittest框架只会运行test开头的小用例函数，所以我们避免这个demo母体被运行，就给它改个名字)
然后，我们下面顶格 新写一个函数，叫make_def,意思就是我们要给这个Test类 创造一些小函数了,它要接收我们的steps，然后循环创造，比如有30个小step，它就要创造30个小函数：
我们在主要的run函数中 一开始就调用这个make_def函数来创造很多小用例函数。然后这个函数内是个for循环，利用python的setattr函数来给Test类创造子函数，setattr应该要传递三个值，第一个是类名，第二个是小函数的名字(小函数名我们为了避免重名，所以test开头的基础上加上了步骤的执行顺序-index来命名，而且unittest就是按照这个小用例函数名的字符串判断来确定执行顺序，所以我们为了避免 出现“12” 小于“5” 这个情况，就强行变成了"012">“005” ,这样才能保持执行顺序正确,而用法就是字符串.zfill(固定长度)。)，第三个参数就是我们要创造的函数本体，这个我们必须要再新建一个函数，这个第三个参数就是调用这个新函数，而这个新函数 会返回一个 demo函数来作为本体。
所以我们在上面再创建一个新的 创造这个函数 的函数：
而这个函数需要什么作为参数呢？需要的就是我们的多个step中的正在要创造的这个单个step本体，因为它要去实际请求这个step了。
所以这么写：
那个tool就是我们真正创造的小用例函数本身，它调用或者说复制的就是我们Test里的那个demo函数，然后返回这个tool就对了。
这里我们也可以再用setattr函数来给这个小tool函数，加上__doc__属性，这个属性就是每个def函数都可以拥有的函数描述。在unittest里就会变成这个用例函数的用例名字。
所以我们创造这个tool的时候，可以指定它的名字，名字当然是从step中拿啊：
最后还有一步，就是我们要给这个demo函数 增加这个step的接收用的型参：
接收到了这个step数据后，我们随便打印一下step的url，看看整个数据链条是否成功：
好了，我们重启服务，刷新页面，点击运行试一下，我这里已经有俩个小步骤了，这样测试就应该是俩条小用例执行：
他们的url分别是：
点击执行用例：
可以看到有俩个点，这就证明执行了俩条小步骤，每条小步骤对应一个小用例。unittest的显示中，点就代表执行成功，F代表断言失败，E代表用例报错。
然后我们点击查看报告看看效果：
看来我的设想完全成功了，动态生成测试脚本链路正常运行了。
下一节我们就在里面直接提取url等所有请求数据，进行请求，然后再对返回值进行提取和断言，那么这个模块 基本就完成了。
最后还有个小缺陷，要改一下ui，因为
点击执行后，按钮太长，导致没装下，所以我们扩展一下操作的宽度，打开P_cases.html：
改成了450px ，就好了
之前有过很多小伙伴觉得总是练习前端代码学腻了，想感受后台的复杂设计和算法，从本节开始就如偿所愿了呦～
最后欢迎持续分享 关注哦～
