质量保障之路：达达测试团队成长记
一 基本概況
達達-京東到家是中國領先的同城速遞信息服務平臺和無界零售即時消費平臺。達達目前已覆蓋全國 400 多個主要城市，服務超過 120 萬商家用戶和超 5000 萬個人用戶，日單量峰值達到千萬級；京東到家已覆蓋北京、上海、廣州等近 40 個主要城市，注冊用戶 5000 多萬，月活躍用戶超 2000 萬，日單量峰值突破 100 萬單。依托達達的高效配送和大量優秀零售合作伙伴，京東到家為消費者提供生鮮蔬果、日用百貨、醫藥健康、鮮花蛋糕、個護美妝等海量商品1小時配送到家的極致服務體驗。
達達-京東到家目前有上海，北京，成都3個研發中心，負責同城速遞信息服務平臺“達達”的研發主要在上海研發中心，本文主要介紹上海研發中心測試團隊（下文簡稱上海測試團隊）的日常工作內容。
二 我們的日常工作
上海測試團隊圍繞保障項目快速上線并穩定運行這一核心目標來組建，主要的工作內容除了業務和技術項目的質量保障，還包括各類流程規范的制定及優化，自動化建設，持續集成，性能測試，開發提升研發中心效能和質量的平臺等。
2.1 項目質量保證
上海測試團隊不僅是對產品功能負責，而是對整個項目的質量負責。從產品需求分析，開發設計評審，測試方案設計，功能測試，性能測試，回歸測試，線上驗證，項目流程跟進等多方面確保線上系統穩定性。
2.1.1 產品需求分析
項目流程中，問題越早被發現，解決的成本越低。盡早發現產品需求的問題，對提升整個項目質量，提高過程效率，都有極大的幫助。
2.1.2 開發設計評審
清晰合理的開發設計可以避免很多“坑”，既有利于后續業務擴展，代碼重構，又可以有效提升系統穩定性。
2.1.3 測試方案&用例設計
測試方案和用例設計是測試的核心。執行測試用例之前，測試人員需要明確被測對象，測試范圍，測試方法，測試計劃，測試用例等內容，這些內容都需要在方案和用例中體現。不經過分析，思考和計劃就開始執行測試的行為存在極大的漏測風險。目前，上海測試團隊用思維導圖進行方案和用例的設計及管理。
2.1.4 線上功能驗證
產品功能發布后的驗證是項目流程中非常重要的環節。功能發布后如果不第一時間做驗證，將驗證交給用戶，是非常危險的舉動。
2.1.5 項目流程跟進&總結
測試人員除了項目測試以外，還承擔著項目流程管理的工作。目前項目迭代我們采用敏捷開發方式，項目過程中人人都可以是項目經理。
很多項目中，測試人員會擔任項目Owner，組織晨會，跟進進度，確保項目進程中各個關鍵節點按計劃完成。項目上線后組織復盤總結，梳理和優化各類流程，落地質量文化，提升全民質量意識。
目前，上海測試團隊已經總結輸出包括常規項目流程，跨團隊項目流程，App發布流程，事故處理流程等穩定性規范，并已經將這些規范落地到日常項目實踐中。同時團隊內部已經整理出了缺陷提交模板，線上問題回溯模板，線上問題跟進流程等規范。
2.2 自動化
自動化測試常見的實現方式，從上至下有：UI自動化、接口自動化、單元測試這幾大類。
達達-京東到家的業務發展迅猛，更新十分頻繁，所以高投入價值有限的UI自動化暫不適用。
接口自動化在所有的自動化測試中是投入產出比最低的一種，能極大節約回歸測試的時間，也是我們后端項目上線的必要條件（目前，全量接口自動化回歸測試百分百通過作為上線標準）。接口自動化在上海測試團隊從一開始的Jmeter簡單實現主流程接口的自動化，到現在使用Python+Unittest實現了區分接口全量用例、冒煙用例，已經有2年。
所有接口自動化用例均由業務測試同學自己編寫，在梳理個人業務線接口的同時，也能更好地提升代碼的能力，最終具備代碼走查能力。
圖：接口冒煙自動化用例執行結果
單元測試能將問題盡早暴露出來，覆蓋越完全的單元測試越能發揮出其巨大價值。在2017年，我們開始著力推動開發工程師實現單元測試，目前已覆蓋了大部分團隊的項目，配送端二級項目嚴格執行著：每次代碼提交時都會自動觸發單元測試，并根據單元測試結果判斷是否能夠進入CodeReview環節。圖：單元測試構建成功后自動提交CodeReview
2.3 工具建設
2.3.1 One平臺
在原來的項目流程中，從需求建立、研發、測試、上線等過程，需要經歷多個平臺，這樣是非常低效且易出錯的，任何一個環節遺漏或操作失誤都可能演變成線上事故。One平臺就是在這樣一個背景下誕生的，抱著集成多平臺，實現「All in One」–由繁化簡的目的，實現了三大功能：
Devops實踐-提升效率利器
實現One平臺與持續集成相結合，高效部署測試環境，集成Docker與K8s后，解決了原測試環境一次只能供一個測試進行測試工作的瓶頸，使項目流程更通暢便捷，極大提高了效率。
項目流程-保障穩定性的手段
互聯網時代下的輕量敏捷，小步快跑也要保障質量。在整合多平臺的過程中，我們重新梳理并定義了通用項目流程，所有的項目都必須嚴格按照項目流程執行，使平臺成為把控流程的工具的同時，收集了項目流程中的各項數據，作為分析提高效率、保障穩定性的依據。
工作臺-研發日常小助手
研發小伙伴們每日登錄One平臺后，只需打開工作臺，便可以看到各個狀態下的需求小卡片，以及待處理的各類缺陷，每日工作任務一目了然。
圖：One平臺工作臺待辦缺陷
2.3.2 mock服務
Mock服務有在我們公司有三種應用場景，分別是：壓測Mock服務，對接平臺Mock服務，RAP Mock服務
壓測Mock服務：
應用于常態化壓測，將被測服務的Rpc調用都做了Mock處理，具體實現上，服務本身是一個Mock內核，需要Mock的接口及返回值等內容都從Config中心讀取。在發現服務上使用Consul，可以自動識別不同的壓測環境，拉取Mock服務及被測服務鏈路，以便在不同的環境實現壓測任務。
對接平臺Mock服務：
應用于在APP回歸時，模擬生成7Fresh的訂單數據，是一個簡單的Flask請求，在對接第三方平臺測試中發揮了巨大作用。此外，因為對接平臺的 Qa 環境是提供外部對接商戶聯調使用的，但是我們的Qa 環境有時會出現不太穩定的現象，導致很多對接商戶的聯調受阻。對接平臺在測試環境通過開關，控制測試環境mock化，提升了外部對接商戶的聯調穩定性。
RAP Mock服務：
RAP是可視化接口管理工具，具體的功能這里不展開說明。后端開發可以在這里維護接口文檔，前端開發即可調用rap服務拿到對應的Mock數據，對于日常的前端開發工作來說十分方便。除此之外，在測試接口時，測試也可以在這里直接拿接口信息貼到Postman里使用。
2.3.3 性能測試平臺
隨著達達-京東到家的業務體量逐漸變大，系統穩定性成為一個需要重點關注的問題。我們有三種不同的性能測試模式：核心接口的常態化壓測、日常迭代過程中的接口壓測、大促期間的全鏈路壓測。
常態化壓測以mock服務為基礎，當核心接口涉及改動時，對各個被壓測接口每次進行壓測后的結果與基線數據做對比，當指標在基線上下一定范圍內浮動時，即判斷為壓測通過，本次改動可上線；日常開發迭代中，建立起了一套性能測試準入準出的標準規范，在項目的各個階段，一旦發現有性能風險時，即可按性能測試流程規范展開壓測工作，評估風險后進行調優或上線；在2018年618期間，得益于Consul帶來的鏈路保證，我們首次嘗試了全鏈路壓測，并且平穩地度過了618。
性能測試需求時時刻刻都在發生，為了能更好地展開壓測工作，在下半年我們計劃搭建性能測試平臺，讓性能測試變得更規范也更簡單高效。
2.3.4 JustRun
JustRun起源于2017年的Hackthon，在這次技術盛會上測試團隊首次提出「數據工廠」概念，針對測試同學復雜場景、開發人員自測困難的痛點，解決測試過程中造數據難的問題。
JustRun的命名吻合了其干練、簡明的氣質，生成測試賬號、測試訂單、模擬經典場景等所有操作均一鍵完成，不但減輕了測試人員日常被其他小伙伴們打斷工作、咨詢測試數據的負擔，也為其他小伙伴的工作提供了更便捷的操作，極大提高了整個上海研發中心的工作效率。
圖-JustRun生成訂單
2.3.5 持續集成
我們的持續集成基于Jenkins實現，隨著項目增多，需要適配不同的測試環境，到發展中期還實現了一次業務代碼的重構，當打包方式發生變更時，需要一個一個修改配置，效率低下且容易遺漏，原來使用自有風格部署的模式就漸漸跟不上需求，于是引入了Pipeline資源庫，方便管理Jenkins部署源碼，每次變更只需要修改通用的Groovy源碼即可。
在Devops大熱的這兩年，我們也緊跟潮流，實現了Jenkins和測試環境服務的全量容器化部署，Jenkins支持動態擴充節點進行打包部署，當有打包需求時，自動生成一個新的節點執行任務，執行完成后自動銷毀，減少了因為對Jenkins節點服務器的使用依賴，節省了服務器資源。
在與K8s打通過后，實現測試環境服務的多套環境并行，在與One平臺打通后，解決了原測試環境一次只能供一個測試進行測試工作的瓶頸。
2.4 質量文化建設
互聯網公司項目迭代很快，一個項目從開發到上線往往只有3至4天；需求不詳細，需求變更多，合作開發質量意識不強都會導致測試時間被壓縮，使得項目質量無法得到保障；在這種情況下，僅僅靠測試工程師來保證質量是不夠的。產品經理，運營，開發，測試，運維作為項目的參與者，對項目的最終質量及線上穩定有直接影響，讓大家都建立質量意識，成為項目過程中保障質量的一分子，是很重要的事情。
2.4.1 規范化
沒有規矩，不成方圓。規范是質量，效率和穩定性的基石，上海研發團隊內主要有兩大類規范，一類是流程規范，主要強調需求移交后一直到上線過程中，哪些事情能做，按照什么樣的標準做，哪些事情不能做；另一類是開發規范，主要是為了降低后期的維護成本，提高可讀性提升團隊開發合作效率。
穩定性相關的流程規范包含以下內容：
常規項目流程
代碼變更規范
配置變更規范
Dbrt變更規范
Dba操作規范
運維操作規范
開發規范包含以下內容:Java代碼規范
Python代碼規范
Job開發規范
Kafka使用規范
Git流程規范
2.4.2 常態化
有了規范只是個開始，保證規范能夠落地，讓每個人都清楚明白并嚴格執行，過程中需要做很多事。對于質量意識常態化，我們主要圍繞經驗傳遞和培訓兩個維度來做。
經驗傳遞相關主要做了三件事，一是重大項目的總結，目的是復盤項目過程中各個階段的問題，優化改進流程使得后續的重大項目能夠更加順利。二是經典Bug，測試團隊內部每季度都會評選經典Bug，通過這個活動方便大家分享測試思維和測試方法，拓寬視野，豐富思維，增進溝通，同時也輸出測試策略和測試方法的經驗總結，幫助開發提升自測質量。三是故障Review，質量管理組每周一會組織各個故障相關技術團隊的Leader和組員一起Review故障，分析原因并總結出通用的避免措施。以上的相關內容都會形成文檔化的記錄，放在Confluence上供大家查閱。
整個培訓體系分成兩方面，一方面是新人入職培訓，目標是為了方便大家更快、更全面的了解大研發的各部門、工作規范和工具而安排的專項培訓。培訓的內容包含
公司發展史及企業文化
新達達產品介紹
IT規范和信息安全
穩定性相關流程規范
技術架構
數據庫開發設計規范
另一方面是研發培訓，主要培訓研發項目流程，開發規范，穩定性相關規范（主要是2.4.1規范化里提到的相關內容），目的是為了保障日常的研發效率和質量。上海研發中心內部會為每個新入職的同學在團隊內部挑選一個導師，導師會負責新同學的落地融入，以及這些規范的學習。2.4.3 可視化
一個項目通常需要產品經理、設計師、開發工程師、測試工程師多方參與，共同協作，項目的質量也是靠大家共同保證的，對于各個職位輸出物的質量需要被量化和自動化收集。需求階段，產品經理的輸出物主要是需求文檔，我們會從需求變更次數，臨時需求數，偽需求次數這三個維度來衡量質量。開發階段，開發工程師的輸出物主要是代碼，我們會從打回需求數、自測通過率率、Bug數、線上Bug數、故障數來衡量。測試和發布階段，測試工程師的輸出物主要是缺陷和測試報告，我們主要考察打回需求次數，項目打回數，有效Bug數，和生產環境Bug漏測數。目前上海研發團隊主要采用自研的研發效能平臺來管理項目，以上數據都會通過該平臺采集展現。
原文鏈接
https://mp.weixin.qq.com/s?__biz=MzAwMzg1ODMwNw%3D%3D&mid=2653791900&idx=1&sn=1fdbb69b46c682e0e61240f2fadc73cf&chksm=80edcc70b79a4566eaa485007a6723d9d98f9301e8410c4dff31050b5d11ac01a772ddd41efb&mpshare=1&scene=23&srcid=0919uQa2HSnt8aFyAazuzX6P%23rd
服務推薦
- 蜻蜓代理
- 蜻蜓ip代理
- 代理ip網
- 代理ip
- 微信域名攔截檢測
- 微信域名檢測api
總結
以上是生活随笔為你收集整理的质量保障之路：达达测试团队成长记的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： unsqueeze，squeeze
- 下一篇： 17届智能车图像处理部分讲解