上节课我们写到了 header的完全处理结束。
本节课继续开始。
1. 拼接完整url
为什么要拼接？因为咱平台设计的是由host和路由两部分组成，所以要拼接后才能给requests方法调用。 两部分均由用户输入，一旦涉及到用户输入，我们就要考虑到用户按照规则和不按照规则的情况，比如Host结尾写了/ 结果路由开头又写了个/ 这样直接简单的拼接起来，就会导致/重复，变成：
https://www.xxxxx.xxx//aaa/bbb/ccc
所以我们要避免这情况，这里就要进行判断后拼接。
ps: 这就是做成平台要额外考虑的事情，比之前我们写个自动化脚本要难一点。
如图，我们的三种判断后，最终的url就是完整且正确的url。
至此，我们的url经过全局变量替换，经过公共域名替换，经过拼接后最终实现完全体。
2. 登录态融合
还记得我们的登录态设计么？通俗点就是在这个步骤运行前是否要先运行登录态接口来获取token等参数并加入到本步骤接口的请求头/体中的设计。
虽然很先进，但是实现起来并不简单。
第一步，从step中拿出登录态开关。
第二步，根据开关进行判断，若为no，则设置一个空的login_res字典，若为yes，则按步骤继续写：
现在，我们要考虑这个else，也就是需要调用登录态接口：
首先，要找拿到这个用例的case_id，为什么呢？因为我们要靠这个用例id来判断这一条大用例，里面的众多步骤接口，是否已经有接口调用了登录态接口了，如果已经调用过，我们这里直接用即可，没必要再次调用。如果没有调用过，我们再进行首次调用。
这个逻辑我们在之前的run_case.py中已经使用过，这里我们再次写出来：
（不要着急写，后面有源码复制版本）
其中的具体步骤我都用注释写了。
然后我们肯定拿到了这个login_res字典，它存放着所有登录态要写入给当前步骤的字段和对应的值。
可能是空的，也可能有东西。有的东西是之前用过直接拿的，有的则是重新生成的。
我们接下来就是直接插入到本步骤的各个位置即可。因为我们不确定这个登录态到底应该插入到什么位置，让用户自己决定又很麻烦。本着参数宁可多传也不要少传的原则，我们干脆一劳永逸，全都加。
先加url和header：
url后接函数必须用?开头，所以我们要先判断一下是否已经存在?
好了，其实这里应该再加到请求体中的，但是请求体又分为很多格式，这个写起来就更麻烦了，而且大多数我所知的登录态，都是放到url或者header即可，若小伙伴公司的接口必须要放在请求体中，那么可以私信我(qingwanjianhua)，我再继续加上这部分代码。
到这里，我们的登录态加入功能就告一段落。
接下来是加密策略：
Ps：有的小伙伴都听累了，心说为什么要这么麻烦再讲一遍，代码95%都是直接复制run_Case.py的吧。
这里解释下，是的，代码大多直接复制粘贴即可。但是这里为了再一次带大家复习这个复杂的环节，所以作者仍然选择再写一遍。
加密策略：
先判断加密开关是否是yes,若是，则把我们的url,请求体等参数传给我们之前写好的加密函数。即可，代码量并不多。
好了，本节课暂时到这里结束，希望大家年前最后一周好好努力工作哦~
