背景

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

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

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

技术上

经验一，系统分层实现。

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

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

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

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

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

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

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

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

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

管理上

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

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

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

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

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

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

获取更多测试干货，请搜索微信公众号：腾讯移动品质中心 TMQ！