实践中的质量度量

标签: 实践 质量 度量 | 发表时间:2012-07-30 13:22 | 作者:
出处:http://pipes.yahoo.com/pipes/pipe.info?_id=10560380f804c7341f042a2b8a03e117

上周末InfoQ与 支付宝技术大学携手将QClub线下技术沙龙带入了 支付宝上海分公司,本次活动的主题为“质量度量123”。随着软件及互联网行业逐步走向正规化、规模化,软件质量正日益受到大家的重视,无法进行合理的度量就无法保证质量。因此,这一话题吸引了很多同学来到现场。

在支付宝技术大学 马良(花名)的简单开场之后,活动便进入正题,由来自支付宝SQA团队的 西剑(花名)为大家分享了一些持续集成中的代码度量模型与实际应用。首先,西剑做了一个现场调查,在场多少人的公司在实施持续集成,结果现场几十名同学约有10人举手,而当问及有多少公司在做代码度量时,就只有一位爱立信的同学依然举手。由此可见,经过一段时间的推广,持续集成这一实践已开始为大家所认识,并开始尝试,而代码度量的实施情况不容乐观。

统一配置管理(UCM)就指出对代码变更的范围是可以进行精细化管控的。说起代码质量管控,目前面临三大挑战――精准、快速、协同。那代码质量到底是什么?现场有人提出稳定性、健壮性、可维护性,其实有很多衡量代码质量的模型,比如圈复杂度。这么多模型,该如何在实践中加以用?西剑提出有效的代码度量模型应具备以下特征:

  • 与组织的目标一致:代码度量模型的底线要与组织的要求一致,和业务相关的东西会体现在规范里。在支付宝,代码安全规范、敏感信息处理规范被作为代码质量最基本的要求。
  • 有针对性:要做针对性分析,比如对线上故障的研发原因进行分析,分析的规则会有周期性变动的,但不要太频繁,而且规则会随着组织的成熟度而改变。
  • 可操作性:要对度量维度做进一步分解,比如测试要有明确的检查点,覆盖要完整,可重复运行。支付宝就制定了具体的度量维度,从多个维度对系统加以度量。
  • 有工具支持:这不是必要条件,工具不能解决所有问题!能用工具最好,不行的话就人工检查。工具检测维度要按照优先级和操作性,逐步增加精细化维度。这一点上,支付宝将一些编码规则的检查放入了持续集成工具之中,以求尽早检查、频繁检查。

西剑介绍了支付宝正在构建的一套持续集成平台,自上而下分为DashBoard、服务管理层与服务层,其中最为基础的服务层中就提供了单元测试(构建服务、静态扫描、单元测试、CodeReview)、集成测试(API测试)、系统测试(SIT、UI测试)等众多服务。

当被问及人工CodeReview是靠资深的工程师来做,还是质量部门自己来做时,西剑认为最佳的方式是项目成员进行交叉CodeReview。如果靠资深的架构师来进行CodeReview,他可能只会关注代码规范或者一些上层的东西,无法深入细节,因为他本身的视角太高,不清楚业务实现的具体细节,而项目的成员或者开发Owner可能更清楚这些东西。

代码度量模型又该如何应用?首先,要有度量模型作为代码质量标准,引导团队代码质量意识和方向;其次,辅以持续集成,实时监测代码复合模型中客观质量度量的情况,再配合人工CodeReview保证业务一致性。持续集成相对客观,而人工的CodeReview则较为主观。产品在发布之前,必须满足组织的代码度量模型,否则不予上线。

在进行了度量之后,系统代码质量可以在多个系统间进行横向比较,其中服务型系统与应用型系统质量要求会有所区别,新老系统会有区别,检查系统量目标是否达成,以此确定部门改进的系统范围和目标。单个系统也可进行纵向比较,了解系统质量的变化趋势,分析原因,确定单个系统质量改进月度目标。

质量度量并不是一个人,或者几个人就能轻松实现的,需要建立有效的执行体系,西剑建议可以从以下几个方面着手:

  • 获得管理层认同:让管理层能看得见目标,看得到做法,往往有技术背景的管理层更容易说服。
  • 流程保障:把要求放入日常流程之中。
  • 组织保障:要有人专门负责制定、维护、解释标准,并将标准落地,因此可以成立专门的组织(可以是一个虚拟组织),在支付宝就有一个名为SQPG的组织。

