iSQE对话金融行业第三期直播活动圆满落幕，本期直播邀请到了中国人寿保险股份有限公司研发中心高级工程师熊军军老师进行了《保险信息系统稳定性测试实践》专题分享，聚焦保险行业，围绕无侵入在线压测、混沌工程故障演练、自动化测试等方向进行探讨交流。

以下是熊军军老师演讲的文字版内容。

各位朋友晚上好，我是中国人寿寿险研发中心熊军军，很荣幸能有这样一个机会跟大家一起交流《保险信息系统稳定性测试实践》。

今天我分享的主要内容包括5个部分。第一个部分是信息系统稳定性测试的简介，我们来聊一下相关的概念、内容及我们的工作思路。第二、三、四部分我们给大家汇报一下中国人寿在稳定性测试方面的一些具体的实践，主要包括无侵入在线压测、混沌工程故障演练和自动化测试。最后我们来一起展望一下稳定性测试能力的发展。

一、系统稳定性测试简介

首先我们一起看一下什么是系统稳定性。我认为百度百科给了一个很好的解释——系统稳定性是指系统要素在外界影响下表现出的某种稳定状态。其中有三个含义，

含义一：外界变化不至于对系统的状态发生显著的影响。假设我们这家店，今天来了很多客人，这些客人不至于把我们的门挤变形，也不至于把我们的门挤垮。这其实是一个容量规划的概念，我们要通过容量规划去评估到底能够承载多少，在线压测是一个很好的评估手段。

含义二：系统受到某种干扰而偏离正常状态，等干扰消除后，能恢复起正常状态，则系统是稳定的。也就是说万一我们的门，真的被挤变形了，我们能够弹性恢复，如果我们的门真的被挤垮了，我们可以很快新建一个门，这就涉及到我们的弹性和自愈。保证弹性和自愈及时奏效就要需要通过演练，所以我们在第三部分会给大家介绍混沌工程故障演练。

含义三：系统自动发生或容易发生的总趋势，如果一个系统能自动地趋向某一状态，就可以说，这一状态比原来的状态更稳定。就像水从上游流到下游，它从一个稳定的状态变到了一个更稳定的状态。其实我理解这个地方主要是讲架构演进的概念。我们每次架构重构之后，需要用自动化的方式做一个全面的回归，保障我们的功能能够正常运行。所以我在第五第四部分会给大家介绍一下系统自动化测试相关的概念。

影响系统稳定性的因素主要有哪些？我们认为一般有下面5个部分。

第一是功能缺陷、第二是性能缺陷、第三是我们的设备问题、第四是人为操作的问题、第五是安全问题。今天我们会聚焦在前面4个部分，第五个部分安全问题其实是一个单独的领域，后面如果有机会我们再探讨。

第二点大型信息系统面临着较高的稳定性风险。首先高业务的复杂性给我们的系统天然的带来了高复杂性的属性，一旦它复杂就带来了很多的变量，这些变量就给我们带来了较高的稳定性风险。

大家可能会问“分布式架构，不是很好的解决了稳定性的问题吗？”我们是不是可以这么来理解？分布式架构在一定程度上降低了稳稳定性的风险，因为通过解耦，我们形成了单个的应用单元，它的可测性和可管控性大幅提升了，确实在一定程度上降低了稳定性的风险。

但是分布式系统整体性的运行风险仍然不容忽视。为什么这么说？我们从一个系统的整体来看，会发现系统的调用关系是非常复杂的，特别是在当今开放式API理念下，会呈现出一个复杂的网站结构，就像图中一样，稍有不慎就牵一一发而动全身，造成生产事故。所以我们最近看到大型信息系统稳定性风险时有发生，比如：2020年Google，2021年美联储、DD和Facebook；2022年7月初有两件事，其中国影响最大的一件事就是日本KDDI电信发生了一个故障，影响超过48小时，波及3800多人，涉及到电信、银行、物流等等行业。日本总务相认为该事件属于《电气通信安全法》规定的“重大事故”。可见，大型系统面临着稳定性的风险，我们开展稳定性工作非常有必要。

