断断续续折腾了好久的带有web端管理平台的接口自动化框架终于有了雏形，也终于可以开始动笔整理整个过程中所涉及到的设计思路以及所需要用到的技术栈。

其中依然有许多待完善内容，但时间不容许再继续拖下去了。故此形成此文，目的主要是和大家揭秘在开发一个测试相关的平台过程中的一些情节故事。

行为背景

在工作的前三年中写的代码基本是在已有的框架基础上编写用例代码，写作过程中只能知其然而不知其所然，因此在后续的工作中想要找机会可以开发自己的接口自动化框架，同时锻炼自己的二次开发能力。因为中间件的工作机会使得习惯了用写代码来解决问题，所以在接手车载业务之后，为了搭建接口自动化用例 有了这么一个从零到1使用python进行接口自动化框架开发的机会，同时因为组内有4个成员一起用这个框架编写代码，且在日常工作不断的使用，也因此有了不断完善框架的机会。

而当初进行接口自动化框架设计的初衷主要有以下几点：

1. 历史接口文档的缺乏和不完善会造成书写接口自动化带来一定的困难，同时对端上的自动化来说通常最快捷的方式就是通过app端抓包的方式来进行 请求参数的获取；在将app抓包的数据转换为自动化用例过程中存在大量重复的手工操作，希望有工具和框架可以支持我们快速的生成一批接口自动化case。（期初这个原因占据了框架开发大部分的动力）
2. 组内需要统一的自动化描述语言，同时接口自动化的工作需要例行化运维 需要有平台以及框架层面的工具可以帮助我们进行case管理以及运维。有大量重复的建设工作可以在框架层面上进行避免
3. 同时如果大家有做过自动化的工作，那么势必知道自动化建设过程中存在大量重复的代码书写，这些都是可以通过工具与框架层面帮助我们进行快速简化的

综上，设计或者形成组内统一的的接口自动化平台是非常有必要的。那么在方案的选择上，首先b站内部没有基于python的统一的接口自动化框架，统一的平台又非常的难用（这个平台的诞生也落后于本框架的开发设计时间），即使选用外部平台还是少不了要有很多适配的工作，纯自研的角度来说花费的代价也不会非常大（因为如果你会写代码其实用不了多少代码量的）。同时也为了进一步锻炼自己的编码能力，因此也选择了自研代码的方式。一旦有了自研的经历，后续无论是选择基于开源框架来做相对来说都会简单很多。

开发历程

整个框架的开发主要经历了：

1. 22年5月份开始书写车载端的自动化，因此写了初步的demo；这个demo主要基于配置化的yaml文件来生成接口api和用例定义；同时写了解析抓包文件并快速生成的py脚本
2. 22年7月份，随着校招生入职车载团队扩展至4人的team，组内指定了编写接口自动化用例的工作目标，因此给大家讲解了框架设计思路，并开始利用这个简单的框架来大批量编写用例
3. 随后就是按需进行框架的完善
1. 22年9月
1. 增加测试数据区分pre、prod、uat环境；实现同一套代码适配多个环境
2. response中增加格式化输出方法，便于日志打印
3. 实现CaseGen装饰器，简化yaml文件读取过程以及case定义过程
4. 实现host配置可由单个yaml文件配置
5. Step中增加waittime参数 可控制每一步运行时间
2. 22年12月
1. 增加ApiGen装饰器 简化api生成过程
3. 23年4月
1. 修改CaseGen装饰器，增加参数可以获得case.yaml文件中指定case
2. 运行过程中可以打印错误日志
4. 23年5月
1. 升级底层http实现为httpx以适配http2.0的请求，支持不同http版本的调用
5. 23年6月
1. 增加历史response的保存并且实现pre和prod环境的diff流程
6. 23年10月
1. 增加case串行化配置：支持step提取上一个请求的respone数据；支持step中动态生成数据，如随机字符串，时间戳等；设计afterStep，支持新增step用于数据的检验【这个也可以通过数据库组件查询，但是也提供此类方法】

纵观框架的整个开发历程，能够得以发展的关键是【按需开发】，并在过程中不断的去进一步的优化，服务于真实工作的需要。同时过程中也解决了一个一个看似不能完成的事情，比如之前头疼过如何在自动化运行失败后能把respone中的header的trace打印出来 并打印相应的response；比如diff流程的建设。

当然目前来看从一个成熟框架的角度来看，这个工具依然有许多值得改善的地方，但是这个项目本身的定位除了做框架外，更多的是希望组内的大家能够参与共建；从而锻炼适应编码的过程。因此该框架会保留目前半成品的状态。大家也可以依托该半成熟的框架在自己的工作中使用，然后不断的添砖加瓦。

项目收益

