CC BY
59
Рисунок 4 - Зависимость величины эффективного радиуса устья МТ частот ультразвуковых колебаний Ю :
/ ^ma
E2 ! E20
для разных 1 - 3-104 с-
2
3,5-104
3
4-104
Заключение
Таким образом, в работе теоретически исследован кавитационный механизм управления качеством поверхностного слоя деталей машин с цепочкой МТ, основанный на звукокапиллярном эффекте с участием НЧ. Выявлена возможность управления эффективным модулем Юнга поверхностного слоя путём соответствующего подбора материала НЧ. Показано, что основной вклад в силу взаимодействия НЧ вносят кластеры НЧ с большой дисперсией их радиуса. Предложена одномерная модель поверхностного слоя металла с цепочкой МТ. Найдено, что в случае достаточно плотной регулярной цепочки МТ эффективный модуль Юнга поверхностного слоя определяется в основном модулем Юнга материала НЧ. Полученные теоретические результаты могут составить основу технологии повышения эффективности шлифования, в том числе и достаточно хрупких материалов.
ЛИТЕРАТУРА
1. Мухин, В. С. Инженерия поверхности деталей машин / В. С. Мухин, А. М. Смыслов //Вестник УГАТУ. - 2009. - Т. 12, №4 (33). - С. 106-112.
2. Bin Shen, Ajay P. Malshe, Parash Kalita, Albert J. Shih. Performance of novel Mo S2 nanopar-ticles based grinding fluids in minimum quantity lubrication grinding — 2008 — V. 36 — p. p. 357364.
3. Долматов, В. Ю. Детонационные наноалмазы: синтез, строение, свойства и применение / В. Ю. Долматов // Успехи химии. - 2007. - Т. 76, №4. - С. 375-397.
4. Андриевский, Р. А. Размерные эффекты в нанокристаллических материалах / Р. А. Андриевский, А. М. Глезер // Механические и физические свойства // Физика металлов и металловедение. - 2000. -Т. 89, № 1. - С. 91-112.
УДК 618.1
Моисеев Д.А., Моисеев А.В.
ФГБОУ ВО «Пензенский государственный университет», Пенза, Россия
АВТОМАТИЗИРОВАННОЕ ТЕСТИРОВАНИЕ BACK-END ФУНКЦИОНАЛА С ПОМОЩЬЮ ПРОГРАММЫ JMETER
Актуальность и цели.
Обеспечение качества любого продукта в настоящее время невозможно переоценить. Для того, чтобы продукт полностью соответствовал всем ожиданиям пользователя, необходимо автоматизировать не только front-end продукта, но и его внутреннюю часть — back-enda.
Материалы и методы.
Для качественного тестирования программного обеспечения необходимо использовать все накопленные знания и методологии тестирования, в том числе тестирование back-enda любого продукта. Для автоматизации такого тестирования успешно используется программа jMeter. Результаты.
Предложенный процесс автоматизации тестирования back-enda программного обеспечения является удобным во многих смыслах. Благодаря автоматизации с помощью программы^ jMeter тестирование нового функционала или исправление старых кейсов удобно и не времязатратно. Адекватность данной схемы тестирования программного обеспечения проверена экспериментально. Выводы.
Автоматизация тестирования back-enda любого продукта является гарантией того, что пользователь или покупатель останутся им довольны. Повышение качество продукции и качественного тестирования является одной из важнейших задач, которая сейчас стоит перед любым производителем. Ключевые слова:
АВТОМАТИЗИРОВАННОЕ ТЕСТИРОВАНИЕ, BACK-END, JMETER, РЕГУЛЯРНЫЕ ВЫРАЖЕНИЯ
Актуальность
Почти все современные web-сайты разрабатываются, используя подход «клиент-сервер» [1]. Суть подхода заключается в том, что есть как бы 2 части сайта. Первая часть - клиентская. Это то, что видит конкретный пользователь у себя в браузере после того, как перешел по адресу сайта. Эту часть можно назвать так же пользовательской. В большинстве случаев эта часть только отображает те данные, которые приходят ей с сервера, отображая их в нужном месте, нужном стиле и в нужном формате. Вторая часть - серверная. По названию можно понять, что эта часть приложения находиться на сервере, единая для всего сайта. В серверную часть поступают все запросы от клиентской части и сервер должен по этому запросу вернуть нужные данные, в нужном формате. Общая схема работы данного подхода приведена на рисунке 1.
Соответственно для корректной работы всего приложения обе его части должны работать корректно. Проверить клиентскую часть немного проще, потому что всегда можно посмотреть, что и как отображается просто, открыв необходимый для тестирования сайт. Тестирование серверной части немного сложнее, потому что мы не можем
без дополнительных усилий увидеть какие данные на сервер пришли, и какие он отдал.
Рисунок 1 - Архитектура «Клиент-сервер»
Именно поэтому для тестирования серверной части (или back-endа[4], как мы будем называть ее дальше) периодически используются внешние программы или утилиты. Наиболее удобной программой для себя я считаю программу jMeter. Именно о тестировании с помощью этой программы я и хочу рассказать. Так как взаимодействие двух приложений меду собой всегда происходит через back-
от
1.
1.
1
с
1]
end, то и интеграционные тесты весьма эффективны с помощью программы jMeter.
Работа серверной части (back-and части приложения)
Общение между front-end[4] (клиентской части) и back-and (серверной части) происходит с помощью запросов. В момент, когда пользователь вызывает какой-либо функционал, которые требует обработки на сервере, на сервер уходит запрос с нужными данными. Пример такого запроса: http://{сервер}/auth/login
Этот запрос обрабатывается сервером и возвращает на front ответ с нужными данными. Пример ответа от сервера:
{"code":200," message": null," data": {Данные, которые пришли от сервера}
Соответственно для корректного тестирования back-enda[4] надо проверять и запросы, которые туда уходят и ответы, которые сервер возвращает.
Взаимодействие компонентов front-end и backend может осуществляться с помощью нескольких архитектур[4]. Самые популярные архитектуры это: REST[2] SOAP[3]
Так как именно первый сейчас используется в большей степени, то тестирование web-сайта именно с этой архитектурой мы и рассмотрим.
Архитектура REST позволяет передавать не только запрос и тело запроса, но и идентификатор запроса. Идентификаторы запроса бывают следующими:
GET — получение ресурса POST — создание ресурса PUT — обновление ресурса DELETE — удаление ресурса
Таким образом полный запрос будет выглядеть так:
POST http://{сервер}/auth/login Программа jMeter
Для тестирования back-enda любого сайта существует огромное множество различных программ.
Самые популярные из них это программы, которые позволяют отправлять нужный запрос с необходимыми данными на проверяемый сайт. Это такие программы как Postman, Fiddler, Rested (плагин для Google Chrome) и другие. Они все обладают достаточно мощным инструментарием для отправки запросов, однако у них есть существенный минус. В них нельзя выстроить последовательные вызовы запросов. Таким образом в них не получиться написать полноценный сценарий тестирования back-enda, который, например, можно просто запустить раз в регресс. Именно из-за этого минуса я и решил для этих целей использовать программу jMeter.
Программа jMeter изначально была разработана для проведения нагрузочных тестов. Ее смысл в том, что она по заданному сценарию и параметрам с помощью запросов генерирует необходимую для проверки пользовательскую активность на сайт. Однако, для проверки именно сервисных тестов достаточно сгенерировать нагрузку одного пользователя, который будет проверять всю функциональность сайта. Именно возможность выстраивания последовательных тестов и последовательного вызова разных запросов друг за другом является ключевым параметром при выборе jMeter именно для проверки back-end кода сайта.
Примеры проверки back-enda с помощью программы jMeter
Для того, чтобы наглядно показать все преимущество и удобство тестирования именно с помощью этой программы приведу несколько примеров.
В первом примере рассмотрим проверку запроса на поиск информации в цифровой системе google.
Для этого я в программе jMeter создал группу тестов с помощью компонента thread group с названием «Гугл тест», и в нем создал http request «Запрос на поиск». Так же я добавил инструмент, с помощью которого можно следить за успешностью/не успешностью пройденных тестов view result tree. В программе это выглядит так
Рисунок 2 - Интерфейс программы jMeter с добавленными компонентам thread group, http request,
view result tree
Стоит остановиться на параметрах компонента http request. Основные параметры, которые нам понадобятся:
Server Name or IP
Method
Path
Name
Server Name or IP - сюда надо вставить непосредственно IP или адрес сайта, который мы собираемся тестировать. В нашем случае это «www.google.com»
Method - этот параметр отвечает за идентификатор запроса, который мы хотим отправить
(GET/POST/PUT/DELETE). В нашем случае это Get запрос.
Path - дополнительная часть запроса, которая в основном используется для указания параметров запроса. В нашем случае это
«search?newwindow=1&hl=ru&source=hp&ei=9ubpWpyU NaGy6ATTwaCYAg&q=%D1%82%D0%B5%D1%81%D1%82%D0%B8 %D1%8 0%D0%BE%D0%B2%D0%B0%D0%BD%D0%B8%D0%B5&oq=% D1%82%D0%B5%D1%81%D1%82%D0%B8%D1%8 0%D0%BE%D0%B2 %D0%B0%D0%BD%D0%B8%D0%B5» ( Параметры взяты из реального запроса в google).
Name - Имя http request. В нашем случае «Запрос на поиск»
Рисунок 3 Интерфейс компонента http request c заполненными параметрами
Теперь, когда запрос написан надо добавить проверки, через которые мы убедимся, что наш запрос отобразился корректно. Для этого в компонент http request добавим так называемые Listeners, то есть слушателей. Допустим, что для этой проверки нам надо, что бы в ответе на запрос было слово «тестирование», потому что именно по этому слову мы и выполняем запрос и сам он выполнялся не дольше 1 секунды. Добавим компоненты Response Assertion (сравнение ответа) и Duration Assertion (сравнение длительности). В Response Assertion добавим слово тестирование, а в Duration Assertion добавим 1000 мс.
Теперь необходимо запустить наш тест. Зайдем в меню Run и нажмем там Start. Что бы проследить за процессом выполнения тестов необходимо нажать на компонент view result tree. Там мы увидим наши тесты и там же можно проверить прошли они или нет. Если мы запустим с теми параметрами, которые мы указали выше, то тест должен быть пройден.
Если же мы допустим в response assertion введем, например, слово «суп» или в duration assertion 10 мс, то мы увидим, что наш тест будет отображаться как не пройденный.
Еще одним замечательный свойством jMeter является то, что из ответа любого запроса с помощью переменных можно вытащить любую информацию. Это бывает очень полезно для того, чтобы выстроить тест план, в котором для проверки подставляются не стандартные данные, а либо случайные данные, либо данные, которые пришли с предыдущих запросах. В следующем примере мы проверим, что в ответе на запрос в google по слову «Тестирование» будет ссылка на сайт www.protesting.ru. Для этого в запрос мы добавим компонент Regular Expression Extractor, который с помощью регулярного выражения запишет в нужную нам переменную из ответа нужный сайт.
Рисунок 4 - Интерфейс компонента Response Assertion c заполненными параметрами
Рисунок 5 - Интерфейс компонента Duration Assertion c заполненными параметрами
Рисунок 6 - Интерфейс компонента Regular Expression Extractor c заполненными параметрами
/ Apache JMeter (3.3 MB0B647) — U
Рисунок 6 -. Интерфейс компонента http request для перехода на protesting c заполненными
параметрами
Теперь добавим еще один http request, где в нашу переменную, в которой будет содержаться свойстве server name напишем оставшаяся часть адреса на нужную страницу.
«www.protesting.ru», а в свойство path добавим
Теперь нажнем на Run-Start и перейдя в компонент view result tree убедимся, что запрос корректно отработал, отобразив нужный сайт.
В данной статье мы рассмотрели, что такое back-end и front-end web - сайтов. Рассказали про наиболее популярные архитектуры для написания back-enda проекта. Выяснили для чего именно тестировать back-end и почему это является очень
важным. Рассмотрели несколько самых популярных инструментов для тестирования сервисов, выделили их отрицательные стороны и выделили положительные стороны программы jMeter. Так же рассмотрели примеры такого тестирования в программе jMeter останавливаясь на положительных сторонах данной программы.
1
25 с 2
3
4
ЛИТЕРАТУРА
Валерий Коржов. Многоуровневые системы клиент-сервер. Издательство «Открытые системы», 1997,
Джон Фландерс. Введение в службы RESTful с использованием WCF. MSDN Magazine, 2009, 105 с. Бенот Маршал, "Soapbox: почему я использую SOAP", IBM, 2001, 13 с.
Бин Мухаммад, Рашид. "Примечание операционных систем", Kent State University, 2016, 239 с.
УДК 004.942
Старостин1 И.Е. , Степанкин2 А. Г.
1ООО «Экспериментальная мастерская «НаукаСофт», Москва, Россия
2Федеральное государственное унитарное предприятие «Научно-исследовательский институт стандартизации и унификации», Москва, Россия
КОМПЬЮТЕРНАЯ РЕАЛИЗАЦИЯ МЕТОДОВ СОВРЕМЕННОЙ НЕРАВНОВЕСНОЙ ТЕРМОДИНАМИКИ В ВИДЕ ПРОГРАММНОГО МОДУЛЯ
Моделирование и анализ реальных физико-химических систем является важнейшей задачей, имеющей практическое применение. Однако ввиду большого количества реальных физико-химических процессов в реальных технических системах очевидна сложность задач моделирования реальных физико-химических систем. Этим и обусловлена необходимость компьютерной реализации методов современной неравновесной термодинамики, являющимся макроскопическим подходом анализа и моделирования динамики реальных физико-химических систем. Этот подход имеет практическое применение. Ранее авторами в рамках современной неравновесной термодинамики был разработан потенциально-потоковый формализм построения системы уравнений, описывающий физико-химические процессы в произвольной заданной физико-химической системе. Этот формализм применим в общем случае макроскопических физико-химических систем, в том числе и технических объектов, характеризующихся протеканием в них физико-химических процессов, живых клеток, процессов в природе. Поэтому в настоящей работе речь пойдет о компьютерной реализации методов современной неравновесной термодинамики, в том числе и потенциально-потокового формализма. Эта реализация представляет собой библиотеку, которая может быть расширена до модулей расширения моделирующих пакетов (MatLab, Comcol Multiphysics, LabView, и т. д.).
Ключевые слова:
ФИЗИКО-ХИМИЧЕСКИЕ ПРОЦЕССЫ, СОВРЕМЕННАЯ НЕРАВНОВЕСНАЯ ТЕРМОДИНАМИКА, ПОТЕНЦИАЛЬНО-ПОТОКОВЫЙ МЕТОД, ПРОГРАММНАЯ РЕАЛИЗАЦИЯ, БИБЛИОТЕКА РАСШИРЕНИЯ
Моделирование и анализ динамики реальных физико-химических процессов является важнейшей задачей, имеющей практическое значение для проектирования, управления, диагностики технических систем, анализе физико-химических процессов в природе и в живых организмах. Для описания и математического моделирования этих подходов в общем случае может быть использована современная неравновесная термодинамика (макроскопический подход описания реальных физико-химических процессов) [1 - 5], которая имеет широкое практическое применение [1 - 4].
В работе [5] разработан в рамках современной неравновесной термодинамики формализм описания в общем случае реальных физико-химических процессов. В соответствие с этим формализмом формируется список этих процессов, записываются уравнения баланса этих процессов, определяются через потенциалы взаимодействия термодинамические силы, движущие эти процессы, а также кинетическая матрица - шкала кинетических свойств неравновесных систем [5]. Зная термодинамические силы и кинетические свойства, определяются скорости протекания физико-химических процессов, а затем скорости изменения координат состояния [5]. Так получается система дифференциальных уравнений, описывающая реальные процессы. Эта система решается методами, описанными в [6, 7].
Однако реальные системы (технические системы, живые клетки, природные системы, и т.д.) являются сложными системами. Поэтому компьютерная реализация формализма описания физико-химических процессов, изложенного в [5], является актуальной задачей. В настоящее время существует множество информационных систем, позволяющих выполнять математические расчеты по заданным уравнениям (например, MatLab, Scilab, Python) [8, 9], имитировать системы (например, Simulink, Scicos, Xcos) [10]. К этим системам можно подключать модули расширения, позволяющие решать те или иные задачи [8 - 10]. Однако среди этих модулей расширения отсутствуют модули, реализующие формализм, описанный в [5]. Поэтому целью этой статьи - разработка архитектуры модуля, реализующего этот формализм.
Система классов, реализующая формализм современной неравновесной термодинамики
Рассматриваемая в настоящей работе библиотека, реализующая формализм современной неравновесной термодинамики, описанный в [5], представляет собой библиотеку классов. Каждый класс библиотеки представляет собой реализацию сущностей современной неравновесной термодинамики [1 - 5].
С точки зрения программирования структура расчетной схемы произвольной физико-химической представляет собой соответствующий структурный тип данных (на языке программирования С (Си) это структура, на С++ - это класс), показанный на рисунке 1.
Структурные типы данных координат состояния и энергетических степеней свободы, входящие в структурный тип данных физико-химической системы (рисунок 1), показаны на рисунке 2. Структурный тип данных энергетических степеней свободы имеет массив ссылок на скорости изменения соответствующих координат состояния (рисунок 2б), входящих в структурный тип данных координат состояния (рисунок 2а). Структурные типы данных процессов (кроме процессов теплообмена), входящие в структурный тип данных физико-химических систем (рисунок 1), имеют массивы ссылок (рисунок 3в) на: термодинамические силы перекрестных процессов;
скорости изменения сопряженных координат состояния и суммарные потенциалы взаимодействия, обусловленные энергетическим взаимодействием между подфазами [5], сопряженные этим координатам состояния;
температуры и скорости сообщения теплоты каждой сопряженной энергетической степени свободы, а также на потенциалы взаимодействия сопряженных энергетический степеней свободы, сопряженных соответствующим сопряженным процессу координатам состояния.
В типе данных процессов ссылки на сопряженные процессу потенциалы взаимодействия и координаты состояния входят в структурный тип данных сопряженных координат состояния (рисунок 3а).