前面讲到开展稳定性工作的必要性，我们现在看一下，开展稳定性工作的充分性。我们认为开展信息系统稳定性工作正当其时。主要是基于以下三点：

第一是国家经济政策层面要求稳字当头，稳中求进，相信这些大家都有深刻的理解。

第二是公司业务的高速发展需要稳定的系统支撑。主要是从日常经营和重大业务活动两个层面来看。

50. 日常经营层面，我们绝大部分业务已经线上化，特别是在疫情情况下，系统的支撑作用尤为明显。所以大部分公司对于IT系统稳定运行要求分厂高，可用率指标基本都在99.9%以上。
50. 重大业务活动方面，对公司起着越来越重大的作用，比如：我们的各种促销，客户节活动，某些公司在开展重大活动的那几天营业收入可能占了当年营业收入中很大的比值，所以公司对信息系统的稳定性是高度重视的。

第三是科技条线自身高质量发展的内生动力的要求。大家现在可能有一个体会，现在功能性需求可能已经不是科技条线主要的痛点，非功能性需求日益成为科技条线主要痛点，特别是稳定性需求。也就是说我们已经占领了一座山头，只有占领另外一座稳定性的山头，才可以说我们的科技做到了高质量的发展。所以从这几个角度上讲，我们现在做系统稳定性工作正当其时。

大家都加大了稳定性保障工作的力度，那么有没有一个整体的框架来指导我们规范的开展这项工作？中国信通院，今年发布了一个系统稳定性保障能力标准框架，就像上图左边所示，同时中国人寿寿险研发中心这些年也在开展稳定性保障能力的规划。

我们比较左边和右边两张图，可以看到稳定性保障工作的思路基本一致，也就是说从软件研发周期的设计、开发、测试、发布等环节去想点子、想办法、去提升。这里面既有我们传统的三板斧——可监控、可灰度、可回滚，也有新提出来的三板斧——自动化部署、无侵入在线压测或者说在线压测、以及混沌工程故障演练。

右下角显示了我们中国人寿寿险研发中心这些年来稳定性保障工作的一个发展轨迹。在2018年我们重点开展监控能力的建设，2019年开展灰度能力的建设，2020年我们做自动化，2021年做无侵入在线压测，今年我们开始做混沌工程故障演练。

上面讲了一个整体的稳定性的能力，在测试方面，稳定性测试能力该如何去定义它？我们把这个图聚焦一下。会发现左边这个能力框架里面已经定义了“测试与评估”能力域，主要包括流程管理、覆盖率和通过率、容量评估以及故障演练几个方面的工作。

相应的右边，我们做的工作跟它基本上是保持一致的，也就是说通过测试平台来实现流程管理；通过自动化测试来保障我们的测试覆盖率和通过率；通过无侵入在线压测来做容量评估；通过混沌工程故障演练来开展相关的演练工作。两个方案的一致性，增加了我们的信心，也使我们的思路更加清晰。

所以接下来就给大家汇报一下我们稳定性测试工作的思路。

上图从下往上看我们有三层，其实我们可以把焦点聚焦在第二层，能力层。我们的思路是建设4种能力，包括无侵入在线压测能力、混沌工程故障演练能力、自动化测试能力以及数字化测试管理能力，来实现保稳定、提质效、优效能的目标。

大家可以看到保稳定始终是我们的第一目标，同时我们的生产部门也是放在第一位的，也意味着我们最好能够直接对生产部门赋能，保障我们的生产稳定。以上就是我们的一些工作思路。

二：无侵入在线压测实践

下面给大家汇报一下我们公司在无侵入在线压测方面的实践工作。我们知道在无侵入在线压测之前，其实有两类传统的压测手段，第一是测试环境压测，第二是生产环境的有侵入压测，这两种压测都有一定的局限性。

