Automated testing patterns

Automated testing patterns Основано на теории, практике, размышлениях, Lessons Learned

Несколько слов о себе • В тестировании с 2004 года • В настоящее время работаюв GlobalLogic • Автоматизировал на Test Complete, UI Automation (VS2008, C# + .NET + WPF) • Люблю свою работу  • Веду блог: testingforall.com

О чем это все • Record-Play • Functional Decomposition • DDT/ODT • Фреймворки • Логирование

Паттерн • Шаблон или модель, позволяющая выработать общее решение для набора задач. • Паттерн должен быть достаточно абстрактным, чтобы быть применимым ко множеству задач и дать свободу действий в реализации, не отклоняясь от сущности паттерна • Паттерн должен обладать четким набором характеристик, без наличия которых он теряет свою сущность.

Record-Play Суть: нажали запись, сделали действия, нажали стоп => получили скрипт Когда имеет смысл использовать: • Знакомство с инструментом • Вы – начинающий автоматизатор (осторожно!) • Поймать сложный элемент или посмотреть, как инструмент предлагает решить то, что вызывает сомнения (цель – посмотретьи понять) • Нужна «одноразовая» автоматизация чего-то

Record-Play Недостатки: • Плохая читаемость кода • Невозможно поддерживать и расширять • Не позволяет работать командно (несколько человек, работая с одним модулем, создадут свалку) • Изменение в приложении может вызвать коллапс «фреймворка»

Functional Decomposition Суть: разбили скрипты на функции/методы, разнесли по файлам, структурировали.

Functional Decomposition Подходит, когда: • Функциональная команда (каждый пишет свое) • Разный уровень автоматизаторов в команде (синьйоры пишут фреймворк, юниоры пишут тесты на базе фрейморка) Сложности: • Спроектировать структуру фреймворка • Отвязать тесты от изменений

Data Driven Testing (DDT) Особенности: • Само по себе вынесение тестовых данных за пределы скрипта – это еще не DDT • DDT подходит не для всех проектов и не для всех задач • Центр внимания сконцентрирован вокруг данных

Data Driven Testing (DDT) Вынесение данных за пределы скрипта: DDT:

Data Driven Testing (DDT) Что еще можно сделать?

Data Driven Testing (DDT) Functional Decomposition:

Data Driven Testing (DDT) DDT:

Data Driven Testing (DDT) Особенности DDT: • Возможность трассировать требования на тестовые данные, огибая саму имплементацию тестов • Возможность разделить составление тест дизайна от написания кода тестов • Возможность изменять тестовые данные, не трогая при этом код (полезно для регресионных тестов) • Возможность генерировать случайные данные (валидные – проще, невалидные – сложнее, но возможно) и гонять на них тесты в режиме non-stop

Data Driven Testing (DDT) DDT подходит, если: • В проекте много сущностей с большим числом входных данных (поля регистрации, добавления чего-то и т.п.) • Есть кому составлять тестовые данные (не должно демотивировать), есть кому писать фреймворк (он обычно сложнее, чем при FD) DDT не подходит для: • Проверки workflow-based требований или функциональности • Тестов для графики (визуализация чего-то, layout, картинки и т.п.)

Object Driven testing (ODT) Особенности: • Центром внимания является объект Подходит, если: • Приложение содержит много визуализации/окон/форм и мало полей ввода Сложности: • Архитектура фреймворка под ODT – очень не тривиальная задача • Боязнь изменений

Object Driven testing (ODT)

Object Driven testing (ODT) Пример:

Object Driven testing (ODT) Преимущества: • Позволяет «держать в памяти» текущий объект => облегченное логирование в случае ошибок • Позволяет существенно уменьшить параметризацию методов

Логирование: что, как • Что логировать? • Как логировать? • Как это выглядит во фреймворке?

Логирование: что, как Tests Helpers Forms Controls Log level 1 Log level 2 Log level 3

Логирование: что, как

На этом все. Спасибо за внимание  Questions?

Automated testing patterns

Télécharger la présentation

Plus de contenu associé