人工智能测试是什么意思_测试工程师必须懂这些
阿里妹導(dǎo)讀:近幾年人工智能、機(jī)器學(xué)習(xí)等詞漫天遍地,似乎有一種無AI,無研發(fā),無AI,無測試的感覺。有人說:不帶上“智能”二字,都不好意思說自己是創(chuàng)新。我們先暫且不評論對錯,只探討這背后值得我們思考的問題。
在測試領(lǐng)域,人工智能和測試是什么關(guān)系?為什么測試領(lǐng)域會談及人工智能?如果測試工程師不懂AI,是否有未來,測試人員該如何看待“AI測試”?帶著這些問題,阿里高級測試開發(fā)專家汪維希望借此和大家做一些交流和探討。
測試發(fā)展變革史
借用一幅圖先讓我們快速來回溯一下測試變革所經(jīng)歷的幾個不同的時期,從最早期的純手工測試,隨著整個IT技術(shù)的發(fā)展,測試也歷經(jīng)了不少的變革,每一次變革我們不難發(fā)現(xiàn)側(cè)重點都有所不同。
從最初的驗證軟件的可工作狀態(tài),到強(qiáng)調(diào)釋放生產(chǎn)力的自動化訴求,從封閉式的自動化能力到基于社區(qū)模式的開放式能力建設(shè),再到從更加全面的研發(fā)流程體系來構(gòu)建的持續(xù)集成的自動化能力,我們不難發(fā)現(xià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)
對于軟件測試而言,其實互聯(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)運而生,敏捷的本質(zhì)是為了獲得更快的Go To Market的能力,從而讓企業(yè)能獲得更快的商機(jī),在敏捷模式下,本身是一種好事,這種模式下需要軟件更快的交付能力,而不是等著專業(yè)的軟件測試人員慢吞吞的進(jìn)行功能驗證。
如果不是等著專業(yè)的軟件測試人員進(jìn)行測試,那還能誰來參與測試?開發(fā)人員?但是開發(fā)人員測試自己的軟件還并沒有成為主流,大多數(shù)開發(fā)人員不會寫測試來測試自己的代碼,他們選擇手工測試或者等待專業(yè)的測試人員來測試他們的軟件,從而保證軟件可正確運行。
這正是測試面臨的挑戰(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ù)在此過程中核心起到輔助的作用。
層次三:部分自動化——雖然能分辨實際頁面和期望值的區(qū)別這一點已經(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逐漸具備了貫穿上下文的能力,如果相對層次二而言,層次二停留在”點“上,層次三模式下的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)行輔助自動化,但這實現(xiàn)起來非常的困難,目前相對不夠成熟。
層次五:高度自動化——直到現(xiàn)在,所有 AI 都只是在自動化地進(jìn)行檢查。盡管使用自動化軟件,還是需要手動啟動測試,需要點擊鏈接,而第五層的 AI 可以自動啟動測試本身。AI 將通過觀察啟動應(yīng)用程序的真實用戶的行為,理解如何自己啟動測試。這層的 AI 可以編寫測試,可以通過檢查點來測試頁面。
但這不是終點,它還需觀察人的行為,偶爾需要聽從測試人員的指令。在這種模式下,相對前邊的幾種層次,這個層次的AI已經(jīng)擺脫了人工”驅(qū)動“的模式,核心改變就是從人工”驅(qū)動“發(fā)展為”AI“驅(qū)動,如果說前邊幾種模式還需要測試人員編寫流程驅(qū)動腳本,而在這種模式下,測試人員將擺脫這一束縛。
層次六:完全自動化——我必須承認(rèn),這個層次有點恐怖。這個層次的 AI 可以和產(chǎn)品經(jīng)理“交流”,理解產(chǎn)品的標(biāo)準(zhǔn),自己寫測試,不需要人的幫助。這種模式可能是我們所希望追求的最高境界,或許發(fā)展到這個階段,測試這個崗位需要重新被定義。
小結(jié)
在我看來AI技術(shù)的發(fā)展應(yīng)該是測試人員需要重點關(guān)注的領(lǐng)域,我們往往會因為有些技術(shù)可能當(dāng)下并不成熟,或者當(dāng)下并沒有很好的落地場景,從而忽略對未來技術(shù)的關(guān)注度,在測試領(lǐng)域?qū)τ贏I的探索也是如此,同時不難發(fā)現(xiàn)在業(yè)界其實已經(jīng)有非常多的公司已經(jīng)在自己的商業(yè)化解決方案中注入了AI能力,這種趨勢也是值得我們持續(xù)關(guān)注,最后我個人比較推薦在AI領(lǐng)域的落地和時間可以嘗試從本文提到的6個層次模型中去由淺入深的探索,這有利于在AI和測試的道路上有層次的循序漸進(jìn)。
總結(jié)
以上是生活随笔為你收集整理的人工智能测试是什么意思_测试工程师必须懂这些的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 1.5吨左右的电搬叉车,既要坚固耐用又要
- 下一篇: netcore redis 存储集合_.