洞窝交易结算系统质量&稳定性提升实践

1,030 阅读20分钟

一、背景介绍

(一)业务背景

  洞窝是一个赋能产业、服务用户的家装家居行业的数智化产业服务平台,围绕以“优质内容”聚合“精准流量”为核心持续提升数字化能力,加速数智化产业服务平台的建设及推广。截至 2023年末,洞窝累计上线卖场已达 934家,入驻商户超过 10 万家,注册用户超 2,500 万,平均月活 390.51 万。2023 年开通了澳门站以及新加坡、柬埔寨 2 个境外分站。洞窝现已接入12家支付渠道,6类分账产品。其中支持微信、支付宝、云闪付等18种线上支付方式,POS、现金、礼品卡等9种线下支付方式,年度实现交易额(GMV)超过900 亿元。这些多元化的支付渠道不仅为卖场提供了丰富的选择,更通过智能化、高效率的收银解决方案,极大地提升了卖场和店铺的运营效率和用户体验。

(二)业务特性

  洞窝不仅为中国大陆、澳门以及海外的ToB&ToC用户提供支付收银能力,还具备对店铺、商户货款、服务费以及营销补贴等多种费用结算的能力,通过其复杂多样的结算方式、灵活多样的支付方式以及广泛的海外业务覆盖,展示出了其独特且强大的业务能力,以下是洞窝业务的几个关键特性:

1. 多样化的结算方式

洞窝的系统支持实时分账、资管分账以及对接支付宝分账产品如云资通、直付通等,其中云资通除支付宝渠道费外,还涉及其他四种费用类型。这种复杂且多样的结算方式满足了各种不同的业务需求。

2. 高客单价的行业特性

由于洞窝主要服务于家居行业,特别是定制家装和整装类业务,其客单价较高。这就要求洞窝的支付方式必须具备灵活性和多样性,以便为用户支付提供便捷。

3. 海外业务覆盖

洞窝的业务已经覆盖了柬埔寨、新加坡等地,因此需要具备为海外业务提供支付结算的能力。

二、业务特性痛点分析

(一)交易财务业务高度耦合 - 牵一发而动全身

  发起交易后,交易服务会将订单的报文发送给清结算服务,清结算服务会根据报文中的信息获取费用项配置,并根据配置计算需要收取的费用项金额,然后清结算服务将各项费用返回给交易服务,由交易服务调用第三方支付渠道最终完成交易。如果交易或清结算任意一方出现改动,都有可能导致中间报文传输出现差异而产生问题,所以一方出现改动或者问题,另一方需要做同步验证回归,增大了测试工作量。

(二)支付灵活性高 - 敏感度要求高

  交易线上监控发现三方问题占比62%,面对第三方导致的线上交易问题,洞窝构建了支付路由系统以确保服务稳定性。公司整合了12家线上和线下支付渠道,提供了27种支付方式以供选择,且支持混合、分批和批中混支付。支付路由在不同渠道之间灵活切换,当主通道遇到故障时,能迅速调整优先级转向备用方案,保障用户交易畅通。对于支付系统的任何变更,我们都需要高度警觉,以优化用户体验和业务连续性。

(三)财务复杂度高 - 对QA人员的专业度要求高

  洞窝对接了六类分账产品,涵盖租金、货款、服务费以及针对外部商户的营销补贴等多种费用类型的结算。这不仅限于洞窝体系内部,还包括与天猫、抖音等第三方平台的订单结算。结算链路较长,逻辑复杂且涉及多方,例如对接天猫订单结算更是多达四方分账。除了关注资金流向外,还需确保接口的稳定性、数据的准确性、资金的安全性以及制定数据修复方案。此外,还需结合财务方案,及早识别垫资、客户投诉以及资金损失的风险点,并与业务方达成共识,制定兜底方案。

(四)低频高客单 - 对系统的稳定性要求高

  由于家具属于高客单价商品,单次交易金额较大,因此消费者对交易过程的安全性和可靠性有很高的期望,顾客购买家具的频率较低,但每次购买都需要投入大量时间和精力进行决策。因此,任何交易中断或错误都可能导致顾客体验差,甚至失去潜在销售。

(五)三方依赖强 - 出错不易感知

  对第三方服务的依赖通常较强,这包括支付、清算和物流等方面。这种依赖带来了效率和成本优势,但同时也引入了一些风险和挑战,尤其是在服务出错时不易被及时发现和感知的问题上。

三、质量保障方案

  我们主要从测试过程以及工具体系两大方面着手构建质量体系。

(一)测试过程

  整个测试过程,我们划分为四个阶段,分别为提测前,测试中,上线前以及上线后。测试过程sop如下图,接下来我们将抽取每个阶段的一些关键动作进行细致讲解。

