UI測試確實是最直觀的測試方法。隻要找一個能代表目標用戶的人，讓他們在日常工作中使用的界麵(UI)中閑逛。這是自然的。它是直觀的。現在，它仍然是用於測試大多數軟件發行版的主要方法。
這種人為驅動的測試永遠不會停止。讓聰明的測試人員創造性地探索UI，用他們的創造性和分析思維來發現破壞用戶體驗的問題是絕對必要的。但是，對每次修改都要進行嚴格的、常規的檢查，以確保修改不會帶來奇怪的副作用，這也是很重要的。以所需的頻率和速度執行如此乏味的檢查對人類測試人員來說是一種折磨。因此，向測試自動化的推進。
那麼，您可能會認為，開始測試自動化的自然位置應該是自動化所有測試中最自然的部分:人類與UI交互。不是這樣的。UI測試自動化實際上是最困難的測試之一測試自動化方法。
在UI級別自動化的測試在曆史上有相當多的問題。他們跑得很慢。它們很快就會斷裂。即使是在網絡和手機等常見的現代技術中，創建它們也有些技術化和乏味。當您必須處理自定義桌麵應用程序、打包應用程序、非常老的技術、非常新的技術或Citrix/遠程應用程序時，創建它們要困難得多。創建自動化的UI測試通常需要一個完全實現且穩定的UI。
如果您的目標是衝刺測試自動化，這意味著測試需要在開發人員完成最終UI代碼(成功構建)和衝刺應該完成之間的一小段時間內實現。你猜怎麼著?這種情況很少發生。在衝刺階段中，團隊當然可以處理人工UI測試(又稱探索性測試)。但自動化UI測試?這通常會被推遲到下一個衝刺階段，或者完全放棄。
顯然，UI測試自動化存在很多問題。但是如果你認真地思考這些問題，它們都可以歸結為一件事:測試自動化不像人類一樣思考:
- 人類可以非常快速地與應用程序的UI交互(人眼每秒可以處理24張圖像)。
- 人機交互不會因為界麵變化而脫軌。諸如重新實現的下拉菜單或顯示結果的新方法之類的東西根本不會影響人工測試人員。
- 人類的大腦可以與非常老的技術(比如大型機和基於cobol的應用程序)以及明天發布的任何新技術進行交互。如果你的應用程序從整體架構遷移到微服務架構，同一個測試人員的大腦仍然可以以完全相同的方式測試它的UI。
- 人工測試人員可能無法識別應用程序是安裝在他們的機器上，還是通過桌麵虛擬化訪問。他們同樣可以測試它的UI。
- 人們並不真的需要等待一個完全實現的(穩定的)UI實現。他們可以在一個粗略的原型可用時就開始進行測試。他們可以開始執行測試隻要UI至少有點如果底層的技術實現仍然有一些變化，這並不一定會是一個精彩的表演。
因此，如果UI測試自動化的關鍵問題源於人類智能大於測試自動化的事實，為什麼不嚐試用下一個最好的東西來解決這些問題:人工智能。通過利用AI的力量，我們可以實現UI測試自動化，它像人類一樣聰明和有彈性，但像機器一樣高效和可擴展。
為了實現這一點，技術必須學會如何像人類一樣理解用戶界麵。例如，它需要僅僅通過“看”就知道下拉列表是下拉列表。完成這些工作後，您——嗯，任何人——都可以通過簡單地提供應該測試什麼業務流程的自然語言解釋來定義測試自動化(例如，“在列表價格輸入中輸入10,000，單擊確認按鈕，然後……”)。人工智能驅動的測試自動化可以從這裏開始。沒有必要處理影子dom、web程序集等等。SAP上的模擬表無需任何特殊定製即可實現自動化。它不會在下一次有一個小的UI調整時失敗，並且如果應用程序在新技術中重新實現，您不必重新構建您的測試。
至於左移，隻要團隊繪製出粗略的原型或模型，您就可以開始實現UI測試。像這樣的高級UX設計是一個很好的起點:
你真的可以從任何地方開始。甚至更基本的白板草圖也可以讓您開始UI測試自動化，而不需要等待實際的實現。這意味著每次發布的關鍵時間更少，最終消除了測試延遲、未完成的故事和“強化衝刺”的連鎖反應。它還實現了一種有趣的TDD:在開始實現之前開始運行這些自動化的UI測試，然後讓開發人員編寫代碼，使它們通過測試。
抓住嗎?讓UI測試自動化變得如此簡單並不容易。有兩件事需要注意:準確性和速度。要做到這一點，這項技術必須能夠準確地識別以前從未見過的UI控件並與之交互。這需要視覺目標檢測以及光學字符識別(OCR)。這是很簡單的部分;困難的部分是要快速完成。一段時間以來，人工智能驅動的自動化解決方案一直在努力接近人類處理的速度。平均而言，你看到的工具每秒處理1.8張圖像，而人類可以處理25張。你不需要模仿人類速度的自動化，但你需要超越它。 If you want this UI testing to run as part of your continuous testing as a core part of your CI/CD process it needs to vastly超越人類眼睛和大腦的速度。
一旦你克服了這個小挑戰，ai驅動的UI測試將消除敏捷開發團隊中許多不那麼人為的衝突:
- 測試人員等待開發人員完成UI，這樣他們就可以開始執行測試，從而避免了sprint結束時可怕的關鍵時刻。
- 開發人員等待測試人員完成測試，以便用戶故事在當前sprint中被視為“完成”。
- 當延遲或未完成的測試導致未完成的用戶故事時，您所得到的所有複古的指責。
我承認，當您第一次告訴團隊UI測試自動化將幫助您更快地完成測試時，這可能是一個艱難的推銷。但是在開發人員編寫一行代碼之前，經過幾輪UI測試自動化的準備之後，我相信您會找到對這種人工智能驅動的測試方法的真正支持。
注:最初發表於DevOps.com