摘要：每周都會(huì)舉行嘉賓分享，話題討論等活動(dòng)。本期，我們邀請(qǐng)了測(cè)試技術(shù)社區(qū)聯(lián)合創(chuàng)始人陳曄，為大家分享移動(dòng)互聯(lián)網(wǎng)測(cè)試到質(zhì)量的轉(zhuǎn)變。分享內(nèi)容簡(jiǎn)介在移動(dòng)互聯(lián)網(wǎng)越來(lái)越快的迭代項(xiàng)目中，很多測(cè)試人員和測(cè)試團(tuán)隊(duì)都開(kāi)始覺(jué)得力不從心。

本文來(lái)自于騰訊bugly開(kāi)發(fā)者社區(qū)，非經(jīng)作者同意，請(qǐng)勿轉(zhuǎn)載，原文地址：http://dev.qq.com/topic/57ee0...

Dev Club 是一個(gè)交流移動(dòng)開(kāi)發(fā)技術(shù)，結(jié)交朋友，擴(kuò)展人脈的社群，成員都是經(jīng)過(guò)審核的移動(dòng)開(kāi)發(fā)工程師。每周都會(huì)舉行嘉賓分享，話題討論等活動(dòng)。

本期，我們邀請(qǐng)了 TesterHome 測(cè)試技術(shù)社區(qū)聯(lián)合創(chuàng)始人“陳曄”，為大家分享《移動(dòng)互聯(lián)網(wǎng)測(cè)試到質(zhì)量的轉(zhuǎn)變》。

分享內(nèi)容簡(jiǎn)介：

在移動(dòng)互聯(lián)網(wǎng)越來(lái)越快的迭代項(xiàng)目中，很多測(cè)試人員和測(cè)試團(tuán)隊(duì)都開(kāi)始覺(jué)得力不從心。很多團(tuán)隊(duì)和公司都開(kāi)始討論怎么保證質(zhì)量，事實(shí)是單純的從測(cè)試和測(cè)試團(tuán)隊(duì)出發(fā)都無(wú)法保證產(chǎn)品的質(zhì)量了。是時(shí)候從技術(shù)以及思想上開(kāi)始轉(zhuǎn)變了。

下面是本期分享內(nèi)容整理

好的，感謝大家今天晚上能來(lái)參加這個(gè)分享。時(shí)間有限，我先自我介紹下，大家看一下就可以過(guò)了。

首先先看下今年我到各個(gè)公司交流的時(shí)候，大家最常問(wèn)的一些問(wèn)題吧。

其實(shí)總體來(lái)講測(cè)試行業(yè)現(xiàn)在還是有很大進(jìn)步的，既關(guān)注了整體策略也關(guān)注了技術(shù)細(xì)節(jié)。但其實(shí)比較奇怪的是其實(shí)大部分人關(guān)注的還是別人怎么做，就是特別的缺少的從自己公司的產(chǎn)品業(yè)務(wù)和團(tuán)隊(duì)情況去思考問(wèn)題。這不得不讓我想到“別人家的xxx”這樣一個(gè)場(chǎng)景。當(dāng)初我在做這個(gè)“測(cè)試到質(zhì)量”轉(zhuǎn)變的時(shí)候我就是希望貼近主題盡量從全面的去闡述測(cè)試到質(zhì)量的變化。 總體來(lái)講，還是測(cè)試行業(yè)太過(guò)焦躁，我們總是偶爾的很積極的想去了解，想去學(xué)習(xí)，但這不可持續(xù)發(fā)展，這就好像我們會(huì)去存很多pdf和網(wǎng)站，但從來(lái)不看是一個(gè)道理。

今天在群里的都是開(kāi)發(fā)同學(xué)，其實(shí)就我的了解，大部分的開(kāi)發(fā)同學(xué)都知道測(cè)試的重要性，但其實(shí)本質(zhì)上并不知道測(cè)試具體要做什么或者說(shuō)怎么做，再比如測(cè)試工程師到底應(yīng)該具備什么樣的能力也不清楚，反正就是是一個(gè)模糊的概念。

