各位大佬，马上过年了，歪小王在这里给大家拜个早年。祝大家新年快乐，早日卷出一片天~ 年底偷懒了一段时间，一直没写公号。最近在写执行接口自动化脚本过程中，遇到了一个header的问题。就随手整理记录一下
问题描述
前段时间，完成了接口自动化解析swagger版本的代码修改。并在我们项目中跑了一次。由于是读取swagger接口，直接绕过了业务层，没有去从业务角度出发跑脚本，所以在结果上面，没有很强的参考性
通过简单修改，在yaml文件中，拼接上业务层的路由加上夹具获取登录态，然后走网关ip，从而实现正常的业务请求
但是在完成这些操作后，依然不能够实现正常的一个效果。经过与研发沟通，需要在header中增加用户id。来表明用户角色。才能实现正常的验证效果
于是就想着直接在yaml用例文件的header头中增加用户id。就又延伸了一个新的问题。会把基本的header信息覆盖
问题定位
经过一番断点调试后，发现request发起请求本身，会填写默认header值，这些默认值能够保证常规请求。如果在yaml文件中随意写一个header。在脚本执行时，就会讲这些默认值覆盖，从而导致请求不成功等一些问题。
所以通过写死yaml文件的方法来解决这个问题，就会有隐患：
- 写死一个变量，这个做法很low。如果换一个用户id，就每次手动调整。很麻烦
- 如上面所说，如果在header中写死一个值时，会将基本的默认参数覆盖掉，导致请求失败
解决方法
在request发起请求时，header是以一个字典的方式存在，可以通过插入用户id的方式来解决这个问题。既保证了默认值的存在。也可以将需要的用户id更新进去，达到最终的验证效果
有了目标，接下来就是实现思路
- 首先在夹具获取登录态的方法中，将用户id提取
- 然后将这个用户id更新到session的header中
在这个过程中，有个小坑，就是在request这个包实现共享session的时候，需要调用同一个封装实例
比如，接口脚本调用的是封装着request的A对象。此时，夹具中获取登录态的也需要调用这个A对象，如果重新实例了一个新的B对象，就没办法达到共享session的效果
最终通过这种解决方式，能够使接口自动化脚本达到预期的验证效果
结语
以上就是本期分享的内容了。关于接口自动化脚本方面，基于本次改动，扩展了一下验证范围，由原来的只验证接口的边界、合法性，延伸到接口权限验证，后面会更新一些验证接口权限的思路
各位大佬们，再次祝大家新年快乐。我们下期见~