目前的质量度量主要还是集中在开发阶段,今后可能会将部署阶段也囊括进来,部署的度量主要包括系统依赖性检查、配置一致性检测、应用部署验证、DB部署验证、性能极限验证和业务验证。此外还要寻求更科学的度量指标,在实践中圈复杂度也会有这样那样的问题,需要寻找一些更合适的度量指标。

在简短的休息之后,来自 51Testing的宋光照为大家介绍了如何构建可维护的自动化测试。首先,他分享了他对软件质量特性中的可维护性的理解,可维护性包含易测试性(降低发现缺陷的成本)、易分析性(降低定位缺陷的成本)、易改变性(降低修改缺陷的成本)和稳定性(减少频繁修改而导致的不稳定),其中易测试性是最为重要的。测试自动化和自动化测试常被混为一谈,宋光照解释到自动化测试偏重于测试的执行,而测试自动化则包含自动化测试管理、自动化测试执行和工具支撑三个部分。自动化测试目前面临了很多挑战,比如软件测试的时间越来越短,变更越来越多越来越频繁,回归测试成本压力越来越大。业界对自动化测试的需求大致可以归纳为:

  • 要求是执行快、效率高、可重复的自动化测试资产
  • 自动化测试工具成本要低
  • 要有易学易用的自动化测试方法
  • 对提高软件质量有评价或质量度量指标

而开发对自动化测试也有自己的需求:

  • 能尽早快速发现软件缺陷
  • 工具要有自我检查和任务闭环管理功能
  • 对提高编程质量有指导性意义
  • 自动化测试工具链支撑能适应自身开发模式

从自动化的角度来看,底层从单元测试开始时比较现实的,只要提供了框架,传递了合适的方法即可。面向函数级别,请考虑单元测试;面向API层面,构建功能测试,快速做验收;面向GUI层面,开展录制回放;从使用者角度来关注质量,做一些手工测试。宋光照强调了测试自动化开发也是软件开发,要多考虑可测试性设计。随后,他为大家演示了两套自动化测试工具,介绍了一些实际使用案例。

在成本方面,自动化测试也要有投资回报考虑,至少要回归3次才会有收益,随着版本迭代次数增加,收益会明显提高,如果考虑其他平台兼容性问题,收益还会成倍增加。在实施前期,需要投入自动化测试管理、人员和研发过程管理,做到人员清楚定位、合理分层。自动化测试在起步阶段,重在用例转化,将手动测试转为自动化测试;在成熟阶段则重在效率,提高用例重用度,提高持续集成和每日构建效率。

关于质量度量与自动化测试,还有很多值得深入讨论的内容,如何把控软件质量,各位读者,您是怎么做的?

丁雪丰 是InfoQ中文站编辑,满江红翻译组核心成员,出版过《Spring攻略》、《JRuby实战》等多部译著。主要关注领域:企业级应用、海量数据计算、动态语言应用等。

相关 [实践 质量 度量] 推荐:

实践中的质量度量

- - InfoQ cn
上周末InfoQ与 支付宝技术大学携手将QClub线下技术沙龙带入了 支付宝上海分公司,本次活动的主题为“质量度量123”. 随着软件及互联网行业逐步走向正规化、规模化,软件质量正日益受到大家的重视,无法进行合理的度量就无法保证质量. 因此,这一话题吸引了很多同学来到现场. 在支付宝技术大学 马良(花名)的简单开场之后,活动便进入正题,由来自支付宝SQA团队的 西剑(花名)为大家分享了一些持续集成中的代码度量模型与实际应用.

提高软件质量实践―― Facebook 篇

- - 博客 - 伯乐在线
来源: Bill Liu 的博客. Facebook从04年的哈佛校园的学生项目在短短的7-8年的时间中快速增长为拥有10亿用户的世界上最大的社交网络,又一次见证了互联网创业成功的奇迹. 同时它的产品研发流程也成为了众多互联网产品公司的追逐对象. 今天我们来看一下facebook在产品质量控制方面的实践.

提高软件质量实践――Amazon篇