测试环境压测的主要的问题是测试环境和生产环境不一致，包括程序不一致，配置不一致，数据不一致以及我们操作人员不一致。

生产环境的有侵入压测是指生产环境通过修改我们的源代码来识别我们的压测流量，进而正确的路由我们的压测流量，保证压测顺利进行，而不污染我们的生产环境。这个方法它主要的影响有三点：

第一是不统一，各系统各自为战，缺乏统一的标准，这样协作起来会比较困难。

第二是技术难共享，技术推广的难度大，这样很难实现全链路在线压测。我们知道一个业务流程要真正压测全面，必须要走到全链路，否则风险隐患始终存在，今天这冒一个，明天那冒一个，永远都是不放心的状态，所以这是很不好的。

第三点是不安全，我们缺乏统一的压测安全管控的措施，比方说压测开关，一旦出了问题能不能统一关掉？白名单是不是可以控制住链路走向？我们需要走的走，不需要走的不走。压测前的检查以及压测中的资源监控，压缩后的数据检查，都缺乏相应的机制来保障。

我们无侵入在线压测的工作的目标是什么？大致可以用1+1+N来概括。一个平台就是讲我们要建设一个无侵入在线压测平台，能够支持我们在对源代码无侵入的情况下开展压测。第二个就是一个流程，我们知道无侵入在线压测的影响面非常大，关联团队非常多，涉及到开发团队、测试团队、部署团队、生产保障团队、网络组、平台组等等，如果缺乏一个统一的流程，职责不清晰的话，轻则是执行不下去，重则会造成生产事故，所以必须要有一个流程。有了一个平台和一个流程之后，我们就可以基于这个平台和流程来支持我们N个场景的在线压测。那么主要有哪些场景？比如：长险出单，短险出单，培训学习和APP登录等等这样的业务场景在线压测。其实大家最后可以看到还有一个“重大技改”场景，在近一段时间，我们会发现有一些系统的模块发生了重构，比方说我们做了信创，大家会非常乐意用到无侵入在线压测这个手段，在生产上验证技改前后性能的变化情况，这是一个新的应用方向。

下面我们简单来看看“一个平台”是什么？图上方就是我们的无侵入在线压测平台，它主要包括两个部分，第一是压测执行模块，我们可以把它理解成一个云化的JMeter，它就是施加压测流量的。第二个就是压测链路管理模块，是基于打在应用中的探针，管理我们的被压测链路，来实现在线压测的。简单来讲，主要的流程可以通过绿色箭头来看，我们的压测流量首先到达了业务应用A，业务应用A上的压测探针会识别压测流量，然后把它写到影子库、影子日志、影子topic（这些影子存储用来存储保存压测数据，与正式业务数据隔离开），进而把它传到业务应用B，业务应用B进行业务处理之后开始落影子库，这样就实现了我们整体的压测流量的路由，不影响正式库和正式业务数据，但又是走着同样的业务应用通道，这样就可以验证我们正式业务链路的性能。

我们再花一点时间来看一看最核心的压测探针部分。第一点是基本原理，是基于Java字节码技术实现，它的核心是修改JVM中已加载的字节码。（我们不是去修改源码，而是去修改JVM里面已加载的源码，所以实现了对源代码和开发人员的无侵入，也不会造成源代码的互相混淆，进而造成更多的问题。我们只是修改字节码，在其中加入压测流量处理逻辑，来实现压测流量路由到正确的链路、写入到影子存储。

第二点是操作的对象，我们知道压测的核心目的就是想把我们的压测流量进行路由，让它进入到影子存储和我们的正式流量区分开，而流量的路由一般是通过特定的中间件来完成，比如Tomcat, Redis, Kafka, Oracle等，所以理论上需要且仅需要增强这些中间件就可以了，而不需要去全面梳理所有业务代码，这就使无侵入在线压测的可行性大幅增加。

下面我们写了一个伪码，大家可以参考，看看压测流量是怎么通过增强后的逻辑来路由的，绿色部分逻辑被增强。

