Точно не так все печально))) Как ни крути, но раньше так же говорили и про ручное тестирование, когда только зарождались инструменты автоматизации тестирования, но, тем не менее, никто и никуда не исчез. Просто рутину все переложили на автотесты и осталось время на исследовательское тестирование. С ИИ будет так же, я уверен.
На мой взгляд, Аutomation QA смогут наконец-то заняться более интересными вещами, чем простое функциональное тестирование. Будут развертывать инфраструктуру под AI тулзы и в целом учиться работать с моделями и всяческими прослойками, что появляются вокруг, от MCP до простого OpenAI API.
А ручному тестированию, совершенно точно, стоит задуматься над тем, чтобы учиться общаться с моделями и ИИ (в широком смысле). Задавать промпты и четко формулировать запрос.
Хотел пройти мимо, но не получилось. Скорее всего из-за того, что данный материал предназначен для новичков. Но все по порядку.
Смешались в кучу кони, люди.
Цель статьи, насколько мне стало понятно, сделать краткий обзор на популярные фреймворки автоматизации тестирования. Но не все представленные инструменты таковыми являются.
Selenium и Appium полноценными фреймворками автоматизации тестирования не являются. Что один, что другой, по сути, предоставляют единый интерфейс для разных компонентов автоматизации тестирования. Сами себя они считают экосистемой. Для того, чтобы запустить автоматизацию с использованием этих инструментов нужно будет самостоятельно подумать про систему запуска тестов, выбрать подходящие драйверы для управления браузером и выбрать совместимую библиотеку для предоставления отчетов о тестировании. Например, базовый набор для автоматизации тестирования на JavaScript с использованием Selenium будет выглядеть примерно так:
Mocha.js -> WebDriver -> Driver -> Browser
Mocha.js - система управления запуском тестов, со встроенной отчетностью. К слову, эта библиотека прописана даже как требование к selenium-webdriver, ссылка на документацию (вкладка JavaScript).
WebDriver - общее название библиотеки, которая предоставляет единый API для управления драйверами от разных браузеров. Например, в JavaScript это selenium-webdriver.
Driver - общее название программы, которая непосредственно управляет браузером. То есть физически кликает на элементы, определяет их видимость в DOM-дереве и так далее. Например, для Chrome это ChromeDriver, для каждой операционной системы он свой страница загрузки разных версий.
Selenium в своей документации ровно такую сборку и описывает, вот ссылка. То есть Selenium это не фреймворк автоматизации тестирования, это скорее набор инструментов, для построения фреймворка. Именно поэтому новички часто путаются и думают, что они получат все и сразу, а получают только возможность обращаться к методам WebDriver, но останется большим вопросом как запускать эти тесты, какая должна быть структура у проекта автоматизации и где получить удобные для восприятия человеком отчеты. Но в той же документации Selenium есть перечень полноценных фреймворков для автоматизации тестирования основанных на нём, ссылка (раздел “Frameworks”). Например, Selenide или WebdriverIO, они-то и должны были войти в обзор фреймворков. У них есть все и сразу, у некоторых даже есть встроенные инструменты для подбора и скачивания нужной версии средства управления браузером.
Appium, в свою очередь, устроен примерно так же, как описано выше, с отличием, что его условный WebDriver способен работать не только с браузерными драйверами, но и с UiAutomator2 и XCUITest. В своей официальной документации они разделяют проект на три компонента: Appium Core, Appium Drivers и Appium Clients. Последние как раз и являются фреймворками автоматизации тестирования, такие как: WebdriverIO, Nightwatch.js, ссылка на документацию. Это в целом очень мощный инструмент для автоматизации в принципе чего-либо, при этом на одном и том же клиенте с одним и тем же языком программирования. Но, как видно, из размышлений выше это не фреймворк. Appium не отвечает за запуск тестов, сбор отчетности или же программирование логики тестов, он ровно, как и Selenium предоставляет API для управления браузером и компонентами операционной системы.
Cypress и Playwright действительно являются самодостаточными и полноценными фреймворками для автоматизации, со встроенными инструментами управления браузером, запуском тестов и отчетностью. Они имеют место быть в этом списке.
TestCafe и Robot Frameworkя лично не использовал, потому ничего про них сказать не могу. Но на первый взгляд они действительно являются фреймворками автоматизации тестирования, по крайней мере в документации указаны все необходимые для фреймворка аспекты.
Cucumber- не является даже инструментом автоматизации. Об этом они сами пишут в своей документации на примере автоматизации тестирования в браузере, ссылка. Это средство запуска и организации тестов, которое может интегрироваться как с разными инструментами автоматизации, так и фреймворками. Например, у Cypress есть плагин от сообщества cypress-cucumber-preprocessor, который позволяет отказаться от встроенного runner’а, похожего на Mocha.js, в пользу Cucumber.
Описание сильных и слабых сторон
Сильные и слабые стороны в статье выглядят как сравнение фреймворков, могу ошибаться, но так действительно кажется. Но при этом они абсолютно неконсистентны по отношению друг к другу.
Вот несколько примеров:
У Selenium в качестве сильной стороны указана поддержка headless режима, она есть и у Cypress, но в его описании она не упоминается.
Также, у Selenium описана как сильная сторона интеграция с CI/CD, но учитывая, что встроенного управления запуском тестов у Selenium нет, то не понятно, на чем основана эта интеграция. К слову, об управлении запуском, в официальной документации Selenium указаны раннеры с которыми он работает, ссылка. В то же время у Cypress в документации есть целый раздел про CI/CD, ссылка. Конечно, все всегда сводится к обычному запуску скриптов, но тем не менее.
Cypress имеет специфику в запуске тестируемого web-приложения, он запускает его в iframe, что может накладывать ограничения на тестирование если на страницах вашего приложения используется iframe. Это можно назвать слабой стороной, но никак не отражено в статье. Для новичка это может оказаться сюрпризом.
У каких-то инструментов описана возможность работы в разных операционных системах у каких-то нет, у новичка может сложиться неправильное представление о поддерживаемых средах исполнения.
И так далее.
Подозрения
Это действительно просто подозрения и никого не хочется обвинять. Но статья полна подобных предложений:
Может некорректно обрабатывать динамические веб-страницы или страницы с большим количеством вызовов AJAX, или фреймворков, созданных для обработки таких страниц и вызовов.
Мне, например, абсолютно не понятно, что это за фреймворки, созданные для обработки страниц и AJAX вызовов. Данное предложение выглядит как набор слов услужливо сгенерированных умным Т9.
Итого:
На мой взгляд, автор статьи путает инструменты автоматизации, тестовые фреймворки (системы запуска и управления тестами) и фреймворки для автоматизации тестирования. Последние, как правило, агрегируют в себе все необходимые инструменты, для написания тестов, их запуска и генерации отчетности о прохождении тестов.
Опять же, это мое личное мнение, но для новичков эта статья может быть не только губительной, но и повысит уровень энтропии на их и не без того сложном пути познания мира автоматизации тестирования.
Точно не так все печально))) Как ни крути, но раньше так же говорили и про ручное тестирование, когда только зарождались инструменты автоматизации тестирования, но, тем не менее, никто и никуда не исчез. Просто рутину все переложили на автотесты и осталось время на исследовательское тестирование. С ИИ будет так же, я уверен.
На мой взгляд, Аutomation QA смогут наконец-то заняться более интересными вещами, чем простое функциональное тестирование. Будут развертывать инфраструктуру под AI тулзы и в целом учиться работать с моделями и всяческими прослойками, что появляются вокруг, от MCP до простого OpenAI API.
А ручному тестированию, совершенно точно, стоит задуматься над тем, чтобы учиться общаться с моделями и ИИ (в широком смысле). Задавать промпты и четко формулировать запрос.
Хотел пройти мимо, но не получилось. Скорее всего из-за того, что данный материал предназначен для новичков. Но все по порядку.
Смешались в кучу кони, люди.
Цель статьи, насколько мне стало понятно, сделать краткий обзор на популярные фреймворки автоматизации тестирования. Но не все представленные инструменты таковыми являются.
Selenium и Appium полноценными фреймворками автоматизации тестирования не являются. Что один, что другой, по сути, предоставляют единый интерфейс для разных компонентов автоматизации тестирования. Сами себя они считают экосистемой. Для того, чтобы запустить автоматизацию с использованием этих инструментов нужно будет самостоятельно подумать про систему запуска тестов, выбрать подходящие драйверы для управления браузером и выбрать совместимую библиотеку для предоставления отчетов о тестировании. Например, базовый набор для автоматизации тестирования на JavaScript с использованием Selenium будет выглядеть примерно так:
Mocha.js -> WebDriver -> Driver -> Browser
Mocha.js - система управления запуском тестов, со встроенной отчетностью. К слову, эта библиотека прописана даже как требование к selenium-webdriver, ссылка на документацию (вкладка JavaScript).
WebDriver - общее название библиотеки, которая предоставляет единый API для управления драйверами от разных браузеров. Например, в JavaScript это selenium-webdriver.
Driver - общее название программы, которая непосредственно управляет браузером. То есть физически кликает на элементы, определяет их видимость в DOM-дереве и так далее. Например, для Chrome это ChromeDriver, для каждой операционной системы он свой страница загрузки разных версий.
Selenium в своей документации ровно такую сборку и описывает, вот ссылка. То есть Selenium это не фреймворк автоматизации тестирования, это скорее набор инструментов, для построения фреймворка. Именно поэтому новички часто путаются и думают, что они получат все и сразу, а получают только возможность обращаться к методам WebDriver, но останется большим вопросом как запускать эти тесты, какая должна быть структура у проекта автоматизации и где получить удобные для восприятия человеком отчеты. Но в той же документации Selenium есть перечень полноценных фреймворков для автоматизации тестирования основанных на нём, ссылка (раздел “Frameworks”). Например, Selenide или WebdriverIO, они-то и должны были войти в обзор фреймворков. У них есть все и сразу, у некоторых даже есть встроенные инструменты для подбора и скачивания нужной версии средства управления браузером.
Appium, в свою очередь, устроен примерно так же, как описано выше, с отличием, что его условный WebDriver способен работать не только с браузерными драйверами, но и с UiAutomator2 и XCUITest. В своей официальной документации они разделяют проект на три компонента: Appium Core, Appium Drivers и Appium Clients. Последние как раз и являются фреймворками автоматизации тестирования, такие как: WebdriverIO, Nightwatch.js, ссылка на документацию. Это в целом очень мощный инструмент для автоматизации в принципе чего-либо, при этом на одном и том же клиенте с одним и тем же языком программирования. Но, как видно, из размышлений выше это не фреймворк. Appium не отвечает за запуск тестов, сбор отчетности или же программирование логики тестов, он ровно, как и Selenium предоставляет API для управления браузером и компонентами операционной системы.
Cypress и Playwright действительно являются самодостаточными и полноценными фреймворками для автоматизации, со встроенными инструментами управления браузером, запуском тестов и отчетностью. Они имеют место быть в этом списке.
TestCafe и Robot Framework я лично не использовал, потому ничего про них сказать не могу. Но на первый взгляд они действительно являются фреймворками автоматизации тестирования, по крайней мере в документации указаны все необходимые для фреймворка аспекты.
Cucumber - не является даже инструментом автоматизации. Об этом они сами пишут в своей документации на примере автоматизации тестирования в браузере, ссылка. Это средство запуска и организации тестов, которое может интегрироваться как с разными инструментами автоматизации, так и фреймворками. Например, у Cypress есть плагин от сообщества cypress-cucumber-preprocessor, который позволяет отказаться от встроенного runner’а, похожего на Mocha.js, в пользу Cucumber.
Описание сильных и слабых сторон
Сильные и слабые стороны в статье выглядят как сравнение фреймворков, могу ошибаться, но так действительно кажется. Но при этом они абсолютно неконсистентны по отношению друг к другу.
Вот несколько примеров:
У Selenium в качестве сильной стороны указана поддержка headless режима, она есть и у Cypress, но в его описании она не упоминается.
Также, у Selenium описана как сильная сторона интеграция с CI/CD, но учитывая, что встроенного управления запуском тестов у Selenium нет, то не понятно, на чем основана эта интеграция. К слову, об управлении запуском, в официальной документации Selenium указаны раннеры с которыми он работает, ссылка. В то же время у Cypress в документации есть целый раздел про CI/CD, ссылка. Конечно, все всегда сводится к обычному запуску скриптов, но тем не менее.
Cypress имеет специфику в запуске тестируемого web-приложения, он запускает его в iframe, что может накладывать ограничения на тестирование если на страницах вашего приложения используется iframe. Это можно назвать слабой стороной, но никак не отражено в статье. Для новичка это может оказаться сюрпризом.
У каких-то инструментов описана возможность работы в разных операционных системах у каких-то нет, у новичка может сложиться неправильное представление о поддерживаемых средах исполнения.
И так далее.
Подозрения
Это действительно просто подозрения и никого не хочется обвинять. Но статья полна подобных предложений:
Мне, например, абсолютно не понятно, что это за фреймворки, созданные для обработки страниц и AJAX вызовов. Данное предложение выглядит как набор слов услужливо сгенерированных умным Т9.
Итого:
На мой взгляд, автор статьи путает инструменты автоматизации, тестовые фреймворки (системы запуска и управления тестами) и фреймворки для автоматизации тестирования. Последние, как правило, агрегируют в себе все необходимые инструменты, для написания тестов, их запуска и генерации отчетности о прохождении тестов.
Опять же, это мое личное мнение, но для новичков эта статья может быть не только губительной, но и повысит уровень энтропии на их и не без того сложном пути познания мира автоматизации тестирования.