BVT系统建设
背景介绍
概念引入
在微服务架构的前提下，服务数量众多，相互之间接口依赖关系错综复杂。在敏捷迭代的情况下，各个发布频繁；尤其是中台服务的变更影响范围非常大。
对于Tob公司来说，有很多SKA这种大客户，需要保障这些用户使用到的核心功能的稳定。而各个前台业务线功能的稳定性不仅仅依赖自身服务的稳定性，而且需要全链路的稳定。每个版本的发布，都需要对应的所有测试场景验证通过。
这样，BVT的概念就比较清晰了：版本验证测试(Build Verification Test)，是为了确保版本上线前整体功能的正确性。
思路拆解
举个例子：当前对于定制大客户来说建模、工具设计、生产下单完整的链路构成一个使用版本，这其中除了定制功能之外，云图、商家后台、权限中台、方案中台等都会影响用户操作过程的稳定性。为了保障整个版本的稳定性，将链路进行分层，并集成整个链路的自动化回归能力。
具体来说：
优先运行底层基础设施的自动化方案，确保整体框架的稳定性
运行中台业务自动化方案，确保中台提供能力的正确性
最后运行前台业务进行整体的链路调用验证。前台业务分为自身业务和协作业务：对于定制来说，自身业务即为定制提供的业务能力；协作业务即为前台相关业务方，如云图、BIM、国际化等承载定制业务方，在使用定制业务能力前的必经之路。
从链路自动化能力集成的实施上来看：对于基础设施、中台业务来说，集成自有的自动化方案、接口测试方案；对于前台业务除接口测试外，UI自动化等其他回归能力也是考虑集成的范畴。
BVT除去前台业务版本发布前系统性回归之外，可以有的额外收益有：底层基础设施变更、中台业务变更等，调用前台业务方的BVT能力验证对整体业务的影响。
实现方案
场景映射
对于前台业务来说，可以分场景整理业务关键点，从场景出发梳理从上游到下游全部链路应用相关接口，最后以场景为维度聚合形成版本验证测试集。
在梳理过程中，不同场景存在同时调用同一应用的情况。因此，在梳理完成后，对于某个应用关联的场景进行反向映射，这时有几个好处：
当底层应用自动化构建失败时，能及时判断影响的业务场景
对于不同的场景涉及的同一应用，只需要进行一次全量的自动化运行，节省运行时间
调用链梳理
场景梳理完成后，根据各场景梳理顶层调用接口。
可通过相应的hunter调用链查询顶层接口向下的依赖应用和依赖接口。
同时，在梳理过程中需要注意的点有：
确保场景涉及的接口测试在各个应用的自动化中均存在，如果没有需要补充（包含其他团队）
可只对强依赖的应用和接口进行梳理
可以借助精准测试平台的能力拿到接口间的依赖关系。
产品形态
核心能力
通过录入场景及场景关联的顶层接口，解析接口调用链路，分析链路中涉及接口的自动化运行情况
每天定时更新链路涉及接口自动化覆盖情况
每周一、周四0点触发链路上各系统的自动化运行（release分支、sit环境）
每6个小时收集最新运行结果
tips：什么是顶层接口？前端web页面直接请求的后端接口定义为顶层接口。通过顶层接口调用情况，可以判断业务层面的强弱依赖（如：前端调用某个接口失败，但页面依然能展示，业务核心流程不受影响）
BVT平台操作
场景管理
说明：提供场景录入、调用链分析、场景分析功能
1.场景录入：场景名称、归属敏捷组、优先级、场景包含的顶层接口、UI自动化场景
2.顶层接口涉及调用链路的自动化覆盖查询（推进链路上未覆盖自动化的接口进行自动化）
3.依赖链路强弱依赖设置：对于查询到的依赖链路，可以设置相关接口的强弱依赖标记。对于弱依赖接口，BVT运行时将忽略自动化结果校验
4.查询整个场景未覆盖的接口测试，推进整个场景自动化完善程度；场景评分的详细介绍如下：
顶层api，总分80
每个api覆盖和运行是否成功得分为4:1
依赖api，总分20
强依赖api分数占比80%
如果只有UI自动化也是100分
简单解释：如果顶层api全部覆盖并且全部运行成功则可得80分，所有80分是一个比较明显的阈值
5.场景分析可以统计本业务线的全局数据
通知设置
说明：对于BVT运行的结果进行通知人员设置：
场景运行有失败：通知敏捷组测试owner（kaptain上设置后，更新即可）
接口运行失败：通知应用owner（从cmdb拉test权限用户，准确的用户需要手动确定）
运行设置
支持接口测试和UI自动化配置，可以自助设置定时任务
按照stage和域名来区分接口测试运行环境，一套环境包含本业务线场景涉及到的所有服务
按照repo和分支来区分UI自动化环境
测试报告
说明：对BVT中涉及的接口自动化运行结果进行展示。
1.BVT报告解读：最新的BVT版本、当前版本运行结果影响的场景数目、当前失败的API数目、当前失败的UI自动化数目
2.BVT报告解读：从场景的角度看，哪些场景出现了异常
3.BVT报告解读：从接口的角度看，失败了哪些接口、影响了哪些场景
4.BVT报告解读：异常应用汇总。未接入持续集成：接口测试未接入或应用无接口测试自动化覆盖；触发CI失败：当前bvt会采样前一天的CI结果，若失败需要owner排查。
5.支持持续集成结果修复后，重新拉取，更新当日报告
6.可以查看接口、UI自动化运行详情，并支持手动触发和拉取最新运行结果
BVT通知
1. 如果一个敏捷组下的场景受到影响，会发送通知给敏捷组owner，敏捷组owner需要确认场景受影响情况
2. 如果应用持续集成失败，会发送通知给应用owner，应用owner需要确认持续集成失败原因，并判断是否需要立即修复
3. 每周五汇总当周未响应同学，上报给各自的mgr，汇总给总监。
服务管理
只统计被bvt场景依赖的接口中未覆盖或者自动化运行失败的，默认按照影响场景最多的顺序排列
如果接口新覆盖了或者失败已修复，点接口测试既可以触发运行
看板建设
场景维度
首先关注是场景数量，要与各业务线故障等级梳理出来的场景一致
需要通过场景自动化得分情况来衡量每个场景的自动化得分，对于顶层接口都没有覆盖完全的场景需要推动owner完善
接口维度
接口覆盖比例和数量，以及每个服务未覆盖的接口数是需要关注的数据，对于较多接口未覆盖的服务需要着重推动
版本运行情况
关心每个版本服务失败api数，各个业务线失败的场景数，以及CI触发异常的情况
总结展望
在BVT平台上沉淀下每个业务线的所有场景，随着业务的迭代也逐步完善；所有的场景又有UI、接口等关联关系。那么就可以跟线上巡检、监控等体系打通，当某个接口出现异常时，可以跟场景关联上，从用户的角度去看是否真的有问题。
在卡点方面也要做的更加严格：一个底层服务的变更，需要触发被影响到的上层业务的CI，当整个链路的场景都验证通过，才可以进行prod环境的发布。
总之在发布前BVT的运行结果将是发布卡点的重要依据；而在发布后告警、巡检等也将更加场景化，不仅仅是告知xx接口失败率超过百分之多少，而是告诉对应的owner，xx场景异常；这样可以立即进行验证、定位以及恢复。
推荐阅读
公众号：酷家乐技术质量 知乎：酷家乐技术质量
TesterHome：kujiale-qa (酷家乐质量效能)