X Международная студенческая научная конференция Студенческий научный форум - 2018

ВВЕДЕНИЕ

Первые попытки «автоматизации» появились в эпоху операционных систем DOS и CP/M. Тогда она заключалась в выдаче приложению команд через командную строку и анализе результатов. Чуть позднее добавились удаленные вызовы через API для работы по сети. Впервыеавтоматизированное тестирование упоминается в книге Фредерика Брукса «Мифический человеко-месяц», где говорится о перспективах использования модульного тестирования. Но по-настоящему автоматизация тестирования стала развиваться только в 1980-х годах[1].

Автоматизированное тестирование программного обеспечения —это процесс тестирования программного обеспечения, при котором основные функции и шаги теста, такие как запуск, инициализация, выполнение, анализ и выдача результата, производятся автоматически с помощью инструментов для автоматизированного тестирования[2].

В свою очередь, инструмент для автоматизированного тестирования — это программное обеспечение, посредством которого осуществляется создание, отладка, выполнение и анализ результатов прогона тест-скриптов (Test Scripts — это наборы инструкций для автоматической проверки определенной части программного обеспечения).

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

Цель данной работы разработать и реализовать собственный фреймворк для автоматизированного тестирования через пользовательский интерфейс (GUI), на примере веб-приложения «Система учета товаров на складе магазина», который будет запускаться в автоматическом режиме на тестовой машине в определенное время.

ГЛАВА 1 ТЕОРЕТИЧЕСКАЯ ЧАСТЬ 1.1 Особенности автоматизированного тестирования

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

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

Быстрое выполнение – автоматизированному скрипту не нужно сверяться с инструкциями и документациями, это сильно экономит время выполнения.

Меньшие затраты на поддержку – когда автоматические скрипты уже написаны, на их поддержку и анализ результатов требуется, как правило, меньшее время чем на проведение того же объема тестирования вручную.

Отчеты – автоматически рассылаемые и сохраняемые отчеты о результатах тестирования.

Выполнение без вмешательства – во время выполнения тестов инженер-тестировщик может заниматься другими полезными делами, или тесты могут выполняться в нерабочее время (этот метод предпочтительнее, так как нагрузка на локальные сети ночью снижена).

Недостатки автоматизации тестирования:

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

Затраты на поддержку – несмотря на то, что в случае автоматизированных тестов они меньше, чем затраты на ручное тестирование того же функционала – они все же есть. Чем чаще изменяется приложение, тем они выше.

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

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

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

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

Если принято решение автоматизировать тесты, то для начала тестирования необходимо, исходя из требований к объекту, создать план, по которому будут разрабатываться автоматизированные тесты. В данном документе должно быть четко прописано, «что, как и чем» автоматизировать. Ниже перечислен список мест, где желательно применить автоматизацию:

Труднодоступные места в системе (бэкенд процессы, логирование файлов, запись в БД)

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

Рутинные операции, такие как переборы данных (формы с большим количеством вводимых полей с различными данными и их проверку после сохранения)

Валидационные сообщения (Автоматизировать заполнение полей не корректными данными и проверку на появление той или иной валидации)

Проверка данных, требующих точных математических расчетов

Проверка правильности поиска данных

А также, многое другое, в зависимости от требований к тестируемой системе и возможностей выбранного инструмента для тестирования.

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

Базовые операции создания/чтения/изменения/удаления сущностей

Типовые сценарии использования приложения, либо отдельные действия.

Интерфейсы, работы с файлами и другие моменты, неудобные для тестирования вручную.

Это и есть функциональность, от автоматизации тестирования которой, можно получить наибольшую отдачу.

1.2 Основные подходы и уровни автоматизации

Существует два основных подхода к автоматизации тестирования: тестирование на уровне кода и тестирование пользовательского интерфейса (в частности, GUI-тестирование). К первому типу относится, в частности, модульное тестирование. Ко второму — имитация действий пользователя - функциональное тестирование (с помощью специальных тестовых фреймворков.)

Тестируемое приложение можно условно разбить на 3 уровня:

Уровень модульного тестирования (Unit Tests Layer)

Уровень функционального тестирование (Functional Tests Layer (Non-UI))

Уровень тестирования через пользовательский интерфейс (GUI Tests Layer)

