Основано на теории, практике, размышлениях, Lessons Learned. - презентация

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

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

3 Record-Play Functional Decomposition DDT/ODT Фреймворки Логирование

4 Шаблон или модель, позволяющая выработать общее решение для набора задач. Характеристики: Четкость/точностьАбстрактность

5 Суть: нажали запись, сделали действия, нажали стоп => получили скрипт Когда имеет смысл использовать: Знакомство с инструментом Начинающий автоматизатор Поймать сложный элемент «Одноразовая» автоматизация

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

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

8

9

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

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

12 Вынесение данных за пределы скрипта: DDT:

13 Что еще можно сделать?

14 Functional Decomposition:

15 DDT:

16 Особенности DDT: Трассировка: Test Data => SRS Возможность разделить составление тест дизайна от написания кода тестов Возможность изменять тестовые данные, не трогая при этом код Возможность генерировать случайные данные и гонять на них тесты в режиме non-stop

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

18 Особенность: Центром внимания является объект Подходит, если: Приложение содержит много визуализации/окон/форм и мало полей ввода Сложности: Сложность архитектуры фреймворка под ODT «Боязнь» изменений Давайте порисуем

19

20 Пример:

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

22 Что логировать? Как логировать? Как это выглядит во фреймворке?

23 Tests Helpers Forms Controls Log level 1Log level 2Log level 3

24

25

26

27

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

29 Questions?