精华内容
下载资源
问答
  • 本文为大家介绍持续交付体系在高德的演进落地。 2. 持续交付 正如前序中所总结的,我们需要构建一套持续交付体系,从而保证在质量不下降的前提下,在业务价值交付上有更进一步的突破。那么我们先了解一下什么是...

    1. 前序

    对于工程团队来说,构建一套具有可持续性的、多方面质量保证的交付体系建设,能够为业务价值的快速交付搭建起高速公路,也能为交付过程中的质量起到保驾护航的作用。本文为大家介绍持续交付体系在高德的演进与落地。

    2. 持续交付

    正如前序中所总结的,我们需要构建一套持续交付体系,从而保证在质量不下降的前提下,在业务价值交付上有更进一步的突破。那么我们先了解一下什么是持续交付以及集团在持续交付的建设上有哪些指引。

    **2.1 持续交付概念
    **

    引用Martin Fowler大师在2013年时发表的文章,对于持续交付的概念有如下的解释:Continuous Delivery is a software development discipline where you build software in such a way that the software can be released to production at any time.

    在上述文中,可以提取几个关键词:

    • 软件开发的标准化准则
    • 可以做到随时随地的发布

    什么情况下就可以算是团队达到了持续发布的状态呢?Martin Fowler大师也给出了标准的答案:

    • Your software is deployable throughout its lifecycle
    • Your team prioritizes keeping the software deployable over working on new features
    • Anybody can get fast, automated feedback on the production readiness of their systems any time somebody makes a change to them
    • You can perform push-button deployments of any version of the software to any environment on demand

    那么基于以上的观点,我们在建立自身的持续交付体系时,需要抓住以下几个重点:

    • 标准化流程流转
    • 当有变更进入时,能够快速、准确且自动的得到反馈
    • 解决部署问题的优先级高于功能开发
    • 一键发布

    **2.2 集团的持续交付建设
    **

    从理论基础上对于持续交付有了初步了解后,我们从集团层面了解一下是如何定义持续交付的能力,并且对于持续交付提出了哪些效能改进目标,参见阿里技术公众号的文章 《如何衡量研发效能?阿里资深技术专家提出了5组指标》

    文章中将持续价值交付的能力拆分为3个层面的5组指标,从不同角度对持续价值交付能力进行了衡量。

    有了上面专业层面的衡量指标,那我们是如何定义一个优秀的持续交付衡量目标呢?

    管理学之父德鲁克说:“如果你不能度量它,就无法改进它”。度量帮助我们更深刻认识研发效能,设定改进方向,并衡量改进效果,所以想要进行效能提升的前提是先能够识别交付过程中的质效瓶颈。

    因此,集团在基于部分BU的优秀实践下提出了2-1-1的愿景。

    • 1小时的发布前置时间是对于基础设施能力的要求,需要保证当达到交付标准后,通过交付流水线能够达到1小时内的打包、部署和验证的能力;
    • 1周的开发周期涉及产品需求拆分、研发QA协作能力、持续测试以及快速反馈能力方面提出了挑战;
    • 2周的需求交付周期是以前两项为基础,不仅是涉及到产研测三方,还包括其他协同部门的通力合作才能保证业务价值的快速交付。

    3. 持续交付在高德

    在基于集团愿景的指导下,反观现有高德服务端的交付流程,我们发现在整个流程中,存在很多效率上的竖井,这些效率问题汇总起来,便会成为整个交付流程上的效能瓶颈,进而影响业务价值的尽早交付。

    我们先从一个整体的Milestone来回顾一下整个持续交付所经过的一些重要时间节点:

    • 2018/08 构思与工程能力建设:项目启动阶段,工程效率团队与业务线明确了持续交付的目标,并启动了工程能力建设
    • 2018/12 初步落地与试点:项目试点阶段,完成了初步的持续交付流程搭建,并在一个项目中验证流程卡点以及质量标准的基础能力验证。最终建立了基础的质量标准以及降低流程中的耗时
    • 2019/04 推进接入与平台优化:项目推进阶段,持续交付项目质量项优化并在高德的服务端的6条业务线中进行推广,在9月份完成6条业务线以及11个应用的持续交付落地
    • 2019/09 复盘与展望:项目推进总结,对整个推进过程进行复盘与后续持续交付如何落地进行复盘与展望,整体产出业务推进中出现的问题以及改进方法
    • 未来:在交付流程上进行贴合业务线的微创新,并对效能瓶颈点进行纵深挖掘。结合各纵向平台进行纵深挖掘,例如:覆盖率与精准回归、云歌Case平台、代码扫描平台等

    通过milestone的展示,对于高德持续交付体系的演进有了大致的了解后,下面对于落地的过程以及改进的内容进行一下详细的梳理。

    3.1 接入持续交付前的交付流程

    首先先介绍一下在接入持续交付体系之前,高德的服务端是如何进行迭代的开发与上线的。

    与大部分互联网公司一样,我们将软件的交付拆分为多个周期,进行迭代式的交付,以便增量式的进行用户价值的交付。上图描述了一个正常迭代周期内的研发、测试以及发布的流程,我们可以拆分为以下几个方面:

    1.迭代周期起始于代码库的变更

    2.在功能开发完成后,研发通过CI系统进行冒烟测试验证,保证服务可以正常启动以及基础功能可用

    3.在规定的提测时间前,研发将Feature分支通过CR和MR合并到迭代分支,部署到日常环境进行提测

    4.QA在收到提测邮件后,参与到日常环境的测试中

    5.当日常环境测试完成后,QA会进行测试报告的产出,并确认日常环境测试通过,可以发布到预发环境

    6.部署到预发环境后,会进行流量回放等测试,并最终通过线上的灰度验证,最终发布到正式环境

    通过上述的图片和描述,我们可以看到在看似完善的软件交付过程中,却仍然存在如下一些质量、效率问题:

    1.需求堆积提测、发布:

    目前高德服务端大部分服务采用的是固定迭代周期进行需求发布,规划到迭代周期内的需求,无论需求大小,均需要等到迭代提测时间点进行提测,在迭代的发布窗口进行发布上线。在这种模式下,好的一点是有固定的版本节奏,整体迭代规划性比较强。但是由于提测、发布窗口固定,从而也带来了整体业务价值交付上的等待。因此,需要通过需求拆分来降低需求内部的耦合性,通过改变研发、QA的开发测试模式来降低需求提测中间的竖井等待,从而提升业务价值交付的效率。

    2.质量标准不透明,无法及时反馈:

    从代码提交一直到最终产品发布,一般情况下,会经历日常、预发、灰度、正式发布几个阶段,每个阶段均有每个阶段需要重点解决的问题以及对质量上的要求也不尽然相同。目前结果的收集汇总和通知都是通过跟版人进行人工收集和统计,并邮件通知项目成员。这样所有的标准控制都是有每个版本的跟版人进行把控,存在信息不透明,反馈不及时的问题。通过质量项标准的建立,以及大盘结果透明和及时的通知,能够解决沟通层面的低效以及在传递过程中信息损耗,从而提升沟通效率,并且避免沟通中的误解。在解决了当前透明化和及时通知的问题后,我们需要进一步从以下两方面进行优化:

    将通知进行分类以及优先级处理,降低通知带来的负面影响

    通过信息内容优化,辅助业务进行问题的快速定位与排查

    3.部署与流程流转过程需要人工参与:

    对于持续发布流程来说,有人工参与的地方势必会影响到其中的效率。所以我们将部署和阶段流转拆分为两个方面看:

    阶段流转:结合上述的阶段标准,通过程序来计算是否能够满足当前的质量情况是否可以进行阶段的流转,从而排除人为因素以及在阶段流转中的耗时,做到准确

    部署:提取相应环境的配置信息,结合Docker化,将打包、部署、健康检查等一些列活动转换为机器的标准化执行,通过标准化来避免人为参与所造成的误差或部署失败的问题

    4.多机房正式发布验证人工监督:

    目前在应用的正式发布流程中,由于涉及的机房和机器数量较多,业务上会进行分批验证,每发布完成一批机器,研发会通知QA进行这批机器中部分机器的抽检(部分自动化测试),在这其中也存在着效率上的问题。所以如何节约每次上线过程中的人力损耗,也是在追求效能极致上需要解决的问题。

    上述的每个细节的问题,都在我们通往快速业务价值交付的道路上设置了障碍。因此,为了达成更早(快)的交付业务价值的目标下,我们必须要在交付效率、质量标准以及结果快速反馈这几方面的进行优化。

    3.2 持续交付在高德的落地

    基于上节拆分出来的4方面的问题,从工程角度来说,由于迭代的排期,需求的分解与拆分需要进行长期的实践与规划,并且依赖于产、研、测、项乃至于其他部门的支撑,是一个需要进行逐步探索和调整的过程。所以我们将着眼点放到后3方面的建设上,期望在短期内先建立起快速发布的能力,清除在交付过程中效率低下的点。

    那么在解决效率问题的建设上,借助于集团提供的发布流程以及较好的部署能力,我们将目前拆解为如下几个维度的抓手:

    依托于集团的发布流程,在持续交付体系中建立与集团发布流程对应的标准化流程流转机制

    建立服务端质量标准体系,拉通质量标准,去人工化

    打通各环节的快速反馈机制,并对发布流程进行管控,让变更结果随时可见

    降低发布过程中的人为参与,让整个发布流程做到全程无人值守

    通过下面持续交付流程图,我们通过接入后的流程图中看一下以上4个抓手是如何串联起整体高德持续交付流程,并且这几项是如何在高德服务端交付流程中进行落地的。

    建立标准化的流程流转机制

    FY19高德服务端发生的线上问题中,其中由于变更或发布引发的问题占比约12%。通过这组数据,我们期望能够通过建立一套完整的交付流转流程,实现对于变更的控制和管理,降低或避免此类问题的发生。

    基于以上立论,我们结合当前服务端交付特点,首先先确立以集团标准发布流程为试点,打通整体持续交付流程;其次,针对各应用中不同的需求,例如:需要性能环境、覆盖率环境等,结合流水线配置,将整个持续交付的流程流转进行优化;最终沉淀为各服务的标准化流程流转机制。通过这种先僵化,后优化,再固化的方式,最终在服务端落地了多套标准的交付流程,避免了在交付环节上的遗漏,以及不规范的操作。

    拉通并落地服务端质量体系标准

    在高德现有的交付流程中,整体的质量保障手段大部分是在日常阶段进行的,在迭代交付的过程中,各项质量保障手段执行了哪些,执行结果是什么,目前还是通过QA人员进行人工问题收集与汇总,并判定阶段结果的通过与否。在这种情况下,会出现由于跟版人交替导致的质量项遗漏,以及质量标准难以把控的情况。

    所以基于这几方面的问题,我们希望通过用机器把控替代原有的人工把控的方式,通过建立标准化的质量模板,来避免整体执行标准不透明,执行结果无沉淀的情况。并且,通过拉通标准,也进一步的规避掉了非重点服务质量检查点遗漏的情况。

    通过与业务团队的沟通,我们在第一阶段将现有服务端的质量保证手段进行拆分,提取了在不同阶段中相对重要的12项质量项,通过机器监督替代原有的人为统计的方式。具体覆盖了如下几个维度:

    打通各环节的快速反馈机制,并对发布流程进行管控,让变更结果随时可见

    当建立起有效的质量体系后,在各阶段有了质量要求以及准入准出标准,解决了信息收集方面的问题,那么接下来我们要思考的就是如何将收集上来的各种信息,有效的反馈到项目中的各个干系人,以便进行后续的决策支撑,并且当未达到阶段准出标准时,有效的控制项目的阶段流转。

    我们将问题拆解为两方面看,一是有效反馈、决策支撑,二是流程流转的管控。

    从有效反馈、决策支撑方面看:

    在接入持续交付之前,各业务线的针对不同类型的自动化测试任务,大部分都有通过Jenkins或测试用例工程反馈结果的通知。但是此类反馈有一个致命的问题,就是通过单项反馈无法纵观全局,不足以支撑后续的决策。

    在接入持续交付后,除了原有业务上的反馈机制,平台提供能针对当期版本的整体状态全览,可以通过平台随时观测到当前版本是否达到可发布的状态或者仍然存在哪些不足。将两者结合起来后,针对项目执行人仍然可以通过原有反馈机制了解到单点的质量结果;对于跟版人、一线、二线管理者这类需要纵观全局的角色来说,通过质量大盘,可以有效且明确的知道当前版本与待发布状态的差距,并支撑后续决策以及调整关注的重点

    从流程管控方面看:

    在接入持续交付之前,可部署的产物无论是否经过阶段验证,都可人为的部署到任意环境下,虽然灵活性比较高,但是也存在一定的质量风险。

    在设计持续交付流程时,对于灵活性以及规范性的取舍方面,我们也与业务同学进行了讨论。从全局看,为了避免流程不规范引起漏测或其它线上事故,最终确定在初版时先保证流程流转的规范性,从而降低灵活部署上所带来质量上的风险。平台通过集团实验室插件与集团的部署发布系统打通,当阶段中存在质量项尚未达标的情况下,阻止发布流程进入到下一阶段(环节)。

    当基础的持续交付流程落地后,为了满足业务上对灵活性的要求,目前我们也在尝试通过自定义流水线来进行多环境的分发与部署,从而在保证主要阶段流转有管控的同时,增加部署的灵活性,以适应不同的业务形态。

    降低流程发布过程中的人为参与,让整个流程做到全程无人值守

    我们知道,线上环境部署的复杂程度要远高于在日常和预发环境的部署。由于部分业务线,线上的机器数量众多,且分布在不同机房,为了保证部署时的服务可用性,线上部署时会将上千台机器拆分为多批次进行部署。

    在接入持续交付前,为了保证部署后服务的可用性以及对质量上的高标准要求,在每批次部署完成后,QA都需要针对当前批次进行全批次验证或抽测验证,当验证通过后,再进行下一批次的发布以及后续验证。虽然验证本身是通过自动化脚本进行验证,但由于机器和批次比较多,整个发布和验证流程会持续数小时,存在较大的效率问题。

    在了解到业务上此效率瓶颈后,通过打通上下游系统,集团标准流程、集团发布系统以及原有业务的线上验证工程,针对不同业务的发布场景,进行发布验证策略的配置化。通过感知部署时的消息,获取当批次部署的机器列表,依据各业务的验证策略配置进行自动化的验证。并且结合线上阶段的报警监控,当某批次发布验证出现问题后,系统可以第一时间定位到具体是哪一批次中的哪台机器发布出现问题,帮助业务进行部署问题的快速定位。

    持续交付体系的业务架构

    4. 落地效果

    整个持续交付体系建设,目前在高德服务端落地已经有一段时间了,截止到目前为止:

    业务线覆盖:整个持续交付体系已经覆盖了高德服务端大部分重点业务

    各阶段质量项建设:12项

    正式发布阶提效:50%~90%

    在获得以上成果的同时,除了上述量化指标外,更有价值的是隐含在背后的研发、测试习惯上的变化。从研发、QA和项目主动发起的缩短项目周期,到QA对于质量项上提出更多的诉求等等,无一不感知到大家对于尽早且高质量的交付业务价值这件事情的重视。当然对于更早(快)的交付业务价值这个目标还有一定的差距,这个也是后续我们与业务线需要共同解决的问题。

    5. 持续交付的未来

    有人将持续交付形容为在价值交付上的高速公路,持续交付的落地,标志着价值交付到用户的快速路已经建立完成。但是最终是否能做到更早(快)的交付业务价值,还取决于在这条快速路上行驶的车辆。

    根据这个理论,我们除了要保证这条高速公路上不出现坑洼的同时,还要兼顾车辆本身的能力,以及车辆的性能。因此,在车辆出发前,我们更需要通过对车辆的车况进行检查,保证在高速路上行驶的车辆不会因为自身的原因提不起速度。

    5.1 车况检查

    目前,已有的持续集成系统,仅能够保证车辆在这条路上是能开起来的,车况的检查都是在上了高速后才开始的(大部分的质量保证手段是部署到日常环境后才开始)。所以基于上面描述的指导方针,我们需要尽早的做检查,并且需要做更全面的检查(质量保障手段左移)。

    基于这个目标以及结合集团内其他BU的优秀实践,后续我们希望能通过代码门禁的手段,尽早落地这类全面的检查。若要将代码门禁落地,无论是对于工程效率团队亦或是业务研发与QA团队,都有着不小的挑战,我们需要做到以下的转变:

    • QA

    质量保证的同期化能力建设

    质量保证的稳定性与耗时优化

    • RD

    研发提交代码流程的改变

    单元测试能力的建设

    Code Review的常态化落地以及规范总结

    • 能力支撑

    代码覆盖率,业务场景覆盖率的支撑

    代码合并的门禁管控能力

    代码扫描结合CodeReview的总结的落地

    当逐步完成以上任务的落地后,能够消除批量交付业务价值交付中相互等待的时间,并且也能够保证车辆在持续交付这条高速路上行驶得更快更稳定。

    5.2 车辆性能提升

    前面车辆检查可以说是在车辆上路之前的检查与保障,将质量保证手段左移到研发阶段。相对的,我们希望通过车辆性能提升的方法,在车辆上路后,能够让车辆行驶提速更快,拉高速度的上限。

    • 纵向测试能力提升

    精准回归:通过感知代码的变化,推导出代码变动所影响的Case,让质量保障更为精准且耗时更少

    场景覆盖:结合线上流量回放,通过代码覆盖、场景覆盖进行查缺补漏,让质量保障更完整

    问题定位:结合失败用例,快速的进行问题定位与反馈

    同期化能力:结合云歌Case平台,通过接口定义进行测试代码与研发代码同期化编写能力的加强,以及降低Case编写和维护成本方面的探索

    降低数据干扰:基于高频、隔离和用完即抛的理论实践,降低日常环境的数据干扰,让质量保证更有效

    • 与线上数据挖掘结合

    大数据分析:

    利用线上日志分析,产出线上真实场景模型,降低压测平台语料准备耗时,场景筛选上做到精确、高效

    大数据运用:

    结合线上真实场景以及场景覆盖率,构造线下回归Case集,降低业务回归Case维护成本,提升Case有效率,并且能够快速定位问题

    利用场景回放,以及记录回放中间产物,解决在单测时场景构造问题

    随着持续交付快速通道的搭建完成,期望通过以持续交付体系为契机,在多个纵向维度进行深入挖掘,并完善整个持续交付体系,最终在更早(快)的交付业务价值的前提下,能够有更高的质量以及更低的人工成本,保证市场竞争的先机,让高德在激烈的竞争中优势更为明显。


    双11福利来了!先来康康#怎么买云服务器最便宜# [并不简单]参团购买指定配置云服务器仅86元/年,开团拉新享三重礼:1111红包+瓜分百万现金+31%返现,爆款必买清单,还有iPhone 11 Pro、卫衣、T恤等你来抽,马上来试试手气  https://www.aliyun.com/1111/2019/home?utm_content=g_1000083110

    原文链接
    本文为云栖社区原创内容,未经允许不得转载。

    展开全文
  • 质量体系调整方案 原因 业务不断增加,使得系统复杂度不断增加,回归测试流程越来越长。而对于质量、稳定性、性能以及快速交付能力的要求会进一步提升。 如何成为更好的高效能团队,使得稳定性不因为交付吞吐量的...

    质量体系调整方案

    原因

    业务不断增加,使得系统复杂度不断增加,回归测试流程越来越长。而对于质量、稳定性、性能以及快速交付能力的要求会进一步提升。
    如何成为更好的高效能团队,使得稳定性不因为交付吞吐量的提升而下降,同时让整个团队共同担负起质量的责任,是从去年以来,我们一直希望去做到的。
    很显然我们需要进一步提升自动化测试的程度,提升自动化的覆盖面,进一步清晰化统一化自动化的技术体系,为未来的测试标准化平台化做准备,使得我们可以从大量手工测试、质量与研发体系关联不强,逐渐到质量共责、提升自动化,到慢慢的测试自动化(自动化测试与测试自动化的区别),我们还有很多路要走,但事实证明传统的模式要推进这样的质量改革效能是很低的。
    我们需要跳出原有框架,重新审视我们的文化和愿景,制定新的方针与方案,并且不断的优化,才能让质量让测试更进一步,使测试不仅是测试,而是完善提升坚固我们质量体系的核心关键岗位。
    随着我们组织高效能化的提升,产品的设计、实现和发布会由不同组织更高效地实现,因此QM(质量管理)成为来将不同的环节与组织衔接在一起纽带。
    我们要以价值链为主导,价值链中的每个组织都可以实现自我价值的最大化,价值链的起点是需求,终点是客户,环环相扣,不断迭代优化。

    长期目标

    我们的整个质量体系将像TQM进行转变,TQM(Total Quality Management)全面质量管理,是对一个组织以产品质量为核心,以全员参与为基础,目的在于通过让顾客满意和本组织所有者及社会等相关方受益而建立起一套科学高效的质量体系,从而提供满足用户需要的产品的全部活动,达到长期成功的管理途径。是改善效率及质量的一种重要方法。
    顾客满意:
    顾客即供应所提供产品的接受者,可以是组织内部的,也可以是组织外部的。
    附加价值:
    用最小的投入获取最大的功能价值,追求组织最大的经营绩效和个人最大的工作绩效。
    持续改善:
    建立以PDCA回圈为基础的持续改善的管理体系。

    • 建立持续创新和改善的目标;
    • 采纳这样一种哲学,我们不能容忍老毛病;
    • 用统计证据说明质量已经做进去了;
    • 用统计方法发现问题所在;
    • 改进监督,不仅注重产品质量,而且监督所有各类人员的行为正确性;
    • 驱除恐惧,使大家对指出问题和接受询问时不感到害怕;
    • 打破部门间、研发、测试及产品沟通的障碍,提高沟通有效性;
    • 限制使用只规定效率的工时定额,这种定额只能使大家不顾质量同时限制产量的提高;
    • 鼓励敬业精神;
    • 实行一个保持变革和创新的培训计划;

    影响群体

    名词解释

    QM(Quality Management-质量管理简称),是对确定和达到质量目标所必须的全部职能和活动的管理。包括质量方针目标的制订及其组织实施,也包括质量控制活动。在质量方面指挥和控制组织的协调的活动(通常包括制定质量方针和质量 目标以及质量策划,质量控制,质量保证和质量改进)。
    QA(Quality Assurance-质量保证简称),是指使人们确信某一产品、过程或服务的质量所必须的全部有计划有组织的活动。这种活动的标志或服务的质量所必须的全部有计划有组织的活动。这种活动的标志或结果,就是提供"证据",目的在于确保用户和消费者对质量的信任。
    QC(Quality Control-质量控制的简称),的为保持某一产品过程或服务的质量所采取的作业技术和有关活动。一般指为保证产品质量达到规定水平所使用的方法和手段的总称,是QM的组成部分。
    QMBP(质量管理业务伙伴),会深入到负责项目的全流程,从协助需求把控到进行运营质量把控跟踪,出具测试用例,思考各种边缘情况、极限情况下系统质量问题并进行尝试,记录并跟踪项目运营质量问题,并与开发、产品沟通优化提升方案。
    QMTP(质量管理技术伙伴),更专注于为QMBP提供自动化测试技术解决方案,以及提升自动化测试覆盖率,也可直接与项目小组进行对接,对成熟稳定的系统提供自动化质量保障体系方案。

    测试的影响

    过去我们对测试的定义更偏重于QC,更多的偏重于质量控制,但是我们希望构建更加高效能的质量责任共担的组织。如果测试继续仅仅是QC的定位,这将无法使整个组织都来关注质量。
    让测试人员远离生产一线,实际上是将测试人员角色从保姆变为教练,从仅关注产品质量到关注整体质量。按照逻辑讲,研发人员应该比测试人员更知道问题所在。当组内所有人员都开始关注质量时,那我们就可以消灭现在的测试人员了,测试人员则从更高的层面为我们的整体质量提升做出贡献。因此在这套体系下,测试人员的使命就是消灭专职测试,这似乎是一个悖论,但实际结果就是这样。
    质量人员将转变为QM
    我们需要将QC功能交付给研发部门,解决研发与QC责任不清的问题,所有研发人员都是QC了。这时候以往的QC岗位升级为QA与QM,主要支持研发部门进行质量体系的提升,测试部门的工作与职能将发生转变:

    • 对迭代关键节点的把握
      • 该小组对于产品经理提前提供迭代需求(2周的迭代,需提前1周提供用户故事)
      • 迭代会议时同步提交测试用例,与用户故事一起过审(试行)
      • 迭代结束时研发团队提交基于用例的测试报告
      • 发布前完成验收测试
      • 迭代内代码质量报告
    • 工作产出物
      • 测试用例
      • 测试用数据列举
      • 测试工具规划及需求提交
      • 验收报告
      • Bug提交
      • 自动化测试脚本
      • 生产问题报告(故障、客服、运营问题)
      • 探索性测试、破坏性测试报告并完善用例
      • 质量改进方向
    • 工作验收物
      • 迭代用户故事(迭代会前一周与组内SM一起看,是否基本符合次周召开迭代会的要求 – 做什么,做到什么程度,是否有优先级,细腻度是否够,需求是否清晰)
      • 自动化测试报告
      • 研发小组测试报告
      • 代码质量报告(通常以静态为主,有code review时跟进改进结果)
    • 新的工作职能
      • 跟进追踪质量全过程,协助团队提升整体质量,从需求到生产问题的跟进记录
      • 对产品进行各种探索性测试、破坏性测试,完善测试用例
      • 质量问题分析报告
      • 提升测试自动化程度
      • 降低测试质量缺陷比及生产质量缺陷比
      • 提升生产问题处理效率
      • 提升运营问题处理工具化标准化比例

    研发的影响

    研发将不再是完成开发后就将质量问题交给了测试,更多的测试工作将由研发自己完成。研发需根据测试用例完成测试报告,测试报告的内容由质量人员抽样验收以达到出口标准,测试将不再接受没有组内测试报告的版本提交(鼓励更多地通过自动化的方式完成测试)。
    还记得曾经的敏捷课程分享上,武士与大师的故事吗?
    武士:是的,大师,但是如果没有一个专职的测试者角色,我们如何才能相信有足够的测试呢?
    大师:测试属于必须完成的任务,因此测试会由团队来完成。团队会决定进行何种程度以及何种限度的测试。
    武士:如果没人想做测试怎么办?如果大家都只想坐下来编写代码怎么办?
    大师:那么你最好要找喜欢测试的员工,确保他们成为你团队中的宝贵成员。

    组织调整方式

    现有测试同事会以质量管理顾问的形式与小组关联,测试同事与各小组可双向选择,一个小组从项目角度选择质量顾问。
    QM同事会分为两层,如下图:

    迭代节拍

     

    短期目标

    1. 每个迭代的用户故事都要求产品提前二分之一迭代发出来
      1. 看是否有特别不清楚的内容
      2. 看是否需要跨组协同(需要则提前在其他组迭代会前与其他组协商需求)
      3. 保障迭代会时需求质量不会太差
      4. 提升迭代会效率
    2. 用户故事更标准
      1. 团队所有人都能理解
      2. 分用户场景分情况
      3. 可验证可测试的
    3. 测试用例沉淀
      1. 常规测试
      2. 破坏性测试
      3. 混沌测试
      4. 回归测试可直接参考
    4. 需求沉淀并有良好节奏(基于Tuleap)
      1. 需求做到有迹可循
      2. 变更做到有迹可循
      3. 从过去的需求中提取出模块化的东西
      4. 需求池不至于遗失需求
    5. Bug可追溯(基于Tuleap)
      1. 什么时候发现的
      2. 谁修改
      3. 结果怎么样
      4. 短期不修复的bug不至于遗失
    6. 团队自行负责质量,QM只做验收把控
      1. 通过自测缩减中间环节
      2. 保持团队高效能
      3. 提升整体质量控制
    7. 测试环境开始,所有发布基于Jenkins,不再手动至测试环境发包
      1. 避免手工发包代码覆盖
      2. 测试的发包也基于版本
      3. 研发、QM都可以根据自己需求在特定时间触发发版
      4. 代码静态扫描提升代码质量
      5. 每日构建保证代码质量的可靠,有问题及时发现
    8. 进一步提升质量与效率,并提升测试的自动化含量
      1. 基于RM开始搭建自动化测试平台
      2. 对于稳定的业务尽量做到接口自动化
    展开全文
  • 在上线交付之前,研发体系需要有各种提升工程或质量效率的Mock系统,这些系统通常是提供各种 Restful的接口,以支撑诸如单元测试,功能测试,自动化回归测试、测试数据生成维护等工作。 团队会成长,系统也会...

    要解决的问题

    在上线交付之前,研发体系需要有各种提升工程或质量效率的Mock系统,这些系统通常是提供各种 Restful的接口,以支撑诸如单元测试,功能测试,自动化回归测试、测试数据生成与维护等工作。

    团队会成长,系统也会越来越复杂,而随着这些队伍和系统的演进,Mock系统提供的接口也会越来越多,越来越复杂,包括提供方和提供团队也会越来越多,所以如何高效、及时、低门槛地更新、维护日益庞大的 mock restful API 调用信息,方便工程师们查找,以及贡献者们追加,是我们经常要解决的问题。

     

    演进式服务注册发现体系建设

    团队规模小,Mock 服务少时:


    一张简单的 wiki 作为mock portal,里面登记上主机名,接口,mock的服务名称等等就可以了,方便添加、修改也方便查阅。

     

    团队规模小,Mock 服务增多,需要共享公司或是部门级全局配置信息时:


    这里的配置信息可以是公司统一要求的服务启动缺省参数配置(研发或DevOps需要),或是不同环境的入口地址(单元、自动化回归需要)等等

    引入consul 先作为配置中心,也为后继地演进做过渡。
    选择的原因是其小而美:

    • consul系统是专为服务注册发现而设计的,搭建方便快捷,自带Web Server。
      没有Zookeeper那么臃肿,又比 etcd + confd 强大易用
    • 具备简易的分级的 KV 存取体系
    • 支持 Restful API 的存取形式
    • 自带Web UI 维护界面

    当然我们也可以基于nginx/apache,通过 Git/Svn 在公共Repo中签入签出一系列的静态配置文件来维护共享的配置信息,只是这个更新的步骤就比较繁琐。

    搭建步骤

    1. 安装 docker 以及 docker-compose。
      基于docker搭建是简化系统搭建,以及系统接近零成本重建或搬迁的标配。
    2. docker pull consul。获取 consul 的官方镜像
    3. 编写 docker.yaml 文件(见下)后,敲入:docker-compose up
      ps: 如果想在启动镜像后,进入其中进行一些自定义动作,敲入: docker exec -it <your container id> /bin/sh
      version: "3"
      
      services:
        consulserver:
          image: consul
          ports:
          - "8300"
          - "8400"
          - "8500:8500"
          - "53"
          command: agent -server -ui -data-dir /tmp/consul -bootstrap-expect 1 -client 0.0.0.0

      - image: consul : 镜像来自于#2 拉取的 consul
      - ports: ... : consul 容器中打开的几个tcp端口,其中的 8500 必须映射至宿主机的 8500,以便可在宿主机上输入:http://localhost:8500,访问 consul 的 Web UI
      - command: 相当于container中执行:consul agent -server ...,即 consul 以 server 的形式运行agent,同时打开Web UI 服务(-ui)

      可以用 docker run/stop ... 来启停 consul,但命令长,步骤繁,以 docker-compose up/down 启/停容器,尤其是多容器启、停及彼此关联或依赖维护简化的不二法宝。

    4. 访问 “http://localhost:8500/ui/dc1/kv” ,通过 UI 直接更新维护全局共享配置项


      支持分级的 key/value,例如 dev环境中服务项里的 user 服务配置,dev/service/user = ...

    5. 配置完成后,可通过 http://localhost:8500/v1/kv/dev/service/user 获得配置项的 value 内容,其中 value 是经过了 base64 编码处理的

    续待 ……

    展开全文
  • 体系方面流程:如市场需求调查——接受合同或订单——产品设计开发——采购——生产制造——测量监控——交付——服务;产品生产流程:工艺流程 l是否确定了这些过程的顺序和相互作用? **过程的总流程(可借助...
  • 课程交付:混合| 7周14节 课程学分:3学分| 37.5座位时间| 75小时总 学习成果 在课程结束时,学生将能够... 比较和对比软件体系结构选项和设计模式,以做出明智的选择。 生成精美的伪代码以快速描述如何解决问题。...
  • 移动端测试:UI端测试(界面、流程、数据显示等)—用户行为相关 服务端:数据等,真实的后端服务非常复杂且更新速度非常快 —又称为接口测试 测试流程 服务端测试涵盖在测试和交付之间 接口测试必要性-分层测试...

    背景

    在这里插入图片描述

    • 移动端:UI测试、兼容性测试等(界面、流程、数据显示等),与用户行为相关。
    • 服务端:接口测试,检查数据的交换、传递和控制管理过程,绕过客户端直接对服务端进行测试。

    接口测试的价值

    服务端测试十分复杂,具有复杂的组件交互网络,UI测试无法覆盖,所以要绕过客户端,直接使用接口测试对服务端进行测试。

    测试流程

    在这里插入图片描述
    服务端测试涵盖在测试和交付之间

    接口测试的体系

    分层测试策略

    unit(实际上单元测试仍然是开发进行,最底层)< service(中间层) < UI(最上层)

    越往上层,发现bug的时间越晚,成本越大(时间、人力、损失),接口测试相比于UI测试,能够更早的发现问题,更快的反馈质量,花费的成本越低。

    • 行业成熟方案
    • 更早发现问题
    • 更快质量反馈
    接口测试能否取代UI测试
    • 接口测试无法取代UI测试,因为UI测试涉及到用户体验部分,接口无法进行代替。
      ** 大前端工程师的产出质量只能通过UI测试保证
      ** 接口测试主要是对spring boot(后端研发团队)进行测试
    展开全文
  • 现代运维管理体系

    2017-11-21 11:46:47
    它为IT治理提供了一个基本框架,从企业和客户的角度,将重点放在IT服务交付的持续质量改进评估。ITIL将重点放在IT服务交付的持续质量改进评估上一个最主要的原因是因为ITIL在全球所取得的巨大成功,并且各个组织...
  • 质量度量体系 大家都知道作为测试的主要任务是质量保障,保障线上环境没有故障和缺陷,最终交付给真实用户的质量,即交付质量。那么,质量度量是不是只关注交付质量指标就足够了呢?答案显然是否定的。因为如果只...
  • 文本为研发组织效能改进体系,以用户价值为核心,敏捷迭代,小步快跑,建立持续交付,用户反馈,功能业务闭环。 以业务为导向的跨职能合作,一段时间内享有固定的人员配置。职能主管统筹管理,各业务负责人形成AB...
  • 目前,互联网公司对软件产品的质量要求越来越高,研发测试周期确越来越短。... 精准测试体系的本质目的是在保证质量的前提下提高QA的交付效率,更快地响应公司的业务需求。 精准测试的思想: 1....
  • "DevOps是软件开发、运维和质量保证三个部门之间的沟通、协作和集成所采用的流程、方法和体系的一个集合。它是人们为了及时生产软件产品或服务,以满足某个业务目标,对开发运维之间相互依存关系的一种新的理解。...
  • 在编码后修改软件缺陷的成本是编码前的10倍,在产品交付后修改软件缺陷的成本是交付前的10倍;软件质量越高,软件发布后的维护费用越低。 另外,根据对国际著名IT企业的统计,它们的软件测试费用占整个软件工程所有...
  • 当今激烈的商业竞争中,企业中的服务和产品需要更快速的版本迭代和高质量的软件交付,同时减少完成项目所需的成本和时间,不少企业引入了DevOps概念来提升软件研发交付效率。DevOps是开发和运营的结合,代表着一种...
  • 是中国系统软件过程改进协会第八届年会的一个主题 用友的一个老总做的分享 为什么要改进客户合作关系? 很明确,建立共赢的客户合作体系 有时我们作为甲方很强势,作为乙方很被动,但都是在一条战线上的双方、...
  • 我们以React的技术栈为背景,在日常的需求迭代中, 历时两年多时间,沉淀出了携程用车各大产线(接送机/包车/打车服务等)的公共组件(机场、航班、城市、地址、时间控件等)。通过持续交付了一...
  • 我们以React的技术栈为背景,在日常的需求迭代中, 历时两年多时间,沉淀出了携程用车各大产线(接送机/包车/打车服务等)的公共组件(机场、航班、城市、地址、时间控件等)。通过持续交付了一...
  • 软件组织的质量治理

    2021-02-04 05:12:02
    这篇文章描述了IBMRational软件交付平台(IBMRationalSoftwareDeliveryPlatform)的各种优异特性,它可以帮助软件组织创建质量治理体系以适应如今来自技术进步所引起的组织转型需求。位于Siena的Tuscan城的...
  • 项目质量管理包括执行组织确定质量政策、目标职责的各过程和活动,从而使项目满足其预定的需求。项目质量管理在项目环境内使用政策和程序,实施组织的质量管理体系;并以执行组织的名义,适当支持持续的过程改进...
  • 第八章-项目质量管理

    2016-10-26 22:51:09
    项目质量管理包括执行组织确定质量政策、目标职责的各过程和活动,从而使项目满足其预定的需求。 项目质量管理在项目环境内使用政策和程序,实施组织的质量管理体系;并以执行组织的名义,适当支持持续的过程...
  • 质量运营,是将运营的思路注入到质量评估改进工作中,它着眼于产品的全生命周期,以质量为中心,以数据为驱动,通过建设持续迭代的质量保障体系,最终提升交付质量。本文将聚焦研发过程中的提测阶段,以改进提测...
  • 项目质量管理包括执行组织确定质量政策、目标职责的各过程和活动,从而使项目满足其预定的需求。项目质量管理在项目环境内使用政策和程序,实施组织的质量管理体系;并以执行组织的名义,适当支持持续的过程改进...

空空如也

空空如也

1 2 3 4 5 ... 7
收藏数 125
精华内容 50
热门标签
关键字:

交付体系与质量体系