所以我想先強(qiáng)調(diào)下，今天我和大家說(shuō)的并不是一種測(cè)試的理想狀態(tài)，而是現(xiàn)在移動(dòng)互聯(lián)網(wǎng)，這樣一個(gè)快速發(fā)展，變化的行業(yè)測(cè)試應(yīng)該有的姿態(tài)。以前國(guó)內(nèi)互聯(lián)網(wǎng)行業(yè)中的測(cè)試相對(duì)不是很規(guī)范，流程也好，技術(shù)也罷。但近幾年越來(lái)越走向正軌，所以也希望各位開(kāi)發(fā)同學(xué)能夠一起努力把產(chǎn)品的質(zhì)量做好。

就如我這邊說(shuō)的，現(xiàn)在快速的發(fā)展依靠傳統(tǒng)的測(cè)試已經(jīng)不可能完成了。那么什么是傳統(tǒng)的測(cè)試方式呢？傳統(tǒng)的測(cè)試方法就是只關(guān)注“ui自動(dòng)化，單元測(cè)試，接口測(cè)試，持續(xù)集成，回歸測(cè)試，冒煙測(cè)試等等”。

這些可以說(shuō)是測(cè)試行業(yè)不變的關(guān)注點(diǎn)，但在現(xiàn)今的移動(dòng)互聯(lián)網(wǎng)，單純的關(guān)注這些已經(jīng)遠(yuǎn)遠(yuǎn)不可能保證我們的產(chǎn)品質(zhì)量了，希望很多開(kāi)發(fā)和測(cè)試都有這樣的感覺(jué)。所以這就是今天我們要來(lái)講述的測(cè)試到質(zhì)量的轉(zhuǎn)變。只關(guān)注測(cè)試的測(cè)試已經(jīng)死了，我們所有人都需要把關(guān)注點(diǎn)放在質(zhì)量上

切入點(diǎn)有這樣兩個(gè)：

一個(gè)是人，這里的人先還是比較關(guān)注在測(cè)試身上。

另外一個(gè)就是流程，流程中的每個(gè)細(xì)節(jié)都是質(zhì)量保證的關(guān)鍵點(diǎn)。

由于今天的時(shí)間關(guān)系，無(wú)論人還是質(zhì)量上面，我都會(huì)挑選部分來(lái)說(shuō)，如果大家感興趣所有的點(diǎn)，以后可以再挑時(shí)間來(lái)分享哈。

之前有很多文章討論過(guò)所謂的“全?！?，其實(shí)至少?gòu)默F(xiàn)在來(lái)看，“全棧”真正的意義隨著時(shí)間的推移也開(kāi)始浮出水面——快速學(xué)習(xí)的能力和驅(qū)動(dòng)持續(xù)學(xué)習(xí)的興趣。

第二點(diǎn)其實(shí)想表述的就是如果我們走出測(cè)試來(lái)看質(zhì)量的話，幾乎所有事情都不是單純的測(cè)試個(gè)體或團(tuán)隊(duì)能夠完成的。我們需要走出那個(gè)“你提需求，別人實(shí)現(xiàn)”的時(shí)代，取而代之的是“你提需求，你牽頭來(lái)實(shí)現(xiàn)”。我們需要去利用合適的資源去做合適的事情，而不是什么都自己來(lái)做。

