接口测试平台代码实现139：不同项目大用例登陆态干扰bug测试

虽然上节课我们准备好了测试数据，但是本节我们要想想如何来测，从哪看结果等问题。

根据bug描述，我们每次测试完，都要重启服务，防止干扰。

用例过程：

1. 运行项目B的用例，看看登陆态字段uB是否存在。
2. 重启服务
3. 先运行项目A的用例，看看登陆态字段uA是否存在。
4. 再运行项目B的用例，看看登陆态字段是 uB还是uA 即可。

呢么问题来了，查看我们的un_cases.py中发现：

在输出到报告上的时候，还没有运行到登陆态的相关代码。所以测试报告这样是看不到登陆态字段的。

那么我们只能给这一大堆 输出代码 移动到下面 ，判断请求体类型之前。

并且！修改启动的一些变量！

## 输出请求数据
print('\n')
print('【url】：', url)
print('【header】：', json.dumps(header))
print('【method】：', api_method)
print('【body_method】：', api_body_method)
print('【body】：', api_body)  # 目前graphQL方法的显示上仍然未优化

现在我们开始正式测试！！！！

先重启服务，单独运行项目B的 用例：

报告如下：

可以清晰的从url和header中看到此时 的登陆态字段 uid = uB。

这里证明我们单独测试的情况是ok的，然后就是测试同学反馈的干扰bug了。

然后我们 重启服务，运行项目A用例，报告如下：

可以看到项目A用例 的登陆态字段 uid = uA 没问题。

然后我们不要重启服务！直接去执行项目B的用例，看结果：

好！问题成功复现了！ 感谢找出这么隐秘bug的同学！

接下来我们就要去解决它了，其实不光是这个问题。

按照热饭《测试开发方法论》 中所述：

这种疑难问题，我们先要想好都有什么思路：

思路1 ： 做好隔离，用 大用例id来标记这些变量，防止其他大用例使用。

思路2 : 变换当前存放变量和判断思路，从缓存中改到数据库存储。

然后思路有了，接下来按照方法论指示，就是对俩个思路 进行比对，找出优缺点，制定出顺序。

思路1 优点是代码改动少，缺点是难度较高较抽象，成功率不高。

思路2 优点是必成功，逻辑简单，缺点是代码改动大，麻烦。

所以我的选择是 先从思路1 进行下手，这种讨巧的解决办法如果行不通，再去试试思路2这个 兜底的解决方案。