国产xxxx99真实实拍_久久不雅视频_高清韩国a级特黄毛片_嗯老师别我我受不了了小说

資訊專欄INFORMATION COLUMN

【騰訊Bugly干貨分享】移動互聯(lián)網(wǎng)測試到質(zhì)量的轉(zhuǎn)變

renweihub / 1715人閱讀

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

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

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

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

分享內(nèi)容簡介:

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

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


好的,感謝大家今天晚上能來參加這個分享。時間有限,我先自我介紹下,大家看一下就可以過了。

1. 測試已死,關(guān)注質(zhì)量才是王道

首先先看下今年我到各個公司交流的時候,大家最常問的一些問題吧。

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

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

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

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

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

2. 一專多能

切入點有這樣兩個:

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

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

由于今天的時間關(guān)系,無論人還是質(zhì)量上面,我都會挑選部分來說,如果大家感興趣所有的點,以后可以再挑時間來分享哈。

之前有很多文章討論過所謂的“全棧”,其實至少從現(xiàn)在來看,“全棧”真正的意義隨著時間的推移也開始浮出水面——快速學習的能力和驅(qū)動持續(xù)學習的興趣。

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

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

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

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

好了。以上我就挑了關(guān)于“人”這個方面的幾個點和大家闡述下。關(guān)于測試流程來講的話,其實測試本身還有很大的挖掘點。

3. 質(zhì)量體系的建設(shè)

我給大家舉個例子:

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

測試準備這里其實包括比如說“測試用例的自動生成”,“數(shù)據(jù)的自動化生成”。我相信很多人聽說過“MBT”,就是基于模型的測試,這就是一個比較成熟的case自動化生成的方式。

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

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

由于時間關(guān)系,所以我就挑選幾個點來講。首先是自動化,這個可以說是測試比較注重的一塊。

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

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

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

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

我們在App的專項測試中,自動化也會扮演非常重要的角色。如果對于專項測試不了解的朋友,我們以后可以專門開一個專項測試的課,專項測試可以講2個小時了。自動化在專項中的角色其實主要是為了獲取長時間的app性能數(shù)據(jù)。

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

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

4. 測試技術(shù)還只是剛剛起步,將來是數(shù)據(jù)的天下

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

我相信任何一個人面臨這個問題的時候,都是右邊的這個臉。我其實很想回答,臣妾做不到啊。

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

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

我這里大概的列了質(zhì)量大盤的一個制作流程,這里我無法和大家說細節(jié)了。大家如果有什么問題私下可以咨詢我哈。

我說下質(zhì)量大盤的目的:

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

質(zhì)量大盤會在每個樓層的辦公室里public出來,這樣也會被動的讓那些PM,PD,Dev,Tester去知道自己和別人產(chǎn)品的分數(shù)。被動的可以push大家去提升自己負責模塊的質(zhì)量。

能夠減少一定的測試工作。因為質(zhì)量大盤的數(shù)據(jù)都是通過線上大數(shù)據(jù)總結(jié)得出的。更貼近用戶的痛點,這樣團隊能夠第一時間去著手解決用戶的痛點問題。而不是僅僅通過測試環(huán)境里的數(shù)據(jù)。

這是我通過百度的echart做的模擬圖,基本上就是分成這樣兩塊。一個是每個模塊,每個業(yè)務(wù)的分數(shù)(左邊的),一種就是總體的分數(shù)趨勢(右邊)。T+1會在質(zhì)量大盤上顯示。

我們再來看下每個公司都會有的這個工具組的境地,基本上每個公司的工具組都會出現(xiàn)這樣的問題。做工具的這些同學其實也很苦惱。

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

5. 從思想本質(zhì)上改變對質(zhì)量的認識

所以我們回到這個問題上來,我們怎么很快的迭代下保證產(chǎn)品質(zhì)量呢?

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

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

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

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

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

謝謝大家!

問答環(huán)節(jié)

問:請問單元測試應(yīng)該由誰來做,是自動化測試的重中之重嗎?

你好~單元測試從軟件測試的定義上來講是由Dev來做的,無論測試多么的了解代碼都不應(yīng)該由測試來講。在以前微軟的流程中,有一種測試叫做bvt。也就是每個開發(fā)的模塊如果要check in,需要代碼跑過自己的bvt的單元測試,才能夠check in。