在我參加的很多大會(huì)上都會(huì)有這樣的問(wèn)題，一個(gè)團(tuán)隊(duì)是否都應(yīng)該是這樣一專多能，全棧的人。在我的理解里，一個(gè)團(tuán)隊(duì)中其實(shí)肯定不能沒(méi)有全棧的人，也不可能都是全棧的工程師。但這里其實(shí)特別的去強(qiáng)調(diào)了“定位問(wèn)題”。舉個(gè)例子來(lái)講，我們?cè)谄綍r(shí)測(cè)試的過(guò)程中發(fā)現(xiàn)了一個(gè)問(wèn)題，我們需要有能力去判斷這個(gè)問(wèn)題是前端還是后端的，如果是后端的，那么通過(guò)各個(gè)系統(tǒng)日志和調(diào)用關(guān)系需要去明白問(wèn)題出在什么系統(tǒng)上。如果是前端，那么我們需要去發(fā)現(xiàn)是框架層的，還是組建層的，還是業(yè)務(wù)方等等。也就是說(shuō)其實(shí)無(wú)論你是功能測(cè)試、自動(dòng)化測(cè)試或者架構(gòu)，定位問(wèn)題都是通用的要求。

其實(shí)之所以要求測(cè)試能夠有定位問(wèn)題的能力，本質(zhì)就是為了提升整個(gè)項(xiàng)目流程的效率。因?yàn)楫?dāng)我們發(fā)現(xiàn)一個(gè)問(wèn)題的時(shí)候，以前的方式是測(cè)試直接報(bào)一個(gè)bug。這個(gè)bug會(huì)描述清楚問(wèn)題的上下文和現(xiàn)象。但其實(shí)開(kāi)發(fā)還是需要去排查問(wèn)題，然后再fix。也就是說(shuō)排查問(wèn)題這個(gè)過(guò)程是免不了的，而且往往測(cè)試并不知道這個(gè)問(wèn)題是哪個(gè)開(kāi)發(fā)的頭上，容易出現(xiàn)A踢皮球到B，B再踢給A的情況。所以在現(xiàn)在的測(cè)試行業(yè)中，大部分的公司索性就要求測(cè)試需要有定位問(wèn)題的能力，這也是一項(xiàng)基礎(chǔ)的能力。

這點(diǎn)我特別的強(qiáng)調(diào)下，因?yàn)楝F(xiàn)在整個(gè)行業(yè)都在追求技術(shù)。我們?cè)诤芏嗑W(wǎng)站可以看到這里很牛的hook技術(shù)，那邊有很牛的遍歷技術(shù)等等。但行業(yè)卻慢慢的弱化了測(cè)試原本需要有的技術(shù)能力。比如測(cè)試策略的制定，比如測(cè)試的方式，測(cè)試用例設(shè)計(jì)的方式等等。我很擔(dān)心再過(guò)10年，測(cè)試行業(yè)都是一群技術(shù)很牛卻不懂測(cè)試的人。就好像我已經(jīng)聽(tīng)到很多測(cè)試同學(xué)和我說(shuō)，很多公司的測(cè)試總監(jiān)不知道ab test 和灰度發(fā)布有什么區(qū)別，竟然認(rèn)為兩個(gè)是一個(gè)東西。讓我也是很擔(dān)心測(cè)試行業(yè)的發(fā)展。

好了。以上我就挑了關(guān)于“人”這個(gè)方面的幾個(gè)點(diǎn)和大家闡述下。關(guān)于測(cè)試流程來(lái)講的話，其實(shí)測(cè)試本身還有很大的挖掘點(diǎn)。

我給大家舉個(gè)例子：

其實(shí)互聯(lián)網(wǎng)發(fā)展到現(xiàn)在，測(cè)試大部分的技術(shù)，無(wú)論是自動(dòng)化，還是動(dòng)態(tài)AOP的hook等，其實(shí)我們想想，這些技術(shù)都是存在于“測(cè)試中”或者“測(cè)試執(zhí)行”過(guò)程。但我們的流程中還有兩個(gè)很大的空缺。一個(gè)就是測(cè)試前，我們叫做測(cè)試準(zhǔn)備，一個(gè)就是測(cè)試后，也就是我們的測(cè)試結(jié)束后。這兩個(gè)階段可以說(shuō)是非?？瞻椎?。

測(cè)試準(zhǔn)備這里其實(shí)包括比如說(shuō)“測(cè)試用例的自動(dòng)生成”，“數(shù)據(jù)的自動(dòng)化生成”。我相信很多人聽(tīng)說(shuō)過(guò)“MBT”，就是基于模型的測(cè)試，這就是一個(gè)比較成熟的case自動(dòng)化生成的方式。

