从缺陷到创新：质量保障的新视角

1.背景：

最近一段时间研发大佬们在积极的治理告警，经过一段时间的治理，现在告警情况已经有了很大的改观，但难免还有漏网之鱼；具体我们可以以下边一个例子来看：

这是一个生产的UMP告警，通过这个告警我们发现XXX这个应用的堆内存使用率为90.18%，超过了设置的告警阈值85%，所以产生了这样的一个告警；那什么是堆内存呢？

1.1.Java堆内存

Java堆内存的定义

Java堆内存是JVM内存的一部分，专门用于动态分配对象和数组。它是一个运行时数据区，从JVM启动到JVM关闭，堆内存一直存在。堆内存的大小可以通过JVM启动参数进行调整，如-Xms（表示java虚拟机堆区内存初始内存分配的大小）和-Xmx（表示java虚拟机堆区内存可被分配的最大上限）。

Java堆内存的特点

动态分配：Java堆内存允许在运行时动态分配和释放对象。

自动管理：Java具有自动垃圾回收机制（Garbage Collection, GC），自动回收不再使用的对象，防止内存泄漏。

全局访问：堆内存中的对象可以被程序中的任何部分访问，只要有对该对象的引用。

分代回收：Java堆内存通常被划分为不同的代（Generation），如新生代（Young Generation）和老年代（Old Generation），以优化垃圾回收性能。

堆内存的结构

Java堆内存通常划分为以下几个区域：

新生代（Young Generation） ：存储新创建的对象，分为Eden区、幸存者区（Survivor Space S0和S1）。大多数新对象首先在Eden区分配，经过几次垃圾回收后，如果对象仍然存活，则移到幸存者区，最终移到老年代。

老年代（Old Generation） ：存储生命周期较长的对象。经过多次垃圾回收后仍然存活的新生代对象会被移到老年代。

永久代（Permanent Generation）或元空间（Metaspace） ：存储类的元数据（如类定义和方法元数据）。Java 8及以后，永久代被移除，改为元空间，并且使用本地内存而不是堆内存。

Java堆内存的工作原理

对象分配:当通过new关键字创建一个对象时，JVM会在堆内存中分配空间。比如：在这个例子中，new Person("John", 25)会在堆内存中分配空间来存储Person对象。

public class Main {
    public static void main(String[] args) {
        // 创建一个对象
        Person person = new Person("John", 25);
    }
}

class Person {
    String name;
    int age;
    //构造方法
    Person(String name, int age) {
        this.name = name;
        this.age = age;
    }
}

垃圾回收：Java的垃圾回收机制自动回收不再使用的对象，释放堆内存空间。垃圾回收器（Garbage Collector）会周期性地扫描堆内存，识别不再有任何引用指向的对象，并回收它们占用的内存。

垃圾回收的过程大致分为以下几步：

标记：标记出所有存活的对象。

清除：清除所有未被标记的对象，释放它们占用的内存。

压缩：（可选）将存活的对象移到堆的一端，减少内存碎片，提高分配效率。

堆内存管理中的问题

内存泄漏：虽然Java有垃圾回收机制，但不正确的代码设计仍可能导致内存泄漏，即对象虽然不再使用但仍然被引用，无法被回收。

内存溢出（OutOfMemoryError） ：当堆内存被耗尽且垃圾回收无法释放足够内存时，会抛出OutOfMemoryError。

性能问题：频繁的垃圾回收会影响应用性能，因此需要优化内存使用和垃圾回收策略。

通过对堆内存和垃圾回收简单的了解（备注，由于不是专业开发可能对堆内存和垃圾回收阐述的不是特别专业，只是作为背景知识补充了解问题😭），我们大概知道上述告警多数是由于内存泄露导致的，那么我们怎么做呢，才能避免此类问题的发生呢？先来看看我们目前的质量保障情况；

2.质量保障

2.1.现有体系

2.2.关键要素

需求质量维度

通过产品输出的PRD文档，研发会输出设计文档，测试对应的也会输出测试用例，这也是对于需求最直观的输出；

过程质量维度

产品会进行需求评审，研发会进行设计评审，测试会进行测试用例评审，三方的目的是拉齐需求，以避免各自的理解有偏差；

交付质量维度

测试会发送验收报告，产品会先进行需求的验收，上线前产品会同步业务验收，业务验收有问题会反馈到产品推进研发优化测试复测，形成循环；

2.3.质量把控

环境治理是有专门的团队负责，不做过多阐述
Diff&CR属于测试左移的范畴，会在改进措施中做说明
监控告警和质量大盘属于测试右移的范畴，也会在改进措施中说明

2.4.交付过程

持续迭代

目前是两周一个迭代，基于这个节奏，去排需求，基本上每个迭代都会排满；

持续集成

主要还是基于Coding集团的代码仓库管理工具▪持续发布▪目前由于特殊性，没有用到集团的JDOS，使用的是自己的发布系统

持续运营

专门团队负责

持续度量

建立线上问题处理群，通过群中Oncall对接

通过保险一线之声进行问题反馈

通过用户满意度评价进行问题反馈

2.5.质量文化

质量&效率基本上就是我们的团队文化，可能也是大部分测试团队的文化，通俗一些就是要测的好还要测的快

3.改进措施

3.1.测试左移Diff&CR

传统的diff&cr基本上我都是通过去让开发大佬开放Coding仓库权限，手动拉取开发分支到本地仓库，进行diff和cr,效率较低，时间成本较高

基于大模型工程化进行CodeReview好处良多，具体接入方式可参照，虚拟账号可自行申请diff&cr ,效果如下，我们发现通过AI CR确实能够帮我们发现一些问题，这些问题可能就是潜在的风险，这样能够补充我们的测试Bad Case从而进行更充分的测试；

3.2.测试右移监控&告警

通过最初我们的案例分析发现目前告警信息确实也存在一部分不完善的情况，只给出了具体的告警信息（当然这个对于专业水平较高的同学也是可以快速定位问题并解决的，但是对于稍微欠缺背景知识的同学比如说不是专业开发理解起来可能就稍微晦涩），所以我对自己所测试的业务告警信息也进行了优化下面是我的一个优化情况，多少对我个人而言我觉得还是有些帮助的😁；

4.未来规划

基于现有质量保障框架下，我会持续探索、持续发现、持续优化，保障业务运转质量更丝滑