业务链路的基本单元是应用，所以我们首先要把各个应用配置好，把应用配置好了之后，就可以把应用串起来组成一个链路，进而开始进行压测。应用配置就跟我们搭积木一样，每一个应用模块都有对外的接口部分，比如：我们对于任何一个应用，我们都要去配置他需要调用的接口，影子库、影子消费者，影子日志、缓存和挡板。我们举个例子，远程调用的接口，为什么要配置白名单？假设这个应用要调下游的某一个接口，我需要把它配置在我的白名单里，这是安全考虑。因为业务的形式是很复杂的，我们可能换一个投保要素就走到另外一条链路去了，另外一条链路没有安装探针就会出现异常，所以我们通过白名单来确保不走到预期外的链路，进而保障我们的安全。同样的道理，配置影子库、影子消费者、影子日志和缓存都有相关的技术考虑，主要是为了做正式数据和业务数据的隔离，挡板我们后面会继续介绍。

我们通常把一个完整的压测链路逐层分向下分解为业务流程、业务环节、业务活动、应用，即一个压测链路包括一个或多个业务流程，一个业务流程包括多个业务环节，依此类推。。

比方说我们一个长线投保链路，我们把它对应到一个业务流程，包括了登录、选择产品、填写客户信息、上传投保单、核保、缴费等多个业务环节。其中，“登录”业务环节包括查询用户状态，校验密码等业务活动。每一个业务活动其实就是一个API的调用，每一个API的调用对应着我们下面图的一个子链路，这个子链路涉及多个应用，也就是一个API调用可能涉及多个应用。上面我们已经把应用配置好了，包括应用相关的存储，所以这样逐层下来我们就把整个链路串起来了，接下来就可以开始进行压测。

在压测执行的过程中，我们提供了类似于阿里PTS的全自动化的在线压测功能。我们可以在线编辑脚本、设置线程组、设置压测参数等，在压测过程中，可以实时看到整个业务压测的压测数据，包括TPS、响应时间、成功率、资源利用率。TPS、响应时间、成功率等数据都是从我们的压测引擎来的，资源利用率、告警和失败的信息是通过压测探针传到监控模块的。

平台介绍完了，接下来我们来看看如何设计压测流程。

首先需要提到的是设计流程的原则，“安全优先、严谨规范、统筹协作”。其中安全优先是第一位，我们在设计任何一个具体技术方案的时候，永远是考虑安全优先，即使一个更安全的方案会导致工期延长一个月，我们也选择这个方案。主要流程步骤包括：方案设计、链路梳理、环境准备、系统配置、链路调试和压测实施，详细内容如上图。

下面我们就讲一下在实践的过程中，我们遇到的几个难点。

• 第一个是在制定压制目标，大家说压测目标会有什么难度？其实还里面还是有一些小技巧。在上图中黄色的线，可以作为历史的峰值，蓝色的线作为本次压测期望的峰值，比如我们可能会在这次设定压测的期望峰值是历史峰值的两倍，在链路压测出来后，最短板应用所能支撑的吞吐量位置，就是红线的这个位置，它应该高于我们的期望峰值。那是不是这样就可以保障整个链路没有问题了呢？不是的，因为链路上的某个业务环节可能出现拥挤。比方说有时候登录环节会因为多种业务叠加（包括投保之外的业务）出现登录拥挤，一旦出现这种情况就没有办法开展后续操作了，针对这种情况，单独对我们的登录环节拿出来再做在线压测，评估一个更高的值来满足要求。所以我们在线压测的目标有全流程的目标和单环节的目标。

• 第二个是影子库，我们在压测过程中，有很大一部分工作量都在影子库上，它花费的时间可能远远比我们想象的时间长。主要的两个问题，第一是如何创建影子库，第二是准备多少铺底数据。理想情况当然都是如上图绿色部分，尽量符合实际业务情况，但在条件不具备的情况下，可以考虑用一些折中的办法，比如可以新建一个数据库实例，可以准备一定量级的数据，这个量级可以通过测试环境梯度压测的方法来预先获取。

