在外遊蕩一年回到網易，進到平臺交友事業部，專注於移動互聯網 APP 研發測試領域，在將近一年來的時間裏，經歷了開發、測試團隊的轉型，下面跟大家講述講述帶領測試團隊從挖掘痛點的轉型之路，希望能給各位一點幫助。
測試團隊現狀
這個部門人員朝氣蓬勃，個人認爲更像一個創業型的公司，初期技術資源都投入到產品功能需求開發中，對於產品質量稍作妥協，不需要太嚴格的過程控制和質量把控，相比開發資源而言，測試的投入資源不是那麼急需。
隨着用戶量的上升，各種類型的移動設備問題錯綜複雜，用戶對產品的質量有要求，部門老大對質量越來越重視，狠抓這塊，從 2017 年 Q4、2018 年 Q1 分別招入兩批測試人員，整個技術團隊對於質量把控的訴求越來越強烈了，到後來整個測試團隊跟隨開發團隊的規模壯大而壯大起來了。
測試技能現狀
所有產品線的測試手段都是以手工測試爲主，自動化輔助手段較少，迴歸測試成本高，Android、iOS 獨佔測試人員忙於業務的功能性需求的黑盒測試，非功能性需求無法滿足。
Android、iOS 與後端 Server 進行數據交互的 API 規範定義是一致的，早期無相關測試人員參與，導致發現 API 問題較晚，推遲到客戶端功能開發完成階段才進行檢驗，同時也造成後端 API 迴歸成本高；
功能測試以及 API 相關測試在研發測試過程走一輪、預發佈環境第二輪、生產環境走第三輪，深度依賴於手工測試，發現問題滯後，相比需求、研發階段修復的成本來說，發現的階段越晚修復成本越高，最終可能導致帶着嚴重問題上線運營。
測試流程現狀
交付式測試，開發人員把相關功能任務設置爲 done 之後交付給測試人員，測試人員未全程參與從需求源頭開始跟進（及時瞭解需求背景和細節，消除需求含混性，及早開展測試用例編寫工作），從而研發過程中客戶端功能、後端 API 的可測試性（一個完整的功能是可以分多個功能小點提測，最終完整再提測一次）無法提高，測試人員也無法及早進行冒煙測試；
無測試人員專屬的持續集成構建環境，Android、iOS 打包依賴開發，測試人員存在時間等待上的開銷成本一直存在未能降低。
測試三輪驗證：測試環境驗證第一次、預發佈驗證第二次、生產驗證第三次，爲什麼做三輪，這三輪的評估依據是什麼？
整個測試過程，只有測試人員參與，產品、客戶端開發同學的協助如何提升融入進來呢？
測試任務評估沒有依據
針對需求的相關測試任務，出牌評估工時，沒有評估依據，直接拍腦袋進行，體現在：這個需求需要測試哪些方面？涉及客戶端 Android、iOS 哪些特性？有哪些兼容性需要測試？只有把所有相關點列出來，評估完整的時間，再進行合理的取捨，讓質量維度維持在一個可接受的平衡點，而不是一味追求最高質量，往往很多時候，利用現有資源做最平衡的質量優化，可接受的容忍度。
所謂平衡點的簡單例子：
- 字體樣式的問題，並非致命的，可以權衡接受跟着上線；
- 客戶端列表過長溢出，沒有邊界判斷機制，這就是致命的，必須修復上線；
- 客戶端數據出錯了，後端還可以通過快速發佈來解決，並不影響客戶端的上線；
圖 - 改進的測試評估依據
生產力改進實踐
生產力改進實踐環節，是圍繞幾個大方面開展的： 如果對軟件測試、接口測試、自動化測試、性能測試、LR腳本開發、面試經驗交流。感興趣可以175317069，羣內會有不定期的發放免費的資料鏈接，這些資料都是從各個技術網站蒐集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。
圖 - 生產力改造圍繞方面
敏捷開發
建立 Scrum 流程框架（版本開發流程），以此爲基礎的版本開發模式，各個角色緊密配合的 PDCA 循環：高度合作，善於計劃和總結、擁抱變化、高度可視化。
圖 -Scrum 流程框架 - 交友
自研的燃盡圖進度跟蹤工具
過去 Jira 任務管理系統自帶燃盡圖不能根據團隊特點，展示實際進度和體現反饋風險所在，導致錯過反饋進度問題的最佳時間，因此根據團隊特性，自研能夠反饋實際進度的燃盡圖，讓項目進度透明化，技術、視覺、交互、產品都參與到風險識別和反饋中來。
帶來的效益：
- 使用新版燃盡圖之後，每日晨會分析歷史進度問題有依據，能夠明顯看出風險所在
- 產品人員主動關注燃盡圖趨勢變化，及時調整有問題的任務，提高研發交付的時效
- 每日工時可以看到研發、測試人員的個人進度，及時溝通遇到的困難，推進解決
圖 - 自研的燃盡圖
負責客戶端的測試人員承擔產品職責單一，技術要求多層次
最初測試人力資源不足，爲了提高更大的複用率，要求每位測試人員負責客戶端 Android、iOS 的兩端的測試工作，編寫一份基礎用例，根據每端特性在測試過程中再改變策略，落地實施的第一個季度就暴露出問題：
- 同時兼顧一個產品多個功能的測試任務，對於客戶端開發同學而言，他們是並行工作的，而測試同學需要在不同功能的 Android、iOS 兩端來回切換，導致效率低；
- 同樣問題也存在兼顧多個產品的測試任務，有些產品是同時進行的，需要在多個產品的任務中切換，導致對兩個產品都不熟悉；
- 測試設備佔用時間嚴重，在進行 Android、iOS 輪換切換的場景中，一人獨佔相關設備；
改進：單一職責，專職專責，原則上不再進行跨項目的版本任務，也不在版本中負責一個功能的 Android、iOS 相關測試任務（除了運營的相關活動項目可以兼顧 Android、iOS 測試），主攻 Android、iOS 單一方向的功能測試、自動化測試，說的高大上一點好像成了全棧測試工程師。
實施半年之後，收益頗深，各自負責 Android、iOS 的測試同學結對編寫測試用例，抽取共性部分，運行時附加個性化的系統特性，並行測試效率提高，設備佔用率降低。
自研的 API 管理和測試平臺
過去後端的 API 規範是通過 word 文檔進行管理，版本變更是需要手動通知相應人員，而且每個人編寫的格式不統一，容易造成衝突，解決上有時間開銷，另外修改跟蹤反饋上的成本很高，開源項目中也沒有能夠適合交友團隊模式的工具，因此投入開發 API 管理和測試平臺。
考慮到客戶端與後端交互是通過 API 進行，將 API 平臺化管理帶來效益：
- 使用平臺化管理清晰呈現 MobileAPI 接口分佈圖，有效減輕了後端同學管理接口規範的工作 ;
- 方便客戶端同學快速查閱和版本對比 ;
- API 修改歷史記錄對比，修改後第一時間系統自動通知相關人員 ;
- 在接口定義完之後，可直接生成 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，羣內會有不定期的發放免費的資料鏈接，這些資料都是從各個技術網站蒐集、整理出來的，如果你有好的學習資料可以私聊發我，我會註明出處之後分享給大家。
以上是本人在網易交友事業部一年以來對測試團隊轉型帶來的分享，在合適的階段對測試資源做合理的投入是有必要的，發展初期的困難適當取捨產品質量，換來更多功能亮點吸引用戶，佔領市場，站穩腳步，發展中期，確保用戶的活躍、穩定，是需要靠產品質量取勝的，產品功能並不在於多花俏，有新意、簡單化、易傳播這幾個點可以適當考慮，其實到了中後期，技術很多處於還債階段，之前設計的系統業務模塊解耦、微服務化，提高可測試性都非常重要，而測試人員往往對於技術還債的重構要更加留意，一不小心就掉進坑裏，久久不能自拔，同時最後犧牲最寶貴的就是測試質量，這是需要取捨的，別以爲質量就是高高在上，測試團隊的利益應當與開發、產品團隊的保持一致，這纔是發展的硬道理。