Menu Close

案例分享|领先未来的MeterSphere接口测试实践

编者注:本文作者为领先未来科技集团研发中心测试部经理马林。

领先未来科技集团成立于2007年,总部位于北京,是中国领先的B2B综合解决方案服务商。深耕行业十余年,领先未来科技集团(以下简称为领先未来)致力于为客户提供全场景采购数字化解决方案,涵盖办公物资、工业品、礼品福利、智能办公等领域,可提供21个大品类超过200万SKU的优质商品。

目前,领先未来已经为包括央企、政府、军队、国企及世界五百强在内的上万家客户提供了专业服务,依托全国超过1000家服务网点及专业的服务团队,将线上采购和线下服务深度融合,实现了客户服务全覆盖,让客户的工作更美好。

依托十余年B端采购服务经验,领先未来利用自主研发的数字化系统面向企业采购各场景打造数字化采购全链路,更加符合业务应用场景。目前,集团的B2B办公服务平台包括PC端领先未来商城、手机端领先未来商城,后端包括ERP运营管理系统、CRM客户管理系统、WMS仓库管理系统和移动办公OA系统。

测试方面的问题和挑战

领先未来的测试团队有将近40人的规模,隶属于集团的研发中心,各个产品线并行在测项目超过20个。项目全部基于微服务架构,分别涉及功能、接口、UI、性能、Elasticsearch、大数据等测试内容。普遍存在项目交付周期短、任务重、测试时间比较紧张的情况,难以达到100% 覆盖及回归的目的。基于多方面因素的考量,相对于单元测试、系统测试(UI、集成等)的较高实现成本,测试团队计划逐步加大接口测试所占的比重,类似于在纺锤模型中扩大中间层。

接口测试相关工作内容

■ 功能测试团队:针对接口常见错误总结了一份CheckList,在功能测试的同时借助浏览器F12、Fiddler等工具,以手工抓包的方式验证页面外部接口请求和响应内容的正确性;

■ 对接第三方系统接口测试团队:针对与第三方系统对接开发的接口进行测试,涉及接口测试及双方接口的联调工作。这类项目数量大、周期短,且每个项目接口设计方案均不相同;

■ 自有产品接口测试团队:各产品线的众多微服务涉及到内、外部接口多达几千个,统一在Swagger进行维护。需要进行单接口测试、基于业务场景的多接口测试,需要长期迭代维护接口测试用例和脚本。

面临的主要工作痛点

■ 各测试组进行接口测试的浸入层次不一致,有基于独立工具开展的,有基于Pytest框架开展的,有基于JMeter开展的,各类测试脚本难以统一规范与整合,无法进行统一管理。另外,项目之间人员效能、产品质量也无法合理地进行度量和横向对比;

■ 接口测试用例的执行与开发自测环节没有打通。我们希望由测试人员开发完接口测试用例,交由开发人员进行自测,通过后测试人员进行最终的验收,而不需要由测试人员去反复执行用例后再将结果通知到开发人员。这看似简单的环节,由于没有统一平台的支持,只依靠Postman、Git等工具维护用例脚本,在开发和测试之间想无缝对接很难实施。

MeterSphere的优势

在使用了MeterSphere开源持续测试平台后,我们明显感觉到接口测试更加规范和高效了。总结起来,MeterSphere的优势主要包括以下几个方面:

1. 切换成本低且易上手

无论从传统手工功能测试还是到接口、性能自动化测试,MeterSphere平台的易用性设计还是很不错的,基本上使用过禅道、Postman、JMeter的同学可以很快上手、无缝对接。领先未来的测试团队从接触MeterSphere到实际应用只经过了一周多的时间。

2. 有效提升团队工作效能

相对于各种独立、单机版的测试工具,MeterSphere持续测试平台更适合团队协作,同时针对不同的角色可以辅以相应的权限控制。从各项目首页看板,我们可以宏观地查看接口数量,进而预估后期测试工作量,并制定准确的测试计划。通过接口覆盖率统计,可以把控项目的实际工作进度。

3. 强大且灵活的接口测试支撑能力

在测试部门,多个项目已经实现从接口定义、编写接口测试用例、统筹多接口以覆盖业务线为目的的接口自动化测试,到生成测试报告的全面应用。

① 接口定义功能。有些三方项目我们会通过手工方式录入,而一些大型的自有项目会通过Swagger直接导入进来,对于多达几千数量的接口,这个功能就非常方便;

② 编写独立的接口测试用例。MeterSphere支持定义各类请求、参数化、关联、断言这些通用能力,同时扩展了前置脚本、后置脚本、SQL、参数提取、全局设置等更多的利器,目前基本满足各项目绝大多数的接口测试场景。

③ 基于业务场景的接口测试。除了针对每个独立接口进行正向、反向测试外,团队还考虑了基于场景级别的接口测试,以业务线的方式依次执行多个接口,提升产品质量信心。这部分用例相对会比较复杂,涉及数据库读取、加密处理、批量构造测试数据、关联等更多脚本内容。

④ 随着对MeterSphere的逐渐熟悉,各个测试小组还积累了一些小技巧。例如灵活运用标签功能,标明区分哪些是正向用例哪些是异常用例;而对于不同入参设计的异常测试用例,其数量大且相似度较高,此时我们会先维护好标准的API定义,其全部参数均提前定义有效输入,再以其为模板生成多条异常用例,这样只需在对应的参数位置进行较小的修改即可。

TDD和DevOps

MeterSphere开源持续测试平台可以加强测试团队的协作和沟通,以自动化测试的方式提升持续软件交付能力。在引入MeterSphere后,我们试行了由测试人员并行编写接口测试用例,同时在测试跟踪模块创建测试计划,给开发人员分配角色和权限,由开发人员自行执行并使之通过的过程改进,以期减少测试执行过程中的反复沟通。这个过程在无形中也更加规范了开发的接口设计规范,否则测试用例就会难以执行通过。

期待改进之处

■ 测试环境的配置往往低于生产环境,执行脚本时由于网络抖动、服务的不稳定、服务调用超时等因素经常引起个别用例执行失败。此时需要在整体测试计划之外对失败的个别用例进行手工补充执行以进行验证,所以希望MeterSphere平台可以对用例失败后重复执行次数进行全局和局部的设置;

■ 希望MeterSphere平台尽可能多地去收集不同领域、不同规模的企业应用场景,结合行业最新的测试理念,形成自己的测试理论体系及配套的最佳实践。也希望MeterSphere开源项目团队能够设计典型Demo案例,辅以细致的文档、视频资料等,给更多中小企业以启迪和支持,这样做也有利于MeterSphere项目在企业用户群的推广。

MeterSphere开源持续测试平台引入到领先未来给我们带来了很大惊喜,在此非常感谢MeterSphere开源项目组的辛勤付出。我们也期望在后续的时间里MeterSphere项目能够更快地成长,变得更加强大,稳步打造成为国内最好的开源测试管理平台。

Posted in 持续测试, 案例