En

JazzTeam Software Development Company

Agile Java Development

Необходимость XML DSL платформы

Обоснование необходимости платформы

Автоматизация тестирования продукта - очень актуальная задача. Выполняя ее, приходится сталкиваться с различными проблемами:

- Когда тестирование стоит производить?

- Как сэкономить время на тестировании?

- С помощью чего производить автоматизацию?

- Какой подход при создании тестов выбрать?

Говоря о том, когда стоит производить тестирование, нужно отметить, что это часто зависит от размеров продукта и его сложности. Идеальным вариантом является применение тестов на всех стадиях разработки. Для этого с первой же версией продукта необходимо писать для него тесты. Тесты должны учитывать специфику системы, при необходимости иметь возможность работать с большим количеством различных экземпляров системы. Например, для тестирования всех одновременно разрабатываемых версий проекта. Необходимо думать над входными параметрами тестов, чтобы иметь возможность их запускать на серверах с различной конфигурацией и при этом не менять код. По возможности нужно стараться как можно большее количество входных параметров выносить в отдельные файлы.

В вопросе экономии времени необходимо понимать - чем больше мы вкладываем в тесты - тем качественнее продукт. Необходимо правильно вести документацию. В каждом тесте помечать связь с соответствующим бизнес-кейсом. Это позволит сэкономить в дальнейшем много времени, при поддержке тестов.

При выборе средств автоматизации на помощь приходит большое количество специально предназначенных для этого программ. Для web-приложений на настоящий момент можно воспользоваться Selenium. Он включает множество продуктов, позволяющих вести тестирование различными способами. Это  Selenium RC Server, Selenium IDE и другие.

Выбирая подход  автоматизации, нужно знать, что существуют различные методы для этого: использование программ, генерирующих тесты по обычным манипуляциям с браузером; написание тестов в стиле процедурного и объектно-ориентированного программирования; написание тестов с помощью DSL (Domain Specific Language) языка. Об этих подходах и принципиальной разнице между ними и пойдет речь.

Написание тестов с помощью программ, генерирующих тесты по манипуляциям с браузером

Такой программой является плагин FireFox Selenium IDE. С помощью него, для создания тестов нужно только включить запись теста в плагине, воспроизвести в браузере тест-кейс и тест готов! Такую работу можно дать и тестировщикам. Они могут за несколько дней создать множество тестов, покрыть большую часть приложения. Также полученный тест можно представить в виде кода  на почти любом языке программирования. Полученный тест можно запускать как в самом плагине, так и с помощью других продуктов от Selenium.  Но сами по себе сгенерированные тесты будут выполнены в стиле copy-paste, а все дополнительные проверки придется описать дополнительно в сгенерированном коде. Если нужно изменить во всех тестах несколько шагов, то  изменения придется делать во всех файлах, возможно полностью переделывать их. При большом количестве тестов это может занять очень много времени. На больших проектах количество различных тестов может превышать несколько сотен. При этом подходе поддержание тестов становится трудным, и они не имеют необходимой гибкости. Как итог - такой подход хорош в быстром написании тестов, но слаб во всех остальных возможностях.

Этот метод можно применять для небольших проектов, где главным параметром является скорость написания тестов.

Написание тестов программистом в процедурном стиле

Для получения в тестах желаемой гибкости, необходимо не генерировать их, а писать вручную на каком-нибудь языке программирования. Здесь средствами для выполнения тестов могут служить  библиотеки Selenium: Selenium RC или WebDriver. Они позволяют непосредственно из кода обращаться к браузеру. Такая задача уже требует от создателя тестов определенных знаний в программировании. Ее нельзя доверить неопытному программисту, т.к. он может допускать типичные ошибки при разработке, такие как copy-paste, hard-code и прочие. Все эти ошибки будут портить качество тестов и они потеряют все те свойства, ради которых были приняты решения писать тесты вручную. Желательно при написании таких тестов придерживаться следующих правил:

- выносить входные данные из самого кода, помещать их в файлы, или передавать в качестве параметров

- ввести в тестах логирование

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

- применять параметризацию - для уменьшения copy-paste и другие подходы.

За счет ручного прописывания всех шагов тестов, скорость покрытия приложения тестами уменьшится.

Еще один минус этого подхода: если записывать тесты просто как последовательность действий, то с программной стороны у тестов теряются желаемые возможности. Такой код трудно модифицировать, т.к. “паутинки” действий в тестах могут переплетаться, часто может возникнуть ситуация, где необходимо использовать copy-paste. При большом количестве тестов в них трудно подменять или модифицировать шаги, чтобы при этом не затронуть другие сценарии. Все это не позволяет создавать стабильные тесты, которые можно легко масштабировать и заменять в них различные значения. Каждое новое изменение будет требовать больших временных затрат.

