Внедрение и оценка соотношения «польза / затраты»
автоматизированных GUI-тестов

Внедрение и оценка автоматизированных GUI-тестов

Аннотация

Работа посвящена введению автоматизированных GUI-тестов в компании AEB (поставщик отраслевых решений для логистики и таможенного оформления) и оценке соотношения «польза / затраты» такой автоматизации. Сначала рассматриваются основы качества ПО, роль тестирования и место GUI-тестов в расширенной «пирамиде тестов». Далее описываются техники браузерной автоматизации (Proxy и WebDriver), подходы к созданию автотестов («record & play» и программирование), а также вопросы кросс-браузерного тестирования.

На примере продукта BrokerIntegration реализуются автоматизированные GUI-тесты с использованием фреймворка Selenide; тесты интегрируются в build-pipeline Jenkins и дополняются скриншот-регрессией. Эффективность оценивается через количественный анализ (время прогона, экономия трудозатрат, прогноз окупаемости) и качественный анализ (влияние на поддержку, процессы релизов и доверие разработчиков к системе тестирования). Показано, что при учёте кросс-браузерного тестирования окупаемость достигается в пределах нескольких лет, а автоматизация существенно повышает качество релизов.

1. Введение

Графические пользовательские интерфейсы (GUI) — основная точка контакта пользователя с программной системой. От корректности и удобства GUI напрямую зависит воспринимаемое качество продукта. Традиционно пользовательские сценарии проверяются вручную по тест-планам, что требует значительных ресурсов и ограничивает частоту регрессионных прогонов перед каждым релизом.

В компании AEB GUI-тесты для продукта BrokerIntegration раньше выполнялись только вручную: тест-бланк объёмом 42 страницы занимал около шести часов работы тестировщика на один полный прогон. С ростом требований к частоте релизов и необходимости поддержки нескольких браузеров такая схема стала узким местом.

Цель работы — внедрить автоматизированные GUI-тесты для выбранного продукта и на основе полученных данных оценить, насколько оправданы затраты на их разработку и сопровождение.

2. Цели и исходное состояние

2.1 Цели исследования

• автоматизировать ключевые GUI-сценарии для продукта BrokerIntegration;
• интегрировать GUI-тесты в существующий конвейер сборки Jenkins;
• разработать схему оценки соотношения «польза / затраты»;
• на основе количественных и качественных данных оценить окупаемость;
• сформулировать рекомендации по дальнейшему развитию автоматизации в AEB.

2.2 Состояние до автоматизации

Перед внедрением автотестов в AEB использовались только ручные регрессионные тесты по бумажным/электронным тест-бланкам. Для выбранного продукта:

• 42-страничный тест-план,
• около 6 часов на один полный прогон,
• перед каждым релизом запускался один-два раза,
• для кросс-браузерной проверки время увеличивалось минимум в 3–4 раза.

Задача заключалась в том, чтобы сохранить эквивалентное покрытие, но сделать регрессию воспроизводимой, быстродействующей и доступной для регулярного запуска.

3. Качество ПО и автоматизированные тесты

3.1 Качество и роль тестирования

Качество ПО в стандарте DIN ISO 9126 определяется как совокупность характеристик (функциональность, надёжность, производительность, удобство сопровождения и др.), обеспечивающих соответствие требованиям. Тестирование — лишь одна из мер обеспечения качества, но именно через тесты качество становится проверяемым и частично измеримым.

Автоматизированные тесты выполняются без участия человека, воспроизводимы, хорошо подходят для регрессии и значительно снижают риск повторного появления уже исправленных дефектов.

3.2 Расширенная тест-пирамида

В работе используется классическая «пирамида тестов», дополненная характеристиками уровней:

• Unit-тесты — быстрые, дешёвые, независимы от внешних систем;
• Интеграционные тесты — проверяют взаимодействие модулей;
• Системные тесты (в том числе GUI-тесты) — медленные и дорогие, требуют полноценной тестовой среды, но проверяют реальное поведение системы;
• Эксплораторное тестирование — интуитивное исследование системы, дополняющее запланированные тесты.