另外說比重的話,其實要看測試的對象。不同的對象比重不同。我舉個例子,如果是app,現(xiàn)在整個行業(yè)的UT的比例很低。但如果是中間件or sdk這種,單元測試可能比重會很高。

問(接上):非常感謝回答,不好意思因為這個問題困擾很久了所以想再問的細一點。從微信還有手機管家的經(jīng)驗來看,似乎在項目初期并不需要ut,往往要到很后期產(chǎn)品穩(wěn)定才會做,但是大部分的產(chǎn)品又并不會走到后期,而主流的測試模型又很推崇ut,所以是不是有點矛盾?

并不是。其實這就是我說的測試策略本身。就好像我們說吃飯是對的,喝水也是對的。但如果一天你吃10頓,吃10升的水,你也受不了。所以說本身還是有一定的上下文。首先UT本身其實是為了保證模塊,多帶帶模塊或者幾個模塊耦合度比較高的情況下的質(zhì)量,也就是所謂的代碼質(zhì)量。這和產(chǎn)品穩(wěn)定不穩(wěn)定關(guān)系不大。之所以會有這樣的理論是因為在不穩(wěn)定的時候,大部份的開發(fā)都在忙著重構(gòu)或者寫功能,沒有空去寫UT,所以才會說等穩(wěn)定之后去做。

測試模型推崇UT也是對的,因為測試偏重質(zhì)量,質(zhì)量本身,代碼的check in就應(yīng)該有開發(fā)的測試。我們叫做自測。那么現(xiàn)在移動互聯(lián)網(wǎng)下,大部分的公司其實是沒有UT的,所以開發(fā)就會手工的去跑一些功能測試,以保證自己模塊的質(zhì)量。

所以說從本質(zhì)上說,這兩者并不矛盾,只不過是怎么做效率高,怎么做真的能落地就會怎么做。倒不是說理論or模型說一定這樣做就一定這樣做。

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

關(guān)于第一個問題,我舉個例子。比如客戶端的h5的測試。那么無論是灰度,還是線上。我們可以通過代理服務(wù)器直接透傳的方式,記錄訪問的h5的鏈接,包括req,res data等。這些數(shù)據(jù)可以通過在客戶端的webview容器直接訪問的方式進行回放。當然這個過程中細節(jié)很多,可以用的框架比如anyproxy。

第二個問題,我舉個實際的例子。比如說每個界面打開的響應(yīng)時間,那么我們根據(jù)每個界面的PV,UV來定每個界面的權(quán)重,我們再根據(jù)不同的網(wǎng)絡(luò)狀態(tài),不同的手機下去定不同的公式來做計算。當然這個公式是需要大家討論的,比如Dev,Tester,PD都需要一起討論。然后最終定出來一個公式,會放入大數(shù)據(jù)的計算中間。

問:移動端的兼容性自動化測試老師有好的方法成熟的案例介紹嗎?

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

問:如果是老師會怎么去衡量一個測試人員的價值?或者怎么去看一個工具的roi?

這個是招聘的要求,其實主要是在經(jīng)驗,技術(shù)還可以的情況下,接下來就是看問題的高度和大局觀。然后說我們怎么衡量一個人的價值。basic的話其實就是活干的怎么樣,其實不一定是發(fā)現(xiàn)了多少bug。現(xiàn)在行業(yè)中也有EP團隊,工程效率團隊。也就是說,只要提升了效率,就是有產(chǎn)出的,就是有價值的,這個提升可以是流程任何一個環(huán)節(jié)。

當然還有一點就是需要有感染力,需要帶動測試團隊,開發(fā)團隊。樂于分享,追前沿的技術(shù),包括樂于助人等等。這些都是價值考量的一部分

所以基本上是這樣三大類。

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

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

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

文章版權(quán)歸作者所有,未經(jīng)允許請勿轉(zhuǎn)載,若此文章存在違規(guī)行為,您可以聯(lián)系管理員刪除。

轉(zhuǎn)載請注明本文地址:http://specialneedsforspecialkids.com/yun/8742.html

相關(guān)文章

發(fā)表評論

0條評論

renweihub

|高級講師

TA的文章

閱讀更多
最新活動
閱讀需要支付1元查看
<