1. 提测前--建立测试看板

  QA通过测试看板实现项目质量过程整体管控,一般在需求初评后,由项目对应的测试owner负责发起创建,主要内容包括问题清单、测试范围拆解、测试进度、bug 清单和生产验证方案等,通过该方式既能实现项目透明可视化管理,同时也能形成质量过程文档沉淀,便于后续参考学习、可跟踪、可追溯,具体内容包括:

  • 项目排期:记录项目的排期节奏和会议的跟进事项
  • 问题清单:记录从需求梳理到生产的整个链路过程中出现的问题和解决方案,并分级,划分owner和对齐
  • 风险和阻塞:记录链路过程中的风险和阻塞点,如客诉、垫资和资损等高风险点,及时与产品和业务方对齐,并要求业务侧提供兜底方案,保留看板记录
  • 测试进度:将项目的测试点按层级关系记录到看板上,每天更新状态,通过看板可以清晰地了解整个项目的测试进度
  • bug清单:记录项目测试中的 bug,包括交叉 bug、验收 bug 和线上 bug 等,通过对 bug 的分析评估项目质量和测试质量
  • 生产验证方案:记录项目发布的相关角色应该执行的操作,确保上线方案的一致性,尤其涉及第三方时及早协调,避免发布过程混乱

2. 测试中-CodeDiff

2.1 CodeDiff有哪些作用:

  • 加深对技术实现上的理解,有利于精准设计case、补充测试点
  • 防止在QA不知情下开发偷偷搭车
  • bugfix评估代码改动范围

2.2 进行CodeDiff的时机:

  • 提测时 - 明确改动范围,补充测试范围
  • 测试中 - 确认每次提交代码,查看代码改动点
  • 发布前 - 确保发布代码和测试代码一致,是否有非此次版本的功能,以及漏掉的功能

2.3 CodeDiff主要关注哪些问题:

2.3.1 DB相关
  • WHERE 子句里面的列尽量被索引,提高查询效率
  • ORDER BY 的列尽量被索引,提高查询效率
  • SQL语句对于可选字段有没有判空 可以使用 EXPLAIN 检查索引使用情况以及扫描的行数
2.3.2 代码层面
  • 业务逻辑实现是否正确
  • 提示语文案类,对比需求文档
  • 运算表达式需要注意精度问题以及运算过程(比如三个数相乘取四舍五入,那么是前两个数相乘取四舍五入后再与第三个数相乘,还是三个数相乘后取四舍五入)
  • 条件分支结构,结合业务判断是否有遗漏分支,条件判断语句参数为空是否会导致空指针异常
2.3.3 日志层面
  • 关键节点添加日志(如请求三方接口时,需要记录入参及其响应)
  • 日志级别(运行时info,遇到问题warn,遇到异常error,Exception)
  • 异常处理,在可能出现异常的地方添加 try catch

3. 测试中--接口自动化

  为了保障核心流程的稳定性,我们引入了接口自动化测试平台工具(工具介绍见下文),具体使用场景包括自动巡检模式、手动执行2种模式:

3.1 自动巡检模式

包括uat测试环境自动检查工具、线上接口主动巡检2类场景,其中,uat环境检查工具主要原理为:由于uat环境为多项目共用,会定期发布不同项目代码,稳定性挑战比较大,通过定期执行p0场景接口自动化测试对测试环境进行检查,一旦发现错误,会立即在钉钉群中发送告警通知,以便相关团队成员能够迅速定位并处理,随时保证uat环境稳定性。

线上接口主动巡检主要原理为:通过在线上环境定期自动执行P0只读接口,及时感知线上服务运行状态,以确保生产环境的稳定性和可靠性。

3.2 手动执行模式

在发布到预发环境但还未正式发布灰度之前,我们会在自动化平台上手动执行所有系统的核心P0场景用例。只有当这些用例全部执行通过后,才会进入正式发布环节。

因此,接口自动化实际上是贯穿整个项目生命周期,因为在整个项目过程中,我们都会遵循“自动化先行”的原则。

4. 测试中--测试日报

  测试日报是一种高效的项目管理和沟通工具,对于把控项目进度、质量控制以及风险管理至关重要。一般测试周期>=3pd、重点项目提测后均需要发送测试日报,披露进度、风险(明确到具体人)。测试日报的内容包括但不限于以下内容,可以根据各自项目自行定义:

  • 标题:命名格式一般是【项目名称xx】xxx日期 测试日报
  • 里程碑节点:主要包含一些项目关键节点,比如项目提测时间,介入测试时间,提验收时间,上线时间等
  • 今日项目进度:主要包含该项目整体测试进度以及具体模块进度
  • bug情况:将测试过程中发现的bug进行规整,记录呈现bug总数量,今日新增bug量,未解决的bug数以及已解决的bug数
  • 风险阻塞:该项主要记录在测试过程中,遇到的风险以及阻塞问题,描述问题之后,@对应问题解决人
  • 明日计划:主要包括明日项目整体进度,各个模块计划进度
  • 附件:附上看板链接,呈现数据明细都可以通过看板查看

