UI-тестирование

UI-тестирование#

UI-тестирование проверяет пользовательские сценарии Global ERP: открытие форм, работу выборок и карточек, пользовательские операции, фильтрацию, ввод и сохранение данных, сообщения об ошибках и права доступа.

Примечание

Конкретные инструменты, параметры окружения и команды запуска зависят от проекта.

UI-тесты применяются для проверки сценариев, где важны действия пользователя и состояние интерфейса.

Проверяются:

  • вход пользователя в систему;

  • открытие разделов и форм;

  • работа выборок и карточек объектов;

  • вкладки и вложенные таблицы;

  • кнопки, операции и контекстное меню;

  • ввод, изменение и сохранение данных;

  • фильтрация, сортировка и поиск;

  • сообщения, предупреждения и ошибки;

  • печатные формы и отчеты;

  • загрузка и скачивание файлов;

  • адаптивность интерфейса, если требуется.

Для UI-тестирования используется тестовая среда:

  • тестовый контур приложения Global ERP;

  • тестовая БД PostgreSQL;

  • HTML5-клиент;

  • мобильное приложение, если оно проверяется;

  • тестовые пользователи;

  • тестовые роли и профили;

  • тестовые справочники;

  • тестовое файловое хранилище;

  • тестовые внешние сервисы или заглушки;

  • браузер или набор браузеров.

Предупреждение

UI-тесты не должны выполняться на промышленной среде, если сценарии создают, изменяют или удаляют данные.

Подготовка тестирования#

Инструменты#

Для автоматизации UI-тестирования могут использоваться:

  • Selenium WebDriver — для браузерных сценариев;

  • Playwright — для современных web-интерфейсов;

  • Cypress — для end-to-end тестирования web-приложений;

  • Selenide — для UI-тестов на Java/Scala поверх Selenium;

  • Appium — для мобильных приложений;

  • внутренние инструменты проекта.

Выбор инструмента фиксируется в проектной документации.

Тестовые данные#

Перед созданием UI-теста необходимо определить:

  • какие пользователи нужны для теста;

  • какие роли и профили назначаются пользователям;

  • какие справочники должны быть заполнены;

  • какие бизнес-объекты должны существовать до запуска;

  • какие данные создаются в процессе теста;

  • какие данные удаляются или откатываются после выполнения.

Примечание

Рекомендуется создавать данные для UI-теста автоматически через API или подготовительный скрипт. Это снижает зависимость от состояния тестовой БД.

Пример подготовки данных:

  1. Создать тестового пользователя.

  2. Назначить пользователю нужный профиль.

  3. Создать тестового контрагента.

  4. Создать тестовый договор.

  5. Открыть интерфейс и выполнить проверяемый сценарий.

  6. Удалить тестовые данные или откатить изменения.

Тестовые пользователи и права доступа#

Перед запуском UI-теста необходимо определить:

  • под каким пользователем выполняется тест;

  • какие роли и профили назначены пользователю;

  • какие разделы доступны пользователю;

  • какие операции доступны пользователю;

  • какие элементы интерфейса скрыты или заблокированы;

  • какие проверки выполняются для пользователя с ограниченными правами.

Набор тестовых пользователей может включать:

  • пользователя с правами администратора;

  • пользователя с правами на просмотр;

  • пользователя с правами на создание и редактирование;

  • пользователя без доступа к проверяемому разделу.

Создание и настройка#

Структура UI-теста#

Рекомендуемая структура UI-теста:

  1. Подготовка тестовых данных.

  2. Авторизация пользователя.

  3. Переход в нужный раздел.

  4. Выполнение пользовательских действий.

  5. Проверка результата в интерфейсе.

  6. Дополнительная проверка через API или БД, если требуется.

  7. Очистка тестовых данных.

Шаблон UI-теста:

test("создание документа через интерфейс") {
  // подготовка данных

  // вход в систему

  // открытие выборки

  // создание документа

  // заполнение полей

  // сохранение

  // проверка результата

  // очистка данных
}

Порядок создания UI-теста#

  1. Определить пользовательский сценарий.

  2. Определить тестового пользователя и права.

  3. Подготовить тестовые данные.

  4. Определить ожидаемый результат.

  5. Описать шаги пользователя.

  6. Реализовать автоматизированный тест.

  7. Добавить ожидания загрузки элементов.

  8. Добавить проверку результата.

  9. Добавить очистку тестовых данных.

  10. Запустить тест локально.

  11. Добавить тест в общий набор, если он стабилен.