Для обеспечения лучшего качества продукта, рекомендуется автоматизировать все 3 уровня. Рассмотрим более детально стратегию автоматизации тестирования на основе трехуровневой модели:

Уровень модульного тестирования (Unit Test layer)

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

Уровень функционального тестирование (Functional Test Layer non-ui)

Как правило не всю бизнес логику приложения можно протестировать через GUI слой. Это может быть особенностью реализации, которая прячет бизнес логику от пользователей. Именно по этой причине по договоренности с разработчиками, для команды тестирования может быть реализован доступ напрямую к функциональному слою, дающий возможность тестировать непосредственно бизнес логику приложения, минуя пользовательский интерфейс.

Уровень тестирования через пользовательский интерфейс (GUI Test Layer)

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

1.3 Инструментарий

Один из самых распространенных подходов в автоматизации тестирования через GUI – это разработка проекта на основе паттерна Page Object Model (POM)[3].

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

Преимущества Page Object

Page Object Patten объявляет элементы отдельно от реализации теста. Эта концепция делает код более понятным.

Независимость класса объектов от реализации теста позволяет использовать этот репозиторий в разных целях и с разными для выполнения тестами. Например, мы можем интегрировать POM с TestNG/JUnit для функционального тестирования, а также с JBehave/Cucumber для приемочного тестирования.

Количество кода становится меньше и он более оптимизирован. Его можно повторно использовать.

Методы получают более реальные имена и отображают выполненное действие на UI, например,gotoHomePage().

Главным инструментом является Selenium, а конкретно SeleniumWebDriver. Selenium – инструмент, специально разработанный для проведения автоматизированного тестирования веб-приложений в различных браузерах и на различных платформах. Следует заметить, что не только веб-приложения, а любые рутинные действия, выполняемые в браузере, могут быть автоматически протестированы с помощью Selenium[4].

WebDriver – инструмент для автоматизации реального браузера, посредством вызова команды браузера, используя при этом родной API для каждого конкретного браузера. Поддерживает различные языки программирования - Java, .NET, PHP и т.п. Этот инструмент был реализован для различных платформ, таких как:

GeckoDriver (Mozilla Firefox)

ChromeDriver (Google Chrome)

SafariDriver (Apple Safari)

InternetExplorerDriver (MS InternetExplorer)

MicrosoftWebDriver или EdgeDriver (MS Edge)

OperaChromiumDriver (браузер Opera)

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

спецификацию программного интерфейса для управления браузером,

референсные реализации этого интерфейса для нескольких браузеров,

набор клиентских библиотек для этого интерфейса на нескольких языках программирования.

Структурирование, группировку и запуск тестов, а также генерацию отчётов о тестировании, обеспечивает фреймворк тестирования, такой как JUnit или TestNG для Java, NUnit или Gallio для .Net, RSpec или Cucumber для Ruby и так далее. Разработка тестов ведётся в среде Eclipse, Intellij IDEA, Visual Studio, RubyMine и так далее. Сборка осуществляется посредством Maven, Gradle, Ant, NAnt, Rake и так далее. Запуск тестов по расписанию и публикацию отчётов выполняет сервер непрерывной интеграции – Jenkins, CruiseControl, Bamboo, TeamCity и так далее.

В данной работе в качестве фреймворка для тестирования использовался TestNG, так как языком разработки была Java.

TestNG предназначен для:

unit тестирования;

функционального тестирования;

интеграционного тестирование и т.д.

Возможности TestNG[5]:

1) Annotations. (Аннотация);

2) Использование XML для гибкого конфигурирования тестов;

3) Поддержка data-driven тестирования (с помощью аннотации @DataProvider);

4) Зависимые методы для тестирования серверных приложений;

5) Поддерживается в Eclipse, IDEA, Ant, Maven, Netbean, Hudson;

6) Тестирование вашего кода проходит многопоточно, что дает безопасность и быстродействие;

7) Легкий переход от JUnit.

Основные аннотации:

Аннотации @BeforeSuite, @AfterSuite обозначают методы, которые исполняются единожды до/после исполнения всех тестов.

Аннотации @BeforeTest, @AfterTest обозначают методы, которые исполняются единожды до/после исполнения теста.

