測試管理 有贊.測試團隊介紹 (一) 之平常工做

https://testerhome.com/topics/10231

轉載的目的是爲了讓讀者知道比較成熟的測試團隊除了業務測試外，在平臺開發方面有哪些嘗試，讓高級測試人員知道如何向測試開發專家發展

測試團隊負責相關項目具體測試工做、自動化建設、合併發佈流程管控、設計開發線上業務級別可用性監控、同時在研發提高測試效率的工具。 
有贊測試職位主要負責度量產品質量及研發測試效率工具。從度量產品質量角度講，有贊測試人員須要具有白盒測試能力、CodeReview能力、業務功能測試，從而實現核心系統可持續自動化測試，保障系統在頻繁發佈狀況依然是穩定的、高可用的。對於效率工具研發，測試同窗完成相關第三方mock(例如短信、支付)、應用級健康檢查、線上業務級可用性監控、持續集成工具、UI自動化、測試工做臺、性能測試平臺、全鏈路性能壓測等。
詳細介紹：

1、基本概況

​ 有贊，旨在爲商戶提供強大的微商城和完整的移動零售解決方案，是一個移動零售服務商，正在新零售的潮流中激流勇進、開疆拓土，用產品技術撬動巨大的市場。有贊擁有世界級的 SaaS 電商解決方案，天天處理幾百萬訂單、幾億條消息，且量級仍在不斷攀升中，有贊還開放了有贊雲，鏈接數十萬開發者，大大提高了SaaS 對商家產生的價值。 
​ 有贊測試團隊三分之二以上成員來自於阿里、騰訊、網易等公司，他/她們分別在電商事業部、零售事業部、餐飲事業部、支付事業部及共享技術事業部等部門貢獻本身的力量。

有贊.共享技術測試團隊+HR天使團

 

 

2、咱們的平常工做

​ 測試團隊負責相關項目具體測試工做、自動化建設、合併發佈流程管控、設計開發線上業務級別可用性監控、同時在研發提高測試效率的工具。 
​ 有贊測試職位主要負責度量產品質量及研發測試效率工具。從度量產品質量角度講，有贊測試人員須要具有白盒測試能力、CodeReview能力、業務功能測試，從而實現核心系統可持續自動化測試，保障系統在頻繁發佈狀況依然是穩定的、高可用的。對於效率工具研發，測試同窗完成相關第三方mock(例如短信、支付)、應用級健康檢查、線上業務級可用性監控、持續集成工具、UI自動化、測試工做臺、性能測試平臺、全鏈路性能壓測等。

2.1 具體項目測試

​ 有讚的項目分爲標準需求項目、技術重構項目、優化項目、缺陷修復項目。有限的測試資源經過不一樣策略支持着絕大部分業務產品的測試工做。 
​ 第1、對於標準需求項目或者跨多個業務的項目，必定會有測試投入，而且會有一位PTM來協調測試工做。PTM須要確保全部需求點都拆分到各個業務測試同窗手裏，跟蹤相關測試同窗按時提交標準測試方案。當測試方案彙總後，PTM須要評估後續測試過程當中，測試人員如何投入。即哪些業務的功能測試PTM可順帶執行掉，哪些確實須要對應業務線測試同窗來完成，以免一個項目投入過多測試同窗。 
​ 第2、技術重構改造項目，這種通常是單應用或者極少應用改造，但不改變業務使用規則。這類項目測試同窗只要設計測試方案並完成測試用例落地便可，用例的執行由開發自行完成。測試同窗要作的就是對新系統進行自動化覆蓋。若有須要，測試會在上線前作質量check。 
​ 第3、對於小型項目，若是開發的自測場景與測試同窗的測試場景基本一致，那開發自行搞定便可；或者測試同窗把須要特別關注的或者風險點給開發同窗簡單介紹。對於有差別的，測試同窗把差別點向開發同窗描述清楚便可。 
​ 有贊測試同窗拿到具體需求後，按照有贊測試對需求分析和測試方案統一要求，完成相關工做。

有贊.項目協做圖

 

 