在移動(dòng)互聯(lián)網(wǎng)中，BAT中一些公司會(huì)使用線上導(dǎo)流的方式，從而能夠直接回放線上用戶的行為，這樣既能夠自動(dòng)的準(zhǔn)備測(cè)試數(shù)據(jù)，也可以省下編寫(xiě)自動(dòng)化測(cè)試用例的時(shí)間。但這里要注意的是和用戶相關(guān)的敏感信息的脫敏。

而在測(cè)試結(jié)束，也就是我們的灰度以及我們發(fā)布之后的話，那就是我們之后說(shuō)的質(zhì)量大盤(pán)的事情了。讓我們接著往下看吧。

由于時(shí)間關(guān)系，所以我就挑選幾個(gè)點(diǎn)來(lái)講。首先是自動(dòng)化，這個(gè)可以說(shuō)是測(cè)試比較注重的一塊。

UI自動(dòng)化其實(shí)在幾年前，整個(gè)行業(yè)都還是在搭建自己的框架或者自動(dòng)化團(tuán)隊(duì)，包括積累很多的自動(dòng)化用例。但經(jīng)過(guò)這幾年發(fā)現(xiàn)基本上是不可行的。最大的原因就是UI自動(dòng)化的ROI太低了。在現(xiàn)在這樣一個(gè)快速發(fā)展的移動(dòng)互聯(lián)網(wǎng)下根本是沒(méi)有辦法可持續(xù)發(fā)展的。

那么現(xiàn)在的大部分公司為了更好的支持hybrid（混合式應(yīng)用）的模式，那么選用了開(kāi)源的Appium。當(dāng)然這些公司并不會(huì)直接使用appium，而是拉出appium比較穩(wěn)定的一個(gè)branch，然后自己來(lái)開(kāi)發(fā)，并將appium根據(jù)自己的頁(yè)面封裝成適合自己的框架。

而UI自動(dòng)化不在會(huì)是每次迭代都會(huì)去增加case了。也就是說(shuō)會(huì)將那些很核心，不怎么變化的流程編寫(xiě)成我們的冒煙case和回歸case。而在冒煙的時(shí)候，根據(jù)提交的代碼屬于哪個(gè)bundle，然后會(huì)去調(diào)用對(duì)應(yīng)的case，并不會(huì)每次打包都跑全量。同時(shí)regression的話也是一樣的，會(huì)有一套穩(wěn)定的用例。這是基本上現(xiàn)在大部分公司選擇的方案。

而自動(dòng)化中的API會(huì)要求比較高，比如API的代碼覆蓋率，業(yè)務(wù)鏈路的覆蓋率，本次feature涉及到的API的數(shù)量的覆蓋率等等。這些數(shù)據(jù)會(huì)完完全全的去影響這個(gè)系統(tǒng)是否會(huì)發(fā)布。因?yàn)楝F(xiàn)在移動(dòng)互聯(lián)網(wǎng)的app大部分的邏輯都會(huì)在后端，包括現(xiàn)在的hotfix都是依賴服務(wù)端的能力，所以對(duì)于后端的測(cè)試基本上會(huì)有一套完整的準(zhǔn)入準(zhǔn)出標(biāo)準(zhǔn)。但對(duì)于app前端就相對(duì)會(huì)弱點(diǎn)。

我們?cè)贏pp的專項(xiàng)測(cè)試中，自動(dòng)化也會(huì)扮演非常重要的角色。如果對(duì)于專項(xiàng)測(cè)試不了解的朋友，我們以后可以專門(mén)開(kāi)一個(gè)專項(xiàng)測(cè)試的課，專項(xiàng)測(cè)試可以講2個(gè)小時(shí)了。自動(dòng)化在專項(xiàng)中的角色其實(shí)主要是為了獲取長(zhǎng)時(shí)間的app性能數(shù)據(jù)。