Аннотации @BeforeClass, @AfterClass обозначают методы, которые исполняются единожды до/после исполнения всех тестов в классе, идентичны предыдущим, но применимы к тест-классам.

Аннотации @BeforeMethod, @AfterMethod обозначают методы, которые исполняются каждый раз до/после исполнения тестового метода.

Аннотации @BeforeGroups, @AfterGroups обозначает методы, которые исполняются до/после первого/последнего теста принадлежащего к заданным группам.

Аннотация @Test обозначает сами тесты. Здесь размещаются проверки.

Аннотация @DataProvider объявляет хранилище данных для теста. Обычно это метод, возвращающий Object[][] либо Iterator, содержащий список параметров для определенного теста, например {«en_US», Locale.US}. В самом тесте он объявляется с помощью параметра dataProvider в аннотации @Test.

У всех этих аннотаций есть следующие параметры:

enabled — можно временно отключить, установив значение в false

groups — обозначает, для каких групп будет исполнен

inheritGroups — если true(а по умолчанию именно так), метод будет наследовать группы от тест-класса

timeOut — время, после которого метод «свалится» и потянет за собой все зависимые от него тесты

description — название, используемое в отчете

dependsOnMethods — методы, от которых зависит, сначала будут выполнены они, а затем данный метод

dependsOnGroups — группы, от которых зависит

alwaysRun — если установить в true, будет вызываться всегда независимо от того, к каким группам принадлежит, не применим к @BeforeGroups, @AfterGroups.

Для логирования сообщений использовалась библиотека Log4j. Логирование – это возможность следить за процессом выполнения бизнес-логики проекта.

В качестве модуля для создания отчетов использовался ReportNG - это простой модуль отчетов HTML для тестовой платформы TestNG . Он предназначен для замены стандартного отчета HTML TestNG. Отчет по умолчанию является всеобъемлющим, но его не так-то просто понять. ReportNG обеспечивает простой, цветной вид результатов теста.

ReportNG генерирует 100% действительные файлы XHTML 1.0. Вывод может быть настроен путем перенастройки стилей по умолчанию с собственным файлом CSS[6]. Пример отчета представлен на рисунке 1.3.1.

Рисунок 1.3.1 Пример отчета созданного ReportNG

Для организации непрерывной интеграции использовалась система Jenkins. Она позволяет автоматизировать часть процесса разработки программного обеспечения, в котором не обязательно участие человека, обеспечивая функции непрерывной интеграции. Работает внутри в сервлет-контейнере, например, Apache Tomcat. Поддерживает инструменты системы управления версиями, включая AccuRev, CVS, Subversion, Git, Mercurial, Perforce, Clearcase и RTC. Может собирать проекты с использованием Apache Ant и Apache Maven, а также выполнять произвольные сценарии оболочки и пакетные файлы Windows. Сборка может быть запущена разными способами, например, по событию фиксации изменений в системе управления версиями, по расписанию, по запросу на определенный URL или после завершения другой сборки в очереди.

ГЛАВА 2. ПРАКТИЧЕСКАЯ ЧАСТЬ 2.1 Постановка задачи

В задачи практики входило создание собственного фреймворка для автоматизированного тестового через GUI, в качестве тестируемого приложения был взят один из билдов веб-приложения «Система учета товаров на складе магазина». Данное приложение предназначено для переноса действий, связанных с учетом товара на складе, в современную информационную систему.

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

Для создания фреймворка использовались инструменты, описанные в пункте «1.3 Инструментарий». В качестве среды разработки – Intelli IDEA.

2.2 Описание проекта

Проект написан на основе паттерна Page Object, в качестве главного класса выступает класс Page, представлен на рисунке 2.2.1. Это класс также реализует паттерн Singleton, и имеет функции запуска и закрытия приложения.

public class Page { private static final Logger LOG = Logger.getLogger(Page.class); public WebDriver driver; public Actions actions; public Page(WebDriver driver) { if (this.driver == null) { this.driver = driver; this.actions=new Actions(this.driver); PageFactory.initElements(this.driver,this); } } public Page openWoodstore() { LOG.info("openWoodstore"); driver.manage().window().maximize(); driver.get("http://192.168.0.184:8888/login"); driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS); return new LoginPage(this.driver); } public void close() { LOG.info("close"); driver.quit(); driver=null; }}

