好的 我们接着上节课遗留的问题 进行解答：
1. 如何清理
2. 如何设置和规定 这个同项目不允许重叠执行的高幂等性
3. 目前项目A尚未运行完，项目B开始运行，就会把login_res这个变量给重新赋值，导致项目A后续的步骤发觉login_res已经不是自己的项目id后，就会重新生成新的，然后项目B的后续步骤再次赋值，发生俩个项目甚至多个项目互相抢这个变量的情况。
4. 所谓的时间戳变量还真的有用么？
解决方案：
1. 设置一个登陆态存放的列表，删掉自己用例id的登陆态就可以
2.设置一个字段，放在数据库的用例表中，执行开始时候修改为1，执行结束或报错收尾都修改为0，重叠执行的时候先判断 是否为0，如果不为0 则返回说该用例正在运行中，请稍后再启动！
3. 不再用一个字典作为登陆态login_res的内容，而是改造成一个列表，所有的大用例的登陆态都在里面存放，靠着用例id区分，互相不再影响。删除自己的也好删除。使用的时候 就直接去这个列表中搜索，搜不到就创建新的。
4. 时间戳变量无用了，可以删除相关设计代码。
好，这里我们的设计方案已经出炉了，接下来就是落实过程。
# 登陆态代码： api_login = step.api_login # 获取登陆开关 if api_login == 'yes': # 需要判断 Case_id = DB_step.objects.filter(id=step.id)[0].Case_id #先求出当前执行step所属的case_id global login_res_list #新建一个登陆态列表 try: eval('login_res_list') except: login_res_list = [] #判断是否存在，若不存在，则创建空的，一般只有平台重启后才会触发一次 # 去login_res_list中查找是否已经存在 for i in login_res_list: if i['Case_id'] == Case_id: #说明找到了.直接用。 login_res = i break else: #说明没找到，要创建 from MyApp.views import project_login_send_for_other login_res = project_login_send_for_other(project_id) login_res['Case_id'] = Case_id # 给它加入 大用例id 标记 login_res_list.append(login_res) # 运行到这的时候，可以肯定已经有了这个login res了 print(login_res)
这里改成如上的代码，其实就是完成了这个区分。
为了测试，我给这个大用例多增加了个步骤接口，现在它有俩个需要加登陆态的接口了。运行结果如下：
可以明显的看到 是ok的。
接下来我们要做的事是，在这个大用例执行结束后，从列表中删除掉它的专属login_res。那么如何判断当前这个step是最后一个步骤呢？ 这里我仍然有俩个思路：
- 在首次执行的时删除掉之前旧的login_res，或者在最后一次执行完删除。当然最好放在setupClass 或 teardownClass内，但是这里需要知道当前的大用例id，想办法传给set..或tear.... ，建议使用类变量 而 非global的方式，原因大家都知道，不然又容易引起新的干扰bug出现了。
- 另一个安全的办法是在这个step生成的demo函数生成的时候，给一个标记信号，来告诉demo函数，这个是大用例的最后一个step了，执行完 记得删除大用例的login_res。
根据方法论指导，我选择第一种方式开始试验：
那么具体是在一开始初始化清空还是 结尾删除呢，我倾向于一开始。这样防止如果前一个用例执行到一半报错等，没有正常结束，导致没运行到teardownClass的问题。
代码如下，首先我们要去修改run_cases.py最下面的函数，让它们把Case_id给带进去：
然后去写setupClass函数：
注意不要抄错，也不要忘记装饰符
可以看到，成功带了进来。然后去写 检查login_res_list并删除自己用例id的字典的代码：
代码：
@classmethod def setUpClass(cls): #print('收尾功能') try: for i in login_res_list: if i['Case_id'] == cls.Case_id: #print('进行删除中～') login_res_list.remove(i) break except: pass
让我们重启服务，进行最后的全面测试吧！
先执行项目A:
同一个用例内 一切正常。第一条接口去创建，第二个接口去直接用。
然后再次执行项目A （注意，不要重启服务）
如上图，仍然是第一个接口创建，第二个接口直接用。完全没毛病。
最后我们再去执行项目B：
可以看到 项目B 没有被干扰，并且成功的自己去创建login_res了。
到这里，这个bug完全结束。不过因为我们设计过 那个高幂等性，也就是防止用例运行完之前，用户刷新页面再次启动。
这个问题我们之后会单独拿一段时间去优化，因为存在这种需要提高高幂等性的优化场景 并不仅仅这里。到时候我们一起集中解决比较好。
