2019年10月26日，由Testin主辦的第二屆NCTS中國云測試行業(yè)峰會(huì)在京召開，此次峰會(huì)以“AI+未來”為主題，匯聚來自國內(nèi)外測試領(lǐng)域的知名專家學(xué)者、領(lǐng)先企業(yè)決策者、高層技術(shù)管理者、媒體從業(yè)者等，共同探討高端云測試技術(shù)，幫助測試從業(yè)者了解最前沿行業(yè)趨勢，及最新的行業(yè)實(shí)踐。

[[285504]]

搜狗科技資深高級(jí)測試開發(fā)工程師王鵬做《如何通過精準(zhǔn)測試來解決效率黑洞》主題演講。王鵬指出，“精準(zhǔn)和智能是精準(zhǔn)化測試聚焦的兩個(gè)點(diǎn)，而如何從經(jīng)驗(yàn)型方法中提升技術(shù)性的手段則是精準(zhǔn)化測試的目的。”

以下為王鵬演講實(shí)錄：

大家好，今天我給大家分享的主題是《如何通過精準(zhǔn)測試來解決效率黑洞》，我希望大家聽完后，可以想想現(xiàn)在適不適合開展精準(zhǔn)測試，如果現(xiàn)階段不適合，我的目的也達(dá)到了。第二點(diǎn)，如果確實(shí)可以做精準(zhǔn)化測試，我希望大家聽了以后學(xué)到一些方法，能知道哪些階段引入哪些方法可以解決哪些問題，達(dá)到什么效果，想做的話，回去后，可以開始一步步開展。

分享分三個(gè)部分：1、影響我們測試效率的因素有哪些，既然做這件事肯定是事出有因的。2、簡單介紹一下精準(zhǔn)化測試思想。最近精準(zhǔn)化測試起來了，有的同學(xué)對(duì)此了解不是很深。3、介紹一下我們提升效率的具體方法有哪些，每個(gè)階段都會(huì)詳細(xì)給大家介紹。

首先說一下影響效率的因素，這是和大家訴苦了。我這個(gè)題目選了“黑洞”這個(gè)詞，大家看這張照片是前一陣NASA發(fā)現(xiàn)的第一張黑洞照片，選這個(gè)題目的時(shí)候，這張照片還沒有呢，為什么選黑洞，效率為什么是黑洞，因?yàn)樗麄冇蓄愃频牡胤?，黑洞是什么？質(zhì)量特別大但是體積很小，我們平時(shí)工作是什么樣的？測試的工作非常苦，付出非常多，但有可能成效非常少。是什么造成了這樣一個(gè)情況？

分析了一下：

1、投入產(chǎn)出比。不知道大家平時(shí)做事的時(shí)候有沒有考慮過這個(gè)事情，這個(gè)事情其實(shí)對(duì)你自己的影響非常大，大家可以好好想一想，經(jīng)常有人說我們工作效率低，這直接對(duì)我們個(gè)人的影響就是你的創(chuàng)新性工作啟動(dòng)特別難。作為一個(gè)測試工程師，如果我正天被我的工作羈絆，成天做重復(fù)的工作，也許很多人都是這樣，最開始我也是這樣，那么就很難開展一些創(chuàng)新性的工作，或者你和老板提出有一些想法要做這些創(chuàng)新工作，也可能沒有時(shí)間，老板會(huì)跟你討論，這些創(chuàng)新工作投入產(chǎn)出比怎么樣、收效怎么樣、付出這么多時(shí)間下面如何？這是我們面臨的困境。

2、我們的成效不可衡量。這個(gè)很多分享嘉賓提到了，不出事還好，一旦線上發(fā)現(xiàn)什么問題，往往追溯的時(shí)候，開發(fā)可以查代碼，我們整個(gè)測試過程怎么回放，不可衡量，我昨天這么點(diǎn)的沒有出現(xiàn)問題，今天還是這么做出現(xiàn)問題了，你說我到底錯(cuò)在哪兒？我們的工作不可衡量的話，真正較真計(jì)較這個(gè)事情的時(shí)候，我們就處于非常非常被動(dòng)的地步。

正因?yàn)檫@兩部分，這次出事了，下次投入更大的精力去做，從另一個(gè)角度講就是影響你的效率。

