解决痛点：二方包稳定性测试实践

by 云岚

业务背景

“二方包升级难！”

“XXX升级后，项目起不来了！”

“这次就升级了XXX，外网运行就报错了！”

问题解析

推动应用升级二方包困难，应用本身升级困难，这是19年H1在推动中间件二方包升级过程最大的槽点，那么升级过程究竟碰到了什么问题呢？从上面的截图看主要归类为2点

  • 应用编译过程就报错
  • 中间件依赖的二方包和业务依赖二方包的版本冲突，这个被依赖的二方包本身是不兼容升级，比较容易出现这个问题
  • 中间件二方包升级的版本不一致，比如有些功能需要hunter和soa配合升级
  • 中间件二方包的不兼容升级
  • 应用运行后报错
  • 运行期的二方包问题，这种问题会比较难以发现，问题表现为各种FoundError&Exception

我们不妨看看背后类的选择和加载做了什么工作

1.对于java应用来说，一般是使用maven来做依赖管理的，maven的特性说明3点

2.完成类的选择，类是如何加载的呢？

class字节码通过ClassLoader被转换成内存中的对象，这个转换过程采用按需加载的原则，即用到该类才加载

JVM运行实例会存在多个ClassLoader，这些ClassLoader是如何加载类的呢？

  • JVM内置3个重要的ClassLoader
  • BootstrapClassLoader
  • ExtensionClassLoader
  • AppClassLoader
  • ClassLoader加载类遵循双亲委派模型

所以，二方包升级过程碰到的ClassNotFoundException、NoClassDefFoundError、NoSuchMethodError、ClassCastException、LinkageError问题都可以解释了，加载了非预期的二方包导致的各种冲突和异常

二方包稳定性测试

有了上面的铺垫，回归主题，二方包稳定性测试特性在哪里呢？一样的方面就不再赘述了如研发单测、监控手段等

兼容性融入测试流程

我们已经了解了二方包在升级过程中存在的问题，那么有什么方法来降低升级的成本，提前测试二方包的兼容性呢

  • 运行前
  • 白盒静态检查
  • 采用了基于javassist的开源工具japicmp，静态检查本次升级的二方包的改动，包括new+modify+delete的class、method、constructors
  • 将静态检查过程已经通过moon融入到测试流程中，帮助测试识别潜在的风险

版本依赖检查

maven的依赖树非常好用，确认升级的各个中间件版本一致

运行期

  • 前面提到，有些兼容性问题只有运行期才会发现，暂时没有一劳永逸的方法，提高接口测试的覆盖度，通过接口测试来触达可能的潜在问题
    上面提到的测试手段，本质并不能解决中间件二方包和业务二方包冲突的问题，因此中间件团队已经在调研实现类隔离的方法，从本质上解决这个问题

探究二方包测试覆盖率

业界主流的测试覆盖率工具jacoco用于应用的测试覆盖率的收集，这个能不能收集二方包的测试覆盖率呢？答案是可以的！此处感谢@石塘一起验证二方包覆盖率过程

  • 方法
  • 准备三件套
  • 原理清楚了，需要做的是把对应的二方包数据整合

  • 将二方包测试覆盖率已经通过moon融入到测试流程中
  • 理想是丰满的，现实然并卯，运营运营

性能测试

会有同学疑问，二方包是怎么做性能测试的，二方包性能测试的关注点在哪里？这个问题可以从一个P0故障开始说起...

  • 首先需要说明，中间件的二方包使用是基于应用的，所以性能测试也是基于应用的。目前在做的二方包的性能测试主要是soa和hunter，测试应用是网关site & 被测应用soatest
  • 详细的测试方案见测试方案 & 20191107网关异常问题验证
  • 测试路径

测试指标，重点需要关注内存，进程内存和机器内存的使用情况，内存使用逻辑非常复杂。如果在测试发现问题，需要根据问题具体分析，这里说的是二方包性能测试，就需要关注有没有因为二方包引起类似这个故障的内存泄露问题

性能基线

  • 由于基础设施的问题，像网关这样大并发的性能基线暂时不能自动化，手工测试的过程也比较复杂，好在网关也不是隔山差五的升级版本应用的中间件性能测试是可以做到的，因此专门建立了一个二方包测试repo用于各种中间件的测试，融入发布流程
  • 故障演练
  • 演练目标
  • 测试rds集群/es集群/redis集群发生不可抗拒故障时和故障恢复后，tddl/es client/rops中间件层面行为是否可靠
  • 测试rds集群/es集群/redis集群故障恢复后，应用的自动恢复情况
  • 针对rds集群/es集群/redis集群不可抗拒故障，产出对应BP，帮助用户缩短定位问题的时间，提高解决问题的能力
  • 测试rds集群/es集群/redis集群发生不可抗拒故障时和故障恢复后，tddl/es client/rops中间件层面告警详情
  • 演练案例
  • 数据库中间件全链路故障演练
  • es 故障演练201909
  • redis 故障演练 201903

    业务同学实际故障演练时，可以review对应的测试结果，参考故障发生时的解决方案(重要，重要，重要!)

关注我们

酷家乐质量效能团队热衷于技术的成长和分享，几乎每个月都会举办技术分享活动（海星日），每半年举办一次技术专题竞赛分享（火星日），并将优秀内容写成技术文章。

我们尽可能保障分享到社区的内容，是我们用心编写、精心挑选的优质文章。如果您想更全面地阅读我们的文章，请您关注我们的微信公众号"酷家乐技术质量"。