老旧服务的接口保障
一、背景
在数字经济背景下，产品会依据市场需求不停更新迭代，新产品会不断淘汰老产品。在新老产品更替的过渡时期，老服务将会进入维护状态，研发的投入会急剧减少，服务的维护人员也会发生较大变动。因此，对于基础设施升级或者服务合并的情况，旧服务的测试工作就会变得相当棘手。总结有以下2个痛点：
服务中存在很多的废弃代码和接口，服务处于亚健康状态。
旧服务的接口自动化难以维护和覆盖全面。
基于以上的2个痛点，需要有工具可以自动评估服务的接口优先级。通过该工具，测试人员可以抓住服务的重点接口，保障老旧服务的质量。
二、现状分析
我司目前有一套比较完善的监控系统，可以拉取接口流量以及接口的详细数据。但由于日志的时限性，监控系统最多保留7天数据。而我们的诉求是想知道更长时间内的接口访问情况，时间越长，越能对接口的重要性有准确的评估，从而辅助判断接口的优先级。针对该现状，我们需要做一次新的开发。
三、实现
3.1、基本框架的设计
基于背景的思考，希望有个平台拥有以下3点功能：
沉淀每日API请求数据。根据请求频率和请求次数来决定接口的优先级。
做成可接入式，方便公司内其他组的接入。
一键式接入，节省使用方的时间。
3.2、思路拆解
对应平台的功能，主要可以拆解成3个模块。分别是服务接入、巡检模块和前台展示。如下图，服务接入主要做的是初始化操作，即从网关读取服务的所有接口进行入库操作。巡检模块是对服务的每日数据进行整理与入库，前台展示将在后续第4章进行详细描述。
3.2.1 服务接入
由图可知，服务接入是由用户手动录入服务。
但由于该平台与其他平台不同，在刚接入的时候，平台对用户的价值很小，随着时间的积累，平台会进行巡检，有价值的接口才会慢慢的展现出来。从服务接入，到平台起效果，最少需要进行2周的数据沉淀。为了趁早积累数据，开发者对公司核心服务做了批量的接入。后续其他服务如果需要，可以自行在平台上添加。
3.2.1 巡检模块
巡检模块又分为初始化巡检和每日巡检两个部分。如下图，初始化巡检发生在服务首次接入的时候，系统会从网关处读取该服务所有注册的接口进行初始化入库。
每日巡检的工作内容主要是对接已有的监控系统，拉取该服务昨日所有有访问量的接口进行更新入库。将拉取频率定为每日，是为了看出API在每天的调用情况。若拉取频率为每周，API的最后一次访问时间将会变得不准确。
这里有一个“坑”需要注意：由于初始化操作只会进行一次，但随着时间的增加，服务的接口会慢慢增多。如果每天都从网关全量同步一次，则太费资源。我们改成在每日巡检的时候，如果获取到了新的接口，则由原来的更新操作改成插入操作，代码如下图。这样就能从最小的成本上保证服务所有的接口都被覆盖。
四、平台简介
4.1 、页面展示
前台页面展示主要分为两部分，操作区和展示区。
操作区进行服务、接口的查询，项目的新增与删除；
展示区主要进行查询结果的展示，显示每条数据的api、method、最近调用日(或初始化日)、最近调用日调用次数、是否已下线、操作(支持标记上下线)。
4.2、 平台功能
前台包括了增删改查在内的一系列功能。
增：指新增项目。
选择服务对应的cmdbTag，点击确定后进行服务初始化，初始化会将此服务正式环境、预发环境下的接口写入数据库。
删：指删除项目，同样也是通过cmdbTag，将已添加服务从该平台中删除。
查：指服务、接口查询功能。
可以通过服务查询来搜索相应服务，也可以输入api进行搜索。
查询结果列表会显示每条数据的api、method、最近调用日(或初始化日)、最近调用日调用次数、是否已下线、操作(支持标记上下线)。
查询结果有两点需要注意:
接口使用情况巡检为T+1逻辑，首次添加后建议第二天再查看使用情况。
若【最近调用日调用次数】为空，则显示日期为初始化日，且此接口自初始化以来无调用量；若【最近调用日调用次数】不为空，则显示日期为最近调用日。
例：下图中，某接口【最近调用日调用次数】为空，则2022-09-01为初始化日，且自2022-09-01接入以来，此接口无调用量。
改：主要指接口的标记上下线功能。
如果某接口已经下线，可在该平台将其标记为下线。需要注意的是，此功能仅作标记，实际上下线需开发修改代码。
五、经典案例
5.1、评估接口底层改动的影响面
【背景】：底层服务A进行了接口改动，上层调用的接口都要更新接口入参。
【难点】：上层服务B是个非常老旧的服务，一直处于维护状态。虽然新研发给出了API范围，但是API的业务场景都无从追溯。
【解决方案】：
本case有一个特点：改动小影响大。
所以对受影响接口的把控就成为了重点，可以罗列出受影响API的调用频率以及调用数量，方便划分测试重点。长时间无调用API就以线上观察代替手工测试，从而大大提升测试效率。
同理当发生接口迁移的时候，也可以使用同样的方法来提升测试效能。长时间不调用的方法也可以趁机推动下线。
【结果】：项目平稳上线，线上无bug。
测试过程如图
5.2、接口自动化覆盖率的提升
【背景】：服务B属于业务核心，但近3个月无新增代码。目前服务的接口覆盖率较低，想对服务的接口做一次“摸底”操作。
【难点】：接口优先级一无所知，如果一个个进行接口补充，投入产出比较低。
【解决方案】：将接口的访问量和访问频率作为指标，先对核心接口进行用例补充。对无调用的接口类，进行覆盖率的排除。
【结果】：服务接口总数139个，无调用接口55个，占比39%。新覆盖“高优先”接口67个，已覆盖接口/有调用量接口=79%。服务接口自动化基本完成。
覆盖过程如下图
六、总结
通过平台积累的数据，测试人员可快速掌握服务中那些被高频调用的接口，做好老旧服务的接口保障。若接口长时间不再调用，则可以推动进行服务的合并和下线，以节省服务资源。
平台方面也有很多可以优化的地方，比如初始化直接同步近7天的接口数据，下线接口自动标记，以及前端数据图表化等。
推荐阅读