文章整理於 朱少民（《全程軟件測試》作者）在TiD2019質量競爭力大會的演講《AI技術助力軟件測試達到“質效合一”》
TiD2019質量競爭力大會邀請了國內軟件測試知名專家、軟件綠色聯盟標準評測組組長、《全程軟件測試（第3版）》作者朱少民老師爲參會者帶來《AI技術助力軟件測試達到“質效合一”》精彩演講。朱少民老師從目前測試及其自動化的形勢、AI提升測試效率和AI技術有助於測試覆蓋率三方面講述。
目前測試及其自動化的形勢
目前整個軟件質量工程環境與軟件開發的節奏越來越快，開發團隊受制於市場的競爭，需要持續構建、持續集成、持續測試才能做到持續交付。持續測試在當今軟件研發中很有必要，測試的最終目的需要達到這種極致的狀態。
在Google，一個測試用例的執行不能超過60秒，時間越短越有價值。同時Google也強調自動化測試。Google之前有一個著名的GTAC，就是自動化測試會議。現在這個會議已經改成工程效能。目前，效能逐漸被注重起來。Google以前把公司的測試部門和質量部門稱爲工程效率部門，現在包括阿里、百度等大公司也開始注重效能。效能不僅是從速度上體現的，還可以從質量上來體現。
那麼，爲什麼要做測試？測試最終爲業務服務。無論是做開發還是做測試，最終都是爲了解決業務問題、解決用戶的問題。開發更多地是構建質量，而測試是質量的守護者，可以幫助開發少犯錯誤，提醒開發需要改進的方面。這樣就更好地幫助團隊構建質量。作爲質量守護者也不是要完全到最後才做系統測試、驗收測試，守護質量可以從全過程來守護質量。
測試的效率是當今社會關注的焦點。白盒測試、黑盒測試、手工測試、自動化測試，哪一個效率更高呢？朱少民介紹道，手工測試的效率有時候也可以很高，但現在靜態測試做得比較少，更多地是動態測試。靜態測試工具自動做一些安全性和漏洞模式的檢測，不需要投入太多的人力，人力只需要對結果進行分析。有些工具的誤報率可能比較高，基本上降到10%，高的話可能也會有20%-30%。
自動化公認會帶來高效率的，敏捷開發的迴歸測試範圍越來越大，完全靠手工測試肯定不行。在一般情況下，軟件測試中迴歸測試更適合自動化，雖然這個觀點是比較老的，但是還是適用於當今環境。
然而工具的發展能力比較弱，過分關注工具、關注腳本本身，往往就忽視了業務、產品與測試用例的質量和覆蓋率。面對大量的代碼和組件，有經驗的工程師在系統和業務層次上的探索式測試能保證質量。但是機器理解這個業務是很困難的，當今人工智能工具多數是脫離業務的，真正跟業務結合比較緊密的工具還是很少見的。AI測試工具可以理解代碼，但是真正跟業務結合起來的數據也很少。就像機器學習有時候需要大量的數據，但是真正基於業務的數據比較少，像開源裏面有4TB的代碼，這些代碼更多的是可以做Java、C、Python這方面語言的學習，甚至可以做到Bug的自動定位、Bug的自動修復。但是如果真正結合業務，發現與業務結合這個工具還是很弱的，需要靠人進行測試。
從測試質量來講，代碼覆蓋率只是一個比較客觀的結果，但是代碼覆蓋率做到100%，也不能保證很高的質量。開發很容易就可以做到代碼覆蓋100%，但是不會測一些非法的或特殊值的輸入。所以這個角度來講，代碼行做到100%覆蓋還會遺漏比較多的缺陷。當今多數企業甚至對代碼行100%的覆蓋都沒有要求，只有部分企業要求代碼行覆蓋做到80%以上。代碼是有控制流和數據流的。代碼行覆蓋、分支覆蓋是控制流。數據流主要是變量的定義和引用，在一般的軟件裏不會做代碼的分析，只有在航空航天、核工業，或者其他的一些生命相關的系統會做變量的定義和引用的分析。
測試是爲了滿足業務的要求。之前去某金融科技公司或者其他一些公司交流，發現他們都沒真正做業務測試，甚至連一張業務流程圖都沒有，無法保證業務不出問題。業務流程圖就是一個業務層次的控制流，還有業務的數據流。以前做功能測試的時候，更多地是做了數據測試，但可能業務數據複雜，並沒有完整地依據數據流圖做驗證，只是驗證了數據的模塊或者功能的數據，並沒有真正驗證整個業務數據流。所以業務決策、業務流程、業務規則、業務操作、業務數據，甚至業務將來的可持續發展，包括它的安全性，都需要驗證。
除了業務、用戶角色、用戶行爲、事件、條件、場景、數據、運行環境，當今更多用微服務架構還有云平臺，還有配置參數組合都需要考慮測試。
質量和效率的統一
當公司是做敏捷開發，擁有專職的測試工程師時，上述“質效合一模型”是值得大家思考和引用的。當開發做新功能的時候，針對新功能做設計、寫代碼，開發自動化測試比較困難，無法調試腳本，被測對象也不穩定，即使能調效率也是比較低的。所以從這個角度來講，新功能最好用探索式測試去做，因爲不用寫測試用例，把省下了寫測試用例的時間，來寫上一個迭代的、已經通過評審/驗證的、穩定的功能，並針對上一個版本的功能做自動化測試。在這樣的情況下你才能更好地保證質量，又能提高效率，因爲所有的迴歸測試是自動化的，新功能相對是未知的，用探索式測試發揮人的潛力與智慧，就更好地做到質量和效率的統一。
雖然現在都在提倡自動化測試，上面這張圖的數據反映了自動化測試的國際水平，但是工信部五所（賽寶）做的國內自動化測試現狀調查結果比這個要差很多。這裏，自動化測試做得好的只有32%左右，真正做到90%以上的只有4%。還有19%做得還可以，自動化比重超過了50%。可以看出，大多數的自動化測試實際做得不夠好。
AI提高測試效率
早期是手工測試，然後到自動化測試，到後面用健壯的TA工具與開源框架集成，得到大家的歡迎和廣泛的應用。
現在行業在推雲計算、大數據，希望公司可以構建一個代碼庫，把所有的代碼都放在一起，這樣可以更好地複用或者學習。公司也在雲化自己的開發環境和測試環境，這樣纔能有更多的數據積累下來，可以實現更好的機器學習。當前基於雲計算平臺和大數據，基於生態鏈工具，可以更好地去完成自動化測試，更具有彈性。未來測試基於新的微服務架構或者其他架構，真正做到智慧、自主。在架構方面甚至在需求工程方面，正在研究這種自主的系統，算法不變可以自主擴展、動態成長。
未來人更多地是做分析、做設計、建模、訓練模型。所有的執行應該交給工具去做的。而且在今天是有這個條件，有大量的數據，許多算法也都是成熟的。Google提供了TensorFlow（TF）或其他的一些平臺，但這些是脫離業務的。針對自己的業務，需要大量的分析來構建對應的模型。另外人機交互智能更有價值，不能完全靠機器， Google搞AlphaGo，先是AlphaGo做出來才了有AlphaZero，還是要有一個過程。人工智能或者機器人，或者未來的測試機器人是需要人去訓練的。就相當於把測試工程師的經驗和知識，對業務流程和業務場景的理解賦能給機器人。讓工具與用戶見面，跟業務有更強的綁定。現在人類可以給工具做按鈕、菜單、文字、圖標的識別訓練，但它還不能真正的認知業務流程。東南大學、復旦大學正在研究知識圖譜，在特定的業務領域可以幫助計算機去提高認知。
一般來講，人工智能有計算智能、感知智能、認知智能，現在計算智能和感知智能已經相對比較成熟，但認知智能比較弱，要讓人工智能真正去理解人類業務還是比較困難的。需要人類構建業務流程或者知識圖譜，讓機器去理解、學習。
人工智能需要靠很大的人力，沒有大量的數據標識，機器是不會去識別或者做預測的。所以有時候講在某些落後地區，非一、二線城市會有大量的人相當於民工一樣在做數據標識，這個過程就會比較慢。
人工智能的算法不一定要有數據標識，監督學習需要標識數據，還有無監督學習、強化學習。目前無監督的學習更受歡迎，有更好地應用和發展。
從單元測試擴展到系統測試，文字識別變成圖像識別來處理。不管是汽車電子還有其他的領域，可以把有限狀態機或者是基於模型測試跟人工智能測試結合起來，測試效果會更好一些。在移動應用這方面的計算能力比較弱一些，可以用多個機器人去模擬用戶的操作。在遊戲行業，騰訊、華爲、網易等公司在測試上應用AI能力方面有了良好應用成果，與高清攝像頭結合，可以做到更多的場景識別、人工智能輔助決策，實時遊戲控制等。（具體見演講PPT）
AI技術助力於測試覆蓋率
AI技術助力於測試覆蓋率，可以藉助AI提高功能測試覆蓋率、源碼測試覆蓋率、迴歸測試覆蓋率、系統非功能性測試覆蓋率等。同時，也可以藉助關鍵字引導的搜索策略以提高測試覆蓋率。
迴歸測試利用AI，選擇40%測試用例集可以達到80%的測試覆蓋率。通過針對關鍵字索引提高測試覆蓋率。例如：Eggplant AI導入已有測試資產創建模型、使用智能算法選擇最佳測試集運行測試，基於模型算法能最大程度減少構建與維護的成本。Eggplant AI的測試覆蓋率與以前相比，有很大提高，達到80%-90%。
通過遺傳算法和對源碼“編譯時插樁”的方式自動生成測試用例，以探索二進制程序內部新的執行路徑，而且能夠不斷優化執行路徑，從而獲得高效的模糊測試策略。這樣可以大大提高源碼測試覆蓋率。
使用NLP進行E2E Web測試依賴項檢測驗證所有依賴關係，並使用一個新的恢復算法來確保在最終的測試依賴關係，提高迴歸測試覆蓋率。
Peach Fuzzer模糊測試工具通過代理和狀態機感知狀態，實時調整變異策略，從而發現應用程序中更多的安全性漏洞，可以提高系統非功能性測試覆蓋率。
朱少民老師認爲未來的AI理想狀態有兩種，第一種是結合MBT與AI合力相助測試。第二種是探索式測試（ET）與AI結合， AI智能生成代碼，ET給AI喂數據、加速AI模型的訓練。（具體見演講PPT）
如要下載PPT，關注《軟件質量報道》公衆號，輸入“質效合一”獲取。
其它參考：