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

Основано на теории, практике, размышлениях,
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:
 Возможность трассировать требования на тестовые
данные, огибая саму имплементацию тестов
 Возможность разделить составление тест дизайна
от написания кода тестов
 Возможность изменять тестовые данные, не трогая
при этом код (полезно для регресионных тестов)
 Возможность генерировать случайные данные
(валидные – проще, невалидные – сложнее, но
возможно) и гонять на них тесты в режиме nonstop
DDT подходит, если:
 В проекте много сущностей с большим числом входных
данных (поля регистрации, добавления чего-то и т.п.)
 Есть кому составлять тестовые данные (не должно
демотивировать), есть кому писать фреймворк (он
обычно сложнее, чем при FD)
DDT не подходит для:
 Проверки workflow-based требований или
функциональности
 Тестов для графики (визуализация чего-то, layout,
картинки и т.п.)
Особенности:
 Центром внимания является объект
Подходит, если:
 Приложение содержит много визуализации/окон/форм
и мало полей ввода
Сложности:
 Архитектура фреймворка под ODT – очень не
тривиальная задача
 Боязнь изменений
Пример:
Преимущества:
 Позволяет «держать в памяти» текущий объект =>
облегченное логирование в случае ошибок
 Позволяет существенно уменьшить
параметризацию методов
 Что логировать?
 Как логировать?
 Как это выглядит во фреймворке?
Tests
Helpers
Forms
Controls
Log level 1
Log level 2
Log level 3
Questions?