Организация процесса автоматизированного тестирования web-приложений на базе фреймворка Selenium

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

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

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

Недостатком автоматизации тестирования является то, что она применима только к работе с длинными проектами. Создание программы тестирования занимает много времени, и тратить это время на небольшие проекты просто бессмысленно. Как правило, автоматизированное тестирование эффективно применяется к относительно простым сценариям и тестам. Автоматизация сложных многошаговых сценариев может занять недопустимо много времени из-за непредвиденных нюансов или технических проблем [3]. Также может потребоваться много времени для поддержки тестов, при необходимости часто вносить в них правки после изменений в тестируемой функциональности. Несмотря на нюансы автоматического тестирования, этот тип не уступает, и компании внедряют его в свой рабочий процесс.

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

Разработка архитектуры программной системы. Архитектуру системы опишем в соответствии с рекомендациями Rational Unified Process. UML спецификация системы разделена на следующие части:

‒ Концептуальная модель. Данная модель описывает участников системы, основные сценарии и варианты использования системы;

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

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

Концептуальная модель разработанной программной системы представлена диаграммой вариантов использования (см. рис. 1):

Рис. 1. Диаграмма вариантов использования.

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

- Тестировщик создает/редактирует сценарий тестирования web-приложения, используя возможности фреймворка Selenium Web Driver [4] и среды юнит-тестирования NUnit для языка С#. Сценарий сохраняется в виде исполняемого файла .exe для проведения последующих тестов.

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

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

Диаграмма классов системы представлена на рисунке 2:

Рис. 2. Диаграмма классов.

Класс <Текущая сессия> содержит переменные для подсчета количества пройденных и не пройдённых тестов, адреса каталогов, а также методы инициации и проведения функционального тестирования:

‒     переменная служит указателем на интерфейс, через который пользователь управляет браузером;

‒     переменные , , , содержат информацию о путях расположения компонентов программы;

‒     переменные , являются счетчиками положительного и отрицательного прохождения тестов.

Класс <Текущий тест> содержит атрибуты, предоставляющие информацию о прохождении теста; инициирует и хранит такие переменные как:

‒     переменная хранит строку с наименованием протекающего тест- сценария.

‒    переменная служит индикатором прохождения тестирования.

‒    переменная является указателем на возникающее в случае выявления ошибки сообщение.

Класс <Генерация отчета> содержит атрибуты для создания отчета, инициирует и хранит такие переменные как:

‒     переменная которая является идентификатором этапа внесения информации: 0

– начало отчета, 1 – формирование отчета, -1 – завершение отчета.

‒    переменная хранит строку с наименованием протекающего тест- сценария.

‒     переменная хранит результат прохождения тестирования: True-пройдено,

False-не пройдено.

‒    переменная хранит строку с сообщением, выводимым при возникновении ошибки.

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

В разработанной программной системе в Visual Studio происходит компиляция кода на языке C#, который передается для исполнения утилите NUnit.consolerunner.

Скрипт теста содержит в себе команды, имитирующие взаимодействие пользователя с браузером Google Chrome при помощи драйвера Selenium WebDriver. При этом все внесенные или измененные данные записываются в существующую базу данных, связанную с тестируемым web-приложением. Диаграмма компонентов представлена на рисунке 3:

Рис. 3. Диаграмма компонентов.

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

Тест начат 20.09.2021 12:15:16

Тест	Результат	Время	Снимок	Сообщение
S1	Успех	12:15:18	-
S2	Успех	12:15:23	-
S3	Успех	12:15:43	open

Всего тесто запущено: 3 || Успешно: 2 | Провалено: 1 | Процент пройденных тестов: 66% | Тест завершен: 20.09.2021 12:17:35

Рис. 4. Модель отчета.

Отчет представляет собой HTML-таблицу, в первой строке которой размещается время начала тестирования. Первый столбец хранит название тестовых сценариев, второй – отвечает за результат проведения тестирования (Успех и Провал), третий – хранит время воспроизведения тестового сценария, которое привязано к системным часам операционной системы. В четвертый столбец (в случае провала тестирования) выводится ссылка на сделанный в момент возникновения критической ситуации скриншот окна браузера. Последний столбец содержит сообщение, выводимое при возникновении ошибки тестирования. В конце отчета выводится информация об общем количестве проведенных 5

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

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

Атрибут [TestFixture] означает, что все помеченные им классы образуют тестовую структуру.

Атрибут [OneTimeSetUp] означает, что помеченные им классы будут вызываться единожды перед началом тестирования.

Атрибут [OneTimeTearDown] означает, что помеченные им классы будут вызываться единожды после окончания тестирования.

Атрибут [SetUp] означает, что помеченные им классы будут вызываться перед началом каждого теста.

Атрибут [TearDown] означает, что помеченные им классы будут вызываться после окончания каждого теста.

