测试管理 质量可视化-让数据为质量说话演讲稿 _美柚孔令云_20201121

Mr. null · November 21, 2020 · Last by 阿禾 replied at November 27, 2020 · 2322 hits

质量可视化-让数据为质量说话演讲稿

美柚测试总监-孔令云

建议对照ppt阅读(链接: https://pan.baidu.com/s/1NSip2sH5v1i6BALS8bYdsg 密码: h08h)

p1-2 开场

各位测试的小伙伴们,大家上午好,刚才云层老师讲了很多段子,大家有没有感觉进来的是脱口秀专场啊?讲段子的过程中让大家get到一些测试的点,我觉得非常好,那接下来我们切换到质量保障专场,由我来跟大家分享下美柚质量可视化管理的相关经验,希望对大家有一定的帮助或者启发。

p3 大纲

今天我将从4个方面对我们在质量可视化方面所做的工作进行分享

1 为什么要做质量可视化?

2 质量可视化的数据有哪些?分别具有什么意义?

3 质量数据如何采集,以及应用效果展示

4 最后会谈一谈质量可视化平台未来的展望

p4 个人简介

在正式开始分享前,我先做下自我介绍,我现在在美柚负责测试及质量管理工作。

P5 为什么要做质量可视化

接下来我就给大家分享一下我们做质量可视化平台的初衷。

p6 美柚App,工具->平台

随着业务的不断发展,美柚App已经从一个生理期记录的工具型App成长为涵盖女性经期、备孕、怀孕、辣妈4个身份,包含资讯、社区、电商、直播等业务在内的一个平台型App。

p7 美柚系App

同时,除了美柚App以外,我们还形成了主打育儿的柚宝宝、宝宝记App,主打电商的柚子街App,还有返利相关的返还、羊毛省钱等一系列App产品的产品矩阵。

p8 挑战

在这样的产品研发背景下,对我们产品质量的保障提出了更多的挑战,
外部挑战是:活跃用户多,设备碎片化严重,尤其是Android设备,近年来碎片化更加严重,top10机型总占比只有15%, top100也只有67%,iOS相对会好一些, top10占比达到75%
另外产品根据用户标签、推荐算法、用户设置等呈现了千人千面的样式,同时线上存在多个并行的的AB实验,也增加了测试验证的成本以及难度,还有一点就是多个App版本并存,需要考虑版本前后兼容性的问题

内部挑战是:美柚App涉及经期、备孕、孕期、育儿不同身份以及社区、资讯、算法、广告、电商等不同的业务团队,研发人员几百人,各个业务开发节奏、发版周期不尽一致,而且业务耦合性较高,比如广告会嵌入不同的业务当中,身份与业务也是互相交叉,同时研发数据比较分散,而且App通常以2-3周为一个迭代。

这些都对App质量的保证提出了巨大的挑战。

p9 测试问题

对于测试内部来讲,之前也有很多抱怨,比如:需求经常变更;临时需求很多;马上发版了,老板要加需求;开发提测质量很差;开发提测也比较晚,测试时间被压缩;对上线没有信息,提心吊胆;线上出了问题不知不觉或后知后觉;不知道现场的朋友们是否遇到过类似的问题,有的话,我们可以一起先来看看,是不是可以将问进一步归类,并且通过数据量化的方式来评估问题,比如:

1) 跟产品相关的问题:

  • 迭代周期内,需求变更了多少次?变更率是多少?
  • 哪些是临时需求?临时需求增加了多少次?
  • 老板需求是否有经过评审确认?是否经常性出现?等等 ### 2) 跟开发相关的问题:
  • 是否在提测前有进行自测?
  • 开发的task是否规定了提测时间?是否按时提测了?
  • 是否确定集成测试时间?集成测试时间占研发周期比例多少?
    ### 3)跟测试相关的问题:
  • 上线的标准是什么?
  • 线上都监控哪些质量相关的指标?
  • 线上问题数量,是否符合质量标准?

p10 质量可视化数据及意义

正是为了解决上述研发过程中跟质量相关或影响质量的问题,我们决定做质量可视化。

p11 3阶段指标

大家可以看到这张图里面,我们将整个研发过程分成3个阶段,分别是研发-即质量预防阶段,测试-即质量保证阶段,线上-即质量监控阶段,3个阶段中间会有两个卡口,来控制质量,一个是提测节点的卡口,一个是上线节点的卡口,每个卡口都会定义卡口通过放行的质量标准,比如在提测卡口,会重点关注开发提测的及时性以及提测质量,上线卡口呢,则会关注各类bug关闭率情况以及DI收敛趋势状况,来评估质量风险。

3个阶段中也会制定相应的质量指标,比如在研发阶段:

1)针对产品

针对产品,我们会关注产品的需求变更率指标,针对需求的微小调整是允许的,但我们不希望出现频繁的需求大改以及一些本身不明确的需求就进入开发测试阶段,我们遵循的质量原则是“第一次就将正确的事情做正确”,另外,在上线时间确定的情况下,需求的频繁变更势必会压缩开发和测试时间,从而增加质量风险,所以,我们通过统计需求变更率的指标,一方面减少不必要的变更,另一方面和产品一起持续提升需求本身的质量,让需求逻辑、交互、边界更加明确,从而减少返工造成的内耗;

