PerfMa

IT系统稳定性保障专家

请至少选择一个您感兴趣的方案
发送验证码

感谢您的提交!

我们会在2工作日内与您联系

产品

全天候为您的IT系统稳定运行提供有力保障
即刻开启您的IT系统稳定性保障之旅

XSea 压测产品

多地域高仿真流量模拟、端到端流量染色与数据隔离、全链路压测风险熔断

XSpider 监控平台

无侵入实时性能分析、低性能开销、动态采样、根因定位

XLand 性能分析平台

探针接入简易、性能开销低廉、补足离线/在线分析能力

解决方案

沉淀PerfMa多年的业务经验,提供金融、
证券、快消、交运等多个领域的解决方案

金融

依托全链路压测平台的能力,建立一套完整的性能保障体系

电商

基于平台的建设及专家咨询服务,进行统一平台管理,实现工具、框架的统一

连锁快消

实现多维自动化能力,协助构建标准化的性能测试及回归体系,提升测试效率

交通运输

以数据驱动,形成标准化测试能力,保障系统的正确性、性能容量及可靠性

公司动态

全方位汇集PerfMa大小资讯
寻找对您有帮助的事件

PerfMa新闻

PerfMa公司最新动态或消息,为您提供关于PerfMa公司的第一手资讯

PerfMa活动

为您提供PerfMa线上线下精彩活动回顾及预告

关于

和优秀的小伙伴一起共事
不负初心,用技术的力量创造梦想

关于PerfMa

强大的专业团队、企业资深专家,致力于为企业提供性能领域的全方位解决方案

加入我们

浓厚的工程师文化、靠谱的发展平台、舒适的办公环境,拥抱变化中快速成长

社区&开源

汇聚IT系统稳定性领域问题诊断调优精英
共建IT系统稳定性领域问题诊断调优标准和能力

专注性能领域垂直社区,几十万开发者在这里交流性能问题,分享技术干货,是开发者们学习和成长的乐园。


访问HeapDump社区 >

为终结性能问题而生的开源插件容器,将定位/解决各种性能问题的工具适配成插件,通过相互联动组合,一键解决您的性能问题。


访问XPocket官网 >
精效如何带来1+1>2的价值
2021-09-08

小麦.jpg
张晋筠
PerfMa高级技术顾问
文章来源:MTSC中国互联网测试开发大会

“宝剑锋从磨砺出,梅花香自苦寒来”

【挑战无处不在】

我们的挑战

2.jpg

这是一个大家非常熟悉的工作流程图,上面的是测试管理人员非常熟悉的测试流程,下面的是测试开发人员的工作流程,在这张流程图里面涉及到了3个角色,一个是测试管理人员,一个是测试人员,另外一个是开发人员,这三个人员,其实已经面对了3个不同的挑战:

第一个挑战,是测试人员对于技术方面的挑战,虽然目前我们在技术方面已经有了很多的突破和创新,但面对自动化技术的时候,我们还是不知道如何把它高效的应用出来;
真正的测试技术要在自动化效率上面去提高,在效率提高的同时,我们在不同的企业或着不同的项目当中会发现,前期投入的时间会非常长,那么如何去缩短这个时间,是对测试人员的挑战,
第二个对于开发人员,则是业务价值链熟悉度的挑战,当每次新产品上线的时候,生产故障还是频繁发生,发生之后我们则会跑去问测试人员,怎么复现这个故障,没有测试人员可能开发人员都不知道如何复现,或者复现效率特别低。

而管理人员,尤其在面对多个供应商的时候,如何去评定这些供应商的测试质量,在这些很庞大的团队当中,又如何真正的去落地可持续性,把团队的协作性带动起来,把测试人员的积极性带动起来。

呐喊:我们要质效—优先找准相对分母

这也是我们在QECon大会上面提出的质效这样一个主题,在实验中大家的技术都已经非常厉害了,甚至达到了巅峰的状态,而实际现实情况则是:堆人堆机器加时间,对于这种现状,其实我们应该深刻地反省一下,怎样才能真正的解决这个问题,所以我在左边画一个价值模型图,那这张价值模型图里面,大家可以看到,类似于金字塔结构,这个其实是漏斗形的,这个漏斗它每一层都有相应的分母。
这边要优先的去找相对的分母这个方法论,在每一个分母找寻的方法,有不同的技术和实践的方法,需要我们的测试人员不停的去找,然后把这个每一层的分母找出来之后,会形成产品和系统这个最大的分母。那么这个分母里面包括了相应的覆盖率,相应的数据,对于我们后续质量的评估和评价,构建评价体系,都会提供相应的数据。这个价值的模型图会一一把它展现出来,我们在做落地方案的时候也是要不停的去找这个分母。在接口测试的时候我们可以去找接口测试的分母。

