汽車之家新車電商事業部高級測試工程師聞小龍做《QA團隊精準測試實踐之路》主題演講。聞小龍指出，“自動化測試本質上是根據測試的設計去執行的，只是執行手段不一樣，當設計出了問題，自動化測試不管再怎么執行還是會遺漏那個問題，所以，自動化測試沒有解決所有的問題�！�

以下為聞小龍演講實錄：

我是汽車之家電商事業部的聞小龍，今天很高興給大家進行分享，我想先做一個現場調查，在座各位多數工作是功能測試相關的？還是很多的！我也是一名一線測試人員，所以我今天講的內容可能大家會比較感同身受。

濟南網站建設公司組內每隔一段時間聚在一起聊聊最近工作的問題和可以改進的地方，時間長了，濟南網站建設公司發現問題是多種多樣的，但抽象出來后最主要的矛盾大概有那么兩個。

一、測試深度、廣度，與測試資源、項目時間的矛盾。

二、被測系統的黑盒狀態與需要了解系統的矛盾。

發現矛盾以后濟南網站建設公司進行了思考，下面我想說一下整個思考的過程，并且這個過程我想通過一個比較有意思的方式去跟大家交流。

前一段時間我發現一個游戲，這個游戲在朋友圈流行過一段時間，相信很多人也都玩過，規則很簡單，你需要在規定時間內找出跟周圍色塊不一樣的色塊，左邊圖是第一關的截圖，大家很容易看到右下角色塊會淺一些，點擊它，這關就成功了。當玩兒到55關的時候，大家還能一眼找到不同的色塊嗎？

還是有一些難度的是吧，所以我覺得我死在這關不是特別冤，當色塊不斷增加你會發現難度是會遞增的，我覺得這個東西特別像濟南網站建設公司的測試，為什么這樣說呢？大家都寫過用例，用例設計是把不同邏輯分支進行組合，最后會羅列出來數量比較大邏輯路徑，測試工作的本質是什么？濟南網站建設公司對所有路徑進行覆蓋，然后找出其中有問題的幾個路徑，舉個例子，比如：訂單系統的測試，訂單類型其實就有很多，再加上不同平臺下PC端，APP端；還需要考慮中間的操作差異，比如說我加到購物車里下單，還是直接下單，考慮完這些影響因素以后，按照濟南網站建設公司用例設計方法正交分析法進行分析，很簡單的一個下單場景，我發現有102種路徑組合�！�

假如說濟南網站建設公司訂單系統修改了其中一個路徑，要完整回歸102種下單情況，才能覆蓋所有的邏輯。濟南網站建設公司發現這個成本在濟南網站建設公司敏捷開發和快速迭代當中是一個很大的瓶頸。

濟南網站建設公司要去解決這個問題，第一個想到的就是減少工作量，還是從游戲說起，既然這一關難以完成，并且濟南網站建設公司分析了造成難度的是色塊數量過多，濟南網站建設公司有沒有什么方法把色塊減少呢？如果濟南網站建設公司能把色塊減少是不是意味著回到了前面的關卡，所以你就能快速的把問題色塊找出來。映射到測試，每個團隊都有經驗豐富的員工，會根據這次改動告訴你其實有一些訂單類型是不用回歸的，因為這些跟你的改動點關系比較弱，所以說濟南網站建設公司不用測；然后會告訴你這個邏輯的改動點，和他是否加入購物車其實感覺上關系不大，所以直接測直接下單就可以包含所有場景。

當濟南網站建設公司把經驗者建議的影響因素刨除后，濟南網站建設公司發現場景確實大大減少了，但是長時間按照這種思路實施以后，你會發現你還是偶爾的遇到一些線上的問題，你拿出來復盤分析的時候會發現你排除掉的路徑出了問題。為什么會出現這個問題？分析到最后發現是因為這種經驗性的進行測試范圍的縮減是沒有依據的，當你把你的可能發現問題的路徑排除在計劃之外的時候，不管執行做的再仔細，其實在計劃階段你已經失去了發現它的可能性。