說完我自己的切身體會(huì)再來回顧一下我們平時(shí)的工作，我列了兩項(xiàng)：黑盒測試，白盒測試。大家可能覺得老生常談，其實(shí)不是這樣的，黑盒測試我們今天聽分享有好多高大上的方法，據(jù)我們了解，在很多大廠包括很多公司里，黑盒測試的同學(xué)仍然占80%以上，這是不可規(guī)避的一個(gè)問題，大量的同事還在從事著黑盒測試工作，那么我們怎么幫助他們其實(shí)是一個(gè)非常重要的問題。

說到黑盒測試，準(zhǔn)備從三個(gè)方面說一下，過程、效果、管理。黑盒測試的過程是怎樣的？因?yàn)楹诤袦y試是看不到代碼的，在整個(gè)測試過程中伴隨著很多猜測的成分，在測這個(gè)功能的時(shí)候可能憑借你的經(jīng)驗(yàn)猜，它可不可能出現(xiàn)一些問題，設(shè)計(jì)測試用例的時(shí)候也是靠猜的。第二不穩(wěn)定，體現(xiàn)在很多方面，極端的例子，今天測的和昨天測的可能就不一樣，今天身體不舒服測的版本效果可能跟身體好的時(shí)候也不一樣。第三難控制。正因?yàn)檫@么多因素造成整個(gè)黑盒測試的過程是不可控的，我說測一個(gè)90分的版本來，怎么確定這件事情？

效果跟個(gè)人素質(zhì)關(guān)系很大，一個(gè)新人和一個(gè)有經(jīng)驗(yàn)的老人對(duì)業(yè)務(wù)測試的質(zhì)量，這個(gè)區(qū)別是很大的，在座很多管理者，如果你管理的是一個(gè)黑盒測試團(tuán)隊(duì)的話，你面臨的難度是什么？要管理測試開發(fā)團(tuán)隊(duì)評(píng)估你的代碼開發(fā)能力、代碼設(shè)計(jì)能力，其實(shí)不是一個(gè)很難的事情，咱們打幾次交道，你給我實(shí)現(xiàn)幾個(gè)功能就基本知道你的底了，就知道什么樣的工作可以交給你開發(fā)，業(yè)務(wù)怎么辦？你可能有自己熟悉的業(yè)務(wù)，比如說來了一個(gè)測試需求，測試需求里的很多業(yè)務(wù)，30%是你熟悉的，70%是不熟悉的，能不能交給你，如何選擇一個(gè)合適的同事測這個(gè)版本？這是一個(gè)非常大的問題，是對(duì)黑盒測試團(tuán)隊(duì)管理者提出的很大的挑戰(zhàn)，出現(xiàn)問題時(shí)我們反思，測試過程中這個(gè)問題需要注意、那個(gè)問題需要注意，管理者有沒有捫心自問為什么選擇他做這件事情，如果選擇另一位同學(xué)能不能規(guī)避他犯的錯(cuò)誤？這是很難的事情。

另外聊一聊白盒測試，在座有做白盒測試的嗎？有兩個(gè)，不知道你們是不是互聯(lián)網(wǎng)行業(yè)的，其實(shí)我是不建議在互聯(lián)網(wǎng)行業(yè)做白盒測試的，因?yàn)榘缀袦y試產(chǎn)生是以前像微軟Office這種開發(fā)周期極長用白盒測試，互聯(lián)網(wǎng)一天上線三個(gè)版本，做完以后門檻高，團(tuán)隊(duì)里有一到兩個(gè)人能做白盒測試嗎？單兵作戰(zhàn)，你測一半能不能交給另外一個(gè)同學(xué)？沒法交接只能自己做。第三目標(biāo)比較單一，做白盒測試的時(shí)候一般評(píng)價(jià)我們測試是否到位，基本只能依靠覆蓋率，白盒測試過程中覆蓋率達(dá)到一定指標(biāo)了就說明OK，目標(biāo)非常單一。還有沒法大家一起做，一個(gè)版本來了大家一起做白盒測試，最后把結(jié)果匯總到一起，這個(gè)也是很難做的；第四就是分析之殤投入產(chǎn)出比比較低，有可能做完以后只能告訴“看了，這些邏輯確實(shí)都覆蓋到了，沒有問題”但是你發(fā)現(xiàn)bug了嗎？一個(gè)也沒有發(fā)現(xiàn)，這種情況很常見，所以白盒測試對(duì)于互聯(lián)網(wǎng)行業(yè)是不合適的，所以現(xiàn)在其實(shí)很早大家就在做灰盒測試了。我們基本上測試是通過黑盒測試做的，在黑盒測試基礎(chǔ)上更高效的解決問題。這是我們面臨的現(xiàn)狀。