Запуск тестов#

UI-тесты могут запускаться:

  • локально из IDE;

  • через командную строку;

  • в CI/CD;

  • на отдельном тестовом стенде;

  • по расписанию;

  • перед релизом.

Перед запуском проверьте:

  • доступность тестового стенда;

  • состояние тестовой БД;

  • наличие тестового пользователя;

  • настройку прав пользователя;

  • наличие браузера или драйвера;

  • доступность внешних зависимостей или заглушек;

  • отсутствие обращений к промышленной среде.

Команда запуска зависит от используемого инструмента.

Пример:

sbt test

Проверка результата#

UI-тест считается успешным, если:

  • пользовательский сценарий выполнен без ошибок;

  • нужная форма открылась корректно;

  • элементы интерфейса отображаются в ожидаемом состоянии;

  • данные введены и сохранены корректно;

  • результат операции отображается в интерфейсе;

  • сообщения и ошибки отображаются корректно;

  • тестовые данные очищены или изолированы;

  • повторный запуск дает тот же результат.

Примеры критериев:

  • документ создан через интерфейс;

  • статус документа изменился на Проведен;

  • документ отображается в выборке;

  • ошибка валидации отображается при незаполненном обязательном поле;

  • после удаления тестовый объект не отображается в списке.

Отчетность#

Если UI-тесты запускаются в CI/CD или перед релизом, в отчете фиксируются:

  • дата и время запуска;

  • версия приложения;

  • тестовый стенд;

  • браузер и его версия;

  • список выполненных тестов;

  • количество успешных и упавших тестов;

  • скриншоты при ошибках;

  • видеозапись выполнения, если поддерживается инструментом;

  • логи браузера;

  • логи приложения;

  • ссылки на отчет CI/CD.

Особенности UI-тестирования#

Проверка входа в систему#

Проверяются:

  • открытие страницы входа;

  • ввод логина и пароля;

  • успешная авторизация;

  • переход на стартовую страницу;

  • отображение доступных приложений или разделов;

  • сообщение об ошибке при неверных учетных данных;

  • выход из системы.

Сценарий:

  1. Открыть страницу входа.

  2. Ввести логин тестового пользователя.

  3. Ввести пароль.

  4. Нажать кнопку входа.

  5. Проверить, что открылась главная страница.

  6. Выполнить выход из системы.

Проверка навигации#

Проверяются:

  • доступность приложения;

  • доступность пункта меню;

  • переход по меню;

  • открытие формы;

  • заголовок формы;

  • основные элементы формы;

  • отсутствие ошибок при открытии.

Пример:

Путь: Приложение «Администратор» > Доступ > Пользователи

Ожидаемый результат:

  • открыта выборка пользователей;

  • отображается заголовок формы;

  • доступны основные действия;

  • ошибки загрузки отсутствуют.

Проверка выборок#

Проверяются:

  • открытие выборки;

  • загрузка данных;

  • отображение колонок;

  • порядок колонок;

  • наличие обязательных атрибутов;

  • фильтрация;

  • сортировка;

  • группировка;

  • открытие карточки из строки выборки;

  • операции из панели или контекстного меню;

  • обработка пустого результата.

Сценарий:

  1. Открыть выборку документов.

  2. Дождаться загрузки данных.

  3. Проверить наличие колонок Код, Наименование, Статус.

  4. Применить фильтр по статусу.

  5. Проверить, что в списке остались только документы с выбранным статусом.

  6. Открыть карточку первого документа.

Проверка фильтрации и поиска#

Проверяются:

  • простой фильтр;

  • универсальный фильтр;

  • поиск по строковому значению;

  • фильтрация по дате;

  • фильтрация по ссылочному атрибуту;

  • очистка фильтра;

  • сохранение или восстановление фильтра;

  • отображение пустого результата.

Сценарий:

  1. Открыть выборку.

  2. Применить фильтр по полю Статус.

  3. Проверить количество найденных записей.

  4. Очистить фильтр.

  5. Проверить, что список вернулся в исходное состояние.

Проверка карточек объектов#

Проверяются:

  • открытие карточки;

  • отображение вкладок;

  • обязательные поля;

  • заполнение полей;

  • изменение значений;

  • сохранение объекта;

  • ошибки валидации;

  • вложенные таблицы;

  • операции из карточки;

  • закрытие карточки.

