CC BY
45
УДК 519.685/519.686
А.А. ЛЕТИЧЕВСКИЙ* (мл.)
ЭКСПЕРИМЕНТЫ С ДЕДУКТИВНЫМ ТЕСТИРОВАНИЕМ РЕАКТИВНЫХ СИСТЕМ
*
Институт кибернетики им. В.М. Глушкова НАН Украины, Киев, Украина
Анотація. Застосування дедуктивних методів у тестуванні можливе при визначенні відповідності програмного забезпечення вихідним вимогам. Передбачається, що програмний код розробляється за вимогами, які можуть бути задані в деякій формальній мові. Техніка дедуктивного тестування з використанням символьного виконання програми дозволяє отримати найбільш повне покриття спостережуваних даних. У даній статті розглядається приклад дедуктивного тестування реактивної системи.
Ключові слова: автоматизація тестування, формальна верифікація, інженерія вимог, формальні методи, автоматизація доказів.
Аннотация. Применение дедуктивных методов в тестировании возможно при определении соответствия программного обеспечения исходным требованиям. Предполагается, что программный код разрабатывается по требованиям, которые могут быть заданы в некотором формальном языке. Техника дедуктивного тестирования с использованием символьного выполнения программы позволяет получить наиболее полное покрытие наблюдаемых данных. В данной статье рассматривается пример дедуктивного тестирования реактивной системы.
Ключевые слова: автоматизация тестирования, формальная верификация, инженерия требований, формальные методы, автоматизация доказательств.
Abstract. The application of deductive methods in testing technology is possible at definition of equivalence of software product to initial requirements. It is anticipated that programme code is developed due to the requirements that could be presented as formal specifications. Deductive testing technique by using symbol programme execution allows obtaining the most complete coverage of all visible data. The example of deductive testing of reactive system is considered in this paper.
Keywords: automation of testing, formal verification, requirements engineering, formal methods, proving automation.
1. Введение
Современные технологии тестирования программного и аппаратного обеспечения в основном базируются на автоматизации тестирования методом «черного ящика». Сам «черный ящик» представляет собой модель или готовое изделие программно-аппаратного комплекса, а технология тестирования заключается в изучении его поведения или реакций, полученных как ответы на внешние воздействия. Существует также проблема надежности тестирования, в которой изучаются вопросы адекватности «черного ящика» требуемым свойствам создаваемой программы.
Мы рассматриваем тестирование программного кода реактивных систем, то есть систем, которые многократно получают от внешней среды входные воздействия, а в среду возвращают реакции. Взаимодействие со средой происходит в виде обмена сообщениями или данными. Если в требованиях к системе встречаются временные ограничения, то такая система относится к классу систем реального времени.
Как математический объект реактивная система представляет собой транзиционную систему, действия которой подразделяются на входные воздействия и реакции. В одном действии могут быть также совмещены входные воздействия и реакции, даже конечные последовательности таких действий.
Стандартная технология тестирования представляет собой, в первую очередь, описание функциональных спецификаций, которые содержат описание реакций системы на
© Летичевский А.А. (мл.)., 2013
ISSN 1028-9763. Математичні машини і системи, 2013, № 4
входящие воздействия, а затем создание тестового набора, который соответствует описанным реакциям. Такой тестовый набор может быть создан автоматически, если функциональные спецификации или требования к системе представлены в виде формальных спецификаций. Существует ряд инструментов, которые позволяют автоматически сгенерировать тестовый набор, удовлетворяющий некоторому покрытию [1]. Под покрытием понимают некоторый критерий для оценки качества тестирования, такой, как покрытие требований, покрытие данных, а также покрытие строк кода.
Тестирование методом «черного ящика» происходит с помощью контроля конкретных значений атрибутов системы, которые наблюдаются в качестве реакции системы на некоторый набор конкретных воздействий. Полученные значения автоматически сравниваются с прогнозируемыми, и делается вывод о прохождении теста.
Таким образом, для обнаружения всех ошибок в программном коде системы необходимо проверить все комбинации всех конкретных значений входных данных, что для большинства систем сделать невозможно. Поэтому применяют выборочные данные, соответствующие некоторому разумному выбору, например, использование граничных значений, эквивалентных разбиений.
Такие методы также не дают гарантии обнаружения всех ошибок и адекватности свойств программного кода системы исходным требованиям, так как даже при разумном выборе может быть пропущено некоторое критическое состояние. В данной работе предлагается использовать дедуктивный метод тестирования, где в тестах с целью достижения полного покрытия данных рассматриваются не конкретные значения, а их множества. Для этого используется символьное моделирование формальных спецификаций, в частности, программного кода реактивной системы.
2. Тестирование программного кода реактивных систем с применением формальных методов
Методы автоматизации тестирования разрабатываются в соответствии с моделью процесса разработки программного обеспечения. В качестве исходных требований рассматривается некоторое описание будущей системы на уровне абстракции, соответствующей пониманию заказчика.
Изначально выполняется процедура формализации исходных требований, а также их формальная верификация с помощью специальных инструментов. Далее процесс разработки происходит согласно следующей схеме (рис. 1).
Рис. 1. Процесс разработки
Формальные требования в языке спецификаций, подходящем для верификационных инструментов, представляют модель будущей системы на некотором уровне абстракции.
Здесь нужно зафиксировать уровень абстракции информации, в частности, описание входных и выходных данных, который соответствовал бы и требованиям, и программному коду системы. В этом случае можно автоматически сгенерировать тестовый набор, который был бы применим в тестировании готовой системы.
Программист создает код системы согласно верифицированным требованиям. Он может использовать исходное описание требований, а также и формальные требования. Существует технология, когда из формальных требований возможно сгенерировать программный код автоматически. Полученный код будет соответствовать уровню абстракции требований. Если этот уровень недостаточен, то проводится уточнение программного кода или же понижение уровня абстракции. В этом случае схема выглядит следующим образом (рис. 2).
Рис. 2. Процесс разработки, включающий генерацию кода
Автоматическое тестирование представляет собой процедуру, в которой входом являются исходный программный код системы и некоторый тестовый набор, представляющий последовательности реакций системы в соответствии с входными воздействиями.
Для поддержки традиционного метода тестирования «черного ящика» тестовый набор представляет последовательность входных воздействий на программный код и множество выходных реакций, которые сравниваются с выходными реакциями программного кода. При этом программный код непосредственно выполняется или моделируется.
Использование же символьных методов позволит работать с множествами наборов входных данных. Так, например, на вход программного кода поступает не конкретное значение некоторой переменной, а формула, которая описывает множество значений этой переменной. В этом случае программный код моделируется и на выходе получаем также формулу, которая описывает множество значений выходных данных или некоторое символьное состояние программы. Сравнивая полученную формулу с ожидаемой, можно сделать вывод об адекватности поведения программы изначальным требованиям. Далее мы рассмотрим подробнее эту технологию, определив более точно каждый этап.
3. Формализация требований и генерация тестового набора
Требования к реактивным системам представляют собой описания реакций системы на внешние воздействия. Эти реакции содержат изменение среды системы и выходные сообщения. Для формализации таких требований мы будем использовать язык базовых протоколов, синтаксис и семантика которого описаны в [2], а примеры и методика формализации в [3].
Базовый протокол представляет собой описание реакции системы на внешнее воздействие, а также изменение среды системы, которая определяется ее атрибутами.
Базовый протокол содержит предусловие, в котором представлено триггерное событие, а также условия, при которых оно происходит. Предусловие является формулой в некотором базовом логическом типизированном языке, содержащем арифметические и логические операции.
Базовый протокол также содержит постусловие, в котором могут быть императивные операторы присваивания и формула в базовом языке.
Таким образом, базовый протокол представляет реакцию системы как некоторый переход транзиционной системы, который изменяет ее состояние.
Мы различаем конкретные и символьные модели требований к системе. Состояние конкретной модели требований определяется конкретными наборами значений атрибутов системы. Состояние символьной модели представляет собой формулу в базовом языке модели.
Рассмотрим пример требований к системе, которая моделирует работу некоторого станка по изготовлению неких изделий.
Ю. Станок-автомат должен принимать на вход заготовки двух типов. Станок должен состоять из двух встроенных внутренних механизмов, один из которых воспринимает на вход заготовки типа А, а другой типа В.
Я2. Заготовки типа А поставляются на вход в кассетах по 20 единиц, а типа В по 16 единиц. Новая кассета поставляется на вход в начале дня, если предыдущие заготовки исчерпаны.
Я3. Максимальная производительность станка 10 изделий в день.
Я4. Выходом станка являются изделия, собранные из деталей типа А и деталей типа
В, которые изготавливаются встроенными механизмами соответственно из заготовок типа А и типа В. Для каждого изделия используется по одной детали типа А и типа В.
Я5. Возможны общие потери в производстве станка в количестве 2 изделий как
брак.
Я6. Если количество заготовок меньше, чем производительность станка или механизма, то изготавливается то минимальное количество изделий, которое можно получить из имеющихся заготовок, то есть равное количеству заготовок того типа, которых меньше.
Я7. Если количество заготовок больше или равно производительности станка, то изготавливается количество изделий, равное производительности станка. Остальные заготовки остаются в кассете для следующего раза.
Необходимо построить программу, моделирующую данный, производящий изделия, станок, которая соответствует вышеуказанным требованиям.
Мы рассматриваем эту систему как реактивную, которая воспринимает в качестве входных воздействий количество заготовок типа А и типа В, поступающих в начале дня, а выходной реакцией является количество изготовленных за день изделий.
Определим переменные в этой программе:
А - количество заготовок типа А;
В - количество заготовок типа В;
Б - планируемое количество произведенных изделий;
Б_ОИТ - количество произведенных изделий с учетом возможного брака.
Множество базовых протоколов, соответствующее требованиям, состоит из пяти протоколов. Первые два представляют ввод заготовок в станок. Остальные три моделируют процесс изготовления изделий. Таким образом, получаем следующую модель требований.
Р1: А = 0 <Ввод кассет с заготовками типа А> А := 20 Р2: В = 0 <Ввод кассет с заготовками типа В> В := 16
Р3: (А < В) а (А < 10) <Произвести и выдать изделия в количестве А> Б := А; А: = 0; В :=
В - А; (Б_ОиТ > Б - 2) а (Б_ОИТ < Б)
Р4: (А > В) а (В < 10)<Произвести и выдать изделия в количестве В> Б :=В; В := 0; А := А - В; (Б_ОиТ > Б - 2) а (Б_ОИТ < Б)
Р5: (А < В) а (А > 10) V (А > В) а (В > 10) <Произвести и выдать изделия в количестве 10>
А:= А - 10; В := В - 10; Б:=10; (Б_ОИТ > 8) а (Б_ОИТ < 10)
Мы также определяем порядок на множестве базовых протоколов, который задает последовательность их применения согласно вышеуказанным требованиям. Данный порядок мы можем изобразить в виде диаграммы (рис. 3).
Согласно диаграмме процесс работы станка начинается с ввода заготовок типа А (протокол Р1) и типа В (протокол Р2). Если количество заготовок больше нуля, то их ввод не
производится, что воплощено в
стрелочках, обходящих протоколы Р1 и
Р2. После этого производится изготовление изделий согласно количеству заготовок (протоколы Р3 - Р5).
Зафиксировав некоторое начальное состояние модели требований (А = 0)а(В = 0), мы можем моделировать описанные
требования посредством применения базовых протоколов. При этом мы получаем трассы, содержащие символьное состояние среды после каждого применения базового протокола. Эти трассы могут быть основой теста для поверки программы, которая должна соответствовать вышеизложенным требованиям.
Ниже представлена одна из возможных последовательностей базовых протоколов и соответствующих символьных состояний среды.
Таблица 1. Состояния среды в модели
(А = 0) А {В = 0)
Р1 (А = 20) Л {В = 0)
Р2 (А = 20) Л {В = 16)
Р5 (А = 10) Л {В = 6) Л (£> = 10) Л (Б.ОиТ < 10) Л {0_0иТ > 8)
Р4 {А = 4) Л {В = 0) Л ф = 6) Л (О.ОиТ < 6) А ф_0[/Г > 4)
Р2 {А = 4) А (В = 16) А ф = 6) А ф_0[/Г < 6) А (о.оит > 4)
РЗ (А = 0) А {В = 12) А ф = 4) А (О^ОиТ < 4) А ф_0£/Г > 2)
Р1 (А = 20) А (В = 12) А ф = 4) А (О.ОиТ < 4) А ф_ОС/Т > 2)
Р5 (А = 10) Л (В = 2) А ф = 10) А ф_ОЇ/Г < 10) А ф_ОЇ/Г > 8)
Р4 (А = 8) А (В = 0) А ф = 2) А ф_ОЕ/Г < 2) А ф_0£/Г > 0)
Р2 (А = 8) А (В = 16) А ф = 2) А {Б-ОиТ < 2) А ф_0£/Г > 0)
РЗ (А = 0) А (В = 8) А ф = 8) А ф_ОС/Г < 8) А ф_ОС/Г > 6)
Р1 (А = 20) А {В = 8) А ф = 8) А ф_ОС/Г < 8) А ф_ОС/Г > 6)
Р4 (А = 12) А {В = 0) А ф = 8) А {Б-ОиТ < 8) А ф_ОЕ/Г > 6)
Р2 (А = 12) А (В = 16) А ф = 8) А ф_0[/Г < 8) А ф_0£/Г > 6)
Р5 (А = 2) А {В = 6) А ф = 10) Л {Б^ОиТ < 10) А ф_0[/Г > 8)
РЗ (А = 0) А (В = 4) А ф = 2) А (Б-ОиТ < 2) А ф_ОС/Г > 0)
Р1 (А = 20) Л (В = 4) А ф = 2) Л (Б-ОІ/Т < 2) А ф_ОС/Г > 0)
Р4 (А = 16) А {В = 0) А ф = 4) А ф_ОС/Г < 4) А ф_0£/Г > 2)
Р2 (А = 16) А (В = 16) А ф = 4) А ф_0[/Т < 4) А ф_0[/Г > 2)
Р5 {А = 6) А {В = 6) А ф = 10) А ф_0[/Г < 10) А {Б.оит > 8)
РЗ (А = 0) А {В = 0) А ф = 6) А (0_0ит < 6) А ф_0[/Г > 4)
Рис. 3. Порядок на множестве базовых протоколов
Каждое новое состояние среды получается с помощью предикатного трансформера функцией р!, имеющей в качестве аргументов текущее состояние среды - ЕоШ, предусловие Ргесопё и постусловие Ров1;сопё базового протокола. Таким образом, новое состояние Еп, среды получается следующим образом:
Еп, = р! (ЕоЫ а Ргвеопй, Роъ^опй).
В дальнейшем для моделирования также используется функция обратного предикатного трансформера, позволяющая получать предыдущие состояния среды от текущего.
Еаш = Р!- (Еп,, Ро81еопй) а Ргвеопй.
Описание свойств функции р1 содержится в работе [4].
4. Символьное моделирование программного кода
Система может быть спроектирована любыми способами программистом с использованием исходных требований. Программист может либо написать код, соответствующий этим требованиям, либо использовать генерацию программного кода и уточнять его в соответствии с требуемым уровнем абстракции.
В данных требованиях мы абстрагированы от двух механизмов, обрабатывающих заготовки типа А и типа В, которые являются составляющими системы и о структуре которых на уровне требований мы ничего не знаем. Эти механизмы производят детали типа А и типа В. Каждый из них может иметь определенную производительность и определенный процент брака. При проектировании систем допускают переиспользование ранее спроектированных таких механизмов со своими собственными свойствами в новой системе.
Таким образом, задача программиста состоит в том, чтобы создать код, представляющий более низкий уровень абстракции с учетом информации о составляющих механизмах, а с другой стороны, этот код должен соответствовать исходным требованиям. Для связи модели с ее реализацией естественно требовать, чтобы программа использовала все атрибуты модели требований, в частности, те, которые используются для взаимодействия системы со средой.
Пусть мы имеем некоторые уточнения, относящиеся к работе механизмов А и В, являющихся составляющими системы, заключающиеся в том, что механизм, производящий детали типа А, имеет производительность 15 деталей, а типа В - 9 деталей в сутки. При этом количество возможного брака составляет 3 детали и 1 деталь соответственно.
Учитывая эти уточнения, можно написать С-программу (рис. 4).
main () {
int A—0,B—0,D,AJDUT—0}B^OUT—0; for(i=0;;i-H-){
/* Input of cartridges in machine*/ if (A==0) A = 20; /*sl*/ if(B==0) B - 16; /* s2 */
/* producing of parts of type A */ if (A>—15){A_OUT^A_OUT+ 15;A—A— 15;} /*s3*/ else {A_OUT=A_OUT-hA;A=0;}
//precondition: ZZ=A_OUT /*s31*/ PERCENTA(&A_OUT) ;
//postcondition : (A_OlTE>=ZZ—3)&iS£(A_OUT<=ZZ)
/* producing of parts of type B*/ if (B>=9){B_OUT=B_OUT+9;B=B-9;} /*s4*/ else {BlOUT=B_QUT-+B;B=0;}
//precondition: ZZ=B_OUT /*s41*/ PERCENT_B(&B_OUT) ;
//postcondition : (B.OUT> ZZ l)fe.V(B..fZZ) /^producing of output product*/
if ((A oin> )ioi;t)W-.(a out«? in), { /*sg,*/
D=A_OUT; BJ3UT=B_OUT-A_OUT; A_OUT=0;} if ((A_OUT>B_OOT)fc&(B_OUT<10)) { /*s6 +/
D=B_OUT; A OUT-A OUT H OUT: B_C)UT=0; } i f ((A_OUT<=B_OUT)&&(A_OUT>=10) | ] /* s7 */
(A_ouT>^-Our)fe&(B_oim>=io)) {
A OUT: A OU T II); B_OUT:=B_OUT-10: D: = 10;} produce(D); /*s8*/
//postcondition : (DJ3UT>=D-2)iifc(D_OUT<=TD)
}
>
Рис. 4. С-программа
В данной программе мы уточнили производство деталей типа А и типа В. Но будет ли тогда данная программа соответствовать исходным требованиям?
Для дедуктивного тестирования будет использоваться символьное моделирование С-программы. Мы рассматриваем некоторое подмножество С-программ, состоящих из операторов присваивания, условных операторов, операторов цикла и процедур. В этом случае символьное моделирование будет производиться так же, как и моделирование требований. Отличием будет то, что подпрограммы или библиотечные функции должны быть аннотированы пред- и постусловиями. Таким образом, мы имеем следующие состояния среды после выполнения каждого оператора (рис. 5).
C-statements Svmbolic states of environment s
int A=0,B=0tD, A OUT = O.B OUT = 0; (А=0)л(В=0) л (A_OUT=0) a (B_OUT=0)
for <1=0:3++) { (A=0) л (B=0) л (A_OUT=0) л (B_OUT=0) a (i=0)
if (A=Q) { A = 20;}/*sl*.' (A=20) a (B=0) a (A_OUT=0) a (B_OUT=0) a (i=0)
if(B=0){ В = 16;} ,*s2*/ (A=2Û) л (B=16) л (A_OUT=0) A (B_OUT=û) a (i=0)
if (A>=15) { A OUT= A OUT+ 15A=A- 15;}/*s3*/ (A=5) л (В=1б) a (A_OUT=15) л (B_OUT=Û) a (i=0)
PERCENT_A(&A_OUT): (A=5) л (B=lâ) л (12<=A_OUT<=l 5) л (B_OUT=0) л Гі=0)
if (B>=9) { B_OUT = B_OUT + 9;B = В - 9:} /*s4*/ (A=5) л (B=7) л (12<=A OUT<=15)a(B OUT=9) л
PERCENT_B (&B_OUT); (A=5) л (B=7) л (12<=A OUT'=15) л (8<=B_OUT<=9) л (И0
if ((A OUT>B OUT)&&(B 0UT<1())){ D-B OUT: A OUT= A OUT-В OUT: B OUT = 0; } *s6* (A=5) A (B=7) A (3<=A_OUT<=7) A (8<=D <=9) л fi=0) л (B_OUT = 0)
pioduce(D); (A=5) л (B=7) л (3<=A_OUT<=7) a (i=Q) л (B OUT = 0) A (D_OUT>=6) л (D_OUT<=9)
Рис. 5. Состояния среды в С-программе
5. Дедуктивное тестирование
Входом дедуктивного тестирования (рис. 6) является множество трасс, полученных посредством символьного моделирования модели требований. Другим входом является программный код (в данном случае написанный на С).
Мы рассматриваем тестируемую программу и внешнюю среду, посредством которой управляется моделирующая программа.
Управляющая программа имитирует эту внешнюю среду, подавая на вход моделирующей программы данные вместе с формулой, ограничивающей их значения, в соответствии с символьной трассой, полученной в процессе моделирования требований.
В точках взаимодействия управляющей и тестируемой программы производится контроль значений. В качестве такой точки контроля выбрана точка ответа системы, а именно выдача количества деталей после их производства.
Рис. 6. Процедура дедуктивного тестирования
В точке контроля мы получаем текущее символьное состояние среды в моделирующей программе и сравниваем его с контрольным значением в трассе. Рассматриваются следующие случаи.
1. Символьное состояние среды на контрольной трассе эквивалентно символьному состоянию среды, полученной в результате символьного моделирования С-программы. Это означает, что ответ программы соответствует требуемой модели требований.
2. Символьное состояние среды, полученной в результате символьного моделирования С-программы, следует из символьного состояния среды на контрольной трассе. Это означает, что на уровне кода запрограммировано поведение, которое выходит за рамки требований.
3. Символьное состояние среды на контрольной трассе следует из символьного состояния среды, полученной в результате символьного моделирования С-программы. Это означает, что на уровне кода не запрограммировано поведение, которое определено в требованиях. Трассу, не соответствующую требованиям, можно найти обратным моделированием на уровне требований.
4. Ни одно из символьных состояний не следует из другого. В этом случае программа не удовлетворяет требованиям.
Рассмотрим дедуктивное тестирование на примере, предложенном выше. В данном примере изначально мы имели эквивалентные состояния среды ( A = 0) а ( B = 0) на уровне
требований (в символьной трассе) и в самом коде.
Рассмотрим первую точку контроля программы, которая соответствует точке s8, представляющей функцию produce .
Контрольное состояние среды в трассе:
(A=10) а (B = 6) а (DOUT< 10) а (DOUT > 8).
Состояние среды в С-программе:
(A=5) а (B=7) а (3 < A OUT< 7) а (8 <D OUT< 9) а (i = 0) а (B OUT = 0).
Эти две формулы не являются эквивалентными, что говорит о том, что программа работает не в соответствии со сценариями, представляющими требования.
Для анализа формул возможно рассматривать информационно независимые литералы.
В отношении переменных А и В можно сказать, что значения в С-среде не соответствуют значениям на контрольной трассе, значит, поведение неверно. ~((B = 6) & (B = 7)) и ~((А = 10) &(А = 5)).
В отношении переменно D OUT можно сказать, что С-программа не моделирует те сценарии, которые представлены требованиями.
~((8 < D OUT < 9) & (D OUT <= 10) а (D OUT > 8)).
Имея отрезок трассы от начальных значений до обнаруженного несоответствия, требованиям можно найти место, где появляется это несоответствие, визуальным анализом или методом обратного моделирования, который также описан в работе [4].
Нарушение для переменных А и В возникает на операторах, помеченных s3 и s4, или же производительность блоков, изготавливающих детали А и В, влияет на общую производительность станка. Для переменной DOUT нарушение обнаруживается в момент выполнения функций PERCENT A и PERCENT B, то есть процент брака встроенных механизмов не совместим с требуемым процентом брака.
6. Выводы
Дедуктивное тестирование является методом, который может решить задачу покрытия тестами всех конкретных значений переменных в программе. В данной методике не
рассматривается вопрос покрытия всего кода или же всех требований тестами. Это рассматривается в работах, посвященных символьному моделированию и генерации трасс с заданным покрытием [5].
Вместе с тем в данном методе существуют проблемы, требующие уточнения в реальных индустриальных примерах.
Первая проблема заключается в определении соответствия между переменными в требованиях и переменными в программе. Одним из условий возможности дедуктивного тестирования является соответствие уровня абстракций в интерфейсе между внешним воздействием на программу и выходом программы для требований и для создаваемого кода. Все переменные должны быть четко описаны в требованиях и использованы в коде.
На этапе кодирования при уточнении требований возможны уточнения некоторых абстракций и, соответственно, появление переменных, которые не относятся к переменным, фигурирующим в требованиях. В этом случае мы выбираем переменные, которые информационно зависимы от переменных, участвующих в требованиях, и проверяем формулу среды в С-программе на эквивалентность с формулой состояния среды в требованиях, относя новые информационные переменные под квантор всеобщности.
Другой проблемой является появление недетерминизма в символьном моделировании С-программы вследствие уточнения кода. Таким образом, в коде появляется информация, которая не отражена в требованиях. Соответственно среда С-программы может быть не эквивалентной среде, фигурирующей в требованиях. В этом случае следует проверять не на эквивалентность, а на импликацию формулы среды в требованиях из формулы среды в С-программе. Тем не менее, покрытие данных может быть определено с помощью техники обратного моделирования.
Рассмотренный пример содержит программу, построенную с помощью линейных арифметических преобразований. Используя методы символьного моделирования, разработанные авторами [2], возможно рассматривать также рациональные числа, списки, функциональные и перечислимые типы данных. В качестве будущих работ планируется использовать ряд индустриальных примеров, а также технику инвариантов.
СПИСОК ЛИТЕРАТУРЫ
1. Кулямин В.В. Формальные подходы к тестированию математических функций / Кулямин В.В. // Труды ИСП РАН. - Москва, 2006. - Т. 10. - С. 69 - 114
2. Спецификация систем с помощью базовых протоколов / А.А. Летичевский, Ю.В. Капитонова, А.А. Летичевский (мл.) [и др.] // Кибернетика и системный анализ. - 2010. - № 4. - С. 3 - 21.
3. Летичевский А.А. (мл.) / Об одном классе базовых протоколов / А.А. Летичевский (мл.) // Проблемы программирования. - 2005. - № 4. - С. 82 - 97
4. Свойства предикатного трансформера системы VRS / А.А. Летичевский, А.Б. Годлевский, А.А. Летичевский (мл.) [и др.] // Кибернетика и системный анализ. - 2005. - № 4. - С. 4 - 14.
5. The technology of Automation Verification and Testing in Industrial Projects / S. Baranov, V. Kotlya-rov, A. Letichevsky [et al.] // Proc. of St. Petersburg IEEE Chapter, International Conference, (St. Petersburg, Russia, May 18-21, 2005). - St. Petersburg, Russia, 2005. - P. 81 - 86
6. Clarke L. A system to generate test data and symbolically execute programs / L. Clarke // IEEE Trans. Software Eng. - 1976. - Vol. 2. - P. 215 - 222.
7. Wegbreit B. Symbolic execution and program testing / B. Wegbreit // Communications of ACM. -1976. - Vol. 19. - P. 385 - 394.
Стаття надійшла до редакції 13.09.2013
