阿裡妹導讀：近幾年人工智能、機器學習等詞漫天遍地，似乎有一種無AI，無研發，無AI，無測試的感覺。有人說：不帶上“智能”二字，都不好意思說自己是創新。我們先暫且不評論對錯，隻探讨這背後值得我們思考的問題。
在測試領域，人工智能和測試是什麼關系？為什麼測試領域會談及人工智能？如果測試工程師不懂AI，是否有未來，測試人員該如何看待“AI測試”？在軟體品質保障中到底應該如何循序漸進的切入這一話題？業界在此領域目前現狀是怎樣？帶着這些問題，阿裡進階測試開發專家汪維希望借此和大家做一些交流和探讨。
測試發展變革史
借用一幅圖先讓我們快速來回溯一下測試變革所經曆的幾個不同的時期，從最早期的純手工測試，随着整個IT技術的發展，測試也曆經了不少的變革，每一次變革我們不難發現側重點都有所不同。
從最初的驗證軟體的可工作狀态，到強調釋放生産力的自動化訴求，從封閉式的自動化能力到基于社群模式的開放式能力建設，再到從更加全面的研發流程體系來建構的持續內建的自動化能力，我們不難發現每次變革背後似乎都有一個核心詞在推動，那就是“效率”。但這個效率又有所不同，就是不同階段對于效率在逐漸從單點效率往系統性效率邁進。
如果我們認為前邊四個階段都是基于規則為核心的測試，而未來則會打破這種模式，推動這個核心改變的模式可能主要來源兩個方面，第一是研發技術的更新，第二是研發模式的更加靈活和分布式開發，這兩者都打破了以規則為核心的測試理念。
因為我們可能面對更多的研發人員，更複雜的研發場景，更複雜多變的應用系統，在此基礎上便催生了對于軟體測試新的思考，那便是如何讓軟體測試變得更加的“Smart”，這便是我們正在經曆的時代，不過很不幸的是，我們可能大多數情況下測試還不夠“Smart”，很有可能我們在某些情況下我們還處于“1980-1990”的時代，我想這也是測試人員之痛。
圖檔來源：
https://becominghuman.ai/ai-in-testing-the-third-wave-of-automation-cfdd43f55d9c如今測試發展面臨的主要挑戰
對于軟體測試而言，其實網際網路的發展和興起對軟體測試的發展帶來了巨大的挑戰，這不得不從本質問題說起，相對網際網路時代之前的傳統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測試領域的解決方案
針對上述提到的運用場景和不同的六個層次，目前業界在此領域也有非常多的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模組化，後者實際是資料驅動。
Customer Journey
http://docs.testplant.com/ 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，是以我們可以了解為其核心解決的不是測試自身的問題，而是偏管理方面的問題，利用智能化技術針對此領域希望能更加智能的給予決策人員更加準确的決策資訊，提高決策效率。
Sealights品質趨勢智能分析
ReportPortal
從名字上不難看出，這款工具主要是聚焦在測試結果分析和管理方面，這一點和Sealights有些類似，主要基于測試執行的資料利用AI和ML技術進行挖掘，來快速評估新的風險。
ReportPortal産品
https://reportportal.io/Functionlize
該解決方案主打AI自動化領域，其核心能力是其所為的AEA（Adaptive Event Analysis）技術，該技術能自動發現case執行過程中的Broken問題，并自動修複，進而讓你的用例Never Break And NO More Test Maintenance，其利用ML技術的智能識别号稱覆寫以下一些UI場景，如果在你的測試中有涉及下邊這些的Change，利用AEA技術可以自動識别更自動更新測試腳本，無需人工幹預：
- Size of Element
- Locaiton on Page
- Previous sizes and locations
- Visual configurations
- Xpaths
- CSS Selectors
- Parent and child elements
- Visibility
除了上述提到的這些目前業界已有的解決方案以外，還有很多廠商也在自己現有的工具能力中注入了AI和ML的能力，不過從上述幾個中我們不難發現，目前業界在測試領域使用AI和ML技術大緻可以分為幾類：
- 利用Computer Vision（計算機視覺）技術對測試結果進行輔助檢測，對于檢測的結果要麼用于結果判斷，要麼用于更新腳本。
- 利用Natural Language Porcessing（自然語言處理）技術對測試對象進行分析，或者對測試資料進行分析，進而進行測試決策輔助和腳本優化。
- 利用ML（機器學習）技術或者深度學習技術，對采用CV和NLP技術所獲得的資料進行深度加工，進而來解決自動化腳本Break，或者快速建立大量自動化腳本的目的。
小結
在我看來AI技術的發展應該是測試人員需要重點關注的領域，我們往往會因為有些技術可能當下并不成熟，或者當下并沒有很好的落地場景，進而忽略對未來技術的關注度，在測試領域對于AI的探索也是如此，同時不難發現在業界其實已經有非常多的公司已經在自己的商業化解決方案中注入了AI能力，這種趨勢也是值得我們持續關注，最後我個人比較推薦在AI領域的落地和時間可以嘗試從本文提到的6個層次模型中去由淺入深的探索，這有利于在AI和測試的道路上有層次的循序漸進。
原文釋出時間為：2019-11-8
作者：汪維
本文來自雲栖社群合作夥伴“
阿裡技術”，了解相關資訊可以關注“
”。