迴歸網易 9 個月來的測試團隊轉型之路

在外遊蕩一年回到網易，進到平臺交友事業部，專一於移動互聯網 APP 研發測試領域，在將近一年來的時間裏，經歷了開發、測試團隊的轉型，下面跟你們講述講述帶領測試團隊從挖掘痛點的轉型之路，但願能給各位一點幫助。

測試團隊現狀

這個部門人員朝氣蓬勃，我的認爲更像一個創業型的公司，初期技術資源都投入到產品功能需求開發中，對於產品質量稍做妥協，不須要太嚴格的過程控制和質量把控，相比開發資源而言，測試的投入資源不是那麼急需。

隨着用戶量的上升，各類類型的移動設備問題錯綜複雜，用戶對產品的質量有要求，部門老大對質量愈來愈重視，狠抓這塊，從 2017 年 Q四、2018 年 Q1 分別招入兩批測試人員，整個技術團隊對於質量把控的訴求愈來愈強烈了，到後來整個測試團隊跟隨開發團隊的規模壯大而壯大起來了。

測試技能現狀

全部產品線的測試手段都是以手工測試爲主，自動化輔助手段較少，迴歸測試成本高，Android、iOS 獨佔測試人員忙於業務的功能性需求的黑盒測試，非功能性需求沒法知足。

Android、iOS 與後端 Server 進行數據交互的 API 規範定義是一致的，早期無相關測試人員參與，致使發現 API 問題較晚，推遲到客戶端功能開發完成階段才進行檢驗，同時也形成後端 API 迴歸成本高；

功能測試以及 API 相關測試在研發測試過程走一輪、預發佈環境第二輪、生產環境走第三輪，深度依賴於手工測試，發現問題滯後，相比需求、研發階段修復的成原本說，發現的階段越晚修復成本越高，最終可能致使帶着嚴重問題上線運營。

測試流程現狀

交付式測試，開發人員把相關功能任務設置爲 done 以後交付給測試人員，測試人員未全程參與從需求源頭開始跟進（及時瞭解需求背景和細節，消除需求含混性，及早開展測試用例編寫工做），從而研發過程當中客戶端功能、後端 API 的可測試性（一個完整的功能是能夠分多個功能小點提測，最終完整再提測一次）沒法提升，測試人員也沒法及早進行冒煙測試；

無測試人員專屬的持續集成構建環境，Android、iOS 打包依賴開發，測試人員存在時間等待上的開銷成本一直存在未能下降。

測試三輪驗證：測試環境驗證第一次、預發佈驗證第二次、生產驗證第三次，爲何作三輪，這三輪的評估依據是什麼？

整個測試過程，只有測試人員參與，產品、客戶端開發同窗的協助如何提高融入進來呢？

測試任務評估沒有依據

針對需求的相關測試任務，出牌評估工時，沒有評估依據，直接拍腦殼進行，體如今：這個需求須要測試哪些方面？涉及客戶端 Android、iOS 哪些特性？有哪些兼容性須要測試？只有把全部相關點列出來，評估完整的時間，再進行合理的取捨，讓質量維度維持在一個可接受的平衡點，而不是一味追求最高質量，每每不少時候，利用現有資源作最平衡的質量優化，可接受的容忍度。

所謂平衡點的簡單例子：

1. 字體樣式的問題，並不是致命的，能夠權衡接受跟着上線；
2. 客戶端列表過長溢出，沒有邊界判斷機制，這就是致命的，必須修復上線；
3. 客戶端數據出錯了，後端還能夠經過快速發佈來解決，並不影響客戶端的上線；

圖 - 改進的測試評估依據

生產力改進實踐

生產力改進實踐環節，是圍繞幾個大方面開展的： 若是對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發、面試經驗交流。感興趣能夠175317069，羣內會有不按期的發放免費的資料連接，這些資料都是從各個技術網站蒐集、整理出來的，若是你有好的學習資料能夠私聊發我，我會註明出處以後分享給你們。

圖 - 生產力改造圍繞方面

敏捷開發

創建 Scrum 流程框架（版本開發流程），以此爲基礎的版本開發模式，各個角色緊密配合的 PDCA 循環：高度合做，善於計劃和總結、擁抱變化、高度可視化。

圖 -Scrum 流程框架 - 交友

自研的燃盡圖進度跟蹤工具