比如說(shuō)我們要獲取一個(gè)連續(xù)支付3000次，或者某個(gè)功能連續(xù)使用6小時(shí)下的耗電量。那么這種情況我們就需要那種能夠脫離usb的自動(dòng)化框架的支持，例如android的uiautomator。

所以總結(jié)下，UI自動(dòng)化其實(shí)就是為了保證我們的核心功能是正確的，不會(huì)出現(xiàn)很大的regression的問(wèn)題。我們不可能依賴UI自動(dòng)化去提升質(zhì)量。最多也就是保證核心的質(zhì)量。

然后出現(xiàn)了這樣的一個(gè)問(wèn)題。

我相信任何一個(gè)人面臨這個(gè)問(wèn)題的時(shí)候，都是右邊的這個(gè)臉。我其實(shí)很想回答，臣妾做不到啊。

我們的測(cè)試人員是有限的，我們的測(cè)試環(huán)境也和線上環(huán)境不同。我們的測(cè)試機(jī)也不可能有線上用戶那么多。你讓我說(shuō)數(shù)據(jù)要一樣，我肯定說(shuō)不一樣，但如果我說(shuō)不一樣，那么老板肯定會(huì)想，我投入那么多人力，資金等于沒(méi)有用啊。所以就會(huì)面臨兩難的境地。

所以就這個(gè)問(wèn)題之后出現(xiàn)了“質(zhì)量大盤(pán)”這個(gè)概念

我這里大概的列了質(zhì)量大盤(pán)的一個(gè)制作流程，這里我無(wú)法和大家說(shuō)細(xì)節(jié)了。大家如果有什么問(wèn)題私下可以咨詢我哈。

我說(shuō)下質(zhì)量大盤(pán)的目的：

為了讓所有的人明白現(xiàn)在產(chǎn)品的質(zhì)量，因?yàn)橘|(zhì)量大盤(pán)上面是會(huì)根據(jù)一定的公式算出分?jǐn)?shù)。這樣無(wú)論是不是技術(shù)人員都能夠一目了然這個(gè)產(chǎn)品每天的分?jǐn)?shù)到底怎么樣，以及長(zhǎng)時(shí)間的趨勢(shì)是怎么樣的。

質(zhì)量大盤(pán)會(huì)在每個(gè)樓層的辦公室里public出來(lái)，這樣也會(huì)被動(dòng)的讓那些PM，PD，Dev，Tester去知道自己和別人產(chǎn)品的分?jǐn)?shù)。被動(dòng)的可以push大家去提升自己負(fù)責(zé)模塊的質(zhì)量。

能夠減少一定的測(cè)試工作。因?yàn)橘|(zhì)量大盤(pán)的數(shù)據(jù)都是通過(guò)線上大數(shù)據(jù)總結(jié)得出的。更貼近用戶的痛點(diǎn)，這樣團(tuán)隊(duì)能夠第一時(shí)間去著手解決用戶的痛點(diǎn)問(wèn)題。而不是僅僅通過(guò)測(cè)試環(huán)境里的數(shù)據(jù)。

這是我通過(guò)百度的echart做的模擬圖，基本上就是分成這樣兩塊。一個(gè)是每個(gè)模塊，每個(gè)業(yè)務(wù)的分?jǐn)?shù)（左邊的），一種就是總體的分?jǐn)?shù)趨勢(shì)（右邊）。T+1會(huì)在質(zhì)量大盤(pán)上顯示。

我們?cè)賮?lái)看下每個(gè)公司都會(huì)有的這個(gè)工具組的境地，基本上每個(gè)公司的工具組都會(huì)出現(xiàn)這樣的問(wèn)題。做工具的這些同學(xué)其實(shí)也很苦惱。

