Файл: Отладка и тестирование программ: основные подходы, ограничения.pdf

Во-вторых, в случае, когда разработанные тесты ПО необходимо запускать в различных рабочих окружениях, браузерах или операционных системах, появляется возможность настройки удаленных серверов развертывания с независимом запуском одного набора тестов во всех необходимых средах. Это значительно ускоряет процесс тестирования. Это является значительным преимуществом Selenium в сравнении с существующими аналогами [8].

2.2. Анализ возможностей средства Ranorex и Rational Functional Tester

Ranorex является средством автоматизации тестирования GUI для тестирования настольных, web и мобильных приложений. Ranorex не имеет собственного языка сценариев, и использует в этом качестве стандартные языки программирования C# и VB.NET в качестве базы [9, 11].

Поддерживаемые приложения:

• Windows native (WinForms, WPF, Win32);
• Java;
• Qt;
• Delphi;
• Flex +;
• HTML.

Браузеры:

• Internet Explorer;
• Mozilla Firefox;
• Chrome;
• Safari.

Ranorex поддерживает возможности фиксации действий на базе применения интегрированного рекордера, идентификации различных элементов интерфейса пользователя при помощи инструмента Ranorex Spy. Все обнаруженные элементы хранятся в формате XML в соответствующих репозиториях. Отдельный элемент в них записан с помощью нотации XPath.

Исполнение тестов происходит путем последовательного запуска .exe файлов test-suite. После их выполнения формируется по одному файлу формата zip на один test-suite, каждый из которых включает один файл XML с полученными результатами. Затем программный скрипт осуществляет конвертацию XML формата в xUnit. За счет этого достигается возможность получить отчетов по каждому клиенту в Ranorex и в графическом формате представления тестов.

На базе записи данных действий происходит автоматическое формирование программного кода. Каждый шаг, при этом, можно написать вручную [2].

Окно создания тестового проекта в Ranorex представлено на рис.6.

Рисунок 6 – Создание тестового проекта в Ranorex

IBM Rational Functional Tester – это комплексный инструмент проведения автоматизированного регрессионного и функционального тестирования.

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

Rational Functional Tester входит в состав IBM Rational Quality Manager, что представляет собой стек средств управления процессом тестирования, идентификации дефектов, управления различными версиями сценариев осуществления тестирования и менеджмента требований. Инструментальные средства, которые интегрированы в данную платформу, позволяют обеспечить процесс ускорения разработки приложений, что способствует облегчению координации и коммуникации внутри разработчиков [4].

Окно работы с тестовым проектом в Rational Functional Tester представлено на рисунке 7.

Рисунок 7 – Работа с тестовым проектом в IBM Rational Functional Tester

Основные возможности [7]:

• проведение процесса тестирования программных приложений на языке Java;
• тестирование различных Web-приложений, реализованных на базе JavaScript, HTML и др;
• написание модульных тестовых сценариев на базе языка Java;
• интеграция технологии ScriptAssure для обеспечения проверки модификации прикладных данных;
• поддержка коммуникационных коллективных средств системы Rational;
• имплементация возможностей проверки работы приложений 3270 (zSeries) и 5250 (iSeries) с помощью плагина Functional Tester Extension для терминальных приложений.

2.3 Анализ преимуществ и недостатков автоматизации тестирования программ

Проведенные выше исследования специфики организации и обеспечения процесса тестирования ПО в автоматическом режиме является основой для выделения основных достоинств и недостатков применения концепции автоматизации тестирования.

Преимущества автоматизации тестирования [4,6,7]:

- Повторяемость. Разработанные тестовые сценарии выполняться единообразно, «человеческий фактор» не оказывает на процесс неожиданных негативных влияний. Таким образом, тестировщик не сможет пропустить тест.

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

- Снижение затрат на поддержку. Поддержка готовых тестов и анализ результатов их работы не требуют таких затрат времени, как проведение этого объема работы вручную.

- Наличие гибких отчетов. Отчеты о результатах тестирования генерируются и рассылаются автоматически.

Недостатки [1,2,6,7]:

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

- Рост расходов на поддержку. С увеличением количества релизов и развертываний в различных инфраструктурах повышаются временные и материальные затраты на поддержку.

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

- Стоимость средства автоматизации. Лицензионное ПО, его поддержка и установка не являются дешевыми и оплачиваются не единожды. Свободные средства не имеют, как правило, достаточной степени гибкости и удобства в использовании.

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

Выводы по главе 2

В данной главе приведены результаты проведенного обзора средств и технологий автоматизации процесса тестирования ПО. Описаны результаты проведенного анализа функциональных возможностей и достоинств Soap UI, Selenim, Ranorex и Rational Functional Tester. Проведен анализ общих преимуществ и недостатков, характерных для концепции автоматизированного тестирования ПО.

