【腾讯TMQ】自动化测试平台实践几点经验总结

背景

自动化建设是质量和效率提升的一个基础手段。从各产品业务测试的角度上,在自动化测试上有了一定的积累。从整个品质中心上,各个组都在支撑多产品的质量保证工作。出于提升自动化建设基础服务的专业度和深度,同时减少重复建设的成本,2016年品质中心成立联合项目,有组织性协作开展中心层面自动化体系和自动化平台的建设工作。

本人在9月份加入自动化建设UTP团队,PM角色。主要负责项目的管理,运作等。以下是在UTP项目实践中几点经验教训的总结。主要分两个方面,一个是技术上,一个是运作管理上。供各位有相关工作的同学做参考。

若对总结有异议,欢迎共同探讨。

技术上

经验一,系统分层实现。

我们整个自动化平台主要有四个子系统,任务系统,用例系统,资源系统和报表系统。以下是UTP整体的架构图。

前期的想法很简单,每个人认领一个系统开发,这样各自比较独立,只需要沟通好对应的接口即可。这样的做法,起初确实能快速的把整个自动化平台搭建起来了。但是随着规模和用户使用上来,出现了一个问题,即慢慢的由原先任务系统对用户有页面交互外,用例和资源系统逐渐出现较复杂的交互页面。如用例系统需要用户配置用例工程代码路径,用例选择更复杂的能够配置是否需要并发,怎么并发。资源系统需要能够展示资源列表,配置标签组等。

而这些由系统各自开发人员开发,就会带来一个问题:一个系统开发需要掌握后台和前端两块的开发,而每个人的经验不一样,有些没接触过,有些接触过又各自熟悉语言不一样,这样就导致前端页面的交互开发速度慢,风格不一致,且选取实现的语言也会不统一。这是早期为了快速实现功能遗留的技术债,没有合理的做系统分层。因此在今年上半年,随着前端人力richer的加入,慢慢的将前端的开发专人负责,分层实现。

这样带来的好处是:一是页面交互体验,不涉及接口的变动,可直接由专人修改;二是,在开发效率上,专人专职,熟练度和深度都有提升,交付速度也能随之提升。

分层后人员分工简单如下:

经验二,适当采用公司或外部的三方公共服务。

这一点,我们在早期开发时,就快速达成结论,不用临时的本地系统和数据库,防止随着代码工程规模的变化,增大改造成本。如mdb,ceph,jenkins等,都在各系统开发时就直接使用公司或外部的三方服务。三方服务上,经验是,主动去和有经验的人请教,这样可以节省大部分盲目网上查看资料的时间。这里感谢期间请教万松,yunshan各种问题,省得走一些弯路。当然,真正采纳使用还是需要花时间和精力去熟悉细节。

经验三,增强产品思维,同时做好基础质量的保证。

开发中,很多想法和使用都是理所当然或是希望提供更灵活的操作给到用户,也就出现了用户使用很茫然,体验不佳的情况。在我们没有专业的产品设计时,很多时候就需要自己跳出开发实现的细节,增强自身产品的思维,从用户的角度去设计实现。还有整体后台的基础质量也应该抓起来,从代码review到各纬度自动化测试都尽力覆盖到,保证发布无严重质量问题。这一块我们做的比较薄弱,希望能不断加强。

管理上

经验一,迭代开发,日常工作模版化,共同分担。

因为UTP团队比较特殊,都是各组抽调一二人联合支撑平台建设,因此出现四地的局面,这样导致异地沟通成本极高,每次组织一次讨论或晨会都是很耗时间,而且沟通效率也大打折扣。我们采取的方法是,首先大家节奏要一致,两周一个迭代开发,迭代开始会有总结和开工会,全员了解本次迭代的重点工作内容。其次,日常的工作,如晨会,周报,缺陷情况,发布情况,迭代规划等事项分别各人承当一个,责任田制,互相配合,共同分担。而非一人管理,即没有成长,而其他人又处于被动状态。

经验二,主动和各业务测试团队共同建设,防止闭门造车,偏离价值。

相较于去年的平台建设,今年更多的关于业务侧自动化的使用,从需求入手,共同建设自动化测试体系。

经验三,主动思考和邀请各团队和老大们共同讨论。

在整体的目标规划上,也更积极的主动和思考,同时请教各团队和老大们的意见,希望整体的工作更贴近业务的价值。

获取更多测试干货,关注微信公众号:腾讯移动品质中心TMQ!

【腾讯TMQ】自动化测试平台实践几点经验总结_第1张图片

版权所属,禁止转载

你可能感兴趣的:(自动化)