之后改變成了，這個(gè)工具組會(huì)變成一個(gè)平臺(tái)建設(shè)組。這個(gè)平臺(tái)建設(shè)組就是輸出通用的sdk，數(shù)據(jù)的存儲(chǔ)以及前端的展現(xiàn)。至于每個(gè)BU自己的需求，每個(gè)BU 基于這個(gè)sdk和平臺(tái)的功能自己去封裝和實(shí)現(xiàn)。雖然我覺(jué)得這并不是一個(gè)最終的解決方案，但至少比之前的方案來(lái)的好，也更容易落地。

所以我們回到這個(gè)問(wèn)題上來(lái)，我們?cè)趺春芸斓牡卤ＷC產(chǎn)品質(zhì)量呢？

從本質(zhì)上我們需要認(rèn)清，無(wú)論是誰(shuí)，無(wú)論什么架構(gòu)都不可能在移動(dòng)互聯(lián)網(wǎng)下去保證產(chǎn)品的質(zhì)量，這是絕對(duì)不可能的。我們只能保證產(chǎn)品核心和很重要的模塊的質(zhì)量，但不可能說(shuō)我們保證產(chǎn)品的完整的質(zhì)量。

從思想上，我們需要轉(zhuǎn)變的是，以前我們認(rèn)為在項(xiàng)目流程中我們通過(guò)測(cè)試，通過(guò)bug bash，通過(guò)各種方式在上線前保證我們產(chǎn)品的質(zhì)量。但現(xiàn)在我們需要轉(zhuǎn)變，我們需要利用線上，利用用戶，幫助我們一起去保證產(chǎn)品質(zhì)量。我們不要擔(dān)心線上出問(wèn)題。所以我們需要一套質(zhì)量體系，當(dāng)出現(xiàn)問(wèn)題的時(shí)候，第一時(shí)間能夠預(yù)警，能夠hotfix，能夠動(dòng)態(tài)的更新，能夠及時(shí)應(yīng)對(duì)。這就是我們?cè)谝苿?dòng)互聯(lián)網(wǎng)下應(yīng)該有的質(zhì)量思維。

就如剛剛的這張圖。這里所有都是質(zhì)量體系的一部分。

這張圖是電影中的，很多人都知道吧?！俺T(mén)的世界”，其實(shí)測(cè)試就如同楚門(mén)，那么多年都在測(cè)試這個(gè)圈子里走來(lái)走去，就好像我一開(kāi)始說(shuō)的，關(guān)注UI自動(dòng)化，功能測(cè)試，api測(cè)試，持續(xù)集成等等。其實(shí)本質(zhì)上，關(guān)注這些根本無(wú)法從本質(zhì)去保證質(zhì)量，更不要說(shuō)提升質(zhì)量。所以我們只有跳出測(cè)試這個(gè)圈子，站在質(zhì)量的這個(gè)角度，才能夠真正的看到更全面的東西。比如產(chǎn)品的架構(gòu)，代碼的規(guī)范，每個(gè)milestone的準(zhǔn)入準(zhǔn)出，怎么灰度，怎么利用大數(shù)據(jù)等等。這些都是測(cè)試需要關(guān)注的。也是每個(gè)關(guān)注質(zhì)量的人應(yīng)該關(guān)注的。

好了。由于時(shí)間關(guān)系，今天就是到這里。其實(shí)很多擴(kuò)展的，可以放在以后的課程哈。

謝謝大家！

問(wèn)：請(qǐng)問(wèn)單元測(cè)試應(yīng)該由誰(shuí)來(lái)做，是自動(dòng)化測(cè)試的重中之重嗎？

你好～單元測(cè)試從軟件測(cè)試的定義上來(lái)講是由Dev來(lái)做的，無(wú)論測(cè)試多么的了解代碼都不應(yīng)該由測(cè)試來(lái)講。在以前微軟的流程中，有一種測(cè)試叫做bvt。也就是每個(gè)開(kāi)發(fā)的模塊如果要check in，需要代碼跑過(guò)自己的bvt的單元測(cè)試，才能夠check in。
另外說(shuō)比重的話，其實(shí)要看測(cè)試的對(duì)象。不同的對(duì)象比重不同。我舉個(gè)例子，如果是app，現(xiàn)在整個(gè)行業(yè)的UT的比例很低。但如果是中間件or sdk這種，單元測(cè)試可能比重會(huì)很高。