過去 Jira 任務管理系統自帶燃盡圖不能根據團隊特色，展現實際進度和體現反饋風險所在，致使錯過反饋進度問題的最佳時間，所以根據團隊特性，自研可以反饋實際進度的燃盡圖，讓項目進度透明化，技術、視覺、交互、產品都參與到風險識別和反饋中來。

帶來的效益：

1. 使用新版燃盡圖以後，每日晨會分析歷史進度問題有依據，可以明顯看出風險所在
2. 產品人員主動關注燃盡圖趨勢變化，及時調整有問題的任務，提升研發交付的時效
3. 每日工時能夠看到研發、測試人員的我的進度，及時溝通遇到的困難，推動解決

圖 - 自研的燃盡圖

負責客戶端的測試人員承擔產品職責單一，技術要求多層次

最初測試人力資源不足，爲了提升更大的複用率，要求每位測試人員負責客戶端 Android、iOS 的兩端的測試工做，編寫一份基礎用例，根據每端特性在測試過程當中再改變策略，落地實施的第一個季度就暴露出問題：

1. 同時兼顧一個產品多個功能的測試任務，對於客戶端開發同窗而言，他們是並行工做的，而測試同窗須要在不一樣功能的 Android、iOS 兩端來回切換，致使效率低；
2. 一樣問題也存在兼顧多個產品的測試任務，有些產品是同時進行的，須要在多個產品的任務中切換，致使對兩個產品都不熟悉；
3. 測試設備佔用時間嚴重，在進行 Android、iOS 輪換切換的場景中，一人獨佔相關設備；

改進：單一職責，專職專責，原則上再也不進行跨項目的版本任務，也不在版本中負責一個功能的 Android、iOS 相關測試任務（除了運營的相關活動項目能夠兼顧 Android、iOS 測試），主攻 Android、iOS 單一方向的功能測試、自動化測試，說的高大上一點好像成了全棧測試工程師。

實施半年以後，收益頗深，各自負責 Android、iOS 的測試同窗結對編寫測試用例，抽取共性部分，運行時附加個性化的系統特性，並行測試效率提升，設備佔用率下降。

自研的 API 管理和測試平臺

過去後端的 API 規範是經過 word 文檔進行管理，版本變動是須要手動通知相應人員，並且每一個人編寫的格式不統一，容易形成衝突，解決上有時間開銷，另外修改跟蹤反饋上的成本很高，開源項目中也沒有可以適合交友團隊模式的工具，所以投入開發 API 管理和測試平臺。

考慮到客戶端與後端交互是經過 API 進行，將 API 平臺化管理帶來效益：

1. 使用平臺化管理清晰呈現 MobileAPI 接口分佈圖，有效減輕了後端同窗管理接口規範的工做 ;
2. 方便客戶端同窗快速查閱和版本對比 ;
3. API 修改歷史記錄對比，修改後第一時間系統自動通知相關人員 ;
4. 在接口定義完以後，可直接生成 API Mock，節約手工寫 mock 接口的時間，客戶端同窗能夠直接開始開發工做，與後端開發並行 ;

功能點包括如下三個方面：

API 統一規範

支持在線管理接口規範文檔：接口規範管理功能有不少特性，包括自動生成 change log，自動生成技術審查的規範文檔，review 通知，接口版本管理，支持任意歷史版本的對比，方便追蹤每一個版本的變化。

後端同窗只須要專一於接口定義，大大節約了文檔維護的時間，更早投入開發工做。

圖 -API 規範示例

圖 - 歷史版本 diff 對比

API 模擬調試

平臺支持從接口規範文檔直接生成 API Mock，在後端接口開發完成以前，前端、客戶端的同窗利用 Mock Server 擺脫後端接口的依賴，直接開始開發工做，與後端開發並行。

圖 -API 模擬調試節省時間

API 自動化測試

平臺支持從接口規範文檔直接生成 API 測試用例，測試人員集中參與關鍵場景編寫，執行用例以後自動生成測試報告咯，測試同窗能夠在後端開發的同時，寫好測試用例，在開發完成後作冒煙測試，以及迴歸測試，提高測試效率。

圖 -API 自動化用例流程

圖 -API 自動化測試報告

持續集成與靜態代碼分析

過去代碼構建在開發人員本地進行，每次提交在解決衝突上時間開銷大，每一個環節發現的問題滯後，沒法自動化集成、按需構建，以及代碼的質量沒有數據參考。

團隊須要引入有效的自動化構建平臺，以及靜態代碼分析平臺，用以指導平常開發過程的質量改進，將代碼問題的反饋機制自動化，構建數據可視化。

