有贊.測試團隊介紹（轉）
轉載原因：學習、借鑑先進生產力
一、基本概況
有贊，旨在為商戶提供強大的微商城和完整的移動零售解決方案，是一個移動零售服務商，正在新零售的潮流中激流勇進、開疆拓土，用產品技術撬動巨大的市場。有贊擁有世界級的 SaaS 電商解決方案，每天處理幾百萬訂單、幾億條訊息，且量級仍在不斷攀升中，有贊還開放了有贊雲，連線數十萬開發者，大大提升了SaaS 對商家產生的價值。
有贊測試團隊三分之二以上成員來自於阿里、騰訊、網易等公司，他/她們分別在電商事業部、零售事業部、餐飲事業部、支付事業部及共享技術事業部等部門貢獻自己的力量。
二、我們的日常工作
測試團隊負責相關專案具體測試工作、自動化建設、合併釋出流程管控、設計開發線上業務級別可用性監控、同時在研發提升測試效率的工具。
有贊測試職位主要負責度量產品質量及研發測試效率工具。從度量產品質量角度講，有贊測試人員需要具備白盒測試能力、CodeReview能力、業務功能測試，從而實現核心系統可持續自動化測試，保障系統在頻繁釋出情況依然是穩定的、高可用的。對於效率工具研發，測試同學完成相關第三方mock(例如簡訊、支付)、應用級健康檢查、線上業務級可用性監控、持續整合工具、UI自動化、測試工作臺、效能測試平臺、全鏈路效能壓測等。
2.1 具體專案測試
有讚的專案分為標準需求專案、技術重構專案、優化專案、缺陷修復專案。有限的測試資源通過不同策略支援著絕大部分業務產品的測試工作。
第一、對於標準需求專案或者跨多個業務的專案，一定會有測試投入，並且會有一位PTM來協調測試工作。PTM需要確保所有需求點都拆分到各個業務測試同學手裡，跟蹤相關測試同學按時提交標準測試方案。當測試方案彙總後，PTM需要評估後續測試過程中，測試人員如何投入。即哪些業務的功能測試PTM可順帶執行掉，哪些確實需要對應業務線測試同學來完成，以避免一個專案投入過多測試同學。
第二、技術重構改造專案，這種一般是單應用或者極少應用改造，但不改變業務使用規則。這類專案測試同學只要設計測試方案並完成測試用例落地即可，用例的執行由開發自行完成。測試同學要做的就是對新系統進行自動化覆蓋。如有需要，測試會在上線前做質量check。
第三、對於小型專案，如果開發的自測場景與測試同學的測試場景基本一致，那開發自行搞定即可；或者測試同學把需要特別關注的或者風險點給開發同學簡單介紹。對於有差異的，測試同學把差異點向開發同學描述清楚即可。
有贊測試同學拿到具體需求後，按照有贊測試對需求分析和測試方案統一要求，完成相關工作。
2.1.1 需求分析
測試同學在參加需求評審或者測試方案設計之前，需要認證閱讀需求文件，從獲取相關的資訊：
第一、這個需求是給哪些角色使用的。例如，高階管理員、普通管理員、庫管人員、核銷員；還是買家，是大眾買家還是特定買家。
第二、不同角色，在什麼環境下使用這個些功能。例如PC後臺、店鋪收銀臺、手機端、還是有讚的移動終端。
第三、整個專案是否存在物件的生命週期扭轉，例如訂單物件、店鋪等，它們在什麼條件下會發生什麼樣的扭轉。即明確狀態發生變更的條件規則，確保物件生命週期是有終態的。
第四、明確每個業務點的人機互動過程及規則，業務過程是否連貫明確；即如何使用這個需求。
需求分析後，需要輸出物件生命週期圖、業務時序圖、用例圖、待確認的問題、風險點清單。並就相關問題、風險與產品、開發進行多次溝通，直到問題得到明確答覆。
2.1.2 測試方案設計
一、功能測試設計的完整性，取決於測試人員對需求分析的深入程度及其經驗。為了彌補測試同學經驗不足，我們梳理了《功能測試.頁面測試.基礎篇》《有贊雲.測試參考規範》《有贊雲.carmen介面自動化參考規範》等供平時設計參考。同時，不定期組織業務分享，提高測試人員的業務全域性觀及跨業務耦合與風險評估能力。
二、提供《有贊.異常測試基本場景》指導測試人員如何考慮異常。包括Redis快取、訊息、大資料定時任務處理、多系統協同等。
三、有贊有安全測試專員及虛擬小組，提供安全測試方面的指導和工具；針對SQL注入、XSS、越權、業務規則安全、檔案上傳&下載、重定向定製常規安全測試用例，指導日常測試。
四、其它的專項測試，根據實際情況定義指導案例及分享。
2.2 自動化開發
前面提到有贊測試開發的職責，自動化是必修課。我們從介面層、端對端的資料層、端對端的UI層來做自動化建設。有贊前端應用互動與後端業務是分離的，資料通過.json請求獲取或者提交資料。UI自動化依賴於前端元素的穩定性且Selenium測試具有的一定不穩定性，我們構建了在不開啟瀏覽器的情況，對前端請求資料進行覆蓋的端對端資料層自動化。各層自動化比例如下。
有贊.自動化分佈圖
一、介面自動化主要包含對Rest、Dubbo、Nova提供的業務介面進行覆蓋。在youzan-boostrap框架上設計了介面自動化框架。根據不同業務線構建獨立自動化應用。有贊介面自動化用例總量已經達到3000+，其中商品中心+庫存中心+物流中心的用例總數就達到500+。
二、端對端資料層，基於Spring Aop技術封裝有贊帳號登入與店鋪切換的前端測試外掛yago。測試人員可以更關注自己的業務自動化開發。
三、UI自動化框架是基於Selenide和Selenium框架進行的二次封裝。框架支援Web和Wap頁面的元素操作，其中Selenide用來支援Web頁面，Selenium用來支援Wap頁面。以下從三方面對框架作簡要闡述。
框架結構。driver層二次封裝Selenide和Selenium的介面，是操作頁面元素的核心；pageObject層用於封裝業務流程中需要使用的每一個頁面元素，是業務流程實現的核心；dataprovider層自定義測試資料，實現測試資料的隔離；service層用於定義各模組之間的公共業務流程，實現模組間業務的呼叫。
用例組織。從賬戶登入到一個業務流程結束作為一個完整的UI自動化用例。用例由每一個pageObject介面的呼叫來實現業務流程。所有測試用例使用testng進行管理。
報告展示。採用reportng收集測試資料再結合jenkins外掛呈現測試報告。
2.3 線上監控開發
隨著有贊系統網路拓撲與業務場景越來越複雜，釋出頻率越來越高，同時系統是部署在公有云上；節假日、及頻繁的釋出後，有讚自己如何知道當前系統中核心業務場景的健康情況。在上半年我們開始設計建設「業務級可用性監控系統」，從商家後臺業務管理，到買家端的交易前、交易中，交易後等核心業務場景執行使用者真實操作，監控線上業務級可用性。
現在，有贊釋出系統完成應用釋出後，呼叫「線上監控系統」的Rest介面發起業務級可用性檢查；監控系統以多執行緒方式把各業務的監控點拉起，每個業務的多個檢查點，也以多執行緒方式來執行。若發現業務失敗，通過有贊告警系統向業務的開發&測試傳送告警。
在非釋出時間，該系統以10分鐘一次的頻率監控線上業務可用性。
Rest請求返回物件如下。對定時任務，如果檢查失敗，將AppResult物件轉成告警物件傳送給業務開發及測試人員。
有贊.業務級可用性監控介面輸出物件及告警
2.4 合併釋出運作
今年，有贊開發小夥伴超過600+,主站每天需要釋出十幾至二十幾個程式碼分支。有贊開始實行公交車釋出模式，將需要釋出的分支集中後由測試管控釋出。統一部分，一來、測試同學能夠驗證一次核心場景，確保上線質量；二來，可以節省測試投入成本。我們的每次釋出，需要經過前面提到的介面自動化、Ui自動化驗證，及預發環境核心場景驗證。
有贊.公交車系統簡圖
有贊.公交車釋出流程步驟
2.5 工具建設
2.5.1 有贊QA平臺
有贊QA平臺提供了「構造測試資料」「專案質量報告」「專案日報」「環境健康檢查」能力。由Dmm_platform提供統一工具開發標準，然後測試同學完成相關工具開發。
有贊.QA平臺
構造測試資料，通過直接寫DB、或呼叫各業務系統介面來構造測試資料。例如新建帳號、店鋪、不同型別的商品、交易訂單等；
測試報告，包含專案質量報告及專案日報。用於跟蹤專案過程質量、進展、風險及最終專案上線的質量。
環境健康檢查，通過檢查Etcd(有讚的dubbo&Nova註冊中心)服務，判別各應用本該提供的Rest、Dubbo、Nova服務是否正常。以瞭解測試和效能環境，全站應用的執行情況，解決過去測試遇到環境問題，但是不知道那個應用有問題的痛點。
有贊.環境健康檢查
2.5.2 有贊mock服務
作為網際網路應用，依賴部分外部系統實屬正常，例如支付、簡訊、物流等第三方。為了實現可測性、穩定性、高效性和節約成本而構建了Mock服務。例如測試環境訂單支付，真正去付錢，不現實且成本太高；測試環境簡訊若真的通過通訊運營商傳送到手機上，也需要成本。
有贊.Mock服務
2.5.3 有贊安全掃描工具
SecLab單機工具為有贊安全線上掃描系統單機版工具，工具基於Python2.7及Mac OS平臺。主要功能為實現XSS、SQL注入、安全配置檢查錯誤等問題的工具化掃描，提供與《通用基礎安全測試用例》相配套的安全測試工具能力，降低在此類安全問題測試上的人力與時間投入。
有贊.安全測試工具
2.5.4 有贊效能測試平臺
效能測試平臺簡化了效能測試的步驟，提高了測試的效率，使得普通測試工程師也能方便地進行效能測試。平臺後端引擎採用普遍使用的Jmeter，並能實時收集、展示效能資料（響應時間、TPS、併發使用者數等），自動採集並實時展示監控資料（如Linux系統的CPU使用率、系統負載等，JVM GC的eden、S0、S1、old區的使用率，垃圾回收的次數、時間等）。
有贊.效能測試任務與結果
2.5.5 建設中的工具
2.5.5.1 Carmen測試平臺
該平臺開始一種新的嘗試，即實現測試用例管理，又能夠將用例自動化與用例繫結在一起；重點解決開發也可以幫忙維護自動化用例，並提供精準用例驗證開發程式碼質量。第一版提供用例維護、單用例測試，批量用例測試。該專案後期將整合到測試工作臺中。
用例維護，可以錄製用例的基本資訊，執行的環境、用例執行結果校驗。
批量用例測試，開發或者測試人員，可以根據專案的需求，選擇需要的測試用例群，並建立一個用例任務。過後，再回頭檢視任務的執行情況。
用例測試執行，按照Carmen的呼叫規則，組裝測試執行。這裡重點解決用例依賴、測試結果檢查。測試結果檢查分三期：一期、根據靜態檢查資料，檢查返回資料；二期、採用Goovy等方式支援能夠到資料庫核查。三期，接入Diffy平臺，實現測試分支與master環境測試結果的去燥比對。
2.5.5.2 持續整合平臺
持續整合平臺一期主要實現可流程化配置業務應用釋出順序並與測試自動化相結合的工作流，同時提供自動執行及外部觸發的執行模式。
隨著有贊系統的SOA服務化程序，系統依賴越來越複雜，根據事先定義的系統依賴關係，計算合理的應用釋出順序；並最終與Sona、自動化專案等相結合；實現釋出、單側覆蓋率統計儲存、測試覆蓋率統計儲存等。
持續整合同時實現與Gitlib對接，根據應用程式碼commit情況，自動或定時更行應用程式碼；同時提供Restfull介面，供外部觸發工作流或查詢相關資料。
2.5.5.3 測試工作臺
該工作臺的目標是把測試小夥伴平時奮鬥的成果展示出來，即可以回顧，也可以預警。例如某個產品線，近一個月自動化用例及相關應用的覆蓋率變化曲線如何；測試同學參與了哪些專案，專案的提測質量、測試質量、相關報告及風險點。第一期的 主要目標，從應用到專案到人員的維度，及從專案到應用到人員的維度檢視當前的團隊工作情況。
有贊.測試工作臺雛形
#有贊.測試團隊介紹(二)之團隊建設
之前，我們在《有贊.測試團隊介紹(一)》介紹了有贊測試團隊日常工作情況。本文來講講從我入職有贊後看到的整個測試團隊發展與變化。 我16年加入有贊，當時測試團隊只有17位測試同學，一年半以後的今天，測試團隊已經有50+同學了。大部分同學已在網際網路行業深耕多年，當然也有從傳統行業轉型過來的。我從事通訊運營商產品測試6年。同學們的能力各有所長，包括在白盒測試、安全測試、效能測試、工具研發……。測試同學的職責也從之前的業務測試，向度量產品質量與研發測試效率工具轉變。
下面，我們從小夥伴能力培養與融入團隊兩方面展開介紹。
##一、小夥伴能力培養
這裡我們主要從新人到老人，從初級到高階的過程介紹。
1.1 新人入職
在有幸加入有讚的第一天，辦理完入職手續後續後，HR天使會領著小夥伴到各團隊辦公地點參觀並作些必要的介紹，以便於大家瞭解公司的情況。之後，有伴會去把新同學帶回來。
有伴，顧名思義，就是新夥伴的Buddy，由團隊TL指定，在新夥伴入職時介紹給對方；直至轉正，需要持續的關注新同學和提供幫助，陪伴融入，共同成長；下面介紹測試團隊關於新人融入的培養。
新人可以拿到《有贊環境知多少.key》文件，介紹如下內容。
- 環境，介紹有贊現有測試工作環境，包括開發環境，測試環境、預發及線上環境。
- 基礎應用，支援整個系統執行的基礎服務，包括ZK、yz-haunt、Nginx等；介紹這些基礎應用是如何配置及如何檢視日誌等工作中需要涉及的內容。
- 應用依賴關係，有贊系統現在的基本情況、系統間依賴關係，現在有贊有那些型別的系統。
- 卡門測試，介紹通過有贊卡門測試業務時，該怎麼入手。
- 系統間呼叫，介紹各型別系統間是如何呼叫的。例如，主站系統如何呼叫其他Restfull Soa服務，如何呼叫Dubbo\Nova Soa服務；Php服務化專案如何呼叫其他專案。這些呼叫依賴是如何配置的。
同時文件《2017年4月12日XXXXX分析思路.pdf》會給出基於上面的介紹內容，從實戰角度介紹在有贊工作中，如何排查問題。
為期3個月的試用期裡，有伴還會在很多方面手把手指導新同學如何快速適應有讚的日常工作。當然包括如何使用Mac Book電腦。
公司層面會組織一個禮拜脫產入職培訓，介紹公司發展歷程、公司文化、如何開店等。還有脫產兩天到有贊技術大學學習以下內容。
1.2 業務梳理與分享
我們堅信測試方案設計的深度如何及專案風險評估能力高低等在一定程度上，取決於測試同學對業務熟悉程度及對周邊業務的瞭解程度。所以，我們要求測試同學閱讀自己負責的業務線程式碼，並整理成文件，文件需要從巨集觀到微觀描述業務。總體上包含如下內容
- 該業務的全景概況，描述它有哪些業務，每個業務的使用角色都有哪些。
- 該業務的總體資料模型。
- 該業務裡存在哪些業務物件，例如交易訂單，物流單、退款單等。
- 該業務裡的業務物件是否存在生命週期，生命週期如何扭轉。例如交易單，它會有待支付、已支付、已發貨、已關閉等狀態。
- 對於每個業務點的描述，除了文字外，還應該有流程圖或者時序圖，能夠直觀的描述業務。
業務文件整理好了，小夥伴可以把業務分享約起來了。用最通俗的語言，讓不知道該業務的同學，瞭解該業務，以便於他們在工作中做參考。例如他手裡有個專案，他可以評估，他的專案對你是否有影響。
經歷這個過程，小夥伴的文件能力與演講能力都會在一定程度上得到提升。
1.3 測試能力培訓
隨著有贊系統的複雜度越來越高，系統使用者越來越多。我們對系統的要求也隨之提高，那麼，測試能力也需要不斷提升。從一般的業務測試、再到專項測試。
1.3.1 測試基本功-業務測試能力
業務測試能力的培養，我們準備了從測試小白到測試進階分三個階段的能力培養教程。
第一階段，測試入門級培訓,從最簡單的，以例項介紹出發，講解如何測試。
以頁面基本元素為例，介紹了常見的Html標籤如何測試。
對於檔案上傳測試，除了測試檔案是否能夠正常上傳，上傳後驗證外；測試時，還需要再考慮下如下內容。
第二階段，中級能力培訓，主要以專案實戰為例，介紹一個專案的測試方案設計該如何思考。
這裡以具體中型專案為例介紹專案如何拆解，該從哪些方面思考測試關鍵詞，每個業務點如何思考和設計。例如，什麼時候需要考慮冪等，什麼時候需要考慮資損防控。
這裡就需要知道對於有贊系統，哪些是使用者資產，例如，錢、使用者資源、可用訊息資源。例如微信公眾號每個月只能給使用者推送3次訊息，那這3次就不能隨便浪費，不能因為系統設計缺陷導致浪費，否則就是資損。
第三階段，大型專案測試方案如何設計、專案管控與管理進行介紹
該階段，部分比較抽象，偏向理論，需要有一定的測試工作經歷。這裡就展開介紹。
1.3.2 測試專項-安全測試
有贊今年成立安全測試小組，負責公司安全意識培訓與安全檢查。同時，我們制定日常專案安全測試培訓及實戰案例，並搭建環境給小夥伴親身實戰安全測試。
公司資訊保安意識宣講
日常專案測試培訓大綱內容。這裡會詳細介紹每個測試點的解釋、如何測試、如何避免等。
安全測試案例
1.3.2 測試專項-效能測試
效能測試已成為我們日常工作的一部分。如果你是效能測試的老司機，入職有贊後，你可以成為專項測試小組一員，給其他小夥伴提供幫助。如果你在效能測試剛入門，你可以到專項測試小組裡尋求指導和幫助，學習如何做效能測試和效能測試分析。這個後面我們推出效能測試入門部落格來專門介紹。
1.4 技術提升計劃
在《有贊.測試團隊介紹(一)》提到，我們在做一些效率提升工具。這些工具建設，由資深測試開發工程師設計，帶領其他測試開發工程師實施完成。前端使用AdminLte或者Vue框架，後端以Spring、Spring boot、Goovy等來開發。這裡就會遇到之前沒有學過的，那就需要學習。
學習就會學習計劃和作業。我們給不同同學指定不同學習任務，然後每天發學習日報。每週做一次學習分享。學習了2、3周後，開始投入到專案。
