网站备案号注销查询系统,wordpress合并js,知识付费问答系统网站开发,网站建设遇到的问题及解决方法阿里妹导读#xff1a;在所有的开发测试中#xff0c;接口测试是必不可少的一项。有效且覆盖完整的接口测试#xff0c;不仅能保障新功能的开发质量#xff0c;还能让开发在修改功能逻辑的时候有回归的能力#xff0c;同时也是能优雅地进行重构的前提。编写接口测试要遵守… 阿里妹导读在所有的开发测试中接口测试是必不可少的一项。有效且覆盖完整的接口测试不仅能保障新功能的开发质量还能让开发在修改功能逻辑的时候有回归的能力同时也是能优雅地进行重构的前提。编写接口测试要遵守哪些原则测试代码的结构应该是什么样的接口测试有哪些实践技巧本文分享作者在接口测试上的实践总结。
一线开发同学可能都或多或少地造成过线上bug甚至故障也会遇到这样的场景某同学在开发某功能的时候重构了代码造成了线上bug或者故障在开发某个功能时发现需要修改公共逻辑害怕影响到其他功能非常不雅观地拷贝代码重新写套单独逻辑来支持。
上面这些情况都包含了一个关键的问题无论是功能开发还是逻辑重构如何来保障代码开发的质量。保障的手段每个人都知道就是测试。首先是新功能测试保障新功能逻辑正确其次是回归测试保障原有业务功能逻辑正确。测试的方式一般是两种人工测试和自动化测试。随着测试技术和工具的持续发展人工测试比例逐步降低被自动化测试逐步替代。自动化测试是可持续和可重复的甚至是可AI化的。 一 测试分层
测试也是分层的如下图所示 在一个系统内自动化测试一般分单元测试、模块测试和接口测试。 单元测试
目前我的应用代码基本都是基于spring框架面向接口这种编程模式单元测试已被弱化。单元测试的要求基本上是单个类单个方法的测试在我们当前模式下编写成本太高。当然如果是一个工具或者一段比较内聚而又复杂的逻辑(例如算法逻辑)还是应该使用单元测试来保障逻辑的正确性。 模块测试
在系统比较大、模块比较多的情况下可以建立模块测试层保障各模块功能的正确性。不过当前的系统发展趋势是微服务架构因此模块测试层并非十分必要可以通过接口测试层来覆盖。 接口测试
个人觉得准确来说应该叫入口测试这一层是从系统入口出发进行集成测试。应用入口通常是HSF一个分布式RPC服务框架服务消息定时任务。
作为开发测试手段千万条接口测试不可少。在我们应用的接口测试有效且覆盖完整的情况下不仅能保障我们新功能的开发质量还能让我们在修改功能逻辑的时候有回归的能力同时这也是我们做代码重构的前提。同时易测性也是代码结构合理的一个指标如果发现一段代码编写测试脚本困难或者无法测试那就说明当前代码结构不合理需要重构。接下来我将主要谈一谈接口测试的有效性。
现在我也找了很多测试的朋友做了一个分享技术的交流群共享了很多我们收集的技术文档和视频教程。
如果你不想再体验自学时找不到资源没人解答问题坚持几天便放弃的感受
可以加入我们一起交流。而且还有很多在自动化性能安全测试开发等等方面有一定建树的技术大牛
分享他们的经验还会分享很多直播讲座和技术沙龙
可以免费学习划重点开源的
qq群号110685036 二 测试原则
基础原则 自动化接口测试是非交互式的自动化执行不需要人参与。 独立性接口测试之间不应该相互依赖。 可重复接口测试可重复执行不受环境影响。 接口测试遵守BCDE原则保障接口交付质量。 Border边界测试。 Correct正确的输入正确的预期输出。 Design按照需求和设计文档编写测试逻辑。 Error错误输入预期输出。 数据准备数据准备通过系统服务进行不能通过直接插入db方式。 可测性对于不可测的代码需要进行重构成合理的结构。 覆盖性接口测试需要覆盖所有UC同时代码覆盖率和分支覆盖率应达到一定标准新增代码必须被覆盖。 持续性如果代码修改导致已有接口测试执行失败必须修复代码问题或者测试代码逻辑。 时间要求接口测试应该在项目发布之前完成不应放到项目发布之后补充。
以上的基本原则应适用于所有层的自动化测试用例在编写接口测试时除了上面这些原则还有其他原则需要遵守先看一张图 从系统角度来分析入口调用以HSF服务为例 外围系统调用由我们系统提供的服务。 系统执行了一堆代码逻辑其中包含有分支逻辑。 系统执行过程中依赖外部HSF服务进行了调用并得到了返回值。 系统执行过程中依赖DB查询或者落地了数据依赖缓存查询或者落地了数据。 系统执行过程中对外发送了消息。 给上游系统返回HSF执行结果。
有效接口测试的关键原则是要覆盖所有入口mock所有依赖校验执行过程中所留下的痕迹总结如下 入口覆盖接口测试用例必须覆盖HSF服务入口、消息入口、定时任务入口。 依赖mock在基本原则中有可重复这个原则即接口测试不能受环境依赖需要mock掉对外依赖。但对于db依赖不建议完全mock掉一方面mock成本高另外可能覆盖不到sql和表约束逻辑。 校验完整有效的接口测试应该具备完整的校验没有校验的接口测试是没有意义的。只要执行过程中留下的痕迹对业务有影响都要进行完整校验方能保障接口测试的有效性。 HSF接口返回值校验按照场景和接口约定进行HSF返回参数校验。 DB校验校验落地数据的正确性。 缓存校验校验存入缓存中数据的正确性。 HSF依赖入参校验通过mock工具获得依赖HSF调用的入参进行入参校验。 消息校验通过mock工具获得发送的消息对象进行消息体校验。 三 测试代码结构
在编写测试代码的时候也应跟写业务代码一样考虑代码的可读、可扩展、可复用性。同时也可以根据系统的业务特性在测试框架的基础上封装适合当前系统的测试组件提高测试代码编写效率规范测试代码结构。
一个接口的测试代码大概的结构如下
1 测试准备
依赖数据准备
很多时候我们的测试有数据依赖可能是配置数据也有可能是业务数据(例如退款需要依赖支付数据)。 配置数据可以通过定义配置文件来初始化配置。 业务数据这类数据禁止通过直接插入数据方式产生而是应通过调用业务服务产生。 依赖mock
对于外部依赖需要对被依赖的服务进行mock避免真实调用。 接口测试入参准备
准备接口方面的入参。
2 测试执行
调用接口方法执行业务逻辑。
3 测试校验 返回参数校验校验接口的返回参数。 DB校验DB落地数据。 缓存数据校验校验落地到缓存中的数据。 消息校验校验对外发送的消息对象。 对外HSF调用校验校验对外HSF调用的入参。 四 实践技巧
1 执行效率
对于接口测试执行效率是不得不关注的一个点若一个接口测试执行3分钟以上才能看到结果会大大降低开发同学编写接口测试的热情。对于测试执行效率提高建议的方案为 最小化启动测试上下文例如spring boot的应用启动spring就可以了 使用内存数据库例如h2 将中间件依赖mock掉 2 测试框架选择
对于测试框架建议选择基于testng能够提供通过配置文件做数据准备的测试框架。如果找不到合适的可以自己基于testng进行封装。 3 接口测试覆盖度
场景的完整性影响着测试用例的覆盖度一方面需要开发同学基于业务场景的输入和测试经验枚举出正常和异常情况另一方面接口方法也有一些固定需要测试的点例如幂等测试边界值测试参数不正确测试等等。
同时也要通过覆盖率工具查看接口未覆盖的代码或分支逻辑进行针对性的场景覆盖测试。根据我的经验分支完整覆盖非常重要特别是异常的分支。 五 总结
要保障系统线上运行稳定质量保障手段必不可少。虽然现在有很多自动化的保障手段但接口测试依然是最基本的和最重要的保障手段之一。如能做到持续保障接口测试覆盖度和有效性很大程度上会降低线上bug的产生开发同学也会更有积极性去重构代码。
今天的分享就到此结束了大家还有什么不懂的可以评论区下提问哈如果我的文章对你有所帮助的话可以点赞三联支持一下哈