持續集成

爲了讓產品能夠快速迭代，同時還能保持高質量。技術團隊對各產品的各端都創建了持續構建平臺：在代碼集成到主幹以前，必須經過自動化測試。只要有一個測試用例失敗，就不能集成。保證持續地發現、反饋和解決問題。

圖 - 美聊持續集成

靜態代碼分析

爲了保證代碼質量，從代碼層級下降線上出錯的可能性，技術團隊引入了靜態代碼分析技術：在不執行計算機程序的條件下，對源代碼進行分析，找出代碼的設計缺陷，例如代碼規範、內存泄露，以及體現整體質量：代碼覆蓋度、技術債務的趨勢圖，通知技術改進，攔截在上線以前，這些數據都成爲 QA 統計的數據來源。

圖 -Sonar 靜態代碼分析 qa 儀表盤（Java、iOS、Android）

客戶端手工覆蓋度數據收集工具

過去執行完測試用例以後，沒法考量哪些代碼覆蓋了，哪些沒有覆蓋，測試用例寫的好很差，爲了解決這些困境，在客戶端 Android、iOS 植入手工測試覆蓋度工具，收集代碼覆蓋度展現，目的是找出測試過程當中未被覆蓋的代碼，指導測試人員調整測試策略，開展探索式測試。

圖 - 客戶戶端 UI 手工測試報告

下圖是執行美聊 2.8 版本 iOS 相關用例後的統計結果，能夠根據結果調整測試策略，例如：若是改動了登陸模塊，目前用例覆蓋度比較低，那是須要增強特殊場景測試，仍是其餘方面呢？這個須要團隊 review 下作出決定。

圖 - 美聊 2.8-iOS 手工覆蓋率

利用 BugTags 工具的問題反饋

過去發現線上問題無有效收集數據的手段，用戶反饋以後，須要相關人員跟進溝通，詢問環境、設備等諸多問題，整個過程繁瑣，人力投入開銷大，引入 BugTags 是爲了簡化 Bug 提交過程，記錄重現場景相關信息，將客戶端的大量複雜操做最大限度簡化。經過白名單機制，美聊可讓用戶打開 Bugtags 搖一搖問題，提交用戶的相關環境、設備信息，進一步推動排查問題的效率。

若是對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發、面試經驗交流。感興趣能夠175317069，羣內會有不按期的發放免費的資料連接，這些資料都是從各個技術網站蒐集、整理出來的，若是你有好的學習資料能夠私聊發我，我會註明出處以後分享給你們。

圖 -BugTag 競品分析

BugBash 質量活動

傳統的產品走查，產品、視覺、交付、運營只對本身負責的功能部分有了解和檢查，缺少一個需求方的總體走查。當有人發現一些功能間互相關聯的問題時，已經比較晚，修復成本高。引入 Bug Bash（所謂 Bug 大掃除的活動），在項目開發階段的末期，專門劃出一個專門的時間段（一般 1 天），打破以往非技術人員未參與的作法，在這期間全部參與項目的人員（技術、產品、交互），集中所有精力，運用各方面的知識來搜尋項目的 Bug，作到及早發現問題。

圖 -Bugbash 流程

會後將問題彙總，用以推進開發改進功能。

圖 -Bugbash 記錄

QA 數據收集

在 Sprint 總結會上爲了讓項目成員能更加清楚瞭解整個 Sprint 的質量、進度問題，從 Q4 開始對每一個 Sprint 都作了數據收集和展現。經過收集每一個迭代版本的工時、bug 數據，在總結會上向全體人員（技術、產品、視覺、交互、運營）呈現當前版本整體質量多維度數據，指導工做的改進方向。

· 按照階段的 bug 分佈展現

圖 -bug 分佈展現

按照組件的 bug 分佈展現

圖 - 組件分佈展現

Android Monkey 崩潰性測試

持續集成環境每日代碼 daily build 以後，夜間在測試專屬服務器進行長達幾個小時的 Android Monkey 崩潰性測試

圖 -Android Monkey 崩潰性持續構建

圖 -Android Monkey 崩潰性測試報告

兼容性質量風險控制轉移

目前交友測試團隊現有的 Android 測試機型不足，爲了解決 Android 碎片化，特別是兼容性問題，藉助公司內部的易測平臺來控制質量風險。

圖 - 網易易測

圖 - 網易易測：美聊基礎兼容性測試