Атрибут [Test] означает, что все помеченные ими классы, являются непосредственно тестами.

Таким образом, проект представляет собой следующую структуру:

[TestFixture]

class Test

{      public static void Main(string[] args){}

[OneTimeSetUp] public void TestFixtureSetUp(){}

[OneTimeTearDown] public void TestFixtureTearDown(){}

[SetUp] public void SetUp(){}

[TearDown] public void TearDown(){}

[Test] public void TEST_1(){}

[Test] public void TEST_2(){} }

Листинг 1. Структура проекта.

public static void Main(string[] args)

{ string path = Assembly.GetExecutingAssembly().Location;

}

Листинг 2. Функция запуска тестов.

Конструирование тест-кейсов. Построение тест-кейсов начинается с объявления используемых глобальных переменных:

public string Sname = Randomizer.CreateRandomizer().GetString(8);

public string Slogin = Randomizer.CreateRandomizer().GetString(10);

public string Sphone =

Randomizer.CreateRandomizer().GetString(9,"1234567890");

public string Spassword = Randomizer.CreateRandomizer().GetString(6);

public string ItemName;

public string ItemCount;

public string OrderItemCount =

Randomizer.CreateRandomizer().GetString(2, "1234567890");

Листинг 3. Объявление глобальных переменных.

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

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

Определяем как указатель переменной типа , принадлежащего пакету . Это позволит нам управлять действиями браузера Google Chrome.

Метод позволяет управлять настройками драйвера, с его помощью устанавливается разрешение окна приложения “На весь экран” и время ожидания до появления следующего элемента в 5 секунд.

[OneTimeSetUp]

public void TestFixtureSetUp()

DirectoryInfo dr = Directory.CreateDirectory(iFolderResultTest);

DirectoryInfo ds = Directory.CreateDirectory(iFolderScreen);

GenerateReport(0, "0", true);

ChromeOptions options = new ChromeOptions();

options.AddArguments("--ignore-certificate-errors");

options.AddArguments("--ignore-ssl-errors");

driver = new ChromeDriver(iWorkDir, options);

Листинг 4. Класс .

Класс имеет вид:

[SetUp]

public void SetUp()

{             driver.Navigate().GoToUrl("http://localhost/");  }

Листинг 5. Класс .

При помощи метода браузер переходит на страницу тестируемого приложения перед запуском каждого теста.

Объектом для проведения тестирования было выбрано web-приложение, созданное студенткой, обучающейся по направлению подготовки «Программная инженерия», и реализующее косметику посредством сети Интернет. Вид главной страницы приложения представлен на рисунке 5:

Рис. 5. Главная страница web-приложения.

Было создано 10 тест-кейсов, выполняющих проверку работоспособности основного функционала web-приложения:

• -    тест-кейс №1 – Проверка прохождения регистрации,

• -    тест-кейс №2 – Проверка прохождения авторизации,

• -    тест-кейс №3 – Проверка правильности отображения меню,

• -    тест-кейс №4 – Проверка правильности отображения товаров,

• -    тест-кейс №5 – Заказ товара,

• -    тест кейс №6 – Поиск товара,

• -    тест-кейс №7 – Проверка покупки повара,

• -    тест-кейс №8 – Проверка товара на складе,

• -    тест-кейс №9 – Редактирование цены товара администратором,

• -    тест-кейс №10 – Проверка совместимости с браузером Internet Explorer.

Подробно рассмотрим создание тестового сценария для тест-кейса №1 – Проверка прохождения регистрации.

Пакет Selenium.WebDriver предоставляет следующие методы взаимодействия с содержимым web-страницы:

Метод находит на странице первый элемент, удовлетворяющий условиям поиска в зависимости от выбранного метода:

• ‒    By.Id() – поиск элемента происходит по наименованию идентифицирующего его

поля Id;

• ‒    By.Name() – поиск элемента происходит по наименованию его поля Name;

• ‒    By.Xpath() – поиск элемента происходит при помощи языка запросов к элементам XML-документа XPATH

Метод производит щелчок левой кнопкой мыши по выбранному элементу.

Метод производит ввод текста в выбранный элемент.

Код тест-сценария №1 имеет вид:

[Test]

public void TEST_1()

{      iTestName = "registration";

try

GenerateReport(1, iTestName, true); iExecTestGood = true; } catch (Exception ex)

• {    GenerateReport(1, iTestName, false, ex.ToString()); iExecTestGood = false; } Assert.True(iExecTestGood); }

Листинг 6. Код тест-сценария №1.

В результате проведения автоматизированного тестирования с помощью разработанной авторами программной системы, был получен отчет, представленный на рисунке 6. На рисунке видно, что «провалены» 4 сценария: Поиск товара, Проверка покупки товара, Проверка товара на складе и Проверка совместимости с браузером Internet Explorer:

