虽然上节课我们准备好了测试数据，但是本节我们要想想如何来测，从哪看结果等问题。
根据bug描述，我们每次测试完，都要重启服务，防止干扰。
用例过程：
- 运行项目B的用例，看看登陆态字段uB是否存在。
- 重启服务
- 先运行项目A的用例，看看登陆态字段uA是否存在。
- 再运行项目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这个 兜底的解决方案。