挡板有两个作用，第一个作用正如上图左侧，屏蔽不希望被执行的业务，比如我们不希望发送短信，不希望花这个钱，发短信这个环节出性能问题的风险也不大，所以我们要把它屏蔽掉，这一块我们就用入口挡板把它挡掉就好了。

上图右侧“执行希望被执行的业务”就比较难理解，我们举个例子，我们这个影像审核，因为我们很难构造符合真实情况的影像数据，所以我们业务如果流转到影像审核的话，影像审核就会失败，失败了后面的环节就压测不到。这时候在“影响审核”应用出口部分加一个挡板，把这个审核结果给它改成正确就解决这个问题了。这样好处是：我们真实的压测到了影像审核的业务逻辑，验证了该应用模块的性能，同时又不阻断整体的流程。

此外，还需重点关注数据隔离，数据隔离是保障我们压测安全的重要手段。

我们要保障安全压测，必须要做相应的风险预案，例如，对生产系统过载、探针影响正常业务以及业务数据被污染等情况，我们都制定了相应的应急预案，具体如上表。

平台配置好，流程执行完，接下来就可以开始做正式压测了。我认为主要有2个成效：第一是能够准确评估系统容量，保障重大业务活动。我们可以看到左边这个图，可以准确看到长险投保、短险投保、登录、签到、学习、活动等这些场景的最大容量。我们可以很有信心的开展重大业务活动。

第二是可以真实的开展性能指标对比验证，支持重大技改。我们从右边这张图也可以看到，测试前后以及优化前后，性能都会大幅的提升。

存在的不足：第一是业务场景有待丰富，比如有些时候不知道外部调用我们的接口是调用了多少次，我们一般认为一次投保只需一次核保调用，但是很有可能外围调用方改一个投保要素就会调用核保一次，那么最终下来一次投保可能调了几十次核保，超出我们的预期，所以业务场景还有待丰富。第二是链路的深度和广度有待进一步的扩展。

三、混沌工程故障演练实践

接下来我们看一看混沌工程故障演练实践，为什么要开展混沌工程故障演练实践？因为我们的系统太复杂，影响因子太多，在线压测等技术只能解决一部分问题，我们必须引入不断的引入新的办法来解决稳定性的问题。

解决系统复杂性引起的问题，有什么好办法呢？有一句话我觉得讲得很好，“软件可以用新技术实现弯道超车，系统复杂性引起的故障该如何解决？复杂性科学研究者、Cynefin 认知框架的提出者戴夫•斯诺登认为——理解复杂系统的唯一方法，就是与之互动”。

故障演练就是一种互动，但是传统的故障演练有两个困难。第一个是有些场景我们很难真实模拟，比如服务宕机，网络丢包。第二是触发某些故障的成本比较高，比如数据库连接池、内存泄露，单纯通过压测是相当耗费人力物力的。

这就要求我们引入新的故障演练技术，那就是混沌工程故障演练。

混沌工程是一种规范的、受控的、高效的故障演练技术。这里面规范和受控是比较重要的，因为我们必须保证安全。我们通过注入故障观察系统的行为，发现系统的弱点并确定优化策略，建立我们处理混混乱场景的一个信心，这个技术对我们的人员、系统和流程都有很好的提升价值。

我们混沌工程故障演练的目标，可以用1+N+30来概括。1也是建立一个平台，准确的模拟故障，销毁故障；N是对我们的若干个重点产品进行混沌工程故障演练，要求达到30分钟内解决各类故障。这就要求我们能够及时告警、快速定位、限时解决，这就是我们的整体目标。

我们的平台是基于ChaosBlade开源的工具来建设的，图中可以看到，上面是控制台，下面是一个工具，右边是被测系统。按照平台化的思路，工具层除了ChaosBlade工具外还可以不断的扩展引入一些新的工具来实现我们新的故障模拟能力。