5. 上线前--跟版owner机制

  为了规避在发版过程中出现代码漏合并,未修改生产配置,未执行漏执行上线SQL,漏发服务等问题,引入跟版owner机制,发版参考模板如下:

5.1 测试、后端、前端分别指定对应owner,各个owner分工如下:

5.1.1 测试owner
  • 发版列表统计:统计该发版周期内的所有项目
  • 需求状态检查: 发版owner需要检查每个小组的需求状态,确保所有的需求测试完成且产品&业务已完成验收
  • 发版材料检查:确保发版所需的材料都已经准备好,包括发版wiki,配置文件等
  • 通知相关人员:发版前,发版owner需要通知所有相关人员,包括开发人员、QA测试人员、运维团队等,确保他们都知道发版的时间点和相关事宜
  • 发版执行: 在确定一切都准备就绪后,按照计划执行发版操作
  • 验证: 发版后,QA团队应该进行生产的验证步骤,以确保新功能是正常的
  • 后续行动: 根据发版的结果和反馈,进行必要的后续行动,如发布补丁、或发送上线通知
5.1.2 后端owner
  • 确认检查发版内容以及上线wiki
  • 确认发版时间节点
  • 合并代码,整理api以及服务列表,环境配置项
  • 通过日志检查服务状态
5.1.3 前端owner
  • 确认发版项目和wiki是否匹配,检查代码review 状态,项目验收状态
  • 合并代码,运维发布完成后,前往金丝雀检查确认
  • 如若涉及小程序,还需将体验版小程序提交审核

  跟版owner机制主要作用是确保项目进度和质量,通过指定责任人(owner)跟踪项目,及时发现和解决问题,确保项目按计划推进并达到预期目标。

6. 上线后--日志巡检

  日志巡检是确保线上服务稳定运行的重要手段。通过筛选关键词如"error"和"Exception",可以有效地定位异常日志并快速发现系统中的问题。

6.1 日志巡检的流程和方法

  • 定期+不定期检查:版本发版完成后当日及次日定时检查,日常不定期巡检
  • 关键词过滤:使用关键词如"error"、"Exception"来定位潜在的问题
  • 上下文分析:查看错误发生的时间点和相关的事件,以确定问题的根本原因

6.2 问题分类和处理

  • 空指针异常
  • 接口超时
  • 数据库字段相关问题

  针对上述日志巡检经常遇到的问题,需要反馈给研发人员,检查代码逻辑,确保在引用对象前进行非空验证。优化网络延迟,提高接口响应速度,或者调整超时设置。审查SQL查询,确保数据的正确性。

7. 上线后--业务数据自动化监控巡检

  根据交易结算业务特性,对第三方服务的依赖性较强,一旦第三方服务出现故障或异常,可能会对业务造成严重影响,且不易感知,因此,业务数据自动化监控工具可以帮助我们及时发现和处理三方异常情况,确保业务的稳定运行。目前10余个项目已接入业务数据自动化监控工具,有效发现因三方接口异常、服务异常、阿里云OSS异常等问题,导致我方系统处理失败的问题10+,发现问题后通过前置的告警机制,掌握主动权,提前采取相应的措施,确保系统稳健。

(二)工具体系建设

  工具体系分为两部分,提效工具体系和稳定性保障体系。

1. 提效工具体系

  提效工具体系包括接口自动化平台和效率工具平台。

1.1 接口自动化平台

  为了提高效率,我们引入了接口自动化平台,用于管理和执行接口测试。

1.1.1 平台简介

  该平台由前端和后端两部分组成。前端使用Vue.js框架,提供了一个友好的用户界面,让测试人员可以方便地创建、管理和执行测试用例。后端使用Java Spring Boot框架,负责处理前端的请求,执行测试任务,存储测试数据。

1.1.2 平台亮点
  • 平台使用RocketMQ作为消息队列,用于在系统内部传递测试任务和测试结果。这样,即使测试任务非常多,也不会阻塞系统的运行,保证了系统的高效性
  • 平台使用Redis作为缓存,用于存储频繁访问的数据,如测试用例、测试套件等。这样,当我们查询这些数据时,可以直接从Redis中获取,提高了系统的响应速度
1.1.3 功能模块
一级模块二级模块功能简介
接口管理http接口
dubbo接口
创建用例之前先录入接口,支持复用,效率更高
接口测试项目管理
测试用例
用例集合配置
测试报告
先创建测试项目
创建场景用例、调试、执行
通过该功能实现多场景用例批量执
生成测试报告
配置管理Database管理
Redis管理
创建mysql数据源
创建redis数据源
统计分析接口分析
用例分析
统计分析
统计分析