我们在代码层面如何去找代码覆盖率的这个分母,这就是今天要分享的这个,可能偏向于理论或者方法论,所以这一句非常的重要:有了方法论和理论知识但没有执行力,一切都是无用的。

【精效组合拳】

下面来给大家分享一下我们的一些落地的持续解决方案。这个实施落地解决方案,我列举了3个不同类型的客户,这3个不同类型的客户,都是真实在客户现场遇到的比较典型的客户:

解决测试团队全体人员自我驱动不足的问题

第一类客户,总结为装备传统,他们有自己的一个测试体系和测试中心,但对于产品的质量要求和敏感度不是很高,大家的工作都是一成不变的,测试工作和开发工作成为了各自的孤岛。大家都在这个一成不变的工作环境当中很难提高自己的积极性,像这种问题,我们就要改变这种单点测试的方法,需要把它可视化。这就用到了我刚刚提到的精确,就是能够准确的显示出业务的全景链路图,这样才能在产品真正上线之后,从测试、开发到维护人员都能够深刻地找到问题;

这里我们就用到了精确,能够准确的显示出业务的全景链路图,这样才能在产品真正上线之后,从测试、开发到维护人员都能够深刻地找到问题。

3.jpg

如上图,把整个测试的闭环全部都罗列了出来,当然这个测试闭环是我们内部团队的测试计划,在这个测试闭环里面,可以看到,业务关联了用例,用例关联了代码,代码关联了系统,每一个环节,测试团队里的所有人员都是可以一目了然的看到。在用例层面,功能测试人员可以进行设计,在代码层面,开发人员又可以进行排查,到了系统层面,我们又可以通过运维人员的报警来告诉运维人员,上线之后出现了什么问题,我们整个从线上到线下,打通了一个闭环,这对于整个测试流程来讲是非常有价值的,同时也带动了我们整个测试团队以及开发团队的自发意识和积极性。

解决自动化前期转换工作量大的问题

第二类客户,则是装配专注,这个装备专注指的是他们有一定的自动化的沉淀技术,并且有标准的案例库,在这种情况下,它对回归测试的需求是快速回归,这种诉求非常的高,这在一个项目时可以做到快速响应,但是如果这个企业里面有N个项目的话,投入的成本在前期是非常高的。我们在前期做过调研,在做传统自动化实施的时候,前期基本要投入一个人在可行性分析里面,可行性分析有可能是接口、UI等,这样的分析过程之后,再自己去筛选自动化,筛选完之后再去做数据准备。有些系统是比较简单的,功能人员可以参与一下,但是有些系统是比较复杂的,功能人员也比较忙,像这种情况,自动化测试人员,就需要付出2倍的工作量,既要研究业务知识,又要去做自动化的转化工作,这是非常耗时的。为了解决这个问题,我们就用到了流量回放,流量回放的目的是为了节省我们在前期的业务梳理,以及我们前期的分析工作。

这里则会用到精简,即简单化自动测试技术,测试人员应该专注于业务价值链用例的设计,然后把测试化用例技术应用成为一个方法和手段。

4.jpg

关于PerfMa的流量回放,驱动者是测试执行人员,然后通过测试,前端进行正常的执行,后端进行服务抓取,把所有的接口信息全都抓取完,而这种抓取过程当中是需要抓取有效信息的:

第一个,在每个串联整个业务流程的时候,必须要抓取到交互的被测系统,因为我们要全链路的展示;

第二个,要去抓取这些业务场景,让这个业务场景串联出来的话,是给测试人员去看的;

第三个,就是要抓取在整个业务场景当中,测试数据是怎么生成的,这一块非常的重要,因为我们在做自动化优化的时候,测试数据是我们的重点,所以我们在落地实施方案当中,需要把流量回放完全的融入到了整个测试的过程,当然,这在时间上大约可以节省2.5个人。

解决持续回归测试的问题

