有人喜歡創(chuàng)造世界舆瘪，他們做了開(kāi)發(fā)者臊岸；有的人喜歡開(kāi)發(fā)者，他們做了測(cè)試員蕉饼。什么是軟件測(cè)試虐杯？軟件測(cè)試就是一場(chǎng)本該在用戶(hù)面前發(fā)生的災(zāi)難提前在自己面前發(fā)生了，這會(huì)讓他們生出一種救世主的感覺(jué)昧港，拯救了用戶(hù)擎椰，也就拯救者這個(gè)軟件，避免了他們被卸載的命運(yùn)创肥。
在外游蕩一年回到網(wǎng)易达舒，進(jìn)到平臺(tái)交友事業(yè)部，專(zhuān)注于移動(dòng)互聯(lián)網(wǎng) APP 研發(fā)測(cè)試領(lǐng)域叹侄，在將近一年來(lái)的時(shí)間里巩搏，經(jīng)歷了開(kāi)發(fā)、測(cè)試團(tuán)隊(duì)的轉(zhuǎn)型趾代，下面跟大家講述講述帶領(lǐng)測(cè)試團(tuán)隊(duì)從挖掘痛點(diǎn)的轉(zhuǎn)型之路贯底，希望能給各位一點(diǎn)幫助。
測(cè)試團(tuán)隊(duì)現(xiàn)狀
這個(gè)部門(mén)人員朝氣蓬勃撒强，個(gè)人認(rèn)為更像一個(gè)創(chuàng)業(yè)型的公司禽捆，初期技術(shù)資源都投入到產(chǎn)品功能需求開(kāi)發(fā)中，對(duì)于產(chǎn)品質(zhì)量稍作妥協(xié)飘哨，不需要太嚴(yán)格的過(guò)程控制和質(zhì)量把控胚想，相比開(kāi)發(fā)資源而言，測(cè)試的投入資源不是那么急需芽隆。
隨著用戶(hù)量的上升浊服，各種類(lèi)型的移動(dòng)設(shè)備問(wèn)題錯(cuò)綜復(fù)雜，用戶(hù)對(duì)產(chǎn)品的質(zhì)量有要求胚吁，部門(mén)老大對(duì)質(zhì)量越來(lái)越重視臼闻，狠抓這塊，從 2017 年 Q4囤采、2018 年 Q1 分別招入兩批測(cè)試人員述呐，整個(gè)技術(shù)團(tuán)隊(duì)對(duì)于質(zhì)量把控的訴求越來(lái)越強(qiáng)烈了，到后來(lái)整個(gè)測(cè)試團(tuán)隊(duì)跟隨開(kāi)發(fā)團(tuán)隊(duì)的規(guī)模壯大而壯大起來(lái)了蕉毯。
測(cè)試技能現(xiàn)狀
所有產(chǎn)品線的測(cè)試手段都是以手工測(cè)試為主乓搬，自動(dòng)化輔助手段較少思犁，回歸測(cè)試成本高，Android进肯、iOS 獨(dú)占測(cè)試人員忙于業(yè)務(wù)的功能性需求的黑盒測(cè)試激蹲，非功能性需求無(wú)法滿(mǎn)足。
Android江掩、iOS 與后端 Server 進(jìn)行數(shù)據(jù)交互的 API 規(guī)范定義是一致的学辱，早期無(wú)相關(guān)測(cè)試人員參與，導(dǎo)致發(fā)現(xiàn) API 問(wèn)題較晚环形，推遲到客戶(hù)端功能開(kāi)發(fā)完成階段才進(jìn)行檢驗(yàn)策泣，同時(shí)也造成后端 API 回歸成本高；
功能測(cè)試以及 API 相關(guān)測(cè)試在研發(fā)測(cè)試過(guò)程走一輪抬吟、預(yù)發(fā)布環(huán)境第二輪萨咕、生產(chǎn)環(huán)境走第三輪，深度依賴(lài)于手工測(cè)試火本，發(fā)現(xiàn)問(wèn)題滯后危队，相比需求、研發(fā)階段修復(fù)的成本來(lái)說(shuō)钙畔，發(fā)現(xiàn)的階段越晚修復(fù)成本越高茫陆，最終可能導(dǎo)致帶著嚴(yán)重問(wèn)題上線運(yùn)營(yíng)。
測(cè)試流程現(xiàn)狀
交付式測(cè)試擎析，開(kāi)發(fā)人員把相關(guān)功能任務(wù)設(shè)置為 done 之后交付給測(cè)試人員簿盅，測(cè)試人員未全程參與從需求源頭開(kāi)始跟進(jìn)（及時(shí)了解需求背景和細(xì)節(jié)，消除需求含混性叔锐，及早開(kāi)展測(cè)試用例編寫(xiě)工作），從而研發(fā)過(guò)程中客戶(hù)端功能见秽、后端 API 的可測(cè)試性（一個(gè)完整的功能是可以分多個(gè)功能小點(diǎn)提測(cè)愉烙，最終完整再提測(cè)一次）無(wú)法提高，測(cè)試人員也無(wú)法及早進(jìn)行冒煙測(cè)試解取；
無(wú)測(cè)試人員專(zhuān)屬的持續(xù)集成構(gòu)建環(huán)境步责，Android、iOS 打包依賴(lài)開(kāi)發(fā)禀苦，測(cè)試人員存在時(shí)間等待上的開(kāi)銷(xiāo)成本一直存在未能降低蔓肯。
測(cè)試三輪驗(yàn)證：測(cè)試環(huán)境驗(yàn)證第一次、預(yù)發(fā)布驗(yàn)證第二次振乏、生產(chǎn)驗(yàn)證第三次蔗包，為什么做三輪，這三輪的評(píng)估依據(jù)是什么慧邮？
整個(gè)測(cè)試過(guò)程调限，只有測(cè)試人員參與舟陆，產(chǎn)品、客戶(hù)端開(kāi)發(fā)同學(xué)的協(xié)助如何提升融入進(jìn)來(lái)呢耻矮？
測(cè)試任務(wù)評(píng)估沒(méi)有依據(jù)
針對(duì)需求的相關(guān)測(cè)試任務(wù)秦躯，出牌評(píng)估工時(shí)，沒(méi)有評(píng)估依據(jù)裆装，直接拍腦袋進(jìn)行踱承，體現(xiàn)在：這個(gè)需求需要測(cè)試哪些方面？涉及客戶(hù)端 Android哨免、iOS 哪些特性茎活？有哪些兼容性需要測(cè)試？只有把所有相關(guān)點(diǎn)列出來(lái)铁瞒，評(píng)估完整的時(shí)間妙色，再進(jìn)行合理的取舍，讓質(zhì)量維度維持在一個(gè)可接受的平衡點(diǎn)慧耍，而不是一味追求最高質(zhì)量身辨，往往很多時(shí)候，利用現(xiàn)有資源做最平衡的質(zhì)量?jī)?yōu)化芍碧，可接受的容忍度煌珊。
所謂平衡點(diǎn)的簡(jiǎn)單例子：
- 字體樣式的問(wèn)題，并非致命的泌豆，可以權(quán)衡接受跟著上線定庵；
- 客戶(hù)端列表過(guò)長(zhǎng)溢出，沒(méi)有邊界判斷機(jī)制踪危，這就是致命的蔬浙，必須修復(fù)上線；
- 客戶(hù)端數(shù)據(jù)出錯(cuò)了贞远，后端還可以通過(guò)快速發(fā)布來(lái)解決畴博，并不影響客戶(hù)端的上線；
生產(chǎn)力改進(jìn)實(shí)踐
生產(chǎn)力改進(jìn)實(shí)踐環(huán)節(jié)蓝仲，是圍繞幾個(gè)大方面開(kāi)展的：
敏捷開(kāi)發(fā)
建立 Scrum 流程框架（版本開(kāi)發(fā)流程）俱病，以此為基礎(chǔ)的版本開(kāi)發(fā)模式，各個(gè)角色緊密配合的 PDCA 循環(huán)：高度合作袱结，善于計(jì)劃和總結(jié)亮隙、擁抱變化、高度可視化垢夹。
自研的燃盡圖進(jìn)度跟蹤工具
過(guò)去 Jira 任務(wù)管理系統(tǒng)自帶燃盡圖不能根據(jù)團(tuán)隊(duì)特點(diǎn)溢吻，展示實(shí)際進(jìn)度和體現(xiàn)反饋風(fēng)險(xiǎn)所在，導(dǎo)致錯(cuò)過(guò)反饋進(jìn)度問(wèn)題的最佳時(shí)間果元，因此根據(jù)團(tuán)隊(duì)特性煤裙，自研能夠反饋實(shí)際進(jìn)度的燃盡圖掩完，讓項(xiàng)目進(jìn)度透明化，技術(shù)硼砰、視覺(jué)且蓬、交互、產(chǎn)品都參與到風(fēng)險(xiǎn)識(shí)別和反饋中來(lái)题翰。
帶來(lái)的效益：
- 使用新版燃盡圖之后恶阴，每日晨會(huì)分析歷史進(jìn)度問(wèn)題有依據(jù)，能夠明顯看出風(fēng)險(xiǎn)所在
- 產(chǎn)品人員主動(dòng)關(guān)注燃盡圖趨勢(shì)變化豹障，及時(shí)調(diào)整有問(wèn)題的任務(wù)冯事，提高研發(fā)交付的時(shí)效
- 每日工時(shí)可以看到研發(fā)、測(cè)試人員的個(gè)人進(jìn)度血公，及時(shí)溝通遇到的困難昵仅，推進(jìn)解決
負(fù)責(zé)客戶(hù)端的測(cè)試人員承擔(dān)產(chǎn)品職責(zé)單一，技術(shù)要求多層次
最初測(cè)試人力資源不足累魔，為了提高更大的復(fù)用率摔笤，要求每位測(cè)試人員負(fù)責(zé)客戶(hù)端 Android、iOS 的兩端的測(cè)試工作垦写，編寫(xiě)一份基礎(chǔ)用例吕世，根據(jù)每端特性在測(cè)試過(guò)程中再改變策略，落地實(shí)施的第一個(gè)季度就暴露出問(wèn)題：
- 同時(shí)兼顧一個(gè)產(chǎn)品多個(gè)功能的測(cè)試任務(wù)梯投，對(duì)于客戶(hù)端開(kāi)發(fā)同學(xué)而言命辖，他們是并行工作的，而測(cè)試同學(xué)需要在不同功能的 Android分蓖、iOS 兩端來(lái)回切換尔艇，導(dǎo)致效率低；
- 同樣問(wèn)題也存在兼顧多個(gè)產(chǎn)品的測(cè)試任務(wù)么鹤，有些產(chǎn)品是同時(shí)進(jìn)行的终娃，需要在多個(gè)產(chǎn)品的任務(wù)中切換，導(dǎo)致對(duì)兩個(gè)產(chǎn)品都不熟悉午磁；
- 測(cè)試設(shè)備占用時(shí)間嚴(yán)重磅甩，在進(jìn)行 Android痒钝、iOS 輪換切換的場(chǎng)景中，一人獨(dú)占相關(guān)設(shè)備酵颁；
改進(jìn)：?jiǎn)我宦氊?zé)衙熔，專(zhuān)職專(zhuān)責(zé)登颓，原則上不再進(jìn)行跨項(xiàng)目的版本任務(wù)，也不在版本中負(fù)責(zé)一個(gè)功能的 Android红氯、iOS 相關(guān)測(cè)試任務(wù)（除了運(yùn)營(yíng)的相關(guān)活動(dòng)項(xiàng)目可以兼顧 Android框咙、iOS 測(cè)試）咕痛，主攻 Android、iOS 單一方向的功能測(cè)試喇嘱、自動(dòng)化測(cè)試茉贡，說(shuō)的高大上一點(diǎn)好像成了全棧測(cè)試工程師。
實(shí)施半年之后者铜，收益頗深腔丧，各自負(fù)責(zé) Android、iOS 的測(cè)試同學(xué)結(jié)對(duì)編寫(xiě)測(cè)試用例作烟，抽取共性部分愉粤，運(yùn)行時(shí)附加個(gè)性化的系統(tǒng)特性，并行測(cè)試效率提高拿撩，設(shè)備占用率降低衣厘。
自研的 API 管理和測(cè)試平臺(tái)
過(guò)去后端的 API 規(guī)范是通過(guò) word 文檔進(jìn)行管理，版本變更是需要手動(dòng)通知相應(yīng)人員压恒，而且每個(gè)人編寫(xiě)的格式不統(tǒng)一影暴，容易造成沖突，解決上有時(shí)間開(kāi)銷(xiāo)涎显，另外修改跟蹤反饋上的成本很高坤检，開(kāi)源項(xiàng)目中也沒(méi)有能夠適合交友團(tuán)隊(duì)模式的工具，因此投入開(kāi)發(fā) API 管理和測(cè)試平臺(tái)期吓。
考慮到客戶(hù)端與后端交互是通過(guò) API 進(jìn)行早歇，將 API 平臺(tái)化管理帶來(lái)效益：
- 使用平臺(tái)化管理清晰呈現(xiàn) MobileAPI 接口分布圖，有效減輕了后端同學(xué)管理接口規(guī)范的工作 ;
- 方便客戶(hù)端同學(xué)快速查閱和版本對(duì)比 ;
- API 修改歷史記錄對(duì)比讨勤，修改后第一時(shí)間系統(tǒng)自動(dòng)通知相關(guān)人員 ;
- 在接口定義完之后箭跳，可直接生成 API Mock，節(jié)約手工寫(xiě) mock 接口的時(shí)間潭千，客戶(hù)端同學(xué)可以直接開(kāi)始開(kāi)發(fā)工作谱姓，與后端開(kāi)發(fā)并行 ;
功能點(diǎn)包括以下三個(gè)方面：
API 統(tǒng)一規(guī)范
支持在線管理接口規(guī)范文檔：接口規(guī)范管理功能有很多特性，包括自動(dòng)生成 change log刨晴，自動(dòng)生成技術(shù)審查的規(guī)范文檔屉来，review 通知，接口版本管理狈癞，支持任意歷史版本的對(duì)比茄靠，方便追蹤每個(gè)版本的變化。
后端同學(xué)只需要專(zhuān)注于接口定義蝶桶，大大節(jié)約了文檔維護(hù)的時(shí)間慨绳，更早投入開(kāi)發(fā)工作。
API 模擬調(diào)試
平臺(tái)支持從接口規(guī)范文檔直接生成 API Mock，在后端接口開(kāi)發(fā)完成之前脐雪，前端厌小、客戶(hù)端的同學(xué)利用 Mock Server 擺脫后端接口的依賴(lài)，直接開(kāi)始開(kāi)發(fā)工作战秋，與后端開(kāi)發(fā)并行璧亚。
API 自動(dòng)化測(cè)試
平臺(tái)支持從接口規(guī)范文檔直接生成 API 測(cè)試用例，測(cè)試人員集中參與關(guān)鍵場(chǎng)景編寫(xiě)脂信，執(zhí)行用例之后自動(dòng)生成測(cè)試報(bào)告咯涨岁，測(cè)試同學(xué)可以在后端開(kāi)發(fā)的同時(shí)，寫(xiě)好測(cè)試用例吉嚣，在開(kāi)發(fā)完成后做冒煙測(cè)試梢薪，以及回歸測(cè)試，提升測(cè)試效率尝哆。
持續(xù)集成與靜態(tài)代碼分析
過(guò)去代碼構(gòu)建在開(kāi)發(fā)人員本地進(jìn)行秉撇，每次提交在解決沖突上時(shí)間開(kāi)銷(xiāo)大，每個(gè)環(huán)節(jié)發(fā)現(xiàn)的問(wèn)題滯后秋泄，無(wú)法自動(dòng)化集成琐馆、按需構(gòu)建，以及代碼的質(zhì)量沒(méi)有數(shù)據(jù)參考恒序。
團(tuán)隊(duì)需要引入有效的自動(dòng)化構(gòu)建平臺(tái)瘦麸，以及靜態(tài)代碼分析平臺(tái)，用以指導(dǎo)日常開(kāi)發(fā)過(guò)程的質(zhì)量改進(jìn)歧胁，將代碼問(wèn)題的反饋機(jī)制自動(dòng)化滋饲，構(gòu)建數(shù)據(jù)可視化。
持續(xù)集成
為了讓產(chǎn)品可以快速迭代喊巍，同時(shí)還能保持高質(zhì)量屠缭。技術(shù)團(tuán)隊(duì)對(duì)各產(chǎn)品的各端都建立了持續(xù)構(gòu)建平臺(tái)：在代碼集成到主干之前，必須通過(guò)自動(dòng)化測(cè)試崭参。只要有一個(gè)測(cè)試用例失敗呵曹，就不能集成。保證持續(xù)地發(fā)現(xiàn)何暮、反饋和解決問(wèn)題奄喂。
靜態(tài)代碼分析
為了保證代碼質(zhì)量，從代碼層級(jí)降低線上出錯(cuò)的可能性海洼，技術(shù)團(tuán)隊(duì)引入了靜態(tài)代碼分析技術(shù)：在不執(zhí)行計(jì)算機(jī)程序的條件下跨新，對(duì)源代碼進(jìn)行分析，找出代碼的設(shè)計(jì)缺陷贰军，例如代碼規(guī)范玻蝌、內(nèi)存泄露，以及體現(xiàn)總體質(zhì)量：代碼覆蓋度词疼、技術(shù)債務(wù)的趨勢(shì)圖俯树，通知技術(shù)改進(jìn)，攔截在上線之前贰盗，這些數(shù)據(jù)都成為 QA 統(tǒng)計(jì)的數(shù)據(jù)來(lái)源许饿。
客戶(hù)端手工覆蓋度數(shù)據(jù)收集工具
過(guò)去執(zhí)行完測(cè)試用例之后陋率，無(wú)法考量哪些代碼覆蓋了，哪些沒(méi)有覆蓋秽晚，測(cè)試用例寫(xiě)的好不好瓦糟，為了解決這些困境，在客戶(hù)端 Android赴蝇、iOS 植入手工測(cè)試覆蓋度工具菩浙，收集代碼覆蓋度展示，目的是找出測(cè)試過(guò)程中未被覆蓋的代碼句伶，指導(dǎo)測(cè)試人員調(diào)整測(cè)試策略劲蜻，開(kāi)展探索式測(cè)試。
下圖是執(zhí)行美聊 2.8 版本 iOS 相關(guān)用例后的統(tǒng)計(jì)結(jié)果考余，可以根據(jù)結(jié)果調(diào)整測(cè)試策略先嬉，例如：如果改動(dòng)了登錄模塊，目前用例覆蓋度比較低楚堤，那是需要加強(qiáng)特殊場(chǎng)景測(cè)試疫蔓，還是其他方面呢？這個(gè)需要團(tuán)隊(duì) review 下做出決定身冬。
利用 BugTags 工具的問(wèn)題反饋
過(guò)去發(fā)現(xiàn)線上問(wèn)題無(wú)有效收集數(shù)據(jù)的手段鳄袍，用戶(hù)反饋之后，需要相關(guān)人員跟進(jìn)溝通吏恭，詢(xún)問(wèn)環(huán)境拗小、設(shè)備等諸多問(wèn)題，整個(gè)過(guò)程繁瑣樱哼，人力投入開(kāi)銷(xiāo)大哀九，引入 BugTags 是為了簡(jiǎn)化 Bug 提交過(guò)程，記錄重現(xiàn)場(chǎng)景相關(guān)信息搅幅，將客戶(hù)端的大量復(fù)雜操作最大限度簡(jiǎn)化阅束。通過(guò)白名單機(jī)制，美聊可以讓用戶(hù)打開(kāi) Bugtags 搖一搖問(wèn)題茄唐，提交用戶(hù)的相關(guān)環(huán)境息裸、設(shè)備信息蝇更，進(jìn)一步推進(jìn)排查問(wèn)題的效率。
如果對(duì)軟件測(cè)試呼盆、接口測(cè)試年扩、自動(dòng)化測(cè)試、性能測(cè)試访圃、LR腳本開(kāi)發(fā)厨幻、面試經(jīng)驗(yàn)交流。感興趣可以175317069腿时，群內(nèi)會(huì)有不定期的發(fā)放免費(fèi)的資料鏈接况脆，這些資料都是從各個(gè)技術(shù)網(wǎng)站搜集、整理出來(lái)的批糟，如果你有好的學(xué)習(xí)資料可以私聊發(fā)我格了，我會(huì)注明出處之后分享給大家。
BugBash 質(zhì)量活動(dòng)
傳統(tǒng)的產(chǎn)品走查徽鼎，產(chǎn)品笆搓、視覺(jué)、交付纬傲、運(yùn)營(yíng)只對(duì)自己負(fù)責(zé)的功能部分有了解和檢查满败，缺乏一個(gè)需求方的整體走查。當(dāng)有人發(fā)現(xiàn)一些功能間互相關(guān)聯(lián)的問(wèn)題時(shí)叹括，已經(jīng)比較晚算墨，修復(fù)成本高。引入 Bug Bash（所謂 Bug 大掃除的活動(dòng)）汁雷，在項(xiàng)目開(kāi)發(fā)階段的末期净嘀，專(zhuān)門(mén)劃出一個(gè)專(zhuān)門(mén)的時(shí)間段（通常 1 天），打破以往非技術(shù)人員未參與的做法侠讯，在這期間所有參與項(xiàng)目的人員（技術(shù)挖藏、產(chǎn)品、交互）厢漩，集中全部精力膜眠，運(yùn)用各方面的知識(shí)來(lái)搜尋項(xiàng)目的 Bug，做到及早發(fā)現(xiàn)問(wèn)題溜嗜。
會(huì)后將問(wèn)題匯總宵膨，用以推動(dòng)開(kāi)發(fā)改進(jìn)功能。
QA 數(shù)據(jù)收集
在 Sprint 總結(jié)會(huì)上為了讓項(xiàng)目成員能更加清楚了解整個(gè) Sprint 的質(zhì)量炸宵、進(jìn)度問(wèn)題辟躏，從 Q4 開(kāi)始對(duì)每個(gè) Sprint 都做了數(shù)據(jù)收集和展示。通過(guò)收集每個(gè)迭代版本的工時(shí)土全、bug 數(shù)據(jù)捎琐，在總結(jié)會(huì)上向全體人員（技術(shù)会涎、產(chǎn)品、視覺(jué)瑞凑、交互末秃、運(yùn)營(yíng)）呈現(xiàn)當(dāng)前版本總體質(zhì)量多維度數(shù)據(jù)，指導(dǎo)工作的改進(jìn)方向拨黔。
· 按照階段的 bug 分布展示
按照組件的 bug 分布展示
Android Monkey 崩潰性測(cè)試
持續(xù)集成環(huán)境每日代碼 daily build 之后，夜間在測(cè)試專(zhuān)屬服務(wù)器進(jìn)行長(zhǎng)達(dá)幾個(gè)小時(shí)的 Android Monkey 崩潰性測(cè)試
兼容性質(zhì)量風(fēng)險(xiǎn)控制轉(zhuǎn)移
目前交友測(cè)試團(tuán)隊(duì)現(xiàn)有的 Android 測(cè)試機(jī)型不足绰沥，為了解決 Android 碎片化篱蝇，特別是兼容性問(wèn)題，借助公司內(nèi)部的易測(cè)平臺(tái)來(lái)控制質(zhì)量風(fēng)險(xiǎn)徽曲。
重點(diǎn)關(guān)注基礎(chǔ)兼容性：安裝零截、啟動(dòng)、monkey 隨機(jī)秃臣、卸載涧衙。
團(tuán)隊(duì)人才建設(shè)
17 年初的測(cè)試團(tuán)隊(duì)規(guī)模太小了，業(yè)務(wù)測(cè)試需求不足以滿(mǎn)足奥此，人員技能集中在黑盒測(cè)試弧哎，沒(méi)有移動(dòng) UI 自動(dòng)化測(cè)試、后端 Server API 自動(dòng)化測(cè)試稚虎、測(cè)試平臺(tái)開(kāi)發(fā)的相關(guān)經(jīng)驗(yàn)撤嫩，并且全員對(duì)于 Android、iOS 代碼不了解蠢终，白盒測(cè)試無(wú)實(shí)踐經(jīng)驗(yàn)序攘，也會(huì)導(dǎo)致排查問(wèn)題不夠深入了解原理。
從 17 年 Q2 開(kāi)始制定團(tuán)隊(duì)建設(shè)技術(shù)寻拂，那么整個(gè)測(cè)試團(tuán)隊(duì)的關(guān)注點(diǎn)是什么程奠，如何聚焦，根據(jù)技術(shù)總體需求祭钉、產(chǎn)品需求來(lái)落實(shí)測(cè)試需求呢瞄沙？
根據(jù)團(tuán)隊(duì)特性，測(cè)試慌核、開(kāi)發(fā)劃分了邊界帕识，只有從這些方面出發(fā)，才能更好要求組員的技能形成階梯化遂铡，以及在招聘要求是按照此需求來(lái)落地肮疗，市場(chǎng)上大有可為之人，如何切實(shí)際為之更重要扒接，下面從幾個(gè)方面來(lái)談?wù)劇?/p>
測(cè)試團(tuán)隊(duì)關(guān)注點(diǎn)
Martin Fowler 在博客中解釋了TestPyramid伪货，如下圖所示：
如果對(duì)軟件測(cè)試们衙、接口測(cè)試、自動(dòng)化測(cè)試碱呼、性能測(cè)試蒙挑、LR腳本開(kāi)發(fā)、面試經(jīng)驗(yàn)交流愚臀。感興趣可以175317069忆蚀，群內(nèi)會(huì)有不定期的發(fā)放免費(fèi)的資料鏈接，這些資料都是從各個(gè)技術(shù)網(wǎng)站搜集姑裂、整理出來(lái)的馋袜，如果你有好的學(xué)習(xí)資料可以私聊發(fā)我，我會(huì)注明出處之后分享給大家舶斧。
單元測(cè)試是第一道測(cè)試關(guān)卡欣鳖，也是一個(gè)陷阱，測(cè)試人員如果投入到此環(huán)節(jié)上茴厉，將是一種資源耗盡型的質(zhì)量活動(dòng)泽台。比業(yè)務(wù)熟悉程度，測(cè)試人員沒(méi)有開(kāi)發(fā)人員高深矾缓，比寫(xiě)單元測(cè)試的效率怀酷，測(cè)試人員沒(méi)有開(kāi)發(fā)人員高效，這里交友測(cè)試團(tuán)隊(duì)也跳坑了嗜闻，歷經(jīng)一個(gè)季度跳入胰坟、跳出，理想的狀態(tài)下是：開(kāi)發(fā)的框架很松耦合泞辐，例如使用了 MVP/MVVM 開(kāi)發(fā)模式笔横，實(shí)際情況是這些技術(shù)債務(wù)在逐步償還，熟悉代碼的開(kāi)發(fā)人員進(jìn)行單元測(cè)試都有阻礙咐吼，測(cè)試人員談何容易吹缔，簡(jiǎn)單點(diǎn)來(lái)說(shuō)不務(wù)正業(yè)，投入產(chǎn)出比低锯茄。
真正要從業(yè)務(wù)需求的痛點(diǎn)出發(fā)挖掘適合團(tuán)隊(duì)的方向：測(cè)試層次的關(guān)注點(diǎn)是最清晰的一條分水嶺隔離開(kāi)發(fā)代碼級(jí)別的：?jiǎn)卧獪y(cè)試厢塘、集成測(cè)試，測(cè)試人員真正的關(guān)注點(diǎn)是：以手工測(cè)試為主肌幽，自動(dòng)化為輔的發(fā)展階段晚碾，同時(shí)圍繞整個(gè)研發(fā)測(cè)試過(guò)程的質(zhì)量反饋，包括：需求階段喂急、開(kāi)發(fā)階段格嘁、發(fā)布階段、運(yùn)營(yíng)階段廊移。
理清整個(gè)需求之后糕簿，就是團(tuán)隊(duì)成員角色轉(zhuǎn)型：
分為三種：
基本職能：手工測(cè)試工程師探入，進(jìn)階職能的：自動(dòng)化測(cè)試工程師，再高級(jí)一點(diǎn)懂诗，測(cè)試開(kāi)發(fā)工程師蜂嗽，其實(shí)也可以稱(chēng)為全棧，名字不是最重要殃恒，也不會(huì)設(shè)立這種 title植旧，只是要明確把活給細(xì)分出來(lái)。
最后离唐，根據(jù)需求病附，也把產(chǎn)品測(cè)試人員分布明細(xì)理順了：
按照此規(guī)劃來(lái)落地招聘需求，避免因人設(shè)崗侯繁，而是實(shí)實(shí)在在的產(chǎn)品需求胖喳、技術(shù)需求來(lái)決定人才所向泡躯。
測(cè)試團(tuán)隊(duì)文化建設(shè)
由于篇幅有限贮竟，簡(jiǎn)單來(lái)說(shuō)形成學(xué)習(xí)分享的技術(shù)氛圍，讓測(cè)試人員定期組織技術(shù)分享较剃，這些技術(shù)主要是可以用于生產(chǎn)落地以及對(duì)新技術(shù)的調(diào)研成果展示均可咕别，另外有一些虛擬組設(shè)置，例如：自動(dòng)化測(cè)試組写穴、平臺(tái)開(kāi)發(fā)組惰拱，用于把興趣相同的組員融合到一起，投入到合適的方向上啊送。
以上是本人在網(wǎng)易交友事業(yè)部一年以來(lái)對(duì)測(cè)試團(tuán)隊(duì)轉(zhuǎn)型帶來(lái)的分享偿短，在合適的階段對(duì)測(cè)試資源做合理的投入是有必要的，發(fā)展初期的困難適當(dāng)取舍產(chǎn)品質(zhì)量馋没，換來(lái)更多功能亮點(diǎn)吸引用戶(hù)昔逗，占領(lǐng)市場(chǎng)，站穩(wěn)腳步篷朵，發(fā)展中期勾怒，確保用戶(hù)的活躍、穩(wěn)定声旺，是需要靠產(chǎn)品質(zhì)量取勝的笔链，產(chǎn)品功能并不在于多花俏，有新意腮猖、簡(jiǎn)單化鉴扫、易傳播這幾個(gè)點(diǎn)可以適當(dāng)考慮，其實(shí)到了中后期澈缺，技術(shù)很多處于還債階段幔妨，之前設(shè)計(jì)的系統(tǒng)業(yè)務(wù)模塊解耦鹦赎、微服務(wù)化，提高可測(cè)試性都非常重要误堡，而測(cè)試人員往往對(duì)于技術(shù)還債的重構(gòu)要更加留意古话，一不小心就掉進(jìn)坑里，久久不能自拔锁施，同時(shí)最后犧牲最寶貴的就是測(cè)試質(zhì)量陪踩，這是需要取舍的，別以為質(zhì)量就是高高在上悉抵，測(cè)試團(tuán)隊(duì)的利益應(yīng)當(dāng)與開(kāi)發(fā)肩狂、產(chǎn)品團(tuán)隊(duì)的保持一致，這才是發(fā)展的硬道理姥饰。
