阿里妹導讀:近幾年人工智能、機器學習等詞漫天遍地,彷佛有一種無AI,無研發,無AI,無測試的感受。有人說:不帶上「智能」二字,都很差意思說本身是創新。咱們先暫且不評論對錯,只探討這背後值得咱們思考的問題。
在測試領域,人工智能和測試是什麼關係?爲何測試領域會談及人工智能?若是測試工程師不懂AI,是否有將來,測試人員該如何看待「AI測試」?在軟件質量保障中到底應該如何按部就班的切入這一話題?業界在此領域目前現狀是怎樣?帶着這些問題,阿里高級測試開發專家汪維但願藉此和你們作一些交流和探討。git
借用一幅圖先讓咱們快速來回溯一下測試變革所經歷的幾個不一樣的時期,從最先期的純手工測試,隨着整個IT技術的發展,測試也歷經了很多的變革,每一次變革咱們不難發現側重點都有所不一樣。web
從最初的驗證軟件的可工做狀態,到強調釋放生產力的自動化訴求,從封閉式的自動化能力到基於社區模式的開放式能力建設,再到從更加全面的研發流程體系來構建的持續集成的自動化能力,咱們不難發現每次變革背後彷佛都有一個核心詞在推進,那就是「效率」。但這個效率又有所不一樣,就是不一樣階段對於效率在逐漸從單點效率往系統性效率邁進。服務器
若是咱們認爲前邊四個階段都是基於規則爲核心的測試,而將來則會打破這種模式,推進這個核心改變的模式可能主要來源兩個方面,第一是研發技術的升級,第二是研發模式的更加敏捷和分佈式開發,這二者都打破了以規則爲核心的測試理念。架構
由於咱們可能面對更多的研發人員,更復雜的研發場景,更復雜多變的應用系統,在此基礎上便催生了對於軟件測試新的思考,那即是如何讓軟件測試變得更加的「Smart」,這即是咱們正在經歷的時代,不過很不幸的是,咱們可能大多數狀況下測試還不夠「Smart」,頗有可能咱們在某些狀況下咱們還處於「1980-1990」的時代,我想這也是測試人員之痛。機器學習
對於軟件測試而言,其實互聯網的發展和興起對軟件測試的發展帶來了巨大的挑戰,這不得不從本質問題提及,相對互聯網時代以前的傳統IT時代,軟件一般研發週期較長,軟件功能龐大,軟件更新頻率較低,軟件是做爲支撐企業業務發展的配套設施,之因此叫配套設施,也就是對於企業而言及時沒有這個配套設施,業務發展依然能夠進行,無非是管理效率可能會受到一些影響,而互聯網時代,其本質上軟件自己就是企業的商業模式的核心能力,再也不僅僅是一個配套設施,而是核心設施,核心能力,其直接決定了在複雜多變的商業環境中是否具有核心競爭力。分佈式
所以對於軟件不管是在研發模式、交付模式上都提出了更高、更快的要求,「敏捷」研發思想和模式應運而生,敏捷的本質是爲了得到更快的Go To Market的能力,從而讓企業能得到更快的商機,在敏捷模式下,自己是一種好事,這種模式下須要軟件更快的交付能力,而不是等着專業的軟件測試人員慢吞吞的進行功能驗證。工具
若是不是等着專業的軟件測試人員進行測試,那還能誰來參與測試?開發人員?可是開發人員測試本身的軟件還並無成爲主流,大多數開發人員不會寫測試來測試本身的代碼,他們選擇手工測試或者等待專業的測試人員來測試他們的軟件,從而保證軟件可正確運行。佈局
這正是測試面臨的挑戰,如何能讓研發能參與測試?很不幸的是,目前AI在此領域還不能幫助太多,但也並不是徹底不能作什麼,在理解這個問題以前,我以爲有一個很好的問題,就是咱們不妨來思考一下自動化測試的6個層次與人工智能的關係。單元測試
什麼是自動化測試的6個層次?這6個層次是我目前看到的對於AI和自動化測試相對清晰的一個抽象,先簡單介紹一下這6個層次的來源,這是由Applitools 的高級架構師 Gil Tayar在 Craft Conference 2018上介紹他們如何將 AI 技術應用到自動化測試的內容中提到的6個層次,分別爲:學習
層次一
徹底沒有自動,你須要本身寫測試!
層次二
駕駛輔助——AI 能夠查看到頁面,幫助你寫出斷言。你仍是要本身寫「驅動」應用程序的代碼,可是 AI 能夠檢查頁面,並確保頁面中的指望值是正確的。在這種模式下,軟件測試工程師須要本身用傳統技術解決流程驅動的問題,但無需在腳本中作Expectation的校驗或者無需用腳本方式寫Check Point,而把校驗的工做交由AI來完成,AI技術在此過程當中核心起到輔助的做用。
層次三
部分自動化——雖然能分辨實際頁面和指望值的區別這一點已經很好了,可是第二層次的 AI 須要有更深層的理解。好比說,若是全部頁面都有相同的變動,AI 須要認識到這是相同的頁面,並向咱們展現出這些變動。
進一步來講,AI 須要查看頁面的佈局和內容,將每一個變動分類爲內容變動或是佈局變動。若是咱們要測試響應式 web 網站,這會很是有幫助,即便佈局有細微變動,內容也應該是相同的。這是 Applitools Eyes 這樣的工具所處的層次。在這種模式下,AI逐漸具有了貫穿上下文的能力,若是相對層次二而言,層次二停留在」點「上,層次三模式下的AI已經具有了」線「的輔助能力。
層次四
條件自動化——在第三層,軟件中檢測的問題和變動仍然須要人來審查。第三層的 AI 能夠幫助咱們分析變動,但不能僅僅經過查看頁面判斷頁面是否正確,須要和指望值進行對比才能判斷。可是第四層的 AI 能夠作到這一方面,甚至更多其餘方面,由於它會使用到機器學習的技術。
好比說,第四層的 AI 能夠從可視化角度查看頁面,根據標準設計規則,例如對齊、空格、顏色和字體使用以及佈局規則,判斷設計是否過關。AI 也能查看頁面的內容,基於相同頁面以前的視圖,在沒有人工干預的狀況下,判斷內容是否合理。在這種模式下,AI逐漸具有了自我學習的能力,能從」面「上進行輔助自動化,但這實現起來很是的困難,目前相對不夠成熟。
層次五
高度自動化——直到如今,全部 AI 都只是在自動化地進行檢查。儘管使用自動化軟件,仍是須要手動啓動測試,須要點擊連接,而第五層的 AI 能夠自動啓動測試自己。AI 將經過觀察啓動應用程序的真實用戶的行爲,理解如何本身啓動測試。這層的 AI 能夠編寫測試,能夠經過檢查點來測試頁面。
但這不是終點,它還需觀察人的行爲,偶爾須要遵從測試人員的指令。在這種模式下,相對前邊的幾種層次,這個層次的AI已經擺脫了人工」驅動「的模式,核心改變就是從人工」驅動「發展爲」AI「驅動,若是說前邊幾種模式還須要測試人員編寫流程驅動腳本,而在這種模式下,測試人員將擺脫這一束縛。
層次六
徹底自動化——我必須認可,這個層次有點恐怖。這個層次的 AI 能夠和產品經理「交流」,理解產品的標準,本身寫測試,不須要人的幫助。這種模式多是咱們所但願追求的最高境界,或許發展到這個階段,測試這個崗位須要從新被定義。
AI技術在測試領域的運用並不是新鮮話題,但業界對此討論的一些方向也值得咱們思考和探索AI和ML(機器學習)技術能如何被運用到測試場景,常見的三種運用場景包括:
Unit Tests
單元測試對於確保每一次Build都能構建出穩定和具有可測性的軟件很是重要,但單元測試的構建和維護自己也面臨很大的挑戰,在業界例如像RPA這樣的AI-Powered Unit Test工具,試圖幫助開發人員來更加有效的維護單元測試用例,利用AI技術對代碼進行分析和學習,從而有效的減小那些無用的用例集,從而維護一個更加可靠和穩定的單元測試用例庫。
API Testing
在敏捷開發模式下,測試人員會面臨常態化多變的UI界面,此時針對系統API(接口)的測試其有效性和效率可能會大於UI自動化測試,在此領域有很是多的一些使用AI技術的工具能幫助測試人員對手工UI測試自動轉換爲API測試,從而幫助組織更加高效的構建起復雜和完善的API測試策略。
UI Testing
目前對於UI自動化測試主要思想主要仍是如何把手工測試用例轉換爲自動化測試用例,AI技術在此場景下目前大多被運用在結果識別以及多場景的適配測試領域,從而下降對UI自動化的維護和運行成本。
針對上述提到的運用場景和不一樣的六個層次,目前業界在此領域也有很是多的AI Powered Testing Tools,咱們能夠快速作一個瞭解(工具排名不分前後)。
Applitools
這是一個運用了AI技術的Visual Testing解決方案,他運用AI技術智能化識別UI界面上那些有價值性的改動,並主動識別其是不是潛在的BUG或者是有意義的改動而並不是BUG,從而讓自動化腳本的維護從規則化升級爲智能化,例以下圖中咱們能夠看到應用的圖標位置發生了改變,該工具能自動識別這種變化,其主要主打方向是軟件測試的Look & Feel領域,或者咱們能夠叫用戶體驗領域。
用該公司本身的話來講其核心價值以下,從其官方價值不難看出,其主要解決的問題是在軟件UI影響用戶體驗的領域,好比像視窗存在遮擋,界面元素顏色、大小、位置可能存在問題等,這對於一些很是重視用戶對軟件產品體驗方面的領域仍是具備必定的價值,而這些領域的測試若是用傳統的基於規則的自動化,實現成本和維護成本會很是巨大。
Appvance IQ
Appvance公司出品的解決方案,官方宣傳口號「The Only True AI-Driven Software Test Automation Technology Create 1000's of regression tests in minutes」,翻譯過來大體的意思是這是一個真正的AI驅動的自動化測試解決方案技術,該技術能在1分鐘內瞬間產生1000個左右的迴歸測試用例,從官宣口號中不難能夠看出,其主打的是「效率」二字,核心但願解決迴歸測試的痛點,該公司也提出了一個5層自動化模型,這5層模型和前邊提到的6層模型其實有殊途同歸之處。
Eggplant
該工具得到2019 SIIA CODiE WINNNER(Best DevOps Tool Digital Automation Intelligence Suite),該工具的Eggplant AI功能號稱能自動建立Test Case,並優化測試執行來發現更多的BUG,其提出的測試覆蓋率思想提出了一個「User Journeys」的思想相對有些有趣,官方有這麼一段介紹「Eggplant AI automatically generates test cases and optimizes test execution to find defects and maximize coverage of user journeys」,其實這裏的Customer Journey也便是咱們經常說的不一樣的測試場景,爲了達到對於Customer Journey的覆蓋,其核心實現邏輯抽取出了Model和Tag的概念,前者是Journey建模,後者實際是數據驅動。
Test.AI
這是業界比較知名的兩本書籍(《How Google Tests Software》、《App Quality: Secrets for Agile App Teams》)編寫團隊所建立的一個AI自動化測試平臺,其核心能力是將AI大腦添加到Selenium和Appium的工具來提高其智能化能力。
MABL
一幫前Google工程師創辦的企業,主攻領域就是提供End-To-End的端到端測試解決方案,AI也是其中很重要的方向,MABL具有自動檢測測試對象的變化並動態更新測試腳本的能力。在傳統的自動化測試中,可能UI界面的類型變化可能會阻塞腳本執行,而MABL具有自動識別的機制和能力來緩解這類問題。
Sealights
從官方的宣傳口號來看,不難看出,其核心定位是利用AI技術作質量管理和質量分析和其餘幾個的定位略有不一樣,主要用戶主要針對R&D Manager,因此咱們能夠理解爲其核心解決的不是測試自身的問題,而是偏管理方面的問題,利用智能化技術針對此領域但願能更加智能的給予決策人員更加準確的決策信息,提升決策效率。
ReportPortal
從名字上不難看出,這款工具主要是聚焦在測試結果分析和管理方面,這一點和Sealights有些相似,主要基於測試執行的數據利用AI和ML技術進行挖掘,來快速評估新的風險。
Functionlize
該解決方案主打AI自動化領域,其核心能力是其所爲的AEA(Adaptive Event Analysis)技術,該技術能自動發現case執行過程當中的Broken問題,並自動修復,從而讓你的用例Never Break And NO More Test Maintenance,其利用ML技術的智能識別號稱覆蓋如下一些UI場景,若是在你的測試中有涉及下邊這些的Change,利用AEA技術能夠自動識別更自動更新測試腳本,無需人工干預:
除了上述提到的這些目前業界已有的解決方案之外,還有不少廠商也在本身現有的工具能力中注入了AI和ML的能力,不過從上述幾個中咱們不難發現,目前業界在測試領域使用AI和ML技術大體能夠分爲幾類:
在我看來AI技術的發展應該是測試人員須要重點關注的領域,咱們每每會由於有些技術可能當下並不成熟,或者當下並無很好的落地場景,從而忽略對將來技術的關注度,在測試領域對於AI的探索也是如此,同時不難發如今業界其實已經有很是多的公司已經在本身的商業化解決方案中注入了AI能力,這種趨勢也是值得咱們持續關注,最後我我的比較推薦在AI領域的落地和時間能夠嘗試從本文提到的6個層次模型中去由淺入深的探索,這有利於在AI和測試的道路上有層次的按部就班。
雙11福利來了!先來康康#怎麼買雲服務器最便宜# [並不簡單]參團購買指定配置雲服務器僅86元/年,開團拉新享三重禮:1111紅包+瓜分百萬現金+31%返現,爆款必買清單,還有iPhone 11 Pro、衛衣、T恤等你來抽,立刻來試試手氣!https://www.aliyun.com/1111/2019/home?utm_content=g_1000083110
本文做者:汪維
本文來自雲棲社區合做夥伴「阿里技術」,如需轉載請聯繫原做者。