第二，就給大家介紹一下精準(zhǔn)化測試思想，簡單介紹一下，這有一句話我念一遍，因為我看過很多精準(zhǔn)化相關(guān)的資料，我認(rèn)為這句話總結(jié)的非常到位，精準(zhǔn)化測試就是“用非常精準(zhǔn)和智能的軟件來解決軟件測試的問題，并從根本上引領(lǐng)軟件測試，從經(jīng)驗型方法向技術(shù)性方法的轉(zhuǎn)型”。它強(qiáng)調(diào)兩點，首先當(dāng)然是需要解決問題的，精準(zhǔn)和智能是精準(zhǔn)化測試?yán)镆劢沟膬蓚�點，如果做精準(zhǔn)化測試一定要聚焦在這兩個點上，它要達(dá)到的目標(biāo)是什么？從經(jīng)驗型方法向技術(shù)性方法轉(zhuǎn)移，黑盒測試大多依賴于經(jīng)驗型方法，如何在經(jīng)驗型方法中提升技術(shù)性的手段就是我們精準(zhǔn)化測試的目的。
分別介紹一下，首先介紹一下精準(zhǔn)要做哪些事，我們這邊的精準(zhǔn)：
1、測試用例到代碼邏輯精準(zhǔn)記錄的雙向追溯。什么叫雙向追溯，執(zhí)行黑盒測試用例直接就能映射到你的代碼邏輯上，看代碼邏輯也能反向用到測試用例上，一定是雙向的，如果是單向的，這個效率是提高不了多少的。怎么實現(xiàn)？代碼邏輯到測試用例是通過函數(shù)調(diào)用關(guān)系計算來的，我們提出一種方法叫代碼染色，這兩個都會在后面詳細(xì)給大家介紹。
2、精準(zhǔn)的代碼級的缺陷定位和崩潰分析。在做黑盒測試的過程中，我們一定要給黑盒測試同學(xué)提供什么樣的方法？測著測著發(fā)現(xiàn)一個bug，他自己就知道哪塊代碼出問題了，要達(dá)到這種效果，崩潰也是要能落到崩潰分析上。
3、精準(zhǔn)的測試充分度分析，主要是解決測試不可度量的問題。
智能有哪些？主要列了3點：
1、回歸用例的自動篩選。
2、自動化用例篩選與執(zhí)行。
3、持續(xù)集成。
第二部分就簡單介紹到這，主要介紹第三部分，告訴大家如何去做，上面那些事，如果我想做的話一步步怎么做？我給大家分享我們在搜狗社區(qū)具體應(yīng)用的案例，我們現(xiàn)在正在做的事，大概是做成什么樣子。
首先再給大家提一下影響效率的因素，因為我們這里主要要解決效率的問題，列了很多，剛才也有人說過了：
1、團(tuán)隊新人沒有經(jīng)驗。
2、團(tuán)隊新人能力不足。
3、測試范圍圈定憑經(jīng)驗。這里我們經(jīng)常遇到那種情況，開發(fā)改了一段代碼，需求上寫的很清晰，我們都測到了，但是卻有另外一個場景出現(xiàn)問題，是有關(guān)聯(lián)的，我們很難把那部分測試用例圈出來。
4、測試用例篩選難，讓你從曾經(jīng)的測試用例篩選出這次的測試用例，這個很難。
5、測試經(jīng)驗沉淀效果差，我們這個測試經(jīng)驗沉淀基本是口口相傳，沉淀的東西是靜態(tài)的，無法動起來，看代碼、整理接口、就編成一篇篇測試文檔，或者在某個軟件、某個平臺里落在那兒了，它動不起來，不實際，用到不會查，查還可能查不全，怎么讓這些資料主動為你提供幫助，這是我們做的事情。
6、測試人員狀態(tài)不穩(wěn)定，主要是指大家的心理和生理狀態(tài)。
最初我們給自己提了4個目標(biāo)，我們要解決的問題：
1、要精準(zhǔn)圈定我的測試范圍。
2、對影響的范圍必須給出建議；如果測這個版本要有個東西，暫且叫它軟件，要告訴我還有哪些東西要考慮。
3、自動篩選測試用例，要測這個版本了，至少給我一份測試用例讓我做參考。
4、為黑盒測試提供實時覆蓋率結(jié)果。
為什么強(qiáng)調(diào)實時覆蓋率改革呢？有時候我們經(jīng)常做覆蓋率，一堆功能做完了，讓我們出一份覆蓋率軟件去分析，發(fā)現(xiàn)有幾行沒有覆蓋到，再往回推，效率也是比較低的，我們要達(dá)到什么情況？比如，我執(zhí)行了非常短的業(yè)務(wù)流程可能就是一個登陸，三步操作，輸入用戶名、輸入密碼、提交，這三步操作希望知道我的覆蓋率是什么，及時調(diào)整覆蓋用例，這個對我們價值是比較大的，所以我們必須為黑盒測試的同學(xué)提供實時的覆蓋率分析。
剛才說了那么多我們一步步介紹，下面是具體每一步是怎么做的：
篩選測試用例，一共做了三步：版本提測的時候做哪些事情，首先會提供提測版本的信息和線上版本的信息，我們對這兩個版本進(jìn)行diff，計算出diff結(jié)果，結(jié)合變更函數(shù)計算，通過調(diào)用函數(shù)關(guān)系的計算，現(xiàn)在想想diff軟件里面是有很多代碼段的，告訴你在哪一行發(fā)生了變化，這一部分是他提供給我們的信息，我們要從這個信息里得到什么結(jié)論呢？首先要把變更函數(shù)計算出來，這些代碼段映射到函數(shù)上是哪些函數(shù)發(fā)生變動這我要知道，那么和這些函數(shù)相關(guān)聯(lián)的還有哪些函數(shù)？它的調(diào)用關(guān)系我們要知道，要做到這兩點，要從diff結(jié)構(gòu)解析后面兩部分。第三是測試用例生成，解析出來的函數(shù)映射到測試用例上，這些函數(shù)發(fā)生變化或者這些函數(shù)關(guān)聯(lián)的功能發(fā)生變化就可以把這部分測試用例篩選出來。
針對依賴關(guān)系舉個例子，開發(fā)為了實現(xiàn)功能1，同時修改了函數(shù)A和函數(shù)C，其中函數(shù)之間調(diào)用關(guān)系功能1是C調(diào)用A，功能2是B調(diào)用A，開發(fā)是改了A了，提了C這個場景，B調(diào)用A就可能出現(xiàn)問題，函數(shù)調(diào)用關(guān)系計算就是為了解決這樣的場景。
我們這邊服務(wù)端的語言都是JAVA，所以我們是使用了JAVACG工具，通過對class文件解析計算函數(shù)之間的調(diào)用關(guān)系。具體就是如圖這樣的結(jié)果，當(dāng)你解析對于class穩(wěn)健的時候會輸出這樣的文件，一大堆調(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)系，其實可以通過過濾器把不相關(guān)的過濾掉。
diff結(jié)果解析怎么做的，變更代碼段，解析diff結(jié)果文件，計算變更文件名和變更代碼段的位置信息。它會寫第三行第五行發(fā)生了一堆操作，這個代碼段我們要通過整個diff結(jié)果文件算出JAVA文件里的代碼信息解析出來要保存。變更函數(shù)怎么辦，我們通過掃描源文件和代碼段的信息判斷一個包含關(guān)系，比如函數(shù)A包含了這個代碼段我們認(rèn)為函數(shù)A發(fā)生了一種變化，通過這種方式計算變更的函數(shù)分類。影響范圍怎么計算？結(jié)合函數(shù)剛才說的調(diào)用關(guān)系，圈定受影響的函數(shù)范圍，是這樣的流程。
舉個例子，比如diff結(jié)果，A.java，code有個開始位置、結(jié)束位置，A.java原文件里也有這些信息，你會問，如何判斷一個函數(shù)結(jié)束的位置，開始位置可以判斷，因為你知道可編譯的函數(shù)自己本身是有編譯器的，不用達(dá)到那個級別，比它簡化很多，只要把函數(shù)位置提取出來，肯定是有一個class特征的，函數(shù)開始位置是沒有問題的，結(jié)束位置大概理解成下一個函數(shù)開始位置的上一行，但是可能有細(xì)節(jié)，有嵌套類、其他函數(shù)的套用，這一塊細(xì)節(jié)的地方處理一下但是整體思路是這樣的。所以如果第一個代碼段落到函數(shù)1的區(qū)間范圍內(nèi)的話，我們認(rèn)為這個代碼段屬于那個區(qū)間，大概就是這樣的過程。
如圖就是具體解析SVN diff的結(jié)果，代碼段，大家拿到PPT可以詳細(xì)參考一下，我不詳細(xì)講了，非常簡單。三種定義方式我們?nèi)绾闻袛嗪瘮?shù)，只要把函數(shù)信息確定，位置信息拿到就可以了，不用做更深的分析了。
我們實際達(dá)到的效果是什么？我們要達(dá)到什么樣的效果？以我們工程為例，給出兩個版本號，這兩個版本是這次提測的版本和要比對的版本，底下就會把它的變動函數(shù)計算出來，這個變動函數(shù)就包括依賴的函數(shù)，因為這兩個選的比較近，改了這些內(nèi)容，我們這次需要關(guān)注的所有范圍的函數(shù)信息就在這里。
前面主要介紹從代碼層面影響范圍，最終還是要落在測試用例上的，這是最關(guān)鍵的事情，那么怎么做的？其實我們也是從一些笨方法開始的，這個東西有時候不可能一下達(dá)到最優(yōu)的方式，給大家介紹一下整個的歷程，大家可以思考一下。
現(xiàn)場視頻（下）
首先，人工錄入是一種非常低效的方式，但是為什么從它開始呢？因為我們以前就做這件事，我們其實雖然不做白盒測試，但是我們也是做灰盒，測試人員也是需要看代碼的，看代碼了就讓他錄入時比較順手，這件事情不可持續(xù)只是它原本效率就很低，人工閱讀源碼梳理與業(yè)務(wù)相關(guān)的函數(shù)，并與測試用例建立相關(guān)性，看懂了這個函數(shù)，覺得和哪個用例相關(guān)的就人工手動關(guān)聯(lián)上。這種占20%，他們會提一些抱怨，我們怎么給他們提供輔助信息，工具也跟開發(fā)達(dá)成一致，因為他們也希望提高自己的代碼質(zhì)量，要求他們寫良好的注釋，我們推動開發(fā)撰寫注釋，使用工具把函數(shù)和注釋信息抽出來，那里面有和測試用例對應(yīng)的場景，還是需要人工建立測試用例的相關(guān)性。這一塊大概占30%，我定義叫中效，其實它的效率也不高，而且還有可能開發(fā)寫的注釋，你理解上有偏差的地方，但是比第一種又多了一些輔助信息在，其實最好的是比較高效是代碼染色的工作，根據(jù)測試人員行為自動錄入測試用例和函數(shù)的對應(yīng)關(guān)系，我們特別希望做黑盒測試的時候可以錄制黑盒測試行為，這樣是最好的方法。
可以看一下最笨的方法是用excel的方式，并不是強(qiáng)制要求大家從零開始做這件事的，其實之前也開始做這件事了，只不過要求它和測試用例級對應(yīng)上，后來我們提供了一個平臺，但是沒有從根本上解決這個問題。如圖這是做代碼覆蓋率的時候，做覆蓋率分析的時候可以直接把函數(shù)相關(guān)的內(nèi)容錄入進(jìn)來，效率是有提升，但是還是沒有解決最根本的問題。
給大家介紹一下代碼染色的思想，代碼染色分5步，離不開覆蓋率，首先我們在執(zhí)行黑盒測試用例的時候，會收集覆蓋率，因為我們已經(jīng)做到了黑盒測試覆蓋率的實時收集，比如開始錄制我的行為的話，黑盒測試執(zhí)行一段行為，收集覆蓋率，解析覆蓋率的結(jié)果，覆蓋率當(dāng)中發(fā)生變化的函數(shù)和這一次執(zhí)行肯定是有關(guān)系的，我們會把這些代碼進(jìn)行染色，染色就會和測試用例級反向?qū)?yīng)上，再結(jié)合之前的函數(shù)調(diào)用關(guān)系的計算，相當(dāng)于把范圍稍微放大一點，這些函數(shù)如果發(fā)生變化的話都會映射到黑盒測試用例上，這樣就形成了雙向追溯，執(zhí)行用例也可以到函數(shù)級別，函數(shù)級別變化可以映射到用例上，這種方法效率就得到了很大的提升。
篩選測試用例的流程如圖，首先是基線版本代碼和測試版本代碼diff，對diff結(jié)果進(jìn)行解析計算變更的軟件和方法，計算方法會把依賴關(guān)系入庫做比對，如果發(fā)現(xiàn)庫中有的話，直接會從用例庫里篩選出來，有一部分新增的需求肯定是要手動撰寫用例的，這部分沒有辦法，需要手動把用例補(bǔ)上，最后合并成一份完整的測試用例。
如圖這就是我們最終達(dá)到的結(jié)果，當(dāng)你篩選出來結(jié)果的話，包含所有函數(shù)的信息以及對這種函數(shù)的理解和最后要執(zhí)行的測試用例級，點進(jìn)去可以直接執(zhí)行測試用例。
簡單給大家說一下覆蓋率，我們主要做兩種，JAVA覆蓋率和JS覆蓋率，JAVA不多說，大家都用jacoco，但是我建議用on-the-fly模式。JS我們選擇了一種工具，大部分工具都是支持單元測試的，對我們黑盒測試不是很友好，我們基于JScover做了二次開發(fā)，實現(xiàn)插樁上報加代理的方式，同時支持源文件和ES6編譯文件的插樁。
JS多說一句，覆蓋率無非要做四件事，代碼插樁、數(shù)據(jù)上報、文件映射、生成報告。代碼插樁主要針對源文件和編譯文件，JScover就可以做這件事情。數(shù)據(jù)上報可能需要改動一些代碼，文件映射需要一個代理，把所有線上的請求映射到本地這一塊需要有個代理。生成報告這塊，實際上自己支持的也比較好。
數(shù)據(jù)上報，可以通過一些事件進(jìn)行數(shù)據(jù)上報，這里列了兩個，比如頁面切換，像測PC的時候，如果頁面發(fā)生切換就讓它報上來一次就可以，無線的話可能涉及到滾動，這樣的話一般是鼠標(biāo)移動，不要行行都報一次，那樣對業(yè)務(wù)測試壓力比較大，比如鼠標(biāo)往下滾動一次，鼠標(biāo)有操作了就報上來一次，這種不會發(fā)現(xiàn)前端測試有性能問題，工具引起的性能問題不會有，這個效果還不錯，這個大家感興趣可以回去看一下。
說一下ES6，為什么要兼容ES6標(biāo)準(zhǔn)呢？前段時間大家都用JS框架開發(fā)，他們都是采用ES6方式了，已經(jīng)不是原生JS了，之前是在JS插樁就可以上報了，需要編譯的話像右圖這種怎么辦？選擇一個什么節(jié)點進(jìn)行插樁呢？源碼是易讀不可執(zhí)行的，這種插樁沒有意義，編譯后較易度可執(zhí)行，壓縮混淆后不易讀，可執(zhí)行，我們選擇了這種方式對編譯后的插樁，這樣可以選擇ES6的開發(fā)模式。
大家參考一下就可以了，這是我們一個覆蓋率分析的，有JS的工程也有JAVA的工程，都是支持立即收集覆蓋率的，前端做一些工作就可以覆蓋率實時察看，這是覆蓋率的基本信息，如圖相當(dāng)于左邊是JAVA的結(jié)果頁面，右面是JS的，JAVA這一塊有一個bug的提示，相當(dāng)于這是一個diff結(jié)果，看哪塊沒有覆蓋，如果對這一塊函數(shù)有告警說它有bug的話也可以察看，都可以打通。這是我們整個的測試流程，把它列在這兒，如果做精準(zhǔn)化測試的話，可以在哪個部分把這個事情做了。首先提測前，跟大家差不多，需求評審、用例編寫、用例評審、提測前準(zhǔn)備、提測走查，這個主要支持在提測到預(yù)發(fā)布、上線支持的部分，我們篩選出來的測試用例不僅用于測試人員而且還用于開發(fā)的提測前的默驗測試以及產(chǎn)品提測前的走查。
我們現(xiàn)在做的工作如圖，可能每個公司都有不一樣的東西，我們這邊不是運維發(fā)布代碼的，實際上開發(fā)有很大的權(quán)限，它可以直接把代碼發(fā)布，我們對開發(fā)所有發(fā)布系統(tǒng)做了監(jiān)控，他們有代碼發(fā)布，無論是線上還是測試環(huán)境，我們這邊會啟動所有的操作，只要有一次發(fā)布這一塊都會自動執(zhí)行，如果有測試的話在他提測行為發(fā)生以后，我們測試人員就會收到一封郵件，郵件里包含上述所有的計算結(jié)果，測試之前就可以拿到所有的信息，最大化幫助功能測試人員提高他的測試效率。持續(xù)集成這一塊也會跟很多自動化平臺打通這些自動化都是精準(zhǔn)自動化，都是通過篩選出來的自動化用例。
關(guān)于Testin