第二，就給大家介紹一下精準(zhǔn)化測試思想，簡單介紹一下，這有一句話我念一遍，因?yàn)槲铱催^很多精準(zhǔn)化相關(guān)的資料，我認(rèn)為這句話總結(jié)的非常到位，精準(zhǔn)化測試就是“用非常精準(zhǔn)和智能的軟件來解決軟件測試的問題，并從根本上引領(lǐng)軟件測試，從經(jīng)驗(yàn)型方法向技術(shù)性方法的轉(zhuǎn)型”。它強(qiáng)調(diào)兩點(diǎn)，首先當(dāng)然是需要解決問題的，精準(zhǔn)和智能是精準(zhǔn)化測試?yán)镆劢沟膬蓚€(gè)點(diǎn)，如果做精準(zhǔn)化測試一定要聚焦在這兩個(gè)點(diǎn)上，它要達(dá)到的目標(biāo)是什么？從經(jīng)驗(yàn)型方法向技術(shù)性方法轉(zhuǎn)移，黑盒測試大多依賴于經(jīng)驗(yàn)型方法，如何在經(jīng)驗(yàn)型方法中提升技術(shù)性的手段就是我們精準(zhǔn)化測試的目的。

分別介紹一下，首先介紹一下精準(zhǔn)要做哪些事，我們這邊的精準(zhǔn)1、測試用例到代碼邏輯精準(zhǔn)記錄的雙向追溯。什么叫雙向追溯，執(zhí)行黑盒測試用例直接就能映射到你的代碼邏輯上，看代碼邏輯也能反向用到測試用例上，一定是雙向的，如果是單向的，這個(gè)效率是提高不了多少的。怎么實(shí)現(xiàn)？代碼邏輯到測試用例是通過函數(shù)調(diào)用關(guān)系計(jì)算來的，我們提出一種方法叫代碼染色，這兩個(gè)都會(huì)在后面詳細(xì)給大家介紹。

2、精準(zhǔn)的代碼級(jí)的缺陷定位和崩潰分析。在做黑盒測試的過程中，我們一定要給黑盒測試同學(xué)提供什么樣的方法？測著測著發(fā)現(xiàn)一個(gè)bug，他自己就知道哪塊代碼出問題了，要達(dá)到這種效果，崩潰也是要能落到崩潰分析上。

3、精準(zhǔn)的測試充分度分析，主要是解決測試不可度量的問題。

智能有哪些？主要列了3點(diǎn)：1、回歸用例的自動(dòng)篩選；2、自動(dòng)化用例篩選與執(zhí)行；3、持續(xù)集成。

第二部分就簡單介紹到這，主要介紹第三部分，告訴大家如何去做，上面那些事，如果我想做的話一步步怎么做？我給大家分享我們在搜狗社區(qū)具體應(yīng)用的案例，我們現(xiàn)在正在做的事，大概是做成什么樣子。

首先再給大家提一下影響效率的因素，因?yàn)槲覀冞@里主要要解決效率的問題，列了很多，剛才也有人說過了，1、團(tuán)隊(duì)新人沒有經(jīng)驗(yàn)；2、團(tuán)隊(duì)新人能力不足；3、測試范圍圈定憑經(jīng)驗(yàn)。這里我們經(jīng)常遇到那種情況，開發(fā)改了一段代碼，需求上寫的很清晰，我們都測到了，但是卻有另外一個(gè)場景出現(xiàn)問題，是有關(guān)聯(lián)的，我們很難把那部分測試用例圈出來。4、測試用例篩選難，讓你從曾經(jīng)的測試用例篩選出這次的測試用例，這個(gè)很難。5、測試經(jīng)驗(yàn)沉淀效果差，我們這個(gè)測試經(jīng)驗(yàn)沉淀基本是口口相傳，沉淀的東西是靜態(tài)的，無法動(dòng)起來，看代碼、整理接口、就編成一篇篇測試文檔，或者在某個(gè)軟件、某個(gè)平臺(tái)里落在那兒了，它動(dòng)不起來，不實(shí)際，用到不會(huì)查，查還可能查不全，怎么讓這些資料主動(dòng)為你提供幫助，這是我們做的事情。6、測試人員狀態(tài)不穩(wěn)定，主要是指大家的心理和生理狀態(tài)。

