RU2780458C1 - Method for functional testing of software of electronic apparatus - Google Patents
Method for functional testing of software of electronic apparatus Download PDFInfo
- Publication number
- RU2780458C1 RU2780458C1 RU2021119035A RU2021119035A RU2780458C1 RU 2780458 C1 RU2780458 C1 RU 2780458C1 RU 2021119035 A RU2021119035 A RU 2021119035A RU 2021119035 A RU2021119035 A RU 2021119035A RU 2780458 C1 RU2780458 C1 RU 2780458C1
- Authority
- RU
- Russia
- Prior art keywords
- software
- test
- error
- testing
- functional
- Prior art date
Links
- 230000001960 triggered Effects 0.000 claims 1
- 238000005516 engineering process Methods 0.000 abstract description 2
- 238000007689 inspection Methods 0.000 abstract 1
- 239000000126 substance Substances 0.000 abstract 1
- 238000001514 detection method Methods 0.000 description 9
- 239000000203 mixture Substances 0.000 description 8
- 230000015556 catabolic process Effects 0.000 description 6
- 230000000875 corresponding Effects 0.000 description 5
- 238000000034 method Methods 0.000 description 5
- 230000002159 abnormal effect Effects 0.000 description 2
- 230000015572 biosynthetic process Effects 0.000 description 2
- 238000007374 clinical diagnostic method Methods 0.000 description 2
- 238000005755 formation reaction Methods 0.000 description 2
- 230000004044 response Effects 0.000 description 2
- 238000010200 validation analysis Methods 0.000 description 2
- 230000004913 activation Effects 0.000 description 1
- 239000002131 composite material Substances 0.000 description 1
- 238000004590 computer program Methods 0.000 description 1
- 230000001771 impaired Effects 0.000 description 1
- 238000009434 installation Methods 0.000 description 1
- 239000000463 material Substances 0.000 description 1
- 230000001131 transforming Effects 0.000 description 1
Images
Abstract
Description
Изобретение относится к вычислительной технике, а именно к способу тестирования программного обеспечения электронных устройств.The invention relates to computer technology, and in particular to a method for testing software for electronic devices.
Программное обеспечение электронных устройств в ходе отработки проходит несколько этапов испытаний. Начиная от автономной отладки и заканчивая тестированием программного обеспечения в составе реального вычислительного устройства. Последний этап является наиболее сложным и трудоемким. Сложность и трудоемкость такого тестирования заключатся в необходимости отслеживания хода выполнения программного обеспечения и диагностики его состояния по внешним каналам обмена. При этом выполнение программного обеспечения в электронном устройстве является нормальным (штатным) и не может прерываться или масштабироваться.The software of electronic devices in the course of development goes through several stages of testing. Starting from offline debugging and ending with software testing as part of a real computing device. The last stage is the most difficult and time-consuming. The complexity and laboriousness of such testing lies in the need to track the progress of software execution and diagnose its status through external exchange channels. At the same time, the execution of software in an electronic device is normal (regular) and cannot be interrupted or scaled.
Наличие программного обеспечения в электронном устройстве предполагает наличие технологического канала обмена, как минимум, для выполнения функции перепрограммирования. Технологический канал у современных электронных устройств так же используется для осуществления контроля вычислительного процесса и состояний массивов и данных электронного устройства. Его использование существенно упрощает диагностику вычислительного процесса программного обеспечения и обеспечивает достаточную контролепригодность в процессе отладки и тестирования.The presence of software in an electronic device implies the presence of a technological exchange channel, at least to perform the reprogramming function. The technological channel of modern electronic devices is also used to control the computing process and the states of the arrays and data of the electronic device. Its use greatly simplifies the diagnostics of the software computing process and provides sufficient testability in the process of debugging and testing.
Этап тестирования, на котором подтверждается выполнение требований программного обеспечения (валидация) и дается заключение о разрешении его штатного использования в электронном устройстве, должен быть выполнен либо на полностью отлаженной адекватной эталонной модели электронного устройства, которая прошла этап подтверждения своих характеристик, или на реальном вычислительном устройстве, что является предпочтительным с точки зрения использования реального функционала электронного устройства и оперативности в подготовке рабочего места к испытаниям.The testing stage, which confirms the fulfillment of the software requirements (validation) and gives a conclusion on the permission of its regular use in an electronic device, must be performed either on a fully debugged adequate reference model of an electronic device that has passed the stage of confirming its characteristics, or on a real computing device , which is preferable in terms of using the real functionality of the electronic device and efficiency in preparing the workplace for testing.
На этапе валидации выполняется перепрограммирование программного обеспечения в электронное устройство и тестирование с нормальным выполнением программного обеспечения.The validation phase involves reprogramming the software into the electronic device and testing it with the software running normally.
Известен способ формирования диагностических тестов, основанный на формировании комбинаций входных тестовых сигналов с заданными сочетаниями параметров сигналов и с заданными последовательностями подачи входных сигналов, соответствующими подаче входных сигналов при штатной работе реальных диагностируемых изделий данного типа, а также на определении параметров сочетаний выходных сигналов для каждой комбинации входных тестовых сигналов, отличающийся тем, что на основе описания внутренних частей данного типа изделий формируют эквивалентную эталонную модель соединений, в разрывы эквивалентной эталонной модели соединений включают предварительно подготовленные эталонные модели составных частей данного типа изделий, задают на входы полученной эталонной модели диагностируемых изделий соответствующие сочетания входных сигналов в соответствующей последовательности, отражающей реальную штатную работу диагностируемых изделий, для каждого сочетания задаваемых входных сигналов определяют параметры сочетаний сигналов отклика на выходах эталонной модели диагностируемого изделия и в характерных промежуточных точках между эталонными моделями составных частей изделия, заносят с помощью ЭВМ значения параметров сигналов отклика, полученные с выходов эталонной модели и с промежуточных точек эталонной модели диагностируемого изделия, вместе с параметрами соответствующих тестовых входных сигналов в базу данных, повторяют процесс подачи входных тестовых сигналов и определения параметров эквивалентных выходных сигналов до полного перебора всех состояний эталонной модели диагностируемого изделия, сформированную совокупность входных тестовых сигналов и связанных с ними критериальных эквивалентных выходных сигналов используют для диагностики состояния реальных изделий и диагностики неисправностей составных частей изделий (патент RU 2261471 C1 «Способ формирования диагностических тестов»).There is a known method for generating diagnostic tests based on the formation of combinations of input test signals with given combinations of signal parameters and with given sequences of input signals corresponding to the supply of input signals during normal operation of real diagnosable products of this type, as well as on determining the parameters of combinations of output signals for each combination input test signals, characterized in that, based on the description of the internal parts of a given type of products, an equivalent reference model of connections is formed, pre-prepared reference models of the components of this type of products are included in the breaks of the equivalent reference model of connections, corresponding combinations of input inputs are set to the inputs of the obtained reference model of the diagnosed products. signals in the appropriate sequence, reflecting the actual regular operation of the diagnosed products, for each combination of input signals, parameters are determined with combinations of response signals at the outputs of the reference model of the product being diagnosed and at characteristic intermediate points between the reference models of the components of the product, the computer enters the values of the response signal parameters obtained from the outputs of the reference model and from the intermediate points of the reference model of the product being diagnosed, together with the parameters of the corresponding test input signals to the database, repeat the process of supplying input test signals and determining the parameters of equivalent output signals until a complete enumeration of all states of the reference model of the product being diagnosed, the generated set of input test signals and the associated criterion equivalent output signals are used to diagnose the state of real products and diagnose malfunctions of composite parts of products (patent RU 2261471 C1 "Method of generating diagnostic tests").
В данном способе речь идет о создании эквивалентной эталонной модели устройства. Она должна быть полностью исправна, не содержать ошибок и должна быть адекватной. Ошибки в реализации эталонной модели будут отражаться на качестве диагностики состояния реальных изделий. Таким образом, недостатком данного способа является необходимость создания эквивалентной эталонной модели и ее подтверждение в безошибочности и адекватности, что неизбежно увеличит продолжительность испытаний. А в случае не проведения работ по подтверждению безошибочности и адекватности модели будет снижено качество тестирования программного обеспечения электронного устройства и, как следствие, - качество изделия, в которое оно устанавливается.In this method, we are talking about creating an equivalent reference model of the device. It must be fully operational, free of errors and must be adequate. Errors in the implementation of the reference model will affect the quality of diagnostics of the state of real products. Thus, the disadvantage of this method is the need to create an equivalent reference model and its confirmation of infallibility and adequacy, which will inevitably increase the duration of the tests. And in case of not carrying out work to confirm the accuracy and adequacy of the model, the quality of testing the software of an electronic device will be reduced and, as a result, the quality of the product in which it is installed.
Известно изобретение «Способ отладки функционального программного обеспечения системы, установленной на борту летательного аппарата, и устройство для ее осуществления» (Патент RU 2454706 C2), в соответствии с которым предлагается структурировать выполнение функционального программного обеспечения путем функциональной разметки пути выполнения. Эту функциональную разметку осуществляют путем установки меток в специфических местах нормального пути выполнения программы, чтобы разбить программу на функциональные блоки, что позволяет разработчику находить место, от которого следует осуществлять обратное выполнение. Эту разметку можно выполнять интерактивно или автоматически. Способ отладки функционального программного обеспечения бортовой системы включает следующие этапы: разметка программы путем установки меток вдоль пути выполнения программы для разбивки указанного пути выполнения на смежные функциональные интервалы, нормальное выполнение программы, выделение состояния выполнения программы при помощи векторов состояния меток, при обнаружении ошибки выполняют: поиск функционального интервала нарушения на основании векторов состояния меток, обратное выполнение программы в этом функциональном интервале нарушения, определение и исправление ошибки.The invention "Method for debugging the functional software of a system installed on board an aircraft and a device for its implementation" (Patent RU 2454706 C2) is known, according to which it is proposed to structure the execution of functional software by functional markup of the execution path. This functional markup is done by placing labels at specific locations in the normal program execution path to break the program into functional blocks, which allows the developer to find the location from which to reverse execution. This markup can be done interactively or automatically. The method for debugging the functional software of the on-board system includes the following steps: marking the program by setting marks along the program execution path to break the specified execution path into adjacent functional intervals, normal program execution, highlighting the program execution state using the mark state vectors, when an error is detected, the following is performed: search functional interval of the violation based on the state vectors of the labels, reverse execution of the program in this functional interval of the violation, error detection and correction.
В данном способе разбивка на функциональные блоки осуществляется разработчиком программного обеспечения (программистом), который проводит тестирование. Для достоверной разбивки программист должен полностью понимать роль и цель каждой функции и ориентироваться в сути требований предъявляемых к программному обеспечению. Разбивка заключается в определении функциональных интервалов и установка на них меток. При неверной расстановке меток может получиться, что при тестировании будет наложение одной функции на другую или наоборот и, как результат, функция не будет протестирована полностью, что может привести к недостоверным результатам испытаний.In this method, the breakdown into functional blocks is carried out by a software developer (programmer) who conducts testing. For a valid breakdown, the programmer must fully understand the role and purpose of each function and navigate the essence of the software requirements. The breakdown consists in defining functional intervals and setting labels on them. If the labels are placed incorrectly, it may turn out that during testing there will be an imposition of one function on another or vice versa and, as a result, the function will not be tested completely, which can lead to unreliable test results.
Наиболее близким к заявленному изобретению является изобретение «Способ обработки объема данных, используемого во время фазы отладки функционального программного обеспечения системы, установленной на борту летательного аппарата, и устройство для его осуществления» (Патент RU 2451990 C2), в соответствии с которым способ включает следующие этапы: а) разбивка пути выполнения указанной рабочей программы на функциональные интервалы путем установки путевых точек в каждой функции программы. b) установка контрольных точек, связанных с каждой путевой точкой, с) нормальное выполнение программы, при котором осуществляют: запись в память состояния выполнения программы в месте каждой путевой точки; при этом запись в память состояния выполнения приводит к стиранию состояния выполнения, ранее записанного для указанной путевой точки; при обнаружении ошибки осуществляют: поиск путевой точки, соответствующей нарушенной функции; поиск исходного состояния выполнения программы; восстановление этого исходного состояния выполнения; исправление ошибки в нарушенной функции и повторное выполнение программы.Closest to the claimed invention is the invention "Method for processing the amount of data used during the debugging phase of the functional software of the system installed on board the aircraft, and a device for its implementation" (Patent RU 2451990 C2), according to which the method includes the following steps : a) splitting the execution path of the specified work program into functional intervals by setting waypoints in each function of the program. b) setting the checkpoints associated with each waypoint, c) normal program execution, which is: recording in memory the state of program execution at the location of each waypoint; while writing to the memory of the execution state leads to the erasure of the execution state previously recorded for the specified waypoint; when an error is detected, the following is carried out: search for a waypoint corresponding to the impaired function; search for the initial state of program execution; restoring this original state of execution; fixing the error in the broken function and re-executing the program.
В качестве тестового интервала используется путь от метки до метки, который и определяет функциональный интервал программного обеспечения. Такую разметку может осуществить только программист, знающий реализацию программного обеспечения.The label-to-label path is used as the test interval, which determines the functional interval of the software. Such markup can only be done by a programmer who knows how to implement the software.
Для более полного понимания влияния знаний о реализации программного обеспечения, его сложности и простоты или уровне квалификации программиста, разработавшего его, введем понятие критичности мышления в тестировании.For a more complete understanding of the influence of knowledge about the implementation of software, its complexity and simplicity, or the skill level of the programmer who developed it, we introduce the concept of critical thinking in testing.
Критичность мышления в тестировании - это характеристика отношения тестировщика к программному обеспечению в процессе тестирования, заключающаяся в восприятии программного обеспечения в контексте потенциального наличия ошибок в нем.Critical thinking in testing is a characteristic of a tester's attitude towards software during the testing process, which consists in the perception of software in the context of the potential presence of errors in it.
Данная характеристика напрямую влияет на качество написанных тестов и их детализацию. Если тестировщик считает, что в программном обеспечении мало ошибок (в силу знаний о реализации или ранних проверках данного программного обеспечения и т.п.), то критичность мышления низкая. Если тестировщик считает, что ошибок в программном обеспечении может быть много (в силу знаний об отрицательном опыте программистов или низком качестве их работы, или сложности требований для реализации и т.д.), то считается, что критичность мышления высокая.This characteristic directly affects the quality of written tests and their detail. If the tester believes that there are few errors in the software (due to knowledge about the implementation or early checks of this software, etc.), then the criticality of thinking is low. If the tester believes that there can be many errors in the software (due to knowledge about the negative experience of programmers or the low quality of their work, or the complexity of the requirements for implementation, etc.), then it is considered that the critical thinking is high.
Для разбивки на функциональные блоки в указанном известном способе необходим программист, который знает, как работает программное обеспечение на уровне белого ящика, что не всегда правильно и снижает критичность мышления.To break down into functional blocks in this well-known method, a programmer is needed who knows how the software works at the white box level, which is not always correct and reduces critical thinking.
Для повышения критичности мышления в тестировании лучше привлечь специалиста, знающего требования на программное обеспечение, и не имеющего полного представления о его реализации. В качестве такого специалиста можно выбрать разработчика требований к программному обеспечению, который воспринимает программное обеспечение на уровне требований к нему, без учета реализации. В таком случае в качестве функциональных интервалов будут использоваться именно требования, для проверки которых необходимо написать отдельные тесты с установкой в них контрольных точек обнаружения ошибок. Таким образом, данное тестирование будет проводиться по методу серого ящика.To increase critical thinking in testing, it is better to involve a specialist who knows the requirements for the software and does not have a complete understanding of its implementation. As such a specialist, you can choose a software requirements developer who perceives software at the level of requirements for it, without regard to implementation. In this case, exactly the requirements will be used as functional intervals, for the verification of which it is necessary to write separate tests with the installation of error detection checkpoints in them. Thus, this testing will be carried out according to the gray box method.
Существенное значение имеет качество написанных тестов, которые до тестирования с нормальным выполнением программного обеспечения необходимо проверить и подтвердить. В противном случае возможны ситуации, когда тест не обнаруживает ошибку, и она в последствие приводит к нештатным ситуациям в работе электронного устройства и системы, в которой оно установлено. Выявление и устранение подобной ошибки увеличит время испытаний. Таким образом, чтобы можно было говорить о достоверности тестирования необходимо, не просто произвести расстановку контрольных точек, но и проверить их работоспособность (отработать тесты).The quality of the written tests is essential, which must be checked and validated before testing with the normal execution of the software. Otherwise, situations are possible when the test does not detect an error, and it subsequently leads to abnormal situations in the operation of the electronic device and the system in which it is installed. Identifying and eliminating such an error will increase the testing time. Thus, in order to be able to talk about the reliability of testing, it is necessary not only to place control points, but also to check their performance (work out tests).
Ограничения данного способа могут быть устранены путем функциональной разбивки тестируемого программного обеспечения на основе документации, содержащей требования к программному обеспечению (может быть: спецификация или исходные данные, или отдельный документ требований и т.д.). При такой разбивки каждый функциональный блок равен одному требованию или совокупности требований, связанных между собой какой-нибудь общей частью, а тестировщику отпадает необходимость самому определять границы каждого функционального блока.The limitations of this method can be eliminated by functional breakdown of the software under test based on the documentation containing the requirements for the software (may be: specification or source data, or a separate requirements document, etc.). With such a breakdown, each functional block is equal to one requirement or a set of requirements interconnected by some common part, and the tester does not need to determine the boundaries of each functional block himself.
Для использования полностью достоверных тестов необходимо при их разработке проводить подтверждение на обнаружение ошибок с использованием программного обеспечения электронного устройства. Такая проверка может проводиться путем имитации ошибки через технологический канал обмена электронного устройства и подтверждения выявления введенной ошибки контрольными точками тестов.To use completely reliable tests, it is necessary to carry out confirmation for error detection using the software of the electronic device during their development. Such a check can be carried out by simulating an error through the technological exchange channel of an electronic device and confirming the detection of an introduced error by test checkpoints.
Проверка тестов по подтверждению на обнаружение ошибок дополнительно обеспечит унитарное тестирование программного обеспечения электронного устройства, а значит исключит подобные возможные ошибки еще до тестирования с нормальным выполнением программного обеспечения, а, следовательно, сократит общее время испытаний.Checking confirmation tests for detecting errors will additionally provide unitary testing of the software of an electronic device, which means that such possible errors will be excluded even before testing with normal software execution, and, therefore, will reduce the total testing time.
Изобретение «Способ обработки объема данных, используемого во время фазы отладки функционального программного обеспечения системы, установленной на борту летательного аппарата, и устройство для его осуществления» (Патент RU 2451990 C2) выбрано в качестве прототипа.The invention "Method of processing the amount of data used during the debugging phase of the functional software of the system installed on board the aircraft, and a device for its implementation" (Patent RU 2451990 C2) was chosen as a prototype.
Недостатками прототипа являются:The disadvantages of the prototype are:
• разбивка на функциональные блоки выполняется на усмотрение разработчика и его знаний об объекте испытаний, что в силу человеческого фактора снижает качество тестирования и как результат надежность программного обеспечения;• breakdown into functional blocks is performed at the discretion of the developer and his knowledge of the test object, which, due to the human factor, reduces the quality of testing and, as a result, the reliability of the software;
• отсутствие проверки по обнаружению ошибок контрольными точками тестов, вносит потенциальную возможность пропуска ошибок при тестировании с нормальным выполнением программного обеспечения и увеличивает время испытаний за счет дополнительной корректировки тестов.• the absence of error detection checks by test checkpoints, introduces the potential for missing errors during testing with normal software execution and increases the testing time due to additional test adjustments.
Для заявленного изобретения выявлены следующие общие с прототипом существенные признаки: способ функционального тестирования программного обеспечения электронных устройств, заключающийся в том, что выполняют разбивку программного обеспечения на функциональные блоки, устанавливают контрольные точки для каждого функционального блока и проводят тестирование с нормальным выполнением программного обеспечения.For the claimed invention, the following essential features common with the prototype have been identified: a method for functional testing of software for electronic devices, which consists in breaking down the software into functional blocks, setting checkpoints for each functional block and testing with normal software execution.
Технической проблемой является повышение надежности программного обеспечения, качества тестирования и сокращение общего времени испытаний.The technical challenge is to improve software reliability, test quality, and reduce overall test time.
Техническая проблема решается за счет того, что выполняют разбивку программного обеспечения на функциональные блоки в соответствии с документом требований на программное обеспечение (спецификация или техническое задание или др.), на этапе установки контрольных точек пишут функциональные тесты таким образом, что каждый тест проверяет свой функциональный блок, при этом проводят их проверку на обнаружение ошибок с использованием программного обеспечения электронного устройства. При написании каждого функционального теста устанавливают не менее одной контрольной точки и выполняют проверку теста с использованием тестируемого программного обеспечения, т.е. срабатывание каждой контрольной точки в тесте путем ввода единичной ошибки в программное обеспечение, с использованием средств прямого доступа в память электронного устройства. При обнаружении ошибки контрольной точкой переходят к проверке следующей контрольной точки данного теста, путем формирования новой ошибки в программном обеспечении, а по завершении выполнения проверки теста переходят к написанию следующего функционального теста. В случае не выявления контрольной точкой введенной ошибки, в тесте проводят корректировку логики выявления ошибки в контрольной точке и повторяют проверку до тех пор, пока контрольная точка не будет выявлять ошибку. Когда все тесты выявляют введенные ошибки, переходят к проведению тестирования с нормальным выполнением программного обеспечения.The technical problem is solved by breaking down the software into functional blocks in accordance with the software requirements document (specification or terms of reference, etc.), at the stage of setting checkpoints, functional tests are written in such a way that each test checks its own functional block, while checking them for error detection using the software of the electronic device. When writing each functional test, at least one checkpoint is set and the test is verified using the software under test, i.e. actuation of each control point in the test by entering a single error into the software, using the means of direct access to the memory of the electronic device. When an error is detected by the checkpoint, they proceed to check the next checkpoint of this test by generating a new error in the software, and upon completion of the test check, they proceed to writing the next functional test. If the control point fails to detect the introduced error, the test corrects the error detection logic at the control point and repeats the test until the control point detects an error. When all tests reveal the introduced errors, proceed to testing with normal software execution.
Для реализации предлагаемого способа используется организация комплекса тестирования, содержащая аппаратуру контроля 1 и электронное устройство 2, представленная на фиг. 1.To implement the proposed method, the organization of a testing complex is used, containing
Аппаратура контроля 1 содержит аппаратные модули обмена 1.4 и программное обеспечение, включающее программную среду разработки и выполнения тестов 1.1, средства прямого доступа в память 1.2 и программные имитаторы внешних устройств 1.3.
Программная среда разработки и выполнения тестов 1.1 реализуется в виде единого пользовательского интерфейса и позволяет разрабатывать тесты. Тесты содержат последовательность операций управления вычислительным устройством и установку контрольных точек. В качестве контрольных точек могут выступать операции контроля определенных данных (появление телеметрического признака в словах данных, формирования флага срабатывания по условию или определенного значения математического преобразования и др.), регистрации срабатывания какого либо события в программном обеспечении электронного устройства (выдача определенной команды управления на имитатор, изменение состояния параметра телеметрической информации и др.), подсчета времени выполнения функциональных блоков или времени между событиями и т.д.The software development and test execution environment 1.1 is implemented as a single user interface and allows you to develop tests. Tests contain a sequence of operations for managing a computing device and setting checkpoints. Checkpoints can be control operations for certain data (appearance of a telemetric sign in data words, formation of a trigger flag by a condition or a certain value of a mathematical transformation, etc.), registration of triggering of any event in the software of an electronic device (issuance of a specific control command to the simulator , changing the state of the telemetry information parameter, etc.), counting the execution time of function blocks or the time between events, etc.
Средства прямого доступа в память 1.2 представляют собой программное обеспечение, реализующее протокол обмена по диагностическому (технологическому) каналу обмена 3идля осуществления прямого доступа в память в электронное устройство 2. Прямой доступ в память электронного устройства 2 позволяет модифицировать данные в нем и выполнять его перепрограммирование программным обеспечением.Means of direct memory access 1.2 are software that implements an exchange protocol over a diagnostic (technological)
Программные имитаторы внешних устройств 1.3 моделируют работу внешних устройств, осуществляют управление модулями обмена 1.4 и поддержку протокола соответствующего штатного канала обмена 4 с электронным устройством 2.Software simulators of external devices 1.3 simulate the operation of external devices, control the exchange modules 1.4 and support the protocol of the corresponding
Электронное устройство 2 подключается к модулям обмена 1.4 аппаратуры контроля 1 по штатным каналам обмена 4 и к средствам прямого доступа в память 1.2 аппаратуры контроля 1 по диагностическому (технологическому) каналу обмена 3. В электронное устройство 2 запрограммировано программное обеспечение, для которого будет осуществляться тестирование.The
Программное обеспечение электронного устройства разрабатывается на основе документа требований. В нем описываются все требования заказчика к разрабатываемому программному обеспечению. В качестве такого документа может выступать спецификация, техническое задание и др.The electronic device software is developed based on the requirements document. It describes all customer requirements for the developed software. Such a document can be a specification, technical task, etc.
Способ реализуется следующим образом.The method is implemented as follows.
Реализация способа представлена на фиг.2.The implementation of the method is shown in Fig.2.
Тестировщик на основе документа требований на программное обеспечение, проводит разбивку программного обеспечения на функциональные блоки. В качестве таких функциональных блоков могут выступать как отдельные требования к программному обеспечению, так и их совокупность, связанных между собой общей частью, если они предъявляются для выполнения одной и той же функции.Based on the software requirements document, the tester breaks down the software into functional blocks. Such functional blocks can be both individual software requirements and their combination, interconnected by a common part, if they are presented to perform the same function.
Пример функции как единичного требования: обеспечение определенного времени между управляющими командами во внешние устройства, включение определенного телеметрического параметра по конкретной команде в программном обеспечении электронного устройства и т.д.An example of a function as a single requirement: providing a certain time between control commands to external devices, switching on a certain telemetry parameter on a specific command in the software of an electronic device, etc.
Пример функции как множественности требований - выдача управляющей команды во внешнее устройство (включает в себя: выдача команды от аппаратуры контроля, формирование квитанции для аппаратуры контроля через определенное время, выдача управляющей команды в имитатор внешнего устройства и контроль телеметрической информации аппаратурой контроля о статусе выдачи команды во внешнее устройство) и др.An example of a function as a plurality of requirements is issuing a control command to an external device (includes: issuing a command from the control equipment, generating a receipt for the control equipment after a certain time, issuing a control command to the simulator of an external device and monitoring telemetry information by the control equipment about the status of issuing a command during external device), etc.
После разбивки программного обеспечения на функциональные блоки тестировщик выполняет написание функциональных тестов с установкой, как минимум, одной контрольной точки для каждого теста. Количество контрольных точек определяет тестировщик по функциональному блоку относительно своей критичности мышления.After breaking down the software into functional blocks, the tester writes functional tests, setting at least one breakpoint for each test. The number of control points is determined by the tester according to the functional block in relation to his critical thinking.
Контрольной точкой может являться единичная операция или набор операций, предназначенных для контроля состояния данных или массивов, характеризующих работу проверяемой функции. Прохождение контрольной точки говорит о том, что данные проверяемой функции в норме. Остановка выполнения тестирования в контрольной точке говорит о наличии ошибки в контролируемых данных.A checkpoint can be a single operation or a set of operations designed to control the state of data or arrays that characterize the operation of the function being checked. Passing a checkpoint indicates that the data of the checked function is normal. Stopping the execution of testing at a checkpoint indicates the presence of an error in the controlled data.
Тестировщик проводит проверку контрольных точек на предмет выявления ими ошибок в тестах с использованием тестируемого программного обеспечения и средств прямого доступа в память электронного устройства. Во время проверки контрольных точек выполнение программного обеспечения электронного устройства является нештатным, т.к. функционирует с введенной единичной ошибкой. Ошибка вводится в программное обеспечение через технологический канал обмена и служит только для факта выявления срабатывания контрольной точки. Тем не менее, непредсказуемое выполнение программы с введенной ошибкой может косвенно свидетельствовать о наличии реальной ошибки в программном обеспечении и дать повод для дальнейшего анализа возникшей ситуации. Таким образом, проверка контрольных точек позволяет выявлять потенциальные ошибки в программном обеспечении электронного устройства еще до стадии тестирования с нормальным (штатным) его выполнением.The tester checks the checkpoints to identify errors in the tests using the software under test and means of direct access to the memory of the electronic device. During checkpointing, the execution of the software of the electronic device is abnormal, because. operates with the introduced single error. The error is entered into the software through the technological exchange channel and serves only to detect the activation of the checkpoint. However, unpredictable execution of a program with an introduced error may indirectly indicate the presence of a real error in the software and give rise to further analysis of the situation that has arisen. Thus, checking checkpoints allows you to identify potential errors in the software of an electronic device even before the testing stage with its normal (standard) execution.
Алгоритм проверки контрольных точек следующий: тестировщик последовательно для каждой контрольной точки вводит ошибку в программное обеспечение по диагностическому каналу и проверяет срабатывание контрольной точки (обнаружение ошибки); в случае не обнаружения ошибки контрольная точка корректируется (для нее вводятся уточненные данные или параметры контроля) и опять проверяется ее срабатывание и так до тех пор, пока она не будет выявлять введенную ошибку. В случае обнаружения ошибки контрольной точкой, проверяется следующая контрольная точка в тесте аналогичным образом. После проверки всех контрольных точек в тесте тестировщик переходит к следующему тесту и проверяет аналогично его контрольные точки и так до тех пор, пока для всех тестов контрольные точки не будут проверены.The checkpoint verification algorithm is as follows: the tester sequentially for each checkpoint introduces an error into the software through the diagnostic channel and checks the checkpoint operation (error detection); if an error is not detected, the control point is corrected (refined data or control parameters are entered for it) and its operation is again checked, and so on until it detects the entered error. If a checkpoint detects an error, the next checkpoint in the test is checked in the same way. After checking all the checkpoints in the test, the tester proceeds to the next test and checks its checkpoints in the same way, and so on until the checkpoints for all tests are checked.
После проверки всех контрольных точек тестов тестировщик выполняет тестирование с нормальным выполнением программного обеспечения электронного устройства.After verifying all the checkpoints of the tests, the tester performs testing with the normal execution of the software of the electronic device.
Способ был опробован на рабочем месте наземного отладочного комплекса программного обеспечения приборов управления, который выполнен в стандарте PXI, состоящим из:The method was tested at the workplace of the ground-based debugging complex for control instrumentation software, which is made in the PXI standard, consisting of:
• вычислительного модуля с программным обеспечением выступающего в качестве электронного устройства;• computing module with software acting as an electronic device;
• аппаратуры контроля, которая включает:• control equipment, which includes:
С использованием данного способа проведено тестирование встроенного программного обеспечения вычислительного устройства блоков управления и блоков интерфейсных бортового комплекса управления современных и перспективных космических аппаратов производства АО «ИСС».Using this method, testing of the embedded software of the computing device of control units and interface units of the onboard control complex of modern and advanced spacecraft manufactured by ISS JSC was carried out.
Реализация данного технического решения позволяет получить необходимый технический результат:The implementation of this technical solution allows to obtain the required technical result:
• повышение качества испытаний и надежности программного обеспечения за счет разбивки программного обеспечения на функциональные блоки в соответствии с документом требований на него и проверки тестов на обнаружение ошибок при их написании;• improving the quality of testing and reliability of software by splitting the software into functional blocks in accordance with the requirements document for it and checking tests for error detection when they are written;
• сокращение времени испытаний за счет того, что при написании тестов уже проводится автономная отработка унитарных функций программного обеспечения, а значит, исключается появление таких ошибок при тестировании с нормальным выполнением программного обеспечения.• reduction of testing time due to the fact that when writing tests, the unitary functions of the software are already being worked out autonomously, which means that such errors are excluded during testing with normal software execution.
Из известных заявителю патентно-информационных материалов не обнаружены признаки, сходные с совокупностью признаков заявляемого способа.Of the patent information materials known to the applicant, no features similar to the set of features of the proposed method were found.
Claims (1)
Publications (1)
| Publication Number | Publication Date |
|---|---|
| RU2780458C1 true RU2780458C1 (en) | 2022-09-23 |
Family
ID=
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2817184C1 (en) * | 2023-10-03 | 2024-04-11 | Акционерное общество "Информационные спутниковые системы"имени академика М.Ф. Решетнёва" | Method of testing software of embedded control systems |
Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2261471C1 (en) * | 2004-03-31 | 2005-09-27 | ЗАО Московское конструкторское бюро "Параллель" | Method for forming diagnostical tests |
| US20080256517A1 (en) * | 2006-10-18 | 2008-10-16 | International Business Machines Corporation | Method and System for Automatically Generating Unit Test Cases Which Can Reproduce Runtime Problems |
| RU2451990C2 (en) * | 2007-09-14 | 2012-05-27 | Эрбюс Операсьон (С.А.С) | Method for processing volume of information used during debugging phase of operational system software onboard aircraft and device for realising said method |
| RU2454706C2 (en) * | 2007-09-14 | 2012-06-27 | Эрбюс Операсьон (С.А.С) | Method of debugging functional system software installed onboard aircraft, and apparatus for realising said method |
Patent Citations (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2261471C1 (en) * | 2004-03-31 | 2005-09-27 | ЗАО Московское конструкторское бюро "Параллель" | Method for forming diagnostical tests |
| US20080256517A1 (en) * | 2006-10-18 | 2008-10-16 | International Business Machines Corporation | Method and System for Automatically Generating Unit Test Cases Which Can Reproduce Runtime Problems |
| RU2451990C2 (en) * | 2007-09-14 | 2012-05-27 | Эрбюс Операсьон (С.А.С) | Method for processing volume of information used during debugging phase of operational system software onboard aircraft and device for realising said method |
| RU2454706C2 (en) * | 2007-09-14 | 2012-06-27 | Эрбюс Операсьон (С.А.С) | Method of debugging functional system software installed onboard aircraft, and apparatus for realising said method |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| RU2817184C1 (en) * | 2023-10-03 | 2024-04-11 | Акционерное общество "Информационные спутниковые системы"имени академика М.Ф. Решетнёва" | Method of testing software of embedded control systems |
| RU2817185C1 (en) * | 2023-10-03 | 2024-04-11 | Акционерное общество "Информационные спутниковые системы" имени академика М.Ф. Решетнёва" | Method of confirming tests of embedded software of electronic devices |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| RU2473115C2 (en) | Method for automatic generation of scenario for validation of functional software installed on-board aircraft, and apparatus for implementing said method | |
| US5515384A (en) | Method and system of fault diagnosis of application specific electronic circuits | |
| Wang et al. | An exploratory study of autopilot software bugs in unmanned aerial vehicles | |
| US20050028146A1 (en) | Systems and methods for software and firmware testing using checkpoint signatures | |
| US9342441B2 (en) | Methodology and tool support for test organization and migration for embedded software | |
| CN103678116B (en) | For the method and system promoting automated procedures to test | |
| CN105589837A (en) | Automatic electronic document checking method | |
| CN105512372B (en) | The data processing onboard emulation test method of modelling | |
| US11520966B2 (en) | Automated assisted circuit validation | |
| RU2780458C1 (en) | Method for functional testing of software of electronic apparatus | |
| CN107145381A (en) | The MIPS cpu test instruments of face the practice teaching | |
| RU2817185C1 (en) | Method of confirming tests of embedded software of electronic devices | |
| RU2817184C1 (en) | Method of testing software of embedded control systems | |
| RU2802712C1 (en) | Method for diagnostics of complex of testing built-in software of electronic devices | |
| Ferrante et al. | A methodology for formal requirements validation and automatic test generation and application to aerospace systems | |
| RU2817186C1 (en) | System for confirming tests and testing embedded software of electronic devices | |
| RU2789850C1 (en) | Method for studying electroic control systems of complex technical objects and a test bench for studying electroic control systems of complex technical objects | |
| Khasanov et al. | Automation of software avionics verification in accordance with DO-178C standard | |
| Lipaev | A methodology of verification and testing of large software systems | |
| Kis et al. | ATS-PCB: An Effective Automated Testing System for Advanced Driver Assistance Systems | |
| Wood et al. | Comparative Assessment of Experimental Testing of Instrument with an Embedded Digital Device Using Model-Based and Conventional Methods | |
| Noordbruis et al. | Model-based testing Smart Cable Guard, an embedded system | |
| GRUBE et al. | Test Maintenance for Machine Learning Systems: A Case Study in the Automotive Industry | |
| JPH10307609A (en) | Software verification tool for plant control | |
| Sarla et al. | Automation of Combinatorial Interaction Test (CIT) Case Generation and Execution for Requirements based Testing (RBT) of Complex Avionics Systems |