Рекомендуется переносить проверки по возможности на самый низкий уровень, а системные GUI-тесты использовать точечно — для сквозных сценариев, критичных для бизнеса.

4. Браузерная автоматизация и создание GUI-тестов

4.1 Proxy-подход

В Proxy-схеме всё взаимодействие браузера с сервером проходит через прокси-сервер, который может внедрять JavaScript-код, имитировать действия пользователя и перехватывать сетевой трафик. Для тестирования не требуется отдельный WebDriver для каждого браузера, но часть действий выполняется скриптами в DOM, что может конфликтовать с политиками безопасности.

4.2 WebDriver

WebDriver — стандарт W3C и набор реализаций для разных браузеров. Тестовая программа отправляет команды WebDriver, который через нативные API управляет браузером (щелчки, ввод текста, навигация). Такой подход обеспечивает более реалистичное поведение, меньше побочных эффектов и лучшую совместимость с ограничениями безопасности.

4.3 Способы построения GUI-тестов

• Record & Play — пользовательские действия записываются плагином или прокси, затем воспроизводятся. Проблемы: дублирование селекторов, слабая абстракция, высокая хрупкость при изменении интерфейса.
• Программирование тестов — сценарии пишутся на языке программирования (в работе — Java + Selenide). Даёт мощную абстракцию (Page Object, вспомогательные методы), лучше поддерживается в долгосрочной перспективе.

4.4 Кросс-браузерное тестирование

Из-за различий в реализации стандартов HTML/CSS и особенностей движков один и тот же интерфейс может вести себя по-разному в разных браузерах. Поэтому для корпоративных систем требуется проверка хотя бы в нескольких официально поддерживаемых браузерах (Chrome, Firefox, Internet Explorer/Edge).

5. Требования AEB к GUI-тестированию

В предыдущем исследовании в AEB были сформулированы требования к GUI-testing-framework’у. В данной работе часть требований используется как критерии для качественной оценки пользы и затрат.

6. Внедрение автоматизированных GUI-тестов

6.1 Продукт BrokerIntegration

BrokerIntegration — веб-приложение для взаимодействия с таможенными агентами: синхронизация данных, управление таможенными декларациями, визуальный контроль статусов и уведомления. Интерфейс реализован на Vaadin, поверх которого в AEB используется собственное GUI-фреймворк-надстройка.

6.2 Выбор и приоритезация тестов

Приоритизация выполнялась совместно с сотрудниками AEB. В первую очередь автоматизировались:

• критические сценарии (без них использование системы невозможно);
• наиболее часто используемые сценарии;
• типовые экспортные и импортные операции с разными вариантами прерываний и исправлений.

В три итерации было автоматизировано около 70 % сценариев из исходного ручного тест-плана (остальные зависели от работы с почтой и были отложены на будущее).

6.3 Архитектура тестов и уровни абстракции

Такая архитектура позволяет переиспользовать общие действия, изолировать изменения интерфейса в Page Object’ах и облегчает развитие тестовой базы.

6.4 Селекторы элементов

Поскольку Vaadin-фреймворк AEB не гарантирует уникальные id для каждого элемента, в качестве селекторов используются комбинации CSS-классов и текстов меток/кнопок. Для локализованных текстов применяются ключи из общих ресурсов локализации, что позволяет менять переводы без правки тестов.

6.5 Кросс-браузерные испытания

Тесты запускались в браузерах Chrome, Edge, Firefox и Internet Explorer. В процессе выявлены специфические проблемы WebDriver-реализаций (например, отсутствие корректной поддержки загрузки файлов в Edge и двойного клика в Firefox), которые решались обходными путями (эмуляция клавиатуры, JavaScript-события).

Наиболее быстрым и стабильным оказался Chrome; Internet Explorer демонстрировал в пять раз большее время прогона.

6.6 Интеграция в build-pipeline Jenkins

В nightly-сборке после успешного выполнения unit- и integration-тестов выполняется развёртывание продукта на тестовый стенд, затем запускаются GUI-тесты в нескольких браузерах. Результаты и артефакты (логи, HTML-дампы, скриншоты) доступны в Jenkins, при падениях рассылаются уведомления по e-mail.

6.7 Скриншот-регрессия