1.2 效率工具平台

  效率工具平台集成了一键生单、退款审批等多个提效工具,可以借助这些工具完成一些重复性的手工工作,以节省时间和提高工效。

1.2.1 平台简介

  效率工具平台前端采用了Vue3和Vite4技术栈,提供流畅的用户界面和快速响应。后端使用Spring Boot,确保系统的稳定性和可扩展性。结合我们的提效工具,能够有效提升QA人员的工作效率。

1.2.2 主要功能介绍

  工具平台主要包括不同渠道自动生单、一键配置商编、一键移除短信黑名单、一键生成发版计划等功能。

1.2.3 应用实践:

  手动配置商编需要以下10个步骤:

  工具平台一键配置商编只需要以下3个步骤:

2. 稳定性保障体系

  稳定性保障体系主要包括业务数据巡检监控工具。该工具通过定期巡检业务数据,及时发现和预警潜在问题,确保系统的高可用性和稳定运行。

2.1 业务数据巡检监控工具

2.1.1 工具简介

  巡检工具采用Python语言,结合PyMySQL、PyYAML、Requests和Unittest,提供了高效的功能和稳定的性能。Python提供了强大的编程能力,PyMySQL确保了高效的数据库操作,PyYAML使配置管理变得简洁明了,Requests简化了HTTP请求处理,而Unittest则为我们提供了全面的测试支持。这些技术的结合,使我们的工具不仅功能强大,而且具备高可靠性和可维护性。

2.1.2 项目目录:

2.1.3 Unittest四大组件介绍
  • Testcase:一个TestCase的实例就是一个测试用例,一个完整的测试流程
  • Testfixture:测试用例环境的搭建和销毁,包括测试前准备环境的搭建(setup),执行测试代码 (run)以及测试后环境的还原(teardown),每个测试用例方法执行前后都要执行这两个方法
  • Testsuite:测试套件,批量执行用例集,可以将多个测试用例集合在一起
  • Testrunner:运行器,通过runner的run方法去调用执行测试用例集

2.1.4 程序运行流程图

四、实践结果

(一)测试提效

  1. 接口自动化平台的投入,交易订单链路单次回归时长由0.5人.天缩短为60秒
  2. 工具平台的投入,交易订单链路单次构造数据由1-2分钟缩短为10秒

(二)稳定性提升

  1. 发布过程故障率降低(近半年无因漏修改配置文件、漏发服务产生的线上故障)
  2. 线上问题得到明显收敛,最近一年由月度最高16个逐渐降到2个左右

(三)人员能力提升

  1. 通过工具实践,团队人员具备代码编写能力,实现业务监控工具开发常态化
  2. 通过项目实践,团队成员具备了测试左移和右移的思想,开始从测试转变成质量保障

五、总结与展望

  在本文中,我们详细介绍了交易结算系统在质量和稳定性提升方面的实践。从测试过程的优化到工具体系的建设,我们逐步构建了一个全面的质量保障体系。

在测试过程中:我们将整个流程划分为提测前、测试中、上线前和上线后四个阶段,并在每个阶段采取了针对性的措施。例如,提测前建立测试看板,测试中使用CodeDiff和接口自动化,以及上线前的跟版owner机制和上线后的日志巡检与业务数据自动化监控巡检。这些措施不仅提高了测试的效率和覆盖率,也显著提升了系统的稳定性和质量。在工具体系建设方面:我们引入了接口自动化平台、业务数据巡检监控工具以及效率工具平台。这些工具不仅简化了测试和监控的流程,还提供了更高效和可靠的解决方案,帮助我们及时发现和解决潜在问题。

  未来,我们将继续优化和完善现有的质量保障体系,重点关注以下几个方面:

  1. 智能化测试:引入机器学习和人工智能技术,提升测试用例的生成和执行效率,进一步提高测试覆盖率和准确性
  2. 跨团队协作:加强与其他团队的协作,建立更加透明和高效的沟通机制,确保各团队之间的信息共享和协同工作
  3. 安全性提升:引入安全测试工具和流程,定期进行安全审计和漏洞扫描,确保系统在高效运行的同时,具备高水平的安全防护能力
  4. 性能优化:通过性能测试和压力测试工具,识别系统瓶颈,优化代码和架构设计,提升系统的响应速度和处理能力

  在这个不断变化和发展的技术世界中,我们始终以提升系统的质量和稳定性为目标,不断探索和实践。我们明白,只有不断进步,我们才能在面对未来的挑战时,保持竞争力。我们希望通过分享我们的实践经验,能够给同行带来一些启示和帮助,让我们一起为提升软件的质量和稳定性而努力!

作者:洞窝QA