最初我們給自己提了4個(gè)目標(biāo)，我們要解決的問題：1、要精準(zhǔn)圈定我的測試范圍；2、對(duì)影響的范圍必須給出建議；如果測這個(gè)版本要有個(gè)東西，暫且叫它軟件，要告訴我還有哪些東西要考慮。3、自動(dòng)篩選測試用例，要測這個(gè)版本了，至少給我一份測試用例讓我做參考。4、為黑盒測試提供實(shí)時(shí)覆蓋率結(jié)果。

為什么強(qiáng)調(diào)實(shí)時(shí)覆蓋率改革呢？有時(shí)候我們經(jīng)常做覆蓋率，一堆功能做完了，讓我們出一份覆蓋率軟件去分析，發(fā)現(xiàn)有幾行沒有覆蓋到，再往回推，效率也是比較低的，我們要達(dá)到什么情況？比如，我執(zhí)行了非常短的業(yè)務(wù)流程可能就是一個(gè)登陸，三步操作，輸入用戶名、輸入密碼、提交，這三步操作希望知道我的覆蓋率是什么，及時(shí)調(diào)整覆蓋用例，這個(gè)對(duì)我們價(jià)值是比較大的，所以我們必須為黑盒測試的同學(xué)提供實(shí)時(shí)的覆蓋率分析。

剛才說了那么多我們一步步介紹，下面是具體每一步是怎么做的：

篩選測試用例，一共做了三步：版本提測的時(shí)候做哪些事情，首先會(huì)提供提測版本的信息和線上版本的信息，我們對(duì)這兩個(gè)版本進(jìn)行diff，計(jì)算出diff結(jié)果，結(jié)合變更函數(shù)計(jì)算，通過調(diào)用函數(shù)關(guān)系的計(jì)算，現(xiàn)在想想diff軟件里面是有很多代碼段的，告訴你在哪一行發(fā)生了變化，這一部分是他提供給我們的信息，我們要從這個(gè)信息里得到什么結(jié)論呢？首先要把變更函數(shù)計(jì)算出來，這些代碼段映射到函數(shù)上是哪些函數(shù)發(fā)生變動(dòng)這我要知道，那么和這些函數(shù)相關(guān)聯(lián)的還有哪些函數(shù)？它的調(diào)用關(guān)系我們要知道，要做到這兩點(diǎn)，要從diff結(jié)構(gòu)解析后面兩部分。第三是測試用例生成，解析出來的函數(shù)映射到測試用例上，這些函數(shù)發(fā)生變化或者這些函數(shù)關(guān)聯(lián)的功能發(fā)生變化就可以把這部分測試用例篩選出來。

針對(duì)依賴關(guān)系舉個(gè)例子，開發(fā)為了實(shí)現(xiàn)功能1，同時(shí)修改了函數(shù)A和函數(shù)C，其中函數(shù)之間調(diào)用關(guān)系功能1是C調(diào)用A，功能2是B調(diào)用A，開發(fā)是改了A了，提了C這個(gè)場景，B調(diào)用A就可能出現(xiàn)問題，函數(shù)調(diào)用關(guān)系計(jì)算就是為了解決這樣的場景。

我們這邊服務(wù)端的語言都是JAVA，所以我們是使用了JAVACG工具，通過對(duì)class文件解析計(jì)算函數(shù)之間的調(diào)用關(guān)系。具體就是如圖這樣的結(jié)果，當(dāng)你解析對(duì)于class穩(wěn)健的時(shí)候會(huì)輸出這樣的文件，一大堆調(diào)用關(guān)系在上面，但是只是一層調(diào)用關(guān)系，我們需要通過這種一層調(diào)用關(guān)系把他們串起來，左右關(guān)聯(lián)一下就可以了，所以我們要把函數(shù)調(diào)用鏈關(guān)聯(lián)起來，當(dāng)然你也可以看到，其中有很多第三方庫的函數(shù)調(diào)用關(guān)系，其實(shí)可以通過過濾器把不相關(guān)的過濾掉。