圖 - 網易易測：花田基礎兼容性測試

重點關注基礎兼容性：安裝、啓動、monkey 隨機、卸載。

團隊人才建設

17 年初的測試團隊規模過小了，業務測試需求不足以知足，人員技能集中在黑盒測試，沒有移動 UI 自動化測試、後端 Server API 自動化測試、測試平臺開發的相關經驗，而且全員對於 Android、iOS 代碼不瞭解，白盒測試無實踐經驗，也會致使排查問題不夠深刻了解原理。

從 17 年 Q2 開始制定團隊建設技術，那麼整個測試團隊的關注點是什麼，如何聚焦，根據技術整體需求、產品需求來落實測試需求呢？

根據團隊特性，測試、開發劃分了邊界，只有從這些方面出發，才能更好要求組員的技能造成階梯化，以及在招聘要求是按照此需求來落地，市場上大有可爲之人，如何切實際爲之更重要，下面從幾個方面來談談。

測試團隊關注點

Martin Fowler 在博客中解釋了TestPyramid，以下圖所示：

圖 -Martin Fowler：TestPyramid

若是對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發、面試經驗交流。感興趣能夠175317069，羣內會有不按期的發放免費的資料連接，這些資料都是從各個技術網站蒐集、整理出來的，若是你有好的學習資料能夠私聊發我，我會註明出處以後分享給你們。

單元測試是第一道測試關卡，也是一個陷阱，測試人員若是投入到此環節上，將是一種資源耗盡型的質量活動。比業務熟悉程度，測試人員沒有開發人員高深，比寫單元測試的效率，測試人員沒有開發人員高效，這裏交友測試團隊也跳坑了，歷經一個季度跳入、跳出，理想的狀態下是：開發的框架很鬆耦合，例如使用了 MVP/MVVM 開發模式，實際狀況是這些技術債務在逐步償還，熟悉代碼的開發人員進行單元測試都有阻礙，測試人員談何容易，簡單點來講遊手好閒，投入產出比低。

真正要從業務需求的痛點出發挖掘適合團隊的方向：測試層次的關注點是最清晰的一條分水嶺隔離開發代碼級別的：單元測試、集成測試，測試人員真正的關注點是：以手工測試爲主，自動化爲輔的發展階段，同時圍繞整個研發測試過程的質量反饋，包括：需求階段、開發階段、發佈階段、運營階段。

圖 - 測試層次關注點

理清整個需求以後，就是團隊成員角色轉型：

圖 - 崗位的轉變

分爲三種：

基本職能：手工測試工程師，進階職能的：自動化測試工程師，再高級一點，測試開發工程師，其實也能夠稱爲全棧，名字不是最重要，也不會設立這種 title，只是要明確把活給細分出來。

最後，根據需求，也把產品測試人員分佈明細理順了：

按照此規劃來落地招聘需求，避免因人設崗，而是實實在在的產品需求、技術需求來決定人才所向。

測試團隊文化建設

因爲篇幅有限，簡單來講造成學習分享的技術氛圍，讓測試人員按期組織技術分享，這些技術主要是能夠用於生產落地以及對新技術的調研成果展現都可，另外有一些虛擬組設置，例如：自動化測試組、平臺開發組，用於把興趣相同的組員融合到一塊兒，投入到合適的方向上。若是對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發、面試經驗交流。感興趣能夠175317069，羣內會有不按期的發放免費的資料連接，這些資料都是從各個技術網站蒐集、整理出來的，若是你有好的學習資料能夠私聊發我，我會註明出處以後分享給你們。

以上是本人在網易交友事業部一年以來對測試團隊轉型帶來的分享，在合適的階段對測試資源作合理的投入是有必要的，發展初期的困難適當取捨產品質量，換來更多功能亮點吸引用戶，佔領市場，站穩腳步，發展中期，確保用戶的活躍、穩定，是須要靠產品質量取勝的，產品功能並不在於多花俏，有新意、簡單化、易傳播這幾個點能夠適當考慮，其實到了中後期，技術不少處於還債階段，以前設計的系統業務模塊解耦、微服務化，提升可測試性都很是重要，而測試人員每每對於技術還債的重構要更加留意，一不當心就掉進坑裏，久久不能自拔，同時最後犧牲最寶貴的就是測試質量，這是須要取捨的，別覺得質量就是高高在上，測試團隊的利益應當與開發、產品團隊的保持一致，這纔是發展的硬道理。