轉載自：http://www.uml.org.cn/Test/201707191.asp

2016年初月回到網易，進入交友事業部，更加專註於移動互聯網APP研發測試領域，在將近一年來的時間裏，經歷了開發、測試團隊的轉型，下面講述帶領測試團隊從挖掘痛點的轉型實踐。

測試團隊現狀

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

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

開發測試人員配比

交友事業部有三款APP產品：同城約會、美聊、花田，一線開發人員總數20人，一線測試人員總數4人，示例如下（2016年Q1統計）：

圖-開發測試人員配比

圖中可見測試開發比例是1:6，Android、iOS端各占一名黑盒測試人員，後端API無相關測試人員參與；

測試技能現狀

所有產品線的測試手段都是以手工測試為主，無自動化輔助手段，回歸測試成本高，Android、iOS獨占測試人員忙於業務的功能性需求的黑盒測試，非功能性需求無法滿足。

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

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

測試流程現狀

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

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

測試三輪驗證：測試環境驗證第一次、預發布驗證第二次、生產驗證第三次，為什麽做三輪，這三輪的評估依據是什麽？

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

測試任務評估沒有依據

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

所謂平衡點的簡單例子：

1.字體樣式的問題，並非致命的，可以權衡接受跟著上線；

2.客戶端列表過長溢出，沒有邊界判斷機制，這就是致命的，必須修復上線；

3.客戶端數據出錯了，後端還可以通過快速發布來解決，並不影響客戶端的上線；

圖-改進的測試評估依據

生產力改進實踐

生產力改進實踐環節，是圍繞幾個大方面開展的：

圖-生產力改造圍繞方面

敏捷開發

建立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搖一搖問題，提交用戶的相關環境、設備信息，進一步推進排查問題的效率。

圖-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隨機、卸載。

團隊人才建設

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

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

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

測試團隊關註點

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

圖-Martin Fowler：TestPyramid

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

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

圖-測試層次關註點

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

圖-崗位的轉變

分為三種：

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

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

圖-測試人員產品線分布明細：2016年Q3

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

測試團隊文化建設

由於篇幅有限，簡單來說形成學習分享的技術氛圍，讓測試人員定期組織技術分享，這些技術主要是可以用於生產落地以及對新技術的調研成果展示均可，另外有一些虛擬組設置，例如：自動化測試組、平臺開發組，用於把興趣相同的組員融合到一起，投入到合適的方向上。

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

另外，在接下來一年有計劃的話，交友測試團隊會把關鍵環節的實踐在infoq逐一分享給大家，敬請關註，最後附上一張《網易交友事業部測試團隊技術棧》：

回到網易8個月測試團隊轉型實踐