作者：廖海珍團隊：騰訊移動品質中心TMQ
自動化建設是品質和效率提升的一個基礎手段。從各産品業務測試的角度上，在自動化測試上有了一定的積累。從整個品質中心上，各個組都在支撐多産品的品質保證工作。出于提升自動化建設基礎服務的專業度和深度，同時減少重複建設的成本，2016年品質中心成立聯合項目，有組織性協作開展中心層面自動化體系和自動化平台的建設工作。
本人在9月份加入自動化建設UTP團隊，PM角色。主要負責項目的管理，運作等。以下是在UTP項目實踐中幾點經驗教訓的總結。主要分兩個方面，一個是技術上，一個是運作管理上。供各位有相關工作的同學做參考。
若對總結有異議，歡迎共同探讨。
經驗一，系統分層實作。
我們整個自動化平台主要有四個子系統，任務系統，用例系統，資源系統和報表系統。以下是UTP整體的架構圖。
前期的想法很簡單，每個人認領一個系統開發，這樣各自比較獨立，隻需要溝通好對應的接口即可。這樣的做法，起初确實能快速的把整個自動化平台搭建起來了。但是随着規模和使用者使用上來，出現了一個問題，即慢慢的由原先任務系統對使用者有頁面互動外，用例和資源系統逐漸出現較複雜的互動頁面。如用例系統需要使用者配置用例工程代碼路徑，用例選擇更複雜的能夠配置是否需要并發，怎麼并發。資源系統需要能夠展示資源清單，配置标簽組等。
而這些由系統各自開發人員開發，就會帶來一個問題：一個系統開發需要掌握背景和前端兩塊的開發，而每個人的經驗不一樣，有些沒接觸過，有些接觸過又各自熟悉語言不一樣，這樣就導緻前端頁面的互動開發速度慢，風格不一緻，且選取實作的語言也會不統一。這是早期為了快速實作功能遺留的技術債，沒有合理的做系統分層。是以在今年上半年，随着前端人力richer的加入，慢慢的将前端的開發專人負責，分層實作。
這樣帶來的好處是：一是頁面互動體驗，不涉及接口的變動，可直接由專人修改；二是，在開發效率上，專人專職，熟練度和深度都有提升，傳遞速度也能随之提升。
分層後人員分工簡單如下：
經驗二，适當采用公司或外部的三方公共服務。
這一點，我們在早期開發時，就快速達成結論，不用臨時的本地系統和資料庫，防止随着代碼工程規模的變化，增大改造成本。如mdb，ceph，jenkins等，都在各系統開發時就直接使用公司或外部的三方服務。三方服務上，經驗是，主動去和有經驗的人請教，這樣可以節省大部分盲目網上檢視資料的時間。這裡感謝期間請教萬松，yunshan各種問題，省得走一些彎路。當然，真正采納使用還是需要花時間和精力去熟悉細節。
經驗三，增強産品思維，同時做好基礎品質的保證。
開發中，很多想法和使用都是理所當然或是希望提供更靈活的操作給到使用者，也就出現了使用者使用很茫然，體驗不佳的情況。在我們沒有專業的産品設計時，很多時候就需要自己跳出開發實作的細節，增強自身産品的思維，從使用者的角度去設計實作。還有整體背景的基礎品質也應該抓起來，從代碼review到各緯度自動化測試都盡力覆寫到，保證釋出無嚴重品質問題。這一塊我們做的比較薄弱，希望能不斷加強。
經驗一，疊代開發，日常工作模版化，共同分擔。
因為UTP團隊比較特殊，都是各組抽調一二人聯合支撐平台建設，是以出現四地的局面，這樣導緻異地溝通成本極高，每次組織一次讨論或晨會都是很耗時間，而且溝通效率也大打折扣。我們采取的方法是，首先大家節奏要一緻，兩周一個疊代開發，疊代開始會有總結和開工會，全員了解本次疊代的重點工作内容。其次，日常的工作，如晨會，周報，缺陷情況，釋出情況，疊代規劃等事項分别各人承當一個，責任田制，互相配合，共同分擔。而非一人管理，即沒有成長，而其他人又處于被動狀态。
經驗二，主動和各業務測試團隊共同建設，防止閉門造車，偏離價值。
相較于去年的平台建設，今年更多的關于業務側自動化的使用，從需求入手，共同建設自動化測試體系。
經驗三，主動思考和邀請各團隊和老大們共同讨論。
在整體的目标規劃上，也更積極的主動和思考，同時請教各團隊和老大們的意見，希望整體的工作更貼近業務的價值。
擷取更多測試幹貨，請搜尋微信公衆号：騰訊移動品質中心TMQ！