Для контроля визуальных изменений реализован компонент сравнения скриншотов: текущий снимок экрана сравнивается с эталонным, по превышению порогового числа отличающихся пикселей тест помечается как неуспешный и сохраняется «diff-изображение». Эталонные скриншоты версионируются вместе с тестами.

7. Количественный анализ: ресурсы и окупаемость

7.1 Нагрузка на build-pipeline

На основе измерений в Jenkins оценивается дополнительная нагрузка при включении GUI-тестов в nightly-сборку. Для одного продукта BrokerIntegration суммарное удлинение пайплайна составляет около 6 минут при использовании Chrome. Для прогнозирования полной автоматизации всех продуктов AEB используется коэффициент 200 (по числу продуктов и объёму функциональности).

Для ежедневных прогонов во всех браузерах потребовалось бы около семи постоянно занятых Jenkins-агентов; поэтому предлагается двухуровневая схема: ежедневные тесты только в Chrome и еженедельные кросс-браузерные запуски.

7.2 Сравнение ручного и автоматизированного тестирования

Для оценки окупаемости сравниваются трудозатраты:

• создание и поддержка ручных тест-бланков;
• ручное выполнение тестов при каждом релизе (для 1 и для 3–4 браузеров);
• разработка и поддержка автоматизированных тестов.

Для BrokerIntegration (70 % сценариев автоматизированы) получены следующие оценки:

• создание тест-бланков — около 3 человеко-дней (PT);
• ежегодная поддержка тест-бланков — 0,5 PT;
• ручное выполнение тестов — ≈ 2,5 PT в год на один браузер;
• разработка автотестов — ≈ 20 PT (без общих библиотек);
• поддержка автотестов — ≈ 1,5 PT в год.

При тестировании только в одном браузере окупаемость наступает примерно через 11 лет, однако при кросс-браузерном тестировании (3–4 браузера) срок сокращается до 2,5–3,5 лет.

8. Качественный анализ: влияние на процессы

Качественная часть анализа основана на интервью и обсуждениях с десятью сотрудниками AEB — архитекторами, разработчиками, тестировщиками и менеджерами продуктов.

8.1 Выполнение требований AEB

Было установлено, что большинство ключевых требований выполнено: затраты на регрессию снижаются, кросс-браузерные ошибки выявляются раньше, процесс тестирования стандартизируется, интеграция с Jenkins работает надёжно.

8.2 Влияние на сопровождение ПО

Благодаря использованию Page Object и хорошей абстракции изменения в продукте редко требуют массовой правки тестов. На момент исследования поддержка автотестов оценивалась как «несколько минут в неделю». Отдельной темой остаются изменения в бизнес-процессах (BPMN-схемы), которые могут потребовать перепроектирования сценариев.

8.3 Польза для разработки и релизов

Среди отмеченных преимуществ:

• раннее обнаружение регрессий, особенно в Internet Explorer;
• рост доверия разработчиков к nightly-сборкам;
• возможность чаще выпускать релизы без увеличения нагрузки на тестировщиков;
• большая готовность выполнять рефакторинг благодаря «страховке» в виде тестовой базы.

9. Заключение и рекомендации

Исследование показало, что автоматизация GUI-тестов для веб-приложений экономически оправдана, особенно при необходимости регулярного кросс-браузерного тестирования. При грамотной архитектуре тестов и использовании таких фреймворков, как Selenide/Selenium WebDriver, дополнительные затраты на сопровождение остаются умеренными.

В качестве рекомендаций предлагается:

• продолжать расширение набора автоматизированных сценариев для других продуктов AEB;
• централизованно развивать библиотеку общих Page Object’ов;
• использовать двухэтапную стратегию кросс-браузерного тестирования (часто — один быстрый браузер, периодически — полный набор);
• углублять практику скриншот-регрессии, исследовать применение компьютерного зрения (OpenCV и т.п.) для более интеллектуального сравнения изображений.

Библиографическое описание

GRAF M. Einführung und Auswertung des Nutzen-Aufwand-Verhältnisses von automatisierten GUI-Tests. Bachelorarbeit. Institut für Softwaretechnologie, Universität Stuttgart, 2017. 48 S.