接口测试平台代码实现141: 项目大用例干扰bug解决2

好的 我们接着上节课遗留的问题 进行解答：

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是最后一个步骤呢？ 这里我仍然有俩个思路：

1. 在首次执行的时删除掉之前旧的login_res，或者在最后一次执行完删除。当然最好放在setupClass 或 teardownClass内，但是这里需要知道当前的大用例id，想办法传给set..或tear.... ，建议使用类变量 而 非global的方式，原因大家都知道，不然又容易引起新的干扰bug出现了。
   
2. 另一个安全的办法是在这个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完全结束。不过因为我们设计过 那个高幂等性，也就是防止用例运行完之前，用户刷新页面再次启动。

这个问题我们之后会单独拿一段时间去优化，因为存在这种需要提高高幂等性的优化场景 并不仅仅这里。到时候我们一起集中解决比较好。