上节课我们明确了解决方案，先试验思路1， 也就是想办法 隔离。
首先明白，隔离我们其实就是给它加入一个 标记，这个标记就是 大用例id。再来看看我们的登陆态目前 是个什么 数据类型：
问题处在这个eval()上，它会去检查是否存在 login_res ，如果没有 就重新用项目id去请求。
现在起我们要做的就是，这个try的内容，不但要检查是否存在，也要确保这个login_res的内容中 包含的 标记 （大用例id） 是本次运行的大用例的id。
这里面我们要考虑一个问题，就是同一个大用例，如果被多人重叠运行怎么办？如果使用者修改了登陆态的数据怎么办？如果只靠大用例id一个标记的话，那么这里系统一定会使用最初的那个旧的，所以这里为了确保唯一性，我们要加入的标记 不能仅仅是大用例id，还要有时间戳标记！
不过我们还是先输出一下这个login_res，看看它里面都有什么吧～
可以看到，这个字典就是login_res, 我们要做的其实就是在生成它的时候，给他加入 俩个标记。时间标记和大用例id
不过在此之前，我们要 移动下：
变成：
这样我们在try里 也可以使用login_res来做判断了！
然后就是生成标记的问题了：
（大家先不要抄，这段后面还要改）
我再进行了几次测试：
这是第一次运行项目A:
这是第二次运行项目A:
看来到这来说，原始逻辑没问题，然后继续测试...
这是接着运行项目B:
从上面这个结果中可以发现，不同项目 甚至不同大用例之间 的隔离问题已经得到解决。
不过在这个过程中，我们也找出来新的bug了。那就是 俩次A项目执行，第二次按理说不应该使用第一次的login_res了。所以这就回到了我在一开始时候预测到的问题，需要加个时间戳来保证唯一性。
加入时间戳：
打印结果：
可以看到，这个时间非常非常精确。那么我们接下来就要给它加入到判断里：
这里我们 进行判断，如果判断时间戳标记正确，则直接使用，否则就是触发一个异常来走exception分之，重新生成。
不过这里了问题来了，这个标记 应该和 谁去比对 才知道正确与否呢？
我们生成的时候，是不是应该 把这个时间戳标记 一式两份，一份给到login_res，另一份存到哪里，然后使用的时候 再对比来判断是不是当前的呢？这个思想是不是 很像 加密的公钥私钥 这些呢？
其实简单来说，就是这个时间戳标记，要怎么判断。才能 知道系统现在执行的这个step步骤，是当前大用例的后面的步骤，而不是重新启动 一次大用例的步骤呢？
我画了一张图，来帮助大家捋清楚思路：
如图，同一个项目，第二次执行时候 的创建时间 和第一次执行时候的创建时间，理论上 ，是没有严格的前后之分的。
而第一次的之后所有步骤，都必须判断为真，可以复用。第二次的一开始就要判断为假，主动生成新的。而且这个主动生成新的后，还不能影响第一次执行后面的，也就是说，你不能覆盖。所以 如果是当前这样的情况，我们几乎是无解的。毕竟同一个项目的同一个用例，它的数据库内容是不可以再执行中任意修改，否则会影响其他同时执行的另一次。
所以这里我们郑重决定，不再允许 同一个大用例 的重叠运行。也就是说，必须等前一次执行完 ，才可以执行下一次。
本来实际场景中，也不太可能会出现重叠运行的情况，这本身 对复杂的多接口来场景来说 就是错误的。比如 你一个账号 的大用例场景是 ：添加好友-查看好友资料-删除好友。
结果重叠运行 就变成了。第一遍 已经执行过了添加好友，正在执行查看好友资料的时候，第二遍开始执行 添加好友，结果第二遍添加好友直接报错，说好友已经添加过了！
加上接口用例执行时间本就很短，几秒几十秒。所以实际使用中，不应该出现这种重叠使用。那么我们如此规定后， 再回头看这个问题 就简单了。
只要在项目A结尾的时候，清理掉自己的登陆态 就可以了。 然后再执行项目A的时候 又会重新生成新的了。
不过这里我们依然要面对以下几个问题：
1. 如何清理
2. 如何设置和规定 这个同项目不允许重叠执行的高幂等性
3. 目前项目A尚未运行完，项目B开始运行，就会把login_res这个变量给重新赋值，导致项目A后续的步骤发觉login_res已经不是自己的项目id后，就会重新生成新的，然后项目B的后续步骤再次赋值，发生俩个项目甚至多个项目互相抢这个变量的情况。
4. 所谓的时间戳变量还真的有用么？
综上所述，所有问题，我们下一节课 再解决喽！
欢迎小伙伴继续观看，这个超复杂的解决方案问题：
