Automated testing patterns

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

Automated testing patterns

Несколько слов о себеВ тестировании с 2004

годаВ настоящее время

работаю в GlobalLogicАвтоматизировал на Test

Complete, UI Automation (VS2008, C# + .NET + WPF)

Люблю свою работу Веду блог:

testingforall.com

Record-PlayFunctional DecompositionDDT/ODTФреймворкиЛогирование

О чем это все

Шаблон или модель, позволяющая выработать общее решение для набора задач.

Паттерн должен быть достаточно абстрактным, чтобы быть применимым ко множеству задач и дать свободу действий в реализации, не отклоняясь от сущности паттерна

Паттерн должен обладать четким набором характеристик, без наличия которых он теряет свою сущность.

Паттерн

Суть: нажали запись, сделали действия, нажали стоп => получили скрипт

Когда имеет смысл использовать:Знакомство с инструментомВы – начинающий автоматизатор

(осторожно!)Поймать сложный элемент или

посмотреть, как инструмент предлагает решить то, что вызывает сомнения (цель – посмотреть и понять)

Нужна «одноразовая» автоматизация чего-то

Record-Play

Недостатки:Плохая читаемость кодаНевозможно поддерживать и расширятьНе позволяет работать командно

(несколько человек, работая с одним модулем, создадут свалку)

Изменение в приложении может вызвать коллапс «фреймворка»

Record-Play

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

Functional Decomposition

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

Functional Decomposition

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

Functional Decomposition

Подходит, когда:Функциональная команда (каждый пишет

свое)Разный уровень автоматизаторов в команде

(синьйоры пишут фреймворк, юниоры пишут тесты на базе фрейморка)

Сложности:Спроектировать структуру фреймворкаОтвязать тесты от изменений

Functional Decomposition

Особенности:Само по себе вынесение тестовых данных

за пределы скрипта – это еще не DDTDDT подходит не для всех проектов и не

для всех задачЦентр внимания сконцентрирован вокруг

данных

Data Driven Testing (DDT)

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

DDT:

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

Data Driven Testing (DDT)Functional Decomposition:

Data Driven Testing (DDT)DDT:

Data Driven Testing (DDT)Особенности DDT:Возможность трассировать требования на тестовые

данные, огибая саму имплементацию тестовВозможность разделить составление тест дизайна

от написания кода тестовВозможность изменять тестовые данные, не трогая

при этом код (полезно для регресионных тестов)Возможность генерировать случайные данные

(валидные – проще, невалидные – сложнее, но возможно) и гонять на них тесты в режиме non-stop

Data Driven Testing (DDT)DDT подходит, если:В проекте много сущностей с большим числом входных

данных (поля регистрации, добавления чего-то и т.п.)Есть кому составлять тестовые данные (не должно

демотивировать), есть кому писать фреймворк (он обычно сложнее, чем при FD)

DDT не подходит для:Проверки workflow-based требований или

функциональностиТестов для графики (визуализация чего-то, layout,

картинки и т.п.)

Object Driven testing (ODT)Особенности:Центром внимания является объект

Подходит, если:Приложение содержит много

визуализации/окон/форм и мало полей ввода

Сложности:Архитектура фреймворка под ODT – очень не

тривиальная задачаБоязнь изменений

Object Driven testing (ODT)

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

Object Driven testing (ODT)Преимущества:Позволяет «держать в памяти» текущий

объект => облегченное логирование в случае ошибок

Позволяет существенно уменьшить параметризацию методов

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

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

Tests HelpersForms Controls

Log level 1 Log level 2 Log level 3

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

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

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

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

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

Questions?