«тестирование ГУЯ, самой часто изменяемой на этапе разработки системы части. Затраты на поддержание тестов случайно не перекроют затраты на обезьяньи методы тестирования?»
— Для того и существуют frameworks, позволяющие разносить операции с GUI и бизнес-логику теста на разные уровни (layers), разделять тест данные и код, автоматически проверять тест-код на консистентность.
И тогда изменения GUI не требуют изменений в тест-коде, единственный тест-скрипт позволяет покрывать десятки или сотни ручных тест кейсов, а в нужных случаях можно проверить не-GUI метод объекта, обратившись к нему напрямую (API call).
К тому же, кроме Web есть еще и Desktop, Text-Based/Terminal, и Mobile приложения, которые надо тестировать, и объемы тестирования располагают к автоматизации.
Правда, это все не о Selenium. Надо брать серьезные инструменты — QTP, TestComplete… WinRunner раньше тоже был очень силен.
Из бесплатных рекомендую AutoIT, но к нему надо будет скачать или разработать тест-библиотеки.
А можно взять за основу элементы из Microsoft Development Tools и построить практически с нуля, но это как правило application-specific framework получаются.
Сам я считаю, что от автоматизации максимальная польза когда это «робот на побегушках», а не «робот вместо человека».
Ну или как у меня на сайте написано: «I implement the methodologies intended to cover and support decision-making process and analysis by saving human time on micro-validations and bringing to the state of better awareness of high-level picture».
— Альберт

Спасибо.
Ни фига меня Баранцев не впечатлил. Просто я его оголотелый фанат, потому и… 🙂
(подпрыгивая) Дык, что Selenium… Не в нем же одном все счастье.
Это только поперву о нем Баранцев говорит, а ближе к концу учебы от Selenium уже ничего не остается, начинается не автоматизация GUI, а автоматизация по-существу. Обращение к файлам, работа с почтой, работа с базами данных.
Анадысь мы с коллегой в ходе автоматизации нашего приложения столкнулись с записью мудренного кейса — в нашу систему любой дурак может залогиниться через свой аккаунт на Фэйсбуке (звездно-полосатые жители ценят эту возможность, поэтому она есть). При активации этой замечательной возможности появляется поп-апчик с полями логина/пароля, который опосля логина ТАМ должен вернуть в браузер с НАШИМ приложением все данные.
Путь GUI-самурая — во что бы то ни стало записать все действия, но Selenium оказался слаб в коленках, и заколбасился. Real marazm in GUI automatization.
Молдаване-автоматизаторы выбрали более близкий подход к Баранцев-style — мы по-серьезному забили на GUI; мы взяли программистский код из репозитория; мы выцыганили из него URL, по которому определенным образом генерировались обращения из НАШЕГО браузера на сервер Фэйсбука; мы разложили этот код на определенные составные, и собрали собственный линк для генерации логина в НАШЕЙ системе под акаунтом с Фэйсбука; и вот — мы залогинены в НАШЕМ приложении под акаунтом ВНЕШНЕЙ системы посредством одной команды в Selenium. Оставалось только перегрузить страницу в браузере, и двигаться дальше по плану. Вот в такое дао автоматизации мы усердно вкуриваемся, и именно его я и подразумеваю, когда говорю об автоматизации.
Btw, изменчивость GUI в нашем приложении не так уж и ощутимо, пытуемый нами софт уже много лет здравствует для своих владельцев в определенном состоянии, и изменения в критической области функционала редки. Чаще сталкивались с мелкозаметными изменениями в буквах, которые вписываются в заголовки страниц, чем с передислокацией или переименованием элементов страницы.
Например, был заголовок ‘Personal Profile Page’, а потом без объяснений превратился в ‘Personal profile page’. Мелочь, но Selenium от такой очевидной разницы сразу колбасит, а поскольку assertTitle у нас используется часто, то — проблема.
Эту проблему (и ряд других) мы решили посредством предварительного объявления переменных для всех заголовков страниц, которые используются в каждом отдельном сценарии. Фишка отлично работает и непосредственно в Selenium IDE. Selenium IDE — рулит!
И буквально сегодня выяснилось — нам очень повезло, что мы занимаемся скриптованием и рукоприкладством попеременно. Возня с записью скриптов в какой-то момент реально утомляет. Хочется и покликать, свободно и широко.
А когда утомляет кликанье (такое тоже бывает), или же пугает предполагаемыми объемами, мы беремся за скриптование, и через некоторое время чувствуем себя белыми людьми на хлопковом поле в штате Луизиана образца 1860-го года.
Ты, понимаешь, своим делом занимаешься, и изредка на это чудо в отдельном окне поглядываешь, а оно, понимаешь, как бы само по себе шустренько работает… И суть не в том, что оно там ищет новые баги — это дело наших рук и бошек. Суть в том, что оно дает нам информацию, работает ли четко определенный функционал четко определенным, ожидаемым образом.