收钱吧的 Python 高效自动化测试实践

海哥  金牌会员 | 2024-7-20 07:13:53 | 显示全部楼层 | 阅读模式
打印 上一主题 下一主题

主题 664|帖子 664|积分 1992

1. 配景

收钱吧业务服务千万级商家,业务庞大,产品背后有复杂的应用支撑。我们采用了微服务架构,有成百上千个不同类型的后端服务,利用了包罗Node.js、Java、Go、Python等后端语言,还有Mysql、MongoDB等数据库以及Elasticsearch、Kafka、Redis、Apollo、RabbitMQ等中间件。
随着产品需求复杂性的不断上升,传统功能测试的片面性及滞后性导致测试本钱急剧增加、测试效率大幅度降落,仅靠功能测试已难以持续保障项目质量及交付效率。
而自动化测试可以帮忙测试人员在项目初期就能发现体系深条理的问题,并且降低了问题修复的时间本钱,其好处显而易见。自动化测试也在各大互联网公司逐步地落地,这是局势所趋,收钱吧质量工程部在这几年里不停在践行高效的自动化测试,并且有了一些成果。
2. 测试策略

自动化测试是一个泛称,它包含了诸如单位测试、接口测试、Web 测试等具体测试本事,每个自动化测试本事有其优劣势,找到得当收钱吧技能状况的自动化策略是可以或许实践成功的第一步。
在微服务架构下,相比测试金字塔[1],我们更加推许蜂窝型分层[2]。

  这是因为:

  • 对于微服务模子的项目来说,服务即『单位』,接口表达了『单位』的本事,并实现了单位之间的通讯,编排接口的调用则完成了业务、产品逻辑;

  • 单位测试代码量大、开辟工程师无法投入较多的精力进行维护,且不可以或许通过单位测试来实现服务之间的集成测试、覆盖业务场景,实际收益实在并不明显;

  • 在项目初期有接口定义的情况下,测试工程师可以较早地介入项目当中计划、开辟接口测试用例,无需等开辟工作全部完成,实现测试左移,可以更早地发现体系问题,提高了整体的效率。
接口自动化测试兼顾了介入早、维护本钱低、业务逻辑覆盖完备等优点,因此它成了我们自动化测试重点投入的方向。
2.1 细化微服务下的测试策略

除了明白接口测试是重点以外,我们还要基于微服务架构的分层特点,进一步细化自动化测试策略。
我们简明扼要的描述下当前的体系架构,如图:



  • 接入层:面向客户端,客户端通过调用接入层的接口来哀求应用层的服务,得到响应后,包装数据返回,给客户端利用。比如API网关,它的重要职责包含哀求认证鉴权、安全校验、返回值的包装、哀求的转发,其本身并没有业务逻辑;

  • 应用层:服务面向业务,它通过对一个或者多个范畴层服务的调用、编排来实现业务功能。比方我们体系中的业务开通服务,它依赖用户中心、商户中心、进件、银行卡等范畴层的服务来实现其功能;

  • 范畴层:面向范畴对象,范畴对象是具有高内聚、低耦合的特点,且具有单一的职责。比方我们体系中的付出服务、银行卡服务、分账服务等,它们只实现本身的业务规则和逻辑,可能会依赖一些三方服务、内部服务;

  • 底子设施层:如关系型数据库、缓存服务、消息队列等。
成百上千个后端服务有不同的分层界定,我们可以从接入方调用的视角简化成下图所示&#x

免责声明:如果侵犯了您的权益,请联系站长,我们会及时删除侵权内容,谢谢合作!更多信息从访问主页:qidao123.com:ToB企服之家,中国第一个企服评测及商务社交产业平台。

本帖子中包含更多资源

您需要 登录 才可以下载或查看,没有账号?立即注册

x
回复

使用道具 举报

0 个回复

正序浏览

快速回复

您需要登录后才可以回帖 登录 or 立即注册

本版积分规则

海哥

金牌会员
这个人很懒什么都没写!

标签云

快速回复 返回顶部 返回列表