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