RU2817184C1 - Способ тестирования программного обеспечения встроенных систем управления - Google Patents
Способ тестирования программного обеспечения встроенных систем управления Download PDFInfo
- Publication number
- RU2817184C1 RU2817184C1 RU2023125302A RU2023125302A RU2817184C1 RU 2817184 C1 RU2817184 C1 RU 2817184C1 RU 2023125302 A RU2023125302 A RU 2023125302A RU 2023125302 A RU2023125302 A RU 2023125302A RU 2817184 C1 RU2817184 C1 RU 2817184C1
- Authority
- RU
- Russia
- Prior art keywords
- software
- computing device
- testing
- state
- image
- Prior art date
Links
- 238000012360 testing method Methods 0.000 claims description 81
- 238000000034 method Methods 0.000 claims description 22
- 238000013522 software testing Methods 0.000 claims description 5
- 238000012544 monitoring process Methods 0.000 abstract description 4
- 239000000126 substance Substances 0.000 abstract 1
- 238000012795 verification Methods 0.000 abstract 1
- 230000006870 function Effects 0.000 description 5
- 230000007704 transition Effects 0.000 description 5
- 239000013598 vector Substances 0.000 description 3
- 238000012545 processing Methods 0.000 description 2
- 238000004891 communication Methods 0.000 description 1
- 238000012937 correction Methods 0.000 description 1
- 238000001514 detection method Methods 0.000 description 1
- 230000018109 developmental process Effects 0.000 description 1
- 238000005516 engineering process Methods 0.000 description 1
- 230000002068 genetic effect Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 238000002372 labelling Methods 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 230000008569 process Effects 0.000 description 1
- 238000012797 qualification Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 230000008672 reprogramming Effects 0.000 description 1
Abstract
Изобретение относится к области вычислительной техники. Технический результат заключается в сокращении времени тестирования программного обеспечения встроенных систем управления. Технический результат достигается за счет того, что на этапе анализа функциональных требований на программное обеспечение определяют количество тестируемых функциональных требований программного обеспечения, для каждого требования определяют его количество условий, для каждого условия выполняют программное обеспечение до его проверки, сохраняют образ состояния тестируемого программного обеспечения, определяют количество решений для условия, для каждого решения восстанавливают состояние тестируемого программного обеспечения и выполняют тестирование выбранного решения. Сохранение образа состояния программного обеспечения осуществляют путем останова процессора вычислительного устройства, чтения образа состояния программного обеспечения из памяти вычислительного устройства, сохранения его в память аппаратуры контроля и запуска процессора вычислительного устройства. Восстановление образа состояния программного обеспечения осуществляют путем останова процессора вычислительного устройства, записи ранее сохраненного образа состояния программного обеспечения в память вычислительного устройства и запуска процессора вычислительного устройства. 3 ил.
Description
Изобретение относится к вычислительной технике, а именно к способу тестирования программного обеспечения встроенных систем управления.
Встроенная система управления - любая цифровая специализированная микропроцессорная система управления (далее вычислительное устройство), содержащая программное обеспечение в энергонезависимой памяти.
Программное обеспечение встроенных систем управления в ходе отработки проходит несколько этапов испытаний. Начиная от автономной отладки и заканчивая тестированием программного обеспечения в составе реального вычислительного устройства. Последний является наиболее сложным, трудоемким и продолжительным, т.к. тестирование выполняется по прицепу «черного ящика», а отслеживание хода выполнения программного обеспечения и диагностики его состояния осуществляется по внешним каналам обмена. Для подтверждения выполнения всех требований тестируемого программного обеспечения встроенных систем управления, осуществляется функциональное тестирование. Оно предполагает покрытие тестами всех требований на программное обеспечение, включающих все условия и их решения, аналогично покрытию условий и путей, соответственно, при тестировании «белого ящика».
Решение условия - это один из вариантов выполнения программного обеспечения, из точки прохождения условия, обозначенной в требованиях на программное обеспечение. Количество решений условия определяется множеством значений данного условия в требованиях и может быть различным: для логических условий решения могут быть истина или ложь; для условий выбора может быть небольшое множество конечных значений; для математических условий решений может быть огромное множество значений, количество которых определяет тестировщик или используя средства автоматизации, которые могут перебрать все варианты; и т.д.
Состояние программного обеспечения - это конкретное состояние переменных, флагов, массивов данных, запущенных задач и т.д. в определенный момент времени.
Образ состояния программного обеспечения - образ памяти системы управления, в которой выполняется программное обеспечение.
Тестирование решений предполагает многократный переход между состояниями программного обеспечения для каждого теста. Каждый тест состоит из следующих этапов: установка начального состояния программного обеспечения для выполнения теста (установка начальных условий прохождения теста); выполнение тестирования; контроль данных; установка в исходное состояние программного обеспечения, которое определяется не подготовкой к тесту, а «холостым ходом» программного обеспечения, т.е. когда функционирование сведено к минимуму. Последний этап является не обязательным, и может не выполняться, для случая, когда тесты идут один за одним, т.к. исходное состояние программного обеспечения будет тут же будет заменяться установкой начальных условий следующего теста.
При выполнении нескольких тестов изменение состояния программного обеспечения выполняется многократно, для установки начальных условий прохождения каждого теста. Для их установки задают состояния внутренних условий и данных в тестируемом программном обеспечении, путем выдачи соответствующих управляющих воздействий.
Для прохождения какого-либо условия в требованиях, при выполнении тестируемого программного обеспечения, для различных его решений характерно одинаковое состояние программного обеспечения. Плюс к этому количество однотипных требований предполагает одинаковость начальных условий для их тестирования. Для таких случаев в каждом тесте начальное состояние тестируемого программного обеспечения будет одинаковым, а его установка сводится к многократному повторению одного и того же набора операций и затратам времени на их выполнение.
Таким образом, оперативный переход между состояниями тестируемого программного обеспечения напрямую влияет на общую продолжительность тестирования.
Известно изобретение «Способ отладки функционального программного обеспечения системы, установленной на борту летательного аппарата, и устройство для ее осуществления» (Патент RU 2454706 C2). Способ отладки функционального программного обеспечения бортовой системы, включающий следующие этапы: разметка программы путем установки меток вдоль пути выполнения программы для разбивки указанного пути выполнения на смежные функциональные интервалы, нормальное выполнение программы, выделение состояния выполнения программы при помощи векторов состояния меток, при обнаружении ошибки выполняют: поиск функционального интервала нарушения на основании векторов состояния меток, обратное выполнение программы в этом функциональном интервале нарушения, определение и исправление ошибки.
В данном способе переход в определенное состояние выполнения программы осуществляется только при обнаружении ошибки для ее локализации. Переход выполняется при помощи векторов состояния меток в рамках программы путем обратного ее выполнения на функциональном интервале, содержащем ошибку. Если интервал между метками будет длинным, то обратное выполнение до метки может занять значительное время. Если интервалы между метками короткий, то количество меток будет большим, что может сказаться определенным образом на производительности. Неоптимальная разбивка на метки может увеличить продолжительность тестирования.
Известно изобретение «Способ обработки объема данных, используемого во время фазы отладки функционального программного обеспечения систем, установленной на борту летательного аппарата, и устройство для его осуществления» (Патент RU 2451990 C2). Способ обработки объема данных, используемых во время фазы отладки программы функционального программного обеспечения бортовой системы, включающий следующие этапы: а) разбивка пути выполнения указанной рабочей программы на функциональные интервалы путем установки путевых точек в каждой функции программы, б) установка контрольных точек, связанных с каждой путевой точкой, в) нормальное выполнение программы, которое включает в себя: запись в память состояния выполнения программы в месте каждой путевой точки; при этом запись в память состояния выполнения приводит к стиранию состояния выполнения, ранее записанного для указанной путевой точки; причем при обнаружении ошибки осуществляют: поиск путевой точки, соответствующей нарушенной функции; поиск исходного состояния выполнения программы; восстановление этого исходного состояния выполнения; исправление ошибки в нарушенной функции, и - повторное выполнение программы.
Данный способ предназначен для этапа отладки. Использование данного способа при тестировании в составе встроенной системы управления может увеличить время испытаний, так как для установки путевых точек тестировщик должен знать реализацию тестируемого программного обеспечения. Для этого ему необходимо тесно взаимодействовать с разработчиком, либо самому им быть. В первом случае - это дополнительная квалификация для тестировщика и время изучения информации от разработчика. Во втором случае - это снижение качества тестирования за счет одинаковости проверок при отладке и при тестировании в составе встроенной системы управления, что в конечном итоге приведет к увеличению продолжительности тестирования за счет его повторения при выявлении ошибок в будущем.
Известен способ тестирования программ, описанный в [Мельникова В.В., Котов С.Л., Палюх Б.В., Проскуряков М.А. Тестирование программ с использованием генетических алгоритмов // Программные продукты и системы. - 2011. - № 4. - стр. 107 - 110 (http://www.swsys.ru/index.php?page=article&id=2926)], и заключается в следующей последовательности действий: осуществляют анализ функциональных требований к программному обеспечению, ранжируют функциональные требования к программному обеспечению в зависимости от их сложности и важности, формализуют и записывают функциональные требования в виде спецификаций, разрабатывают набор тестов, формируют тестовую базу, которая в дальнейшем используется для регрессионного тестирования.
В данном способе не сказано, каким образом осуществляется переход между состояниями тестируемого программного обеспечения при установке начальных условий различных тестов, что может увеличить время выполнения каждого теста и как итог увеличить продолжительность испытаний встроенного программного обеспечения.
Данный способ по технической сущности является наиболее близким к предлагаемому изобретению и выбран в качестве прототипа.
Для заявленного изобретения выявлены следующие общие с прототипом существенные признаки: осуществляют анализ функциональных требований к программному обеспечению, разрабатывают набор тестов, формируют тестовую базу и проводят тестирование программного обеспечения.
Техническими проблемами изобретения являются сокращение сроков и упрощение тестирования программного обеспечения встроенных систем управления.
Сокращение сроков и упрощение тестирования программного обеспечения осуществляется за счет быстрой и универсальной процедуры установки начального состояния программного обеспечения для выполнения набора тестов, которая исключает выдачу в программное обеспечение управляющих воздействий для приведения его в начальное состояние. Она реализуется путем сохранения образа состояния тестируемого программного обеспечения до выполнения условия, описанного требованием, и восстановлением его перед тестированием каждого решения данного условия.
Для реализации предлагаемого способа необходим комплекс тестирования с минимально требуемым набором компонент: аппаратура контроля 1, вычислительное устройство 2 и технологический канал обмена 3. Пример приведен на фиг.1.
Аппаратура контроля 1 содержит аппаратные модули обмена 1.4 и программное обеспечение, включающее программную среду разработки и выполнения тестов 1.1, средства прямого доступа в память 1.2 и программные имитаторы внешних устройств 1.3.
Программная среда разработки и выполнения тестов 1.1 реализуется в виде единого пользовательского интерфейса и позволяет разрабатывать тесты.
Средства прямого доступа в память 1.2 представляют собой программное обеспечение, реализующее протокол обмена по технологическому каналу обмена 3 и для осуществления прямого доступа в память в вычислительное устройство 2. Прямой доступ в память вычислительного устройства 2 позволяет выполнять перепрограммирование программного обеспечения вычислительного устройства 2.
Программные имитаторы внешних устройств 1.3 моделируют работу внешних устройств, осуществляют управление модулями обмена 1.4 и поддержку протокола соответствующего штатного канала обмена 4 с вычислительным устройством 2.
Вычислительное устройство 2 подключается к модулям обмена 1.4 аппаратуры контроля 1 по штатным каналам обмена 4 и к средствам прямого доступа в память 1.2 аппаратуры контроля 1 по технологическому каналу обмена 3. В вычислительное устройство 2 по технологическому каналу обмена 3 запрограммировано программное обеспечение, для которого будет осуществляться тестирование.
Программное обеспечение электронного устройства разрабатывается на основе документа требований (далее по тексту спецификация). В нем описываются все требования заказчика к разрабатываемому программному обеспечению. В качестве такого документа может выступать спецификация, техническое задание, формализованные исходные данные и др.
Описание и реализация способа
Реализация способа представлена на чертежах фиг.2 и фиг.3.
Проводят анализ требований на тестируемое программное обеспечение встроенных систем управления по спецификации на программное обеспечение и определяют количество функциональных требований (N), подлежащее тестированию. Разрабатывают набор тестов и формируют тестовую базу. С использованием тестовой базы выполняют тестирование.
Тестирование программного обеспечения осуществляется для каждого требования из N. Выбирают требование из N и определяют количество условий Y, проверяемых в рамках данного требования.
Для условия из Y выполняют программное обеспечение до проверки данного условия, сохраняют образ состояния тестируемого программного обеспечения и определяют количество решений R для данного условия.
Для решения из R выполняют тестирование для выбранного решения, при этом восстанавливая состояние тестируемого программного обеспечения, до его выполнения, кроме первого решения, т.к. для него состояние тестируемого программного обеспечения установлено на стадии выполнения программного обеспечения до условия перед сохранением состояния программного обеспечения.
В данном способе для каждого требования из N определяется свое количество условий Y и для каждого условия из Y определяется свое количество решений R.
Сохранение образа состояния программного обеспечения осуществляют путем останова процессора вычислительного устройства, чтения образа состояния программного обеспечения из памяти вычислительного устройства, с сохранением в память аппаратуры контроля и запуска процессора вычислительного устройства.
Восстановление образа состояния программного обеспечения осуществляют путем останова процессора вычислительного устройства, записи ранее сохраненного образа состояния программного обеспечения в память вычислительного устройства и запуска процессора вычислительного устройства.
Сохранение и восстановление образа состояния программного обеспечения осуществляется по технологическому каналу обмена. Сохранение образа состояния программного обеспечения осуществляется динамически в процессе тестирования перед тестированием каждого условия, для возможности быстрого перехода к тестированию всех решений данного условия. Сохраненный образ состояния программного обеспечения хранится на аппаратуре контроля.
Для понимания работы предлагаемого изобретения рассмотрим упрощенный пример требования к логике работы отдельной функции бортовой системы управления космических аппаратов, включающей следующее:
Упрощенный алгоритм работы функции: по запуску алгоритма выдается команда управления (1Хку00, где 1 номер подсистемы, а 00 - номер команды управления для данной подсистемы) в исполнительную подсистему, запускается ожидание времени 80 минут, по окончании которого выдаются несколько команд управления (1Хку01, 3Хку02) в разные исполнительные подсистемы.
Для выдачи команд управления в исполнительные подсистемы задан следующий алгоритм: выдача команды в исполнительную подсистему, через 100мс чтение состояния исполнительной подсистемы и контроль выполнения команды, в случае невыполнения команды повторная ее выдача, и через 100мс чтение состояния исполнительной подсистемы и контроль выполнения команды, в случае невыполнения команды формируется соответствующая телеметрическая информация и алгоритм прекращается. В случае выполнения команды - алгоритм прекращается.
В предлагаемом способе для проверок всех вариантов выдачи команд 1Хку01 и 3Хку02 для формирования начальных условий нет необходимости запускать каждый раз алгоритм и ждать 80 минут, пока программное обеспечение не дойдет до их выдачи, а необходимо запустить алгоритм и единожды подождать 80 минут и дальнейшее тестирование выглядит следующим образом:
- до проверки выдачи команды 1Хку01 (1ое условие), становить процессор;
- сохранить образ состояния программного обеспечения;
- проверить выполнение команды 1Хку01 с первой попытки (1-е решение);
- настроить модели устройств на выполнение команды 1Хку01 со второй попытки;
- восстановить образ в памяти вычислительного модуля;
- проверить выполнение команды 1Хку01 со второй попытки (2-е решение);
- настроить модели устройств на невыполнение команды 1Хку01;
- восстановить образ в памяти вычислительного модуля;
- проверить невыполнение команды 1Хку01 (3-е решение);
- до проверки выдачи команды 3Хку02 (2ое условие), становить процессор;
- сохранить образ состояния программного обеспечения;
- проверить выполнение команды 3Хку02 с первой попытки (1-е решение);
- настроить модели устройств на выполнение команды 3Хку02 со второй попытки;
- восстановить образ в памяти вычислительного модуля;
- проверить выполнение команды 3Хку02 со второй попытки (2-е решение);
- настроить модели устройств на не выполнение команды 3Хку02;
- восстановить образ в памяти вычислительного модуля;
- проверить невыполнение команды 3Хку02 (3-е решение).
Таким образом, при тестировании такого алгоритма выполнение 80-ти минут по алгоритму будет выполнено единожды, а затем будет сохранение состояний программного обеспечения и восстановление для проверки всех решений каждого условия, что в разы сократит тестирование такого алгоритма и общую продолжительность испытаний.
Способ был опробован на рабочем месте наземного отладочного комплекса программного обеспечения приборов управления, который выполнен в стандарте PXI, состоящим из:
- вычислительного модуля приборов управления с программным обеспечением, выступающего в качестве вычислительного устройства;
- аппаратуры контроля, которая включает:
- крейт NI PXI-1045 с контроллером шины PXI-8110;
- модули обмена (фирмы National Instruments), такие как PXI-C1553M-EF-4 (модуль МКО), PXI-8431/4(модуль RS-485/422), PXI-7813R (модуль цифрового ввода-вывода с ПЛИС) и другие, обеспечивающие приборные интерфейсы и являющиеся имитаторами внешних устройств.
С использованием данного способа проводится тестирование встроенного программного обеспечения вычислительного устройства блоков управления и блоков интерфейсных бортового комплекса управления современных и перспективных космических аппаратов производства АО «ИСС».
Реализация данного технического решения позволяет получить необходимый технический результат: сокращение сроков и упрощение тестирования программного обеспечения за счет быстрой и универсальной процедуры установки начального состояния программного обеспечения для выполнения набора тестов, которая исключает выдачу в программное обеспечение управляющих воздействий для приведения его в начальное состояние. Она реализуется путем сохранения образа состояния тестируемого программного обеспечения до выполнения условия, описанного требованием, и восстановлением его перед тестированием каждого решения данного условия.
Claims (1)
- Способ тестирования программного обеспечения встроенных систем управления, заключающийся в том, что осуществляют анализ функциональных требований на программное обеспечение, разрабатывают набор тестов, формируют тестовую базу и проводят тестирование программного обеспечения, отличающийся тем, что на этапе анализа функциональных требований на программное обеспечение определяют количество тестируемых функциональных требований программного обеспечения как N; этап проведения тестирования программного обеспечения осуществляют следующим образом: выбирают первое требование из N; определяют количество условий Y, проверяемых в рамках данного требования; выбирают первое условие из Y; выполняют программное обеспечение до проверки данного условия; сохраняют образ состояния тестируемого программного обеспечения; определяют количество решений R для данного условия; выбирают первое решение из R; выполняют тестирование для выбранного решения; проверяют есть ли нетестированные решения из R; если есть, то выбирают следующее нетестированное решение из R; восстанавливают образ состояния тестируемого программного обеспечения и выполняют тестирование выбранного решения; если нет, то проверяют, есть ли условия из Y с нетестированными решениями; если есть, то выбирают следующее условие Y, для которого нет тестированных решений, и переходят к определению количества решений R для данного условия; если нет, то проверяют, есть ли требования из N с нетестированными решениями; если есть, то выбирают следующее требование N, для которого нет тестированных решений, и переходят к определению количества условий Y, проверяемых в рамках данного требования; если нет, то тестирование выполнено; для сохранения образа состояния программного обеспечения выполняют: останов процессора вычислительного устройства, чтение образа состояния программного обеспечения из памяти вычислительного устройства с сохранением его в память аппаратуры контроля и запуск процессора вычислительного устройства; для восстановления образа состояния программного обеспечения выполняют: останов процессора вычислительного устройства, запись ранее сохраненного образа состояния программного обеспечения в память вычислительного устройства и запуск процессора вычислительного устройства.
Publications (1)
| Publication Number | Publication Date |
|---|---|
| RU2817184C1 true RU2817184C1 (ru) | 2024-04-11 |
Family
ID=
Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20070234293A1 (en) * | 2005-12-12 | 2007-10-04 | Archivas, Inc. | Automated software testing framework |
| US20110202901A1 (en) * | 2001-07-27 | 2011-08-18 | Ethan Givoni | Automated software testing and validation system |
| US20140082420A1 (en) * | 2012-09-14 | 2014-03-20 | International Business Machines Corporation | Automated program testing to facilitate recreation of test failure |
| US20190079854A1 (en) * | 2017-09-12 | 2019-03-14 | Facebook, Inc. | Systems and methods for executing tests |
| RU2780458C1 (ru) * | 2021-06-30 | 2022-09-23 | Акционерное общество «Информационные спутниковые системы» имени академика М.Ф. Решетнёва» | Способ функционального тестирования программного обеспечения электронных устройств |
Patent Citations (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20110202901A1 (en) * | 2001-07-27 | 2011-08-18 | Ethan Givoni | Automated software testing and validation system |
| US20070234293A1 (en) * | 2005-12-12 | 2007-10-04 | Archivas, Inc. | Automated software testing framework |
| US20140082420A1 (en) * | 2012-09-14 | 2014-03-20 | International Business Machines Corporation | Automated program testing to facilitate recreation of test failure |
| US20190079854A1 (en) * | 2017-09-12 | 2019-03-14 | Facebook, Inc. | Systems and methods for executing tests |
| RU2780458C1 (ru) * | 2021-06-30 | 2022-09-23 | Акционерное общество «Информационные спутниковые системы» имени академика М.Ф. Решетнёва» | Способ функционального тестирования программного обеспечения электронных устройств |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| KR102537875B1 (ko) | 차량 ecu 소프트웨어 검증을 위한 동적 결함 주입 방법 및 장치 | |
| US20170146987A1 (en) | Electronic control module testing system | |
| RU2451990C2 (ru) | Способ обработки объема данных, используемого во время фазы отладки функционального программного обеспечения системы, установленной на борту летательного аппарата, и устройство для его осуществления | |
| Jenihhin et al. | Challenges of reliability assessment and enhancement in autonomous systems | |
| CN112286750A (zh) | 一种gpio验证方法、装置、电子设备和介质 | |
| CN112560372B (zh) | 一种芯片原型验证方法、装置、设备及介质 | |
| RU2817184C1 (ru) | Способ тестирования программного обеспечения встроенных систем управления | |
| US8359577B2 (en) | Software health management testbed | |
| CN113127331B (zh) | 一种基于故障注入的测试方法、装置及计算机设备 | |
| US11734475B2 (en) | Performance measurement methodology for co-simulation | |
| CN115033471A (zh) | 使用系统测试程序自动生成集成测试程序的方法和系统 | |
| RU2817185C1 (ru) | Способ подтверждения тестов встроенного программного обеспечения электронных устройств | |
| RU2780458C1 (ru) | Способ функционального тестирования программного обеспечения электронных устройств | |
| CN112765021A (zh) | 一种引导程序的调试检验方法、装置、设备及存储介质 | |
| EP3734491A1 (en) | Method, apparatus, device, and medium for implementing simulator | |
| US10268625B2 (en) | Signal path verification device | |
| Lim et al. | Efficient testing of self-adaptive behaviors in collective adaptive systems | |
| Butler | The art of fault-tolerant system reliability modeling | |
| US20100192016A1 (en) | Method For Controlling An Operating Mechanism And A Manipulation Unit | |
| Kis et al. | ATS-PCB: An Effective Automated Testing System for Advanced Driver Assistance Systems | |
| CN113407394B (zh) | 一种服务器ras功能测试的方法、装置、设备和介质 | |
| RU2817186C1 (ru) | Система подтверждения тестов и тестирования встроенного программного обеспечения электронных устройств | |
| CN115510782B (zh) | 定位验证错误的方法、电子设备和存储介质 | |
| Kurtz et al. | Software based test automation approach using integrated signal simulation | |
| US10261887B1 (en) | Method and system for computerized debugging assertions |