我们具体的实践大致是如图中左侧9个步骤。我们先看一下演练目标。

我们的演练目标就是定位在三点。第一我们的监控有没有，快不快，准不准。第二我们的告警有没有，快不快，准不准。第三，我们的预案有没有，快不快，行不行。监控有，也很快，但是给的信息不准是不行的，比如我们集群有20个节点，到底是哪个节点出问题，能不能够准确的告诉我？预案确实是有，但是它就是不奏效，也是不行的。

第二个是场景编排，我们的场景编排是严格按照故障发生和处置的逻辑去设计的。通过右图可以看到，发生故障之后，首先想到的可能就是重启。重启之后发现解决不了，怀疑是这个版本的问题，抓紧回退。回退之后还解决不了，只好做熔断，还不能解决问题，我们只好牺牲一部分用户的体验，开始限流。这是一个故障处置的大致逻辑，限流之后把波峰消下去，逐步稳定之后，可以开始放流量，整个过程不应该超过半个小时，这是我们的一个场景设计的思路。

场景设计好之后，分析起来确是很费工夫。首先我们要分析故障场景的影响范围，它的爆炸半径到底有多大，到底会影响哪些系统？第二，我们的故障场景的监控手段有没有，缺哪些？我们的应急预案有没有，缺哪些？所以我们会发现，往往还没有开展演练，在场景分析阶段就能够发现很多系统设计或应急预案的问题。

接下来我们看一下故障注入，上图可以看到故障注入和销毁的执行过程。这是通过我们的混沌工程平台来实现的。在此我想重点提两点请大家关注：第一点要深入的理解我们的故障模拟的能力。比如CPU满故障能力，它有14个子参数，哪个子参数代表什么含义？是不是跟我们的需求是一致的？要详细理解。第二点要深入理解应急预案作用。其实我们参与到这个工作的人非常多，大家对应急预案的理解都不一样，比如限流和熔断，不同的人可能有不同的理解，最大连接数 、最大请求数、最大排队请求数。在不同的工具如 Tomcat、 Redis、MySql中，它的含义都不一样，我们需要做的是深入的理解这些参数，跟合作的人员之间达成共识。只有这样才能够真正的积累经验，沟通一致，把事情做好。

最后我们看一看演练的总结，这是我们对第一个系统进行故障演练的效果。主要发现了9类问题，最常见的是监控没有接入、监控信息不准的问题。但是也会发现限流操作不奏效，加上了限流之后性能衰减超过预期等问题，最后分析发现是它的限流的机制有问题，设计的不好。通过故障演练，我们能够更全面的去发现问题，降低生产的风险。

四、自动化测试实践

我们的自动化测试主要包括三种能力： App测试能力、web测试能力以及接口自动化测试能力。我们结合了开源的工具，已经引入了一些成比较成熟的工具来共同来实现这个事情。我们在实践的过程中解决的几个难点的问题是：

• 第一APP和web的应用的调用的问题；首先从驱动层mPaaS和Selenium封装了一些控件和工具，基于工具又封装了一些页面，基于页面又封装一些应用，在这个应用之间通过代码的调用实现了APP之间的互相调用，web之间的调用和APP和web之间的互动调用。
• 第二是人脸比对；我们现在有一些人工智能的场景，给自动化测试带来一些困难。例如，为了实现一个智能的人脸比对的自动化的流程，我们进行了一些探索，上图中我们可以看到，中间有一个手机，后置摄像头对准了显示器的屏幕上的证件，前置摄像头对准的是人脸的模型，这样进行人脸和影像件的比对，完成整个人脸比对的过程
• 第三是手写签名，我们是基于滑动操作以及字库中定义的文字相对的笔画顺序来进行，同时支持在书写的时候自动的进行旋转和缩放，来完成手写这些场景的一些操作。
• 第四是在接口自动化这一方面，主要是在云效平台进行用例的开发，这是统一的开发模式。但是我们可以支持在不同的流水线上调用营销的机构自动化用例，实现统一情况下的个性化。