Такой метод можно применять на больших проектах, но если время поддержания тестов будет длительным - больше года, то поддержание тестов в дальнейшем вызовет значительные проблемы.

Использование ООП модели (паттерна PageObject)

Добиться полной гибкости для тестов позволяет один замечательный подход - шаблон PageObject. Различия от предыдущего подхода в основном заключаются в том, что здесь идет упор на архитектуру тестов. Поручить эту работу можно только опытному программисту, который сможет грамотно отделить у тестов логику от действий, которые можно совершать на web-странице. Подход предполагает описание тестов чисто в стиле ООП. В начале создается ООП модель всей тестируемой системы, где описан каждый элемент (это кнопки, поля для ввода и т.д.) и представлены всевозможные действия с ним (нажатия, ввод текcта и т.д.). Эта модель сама по себе не является тестом, наоборот - это как бы прототип тестируемой системы, который является интерфейсом для будущих тестов, через который тесты получают доступ к системе. Для web-тестов этим прототипом является представление всех страниц, формочек со страницы, web-элементов и т.д. В этом прототипе можно получать любой из объектов и совершать с ним те действия, которые он в действительности может делать. Например, для страницы логина это:

- ввести данные в поле “логин”

- ввести данные в поле “пароль”

- нажать на кнопку “войти”

Последнее действие, кроме выполнения обозначенной операции (нажатия на кнопку), должно будет вернуть объект следующей страницы, которая появится после этой. И с тем объектом уже можно будет совершать другие операции, которые относятся только к нему.

Шаги бизнес-кейсов в этой ООП модели не описываются. Тесты уже создаются в дополнительной структуре классов, где идет манипуляция этой моделью. В этой структуре идет описание тех тест-кейсов, которые необходимо автоматизировать. Преимуществом такого подхода является очень большая гибкость тестов. Например, при добавлении нового поля, куда необходимо внести данные, нужно изменить только один(!) класс в модели, а не классы во всех тестах, где это новое поле появилось. На первый взгляд такой подход является просто неоспоримым лидером, но имеет и минусы:

- высокий уровень знаний человека, делающего тесты

- медленная скорость создания тестов

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

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

Создание и использование DSL (domain specific language) XML-based языка

Обычно, создание тестов требует как можно меньшего времени, но как можно большей гибкости. Часто автотестами занимаются не программисты, а тестировщики. В основном  квалификации у них не хватает, чтобы создать хорошую ООП модель тестов. Времени на их обучение попросту нет. В этом случае можно использовать средство, позволяющее создавать тесты на удобном для человека языке, совершенно без знаний языков программирования. Таким средством является фреймворк XML2Selenium. Он выполнен на основе WebDriver. Для создания тестов не нужно писать сложный код, тест достаточно представить в виде DSL языка на основе XML. Достаточно просто создать XML-файл и в нем описать последовательность тегов. Каждый тег - какое-то действие в тесте. Тесты получаются наглядными и пишутся очень быстро, их можно без труда видоизменять. Для запуска тестов необходим только фреймворк, браузер, и тесты, описанные в XML-формате. Чтобы поддерживать универсальность, эти теги могут реализовывать наследование, что позволяет уменьшить к минимуму повторение одинаковых шагов в различных тестах.

Отличительные черты платформы:

- плагинность (можно без труда добавить новый плагин для реализации необходимых действий)

- простое API Для создания плагинов

- интеграция с Junit и Jenkins (но при этом полная независимость от них и также от maven, с возможностью создавать свои собственные раннеры)

- возможность удаленного дебага на сервере

- отсутствие зависимости от selenium, потенциальная возможность использовать другой инструмент

- поддержка data driven (возможность описывать в удобном для человека виде результаты работы тестов, репорты получаются понятными даже тому, кто не создавал тест)

- возможность само-тестировать поведение, то есть писать тесты для фреймворка на этом же языке

- умный логгинг, возможность создания снэпшотов и скриншотов

- минимум программирования - jaxb

- eclipse плагин - простой редактор для создания новых тестов, даже без знания XML

- валидация тест кейсов

- рандомизация данных

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

- понятный пользователю обработчик исключений

- репорты для бизнес-пользователя в стиле bdd, какой угодно формат репортов

- поддержка if/for тегов

Используя платформу, можно быстро создать хорошие тесты, и при этом сразу получить множество возможностей для удобной с ними работы. А при необходимости и создать свои собственные дополнения к фреймворку, специфичные только для конкретного приложения.