濟南網站建設公司測試人員真的沒有辦法搞定這個問題么？這時候就有人會說既然質量保證是濟南網站建設公司天職，那濟南網站建設公司還是需要投入足夠的資源和時間把所有路徑都回歸完，起碼能夠保證系統的穩定性。但是說這句話的同學忽略了一個問題，游戲的右上角是有時間的，游戲規則不允許你隨意的拉長單局時間，就像你老板跑過來質問你，為什么我給了你這么多人，卻沒有達到快速迭代的效果一樣。

這時候濟南網站建設公司就想，難道濟南網站建設公司就沒有一個好方法了嗎？當然不是。依據大家玩游戲的經驗，你想快速而顯著的提高游戲能力，其實很簡單，那就是充錢買道具。現在大家看到的就是濟南網站建設公司的第一個道具：自動化測試，這也是濟南網站建設公司的第一個想法，既然你工作量過大，那我也不去想怎么減少你的工作量，我用一個更直接粗暴的辦法，使用工具遍歷所有路徑，大家都知道自動化測試執行成本是不高的對吧，它能在瞬間完成海量的路徑覆蓋，這是一個優點。但是自動化測試真的一勞永逸么？從很久之前行業就存在了很多的自動化解決方案，當然濟南網站建設公司也不能免俗，不管是UI、API的濟南網站建設公司都做了大量嘗試，但是真的實踐過程當中濟南網站建設公司發現自動化這個道具還是存在一些問題的。

自動化測試并不是憑空而生，每一次需求進行到開發提測階段，進行腳本編寫的時候其實是一個很大的成本。有的同學會說，腳本編寫是一次性成本，可能第二次回歸時候你去用它就沒有這部分的成本了，但是你真的在做時候就會發現，當項目進行快速迭代時，第一個版本寫好的腳本往往到了下一個版本就跑不通了，所以又需要你去付出一些維護成本。

自動化測試還有一個問題，它在一些技術棧當中不能保證所有地方都能覆蓋到，有一些不能覆蓋的地方，濟南網站建設公司通常會在自動化測試測后增加手工檢查，因為人的靈活性還是有巨大優勢的。但是這里有一個問題，自動化測試跑完以后移交給手工人員，但當功能總量很大的時候，你發現你已經無法特別精準的描述你需要補充的地方了，所以手工測試人員就不能有的放矢，被迫按照自己的方式做盡量多的覆蓋，這樣會在測試過程中重新引入主觀因素，最后無法避免的造成漏測。

另一方面，還記得前面咱們說過的盲目測試范圍縮減會造成漏測的問題么，其實自動化測試也會遇到這個問題，因自動化測試本質上是根據測試的設計去執行的，只是執行手段不一樣，當設計出了問題，自動化測試不管再怎么執行還是會遺漏那個問題，所以，自動化測試并沒有解決所有的問題。

濟南網站建設公司發現，原來自動化測試有這么多不盡如人意的地方，這個道具有一些缺陷，那濟南網站建設公司是不是該尋找一些新的道具呢？濟南網站建設公司先不揭曉有哪些新道具，濟南網站建設公司分析一下濟南網站建設公司到底需要些什么？

還記得濟南網站建設公司開始說的兩個主要矛盾么，第一個矛盾其實就是工作量與資源時間的矛盾，那濟南網站建設公司最需要一個工具去指引濟南網站建設公司縮小工作量，但是這個縮小要是有依據的，濟南網站建設公司需要的這個范圍，一定是可以找出所有問題的，這是濟南網站建設公司想要的第一個道具。

如果還可以擁有一個道具，濟南網站建設公司可以順著后面自動化的思路來想，自動化是一定要做的，但是自動化中主要的問題需要第二個道具來彌補，這個工具可以告訴濟南網站建設公司一個自動化明確的邊界，它可以是一個可視化顯示，告訴手工人員需要對哪些東西進行補測。

濟南網站建設公司既然有了這些愿景，濟南網站建設公司就進行了一些調查和思考，濟南網站建設公司發現，第一個縮小測試范圍的功能需要在代碼維度入手，通過開發每次提交的代碼差異去分析濟南網站建設公司需要測試的范圍，濟南網站建設公司拿到代碼變動去分析測試范圍，這就把分析過程做到了有據可依，這也解決了濟南網站建設公司開頭提到的對系統了解不足的矛盾。

