Основано на теории, практике, размышлениях, 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 1Log level 2Log level 3

Каждый паттерн подходит для одних ситуаций, и не подходит для других Максимум усилий на выбор паттерна и подхода при старте автоматизации Паттерн => архитектура фреймворка => разработка

Questions?