2.1.1 需求分析

​ 測試同窗在參加需求評審或者測試方案設計以前，須要認證閱讀需求文檔，從獲取相關的信息： 
​ 第1、這個需求是給哪些角色使用的。例如，高級管理員、普通管理員、庫管人員、覈銷員；仍是買家，是大衆買家仍是特定買家。 
​ 第2、不一樣角色，在什麼環境下使用這個些功能。例如PC後臺、店鋪收銀臺、手機端、仍是有讚的移動終端。 
​ 第3、整個項目是否存在對象的生命週期扭轉，例如訂單對象、店鋪等，它們在什麼條件下會發生什麼樣的扭轉。即明確狀態發生變動的條件規則，確保對象生命週期是有終態的。 
​ 第4、明確每一個業務點的人機交互過程及規則，業務過程是否連貫明確；即如何使用這個需求。 
​ 需求分析後，須要輸出對象生命週期圖、業務時序圖、用例圖、待確認的問題、風險點清單。並就相關問題、風險與產品、開發進行屢次溝通，直到問題獲得明確答覆。

有贊.需求分析.需求拆解

 

 

2.1.2 測試方案設計

​ 1、功能測試設計的完整性，取決於測試人員對需求分析的深刻程度及其經驗。爲了彌補測試同窗經驗不足，咱們梳理了《功能測試.頁面測試.基礎篇》《有贊雲.測試參考規範》《有贊雲.carmen接口自動化參考規範》等供平時設計參考。同時，不按期組織業務分享，提升測試人員的業務全局觀及跨業務耦合與風險評估能力。 
​ 2、提供《有贊.異常測試基本場景》指導測試人員如何考慮異常。包括Redis緩存、消息、大數據定時任務處理、多系統協同等。 
​ 3、有贊有安全測試專員及虛擬小組，提供安全測試方面的指導和工具；針對SQL注入、XSS、越權、業務規則安全、文件上傳&下載、重定向定製常規安全測試用例，指導平常測試。 
​ 4、其它的專項測試，根據實際狀況定義指導案例及分享。

有贊.測試大綱模板

 

 

2.2 自動化開發

​ 前面提到有贊測試開發的職責，自動化是必修課。咱們從接口層、端對端的數據層、端對端的UI層來作自動化建設。有贊前端應用交互與後端業務是分離的，數據經過.json請求獲取或者提交數據。UI自動化依賴於前端元素的穩定性且Selenium測試具備的必定不穩定性，咱們構建了在不打開瀏覽器的狀況，對前端請求數據進行覆蓋的端對端數據層自動化。各層自動化比例以下。

有贊.自動化分佈圖

 

 

​ 1、接口自動化主要包含對Rest、Dubbo、Nova提供的業務接口進行覆蓋。在youzan-boostrap框架上設計了接口自動化框架。根據不一樣業務線構建獨立自動化應用。有贊接口自動化用例總量已經達到3000+，其中商品中心+庫存中心+物流中心的用例總數就達到500+。

有贊.接口自動化項目

 

 

 

​ 2、端對端數據層，基於Spring Aop技術封裝有贊賬號登陸與店鋪切換的前端測試插件yago。測試人員能夠更關注本身的業務自動化開發。

有贊.端對端數據層自動化

 

 

​ 3、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、S一、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 測試工做臺

​ 該工做臺的目標是把測試小夥伴平時奮鬥的成果展現出來，便可以回顧，也能夠預警。例如某個產品線，近一個月自動化用例及相關應用的覆蓋率變化曲線如何；測試同窗參與了哪些項目，項目的提測質量、測試質量、相關報告及風險點。第一期的 主要目標，從應用到項目到人員的維度，及從項目到應用到人員的維度查看當前的團隊工做狀況。

有贊.測試工做臺雛形

 

 

後續看點

​ 在下一期，咱們將主要介紹有贊測試團隊對小夥伴的培養，及爲提升團隊間信任度所作的努力。培養包含前面提到的需求分析、測試方案設計、專項測試等，但不只限於此。