diff結(jié)果解析怎么做的，變更代碼段，解析diff結(jié)果文件，計(jì)算變更文件名和變更代碼段的位置信息。它會(huì)寫第三行第五行發(fā)生了一堆操作，這個(gè)代碼段我們要通過整個(gè)diff結(jié)果文件算出JAVA文件里的代碼信息解析出來要保存。變更函數(shù)怎么辦，我們通過掃描源文件和代碼段的信息判斷一個(gè)包含關(guān)系，比如函數(shù)A包含了這個(gè)代碼段我們認(rèn)為函數(shù)A發(fā)生了一種變化，通過這種方式計(jì)算變更的函數(shù)分類。影響范圍怎么計(jì)算？結(jié)合函數(shù)剛才說的調(diào)用關(guān)系，圈定受影響的函數(shù)范圍，是這樣的流程。

舉個(gè)例子，比如diff結(jié)果，A.java，code有個(gè)開始位置、結(jié)束位置，A.java原文件里也有這些信息，你會(huì)問，如何判斷一個(gè)函數(shù)結(jié)束的位置，開始位置可以判斷，因?yàn)槟阒揽删幾g的函數(shù)自己本身是有編譯器的，不用達(dá)到那個(gè)級(jí)別，比它簡化很多，只要把函數(shù)位置提取出來，肯定是有一個(gè)class特征的，函數(shù)開始位置是沒有問題的，結(jié)束位置大概理解成下一個(gè)函數(shù)開始位置的上一行，但是可能有細(xì)節(jié)，有嵌套類、其他函數(shù)的套用，這一塊細(xì)節(jié)的地方處理一下但是整體思路是這樣的。所以如果第一個(gè)代碼段落到函數(shù)1的區(qū)間范圍內(nèi)的話，我們認(rèn)為這個(gè)代碼段屬于那個(gè)區(qū)間，大概就是這樣的過程。

如圖就是具體解析SVN diff的結(jié)果，代碼段，大家拿到PPT可以詳細(xì)參考一下，我不詳細(xì)講了，非常簡單。三種定義方式我們?nèi)绾闻袛嗪瘮?shù)，只要把函數(shù)信息確定，位置信息拿到就可以了，不用做更深的分析了。

我們實(shí)際達(dá)到的效果是什么？我們要達(dá)到什么樣的效果？以我們工程為例，給出兩個(gè)版本號(hào)，這兩個(gè)版本是這次提測的版本和要比對(duì)的版本，底下就會(huì)把它的變動(dòng)函數(shù)計(jì)算出來，這個(gè)變動(dòng)函數(shù)就包括依賴的函數(shù)，因?yàn)檫@兩個(gè)選的比較近，改了這些內(nèi)容，我們這次需要關(guān)注的所有范圍的函數(shù)信息就在這里。

前面主要介紹從代碼層面影響范圍，最終還是要落在測試用例上的，這是最關(guān)鍵的事情，那么怎么做的？其實(shí)我們也是從一些笨方法開始的，這個(gè)東西有時(shí)候不可能一下達(dá)到最優(yōu)的方式，給大家介紹一下整個(gè)的歷程，大家可以思考一下。