Сценарий:

  1. Открыть карточку документа.

  2. Заполнить обязательные поля.

  3. Добавить строку во вложенную таблицу.

  4. Сохранить документ.

  5. Проверить, что документ сохранен без ошибок.

  6. Закрыть и повторно открыть карточку.

  7. Проверить, что введенные значения сохранились.

Проверка создания объекта#

Проверяются:

  • доступность команды создания;

  • открытие новой карточки;

  • заполнение обязательных полей;

  • сохранение объекта;

  • появление объекта в выборке;

  • значения после повторного открытия;

  • ошибка при незаполненных обязательных полях.

Сценарий:

  1. Открыть выборку документов.

  2. Нажать кнопку создания.

  3. Заполнить обязательные поля.

  4. Нажать кнопку сохранения.

  5. Проверить, что объект появился в выборке.

  6. Открыть объект и проверить сохраненные значения.

Проверка изменения объекта#

Проверяются:

  • открытие существующего объекта;

  • изменение доступных полей;

  • сохранение изменений;

  • отображение измененных значений в карточке;

  • отображение измененных значений в выборке;

  • запрет изменения недоступных полей;

  • ошибки валидации.

Сценарий:

  1. Открыть существующий документ.

  2. Изменить поле Наименование.

  3. Сохранить документ.

  4. Закрыть карточку.

  5. Повторно открыть документ.

  6. Проверить новое значение поля.

Проверка удаления объекта#

Проверяются:

  • доступность команды удаления;

  • подтверждение удаления;

  • отмена удаления;

  • успешное удаление;

  • исчезновение объекта из выборки;

  • запрет удаления при ограничениях;

  • ошибка при невозможности удаления.

Сценарий:

  1. Создать тестовый объект.

  2. Выбрать его в списке.

  3. Выполнить команду удаления.

  4. Подтвердить удаление.

  5. Проверить, что объект больше не отображается в выборке.

Проверка операций#

Проверяются:

  • наличие операции;

  • доступность операции;

  • скрытие или блокировка при отсутствии прав;

  • запуск операции;

  • ввод параметров;

  • успешное выполнение;

  • изменение данных после выполнения;

  • сообщение об успехе или ошибке.

Сценарий:

  1. Открыть карточку документа.

  2. Выполнить операцию Провести.

  3. Проверить, что статус документа изменился.

  4. Проверить, что появилась запись в связанных данных.

  5. Проверить сообщение о результате операции.

Проверка мастер-деталь связей#

Проверяются:

  • открытие главной выборки;

  • отображение подчиненной области;

  • обновление подчиненной области при выборе другой строки;

  • добавление подчиненной записи;

  • изменение подчиненной записи;

  • удаление подчиненной записи;

  • сохранение главного и подчиненных объектов;

  • восстановление данных после повторного открытия.

Сценарий:

  1. Открыть выборку документов.

  2. Выбрать документ.

  3. Проверить отображение строк документа в нижней таблице.

  4. Переключиться на другой документ.

  5. Проверить, что строки обновились.

Проверка сообщений и ошибок#

Проверяются:

  • сообщения об успешном выполнении;

  • предупреждения;

  • ошибки валидации;

  • ошибки прав доступа;

  • ошибки внешних сервисов;

  • ошибки при сохранении;

  • ошибки при выполнении операции;

  • корректность текста сообщения;

  • отсутствие непонятных технических сообщений.

Сценарий:

  1. Открыть карточку объекта.

  2. Не заполнить обязательное поле.

  3. Нажать кнопку сохранения.

  4. Проверить сообщение об обязательном поле.

  5. Проверить, что объект не сохранен.

Проверка пользовательских настроек интерфейса#

Проверяются:

  • ширина колонок;

  • порядок колонок;

  • скрытие и отображение колонок;

  • сортировка;

  • группировка;

  • сохранение настройки;

  • восстановление настройки при повторном открытии;

  • сброс настройки;

  • доступность публичных настроек в зависимости от прав.

Сценарий:

  1. Открыть выборку.

  2. Скрыть одну из колонок.

  3. Изменить порядок колонок.

  4. Закрыть форму.

  5. Повторно открыть форму.

  6. Проверить, что настройки восстановились.

  7. Выполнить сброс настроек.

Проверка печатных форм и отчетов#