2)针对开发

针对开发,我们会关注静态代码扫描通过率的指标,比如我们将sql语句规范中的禁止出现“select *”作为强制的规则,扫描出此类bug,就直接提bug,并与开发同学达成一致,此类问题必须修改;

针对开发,我们还会关注bug日清率的指标,bug不能做到日清,通常有两种可能,一个是bug多,改不完,一个是bug难,不好改,这又反映出代码复杂度高、耦合性高、可读性差、可维护性差、历史遗留问题多等一系列更深层次的技术及管理问题;

3)针对测试

我们会关注自动化测试覆盖率、bug一次修复成功率、App打包的成功率,还有App包大小、启动时间、闪退、内存泄漏、卡顿、cpu内存等占用率、耗电量等专项指标;

4)对于线上

针对线上,我们会关注bug漏测率,也就是线上bug与线下bug的比值,还有App补丁包的更新率、后台及api上线回滚率、App闪退、卡顿率以及api性能等线上指标。

p12 采集及应用

有了这些质量数据的指标定义以后,接下来我介绍下我们是如何采集这些质量指标数据并进行应用的。

p13 数据来源及应用

我们的数据来源包括研发管理平台、性能检测sdk、第三方监控平台(如通过bugly、oppo运营后台等获取闪退、卡顿、ANR等指标数据)、elk日志(获取线上api响应时间等指标数据)、持续集成系统(获取App打包、上线回滚等指标数据)、自动化测试系统(获取自动化测试覆盖率,case测试通过率等指标数据)。

p14 指标数据具体来源

这张图展示了质量数据的具体来源,不同颜色代表数据来源于不同的数据源。

比如测试阶段的App专项性能指标,有部分就来自于性能测试sdk,我们通过运行App端的UI遍历测试程序,自动去检测App运行过程中的闪退、卡顿问题,如果发现问题,就通过数据服务接口上报bug到研发管理平台,并将数据存储在数据库中,同时ETL服务会定时同步研发管理平台的bug数据进行存储,并在可视化平台中做汇总、统计及展示应用。

p15 需求管理

接下来我以部分指标为例,分享下我们为了采集这些指标,需要具体做哪些工作:
首先是需求管理,所有需求,不管是业务需求还是技术需求,都需要记录在需求管理系统中,同时比较重要的业务、技术需求会有需求审核的过程,确保需求的质量。

p16 需求拆分task

有了需求之后,开发同学分解需求并拆分成task,预估开发时间,这里面的结束时间将作为提测的时间节点。

p17 需求变更

如果需求有变更,会记录在系统里面,我们需求变更率的统计就是以此为依据进行统计。

p18 测试确认

刚才在结束task的时候有提到,测试人员将会以task结束的时间点作为提测的时间点,如果到时间点没有提测,那么测试人员就会将此任务标记为“未及时提测”,对于已提测的task,测试人员会通过冒烟测试验证该task是否测试通过,同样标记测试结果,这样,每一个task就得到了两个维度的结果,一个是是否及时提测,另一个是测试是否通过

p19 迭代报表

再来看报表,每一天的任务结果我们通过累加,就可以得到当天的提测及时率和通过率数据,这个就可以作为衡量开发质量、进度的很重要的依据;另外,还有一个衡量产品质量变化趋势的值就是DI(defect index,即缺陷指数),每一个严重级的缺陷会定义一个权重,各个严重级bug权重和数量之和即为DI,如图,这是一个迭代周期内,DI的变化趋势,先增加后减少,从图中能看出,质量是逐步趋于稳定的。

p20 阅读报表

那么每个月,我们会出一个业务报表,包含产品需求变更率的情况、开发提测及时率、通过率情况,还有bug日清率以及DI指数等信息,各个业务可以横向对比。

p21 线上bug

针对测试,很重要的一个衡量测试成效的指标就是漏测率,漏测率跟线上bug直接相关,所以就需要先登记线上bug。

p22 线上bug列表

登记的所有线上bug,都会汇总在线上bug列表栏中。

p23 报表

最后,我们会以月、年等维度统计出各个业务的漏测率数据,作为该业务测试团队测试质量评价的重要参考。

p24

刚才介绍了一个业务项目从需求到开发到测试最后上线整个过程中质量相关指标的采集及应用,在这个过程当中还涉及到一些自动化测试的工作以及自动化相关的指标数据的采集及应用。

