g2g有哪些网站,品牌网络授权书,如何查询自己的企业邮箱,wordpress男人福利模板一、问题来源
在云化场景下#xff0c;API的测试覆盖是一项重要评估与考察指标。除了开发者自测试外#xff08;UT#xff09;#xff0c;还可以利用云化测试平台、流水线等方法进行相关指标的检查与考核。利用这种方法既可以减轻开发者测试工作量#xff0c;不必在本地做…一、问题来源
在云化场景下API的测试覆盖是一项重要评估与考察指标。除了开发者自测试外UT还可以利用云化测试平台、流水线等方法进行相关指标的检查与考核。利用这种方法既可以减轻开发者测试工作量不必在本地做大量的、降低人为指标灰度空间又可以自动识别重要接口实现测试数字化与自动化、复用测试用例资产。 这里我们简单对接口测试覆盖率自动化检查办法的相关实践进行说明。
二、基本思路
首先在目前的常见DevOps云化平台中基本都有各自对应的测试平台用于方便、快捷地在线编写用例、执行相关测试任务。 其次在服务部署时云化背景中都是通过DevOps流水线来进行的而为了保证发布版本的合规与可信我们通常会在流水线中添加相关检查与卡点门禁。 最后在服务上线后的运维阶段APM应用性能管理平台会对服务线上接口调用情况做各个维度的统计分析其中就包括了最基础的接口调用环境与具体内容。 基于以上三点思考我们提出利用实际调用链用户侧使用数据聚合统计API实例并利用门禁插件与云化测试相结合的方法来实现对服务接口测试覆盖率的自动检查功能。
三、实践办法
1、API基线统计方法
对于哪些API需要看护统计这其中是需要我们做自动化的识别与统计的。正如第二部分所提到的我们可以直接利用调用链数据来做聚合统计分析找到哪些接口调用次数最多、哪些接口是在生产环境中被实际使用到的。对于这类接口自然是重要等级的接口因此在测试覆盖上我们就需要有强制要求。 通过这种接口分层分级的方法我们便能够快速识别重要接口在保证测试覆盖核心接口的同时减少服务自身用例编写与维护的工作量。
2、云化测试用例
在云化测试平台中接口测试本质上就是利用可视化的AWActionWord可以理解为一个接口单元进行用例撰写并通过在线的执行机发起测试请求、通过对比检查点来判断用例是否执行通过。 因此服务方面只需要在平台中导入对应的接口设计文档yaml文件编辑维护好对应的测试用例并将对应的测试用例统一编排在同一个测试任务中就能够一次全量执行、作为一个统一的视角对外提供用以表达当前服务接口功能的可用性与正确性。
3、流水线插件检查方法
在目前的DevOps流水线体系中服务只需要点击按钮、跑一下流水线就能够自动的将代码仓中的内容部署到现网的机器中。这种方式虽然方便但为了保证整体上线功能的可靠性我们会在流水线的各个环节中添加门禁与卡点包括安全问题、病毒扫描、开源风险等等。 基于这种门禁卡点与检查的逻辑我们便能够直接在流水线中强制添加一个接口覆盖率检查的环节通过获取服务对应云化测试任务中所有接口的测试结果并根据我们API基线的统计数据分析以此对比得出对应服务的重要接口是否有测试用例覆盖。
四、发散与扩展
在上述所说的接口检查中本质上只做了API是否有用例覆盖的相关检查并没有更详尽的检测而在接口测试维度依旧存在着很多痛点与问题。 用例代表了服务对用户调用接口行为的模仿与预测并制定出的执行测试样例。虽然在一定程度上可以检验接口功能的可用性但是会存在一些问题对于一个接口而言不同的参数调用组合实际代表的其实是用户不同的行为逻辑而这种不同的参数组合在代码层面可能会代表截然不同的行径与分支从而带来各种各样的结果。测试人员在编写用例时只能在局限的范围内尽可能模仿用户的使用行为逻辑但很难将用户的全部行为都囊括在其中。 因此基于调用链大数据分析手段我们对海量的用户接口调用与参数情况做聚类分析并提出了一种名为“用户场景覆盖率”的看护维度。
1、用户场景覆盖情况
该场景原始数据来源为鲁班调用链经过我们大数据聚合分析之后可以得到具体结果在生产环境中用户调用的相关实际接口、调用参数组合以及各参数组合的调用次数情况。 同时针对大数据的分析手段我们可以对具体参数组合调用次数做分析统计并针对性地引入“高频”的概念以定级对于调用次数较少的的级别的场景我们倾向于是不重要的或异常的调用找出调用次数多的高频场景。
2、用例场景覆盖情况
基于微服务所配置的功能测试套解析对应的用例接口以及相应的参数选择情况就可以找到服务侧所定义的接口场景覆盖情况。 最后上述两种的参数组合覆盖情况的差集就可以得到了接口对应用户场景未覆盖的情况。 加之结合用例自动化的生成手段就可以较为方便快捷的为服务提供接口调用场景的缺失与待补充情况作为用例设计的指导。
五、小结
接口测试一直是服务的一项重点工作如何又快又好的完成接口在线测试、同时发现测试遗漏点是我们一直探究的目标。上述的相关实践只是其中的一个环节实测有效仅做参考。