目前基于此框架已完成车载业务的自动化用例积累约361例；并且该框架也在多屏测试组内有了初步的接入尝试，构建了约共计244例用例。同时，这些用例同步在pre和prod环境都有所运行。运行至今，发现的问题有：

（PROD环境）

1. 【已解决】搜索接口频繁报code=-500 服务器错误->调整搜索超时调用500ms-》700ms；当前调用搜索服务为http方式，待优化为grpc调用，减少请求中转过程；
2. 【已解决】我的收藏列表接口2周内频繁返回服务调用超时-》收藏服务redis底层超时，redis集群迁移至服务同集群（常熟）问题解决
3. 【已解决】关注的up中动态列表接口经常性返回错误-》待迁移来的动态服务到新go服务上，已迁移上线
4. 【已解决】合集列表接口第二页数据加载失败-》反馈是”并发查询时，如果没有命中缓存会先加分布式锁，再从db加载数据到缓存；如果分布式锁没加成功，就抛错了。可能过度设计，后续优化“
5. 【跟进中】视频列表接口翻页加载经常失败，以咨询tab、生活tab为代表，线上也有很多类似的warn日志-》待跟进解决
6. 【跟进中】fm精选推荐列表数据第二页加载失败-》待观察跟进
7. 【跟进中】评论请求超时-》待观察跟进
8. 【跟进中】ogv详情页接口查询超时》待观察跟进
9. 【已解决】首页fm精选推荐只能刷2页数据，第三页之后返回为空，持续一周时间。原因：算法侧上线变更。解决方案：加上兜底逻辑。已上线
10. 【已解决】小鹏渠道不展示杜比金刚位 已修复
11. 【已解决】web端无法收藏视频-》收藏上线接入风控，web端和app端传入的参数不一致，客户端用aid，web端用oid，web端取错参数-》服务端修复上线
12. 【已解决】游戏tab列表访问第一页报错=》原因算法接口uint64转int溢出-》已上线
13. 【跟进中】大搜上线语义推荐，原始命中空返回结果。-》周末恢复了不知道是什么问题
14. 【待优化】中国移动媒咨接口查询pgc数据会命中空缓存。-》需代码层面优化异常场景查询策略
15. 【待优化】频道第一张数据处于删除状态会导致整个金刚位不露出-》排期优化

pre环境问题

1. 【已解决】预发环境点赞接口-500报错；-》预发接口超时时间配置过短，需要配置3s
2. 【已解决】空间页直播卡不展示test_cases.test_space.test_live (from pytest)-》预发新功能影响，修复相应代码
3. 【已解决】稍后再看接口返回code -500 服务器错误-》服务发布后asko数据库代理没起来
4. 【已解决】视频列表页返回code -500 服务器错误-》/pgc.service.media.v1.Index/IndexSearch 依赖服务500
5. 【已解决】搜索不到ogv视频-》已修复，主站搜索服务异常
6. 【已解决】收藏夹视频列表获取失败-》预发中有脏数据，修复对应数据
7. 【已解决】预发直播接口不可用-》直播流接口升级导致，修复bug
8. 【已解决】pre和线上搜索接口合个人空间页接口出现异常数据【车载2.5】搜索结果页和个人空间页出现展示为ugc横卡的ogv卡-》需要跟随上游升级接口
9. 【已解决】pre和线上/x/v2/car/search接口搜不到ogv卡-》修复代码
10. 【已解决】pre环境下/x/v2/car/view接口不下发历史记录；-》之前有一个后端控制历史下发的逻辑，之后确定是前端做了，后端就把逻辑去掉了，结果是配置为0的逻辑变成不返回了。新代码没有去除干净导致。已修复（2.5代码变更引发bug）

项目运行至今自动化运行过程中均能够发现有效问题，问题都需要做相应的修复。其实这不是第一次自动化发挥重要作用的业务，之前在微服务的时候自动化也帮助我们发现了关键的错误，只是当时的case编写并没有所谓的框架的概念，只是有一套代码编写的自动化流程。

在此，也将之前微服务自动化发现的关键问题做一下总结：

1. 【已解决】Paladin自动化case运行过程中发现case运行时长由一般的3min持续到了7min，因此对其中运行过长的case进行了排查-》开发新版本过程中修改了相关的代码，导致出现了一个判空未处理，造成用例运行时间过长
2. 【已解决】Discovery进行多实例set状态为2时case失败-》优化discovey的性能时，采用延迟拷贝预存数组进行了代码修改，修改后导致set 状态为2情景下，poll返回数据有误
3. 【已解决】Discovery存在多节点无法互通的情况-》临时解决方案：需要手动重启未同步的node的节点。优化方案：git地址，该方案补充了node节点对齐逻辑定期检查
4. 【已解决】Discovery admin服务查询注册接点提示-500 错误-》实际根因排查：服务树返回的tag类型字