针对App的性能自动化,我们通过Monkey以及UI遍历程序(已开源在GitHub,大家有兴趣可以下载,地址:https://github.com/MeetYouDevs/UIWalker) ,在UI遍历自动化测试过程中,我们会自动切换用户身份、AB实验等,目前UI遍历的页面覆盖率能达到80%左右,测试过程中我们会利用性能检测sdk自动检测crash、内存泄漏、ANR、卡顿以及主线程非法调用的问题,并通过接口将问题日志上报性能数据处理服务,这个服务对问题日志进行分析、过滤去重、聚合等操作后,将确认是bug的通过调用bug管理系统的接口创建bug,同时,对开发标记为已修复,并3次未再复现的bug自动进行关闭。

p25-27

这几个分别是自动提单上报的crash、ANR、主线程非法调用的bug。

p28

这一张是自动关闭bug的示例,可以看到创建bug的“变更人”是我们的自动化测试程序“exserver”,bug被开发同学将状态修改为“已解决”以后,经程序自动验证bug已被解决,凌晨1:05,该bug给关闭,可以看到变更人是“exserver_auto_close"

p29

上面这张图是自动化测试bug每日的关闭率情况,下面这张图是版本维度的bug关闭率,通常在一个版本迭代中,App的性能问题bug关闭率需要达到90%以上,我们才允许发版,可以看到从779版本到782版本,每个版本的关闭率均在90%以上,783是正在开发中的版本,目前关闭率还比较低,通过在测试环境的这些测试以及卡口约束,我们线上的App crash率维持在一个相对较低的水准。

p30 卡顿

这张图是自动化测试检测出来的卡顿信息列表,按卡顿次数做了排序,打开详情可以看到卡顿的具体信息。

p31

前面我分享了App性能自动化测试以及数据采集的过程,接下来分享几个线上数据监控的具体例子,这张图是线上95分位api性能,每天我们都会从elk中将前一日的访问日志捞出来做分析,对于95分位超过300ms的接口,针对性分析原因,并配合开发一同优化。

p32

这两张图是美柚App Android版线上卡顿率、ANR从2019年1月1号截止到现在的趋势图,可以看到卡顿率下降非常明显,目前稳定在一个非常低的水平上,ANR中间虽有波动,但总体还是下降的一个趋势。

p33

这张图是我们可视化平台的看板页面,用户也可以定制显示自己关注的指标到看板。

p34 绩效

这张图是开发人员的绩效统计图表,包括开发人员的提测及时率、通过率,bug日清率,线上线下bug数等等,实际上,这些指标一开始是我们测试对开发的一些要求,我们认为只有开发自身重视质量,提测质量有一定保证,整个产品的质量才能得到更好的保障,后来呢,这些指标逐渐被各各个开发小组接纳,作为开发同学绩效考核指标,写入了okr里面。

p35-p36 质量可视化平台未来展望

最后,我介绍一下我们质量可视化平台未来的展望,目前,我们正处于由1.0向2.0升级的阶段,1.0阶段是我们测试自己建设,包括质量指标的定义、质量数据的采集以及应用推广等均由测试自己建设,随着质量可视化对于质量提升效果的显现以及对于研发绩效考核的帮助,产品和开发同学也逐渐会提出一些需求给我们,来共同完善质量可视化平台,比如产品同学提出的需求有:业务需求评审通过率;开发同学提出的需求有:开发工时统计、人均bug数统计等等。除此之外,2.0版本中还将增加基于线上监控数据的智能预警功能,更有效的对潜在的质量风险进行识别并采取相应的风险防范措施。

p37 slogon

我们质量可视化平台的slogon是:让数据为质量说话,捍卫产品的质量以及用户体验,提升研发质量以及研发效率。

p38 个人微信及专栏

最最后面,打个广告,我个人的微信号,大家可以扫码关注交流,同时我的技术专栏《接口测试之代码实例21讲》(https://www.nowcoder.com/tutorial/10032/index) 11月初在牛客网正式上线,随专栏开源了5个GitHub项目,包含接口示例的代码、接口自动化测试框架代码以及一个简易电商网站的代码,我也列出了有专栏的地址,大家有兴趣可以阅览,也欢迎大家转发。

大家的印象里,可能觉得测试总监是不是就不做具体的技术了,实际上,我的主要工作可以用3个词6个字概括,就是“技术”、“流程”、“团队”,技术在我的工作里面永远是排在第一位的。

我的分享完毕,感谢聆听!

共收到 10 条回复 时间 点赞

这个可视化平台是基于tapd二次开发的吧

质量实践的工作做的很踏实,顶一个

linpengcheng 回复

tapd是研发管理平台,用来管理story、task、bug以及看板,质量可视化平台通过调用tapd提供的接口获取story、task、bug等数据进行统计、分析、展示
实际上,如果有自己的研发管理平台,效果可能会更好,可以更方便的获取相应的研发数据

几许风雨 回复

谢谢肯定!

Mr. null 回复

所以前置条件是整个团队要有一套统一的项目管理平台 ,且大家都遵从在这个平台上进行需求 任务 bug的工作流运作。只有在数据准确且状态及时变更下,才能进行下一步的数据化度量平台建设。这在中小型公司里还是任重道远啊😂

质量度量👍

感触颇多,有很多同样的问题在困扰着我;也在为公司从0到1搭建无人值守质量平台,借鉴下,准备一步步投入实际应用👍

linqiangyun 回复

有问题可以随时沟通!

if you can't measure it , you will can't improve it

需要 Sign In 后方可回复, 如果你还没有账号请点击这里 Sign Up