我们做了这么多自动化的工作，如何来衡量它的价值？其实我觉得除了提高效率、节约资源之外，我们应该回归到它的本源，考察最重要的价值，就是如何保障质量。关于如何来保证质量，经常会提到一个问题，测试保障质量最常用的度量指标就是缺陷，但是自动化测试作为一种回归测试手段，其实它发现缺陷的数量应该是比较少的，难以体现出价值。我们一些业内人员也就此进行交流，大家都在想自动化测试还有什么办法能够体现它的质量价值？其实我认为，“确认ok”就是一个很重要的价值考量维度。

我们自动化测试验证了几万个接口，保证这几万个接口没有问题，我们才有信心上线运行，否则就会始终提心吊胆，所以“确认ok”本身就是很重要的一个价值。基于此我们就设计了一些度量指标，发现缺陷方面，是逃逸率和有效性。“确认OK”方面是通过覆盖率、执行率和成功率。

如何去提升我们覆盖率、执行率和成功率，进而实现自动化测试的价值。我们采用度量指标先行的方式，也就是先建设度量能力，然后一边建设自动化一边度量。我们可以看到上面这张图，我们每天更新各个开发部门的覆盖率、执行率和成功率数据，定期把相关的结果发给各开发部门，激励大家提升自动测试水平。

以上就是我们在三个领域具体的实践情况，

五、稳定性测试能力展望

最后跟大家一起展望一下稳定性测试能力的发展趋势。

我想稳定性测试能力可能要经过4个发展阶段，第一是标准化，第二是自动化，第三是开放化，第四是数字化。

所谓标准化，比如我们的无侵入在线压侧以及混沌工程故障演练。首先要明确各方的职责，完善操作流程，这样能够实现常态化的压测和故障演练，保障工作能够持续化的开展。对于接口自动化，我们要统一开发规范，统一测试管理，实现统一下的灵活。

还有自动化，因为现在我们的自动化的程度还不高，所以后续我们要实现自动化的造数，自动化的检查环境，比如每次压测之前，不需要再投入那么多人，去人工的检查环境，我们能不能自动的检查环境，自动的执行，自动的出所有的报告，提升我们的工作的效率。

在具备自动化的条件之后，就可以开放化，从自动化走向自助式，也就是大家可以自助式的开展性能压测。每次晚上升级之后不用请测试人员专门支持了，凌晨升级完之后，开发人员就可以自己来测，甚至在开发环境下大家都可以随时自己开展性能测试或者接口自动化测试，从帮你做，变成你来做。

数字化阶段，我想到两个方向，第一是测试管理的数字化。测试的质量、效率、产能，都希望通过一些数字化的指标来度量，进而推动过程改进，通过数字化来提升管理能力。其实我们现在正在开展相关的工作，把我们的产能也好，我们的效率也好，以及我们的质量都通过可视化的方式展现出来，例如：接口自动化覆盖率、执行率和成功率就能推动各开发部门提升自动化测试水平，各类型测试耗时就可以促进测试团队提高处理能力。

第二个是技术的智能化，包括很多同业先进做的比较好的，比如精准测试，性能问题智能分析等等一系列智能化的手段，能够更进一步提高我们测试工作能力，从而进一步共同推进产品质量的提升，进而更好的为我们的业务服务。以上就是我的分享内容，谢谢大家。

演讲嘉宾

熊军军，中国人寿保险股份有限公司研发中心高级工程师，毕业于中国科学院自动化所，就职于中国人寿保险股份有限公司研发中心，先后从事产品研发、架构设计、质量管理工作，熟悉保险销售管理及销售支持业务，具备数据治理和高可用架构设计经验。现负责质量中心测试公共能力团队，着力建设质量保障工具及平台，助力提升信息系统稳定性。

资料获取

演讲PPT分享：点击：链接 获取演讲PPT（百度网盘提取码：iSQE）

演讲视频回放：想了解更多精彩内容，点击：链接，查看直播回放