1 / 28

Automated testing patterns

Automated testing patterns. Основано на теории, практике, размышлениях, Lessons Learned. Несколько слов о себе. В тестировании с 2004 года В настоящее время работаю в GlobalLogic Автоматизировал на Test Complete, UI Automation (VS2008, C# + .NET + WPF) Люблю свою работу 

azize
Télécharger la présentation

Automated testing patterns

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

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

  3. О чем это все • Record-Play • Functional Decomposition • DDT/ODT • Фреймворки • Логирование

  4. Паттерн • Шаблон или модель, позволяющая выработать общее решение для набора задач. • Паттерн должен быть достаточно абстрактным, чтобы быть применимым ко множеству задач и дать свободу действий в реализации, не отклоняясь от сущности паттерна • Паттерн должен обладать четким набором характеристик, без наличия которых он теряет свою сущность.

  5. Record-Play Суть: нажали запись, сделали действия, нажали стоп => получили скрипт Когда имеет смысл использовать: • Знакомство с инструментом • Вы – начинающий автоматизатор (осторожно!) • Поймать сложный элемент или посмотреть, как инструмент предлагает решить то, что вызывает сомнения (цель – посмотретьи понять) • Нужна «одноразовая» автоматизация чего-то

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

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

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

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

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

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

  12. Data Driven Testing (DDT) Вынесение данных за пределы скрипта: DDT:

  13. Data Driven Testing (DDT) Что еще можно сделать?

  14. Data Driven Testing (DDT) Functional Decomposition:

  15. Data Driven Testing (DDT) DDT:

  16. Data Driven Testing (DDT) Особенности DDT: • Возможность трассировать требования на тестовые данные, огибая саму имплементацию тестов • Возможность разделить составление тест дизайна от написания кода тестов • Возможность изменять тестовые данные, не трогая при этом код (полезно для регресионных тестов) • Возможность генерировать случайные данные (валидные – проще, невалидные – сложнее, но возможно) и гонять на них тесты в режиме non-stop

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

  18. Object Driven testing (ODT) Особенности: • Центром внимания является объект Подходит, если: • Приложение содержит много визуализации/окон/форм и мало полей ввода Сложности: • Архитектура фреймворка под ODT – очень не тривиальная задача • Боязнь изменений

  19. Object Driven testing (ODT)

  20. Object Driven testing (ODT) Пример:

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

  22. Логирование: что, как • Что логировать? • Как логировать? • Как это выглядит во фреймворке?

  23. Логирование: что, как Tests Helpers Forms Controls Log level 1 Log level 2 Log level 3

  24. Логирование: что, как

  25. Логирование: что, как

  26. Логирование: что, как

  27. Логирование: что, как

  28. На этом все. Спасибо за внимание  Questions?

More Related