首先，人工錄入是一種非常低效的方式，但是為什么從它開始呢？因?yàn)槲覀円郧熬妥鲞@件事，我們其實(shí)雖然不做白盒測試，但是我們也是做灰盒，測試人員也是需要看代碼的，看代碼了就讓他錄入時(shí)比較順手，這件事情不可持續(xù)只是它原本效率就很低，人工閱讀源碼梳理與業(yè)務(wù)相關(guān)的函數(shù)，并與測試用例建立相關(guān)性，看懂了這個(gè)函數(shù)，覺得和哪個(gè)用例相關(guān)的就人工手動(dòng)關(guān)聯(lián)上。這種占20%，他們會(huì)提一些抱怨，我們怎么給他們提供輔助信息，工具也跟開發(fā)達(dá)成一致，因?yàn)樗麄円蚕Ｍ岣咦约旱拇a質(zhì)量，要求他們寫良好的注釋，我們推動(dòng)開發(fā)撰寫注釋，使用工具把函數(shù)和注釋信息抽出來，那里面有和測試用例對(duì)應(yīng)的場景，還是需要人工建立測試用例的相關(guān)性。這一塊大概占30%，我定義叫中效，其實(shí)它的效率也不高，而且還有可能開發(fā)寫的注釋，你理解上有偏差的地方，但是比第一種又多了一些輔助信息在，其實(shí)最好的是比較高效是代碼染色的工作，根據(jù)測試人員行為自動(dòng)錄入測試用例和函數(shù)的對(duì)應(yīng)關(guān)系，我們特別希望做黑盒測試的時(shí)候可以錄制黑盒測試行為，這樣是最好的方法。

可以看一下最笨的方法是用excel的方式，并不是強(qiáng)制要求大家從零開始做這件事的，其實(shí)之前也開始做這件事了，只不過要求它和測試用例級(jí)對(duì)應(yīng)上，后來我們提供了一個(gè)平臺(tái)，但是沒有從根本上解決這個(gè)問題。如圖這是做代碼覆蓋率的時(shí)候，做覆蓋率分析的時(shí)候可以直接把函數(shù)相關(guān)的內(nèi)容錄入進(jìn)來，效率是有提升，但是還是沒有解決最根本的問題。

給大家介紹一下代碼染色的思想，代碼染色分5步，離不開覆蓋率，首先我們在執(zhí)行黑盒測試用例的時(shí)候，會(huì)收集覆蓋率，因?yàn)槲覀円呀?jīng)做到了黑盒測試覆蓋率的實(shí)時(shí)收集，比如開始錄制我的行為的話，黑盒測試執(zhí)行一段行為，收集覆蓋率，解析覆蓋率的結(jié)果，覆蓋率當(dāng)中發(fā)生變化的函數(shù)和這一次執(zhí)行肯定是有關(guān)系的，我們會(huì)把這些代碼進(jìn)行染色，染色就會(huì)和測試用例級(jí)反向?qū)?yīng)上，再結(jié)合之前的函數(shù)調(diào)用關(guān)系的計(jì)算，相當(dāng)于把范圍稍微放大一點(diǎn)，這些函數(shù)如果發(fā)生變化的話都會(huì)映射到黑盒測試用例上，這樣就形成了雙向追溯，執(zhí)行用例也可以到函數(shù)級(jí)別，函數(shù)級(jí)別變化可以映射到用例上，這種方法效率就得到了很大的提升。

篩選測試用例的流程如圖，首先是基線版本代碼和測試版本代碼diff，對(duì)diff結(jié)果進(jìn)行解析計(jì)算變更的軟件和方法，計(jì)算方法會(huì)把依賴關(guān)系入庫做比對(duì)，如果發(fā)現(xiàn)庫中有的話，直接會(huì)從用例庫里篩選出來，有一部分新增的需求肯定是要手動(dòng)撰寫用例的，這部分沒有辦法，需要手動(dòng)把用例補(bǔ)上，最后合并成一份完整的測試用例。

如圖這就是我們最終達(dá)到的結(jié)果，當(dāng)你篩選出來結(jié)果的話，包含所有函數(shù)的信息以及對(duì)這種函數(shù)的理解和最后要執(zhí)行的測試用例級(jí)，點(diǎn)進(jìn)去可以直接執(zhí)行測試用例。

簡單給大家說一下覆蓋率，我們主要做兩種，JAVA覆蓋率和JS覆蓋率，JAVA不多說，大家都用jacoco，但是我建議用on-the-fly模式。JS我們選擇了一種工具，大部分工具都是支持單元測試的，對(duì)我們黑盒測試不是很友好，我們基于JScover做了二次開發(fā)，實(shí)現(xiàn)插樁上報(bào)加代理的方式，同時(shí)支持源文件和ES6編譯文件的插樁。