問(wèn)（接上）：非常感謝回答，不好意思因?yàn)檫@個(gè)問(wèn)題困擾很久了所以想再問(wèn)的細(xì)一點(diǎn)。從微信還有手機(jī)管家的經(jīng)驗(yàn)來(lái)看，似乎在項(xiàng)目初期并不需要ut，往往要到很后期產(chǎn)品穩(wěn)定才會(huì)做，但是大部分的產(chǎn)品又并不會(huì)走到后期，而主流的測(cè)試模型又很推崇ut，所以是不是有點(diǎn)矛盾？

并不是。其實(shí)這就是我說(shuō)的測(cè)試策略本身。就好像我們說(shuō)吃飯是對(duì)的，喝水也是對(duì)的。但如果一天你吃10頓，吃10升的水，你也受不了。所以說(shuō)本身還是有一定的上下文。首先UT本身其實(shí)是為了保證模塊，多帶帶模塊或者幾個(gè)模塊耦合度比較高的情況下的質(zhì)量，也就是所謂的代碼質(zhì)量。這和產(chǎn)品穩(wěn)定不穩(wěn)定關(guān)系不大。之所以會(huì)有這樣的理論是因?yàn)樵诓环€(wěn)定的時(shí)候，大部份的開(kāi)發(fā)都在忙著重構(gòu)或者寫(xiě)功能，沒(méi)有空去寫(xiě)UT，所以才會(huì)說(shuō)等穩(wěn)定之后去做。
測(cè)試模型推崇UT也是對(duì)的，因?yàn)闇y(cè)試偏重質(zhì)量，質(zhì)量本身，代碼的check in就應(yīng)該有開(kāi)發(fā)的測(cè)試。我們叫做自測(cè)。那么現(xiàn)在移動(dòng)互聯(lián)網(wǎng)下，大部分的公司其實(shí)是沒(méi)有UT的，所以開(kāi)發(fā)就會(huì)手工的去跑一些功能測(cè)試，以保證自己模塊的質(zhì)量。
所以說(shuō)從本質(zhì)上說(shuō)，這兩者并不矛盾，只不過(guò)是怎么做效率高，怎么做真的能落地就會(huì)怎么做。倒不是說(shuō)理論or模型說(shuō)一定這樣做就一定這樣做。

**問(wèn)：做了幾年測(cè)試，今天講師介紹的很多觀點(diǎn)都很認(rèn)同。想問(wèn)幾個(gè)問(wèn)題：
1，線上導(dǎo)流方式 直接回放線上行為，有哪些實(shí)現(xiàn)的方式，能舉例介紹一下嗎？
2，質(zhì)量大盤(pán)產(chǎn)品不同指標(biāo)也不同，如何設(shè)計(jì)認(rèn)為是能全面合理體現(xiàn)質(zhì)量標(biāo)準(zhǔn)的呢？能舉個(gè)具體事例介紹一下嗎？如何具體真實(shí)的衡量一個(gè)產(chǎn)品的質(zhì)量打多少分？業(yè)界哪個(gè)公司哪個(gè)項(xiàng)目在這方面做的很好能借鑒嗎？能介紹一下嗎？**