第二個工具是對測試過程進行可視化反饋，這個東西就是代碼覆蓋率監控，不管是自動化測試還是手工測試，最后都會得到一個可視化的測試報告，就是哪些邏輯跑過了，哪些邏輯還沒有跑。

有了這兩個理論基礎后，濟南網站建設公司查找可復用的技術棧時發現已經有了一些比較好的開源工具，濟南網站建設公司將這些開源軟件進行二次開發，加上自研的DIFF引擎，可以達到濟南網站建設公司的預期想法，濟南網站建設公司依據這些思路對系統進行了實現，下面這一部分是工具在濟南網站建設公司項目當中跑起來以后，過程中的一些實踐和收益情況,下面濟南網站建設公司大家一起看一下。

首先簡單說一下實現思路和使用的技術棧，首先濟南網站建設公司代碼管理托管在私有的gitlab上，首先濟南網站建設公司通過Git Diff命令獲取代碼差異，當開發修改了代碼提交版本后，濟南網站建設公司用這個版本和上一個版本進行DIFF，差異信息會告訴你某一段代碼哪幾行發生了改變。濟南網站建設公司通過一些字符處理方式，把這個處理成通用的Json格式的數據，格式大致為某一個JAVA類中哪些行發生了改變。濟南網站建設公司分析數據發現這不是濟南網站建設公司想要的。因為行沒有很好的含義性，濟南網站建設公司發現方法是很好的入口，因為一個方法是一個動作，濟南網站建設公司其實想知道的是哪些動作發生了變化，然后進行針對性測試。所以濟南網站建設公司需要對它進行轉化，在轉化的過程中用到了AST(抽象語法樹)，抽象語法樹的簡稱是AST，這是一個可以把靜態代碼實例化成樹狀結構的工具，這個樹狀結構的每一個節點都是一個語法結構，方法，行，甚至注解都是語法樹的一個節點。都可以方便的進行分析和處理，濟南網站建設公司通過語法樹可以拿到每一個方法行范圍，大家知道上一步已經拿到了差異行號，濟南網站建設公司用差異行號去命中所有的方法，當一個行號命中了一個方法，濟南網站建設公司把這個方法進行標記，最后濟南網站建設公司得到了差異的方法列表，方法是動作，因此，濟南網站建設公司知道了哪些動作發生了代碼變動，濟南網站建設公司需要對這些動作進行覆蓋。

看架構圖中的紅線，是方法的差異列表，濟南網站建設公司把數據引出來，然后濟南網站建設公司灌到覆蓋率監控里，就會得到基于代碼變動的覆蓋率監控報告。

Jacoco大家如果關注過覆蓋率監控，應該都聽說過，是JAVA語言里的一個覆蓋率監控開源工具，濟南網站建設公司對源碼進行了二次開發，并與代碼差異分析數據結合，下面講述這兩者是如何進行融合的。

首先濟南網站建設公司需要簡單說一下Jacoco的工作原理，首先Jacoco分為兩部分，第一部分是插樁部分，對被測服務進行插裝操作，其實就是在每一個邏輯分支插一個探針，當邏輯分支被執行了，探針會變成True，未被執行會保持初始的fals,最后通過探針數據濟南網站建設公司就能得到哪些邏輯被執行過了，而哪些邏輯未被執行，下面濟南網站建設公司來說Jacoco的第二部分，命令部分，濟南網站建設公司可以通過一個jacoco的dump命令遠程獲取這些探針數據。

第二個是merge命令，其實是將多次拿到的探針數據進行合并操作，這個解決了什么問題呢？舉個例子當被測服務多次重啟，但是重啟前做的覆蓋數據如果不想丟掉，就需要將它合并到一起，這樣能夠保證探針數據的完整性，當你拿到完整覆蓋率數據以后，最后一步是report命令，這個命令是把覆蓋率數據形成一份可視化報告，告訴你整個的項目有多少被覆蓋。

接下來就是代碼差異信息的引入，濟南網站建設公司入手點是在可視化的時候做一個過濾，當執行report命令時，會有一個遍歷所有方法生成報告的邏輯，濟南網站建設公司會在這個遍歷的過程中判斷當前方法是否發生改變，如果沒有改變濟南網站建設公司就剔除掉，最后得到的就是濟南網站建設公司需要測試部分的報告了。