Способ функционального тестирования программного обеспечения электронных устройств

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

 

Изобретение относится к вычислительной технике, а именно к способу тестирования программного обеспечения электронных устройств.

Программное обеспечение электронных устройств в ходе отработки проходит несколько этапов испытаний. Начиная от автономной отладки и заканчивая тестированием программного обеспечения в составе реального вычислительного устройства. Последний этап является наиболее сложным и трудоемким. Сложность и трудоемкость такого тестирования заключатся в необходимости отслеживания хода выполнения программного обеспечения и диагностики его состояния по внешним каналам обмена. При этом выполнение программного обеспечения в электронном устройстве является нормальным (штатным) и не может прерываться или масштабироваться.

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

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

На этапе валидации выполняется перепрограммирование программного обеспечения в электронное устройство и тестирование с нормальным выполнением программного обеспечения.

Известен способ формирования диагностических тестов, основанный на формировании комбинаций входных тестовых сигналов с заданными сочетаниями параметров сигналов и с заданными последовательностями подачи входных сигналов, соответствующими подаче входных сигналов при штатной работе реальных диагностируемых изделий данного типа, а также на определении параметров сочетаний выходных сигналов для каждой комбинации входных тестовых сигналов, отличающийся тем, что на основе описания внутренних частей данного типа изделий формируют эквивалентную эталонную модель соединений, в разрывы эквивалентной эталонной модели соединений включают предварительно подготовленные эталонные модели составных частей данного типа изделий, задают на входы полученной эталонной модели диагностируемых изделий соответствующие сочетания входных сигналов в соответствующей последовательности, отражающей реальную штатную работу диагностируемых изделий, для каждого сочетания задаваемых входных сигналов определяют параметры сочетаний сигналов отклика на выходах эталонной модели диагностируемого изделия и в характерных промежуточных точках между эталонными моделями составных частей изделия, заносят с помощью ЭВМ значения параметров сигналов отклика, полученные с выходов эталонной модели и с промежуточных точек эталонной модели диагностируемого изделия, вместе с параметрами соответствующих тестовых входных сигналов в базу данных, повторяют процесс подачи входных тестовых сигналов и определения параметров эквивалентных выходных сигналов до полного перебора всех состояний эталонной модели диагностируемого изделия, сформированную совокупность входных тестовых сигналов и связанных с ними критериальных эквивалентных выходных сигналов используют для диагностики состояния реальных изделий и диагностики неисправностей составных частей изделий (патент RU 2261471 C1 «Способ формирования диагностических тестов»).

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

Известно изобретение «Способ отладки функционального программного обеспечения системы, установленной на борту летательного аппарата, и устройство для ее осуществления» (Патент RU 2454706 C2), в соответствии с которым предлагается структурировать выполнение функционального программного обеспечения путем функциональной разметки пути выполнения. Эту функциональную разметку осуществляют путем установки меток в специфических местах нормального пути выполнения программы, чтобы разбить программу на функциональные блоки, что позволяет разработчику находить место, от которого следует осуществлять обратное выполнение. Эту разметку можно выполнять интерактивно или автоматически. Способ отладки функционального программного обеспечения бортовой системы включает следующие этапы: разметка программы путем установки меток вдоль пути выполнения программы для разбивки указанного пути выполнения на смежные функциональные интервалы, нормальное выполнение программы, выделение состояния выполнения программы при помощи векторов состояния меток, при обнаружении ошибки выполняют: поиск функционального интервала нарушения на основании векторов состояния меток, обратное выполнение программы в этом функциональном интервале нарушения, определение и исправление ошибки.

В данном способе разбивка на функциональные блоки осуществляется разработчиком программного обеспечения (программистом), который проводит тестирование. Для достоверной разбивки программист должен полностью понимать роль и цель каждой функции и ориентироваться в сути требований предъявляемых к программному обеспечению. Разбивка заключается в определении функциональных интервалов и установка на них меток. При неверной расстановке меток может получиться, что при тестировании будет наложение одной функции на другую или наоборот и, как результат, функция не будет протестирована полностью, что может привести к недостоверным результатам испытаний.

Наиболее близким к заявленному изобретению является изобретение «Способ обработки объема данных, используемого во время фазы отладки функционального программного обеспечения системы, установленной на борту летательного аппарата, и устройство для его осуществления» (Патент RU 2451990 C2), в соответствии с которым способ включает следующие этапы: а) разбивка пути выполнения указанной рабочей программы на функциональные интервалы путем установки путевых точек в каждой функции программы. b) установка контрольных точек, связанных с каждой путевой точкой, с) нормальное выполнение программы, при котором осуществляют: запись в память состояния выполнения программы в месте каждой путевой точки; при этом запись в память состояния выполнения приводит к стиранию состояния выполнения, ранее записанного для указанной путевой точки; при обнаружении ошибки осуществляют: поиск путевой точки, соответствующей нарушенной функции; поиск исходного состояния выполнения программы; восстановление этого исходного состояния выполнения; исправление ошибки в нарушенной функции и повторное выполнение программы.

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

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