Тест начат 20.09.2021 12:15:16

Тест	Результат	Время	С ни мок	Сообщение
Registration	Успех	12:15:18	-
Autorization	Успех	12:15:23	-
ListCount	Успех	12:15:43	-
ItemOnPage Count	Успех	12:16:01	-
	Успех	12:16:18	-
ItemSearch	Провал	12:16:29	open	OpenQAJjelenhnmNoS^^                 no such element: Unable to locate element: {"merit.о delink text","selector":"Juvia^s 5pcs Multicolored Eye Set"} (Session info: chrome=83.0.4103.106) в OpenQA.Selenium.Remote.RemoteWebDriver.UnpackAndThrowOnError(Response .enorR^ в QffenQAJSelenium,Remote.RemQteWebDriyer.Ex.ecute( String driyerComnian.dToExecu.te , Dictionary ! parameters) в QE!31Q&i§£lS3iffl31J?£IlfiS£=33b£Blfi££^                              mechanism. String value) в OpenQA. S el enium .Rem ot e.Rem ot eWeb Driver TindElem ent ByLinkT ext (String linkText) в OpenQA.Seienium.By.<>c_DisplayClass 17_0.b__0(1 SearchContext context) в QpenQA^SeLgrijjmJSyTjnril^                  context) в QE£!lQ^§£l93jjJBlJ?SIlfiJ£=BbH5£££^^                       by) в TESTING_SPACE.Test.TEST_60 в C:\Users\alexp\D esktopXH овал nanKa\Testsl\Program.cs:crpoKa 225
CheckOrder	Провал	12:16:41	o pen	OpenQAfieljmjuimNciS^^                 no such element: Unable to locate element: {"method":"link text","selector":"Juyia‘0s 5pcs Multicolored Eye Set"} в OpenQA. Selenium.Remote. RemoteWeb DriverTindElementByLii^Text ( String linkText) в TESTING_SPACE.Test.TEST_70 в C:\Us егзЫехрЮезкюр'Новая nanKaTestslProgra^        248
Checkitem Count	Провал	12:17:03	o pen	OpenQA..Selenium,NоSuchElem entException : no such element: Unable to locate element: { "m ethod": "xpath", "selector": "/ /artidel l]//child::img"} в QpenQA.Sel.enium;Remote.RemoteWebDriveiyTindEl^                  xpath) в TESTING_SPACE.Test.TEST_80 в C: Us ers'al exp Desktop Новая nanKa\Testsl\Program.cs:cTpoKa 274
Admin Change	Успех	12:17:30	-
Internet ExplorerRun	Провал	12:17:35	o pen	Opeii.QA.Sele^                          Unable to find element with css selector = #logout в Qj> enQA..Selenium. Rem ot e Rem oteWebDriyer Tin dElem ent By Id (String id) в TESTING_SPACE.Test.TEST_100 в C:\Users alexp Desktop Новая папка Tests Г PrpgjaimcsjcipoKa 345

Всего тесто запущено: 10 || У спешно: 6 || Провалено: 4 || Процент пройденных тестов: 60% || Тест завершен: 20.09.2021 12:17:35

Рис. 6. Отчет о прохождении тестирования.

Благодаря сделанным при возникновении ошибки снимкам экрана (см., например, рисунок 7) были выявлены ошибки, сделанные разработчиком при написании кода web- приложения.

Рис. 7. Снимок экрана при возникновении ошибки тест-кейсе № 10.

После устранения выявленных ошибок было проведено повторное тестирование web-приложения, результаты которого представлены на рисунке 8:

Гест начат 20.09.2021 12:15:16

Тест	Результат	Время	Снимок	Сообщение
Registration	Успех	12:15:18	-
Autorization	Успех	12:15:23	-
ListCount	Успех	12:15:43	-
ItemOnPageCount	Успех	12:16:01	-
Order	Успех	12:16:18	-
ItemS earch	Успех	12:16:29	-
CheckOrder	Успех	12:16:41	-
CheckltemC omit	Успех	12:17:03	-
AdminChange	Успех	12:17:30	-
brtemetExplorerRun	Успех	12:17:35	-
Всего тесто запущено: 10 || Успешно: 10 || Провалено: 0				| Процент пройденных тестов: 100% ||

Тест завершен: 20.09.2021 12:1735

Рис. 8. Отчет о повторном прохождении тестирования.

Заключение. В статье рассмотрена реализованная авторами программная система, построенная на базе фреймворка SELENIUM и предназначенная для проведения автоматизированного тестирования web-приложений. Разработанные в системе тест-кейсы могут успешно применяться для тестирования студенческих работ, выполняемых по дисциплине «Разработка web-приложений», а при согласовании с заказчиком и на основе его требований – и для тестирования коммерческих проектов.