Архитектура автоматизации: Ограниченное использование графического интерфейса (Thin GUI)

Проблема: Как можно протестировать графический интерфейс без непосредственного вызова элементов управления?

Решение: Разрабатывайте графический интерфейс пользователя как отдельный слой презентационного кода исходя из бизнес-логики. Используйте модульные- или API- тесты для тестирования бизнес-логики.

Контекст:

  • Участники: Разработчики помогают тестировщикам разработать архитектуру автоматизации
  • Продукт: Продукт имеет в наличии некоторый графический интерфейс или же другие формы отображения информации. Фреймворк автоматизации уже существует для модульного и API тестирования.
  • Цели: Расширить автоматические тесты для покрытия графического интерфейса

Стратегия тестирования:

  • Создание тестов: Тесты создаются как программистами, так и тестировщиками
  • Выполнение тестов: Тесты запускаются через модульный или API фреймворк
  • Оценка: Ожидаемые результаты описываются вручную в тестах. Заметка, фактические значения, которые отображаются на экране не проверяются, а проверяется значения которые посланы на спроектированный графический интерфейс

Атрибуты качества:

  • Сопровождение и поддержка: Высокая. Цель отделения фактического графического интерфейса заключается в том, чтобы сделать тесты более устойчивыми к изменениям графического дизайна. Хотя некоторые технические проблемы могут помешать этой цели.
  • Проверка: Средняя. GUI тесты написаны на том же языке программирования, что и модульные или API тесты. Соответственно, большинство людей из команды смогут проверять код автоматизации.
  • Целостность и зависимость: Средняя. Фактически графический интерфейс не тестируется автоматически, потому все равно нужно будет выделить ресурсы на ручное тестирование.
  • Возможность повторного использования: Средняя. Все что можно переиспользовать в этой технике - это модульные или API тесты

Следующий шаг:
Нет.