https://testerhome.com/topics/10231
轉載的目的是為了讓讀者知道比較成熟的測試團隊除了業務測試外，在平台開發方面有哪些嘗試，讓進階測試人員知道如何向測試開發專家發展
測試團隊負責相關項目具體測試工作、自動化建設、合并釋出流程管控、設計開發線上業務級别可用性監控、同時在研發提升測試效率的工具。
有贊測試職位主要負責度量産品品質及研發測試效率工具。從度量産品品質角度講，有贊測試人員需要具備白盒測試能力、CodeReview能力、業務功能測試，進而實作核心系統可持續自動化測試，保障系統在頻繁釋出情況依然是穩定的、高可用的。對于效率工具研發，測試同學完成相關第三方mock(例如短信、支付)、應用級健康檢查、線上業務級可用性監控、持續內建工具、UI自動化、測試工作台、性能測試平台、全鍊路性能壓測等。
詳細介紹：
一、基本概況
有贊，旨在為商戶提供強大的微商城和完整的移動零售解決方案，是一個移動零售服務商，正在新零售的潮流中激流勇進、開疆拓土，用産品技術撬動巨大的市場。有贊擁有世界級的 SaaS 電商解決方案，每天處理幾百萬訂單、幾億條消息，且量級仍在不斷攀升中，有贊還開放了有贊雲，連接配接數十萬開發者，大大提升了SaaS 對商家産生的價值。
有贊測試團隊三分之二以上成員來自于阿裡、騰訊、網易等公司，他/她們分别在電商事業部、零售事業部、餐飲事業部、支付事業部及共享技術事業部等部門貢獻自己的力量。
有贊.共享技術測試團隊+HR天使團
二、我們的日常工作
測試團隊負責相關項目具體測試工作、自動化建設、合并釋出流程管控、設計開發線上業務級别可用性監控、同時在研發提升測試效率的工具。
有贊測試職位主要負責度量産品品質及研發測試效率工具。從度量産品品質角度講，有贊測試人員需要具備白盒測試能力、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插件呈現測試報告。
有贊.UI自動化标準接口
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 測試工作台
該工作台的目标是把測試小夥伴平時奮鬥的成果展示出來，即可以回顧，也可以預警。例如某個産品線，近一個月自動化用例及相關應用的覆寫率變化曲線如何；測試同學參與了哪些項目，項目的提測品質、測試品質、相關報告及風險點。第一期的 主要目标，從應用到項目到人員的次元，及從項目到應用到人員的次元檢視目前的團隊工作情況。
有贊.測試工作台雛形
後續看點
在下一期，我們将主要介紹有贊測試團隊對小夥伴的培養，及為提高團隊間信任度所做的努力。培養包含前面提到的需求分析、測試方案設計、專項測試等，但不僅限于此。