UI-тестирование
March 31, 2021

Структура тестового UI-сценария

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

  1. описание тестового окружения сценария
  2. алгоритм создания элементов тестового окружения сценария
  3. алгоритм сценария - шаги и проверки

Рассмотрим более подробно п.п. 2 и 3 предыдущего списка. Алгоритм UI-сценария обращается к элементам интерфейса тестируемой системы. Например, создание новых объектов происходит путем открытия формы нового объекта, заполнения реквизитов формы и нажатия кнопки-записи объекта. Подобные действия характерны как для алгоритма сценария, так и для алгоритма подготовки тестового окружения.

На примере тестового сценария можно сформулировать подход к декомпозиции кода автоматизированного сценария. Рассмотрим сценарий, который проверяет проводки документа "Требование накладная".

Возможны следующие варианты тестовых сценариев:

  • Списание По ФИФО
  • Списание По средней
  • Списание По ФИФО с доп. расходами
  • Списание По средней с доп. расходами

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

  • спр-к Организация метод списания По ФИФО
  • спр-к Организация метод списания По средней
  • спр-к Номенклатура
  • док-к Поступление товаров и услуг
  • док-к Поступление доп. расходов

Алгоритм сценария "Списание По средней с доп. расходами" схематично можно представить так:

  1. Создать и провести документ Поступление товаров и услуг с Организацией со списанием По средней
  2. Создать и провести документ Поступление доп. расходов с Организацией со списанием По средней
  3. Создать и провести документ Требование накладная с Организацией со списанием По средней
  4. Сравнить движения документа Требование накладная с эталоном

Другие сценарии будут построены аналогично, но будут использоваться другие тестовые данные. Получается, что форма каждого документа будет заполнятся 4-мя комбинациями значений реквизитов. Это означает, что алгоритмы заполнения форм документов нужно выделить в отдельные процедуры. Параметрами процедуры будут данные тестового окружения. Такую универсальную процедуру заполнения формы документа можно вызывать из различных сценариев, передавая в нее различные тестовые данные. В результате получаем псевдокод тестового сценария:

ПоступлениеТоваровИУслуг = Новый Структура (Реквизит=Значение,..,..)
ПоступлениеДопУслуг = Новый Структура (Реквизит=Значение,..,..)
ТребованиеНакладная = Новый Структура (Реквизит=Значение,..,..)
СоздатьПровестиПоступлениеТоваровИУслуг(Организация, ПоступлениеТоваровИУслуг)
СоздатьПровестиПоступлениеДопУслуг(Организация, ПоступлениеДопУслуг)
ТребованиеНакладная = СоздатьПровестиТребованиеНакладная(Организация, ТребованиеНакладная)
ПроверитьДвижения(ТребованиеНакладная)

Данный подход позволяет локализовать описание интерфейса и отделить его от тестовых данных. Тем самым применен шаблон проектирования "Page Object". Он позволяет при несущественных изменениях интерфейса формы не изменять все сценарии, достаточно будет изменить только одну процедуру заполнения формы. Это позволяет снизить затраты на поддержку автоматизированных тестовых сценариев.
При серьезных изменениях формы с добавлением новых реквизитов или изменении логики заполнения избежать серьезных изменений не получится. Придется дорабатывать сценарии и корректировать описание тестовых данных.