Критичность мышления в тестировании - это характеристика отношения тестировщика к программному обеспечению в процессе тестирования, заключающаяся в восприятии программного обеспечения в контексте потенциального наличия ошибок в нем.

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

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

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

Существенное значение имеет качество написанных тестов, которые до тестирования с нормальным выполнением программного обеспечения необходимо проверить и подтвердить. В противном случае возможны ситуации, когда тест не обнаруживает ошибку, и она в последствие приводит к нештатным ситуациям в работе электронного устройства и системы, в которой оно установлено. Выявление и устранение подобной ошибки увеличит время испытаний. Таким образом, чтобы можно было говорить о достоверности тестирования необходимо, не просто произвести расстановку контрольных точек, но и проверить их работоспособность (отработать тесты).

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

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

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

Изобретение «Способ обработки объема данных, используемого во время фазы отладки функционального программного обеспечения системы, установленной на борту летательного аппарата, и устройство для его осуществления» (Патент RU 2451990 C2) выбрано в качестве прототипа.

Недостатками прототипа являются:

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

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

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

Технической проблемой является повышение надежности программного обеспечения, качества тестирования и сокращение общего времени испытаний.

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

Для реализации предлагаемого способа используется организация комплекса тестирования, содержащая аппаратуру контроля 1 и электронное устройство 2, представленная на фиг. 1.

Аппаратура контроля 1 содержит аппаратные модули обмена 1.4 и программное обеспечение, включающее программную среду разработки и выполнения тестов 1.1, средства прямого доступа в память 1.2 и программные имитаторы внешних устройств 1.3.

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

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

Программные имитаторы внешних устройств 1.3 моделируют работу внешних устройств, осуществляют управление модулями обмена 1.4 и поддержку протокола соответствующего штатного канала обмена 4 с электронным устройством 2.

Электронное устройство 2 подключается к модулям обмена 1.4 аппаратуры контроля 1 по штатным каналам обмена 4 и к средствам прямого доступа в память 1.2 аппаратуры контроля 1 по диагностическому (технологическому) каналу обмена 3. В электронное устройство 2 запрограммировано программное обеспечение, для которого будет осуществляться тестирование.

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

Способ реализуется следующим образом.

Реализация способа представлена на фиг.2.

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

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

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

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

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

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

Алгоритм проверки контрольных точек следующий: тестировщик последовательно для каждой контрольной точки вводит ошибку в программное обеспечение по диагностическому каналу и проверяет срабатывание контрольной точки (обнаружение ошибки); в случае не обнаружения ошибки контрольная точка корректируется (для нее вводятся уточненные данные или параметры контроля) и опять проверяется ее срабатывание и так до тех пор, пока она не будет выявлять введенную ошибку. В случае обнаружения ошибки контрольной точкой, проверяется следующая контрольная точка в тесте аналогичным образом. После проверки всех контрольных точек в тесте тестировщик переходит к следующему тесту и проверяет аналогично его контрольные точки и так до тех пор, пока для всех тестов контрольные точки не будут проверены.

После проверки всех контрольных точек тестов тестировщик выполняет тестирование с нормальным выполнением программного обеспечения электронного устройства.

Способ был опробован на рабочем месте наземного отладочного комплекса программного обеспечения приборов управления, который выполнен в стандарте PXI, состоящим из:

• вычислительного модуля с программным обеспечением выступающего в качестве электронного устройства;

• аппаратуры контроля, которая включает:

крейт NI PXI-1045 с контроллером шины PXI-8110;

модули обмена (фирмы National Instruments), такие как PXI-C1553M-EF-4 (модуль МКО), PXI-8431/4(модуль RS-485/422), PXI-7813R (модуль цифрового ввода-вывода с ПЛИС) и др., обеспечивающие приборные интерфейсы и являющиеся имитаторами внешних устройств;

единую программную среду разработки и выполнения тестов (свидетельство о регистрации программы для ЭВМ №2013618885 «Наземный отработочный комплекс программного обеспечения вычислительного модуля магистрально-модульной аппаратуры»);

модели функциональных устройств (свидетельства о регистрации программ для ЭВМ: №2013618778, №2013660234, №2013660490, №2014610477, №2014611654, №2015616152, №2015616230, 2015618458, 2015618459, 2015660760, 2015660757, 2015660712, 2015660686, 2015660682, 2015660710, 2015660681 и др.);

средства доступа по диагностическому (технологическому) каналу обмена.

С использованием данного способа проведено тестирование встроенного программного обеспечения вычислительного устройства блоков управления и блоков интерфейсных бортового комплекса управления современных и перспективных космических аппаратов производства АО «ИСС».

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

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

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

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

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