關(guān)于第一個(gè)問(wèn)題，我舉個(gè)例子。比如客戶端的h5的測(cè)試。那么無(wú)論是灰度，還是線上。我們可以通過(guò)代理服務(wù)器直接透?jìng)鞯姆绞?，記錄訪問(wèn)的h5的鏈接，包括req，res data等。這些數(shù)據(jù)可以通過(guò)在客戶端的webview容器直接訪問(wèn)的方式進(jìn)行回放。當(dāng)然這個(gè)過(guò)程中細(xì)節(jié)很多，可以用的框架比如anyproxy。
第二個(gè)問(wèn)題，我舉個(gè)實(shí)際的例子。比如說(shuō)每個(gè)界面打開(kāi)的響應(yīng)時(shí)間，那么我們根據(jù)每個(gè)界面的PV，UV來(lái)定每個(gè)界面的權(quán)重，我們?cè)俑鶕?jù)不同的網(wǎng)絡(luò)狀態(tài)，不同的手機(jī)下去定不同的公式來(lái)做計(jì)算。當(dāng)然這個(gè)公式是需要大家討論的，比如Dev，Tester，PD都需要一起討論。然后最終定出來(lái)一個(gè)公式，會(huì)放入大數(shù)據(jù)的計(jì)算中間。

問(wèn)：移動(dòng)端的兼容性自動(dòng)化測(cè)試?yán)蠋熡泻玫姆椒ǔ墒斓陌咐榻B嗎？

兼容性的自動(dòng)化有的。如果是你是需要自己公司去搭建 ，那么現(xiàn)在github最好用的就是“STF”，在TesterHome上面你可以找到我寫(xiě)的二次開(kāi)發(fā)“STF”框架的文章，還是很詳細(xì)的。如果你需要用第三方的話，那么目前已有的幾個(gè)平臺(tái)也都是ok的。

問(wèn)：如果是老師會(huì)怎么去衡量一個(gè)測(cè)試人員的價(jià)值？或者怎么去看一個(gè)工具的roi？

這個(gè)是招聘的要求，其實(shí)主要是在經(jīng)驗(yàn)，技術(shù)還可以的情況下，接下來(lái)就是看問(wèn)題的高度和大局觀。然后說(shuō)我們?cè)趺春饬恳粋€(gè)人的價(jià)值。basic的話其實(shí)就是活干的怎么樣，其實(shí)不一定是發(fā)現(xiàn)了多少bug。現(xiàn)在行業(yè)中也有EP團(tuán)隊(duì)，工程效率團(tuán)隊(duì)。也就是說(shuō)，只要提升了效率，就是有產(chǎn)出的，就是有價(jià)值的，這個(gè)提升可以是流程任何一個(gè)環(huán)節(jié)。
當(dāng)然還有一點(diǎn)就是需要有感染力，需要帶動(dòng)測(cè)試團(tuán)隊(duì)，開(kāi)發(fā)團(tuán)隊(duì)。樂(lè)于分享，追前沿的技術(shù)，包括樂(lè)于助人等等。這些都是價(jià)值考量的一部分

所以基本上是這樣三大類。
工具的ROI，其實(shí)就是比較好評(píng)估。比如說(shuō)這個(gè)工具能節(jié)省多少的人力?，F(xiàn)在很大的情況下是用了工具，人力還是要保證一遍。這樣等于0。所以就工具而言，一個(gè)是改造需要的投入，一個(gè)就是真正提升的效率有多少。包括維護(hù)成本多少。基本上是這樣幾個(gè)維度。

更多精彩內(nèi)容歡迎關(guān)注bugly的微信公眾賬號(hào)：

騰訊 Bugly是一款專為移動(dòng)開(kāi)發(fā)者打造的質(zhì)量監(jiān)控工具，幫助開(kāi)發(fā)者快速，便捷的定位線上應(yīng)用崩潰的情況以及解決方案。智能合并功能幫助開(kāi)發(fā)同學(xué)把每天上報(bào)的數(shù)千條 Crash 根據(jù)根因合并分類，每日日?qǐng)?bào)會(huì)列出影響用戶數(shù)最多的崩潰，精準(zhǔn)定位功能幫助開(kāi)發(fā)同學(xué)定位到出問(wèn)題的代碼行，實(shí)時(shí)上報(bào)可以在發(fā)布后快速的了解應(yīng)用的質(zhì)量情況，適配最新的 iOS, Android 官方操作系統(tǒng)，鵝廠的工程師都在使用，快來(lái)加入我們吧！