Рисунок 2.2.1 Класс Page

Диаграмму классов имитирующих страницы приложения можно посмотреть на диаграмме 2.2.1. Ниже, на рисунке 2.2.2 представлена структура классов UI, так как они выглядят в окне проекта.

Все классы тестов наследовались от общего класса BaseTest, структуру тестового пакета можно рассмотреть на рисунке 2.2.3.

Бизнес объекты такие как, продукт(Product) и пользователь(User) хранятся в отдельных структурах, в пакете businessobject. Входные данные для тестов в статических методах класса DataInfo и используются через аннотацию @DataProvider. Собственные exceptions используемые в проекте находятся в пакете с соответствующим названием, а классы необходимые для запуска фреймворка с консоли находятся в пакетах config и runner. Структура этих пакетов изображена на рисунке 2.2.4. Целиком проект можно посмотреть по ссылке: https://bitbucket.org/epamsaratovsummerpractice2017/selenium_woodstore.

Диаграмма 2.2.1 Диаграмма классов имитирующих страницы сайта

Рисунок 2.2.2 Структура классов UI

Рисунок 2.2.3 Структура пакета tests

Рисунок 2.2.4 Структура управляющих классов

2.3 Результаты тестирования

Результаты тестирования, благодаря ReportNG, оформляются в удобный html-отчет, который представлен на рисунке 2.3.1. На нем видно, сколько процентов тестов пройдено, сколько пропущено и сколько провалились. Также при нажатии на название набора тестовых классов, можно увидеть подробную информацию о тестовом методе: время его выполнения и логи записанные с помощью библиотеки Log4j. Как выглядит отчет об успешно пройденных тестах можно рассмотреть на рисунке 2.3.2, а на рисунке 2.3.3 изображен отчет о проваленных и пропущенных тестах. В нем к выше изложенной информации прибавляется еще стек-трейс возникшей ошибки, а также скриншот экрана сделанный в это же время.

Рисунок 2.3.1 Отчет о проведении автоматизированного тестирования

Рисунок 2.3.2 Отчет о проведении тестирования в тесте Othertesting

Рисунок 2.3.3 Отчет о непрошедших тестах в классе AddingNegativeProductFromWorkdayTest

ЗАКЛЮЧЕНИЕ

На практике был разработан фреймворк для автоматизированного тестирования через пользовательский интерфейс (GUI), на примере веб-приложения «Система учета товаров на складе магазина», который запускался в автоматическом режиме на тестовой машине в определенное время. В качестве тестовой машины выступала программа VirtualBox с установленной на ней системой Windows 7-64.

Фреймворк был написан на основе паттерна Page Object, и для его создания использовались такие инструменты как:

Среда разработки – Intelli IDEA

Инструмент для автоматизированного тестирования – Selenium WebDriver

Фреймворк тестирования – TestNG

Сборщик проектов – Maven

Библиотека для создания отчетов – ReportNG

Библиотека для логирования – Log4J

Парсер командной строки – Args4j

Система непрерывной интеграции – Jenkins

Система контроля версий файлов – Git

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

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

СПИСОК ЛИТЕРАТУРЫ

Автоматизированное тестирование программного обеспечения - основные понятия. [Электронный ресурс]. – Режим доступа: http://protesting.ru/automation/– Дата обращения: 10.07.2017.

Куликов Святослав. Тестирование программного обеспечения. — Базовый курс, версия книги 1.0.9 от 05.10.2016 – EPAM Systems – 2015-2016 — 289 с.

Основы использования паттерна Page Object вместе с Selenium WebDriver. [Электронный ресурс]. – Режим доступа: https://habrahabr.ru/post/145848/ – Дата обращения: 10.07.2017.

Selenium 2.0 и WebDriver. [Электронный ресурс]. – Режим доступа: https://selenium2.ru/docs/webdriver – Дата обращения: 20.07.2017.

Тестирование с помощью TestNG в Java. [Электронный ресурс]. – Режим доступа: http://devcolibri.com/1528– Дата обращения: 20.07.2017.

ReportNG. [Электронный ресурс]. – Режим доступа: https://reportng.uncommons.org/ – Дата обращения: 20.07.2017.

Код для цитирования: Скопировать