Есть отличная удаленная работа для php+codeception+jenkins+allure+docker спецов. 100% remote! Присоединиться к проекту

Архитектура автоматизации: Шаблоны проектирования

design-patterns
architecture
framework
infrastructure
Теги: #<Tag:0x00007f7b705841c8> #<Tag:0x00007f7b70584088> #<Tag:0x00007f7b7058ff28> #<Tag:0x00007f7b7058fde8>

(Mykhailo Poliarush) #1

Автоматизация как процесс не отличается чем-то разительным от других процессов. Создание автоматизации с нуля, оптимизация уже написанной автоматизации или же автоматизация тестирования при ограниченом времени на разработку. Так или иначе, мы сталкиваемся с одинаковыми проблемами, соответственно и их решения приблизительно одинаковы. Т.е. если существуют общие проблемы, то и существуют шаблоны по которым можно данные проблемы решить. Bret Pettichord обобщил данные проблемы и выделил некоторые шаблоны.

Шаблоны автоматизации (краткое описание)

Простой шаблон

  1. Проблема: Как можно создать много тестов без написания большого количества программного кода?
  2. Решение: Используйте обобщенную среду управления сценариями (фреймворк), расширяя ее под нужды вашего проекта.
  3. Шаблон: Фреймворк
Шаблоны взаимодествия с пользователем автоматизации
  1. Проблема: Как можно разместить тестовые данные в таблицы, не прописывая их жестко в коде тестовых сценариев?
  2. Решение: Напишите код, который позволит тестовым скриптам считывать тестовые параметры напрямую из таблиц.
  3. Шаблон: Скрипты на основе данных (data-driven).
  1. Проблема: Как специалисты без знания программирования могут сами создавать автоматизированные тесты?
  2. Решение: Используйте таблицы где будут определены свойства окон, элементы на окнах, действий и данные для тестов.
  3. Шаблон: Таблицы на основе пользовательского интерфейса.
  1. Проблема: Как бизнес пользователи могут создавать тестовые сценарии без знания программирования?
  2. Решение: Определите ключевые слова-действия, которые будут являться действиями пользователя с системой, с помощью которых можно будет создать нужный сценарий.
  3. Шаблон: Ключевые слова-действия (action keywords).
Шаблоны оптимизации
  1. Проблема: Как можно быть уверенным что разрабатываемый код работает правильно, при этом создавая регрессионные тесты для последующего рефакторинга кода?
  2. Решение: Пишите тесты до создания кода. Они будут способствовать созданию правильного дизайна и мотивировать в процессе кодирования.
  3. Шаблон: Программирование на основе тестов (test-first programming).
  1. Проблема: Как можно разработать тесты без взаимодействия через графический интерфейс?
  2. Решение: Используйте программные интерфейсы, которые позволяют получить прямой доступ к той функциональности, что надо протестировать.
  3. Шаблон: API-тесты.
  1. Проблема: Как можно протестировать графический интерфейс без непосредственного вызова элементов управления?
  2. Решение: Разрабатывайте графический интерфейс пользователя как отдельный слой презентационного кода исходя из бизнес-логики. Используйте модульные- или API- тесты для тестирования бизнес-логики.
  3. Шаблон: Ограниченное использование графического интерфейса.
Шаблоны дополнительных проверок
  1. Проблема: Как можно определить качество большого количества тестов?
  2. Решение: Воспользуйтесь оракулом. Это программа, которая вычисляет правильный ожидаемый результат.
  3. Шаблон: Использование оракула.
  1. Проблема: Пользователи могут совершить действия в такой последовательности, которой вы даже не могли себе представить при дизайне тестов. Как же протестировать их все?
  2. Решение: Спроектируйте автоматизированную обезьянку. Это модель состояния тестируемой системы на основе которой можно генерировать большое количество тестовых последовательностей.
  3. Шаблон: Автоматизированная обезьянка
  1. Проблема: Как можно найти ошибки, которые могут возникнуть только со временем? Из-за этого может возникнуть некорректные состояния системы или поломаться/создаться неправильные данные, но это будет выявлено спустя некоторого времени последующего тестирования системы.
  2. Решение: Добавьте проверки (assert) и диагностики в код продукта. Проверки указывают на неправильное функционирование системы, т.е. когда это случается - это дефект. Диагностики указывают на промежуточные значения, которые подлежат последующему анализу чтобы определить это дефект или нет.
  3. Шаблон: Проверки и Диагностики (Assertions and Diagnostics)
Легкий и быстрый шаблон
  1. Проблема: Как можно разработать автоматизацию, когда не хватает времени?
  2. Решение: Делайте то, что можете. Сфокусируйтесь на тех тестах, которые в данный момент наиболее полезны, smoke тесты, конфигурационные тесты. Тем временеи, изучите возможности инструмента автоматизации и его возможности.
  3. Шаблон: Быстро и неаккуратно (Quick and Dirty)


(futu) #2

Мне кажется что можно написать еще и антипаттерны))


(Mykhailo Poliarush) #3

как только руки дойдут, так можно будет сразу и описывать. есть желание начать самому?


(Vadim Kovrizhkin) #4

ссылки не работают


(Mykhailo Poliarush) #5

ссылки поправлены


(Vadim Kovrizhkin) #6

спасибо большое


(Eugene Moskalenko) #7

Спасиб, довольно интересные мысли :slight_smile:


#8

это типа так? :slight_smile:


(Mykhailo Poliarush) #9

очень похоже :slight_smile:


(Eugene Moskalenko) #10

@Viktor_Borisov, а вы ругались на такую реализацию :slight_smile: Оказывается - это продуманный опытом и годами подход :slight_smile:


#11

Как указал @polusok это для тех, кто не умеет программировать.


#12

Мне кажется профита мало от такой лабуды


(Eugene Moskalenko) #13

дак я же пошутил :slight_smile: эт ирония была :slight_smile: по доброму естественно)