In an ideal world, software testing is all about bringing vital information to light so our teams can deliver amazing products that grow the business (to paraphrase James Bach). Investigation and exploration lie at the heart of testing. The obsession with uncovering critical defects before they unfurl into business problems is what gets under our skin and makes us want to answer all those “what if…” questions before sending each release off into the world.
But before the exploring can begin, some work is required. If you’re tracking down literal bugs in the wilderness, you’re not going to experience any gratification until after you check the weather forecasts, study your maps and field guides, gear up, slather on the sunscreen and mosquito repellant, and make it out into the field. If your metaphorical hunting grounds are actually software applications, these mundane tasks are called “checking.” This includes both the rote work of ensuring that nothing broke when you last made a code change (regression testing) and that the basic tenets of the requirement are actually met (progression testing).
This work is rarely described as “fun.” It’s not what keeps us going through those late-night bug hunts (along with pizza and beverages of choice). So, what do we do? We automate it! Now we’re talking… There is always primal joy in creating something, and automation is no different. The rush you get when your cursor moves, the request is sent, the API is called…all without you moving a finger…can make you feel fulfilled. Powerful, even. For a moment, the application is your universe, and you are its master.
你現在鬆一口氣了,把你的腳up, satisfied with your efforts. Tomorrow is now clear to be spent exploring. Back to the bug hunting! The next day, you flip open your laptop, ready to roll up your sleeves and dive into the fun stuff. But what’s that? Build failed? Awesome! Your work is already paying off. Your automated checks have already surfaced some issues…or have they?
No… not really. It was just an XPath change. No problem; you won’t makethatmistake again. You fix it up, and run the tests again. Wait, that element has a dynamic ID? Since when? Ok ok ok…fine! You utter the incantation and summon the arcane power of Regex, silently praying that you never have to debug this part of your test again. At some point, you glance at the clock. Another day has passed without any time for real exploration. This work was not fun. It was frustrating. No longer are you the master of this universe, but an eternal servant at the whims of an ever-growing list of flaky, capricious tests.
Turns out, the trick to getting past all the mind-numbing grunt work isn’t outsmarting the traditional script-based UI test automation that everyone’s been battling for years. It’s enlisting innately smarter automation—automation that understands what you need it to do so you can focus on what you actually want to do: explore!
With最新一代AI驅動的測試自動化基於光學識別，您可以將所有自動化物流委派給機器 - 因此您可以專注於真正使產品成功的創造性方麵。這種方法背後的想法是點擊可以理解和驅動UI就像人類的發動機。使用各種AI和機器學習策略模擬這種人類行為 - 例如，深度卷積神經網絡與先進的啟發式數據相結合 - 提供穩定，自我修複，平台 - 不可行的UI自動化。
From the tester perspective, you provide a natural language description of what actions to perform, and the engine translates that to the appropriate UI interactions. UI elements are identified based on their appearance rather than their technical properties. If some UI element is redesigned or the entire application is re-implemented using a new technology, it doesn’t matter at all. Like a human, the automation will simply figure it out and adapt.
確保這適用於您需要測試的所有技術的必要速度和準確性，是難以部分 - 但這是我們的工作，而不是您的問題。你可以卷起你的袖子，告訴它你想要測試的東西，讓自動化處理其餘部分。然後可以開始樂趣。
Here are two core ways that this “AI-driven UI test automation” approach helps you get back to the fun part of testing…
自動化無惡化
I’m no stranger to automation. I’ve worked in automation for over a decade, managing automation teams, implementing automation, and even doing some work on the Selenium project. Building stable automation at a technical level is invariably tedious, no matter what you’re automating. And aside from some very high-level guiding principles like separation of concerns, data abstraction, and design patterns, your mastery of automating one technology doesn’t really translate when it’s time to automate another.
Automatically driving a browser or mobile interface is a lot different than “steering” a desktop application, a mainframe, or some custom/packaged app that’s highly specialized. Technologies like model-based test automation remove complexity, adding an abstraction layer that lets you work at the business layer instead of the technical layer. However, it’s not always feasible to apply model-based approaches to extremely old applications, applications running on remote environments (e.g., accessed via Citrix), highly-specialized applications for your company/industry, etc.
通過基於圖像的測試自動化，底層技術是無關緊要的。如果您可以通過UI鍛煉應用程序，您可以為其構建自動化。沒有腳本。沒有學習曲線。隻要鍛煉它就會像你在檢查每個新用戶故事那樣做的，你可以在沒有任何工作或麻風的情況下獲得自動化的所有重複性和可擴展性。
Technology Stockholm Syndrome
Back when I was a university student, I “learned” that nothing would ever be developed that wasn’t a big heavy C thick client. There was some talk of thin clients, but of course those wouldn’t last. After I graduated, everyone was scrambling to rewrite their thick clients using the shiny new service-oriented architecture. Then came mobile. And containerization and Kubernetes.
到這段時間，我想出了我有一個問題：讓我們稱之為技術斯德哥爾摩綜合征。我被不斷變化的技術景觀所俘虜。奇怪的是，我有點喜歡它，因為這種不斷變化，永遠偏離的球門柱都很有趣。
This is a good problem to have in terms of ensuring the continued value and viability of your organization’s applications. You want your dev teams to stay on top of the latest trends and take advantage of new approaches that improve application flexibility, reliability, security, and speed. But if you’re responsible for building and maintaining the test automation, each change can be torture. In most cases, a technical shift means you need to scrap the existing test automation (which likely represents a significant investment of time and resources) and start over—rebuilding what’s essentially the same thing from scratch. Not fun.
Also, not really required anymore. You’d be surprised at how fewfundamentalchanges are introduced into an application’s UI from generation to generation. (Don’t believe it? Just take a trip back in web history onThe Wayback Machineand see for yourself.)
雖然潛在的實施和特定的外觀和感覺可能會發生巨大的方式，但大多數相同的核心測試序列通常仍然適用（例如，輸入MaxMusterman下麵用戶名, enter 12345 underpassword, and click theloginbutton). If those same general actions remain valid, then image-based test automation should still be able to identify the appropriate UI elements and complete the required set of actions.
Remember Java’s mantra of “write once, run anywhere”?” (Go ahead, insert your own Java joke here). Done right, this testing approach should actually deliver on that promise. Of course, you’ll probably want to add/extend/prune some tests as the app evolves from generation to generation—but you certainly don’t need to start with a blank slate each time the application is optimized or re-architected.
Deep down, testing is truly fun
UI test automation is undeniably a critical component of a mature enterprise test strategy. But wrestling with all the nitty gritty bits and bytes of it isn’t fun for anyone. Go search across engineers, professional testers, business users, and all sorts of other project stakeholders, and I guarantee you won’t findanyone渴望處理它。但作為一個學科的測試，作為創意，解決問題的過程，對其核心真正有趣。
Peel away the layers of scripting, flakiness, and constant failures, and you can (re)focus on the experimentation, exploration, questioning, modeling… all the things that make it fun and fulfilling.
*Originally appeared in SD Times