浅谈基于微服务架构前后端分离开发项目的软件测试方法
摘要：随着技术的进步和架构演进，应用云化、微服务化开始成为主流，伴随而来的前后端开发的精细化也是必然趋势，不仅可以提升开发效率，应对复杂多变的前端需求，也可以增强代码可维护性，因此越来越多的项目开始采用基于微服务架构前后端分离开发模式，而之前适用于单一整体式架构的测试方法和工具也必须相应转变，才能更好提高测试效率，尽早发现bug，降低开发成本，保证成品质量。
关键词：微服务架构、前后端分离开发、软件测试
软件测试app1、背景
在传统的前后端混合开发单体项目中，系统相对容易开发、测试、部署，但面对的问题也很多，例如前后端严重耦合，开发效率较低；不同模块发生资源冲突时，扩展非常困难；系统个模块的边界模糊、依赖关系不清晰；代码质量参差不齐，问题定位相对复杂；测试介入时间较为滞后，造成bug修复成本较高。所以随着技术的进步和架构演进，基于微服务架构前后端分离开发模式应运而生。
微服务是一种架构风格，即将单体应用划分为小型的服务单元，微服务之间通过安全的Http Restful 接口进行协同通信，具有复杂度可控，技术选项更灵活，可扩展性更强，容错性更高等优点。前后端分离的开发模式是把前端与后端部署为两个不同的工程，两个不同的代码库，前后端工程师需要约定交互接口，实现并行开发和测试，前端只需要关注页面的样式与动态数据的解析和渲染，而后端专注于具体业务逻辑。微服务化和前后端分离开发模式有天然契合度和融合性，两者的结合可通过对共享业务更细粒度的拆分，和前后端代码的解耦，以及定义良好的接口清晰表述服务边界，使开发团队快速应对需求的变更以及市场的复杂多变，打造出架构清晰、前后端并重的优质产品。鉴于这些优点，越来越多的项目开始采用基于微服务架构前后端分离开发模式，而这种模式下的测试与传统单体架构测试即有相同之处，又带来新的测试挑战。
2、面临的挑战
在基于微服务架构前后端分离开发项目中，多个微服务可能同时被开发，每个微服务有不同的开发周期、开发进度和交付期限，但是整个团队又必须保证统一的节奏，持续地、稳定地提供可测试、可部署、可使用的产品。这意味者，过去传统单体项目中先等产品经理
、业务部门提供需求，开发人员再进行开发，最后交给测试人员执行集成测试的方法，已经无法满足新模式下测试粒度和测试速度的需要。
在基于微服务架构前后端分离开发项目中，因微服务的松耦合特性，直接造成了其服务接口多，版本迭代频繁，并随着项目的进行和业务的复杂深入，也经常会衍生出新的微服务，这必然导致需测试的接口数量会成倍增加，影响测试的依赖和故障分析的复杂度也会随着微服务的数量增加而提高。另外，有些微服务之间由于是内部服务的互相调用，不暴露给用户，为了效率，很有可能采用rpc类的协议，对测试人员来说就是更大的挑战了。
3、测试方法
根据微服务架构前后端分离开发模式的特点，以及测试所面临的各种挑战，本文结合项目测试实践与思考，将从以下几个方面阐述该模式下软件测试方法。
3.1测试分层
在传统单体架构时，测试团队根据Martin Fowler的测试理论，强调测试分层以及每一层的恰当覆盖，整体符合金字塔结构。在基于微服务架构前后端分离开发项目中，大的单体要
拆分成更小的一个个微服务模块，各个微服务之间通过Http Restful 接口去做协同和集成，而且在在微服务化以及多应用端背景下，接口也成了前端页面或APP等调用与后端做交互用的通道，接口的测试就尤为重要。同时，因为单元测试的学习成本较高、难度较大，前端界面改动频繁，应用端众多，为了平衡成本和收益，基于微服务架构前后端分离开发的项目更适合蜂巢模型的测试策略，即重点关注中间的服务间接口测试，并将部分前端测试下移，用接口测试取代，同时减少单元测试的投入。
蜂巢模型
3.2前后端分离测试
采用前后端分离开发模式不仅仅只是前后端开发的分工，而是前后端代码存放分离、前后端开发职责分离，无需等前后端联调完才进入测试阶段，而是哪端先完成就可以先进入测试阶段，并可快速进行bug定位，减少测试工时，提高测试效率。在开发期间，前后端共同商定好数据接口的交互形式和数据格式，编写接口文档。根据接口文档可实现前后端的并行开发，测试人员也可依此接口文档编写测试用例和测试脚本，前端工程师在开发完成之后可以独自进行mock测试，而后端也可以使用Postman、Jmeter等测试工具开展测试，在前后端独自测试都通过前提下，再开展前后端功能联调就可以事半功倍。
3.3接口测试
在前后端混合开发的单体架构中，后端是被封装在前端内部的，通常以前端的黑盒测试为主，通过“点点点”完成功能、界面的测试。在前后端分离的微服务项目中，接口是微服务间、前后端之间重要交互通道，针对接口开展测试，能够更早单独验证后端功能的准确性，降低系统测试复杂度，屏蔽UI层的不稳定性，检查系统的异常处理能力和系统的安全性、稳定性，另外接口测试通过后，后端功能不改变的情况下，可以对接不同的前端应用。
微服务项目接口测试时，接口文档是接口测试方案设计的依据，接口文档的全面性和准确性决定了接口测试范围的全面性和接口测试结果的正确性、有效性。项目团队需对接口文档进行规范和约束，可采用swagger进行接口文档管理。测试团队根据接口文档设计测试用例，准备测试数据，开发接口测试脚本，最后通过postman、jmeter、soupUI等工具执行测试脚本，模拟http向服务器发送请求报文，接收服务器返回应答，并判断返回是否符合预期。
在基于微服务架构前后端分离开发项目中，服务间的调用关系复杂，接口测试是保证服务提高质量的重要手段，在大幅降低测试成本和提高测试效率方面提供了很大帮助，是测试左移可落地实施的有效措施。
3.4自动化测试
微服务架构的一大优势是快速交付，快速交付不止体现在服务的粒度更小，可以独立交付，还体现在整个流程更快速。微服务架构基于自动化的工具链，以流水线交付的方式串联整个DevOps流程。传统单体项目的交付周期以月、周为单位，而微服务架构的交付周期能做到以天为单位，传统的手工测试是无法满足这样的交付周期要求的，因此要扩大自动
化测试覆盖面。
微服务架构下，单元测试可使用基于NUnit或JUnit的单元测试框架，实现以较少的QA参与的自动化测试并用断言判断执行结果，便于尽早发现缺陷，降低修改成本。
接口自动化测试可以使用Jmeter+Ant+Jenkins自动化测试框架，Jmeter用于调试接口自动化测试脚本，Ant是基于Java的构建工具，Jenkins是持续集成工具，将这三者结合起来可以搭建一套HTTP接口测试的持续构建环境，实现接口自动化测试。
基于微服务架构的UI自动化测试的实现时，可使用EXCEL表整理自动化用例，在表中加入URL、testID、值、返回位置、预期返回数据等，然后通过Python+Selenium调excel表，进行UI自动化测试。
自动化测试是快速、安全地交互软件的重要基石。更重要的是，由于微服务架构固有的复杂性，要从微服务架构中充分受益，必须实现自动化测试。
3.5线上巡检
利用接口自动化测试脚本，建立生产系统核心关键接口定时自动检测机制，如果微服务某个接口测试未通过，将立即把测试日志以邮件或企业形式通知相关运维人员，在用户发现问题之前，解决问题或返回到上一个已知的优质版本，使用户对问题无感，从而提升系统使用满意度。
4、结语
随着微服务技术发展和架构的演进，基于微服务架构前后端分离开发项目的软件测试也将面对新的挑战和更复杂的场景，文中只是在微服务测试上的初步实践与学习，希望在今后的开发测试中，摸索出更适宜于微服务架构的最佳测试方法。

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。