CC BY
0Научная статья УДК 004.415.53
doi:10.24151/1561-5405-2023-28-5-687-699 EDN: XVMGMA
Метод автоматизированного тестирования устройств потребительской электроники с помощью удаленного вызова процедур и облачных сервисов
Л. Г. Гагарина, А. В. Букарев
Национальный исследовательский университет «МИЭТ», г. Москва, Россия
anton@bukarev.org
Аннотация. В настоящее время, согласно данным аналитических агентств TAdviser и Statista, при автоматизированном производстве потребительской электроники количество ошибок ежегодно увеличивается на 24 %, что представляет собой актуальную проблему. Существующие методы и средства организации процесса тестирования программного обеспечения при автоматизированном производстве потребительской электроники недостаточно эффективны. Несмотря на то что облачные технологии улучшают процесс разработки программного обеспечения, технические аспекты тестирования еще не полностью изучены. В работе представлен метод дистанционного автоматизированного тестирования программного обеспечения устройств потребительской электроники с использованием удаленного вызова процедур Remote Procedure Call (RPC) с целью улучшить процесс, сэкономить ресурсы и увеличить масштабируемость. Исследование охватывает анализ существующих архитектурных решений, разработку модели процесса тестирования с помощью теории массового обслуживания и метода Монте-Карло. В рамках практического эксперимента создан и применен диспетчер задач, эффективно регулирующий процесс тестирования программного обеспечения устройств потребительской электроники в облачном сервисе, что позволило интегрировать существующие методы тестирования без необходимости модификации их конструкции. Такой подход способствует оптимизации процесса, уменьшению временных затрат и подтверждает успешное применение предложенного метода.
Ключевые слова: автоматизированное тестирование программного обеспечения, диспетчер задач, облачные устройства, модульное тестирование
Для цитирования: Гагарина Л. Г., Букарев А. В. Метод автоматизированного тестирования устройств потребительской электроники с помощью удаленного вызова процедур и облачных сервисов // Изв. вузов. Электроника. 2023. Т. 28. № 5. С. 687-699. https://doi.org/10.24151/1561-5405-2023-28-5-687-699. - EDN: XVMGMA.
© Л. Г. Гагарина, А. В. Букарев, 2023
Original article
A method for automated testing of consumer electronics devices using remote procedure calls and cloud services
L. G. Gagarina, A. V. Bukarev
National Research University of Electronic Technology, Moscow, Russia anton@bukarev.org
Abstract. In recent times, according to data from TAdviser and Statista think tanks, there is a pressing issue of a 24 % annual increase in errors in automated electronics production. Existing methods and tools for software testing organization at automated production of consumer electronics fail to achieve optimum effect. Despite cloud technologies enhancing the software development process, the technical aspects of testing are not yet fully explored. In this work, a method of remote automated testing for software of consumer electronics devices using Remote Procedure Call (RPC) is presented, aimed at improving the process, conserving resources, and increasing scalability. The study covers the analysis of existing architectural solutions and the development of a testing process model using queueing theory and the Monte Carlo method. Within the practical experiment, a task dispatcher has been designed and applied, efficiently regulating the software testing process for consumer electronics devices in a cloud service, which has allowed for the integration of existing testing methods without needing to modify their structure. This approach contributes to process optimization, reduces time expenses, and confirms the successful application of the proposed method.
Keywords: automated software testing, task dispatcher, cloud devices, mobile devices, unit testing
For citation: Gagarina L. G., Bukarev A. V. A method for automated testing of consumer electronics devices using remote procedure calls and cloud services. Proc. Univ. Electronics, 2023, vol. 28, no. 5, pp. 687-699. https://doi.org/10.24151/1561-5405-2023-28-5-687-699. - EDN: XVMGMA.
Введение. По оценкам аналитических агентств TAdviser и Statista, на потребительскую электронику (ПЭ) в мире, включая такие категории, как телевизоры, ТВ-приставки, домашние аудиосистемы, Bluetooth-колонки, игровые консоли, цифровые камеры, видеокамеры, дроны, автомобильные мультимедиа и пр., в 2022 г. было потрачено 2,2 трлн евро. В 2023 г. спрос на новые модели данной электроники сохраняется [1, 2]. Однако существующие в настоящее время методы и средства организации процесса тестирования программного обеспечения (ПО) при автоматизированном производстве ПЭ недостаточно эффективны, что, по оценкам аналитических агентств, приводит ежегодно к росту обнаружения программных ошибок на этапе эксплуатации ПО в среднем на 24 %.
Известно, что жизненный цикл разработки ПО эффективнее при применении облачных технологий и сервисов, которые выполняют ряд функций, направленных на анализ процесса тестирования как архитектурного атрибута. Такой подход позволяет гарантировать более глубокое и детальное тестирование. Следует отметить, что прово-
димые исследования в этой области посвящены использованию подхода высокоуровневого проектирования архитектуры ПО, технические аспекты процессов тестирования оставлены без внимания [3, 4]. Таким образом, задача эффективной организации распределенного тестирования ПО с применением облачных сервисов и разработки специализированных моделей, методов и алгоритмов актуальна.
В настоящей работе на основе анализа существующих архитектурных решений разрабатывается улучшенный метод запуска дистанционных автоматизированных тестов с использованием вызова удаленных процедур (Remote Procedure Call, RPC). Цель работы - создание эффективной и универсальной системы для автоматизированного тестирования ПО c помощью моделирования процессов тестирования, которая сократит время и ресурсы, затрачиваемые на выполнение тестовых сценариев, и обеспечит более высокую степень масштабируемости и адаптивности к различным тестируемым платформам и библиотекам. Отличительная особенность разрабатываемого диспетчера задач заключается в возможности проведения автоматизированного тестирования большого количества устройств без необходимости внесения значительных изменений в существующую инфраструктуру тестирования. Для этого используются системный подход к моделированию сложных систем, основные принципы кибернетики и общей теории систем.
Разработка метода дистанционного автоматизированного тестирования ПО.
Этапы тестирования ПО на протяжении его жизненного цикла занимают примерно 60 % всего процесса разработки [5]. Под эффективностью производственных процессов в данном случае понимается возможность их выполнения за минимальное время T. Говоря об эффективности этапа тестирования, время T зависит от количества устройств тестирования U, количества членов команды K, вероятности некорректного выполнения теста E по причине как человеческого фактора, так и программного сбоя. Взаимосвязь между параметрами определяется функцией T=f (U, K, E (U, K)), отвечающей
следующим свойствам:
- чем больше устройств тестирования, тем больше время выполнения тестирова-
df a ния: > 0;
dU
df n
- параллельное выполнение тестирования позволяет ускорить процесс: -< 0 ;
dK
r dE (U, K)
- при увеличении численности команды растет вероятность ошибок: ---- > 0;
dK
dE (U, K )
- найденные ошибки увеличивают время тестирования: ---- > 0.
dT
Точный вид функций T и E специфичен для каждого проекта, поскольку следует учитывать программные и аппаратные особенности устройств, сложности задач, вследствие которых значительно повышается трудоемкость тестирования.
Тестирование всех возможных комбинаций программных компонентов ПО является непростой задачей, так как различные категории ПЭ могут иметь разные версии драйверов и прикладного ПО [6, 7]. Количество возможных комбинаций в случае сборки отдельно взятой категории ПЭ из взаимозаменяемых блоков равно:
Nc = HDS у,
где H - количество вариантов аппаратного обеспечения; D - количество вариантов драйверов и ^-версий ПО, использующего эти драйвера; у - эмпирический понижающий коэффициент, применение которого обусловлено тем фактом, что на практике редко встречаются все возможные комбинации.
Тем не менее число вариаций программных компонентов ПЭ может превышать 100, что обусловливает необходимость повышения эффективности тестирования, т. е. совершенствования существующих алгоритмов и методов тестирования программной составляющей ПЭ в процессе разработки.
Предлагаемые диспетчер задач и агент для запуска тестирования ПО позволяют проводить дистанционное тестирование с использованием облачных сервисов, что дает следующие значимые преимущества:
- тестируемое ПО понятно для программистов и аналогично тестированию на физическом устройстве;
- отсутствует необходимость подготовки, запуска и сбора результатов тестирования каждой вариации версии программного компонента любой категории ПЭ в отдельности (этот процесс автоматически обобщается в единое целое).
Кластер, состоящий из управляющего сервера - диспетчера задач, серверов устройств и устройств, изображен на рис. 1.
Рис. 1. Структурное представление марковской модели неоднородного кластера с общим доступом
к устройствам тестирования Fig. 1. Structural representation of the Markov model for a heterogeneous cluster with shared access
to testing devices
Входной узел представляет собой управляющий сервер, который действует как диспетчер задач, распределяя тесты между серверами устройств (N1 в общем количестве), имеющими разный функционал. Каждый сервер общается с устройствами тестирования, число которых составляет N2. В начале процесса тестирования число всех тестов определено как M.
Рассмотрим дискретную модель Маркова для данной системы массового обслуживания. Если представить устройства тестирования как однородные, то их можно принять в качестве многоканального устройства. Тесты размещаются в очереди с ограниченным размером, который не превосходит M. Обозначим время, необходимое для обработки тестовых сценариев на серверах и устройствах, Ti. Оно следует геометриче-
х
скому распределению со средним значением для каждого i = 1 ...N + N2 +1; qi =— -
вероятность завершения обработки тестового сценария на серверах и тестирующих устройствах для i в указанном диапазоне; ri = 1 - qi - вероятность того, что обработка теста будет продолжаться на входном узле, серверах или в комплексе устройств, где i = 1...М + N2 + 1.
Для создания матрицы переходов т = (пг1,т2,...,ты+ы+1^ рассмотрим размещение
M тестов на N серверах, где mi - количество задач в /-м сервере. Проанализируем воз-
г * 1
можные состояния. Представим множество состояний как 5 = !(щ,ш2,щ= М к
N
Количество состояний системы для одинакового количества задач ] = ^от. соответст-
г=1
вует количеству размещений ] задач на N серверах и определяется формулой Ь ■ = . Общий объем состояний задач на серверах рассчитывается по формуле
М
]=о
Вектор к =(к1,к2,...,км+м+1^ описывает устройства, взаимодействующие с релевантным сервером. Для определения вектора стационарных вероятностей состояний й = (л0, ,..., лм ) необходимо решить систему равенств
л=Zj j=i-L -1
j=i
L
Z = 1,
относящуюся к рассматриваемой модели кластера, где л/ - вероятность обнаружения системы в /-м состоянии. Стационарные вероятности позволяют устанавливать средние показатели временных характеристик обслуживания и загрузки серверов и устройств. Для расчета ключевых параметров определим множество Л = {^\0 =< Щ {})< к },
где I е {1, Ь} - номера состояния, ^ е{1, *} - номера узла кластера. Множество Л3
включает в себя номера состояний, где в 5-м узле обработки расположено меньше к задач.
Приведем пример расчета усредненных характеристик системы:
- количество свободных устройств 5-го узла в состоянии I - (к - ш[), I е Л;
- количество занятых серверов и устройств в 5-м узле кР = к - к - Щ (1)) Л;
¡еЛ,
количество незанятых серверов и устройств в 5-м узле ^ (к - Щ (I)) Л ;
1еЛ,
К
загрузка серверов рх = —
к.
cp
Ь
- количество тестовых сценариев в 5-м узле ш^р = (I) л1;
i=1
- количество тестовых сценариев в статусе ожидания = ш^р — рж к;
S S
mcp
длительность нахождения тестового сценария us =
Psт / q
<
i=i
- время задержки обработки тестового сценария = 1
р,т / q
N
- время тестового сценария, проведенное в вычислительной системе и = ;
«=1
N
- время задержки выполнения тестового сценария Ж = ^сол.
^=1
При соблюдении ряда условий, означающих долговременную непрерывность рассматриваемого процесса, соответствующие формулы будут справедливы. В случае возникновения каких-либо технологических перерывов значимого времени начала и окончания процесса тестирования реструктуризации и модификаций этого процесса более точные результаты могут быть получены методами имитационного моделирования с применением разработанного ПО для моделирования.
Дальнейшие этапы жизненного цикла ПО предусматривают поэтапный отказ от использования ранних модификаций ввиду их морального устаревания. Одновременно с этим происходит процесс модернизации как программной, так и аппаратной части в каждой категории ПЭ, что требует увеличения объема и модернизации тестовых сценариев. Таким образом, объем тестируемых реализаций сначала возрастает, достигая своего максимума в первой четверти жизненного цикла ПО, затем становится менее интенсивным. При отсутствии конкретных сведений о количестве версий программно-аппаратной реализации категории ПЭ, для которого разрабатывается тестируемое ПО, потенциально возможное количество оценивается с использованием комбинаторной комбинации «сочетание без повторений» [8, 9]. Это обусловлено тем, что рынок компонентов ПЭ представлен широким набором технически совместимых модулей с практически идентичными характеристиками, а при формировании продукта выбирается некоторое подмножество таких компонентов. Для построения модели, позволяющей получить количественные оценки необходимых ресурсов и затраченного времени, проанализированы шаги ручного и автоматизированного тестирования, а также автоматизированного тестирования с помощью прототипа с последующим представлением в виде набора не связанных между собой одно- и многоканальных систем массового обслуживания (СМО), которые взаимодействуют между собой посредством очередей и учитывают параметры, описанные на рис. 2 и рис. 3.
Приведем описание блоков, представленных на рис. 2:
- блок 1 - установка входных параметров алгоритма моделирования, где Sa - количество функций интерфейса ПО, подлежащих тестированию; Sd - количество моделей ПЭ, предназначенных для проверки; Dmax - верхний предел устройств, тестируемых одновременно; Emax - наибольшее количество инженеров; R - число итераций моделирования;
- блок 2 - инициализация счетчика проведенных тестов;
- блок 3 - проверка значения счетчика шагов по методу Монте-Карло;
- блок 4 - формирование входных коэффициентов k для блока 5;
- блок 5 - определение параметров системы массового обслуживания на ]-м этапе метода Монте-Карло (подробное изображение этого блока приведено на рис. 3);
- блок 6 - инкрементирование счетчика количества испытаний;
- блок 7 - расчет средних значений характеристик системы массового обслуживания.
Рис. 2. Схема алгоритма моделирования нестационарной СМО процесса тестирования ПО устройств ПЭ Fig. 2. Algorithm scheme for modeling the non-stationary queuing system of the software testing process for electronic devices
Приведем описание блоков, представленных на рис. 3:
- блок 0 - задание значений входных параметров алгоритма;
- блок 1 - расчет необходимого количества инженеров:
(
S„ = min
max
S„
S„
ran
d (a, b У rand (c, d)
где a, c и Ь, d - соответственно минимальное и максимальное количество функций, используемых в тестовых сценариях для устройств ПЭ.
Рис. 3. Детализация блока 5 процесса тестирования ПО устройств ПЭ Fig. 3. Detailing of the fifth block of the software testing process model for electronic devices
Время шага имеет вид
T (F, D, Emax, Sf , SD ) = ku
FKl SF
E
max+k13 ( Dkl-4 SD )
E
max
здесь SF - сложность функций (это может быть среднее значение или сумма индивидуальных сложностей всех функций); k1,1, k1,2, k1,3, k1,4 - коэффициенты, определяемые на основе статистических данных процесса разработки;
- блок 2 - расчет количества тестовых сценариев:
Q (Sa , Sd ) = Sa (l + (l - kl ) Sd )
и времени выполнения шага:
T2 ( Sa , Sd )= k,/2^+Sd) ,
где k21, k22, k23 - коэффициенты, определяемые на основе статистических данных процесса разработки;
- блок 3 - расчет времени, необходимого для описания тестовых сценариев:
T3 (Q, Sa, Se )=гапё(кзД, кз,2)-QA
5
где к3,1, к3,2 - коэффициенты, определяющие время, необходимое для описания одного тестового сценария;
- блок 4 - расчет времени, необходимого для кодирования тестовых сценариев:
ОА
T4 ( Qc , Sa , Se , Sc ) = k4,1Sc C "
S„ '
где Sc - усредненное значение сложности всех тестовых сценариев, рассчитываемое по
1 Qc
формуле Sc = ~ZSci, где Qc - количество тестовых сценариев; «tl
- блок 5 - расчет времени, необходимого для кодирования тестовых сценариев:
T5(Qc) = ZZrand(1,10)^case,
i=0
где tcase - время сборки тестового сценария, использующего одну функцию;
- блок 6 - инициализация цикла тестирования;
- блок 7 - расчет времени тестирования:
(Qt ) ^
case / т-ч
T (Qc,Sd,Se,Ds ) =---^ + BSdtB,
где B - доля устройств, которые выходят из строя и требуют дополнительного времени (по статистике, вероятность выхода устройств составляет 10 %); tB - дополнительное
время, необходимое для обработки устройства, вышедшего из строя (по статистике, данная операция занимает в среднем 30 мин);
- блок 8 - инкремент счетчика устройств;
- блок 9 - проверка статуса процесса тестирования. Если все тестовые сценарии выполнены на всех устройствах, то тестирование завершается;
- блок 10 - расчет необходимого времени для подготовки отчета по тестированию:
Qt
л-^c case
To ( Qc, Se )=-
S„
где tcase - коэффициент, отражающий время, требуемое для подготовки отчета по одному тестовому сценарию;
- блок 11 - расчет времени для анализа отчета:
а
^(ш=Ъапй (и, о,
1=0
где и ^ах - минимальное и максимальное время, необходимое для проведения анализа пунктов отчета;
- блок 12 - принятие решения о доработках ПО либо о завершении тестирования;
- блок 13 - доработка тестируемого ПО. Время выполнения рассчитывается по формуле
T =
T13
Cerrors (1 + Qc (¿13,2 " *13,1 ))
1 - Qc k13,1
где k13j, k13,2 - коэффициенты, определяемые на основе статистических данных процесса тестирования;
- блок 14 - принятие решения о необходимости доработки тестовых сценариев;
- блок 15 - принятие решения о необходимости доработки прототипа;
- блок 16 - расчет размера прототипа: S = £161 log (Sa) + k162 и расчет времени выполнения шага: Tl6 =k163S , где k161, k16,2, k16,3 - коэффициенты, определяемые на основе статистических данных процесса тестирования;
- блок 17 - расчет времени сборки прототипа: TX1 (S ) = Spkl, где k17 - коэффициент, определяемый на основе статистических данных процесса тестирования.
Анализ результатов моделирования. Результаты для этапа тестирования при моделировании в случае R = 1 000 000 представлены на рис. 4. Анализируя рисунок, можно сделать вывод, что в результате моделирования в случае модульного тестирования переподключение устройств и исправление ошибок при подключении в среднем занимает 5,3 ч, для автоматизированного тестирования - 13,7 ч. Это существенно при регулярном проведении тестирования. Указанные этапы зависят от технической инфраструктуры, и возможность их улучшения заключается в применении усовершенствованных методов и инструментов для запуска тестов. В качестве улучшенного метода предлагается запуск автоматизированного тестирования с помощью RPC. Данный подход позволяет выделить тестируемое ПО в отдельный модуль в целях сокращения накладных расходов [10, 11].
Рис. 4. Время выполнения шагов тестирования Fig. 4. Time to perform steps in the testing
Проведено моделирование рассмотренных методов тестирования с последующим сравнением результатов с практическими значениями. Результаты представлены на рис. 5. Из рисунка видно, что ручное тестирование занимает наибольшее количество времени ввиду особенностей этого метода. Определение затрачиваемого на ручное тестирование времени дает возможность оценить точность модели. Полученные результаты показали, что погрешность моделирования составляет около 16 %. Такая погрешность обусловлена влиянием человеческого фактора и технических аспектов.
Рис. 5. Время выполнения ручного, модульного и автоматизированного тестирования Fig. 5. Time to perform manual, modular and automated testing
При сравнении модульного и автоматизированного тестирования разница между практическими результатами и моделированными показателями незначительна. Это свидетельствует о высокой точности разработанной модели и указывает на возможность использования полученных результатов для последующего улучшения процесса тестирования. Тестирование с применением RPC-метода (см. рис. 5) в среднем занимает на 45 % меньше времени для выбранной конфигурации тестовой среды.
Заключение. В рамках практического эксперимента успешно создан и применен диспетчер задач, который эффективно регулирует процесс тестирования ПО устройств ПЭ, размещенных в облачном сервисе. Такой подход позволяет интегрировать существующие методы автоматизированного тестирования без необходимости вносить значительные изменения в их конструкцию. В результате достигается оптимизация процесса тестирования и значительное уменьшение временных расходов.
Результаты исследования демонстрируют успешное применение предложенного метода, что способствует повышению эффективности процесса тестирования.
Литература
1. TAdviser: Государство. Бизнес. Технологии [Электронный ресурс]. URL: https://www.tadviser.ru (дата обращения: 01.08.2023).
2. Statista [Электронный ресурс]. URL: https://www.statista.com (дата обращения: 01.08.2023).
3. Гагарина Л. Г., Шевнина Ю. С. Моделирование цифрового двойника производственного процесса с использованием смарт-структуры // Системы компьютерной математики и их приложения. 2022. № 23. С. 84-90. EDN: UEMIYJ.
4. Веселов В. Ф., Гагарина Л. Г. Эмулятор вычислительного устройства с абсолютной точностью вычислений // Системы компьютерной математики и их приложения. 2022. № 23. С. 70-78. EDN: GTNYZV
5. Мухутдинов Р. А., Мухутдинов А. А., Коняева О. С. CI/CD системы // Студенческий вестник. 2020. № 19-10 (117). С. 69-70. EDN: QGTKEQ.
6. Карышев А. А., Ромашов П. А. Система для автоматизации ручного тестирования программного обеспечения // Электронный журнал: наука, техника и образование. 2016. № 2 (6). С. 140-146. EDN: WPNCXJ. URL: http://nto-joumal.ru/uploads/articles/7a1f6e69f918d40ce7a55504eb1ff4af.pdf (дата обращения: 28.08.2023).
7. Михальчук В. Д., Решетникова И. В. Использование ручного и автоматизированного тестирования ПО в гибких методологиях проектирования // Современные инструментальные системы, информационные технологии и инновации: сб. науч. тр. XV Междунар. науч.-практ. конф. (Курск, 19-20 марта 2020 г.). Курск: Юго-Западный государственный университет, 2020. С. 203-207. EDN: LSATBQ.
8. Данилова А. А., Майорова Е. С. Обзор патентной информации и источников периодической печати по теме: «Анализ автоматизированных систем тестирования программного обеспечения» // Современные тенденции развития науки и технологий. 2016. № 7-2. С. 22-26. EDN: WHDBAL.
9. Тютюных А. А., Полевщиков И. С. Разработка автоматизированной системы управления процессом тестирования программного обеспечения // Автоматизированные системы управления и информационные технологии: материалы Всерос. науч.-техн. конф. (Пермь, 17 мая 2018 г.): в 2 т. Пермь: Изд-во Пермского нац. исслед. политехнического ун-та, 2018. Т. 1. С. 104-109. EDN: YVAQHB.
10. Филиппов В. А., Хатько Е. Е. Проблемы качества тестирования программного обеспечения для мультизадачных пользовательских комплексов // Качество. Инновации. Образование. 2011. № 3 (70). С. 32-35. EDN: ONDBML.
11. Гридин В. Н., Дмитревич Г. Д., Анисимов Д. А. Методика построения веб-сервисов распределенных платформенно-независимых систем автоматизированного проектирования // Системы и средства информатики. 2014. Т. 24. № 1. С. 213-223. https://doi.org/10.14357/08696527140113. - EDN: SJHVPJ.
Статья поступила в редакцию 27.07.2023 г.; одобрена после рецензирования 04.08.2023 г.;
принята к публикации 08.08.2023 г.
Информация об авторах
Гагарина Лариса Геннадьевна - доктор технических наук, профессор, директор Института системной и программной инженерии и информационных технологий Национального исследовательского университета «МИЭТ» (Россия, 124498, г. Москва, г. Зеленоград, пл. Шокина, 1), gagar@bk.ru
Букарев Антон Владимирович - соискатель ученой степени кандидата наук Института системной и программной инженерии и информационных технологий Национального исследовательского университета «МИЭТ» (Россия, 124498, г. Москва, г. Зеленоград, пл. Шокина, 1), anton@bukarev.org
References
1. TAdviser: Government. Business. IT. Available at: https://tadviser.com (accessed: 01.08.2023).
2. Statista. Available at: https://www.statista.com (accessed: 01.08.2023).
3. Gagarina L. G., Shevnina Ju. S. Modeling a digital twin of the production process using smart structure.
Sistemy komp'yuternoy matematiki i ikh prilozheniya, 2022, no. 23, pp. 84-90. (In Russian). EDN: UEMIYJ.
4. Veselov V. F., Gagarina L. G. Computing device emulator with absolute precision computing. Sistemy komp'yuternoy matematiki i ikhprilozheniya, 2022, no. 23, pp. 70-78. (In Russian). EDN: GTNYZV.
5. Mukhutdinov R. A., Mukhutdinov A. A., Konyaeva O. S. CI/CD systems. Studencheskiy vestnik, 2020, no. 19-10 (117), pp. 69-70. (In Russian). EDN: QGTKEQ.
6. Karyshev A. A., Romashov P. A. The automation system of software testing. Elektronnyy zhurnal: nauka, tekhnika i obrazovanie, 2016, no. 2 (6), pp. 140-146. (In Russian). EDN: WPNCXJ. Available at: http://nto-journal.ru/uploads/articles/7a1f6e69f918d40ce7a55504eb1ff4af.pdf (accessed: 28.08.2023).
7. Mikhalchuk V. D., Reshetnikova I. V. Using manual and automated software testing in flexible design methodologies. Sovremennye instrumental'nye sistemy, informatsionnye tekhnologii i innovatsii: sb. nauch. tr. XV Mezhdunar. nauch.-prakt. konf. (Kursk, 19-20 marta 2020 g.). Kursk, Southwest State University, 2020, pp. 203-207. (In Russian). EDN: LSATBQ.
8. Danilova A. A., Mayorova E. S. Review of patent information and periodical press sources on the topic: "Analysis of automated software testing systems". Sovremennye tendentsii razvitiya nauki i tekhnologiy, 2016, no. 7-2, pp. 22-26. (In Russian). EDN: WHDBAL.
9. Tyutyunykh A. A., Polevshchikov I. S. Development of an automated control system for the software testing process. Avtomatizirovannye sistemy upravleniya i informatsionnye tekhnologii: materialy Vseros. nauch.-tekhn. konf. (Perm', 17 maya 2018g.), in 2 vol. Perm, Perm National Research Polytechnic University Publ., 2018, vol. 1, pp. 104-109. (In Russian). EDN: YVAQHB.
10. Filippov V. A., Khatko E. E. Problems of testing quality of the software for multitask user complexes. Kachestvo. Innovatsii. Obrazovanie, 2011, no. 3 (70), pp. 32-35. (In Russian). EDN: ONDBML.
11. Gridin V. N., Dmitrievich G. D., Anisimov D. A. Methodology of construction of web services of distributed platform-independent computer-aided design. Sistemy i sredstva informatiki = Systems and Means of Informatics, 2014, vol. 24, no. 1, pp. 213-223. (In Russian). https://doi.org/10.14357/08696527140113. -EDN: SJHVPJ.
The article was submitted 27.07.2023; approved after reviewing 04.08.2023;
accepted for publication 08.08.2023.
Information about the authors
Larisa G. Gagarina - Dr. Sci. (Eng.), Prof., Director, Institute of System and Software Engineering and Information Technologies, National Research University of Electronic Technology (Russia, 124498, Moscow, Zelenograd, Shokin sq., 1), gagar@bk.ru
Anton V. Bukarev - Candidate of the Academic Degree of Candidate of Sciences of the Institute of System and Software Engineering and Information Technologies, National Research University of Electronic Technology (Russia, 124498, Moscow, Zelenograd, Shokin sq., 1), anton@bukarev.org
Информация для читателей журнала «Известия высших учебных заведений. Электроника»
Полные тексты статей журнала с 2004 по 2022 гг. доступны на сайтах Научной электронной библиотеки: www.elibrary.ru и журнала «Известия высших учебных заведений. Электроника»: http://ivuz-e.ru