Проверяются:

  • доступность команды печати или формирования отчета;

  • открытие формы параметров;

  • ввод параметров;

  • запуск формирования;

  • успешное завершение;

  • скачивание файла;

  • корректное имя файла;

  • ошибка при отсутствии данных.

Сценарий:

  1. Открыть карточку документа.

  2. Выполнить команду формирования печатной формы.

  3. Указать параметры, если они требуются.

  4. Дождаться формирования файла.

  5. Проверить, что файл скачан.

  6. Проверить, что ошибка не отображается.

Проверка файловых операций#

Проверяются:

  • загрузка файла;

  • отображение вложения;

  • скачивание файла;

  • удаление файла;

  • замена файла;

  • загрузка новой версии файла;

  • ошибка недоступного файлового хранилища;

  • ограничения по типу или размеру файла.

Сценарий:

  1. Открыть карточку объекта.

  2. Добавить тестовый файл.

  3. Проверить, что файл появился в списке вложений.

  4. Скачать файл.

  5. Удалить файл.

  6. Проверить, что файл больше не отображается.

Проверка адаптивности и браузеров#

Проверяются:

  • поддерживаемые браузеры;

  • разные разрешения экрана;

  • мобильные устройства, если применимо;

  • таблицы и карточки;

  • кнопки и меню;

  • отсутствие искажений интерфейса.

Матрица проверки может включать:

  • Chrome, актуальная версия;

  • Edge, актуальная версия;

  • разрешение 1920×1080;

  • разрешение 1366×768;

  • мобильное приложение Android, если используется.

Проверка прав доступа в интерфейсе#

Проверяются:

  • доступность разделов;

  • видимость пунктов меню;

  • доступность кнопок и операций;

  • доступность полей для редактирования;

  • запрет открытия карточки;

  • запрет сохранения объекта;

  • сообщение при отсутствии прав.

Сценарий:

  1. Войти пользователем без права редактирования.

  2. Открыть выборку.

  3. Проверить, что кнопка создания недоступна.

  4. Открыть карточку.

  5. Проверить, что поля доступны только для чтения.

Изоляция и повторяемость#

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

Рекомендуется:

  • использовать устойчивые селекторы;

  • не использовать фиксированные задержки без необходимости;

  • ожидать конкретное состояние элемента;

  • не зависеть от случайного порядка записей;

  • создавать тестовые данные заранее;

  • очищать тестовые данные после выполнения;

  • проверять только значимые элементы интерфейса;

  • не перегружать один тест несвязанными проверками.

Интеграция в массовый запуск или CI/CD#

В CI/CD можно запускать:

  • smoke UI-тесты после сборки;

  • тесты критичных пользовательских сценариев;

  • полный набор UI-тестов перед релизом;

  • ночные регрессионные проверки;

  • тесты совместимости с браузерами.

Типовые проблемы#

При разработке и запуске UI-тестов часто возникают:

  • нестабильные селекторы элементов;

  • зависимость от фиксированных задержек;

  • зависимость от состояния тестовой БД;

  • зависимость от порядка записей в выборке;

  • разные результаты в разных браузерах;

  • долгий запуск тестов;

  • падение тестов из-за медленной загрузки формы;

  • изменение интерфейса без обновления тестов;

  • отсутствие очистки тестовых данных;

  • недостаточные права тестового пользователя;

  • обращение к промышленной среде или внешним сервисам.

Рекомендации#

Рекомендуется:

  • проверять один пользовательский сценарий в одном тесте;

  • использовать отдельного тестового пользователя;

  • готовить данные автоматически;

  • не использовать промышленную среду;

  • использовать устойчивые селекторы;

  • ожидать конкретное состояние интерфейса;

  • не проверять лишние визуальные детали;

  • проверять успешные и ошибочные сценарии;

  • давать тестам понятные названия;

  • хранить тестовые данные и параметры запуска отдельно;

  • обновлять тесты при изменении интерфейса.

Ограничения#

UI-тесты не заменяют unit-, интеграционные и нагрузочные тесты.

Ограничения UI-тестирования:

  • выполняются медленнее unit- и интеграционных тестов;

  • требуют доступного пользовательского интерфейса;

  • чувствительны к изменениям верстки;

  • могут быть нестабильны при медленной загрузке стенда;

  • требуют подготовки тестовых пользователей и данных;

  • сложнее в сопровождении;

  • не всегда позволяют определить причину ошибки без анализа логов и БД;

  • не предназначены для оценки производительности под высокой нагрузкой.

Содержание