- - 博客 - 伯乐在线
来源: Bill Liu 的博客( @billliu_seattle). 前几天回国转了一圈,做了两家企业质量管理培训,一次上海测试沙龙,和chinatest两次演讲. 回来后发现我的软件质量实践系列文章距离上一次发表已经有很长一段时间了. 我想还是先把它写完,再写别的文章吧. 那么今天我们看看互联网公司的另外一个大哥大是如何做质量控制的――Amazon..

DataMan-美团旅行数据质量监管平台实践

- - 美团点评技术团队
数据,已经成为互联网企业非常依赖的新型重要资产. 数据质量的好坏直接关系到信息的精准度,也影响到企业的生存和竞争力. Michael Hammer(《Reengineering the Corporation》一书的作者)曾说过,看起来不起眼的数据质量问题,实际上是拆散业务流程的重要标志. 数据质量管理是测度、提高和验证质量,以及整合组织数据的方法等一套处理准则,而体量大、速度快和多样性的特点,决定了大数据质量所需的处理,有别于传统信息治理计划的质量管理方式.

火山引擎流批数据质量解决方案和最佳实践

- -
火山引擎的数据质量平台是在多年服务字节跳动今日头条、抖音等业务的过程中打磨出来的. 面对今日头条、抖音等不同产品线的复杂数据质量场景,数据质量平台如何满足多样的需求. 本文将介绍火山引擎数据质量平台是如何弥合大数据场景下数据质量校验与计算消耗资源大、校验计算时间长的冲突,并介绍数据质量平台是如何用一套架构框架来满足流批方面的数据质量监控.

技术文章的质量

- Kai Chen - 4G spaces
推友 @StarrySource 就微薄和推特的好坏问题写了一篇文章,正好和霍炬的文章同时发出来,推特上对这两篇文章叫好的人不少,其中还有一些直接就说 StarrySource 这篇比 virushuo 写得好. 文章好坏诚然是个很主观的事情,不过就仅从文章内容来说,就算有一千个读者一千个主观标准,我也想不出什么理由来说明 StarrySource 的这篇比 virushuo 写得好,因为客观上这两篇文章的差距会抵充掉主观上的一些好恶.

关于产品质量

- 茫茫 - 弯曲评论
记得去年某天曾去1号楼机房参观T系列存储系统的硬件,由于前期知道T系列的IO接口卡均可热插拔,而这在中端存储产品里是没有其他友商可以做到的. 抱着好奇的心态,我就反复尝试了一下,可以任意插拔IO接口卡而不影响业务,效果非常好. 为了进一步验证T系列的可靠性,我直接拔出了正在运行的双控中的一个控制器,此时主机端正在从阵列中拷出一个大文件,拔出控制器之后,拷贝出错终断了,这个也是可以理解的,毕竟操作系统自带的拷贝是写死的,超时值不可调.

苏泊尔“质量门”

- 棉花 - 南方周末-热点新闻
有业内人士质疑,以锰代镍是原材料价格上涨导致成本的增加后企业应对压力采取的手段. 对此,苏泊尔方反复强调“产品质量安全是没有问题的”,但未提及相关材质含量的问题.

软件质量之道

- - CSDN博客系统运维推荐文章
        我曾与一些资历非常高但毫无实际经验的人共事过,也曾与一些只有很少或根本没有资历但才华横溢的工程师一起工作过,我也曾经不得已跟一些并不想用心做事、也对学习新东西丝毫不感兴趣的人共事过. 如果说我们这个职业是一张纸,那么这些人就好比纸上的污点. 软件开发业的低劣性不能完全怪罪于那些无知的经理、狡猾的市场营销人员以及总是急不可耐的用户,实际上很大程度上要归咎于这个行业的某些从业人员,他们应该去从事一些即使玩忽职守也不会造成像软件业里这样大的危害的行当,而不应该混迹于这个聚集着人类想象力的最复杂的创造性的行业.

OpenStack实践

- - 开放博客
作者:Baihuogou DevOps Team. 我们在公司内部部署OpenStack主要是内部管理虚拟机的需要. 公司内部之前使用virt-manager来管理内部虚拟机,但是缺点有二:. 虽然提供图形界面,但是是桌面软件形式,需要安装软件. 所以现在需要一个新的管理软件来解决这些问题,满足两个特性:.