第三类客户,是非常先进的客户,可以把他们归结为装备精良,他们对于产品质量敏感度非常的高,因为他们迭代发布的周期非常的快,所以在测试技术的多样性上是有非常高的要求的,对于可持续性集成测试的要求也是必不可少的,这种高负荷的运作团队,技术创新是非常重要的。

面对这样的客户就会用到精益,即测试管理人员如何能够可持续性,并且提高真正的执行效率,来缩短交付时间。

5.jpg

我们一般都是采取合作孵化的模式,提出了双驱动回归自动化测试技术,双驱动回归自动化测试技术其实也是一种流量回放,但是这个流量回放,它的驱动分线上和线下的,也被称为发布前和发布后,发布前这个驱动是测试人员,发布后这个驱动是真实的用户故事驱动。在发布前我们的测试人员把我们的用例库完善,然后在每次迭代版本之后,可以从标准用例库里面去智能的推荐出本次迭代版本要回归的执行案例,这样对回归执行的效率会大大的提高。在执行过程当,可以快速的去推进整个的交付的时间,在上线之后,我们会遇到生产故障,会遇到无法复盘的问题,这种问题我们可以去抓取客户流量,然后和线下的案例做比对,如果存在差异,则会自动补充到我们标准案例库里,这样就形成了一个闭环:从发布前到发布后,这样的闭环使我们整个测试流程成为一个循环状态,从而使整个测试内容非常的丰满充分。

以上3类客户,我们在落地实施的时候,都用了一套组合拳,这个组合拳,并不是说每个客户都要用到精简、精益或精确,我们会根据每个客户现场最终的痛点来给他们做组装式的解决方案。第一类客户他们的技术是传统的,我们可以用精益;第二类客户,我们可以用精简,第三类客户,我可以用精确,也就是说这3个组合拳打出来之后,对于线上的企业来讲的痛点都是可以一一解决的。

【边执行边定策】

战术思路四步走

在如何通实现流程和规范价值最大化的思路当中,我们一般是按照四步战术来制定的,其实在做质效体系建设的时候,也是按照这四步来做的,这四步可以归结为三个闭环:

第一个闭环,是技术的闭关,也是我们目前正在进行的,比如说:Ab的技术或者持续集成的DavOPs,这都是技术的闭环;

第二个闭环,是整个组织结构的闭环,使我们这个整个组织结构从开发测试所有形成闭环;

第三个闭环,是数据的闭环,当我们把前期的技术闭环和人员闭环全部都组建完之后,最后必定是需要去评估测试质量和测试价值的,这种数据是需要以报表的形式来呈现的,所以这个叫做数据的闭环。

持续内建工程,笨马打造的体系化“X”系列明星产品概览图

6.jpg

上图是PerfMa打造的体系化“X”系列明星产品概览图,我们可以把这个概览图分成三大部分:

第一部分,是测试的持续集成通过需求、开发、测试和运维这3块来进行测试的闭环。

第二部分,我们是在做技术的闭环,在这边我们是在质量管控、功能模块、性能和可靠性方面,不停的去找相对分母,不停的在进行补充和优化。

第三部分,是紫色的部分,因为我们要面对不同的客户和不同的企业,不同的客户它的痛点是不一样的,所以我们必须要把他去组件化,不同的客户,可能会用到第一个组件或第二个组件,这样灵活的组建方式,可以为现场的客户达到最优的方法,解决他们最大的痛点。

以业务价值链为轴心,测试、开发、运维真正协同工作

在以上的案例里面,大家在工作中,都是各自的孤岛,等产品上线之后,才开始担心如何去复现问题,那么我们为什么不能在产品上线之前就互相的进行督促或者是互相进行监督呢,所以,我们建立了围绕业务价值链为轴心,由测试人员来编写案例,之后这些案例能够通过我们的这个代码双向追溯的功能,来把代码和用例进行关联,关联之后,系统就会把链路一一的展示出来。对于我们的运维人员来说,也能够可以清晰的看到每一个应用是不是会出现问题。
这种闭环的图示里面,我们最重要的测试人员可以在重要的模块去关注他们重点的东西,开发者人员可以通过代码可以去立刻的找到我们的用例,通过用例,他会知道全景的链路图是什么样的,对开发人员的定位也非常的快速,这就是我们整个以业务价值链为轴心的组织上的一个闭环。