JS多說一句，覆蓋率無非要做四件事，代碼插樁、數(shù)據(jù)上報(bào)、文件映射、生成報(bào)告。代碼插樁主要針對(duì)源文件和編譯文件，JScover就可以做這件事情。數(shù)據(jù)上報(bào)可能需要改動(dòng)一些代碼，文件映射需要一個(gè)代理，把所有線上的請(qǐng)求映射到本地這一塊需要有個(gè)代理。生成報(bào)告這塊，實(shí)際上自己支持的也比較好。

數(shù)據(jù)上報(bào)，可以通過一些事件進(jìn)行數(shù)據(jù)上報(bào)，這里列了兩個(gè)，比如頁面切換，像測PC的時(shí)候，如果頁面發(fā)生切換就讓它報(bào)上來一次就可以，無線的話可能涉及到滾動(dòng)，這樣的話一般是鼠標(biāo)移動(dòng)，不要行行都報(bào)一次，那樣對(duì)業(yè)務(wù)測試壓力比較大，比如鼠標(biāo)往下滾動(dòng)一次，鼠標(biāo)有操作了就報(bào)上來一次，這種不會(huì)發(fā)現(xiàn)前端測試有性能問題，工具引起的性能問題不會(huì)有，這個(gè)效果還不錯(cuò)，這個(gè)大家感興趣可以回去看一下。

說一下ES6，為什么要兼容ES6標(biāo)準(zhǔn)呢？前段時(shí)間大家都用JS框架開發(fā)，他們都是采用ES6方式了，已經(jīng)不是原生JS了，之前是在JS插樁就可以上報(bào)了，需要編譯的話像右圖這種怎么辦？選擇一個(gè)什么節(jié)點(diǎn)進(jìn)行插樁呢？源碼是易讀不可執(zhí)行的，這種插樁沒有意義，編譯后較易度可執(zhí)行，壓縮混淆后不易讀，可執(zhí)行，我們選擇了這種方式對(duì)編譯后的插樁，這樣可以選擇ES6的開發(fā)模式。

大家參考一下就可以了，這是我們一個(gè)覆蓋率分析的，有JS的工程也有JAVA的工程，都是支持立即收集覆蓋率的，前端做一些工作就可以覆蓋率實(shí)時(shí)察看，這是覆蓋率的基本信息，如圖相當(dāng)于左邊是JAVA的結(jié)果頁面，右面是JS的，JAVA這一塊有一個(gè)bug的提示，相當(dāng)于這是一個(gè)diff結(jié)果，看哪塊沒有覆蓋，如果對(duì)這一塊函數(shù)有告警說它有bug的話也可以察看，都可以打通。這是我們整個(gè)的測試流程，把它列在這兒，如果做精準(zhǔn)化測試的話，可以在哪個(gè)部分把這個(gè)事情做了。首先提測前，跟大家差不多，需求評(píng)審、用例編寫、用例評(píng)審、提測前準(zhǔn)備、提測走查，這個(gè)主要支持在提測到預(yù)發(fā)布、上線支持的部分，我們篩選出來的測試用例不僅用于測試人員而且還用于開發(fā)的提測前的默驗(yàn)測試以及產(chǎn)品提測前的走查。

我們現(xiàn)在做的工作如圖，可能每個(gè)公司都有不一樣的東西，我們這邊不是運(yùn)維發(fā)布代碼的，實(shí)際上開發(fā)有很大的權(quán)限，它可以直接把代碼發(fā)布，我們對(duì)開發(fā)所有發(fā)布系統(tǒng)做了監(jiān)控，他們有代碼發(fā)布，無論是線上還是測試環(huán)境，我們這邊會(huì)啟動(dòng)所有的操作，只要有一次發(fā)布這一塊都會(huì)自動(dòng)執(zhí)行，如果有測試的話在他提測行為發(fā)生以后，我們測試人員就會(huì)收到一封郵件，郵件里包含上述所有的計(jì)算結(jié)果，測試之前就可以拿到所有的信息，最大化幫助功能測試人員提高他的測試效率。持續(xù)集成這一塊也會(huì)跟很多自動(dòng)化平臺(tái)打通這些自動(dòng)化都是精準(zhǔn)自動(dòng)化，都是通過篩選出來的自動(dòng)化用例。

以上就是我的全部分享內(nèi)容。