ГЛАВА 3 СПЕЦИФИКА РЕАЛИЗАЦИИ ПРОЦЕССА ТЕСТИРОВАНИЯ ПРОГРАММНОГО ОБЕСПЕЧЕНИЯ

3.1. Разработка и описание проекта для проведения тестирования

Для разработки системы автоматизированного тестирования за основу был взят паттерн проектирования Page Object.

Page Object - один из самых полезных и используемых архитектурных решений в автоматизации.

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

Благодаря данному шаблону проектирования удалось четко разделить описания страниц приложения и тесты. Создав для каждой страницы приложения отдельный класс и создав четкую иерархию наследования страниц приложения. Класс описывает страницу делиться на: описание веб-элементов страницы и действий над ними.

Для удобной работы с элементами страницы и создания своих веб-элементов был создан класс CustomFieldDecorator, который наследуется от DefauitFieidDecorator. С помощью которого мы можем создать декоративную оболочку вокруг стандартного веб-элемента и задекорировать такие элементы страницы как: текстовые поля, выпадающие списки, кнопки и другие веб-элементы.

Далее рассмотрим несколько примеров описания элементов страницы с помощью самописного декоратора:

1. Описание выпадающего списка на странице.

@FindBy(name = "bmonth") public SelectList bmonthField;

2. Описание текстового поля на странице.

@FindBy(name = "firstname")

public TextField firtNameField;

3. Описание кнопки на странице.

@FindBy(name = "submit")

public Button submitButton;

Описав каждый элемент страницы необходимо описать действия, которые можно выполнять с данными элементами. Действия описываются в том же классе, где и сами элементы.

Далее рассмотрим действие над несколькими стандартными элементами страницы.

Над текстовым полем можно сделать действие очистки поля и ввести новое значение в поле, что представлено на следующем фрагменте:

@Step("FirstName {0}")

public AddAddressPage setFirtNameField(String text){

firtNameField.clearAndType(text); return this;

}

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

@Step("Month {0}")

public AddAddressPage setBmonthField(String text){ bmonthField.select(text);

return this;

}

Над кнопкой можно с эмулировать действия клика мыши:

@Step("Enter")

public void clickSubmitButton(){

submitButton.click();

}

Далее необходимо проинициализировать каждую страницу и элементы на ней. Инициализация происходит в конструкторе класса PageManager. Пример инициализации страницы:

addGroupPage = initElements(new AddGroupPage(this));

Для каждого объекта в приложении созданы классы-помощники, которые наследуются от базового класса-помощника DriverBaseHelper. Он создает объект PageManager, а также инициализирует WebDriver для класса-помощника и передает помощникам ApplicationManager.

Классы-помощники нужны для описания общих действий над объектами, таких как: создание, редактирование, удаление и т.д.

Классы-помощники имеют доступ как к действиям над элементами страницы через PageManager, так и к другим классам-помощникам через ApplicationManager. Для нашего приложения используется следующие классы-помощники:

• NavigationHelper - ответственный за навигацию по страницам;
• GroupHelper - ответственный за действия над группами;
• AddressHelper - ответственный за действия над адресами.

Всеми менеджерами управляющей ApplicationManager, которому все менеджеры создаются и ограничиваются к ним доступ.

Также данный менеджер ответственный за запуск и остановку браузера и передачу параметров в WebDriver.

Все тестовые классы наследуются от класса TestBase, который служит для создания ApplicationManager и остановке браузера после завершения тестов.

В каждом тестовом классе описываются тесты по конкретному объекту: тесты с адреса в классе AddressTest, по группа в классе GroupTest.

Для управления тестовыми данными используется технология - Data Driven Testing.

Data Driven Testing (тесты, управляемые данными) - это такой подход к тестированию, при котором тестовые данные хранятся отдельно от скриптов, обычно в документе Excel, CSV-файле или в базе данных. То есть данные для тестов хранятся отдельно и в зависимости от количества набора тестовых данных будет зависеть количество тестов [13].

Для генерации тестовых отчетов использовался Allure Framework.

Для успешной генерации отчетов необходимо все методы воздействия над элементами заметить аннотацией @step (), а тестовые методы заметить аннотация @Title и @Description.

На рис. 8 можно увидеть общий вид фрагмента UML-диаграммы проекта.

Рисунок 8 – UML-диаграмма проекта

3.2. Конфигурация и применение средства автоматизации тестирования Jenkins

Для дальнейшей работоспособности тестов, следует создать новый job и настроить его (рис.9).

Для создания новой job в Jenkins, выбираем первый предложенный пункт. Это - основной и наиболее универсальный тип задач в Jenkins. Jenkins будет собирать наш проект, комбинируя любую SCM с любой сборочной системой.

Данный тип проектов может использоваться для задач, отличных от сборки ПО.

Рисунок 9 – Создание job

После того как job была создана, следует провести все настройки для удачного выполнения тестов.

На рис. 10 управления исходным кодом осуществляется с помощью «Git» (распределенная система управления версиями).