測試工程師不懂AI，還有未來嗎？
近幾年人工智能、機(jī)器學(xué)習(xí)等詞漫天遍地，似乎有一種無AI，無研發(fā)，無AI，無測試的感覺。有人說：不帶上“智能”二字，都不好意思說自己是創(chuàng)新。我們先暫且不評論對錯，只探討這背后值得我們思考的問題。
在測試領(lǐng)域，人工智能和測試是什么關(guān)系?為什么測試領(lǐng)域會談及人工智能?如果測試工程師不懂AI，是否有未來，測試人員該如何看待“AI測試”?在軟件質(zhì)量保障中到底應(yīng)該如何循序漸進(jìn)的切入這一話題?業(yè)界在此領(lǐng)域目前現(xiàn)狀是怎樣?帶著這些問題，阿里高級測試開發(fā)專家汪維希望借此和大家做一些交流和探討。
測試發(fā)展變革史
借用一幅圖先讓我們快速來回溯一下測試變革所經(jīng)歷的幾個不同的時期，從最早期的純手工測試，隨著整個IT技術(shù)的發(fā)展，測試也歷經(jīng)了不少的變革，每一次變革我們不難發(fā)現(xiàn)側(cè)重點(diǎn)都有所不同。
從最初的驗證軟件的可工作狀態(tài)，到強(qiáng)調(diào)釋放生產(chǎn)力的自動化訴求，從封閉式的自動化能力到基于社區(qū)模式的開放式能力建設(shè)，再到從更加全面的研發(fā)流程體系來構(gòu)建的持續(xù)集成的自動化能力，我們不難發(fā)現(xiàn)每次變革背后似乎都有一個核心詞在推動，那就是“效率”。但這個效率又有所不同，就是不同階段對于效率在逐漸從單點(diǎn)效率往系統(tǒng)性效率邁進(jìn)。
如果我們認(rèn)為前邊四個階段都是基于規(guī)則為核心的測試，而未來則會打破這種模式，推動這個核心改變的模式可能主要來源兩個方面，第一是研發(fā)技術(shù)的升級，第二是研發(fā)模式的更加敏捷和分布式開發(fā)，這兩者都打破了以規(guī)則為核心的測試?yán)砟睢?/p>
因為我們可能面對更多的研發(fā)人員，更復(fù)雜的研發(fā)場景，更復(fù)雜多變的應(yīng)用系統(tǒng)，在此基礎(chǔ)上便催生了對于軟件測試新的思考，那便是如何讓軟件測試變得更加的“Smart”，這便是我們正在經(jīng)歷的時代，不過很不幸的是，我們可能大多數(shù)情況下測試還不夠“Smart”，很有可能我們在某些情況下我們還處于“1980-1990”的時代，我想這也是測試人員之痛。
?? 
圖片來源：https://becominghuman.ai/ai-in-testing-the-third-wave-of-automation-cfdd43f55d9c
如今測試發(fā)展面臨的主要挑戰(zhàn)
對于軟件測試而言，其實(shí)互聯(lián)網(wǎng)的發(fā)展和興起對軟件測試的發(fā)展帶來了巨大的挑戰(zhàn)，這不得不從本質(zhì)問題說起，相對互聯(lián)網(wǎng)時代之前的傳統(tǒng)IT時代，軟件通常研發(fā)周期較長，軟件功能龐大，軟件更新頻率較低，軟件是作為支撐企業(yè)業(yè)務(wù)發(fā)展的配套設(shè)施，之所以叫配套設(shè)施，也就是對于企業(yè)而言及時沒有這個配套設(shè)施，業(yè)務(wù)發(fā)展依然可以進(jìn)行，無非是管理效率可能會受到一些影響，而互聯(lián)網(wǎng)時代，其本質(zhì)上軟件本身就是企業(yè)的商業(yè)模式的核心能力，不再僅僅是一個配套設(shè)施，而是核心設(shè)施，核心能力，其直接決定了在復(fù)雜多變的商業(yè)環(huán)境中是否具備核心競爭力。
因此對于軟件無論是在研發(fā)模式、交付模式上都提出了更高、更快的要求，“敏捷”研發(fā)思想和模式應(yīng)運(yùn)而生，敏捷的本質(zhì)是為了獲得更快的Go To Market的能力，從而讓企業(yè)能獲得更快的商機(jī)，在敏捷模式下，本身是一種好事，這種模式下需要軟件更快的交付能力，而不是等著專業(yè)的軟件測試人員慢吞吞的進(jìn)行功能驗證。
如果不是等著專業(yè)的軟件測試人員進(jìn)行測試，那還能誰來參與測試?開發(fā)人員?但是開發(fā)人員測試自己的軟件還并沒有成為主流，大多數(shù)開發(fā)人員不會寫測試來測試自己的代碼，他們選擇手工測試或者等待專業(yè)的測試人員來測試他們的軟件，從而保證軟件可正確運(yùn)行。
這正是測試面臨的挑戰(zhàn)，如何能讓研發(fā)能參與測試?很不幸的是，目前AI在此領(lǐng)域還不能幫助太多，但也并非完全不能做什么，在理解這個問題之前，我覺得有一個很好的問題，就是我們不妨來思考一下自動化測試的6個層次與人工智能的關(guān)系。
人工智能測試的六個層次
什么是自動化測試的6個層次?這6個層次是我目前看到的對于AI和自動化測試相對清晰的一個抽象，先簡單介紹一下這6個層次的來源，這是由Applitools 的高級架構(gòu)師 Gil Tayar在 Craft Conference 2018上介紹他們?nèi)绾螌?AI 技術(shù)應(yīng)用到自動化測試的內(nèi)容中提到的6個層次，分別為：
層次一
完全沒有自動，你需要自己寫測試!
層次二
駕駛輔助——AI 可以查看到頁面，幫助你寫出斷言。你還是要自己寫“驅(qū)動”應(yīng)用程序的代碼，但是 AI 可以檢查頁面，并確保頁面中的期望值是正確的。在這種模式下，軟件測試工程師需要自己用傳統(tǒng)技術(shù)解決流程驅(qū)動的問題，但無需在腳本中做Expectation的校驗或者無需用腳本方式寫Check Point，而把校驗的工作交由AI來完成，AI技術(shù)在此過程中核心起到輔助的作用。
層次三
部分自動化——雖然能分辨實(shí)際頁面和期望值的區(qū)別這一點(diǎn)已經(jīng)很好了，但是第二層次的 AI 需要有更深層的理解。比如說，如果所有頁面都有相同的變更，AI 需要認(rèn)識到這是相同的頁面，并向我們展示出這些變更。
進(jìn)一步來說，AI 需要查看頁面的布局和內(nèi)容，將每個變更分類為內(nèi)容變更或是布局變更。如果我們要測試響應(yīng)式 web 網(wǎng)站，這會非常有幫助，即使布局有細(xì)微變更，內(nèi)容也應(yīng)該是相同的。這是 Applitools Eyes 這樣的工具所處的層次。在這種模式下，AI逐漸具備了貫穿上下文的能力，如果相對層次二而言，層次二停留在”點(diǎn)“上，層次三模式下的AI已經(jīng)具備了”線“的輔助能力。
層次四
條件自動化——在第三層，軟件中檢測的問題和變更仍然需要人來審查。第三層的 AI 可以幫助我們分析變更，但不能僅僅通過查看頁面判斷頁面是否正確，需要和期望值進(jìn)行對比才能判斷。但是第四層的 AI 可以做到這一方面，甚至更多其他方面，因為它會使用到機(jī)器學(xué)習(xí)的技術(shù)。
比如說，第四層的 AI 可以從可視化角度查看頁面，根據(jù)標(biāo)準(zhǔn)設(shè)計規(guī)則，例如對齊、空格、顏色和字體使用以及布局規(guī)則，判斷設(shè)計是否過關(guān)。AI 也能查看頁面的內(nèi)容，基于相同頁面之前的視圖，在沒有人工干預(yù)的情況下，判斷內(nèi)容是否合理。在這種模式下，AI逐漸具備了自我學(xué)習(xí)的能力，能從”面“上進(jìn)行輔助自動化，但這實(shí)現(xiàn)起來非常的困難，目前相對不夠成熟。
層次五
高度自動化——直到現(xiàn)在，所有 AI 都只是在自動化地進(jìn)行檢查。盡管使用自動化軟件，還是需要手動啟動測試，需要點(diǎn)擊鏈接，而第五層的 AI 可以自動啟動測試本身。AI 將通過觀察啟動應(yīng)用程序的真實(shí)用戶的行為，理解如何自己啟動測試。這層的 AI 可以編寫測試，可以通過檢查點(diǎn)來測試頁面。
但這不是終點(diǎn)，它還需觀察人的行為，偶爾需要聽從測試人員的指令。在這種模式下，相對前邊的幾種層次，這個層次的AI已經(jīng)擺脫了人工”驅(qū)動“的模式，核心改變就是從人工”驅(qū)動“發(fā)展為”AI“驅(qū)動，如果說前邊幾種模式還需要測試人員編寫流程驅(qū)動腳本，而在這種模式下，測試人員將擺脫這一束縛。
層次六
完全自動化——我必須承認(rèn)，這個層次有點(diǎn)恐怖。這個層次的 AI 可以和產(chǎn)品經(jīng)理“交流”，理解產(chǎn)品的標(biāo)準(zhǔn)，自己寫測試，不需要人的幫助。這種模式可能是我們所希望追求的最高境界，或許發(fā)展到這個階段，測試這個崗位需要重新被定義。
?? 
運(yùn)用場景
AI技術(shù)在測試領(lǐng)域的運(yùn)用并非新鮮話題，但業(yè)界對此討論的一些方向也值得我們思考和探索AI和ML(機(jī)器學(xué)習(xí))技術(shù)能如何被運(yùn)用到測試場景，常見的三種運(yùn)用場景包括：
Unit Tests
單元測試對于確保每一次Build都能構(gòu)建出穩(wěn)定和具備可測性的軟件非常重要，但單元測試的構(gòu)建和維護(hù)本身也面臨很大的挑戰(zhàn)，在業(yè)界例如像RPA這樣的AI-Powered Unit Test工具，試圖幫助開發(fā)人員來更加有效的維護(hù)單元測試用例，利用AI技術(shù)對代碼進(jìn)行分析和學(xué)習(xí)，從而有效的減少那些無用的用例集，從而維護(hù)一個更加可靠和穩(wěn)定的單元測試用例庫。
API Testing
在敏捷開發(fā)模式下，測試人員會面臨常態(tài)化多變的UI界面，此時針對系統(tǒng)API(接口)的測試其有效性和效率可能會大于UI自動化測試，在此領(lǐng)域有非常多的一些使用AI技術(shù)的工具能幫助測試人員對手工UI測試自動轉(zhuǎn)換為API測試，從而幫助組織更加高效的構(gòu)建起復(fù)雜和完善的API測試策略。
UI Testing
目前對于UI自動化測試主要思想主要還是如何把手工測試用例轉(zhuǎn)換為自動化測試用例，AI技術(shù)在此場景下目前大多被運(yùn)用在結(jié)果識別以及多場景的適配測試領(lǐng)域，從而降低對UI自動化的維護(hù)和運(yùn)行成本。
業(yè)界在AI測試領(lǐng)域的解決方案
針對上述提到的運(yùn)用場景和不同的六個層次，目前業(yè)界在此領(lǐng)域也有非常多的AI Powered Testing Tools，我們可以快速做一個了解(工具排名不分先后)。
Applitools
這是一個運(yùn)用了AI技術(shù)的Visual Testing解決方案，他運(yùn)用AI技術(shù)智能化識別UI界面上那些有價值性的改動，并主動識別其是否是潛在的BUG或者是有意義的改動而并非BUG，從而讓自動化腳本的維護(hù)從規(guī)則化升級為智能化，例如下圖中我們可以看到應(yīng)用的圖標(biāo)位置發(fā)生了改變，該工具能自動識別這種變化，其主要主打方向是軟件測試的Look & Feel領(lǐng)域，或者我們可以叫用戶體驗領(lǐng)域。
用該公司自己的話來說其核心價值如下，從其官方價值不難看出，其主要解決的問題是在軟件UI影響用戶體驗的領(lǐng)域，比如像視窗存在遮擋，界面元素顏色、大小、位置可能存在問題等，這對于一些非常重視用戶對軟件產(chǎn)品體驗方面的領(lǐng)域還是具有一定的價值，而這些領(lǐng)域的測試如果用傳統(tǒng)的基于規(guī)則的自動化，實(shí)現(xiàn)成本和維護(hù)成本會非常巨大。
Appvance IQ
Appvance公司出品的解決方案，官方宣傳口號“The Only True AI-Driven Software Test Automation Technology Create 1000's of regression tests in minutes”，翻譯過來大致的意思是這是一個真正的AI驅(qū)動的自動化測試解決方案技術(shù)，該技術(shù)能在1分鐘內(nèi)瞬間產(chǎn)生1000個左右的回歸測試用例，從官宣口號中不難可以看出，其主打的是“效率”二字，核心希望解決回歸測試的痛點(diǎn)，該公司也提出了一個5層自動化模型，這5層模型和前邊提到的6層模型其實(shí)有異曲同工之處。
Eggplant
該工具獲得2019 SIIA CODiE WINNNER(Best DevOps Tool Digital Automation Intelligence Suite)，該工具的Eggplant AI功能號稱能自動創(chuàng)建Test Case，并優(yōu)化測試執(zhí)行來發(fā)現(xiàn)更多的BUG，其提出的測試覆蓋率思想提出了一個“User Journeys”的思想相對有些有趣，官方有這么一段介紹“Eggplant AI automatically generates test cases and optimizes test execution to find defects and maximize coverage of user journeys”，其實(shí)這里的Customer Journey也即是我們常常說的不同的測試場景，為了達(dá)到對于Customer Journey的覆蓋，其核心實(shí)現(xiàn)邏輯抽取出了Model和Tag的概念，前者是Journey建模，后者實(shí)際是數(shù)據(jù)驅(qū)動。
?? 
Customer Journey圖片來源：http://docs.testplant.com/
?? 
Journey建模
圖片來源：http://docs.testplant.com/
Test.AI
這是業(yè)界比較知名的兩本書籍(《How Google Tests Software》、《App Quality: Secrets for Agile App Teams》)編寫團(tuán)隊所創(chuàng)建的一個AI自動化測試平臺，其核心能力是將AI大腦添加到Selenium和Appium的工具來提升其智能化能力。
MABL
一幫前Google工程師創(chuàng)辦的企業(yè)，主攻領(lǐng)域就是提供End-To-End的端到端測試解決方案，AI也是其中很重要的方向，MABL具備自動檢測測試對象的變化并動態(tài)更新測試腳本的能力。在傳統(tǒng)的自動化測試中，可能UI界面的類型變化可能會阻塞腳本執(zhí)行，而MABL具備自動識別的機(jī)制和能力來緩解這類問題。
Sealights
從官方的宣傳口號來看，不難看出，其核心定位是利用AI技術(shù)做質(zhì)量管理和質(zhì)量分析和其他幾個的定位略有不同，主要用戶主要針對R&D Manager，所以我們可以理解為其核心解決的不是測試自身的問題，而是偏管理方面的問題，利用智能化技術(shù)針對此領(lǐng)域希望能更加智能的給予決策人員更加準(zhǔn)確的決策信息，提高決策效率。
?? 
Sealights圖片來源：https://www.sealights.io/
?? 
Sealights質(zhì)量趨勢智能分析圖片來源：https://www.sealights.io/
ReportPortal
從名字上不難看出，這款工具主要是聚焦在測試結(jié)果分析和管理方面，這一點(diǎn)和Sealights有些類似，主要基于測試執(zhí)行的數(shù)據(jù)利用AI和ML技術(shù)進(jìn)行挖掘，來快速評估新的風(fēng)險。
?? 
ReportPortal產(chǎn)品圖片來源：https://reportportal.io/
Functionlize
該解決方案主打AI自動化領(lǐng)域，其核心能力是其所為的AEA(Adaptive Event Analysis)技術(shù)，該技術(shù)能自動發(fā)現(xiàn)case執(zhí)行過程中的Broken問題，并自動修復(fù)，從而讓你的用例Never Break And NO More Test Maintenance，其利用ML技術(shù)的智能識別號稱覆蓋以下一些UI場景，如果在你的測試中有涉及下邊這些的Change，利用AEA技術(shù)可以自動識別更自動更新測試腳本，無需人工干預(yù)：
- Size of Element
- Locaiton on Page
- Previous sizes and locations
- Visual configurations
- Xpaths
- CSS Selectors
- Parent and child elements
- Visibility
?? 
除了上述提到的這些目前業(yè)界已有的解決方案以外，還有很多廠商也在自己現(xiàn)有的工具能力中注入了AI和ML的能力，不過從上述幾個中我們不難發(fā)現(xiàn)，目前業(yè)界在測試領(lǐng)域使用AI和ML技術(shù)大致可以分為幾類：
利用Computer Vision(計算機(jī)視覺)技術(shù)對測試結(jié)果進(jìn)行輔助檢測，對于檢測的結(jié)果要么用于結(jié)果判斷，要么用于更新腳本。
利用Natural Language Porcessing(自然語言處理)技術(shù)對測試對象進(jìn)行分析，或者對測試數(shù)據(jù)進(jìn)行分析，從而進(jìn)行測試決策輔助和腳本優(yōu)化。
利用ML(機(jī)器學(xué)習(xí))技術(shù)或者深度學(xué)習(xí)技術(shù)，對采用CV和NLP技術(shù)所獲得的數(shù)據(jù)進(jìn)行深度加工，從而來解決自動化腳本Break，或者快速創(chuàng)建大量自動化腳本的目的。
小結(jié)
在我看來AI技術(shù)的發(fā)展應(yīng)該是測試人員需要重點(diǎn)關(guān)注的領(lǐng)域，我們往往會因為有些技術(shù)可能當(dāng)下并不成熟，或者當(dāng)下并沒有很好的落地場景，從而忽略對未來技術(shù)的關(guān)注度，在測試領(lǐng)域?qū)τ贏I的探索也是如此，同時不難發(fā)現(xiàn)在業(yè)界其實(shí)已經(jīng)有非常多的公司已經(jīng)在自己的商業(yè)化解決方案中注入了AI能力，這種趨勢也是值得我們持續(xù)關(guān)注，最后我個人比較推薦在AI領(lǐng)域的落地和時間可以嘗試從本文提到的6個層次模型中去由淺入深的探索，這有利于在AI和測試的道路上有層次的循序漸進(jìn)。
【本文為51CTO專欄作者“阿里巴巴官方技術(shù)”原創(chuàng)稿件，轉(zhuǎn)載請聯(lián)系原作者】
