Паттерны построения фреймворка в авто

Основано на теории, практике, размышлениях,
Lessons Learned
 В тестировании с 2004 года
 В настоящее время работаю в
GlobalLogic
 Автоматизировал на Test
Complete, UI Automation
(VS2008, C# + .NET + WPF)
 Люблю свою работу 
 Веду блог: testingforall.com
 Record-Play
 Functional Decomposition
 DDT/ODT
 Фреймворки
 Логирование
 Шаблон или модель, позволяющая выработать
общее решение для набора задач.
Характеристики:
Четкость/точность
Абстрактность
Суть: нажали запись, сделали действия, нажали стоп =>
получили скрипт
Когда имеет смысл использовать:
Знакомство с инструментом
Начинающий автоматизатор
Поймать сложный элемент
«Одноразовая» автоматизация
Недостатки:
Плахххоаяохая чеетитаемууость кода
Невозможно поддерживать и расширять
Не позволяет работать командно (несколько
человек, работая с одним модулем, создадут
свалку)
Изменение в приложении может вызвать коллапс
«фреймворка»
Суть: разбили скрипты на функции/методы,
разнесли по файлам, структурировали.
Суть: разбили скрипты на функции/методы,
разнесли по файлам, структурировали.
Суть: разбили скрипты на функции/методы,
разнесли по файлам, структурировали.
Подходит, когда:
 Функциональная команда (каждый пишет свое)
 Разный уровень автоматизаторов в команде (синьйоры
пишут фреймворк, юниоры пишут тесты на базе
фрейморка)
Сложности:
 Спроектировать структуру фреймворка
 Отвязать тесты от изменений
Давайте порисуем 
Особенности:
 Само по себе вынесение тестовых данных за
пределы скрипта – это еще не DDT
 DDT подходит не для всех проектов и не для всех
задач
 Центр внимания сконцентрирован вокруг данных
Вынесение данных за пределы скрипта:
DDT:
Что еще можно сделать?
Functional Decomposition:
DDT:
Особенности DDT:
 Трассировка: Test Data => SRS
 Возможность разделить составление тест дизайна от
написания кода тестов
 Возможность изменять тестовые данные, не трогая при
этом код
 Возможность генерировать случайные данные и гонять
на них тесты в режиме non-stop
DDT подходит, если:
 В проекте много сущностей с большим числом входных данных
(поля регистрации, добавления чего-то и т.п.)
 Есть кому составлять тестовые данные, есть кому писать
фреймворк
DDT не подходит для:
 Проверки workflow-based требований или функциональности
 Тестов для графики (визуализация чего-то, layout, картинки и т.п.)
Давайте порисуем 
Особенность:
 Центром внимания является объект
Подходит, если:
 Приложение содержит много визуализации/окон/форм
и мало полей ввода
Сложности:
 Сложность архитектуры фреймворка под ODT
 «Боязнь» изменений
Давайте порисуем 
Пример:
Преимущества:
 Позволяет «держать в памяти» текущий объект =>
облегченное логирование в случае ошибок
 Позволяет существенно уменьшить
параметризацию методов
 Что логировать?
 Как логировать?
 Как это выглядит во фреймворке?
Tests
Helpers
Forms
Controls
Log level 1
Log level 2
Log level 3
 Каждый паттерн подходит для одних ситуаций, и
не подходит для других
 Максимум усилий на выбор паттерна и подхода
при старте автоматизации
 Паттерн => архитектура фреймворка => разработка
Questions?