解决质量评价可视化,需从质量数仓模型入手

7.jpg

当我们所有技术手段全部都已经满足,这个分母会越找越多,可能还会在这个大的漏斗形里面不停的去添加,我不知道大家有没有想过我们在做完这些数据之后,堆积了这么多的数据,但是这些数据在什么时候是有用的,或者什么团队才会看这些数据,开发团队对代码覆盖率比较注重的,功能团队也许对需求变更或需求评审这种用例通过率比较在意,所以在我们这个漏斗里面,起了个名字叫质量数仓,他会把我们所有取得这些数值,在这里面进行处理和加工,等加工完之后,我们就可以形成相应的报表,给到相应的人员或相应的团队,这样就会有一些指导意义,并且告诉他们那些是需要进行优化的。
在质量数仓里面会遇到两个难点:

第一个难点,就是怎么样定级这个资格线,其实我们在实际的实施过程当中,真的是很难定级这个及格线的,这个及格线每个企业都是不一样的,有些企业它本身的基础架构不是很稳定,所以这个及格线不能拍脑袋,上来就说60多或者90多这样一个数值,必须要结合实际的场景;

第二个难点,是如何聚合不同纬度不同数量级的数据。

如果把这两个难点全部解决完之后,肯定会形成一个质量报表,这个质量报表不管是对测试管理人员还是对于开发人员或者是对测试人员,甚至运维人员或者市场人员,都是非常有价值性的,他们看到这个报表之后,会有思路有方法去做优化或者去改善。这样我们的质量数仓模型制造出来的数据才是我们最终要形成的闭环重点。最终数据闭环形成完之后,会有一个报警系统,我们叫风控系统,在这个风控系统里边,我们有大量的数据,这些数据给相应的人员进行报警或者处理化,我们会有几种方式:一种的话就是人工处理,还有一种是自动触发,在质量评估的系统里再加上预警规则的引擎和质量数仓的引擎,有这两个引擎在,我们最终会把相应的报警发送给这些测试人员或者开发人员、运维人员,让他们有这种警示性,提高他们的效率和质量。

【实施心得】

以上内容是我们在实施落地解决方案的时候,怎么样来利用这一套理论方法和技术实现的案例,后面则是我们在整个实施过程当中的心得以及未来的展望:

在实施落地解决方案的过程中,我们遇到了很多的困难,因为我们遇到的客户,遇到的问题,不是一个点,不是一个客户,而是多个客户,然后我们遇到的企业也不是一个企业,而是银行保险等等这些多种企业,那么如何才能为这些企业和客户提供能够解决他们问题的解决方案呢?很多不是技术上的问题,而是需要帮他们去挖掘他们真正的痛点,当他们真正的痛点解决完了之后,我们才能把我们的价值最大化,去不断的去优化他们的技术,或者是这个过程。

我们大概分了3个阶段:
 
第一个阶段是建设阶段,我们在建设阶段其实就是找分母的阶段,这个找分母的阶段,我们要结合当前企业的痛点,缺少什么,缺失什么,然后我们针对这个痛点去帮他们找到这个分母,然后通过再找一个分母,用什么样的技术来完善这个分母,那这个过程是需要一定时间和周期的,是需要一个叫内建,就是我们构建内置的一个过程;

第二个阶段,当我把这个分母和技术实现落地之后,必定会到一个分析定策的阶段,把这种数据做到能够可视化,可分析。让测试人员、管理人员或开发人员能够可视化地去分析我们的这个测试过程是不是要优化,开发过程是不是要进行改进,甚至告诉我们的运维人员,我们整个的运维过程当中的监控是不是达到了相应的指标,告诉我们是因为什么原因,甚至是告诉我们市场人员,这个产品是不是稳定,这样我们在分析定策的阶段,是把数据真正的落地到我们各个部门。各个组织结构;
 
最后,关于未来的一些思考,相信前面的技术我们已经达到一定的高度之后,落地的数据和分析一定也会逐渐的完善和优化起来,在分析和优化过程当中,必定会对质量数仓进行进一步的深究和智能化,质量数仓的未来,也一定会成为研究的一个方向。

请至少选择一个您感兴趣的方案
发送验证码

感谢您的提交!

我们会在2工作日内与您联系

业务咨询电话:4008-717-107

公司联系电话:0571-8500-1801