Содержание к диссертации
Введение
ГЛАВА 1. Методы разработки программного обеспечения. Методы и средства верификации 12
1.1. Модели процесса создания программного обеспечения 12
1.2. Критические системы 14
1.2.1. Жизненный цикл разработки встроенного бортового программного обеспечения 16
1.3. Методы и средства автоматического доказательства корректности программ. 20
1.3.1. Метод индуктивных утверждений 20
1.3.2. Аксиоматический метод доказательства частичной корректности программ 21
1.4. Методы автоматической генерации тестовых данных 22
1.4.1. Проблемы систем генерации тестовых данных 25
1.4.2. Применение методов генерации тестовых данных для тестирования встроенного бортового программного обеспечения 26
1.5. Методы и средства тестирования программного обеспечения -..28
1.5.1. Статическое тестирование 28
1.5.2. Динамическое тестирование 30
1.5.3. Методы тестирования программного обеспечения 1
.5.3.1. Функциональное тестирование 33
1.5.3.2. Тестирование встроенного бортового программного обеспечения 35
1.6. Обзор существующих систем тестирования 40
1.6.1. VectorCAST. 40
1.6.2. AdaTEST95 41
1.6.3. LDRATestbed. 42
1.6.4. Telelogic TAUGeneration 43
1.6.5. SOFTWARE TESTWORKS. 44
1.6.6. UniTesK. 44
1.7. Средства разработки системы генерации тестов
1.8. Проблемы тестирования встроенного бортового программного обеспечения...47
1.9. Постановка задачи 49
1.10. Выводы 53
ГЛАВА 2. Метод генерации тестовых данных на осно ве функциональных требований 55
2.1. Описание метода генерации тестовых данных 55
2.1.1. Суть подхода 57
2.1.2. Выделение областей эквивалентностей 61
2.1.3. Метод решения логических ограничений
2.2. Модификация метода генерации тестовых данных для определения достижимости заданной точки в программе 79
2.3. Автоматизация процесса тестирования встроенного бортового программного обеспечения 80
2.4. Метод генерации тестовых данных и «недоопределенная» математика 81
2.5. Выводы 87
ГЛАВА 3. Прототип системы поддержки моделирова ния и тестирования встроенного бортового программного обеспечения adacs 89
3.1. Проект системы моделирования и помощи разработки 89
3.1.1. Подсистема разбора исходного кода целевого языка 89
3.1.2. Подсистема хранения и анализа семантической информации 92
3.1.3. Подсистема моделирования исполнения исходного кода 103
3.1.4. Интерфейс взаимодействия пользователя с системой 111
3.1.5. Подсистема сбора и анализа степени покрытия кода 114
3.1.6. Подсистема решения логических уравнений
3.2. Тестирование на основе моделирования 116
3.3. Выводы 124
ГЛАВА 4. Применение прототипа системы моделиро вания и тестирования adacs и метода генерации тестовых данных 126
4.1. Анализ и практика применения разработанных методов генерации тестовых данных 126
4.2. Использование метода генерации тестовых данных в системе генерации тестов matlaber 132
4.3. Выводы 140
Заключение 142
Литература : 144
- Жизненный цикл разработки встроенного бортового программного обеспечения
- Выделение областей эквивалентностей
- Подсистема разбора исходного кода целевого языка
- Использование метода генерации тестовых данных в системе генерации тестов matlaber
Введение к работе
Актуальность темы. В последнее время программное обеспечение проникло во все области промышленности и с каждым годом распространяется все больше и больше, становясь одной из важнейших компонент различных систем Отказы в работе таких систем могут приводить к существенным материальным или временным потерям или представлять угрозу жизням людей
В первую очередь, эти проблемы связаны с потенциальной сложностью программного обеспечения, в особенности одного из важнейших видов программного обеспечения - промышленных программных систем Существенная черта промышленной программы - уровень сложности один разработчик практически не в состоянии охватить все аспекты такой системы
Существует особый класс промышленных программных систем - критические системы, ошибки в которых могут привести к крупным материальным потерям или связаны с риском для жизни людей Данный аспект влияет на требования, предъявляемые к подобным программным системам, и трудоемкость и стоимость их разработки по сравнению с программными системами общего назначения возрастает
К такому классу систем относится встроенное бортовое программное обеспечение К этому классу программного обеспечения предъявляются повышенные требования по надежности, поскольку от данной программной системы зависят жизни людей или же большие материальные ценности
Ключом к решению этих проблем является организация и структуризация процесса создания программного обеспечения, реализация технологических принципов промышленной разработки программных систем Эти технологии и методы регламентируются рядом отечественных и международных стандартов, таких, как ISO 9001, IEC 61508 (CENELEC), RTCA/DO-178B, ED-12B, КТ-178В Согласно этим стандартам, необходимым условием обеспечения качества программной системы является обязательная верификация всех результатов работы на каждом из этапов жизненного цикла системы
Проблема верификации встроенного бортового программного обеспечения вызывает существенные трудности Это связано с тем, что существует масса факторов, которые не позволяют провести полную и корректную верификацию системы
недостаток времени,
большое количество входных параметров системы,
трудности с определением ожидаемых выходов,
проблемы неполноты и корректности требований,
отсутствие подготовленных кадров и курсов их подготовки,
неприспособленность существующего инструментария,
недооценка процессов верификации со стороны менеджмента
Работы в данной области ведутся в течение нескольких десятков лет силами многих российских и зарубежных ученых Р Андерсон, Р Л Бейбер, Б Бей-
зер, Б Корел, В В Кулямин, В В Липаев, Г Майерс, А.Д Оффут и др Вместе с тем существует достаточно небольшое количество работ, связанных с автоматизацией процесса разработки тестов при тестировании на основе требований
Работа посвящена одному из аспектов верификации программного обеспечения — методам и средствам покомпонентного тестирования встроенного бортового программного обеспечения на основе требований и методам автоматической генерации тестовых данных на основе требований
Объект и предмет исследования Объектом исследования является процесс покомпонентного тестирования встроенного бортового программного обеспечения в соответствии со стандартом RTCA/DO-178B Предметом исследования данной диссертации являются методы и средства автоматизированной и автоматической генерации тестовых данных, используемые при структурном и динамическом тестировании программных систем, призванные помочь тести-ровщикам увеличить количество обнаруживаемых дефектов и степень покрытия исходного кода исследуемых программных систем Данные методы рассматриваются с точки зрения возможности их приложения к тестированию встроенного бортового обеспечения с применением метода тестирования на основе моделирования
Цель диссертационной работы состоит в разработке методов и средств генерации наборов входных данных для тестирования встроенного бортового программного обеспечения на основе требований для обнаружения дефектов Объектом анализа является исходный код тестируемой системы, а ограничения строятся либо автоматически, исходя из предположения, что программа должна в процессе выполнения достичь некоторой контрольной точки, либо вручную на основе функциональных требований к системе Данная цель предполагает решение нижеприведенных задач
исследовать существующие методы и средства тестирования программ, подходы к доказательству корректности программ и генерации тестовых данных и их применимость к тестированию встроенного бортового программного обеспечения,
разработать метод генерации тестовых данных, позволяющий выявить дефекты в коде программной системы, связанные с несоответствием кода функциональным требованиям, и недокументированные возможности,
разработать метод генерации тестовых данных, который бы позволил автоматически получать наборы входных значений, позволяющие обеспечить покрытие кода, и обнаруживать недостижимые участки кода,
разработать прототип системы анализа встроенных бортовых программ и помощи при разработке тестов,
экспериментально проверить разработанные методы и программные средства
Методы исследования. При разработке математического и программного обеспечения в диссертационной работе используются методы теории доказательства корректности программ, методы генерации тестовых данных, теории
построения трансляторов, математического программирования и оптимизации и методы объектно-ориентированного программирования Научная новизна работы заключается в следующем
разработана классификация отказов и дефектов программного обеспечения, вызванных несоответствием между кодом и предъявляемым к нему функциональным требованиям,
на основе метода выводы предусловий и постусловий разработан метод построения логических ограничений, описывающих области входных значений, приводящих к возникновению отказов в соответствии с разработанной классификацией отказов и дефектов на основе требований,
разработан метод поиска решения логических уравнений вида Р(Х) = = True на основе метода внешних точек (внешних «штрафных» функций) для задачи математического программирования,
на основе комбинации методов построения логических ограничений и ре
шения логических уравнений разработаны методы генерации тестовых
данных, при которых возникают отказы встроенного бортового программ
ного обеспечения, вызванные несоответствием кода требованиям
Практическая значимость состоит в том, что разработанные методы ге
нерации тестовых данных позволяют обнаруживать дефекты при компонент
ном тестировании встроенного бортового программного обеспечения в соответ
ствии с функциональными требованиями, а также автоматизировать работу по
составлению тестовых планов и сократить общие временные и материальные
затраты на этапе тестирования
Реализация результатов. Результаты, полученные в работе, имели следующие научно-практические приложения
на основе разработанного метода генерации тестовых данных был реализован и использовался в учебном процессе прототип системы поддержки тестирования и генерации тестов ADACS, что подтверждается актом об использовании результатов диссертации от 14 сентября 2007 года,
на основе метода генерации тестовых данных был разработан метод тестирования логических схем, описанных в системе Matlab,
метод тестирования логических схем был реализован в рамках проекта
разработки ядра XMath для системы генерации тестов MatLaber и исполь
зовался в проектах по тестированию встроенного бортового программ
ного обеспечения ООО «ДС БАРС», что подтверждается актом об исполь
зовании результатов диссертации от 21 сентября 2007 года
Апробация работы. По теме диссертации опубликованы 13 работ и сде
ланы доклады на следующих семинарах и конференциях
Научные сессии МИФИ, 2001 и 2003-2005 гг,
XII, XIII, XV, XVI Международные научно-технические семинары
«Современные технологии в задачах управления, автоматики и обработки
информации», Алушта, 2003,2004,2006,2007 гг,
The 9th International Workshop on Computer Science and Information
Technologies (CSIT'2007), Уфа, 2007 г
На защиту выносятся:
классификация отказов и дефектов встроенного бортового программного обеспечения, вызванные несоответствием кода требованиям,
метод построения логических ограничений на основе разработанной классификации дефектов;
метод решения логических уравнений на основе метода внешних точек для задачи математического программирования,
метод генерации тестовых данных, при которых возникают отказы встроенного бортового программного обеспечения, вызванные несоответствием кода требованиям, на основе комбинации методов построения логических ограничений и решения логических уравнений,
программные реализации прототипа системы поддержки тестирования и генерации тестов ADACS и ядра XMath для системы генерации тестов MatLaber, реализующие разработанные методы генерации данных Структура работы. Диссертация изложена на 143 стр основного текста
(с приложениями — 177 стр), состоит из введения, четырех глав, заключения, списка литературы из 140 наименований и четырех приложений Содержит 37 рисунков, восемь таблиц
Публикации.
Основные научные результаты диссертации опубликованы в 13 научных работах.
Жизненный цикл разработки встроенного бортового программного обеспечения
Процесс создания программного обеспечения - это множество взаимосвязанных процессов и результатов их выполнения, которые ведут к созданию программного продукта. Процесс создания программной системы может начинаться с разработки программной системы с «нуля», но чаще всего новое программное обеспечение разрабатывается на основе существующих систем путем их модификации.
Существует большое количество методов разработки программного обеспечения. Хотя не существует «идеального» процесса создания программного обеспечения, во многих организациях-разработчиках пытаются его усовершенствовать, поскольку он может опираться на устаревшие технологии и не включать лучших методов современной инженерии программного обеспечения.
Совершенствовать процесс создания программных систем можно разными путями. Например, путем стандартизации, которая уменьшит разнородность используемых в1 данной организации технологий. Это, в свою очередь, приведет к совершенствованию внутренних коммуникаций в организации, уменьшению времени обучения- персонала и сделает экономически выгодным процесс автоматизации разработок.
Модель создания программного обеспечения представляет собой общее абстрактное представление данного процесса. Чаще всего они представляют обобщенные модели, основанные на архитектурном подходе. Эти модели не содержат точного описания всех стадий процесса создания программных систем. Они являются полезными абстракциями, помогающими приложить различные подходы и технологии к процессу разработки. Кроме того, процесс создания больших систем не является единым, а состоит из множества различных процессов, ведущих к созданию отдельных частей большой системы.
Существует несколько различных моделей создания программного обеспе 13 чения.
1. Каскадная модель. Основные базовые виды деятельности, выполняемые в процессе создания ПО, представляются как отдельные этапы этого процесса [24; 40; 43; 59].
2. Эволюционная модель разработки ПО. Здесь последовательно перемежаются этапы формирования требований, разработки ПО и его верификации. Первоначальная программная система быстро разрабатывается на основе некоторых абстрактных общих требований. Затем они уточняются и детализируются в соответствии с требованиями заказчика. Далее система дорабатывается и проверяется в соответствии с новыми уточненными требованиями [121].
3. Модель формальной разработки систем. Основана на разработке формальной математической спецификации программной системы и преобразовании этой спецификации посредством специальных математических методов в исполняемые программы. Проверка соответствия спецификации и системных компонент также выполняется математическими методами [87].
4. Модель разработки ПО на основе ранее созданных компонент. Предполагает, что отдельные составные части программной системы уже существуют, т.е. созданы ранее. В этом случае технологический процесс создания ПО основное внимание уделяет интеграции отдельных компонент в общее целое, а не их созданию [87].
5. Модель пошаговой разработки. Является промежуточной между эволюционной и каскадной моделями. В соответствии с данной моделью, в самом начале разработки определяются наиболее важные сервисы, на основе этой информации определяются основные шаги и их последовательность. На первых шагах детализируются требования для сервисов, а для их реализации используют один из подходящих методов разработки программного обеспечения [134].
6. Спиральная модель разработки. В данной модели нет фиксированных этапов, а процесс разработки представлен в виде спирали. Каждый виток спирали соответствует одной стадии процесса создания ПО. Эта модель может включать в себя любые другие модели разработки систем [84]. На практике могут применяться и гибридные модели, позволяющие выполнить отдельные процессы разработки подсистем и весь процесс создания ПО итеративно. Примерами подобных подходов являются модель пошаговой разработки и спиральная модель разработки.
Большую популярность приобрел метод экстремального программирования, основанный на модели пошаговой разработки. Он основан на пошаговой разработке малых программных компонент, реализующих простые функциональные требования, постоянном вовлечении заказчика в процесс разработки и обезличенном программировании [20].
Также в последнее время все большую популярность приобретает предлагаемый фирмой Rational Унифицированный Процесс Разработки программного обеспечения. Данная модель управляется.вариантами использования, ориентирована на архитектуру, и является инкрементной и итеративной [73].
Обычно отказы систем, управляемых с помощью программного обеспече-нияобщего назначения, вызывают неудобства, но не приводят к существенным последствиям. Однако имеются системы, отказы которых могут приводить к значительным экономическим потерям, физическим повреждениям или создавать угрозу человеческой жизни. Такие системы обычно называют критическими. Функциональная надежность - необходимое требование к критическим системам, и все ее составляющие (работоспособность, безотказность, безопасность и защищенность) очень важны.
Существует три основных типа критических систем.
1. Системы, критические по обеспечению безопасности, т.е. системы, отказ которых приводит к разрушениям, создает угрозу жизни человека или наносит вред окружающей среде.
2. Системы, критические для целевого назначения, т.е. системы, отказ кото 15 рых может привести к ошибкам в действиях, направленных на обеспечение определенной цели (например, системы обслуживания научной аппаратуры на борту космического корабля). 3. Системы, критические для бизнеса. Отказ таких систем может нанести вред делу, в котором они используются (например, системы обслужива-ния счетов клиентов). Для критических систем необходимо гарантировать высокое качество разработки спецификации и точность отражения в ней реальных потребностей пользователей. Условия надежности критических систем порождают как функциональные, так и нефункциональные требования.
Выделение областей эквивалентностей
Как было показано в разделе 1.8, процесс тестирования является одним из самых сложных и ресурсоемких этапов разработки. И одна из проблем данного процесса связана с генерацией тестовых данных. Причем данная проблема существует как в случае тестирования программного обеспечения методами «белого» ящика (раздел 1.5.3), так и при тестировании методами «черного» ящика (раздел 1.5.3.1). Отличие между этими двумя подходами состоит только в разных входных документах, которые являются основанием для генерации входных и ожидаемых выходных данных: в первом случае это формальные требования к программному обеспечению, а во втором - преимущественно исходный код программной системы.
При тестировании встроенного программного обеспечения (раздел 1.5.3.2) могут использоваться преимущественно те же самые методы, которые применяются при тестировании методами «черного» ящика. Это связано с тем, что основным входным документом в данном случае являются» формальные требования к бортовой системе. В.данношглаве предложен один из методов генерации тестовых данных на основе контрактных обязательств- или функциональных требований к системе.
Разработанный метод невозможно полностью отнести к одной определенной группе, так как данный-метод объединяет несколько подходов. В нем частично используется аксиоматический метод доказательства корректности программ, а также методы целевой генерации тестовых данных и генерации тестовых данных на основе определенного пути [5; 6; 7].
Данный метод, также как и метод динамического сокращения области определения (раздел 1.4), позволяет не задавать начальные значения переменных, а вычислять их на основе области определения переменных.
Следует заметить, что хотя разработанный подход и не является аналогом процесса символического вычисления, элементы символического вычисления могут использоваться при работе данного метода. Он позволяет генерировать множество диапазонов значений, представляющих условия, при которых заданный путь, ветвь или вообще вся программа может быть выполнена. Кроме этого, в данном методе частично применяются методы «расслоения» программ (раздел 1.4).
Метод позволяет получать значения переменных в процессе прохождения по графу программы. При этом для каждой переменной задается начальная область определения и каждый раз, когда выполняется некоторая ветвь в программе, области определения переменных, входящих в условие для данной ветви, ограничиваются таким образом, чтобы соответствующий предикат оставался истинным. По окончании процедуры образуется система условий, определяющих диапазоны входных переменных, при которых отдельный путь или же вся программа в целом может быть выполнена.
Метод генерации тестовых данных использует комбинацию статического и динамического анализа. Статический анализ исследует программный код без его исполнения - информация о программе получается из самого кода. Динамический анализ основан на исполнении или имитации исполнения программы. В целом, динамический анализ является более тяжелым методом анализа (как при реализации, так и в работе), но и позволяет получить больше полезной информации.
Символическое исполнение используется для получения ограничений для входных переменных. Для этого некое начальное условие обрабатывается специальным образом так, чтобы удовлетворять условиям, наложенным на программу или некоторый путь в этой программе.
Используя разработанный метод возможно получение точных диапазонов входных переменных, при которых данная программа или отдельный путь будет гарантированно выполнен. Хотя возможны случаи, когда данные диапазоны могут включать не все значения, при которых возможно выполнение кода, так как на финальном этапе используются эмпирические методы для вычисле 57 ния данных диапазонов.
Приблизительные методы позволяют решить проблему обработки сложных выражений. Данная проблема в других методах чаще всего либо игнорируется, либо используется случайная генерация данных. Задача заключается в том, чтобы найти для заданного выражения и его значения диапазоны значений переменных, входящих в это выражение, при которых получается требуемое значение.
Разработанный метод генерации тестовых данных базируется на подходе генерации данных для всех путей в программе на основе требований и исходного кода тестируемой функции/процедуры системы и позволяет решить проблему поиска дефектов программного обеспечения, вызванных несоответствием ПО требованиям. Также, модифицировав разработанный метод, удается оценить общее количество допустимых путей, общее минимальное количество тестовых случаев, а также сгенерировать наборы тестовых данных, обеспечивающие максимальную степень покрытия кода [15; 17];
Разработанный метод генерации тестовых данных включает два основных этапа.
1. Используя подход к тестированию на основании областей (или классов) эквивалентности и методы теории аксиоматического доказательства корректности программ (в частности, методы построения предусловий на основании требований и вывода предусловий к программам на основании постусловий), строятся логические ограничения, описывающие множества входных значений, вызывающие отказы 1-го, 2-го и 3-го класса, и их подмножества, образованные классами эквивалентности. Предполагая, что требования корректны и внутренне не противоречивы, а тестируемые программы являются статическими функциями/процедурами, реализованными на императивных языках программирования, эти подмножества являются разбиениями соответствующих множеств(доменов) входных значений.
Подсистема разбора исходного кода целевого языка
Диаграмма классов подсистемы трансляции Данное представление модели модуля разбора кода автоматически вытекает из структуры кода, производимого системами flex++ и bison++. Для начала процесса разбора текста программы необходимо сначала открыть соответствующий файл с исходным кодом на чтение. Затем, файловый дескриптор, связанный с данным файлом, должен быть передан на вход методу SetScannerl-nOut( new_file_handler , stdout). Если анализ исходного кода должен осуществляться с устройства стандартного .ввода, то нет необходимости открывать файл и вызывать метод SetScannerInOut(). Затем достаточно просто вызвать метод yyparse(), который произведет разбор исходного кода исследуемой программы. По окончании работы необходимо произвести реинициализацию сканера с помощью метода ScannerReInit() (если предполагается разбор другого файла). Метод ClearQ очищает все таблицы и инициализирует блок парсера. Метод Save() позволяет сохранять информацию из библиотеки, образуемой при трансляции исходных файлов, в файл на диске, а метод Load() - загружать библиотеку с диска в память системы.
Использовать код, производимый данными системами, невозможно - необходимо дополнительное проведение семантического анализа и генерация некоторого кода, который затем можно было бы сохранять/загружать, моделировать его выполнение, а также обеспечить доступ к информации, характеризующий данный код. При этом данная система может не быть полноценным компилятором в том смысле, что от нее не требуется полной проверки семантики программы. Связано это с тем, что тестирование выполняется уже над кодом, который является корректным относительно используемого компилятора. Поэтому можно применять упрощенную модель правил целевого языка.
В результате, основной целью разработки системы стала разработка унифицированной библиотеки классов, позволяющей специфицировать все языковые конструкции императивных языков программирования, проводить имитационное исполнение кода, обеспечивать доступ к семантической и синтаксической информации каждой конструкции.
Для решения данной задачи был выбран следующий подход: каждый класс, представляющий конкретную конструкцию некоторого абстрактного языка программирования (тип, оператор, функция/процедура), содержит не только семантическую информацию о данной конструкции, но и является моделью данной конструкции. Это подход позволяет решить сразу две задачи -предоставить систему хранения семантической и синтаксической информации, и автоматическое построение модели анализируемого кода. Затем, используя механизм виртуальной машины, может имитироваться исполнение исследуемой программы на основе построенной модели. Кроме того, подобное представление существенно упрощает разработку системы, так как при подобной реализации достаточно реализовать интерфейс одного класса для каждой языковой конструкции. Недостатком данного подхода является увеличение расхо да памяти на хранение всей информации об объектах программы. Но так как данная система является экспериментальной, а также из-за недостатка ресурсов, было принято решение выбрать описанный выше подход. Чтобы упростить процесс поиска и процесс хранения библиотеки, было решено объединить эти два модуля в один. Для этого использовался подход на основе таблиц символов компилятора.
Как известно, основная задача таблиц символов состоит в том, чтобы установить соответствие между объектом программы (переменной, модулем, функцией) и соответствующей семантической информацией (для переменной и функции - ее тип, для модуля и функции - код данных объектов). Также таблицы символов используются для отслеживания области видимости и информации о связях имен.
Для обеспечения этих функций механизм таблиц символов должен обеспечивать эффективный поиск и добавление новых элементов в таблицу. Чаще всего для этого используются методы на основе линейных списков и хэш-таблиц. Но в данном проекте, благодаря средствам языка C++ и абстракциям, предоставляемым стандартной библиотекой, удалось выбрать более простой и удобный подход к реализации таблиц символов.
Для этого таблицы были включены в состав некоторых классов, реализующих функциональность определенных конструкций целевого языка программирования, таких как блок операторов, условные конструкции, циклические конструкции и так далее, то есть все те конструкции, в рамках которых возможно появление новых символов в программе. Это позволило построить иерархическую древовидную структуру, которая обеспечивает простоту навигации по областям видимости. Каждая область имеет свою собственную таблицу символов, не пересекающуюся с таблицей других областей. В данном проекте локальные таблицы символов были реализованы на основе ассоциативных массивов.
Для реализации таблиц символов была выбрана абстракция «словаря» с повторениями, когда ключу (индексу ассоциативного массива) может сопостав 94 ляться несколько значений (элементов ассоциативного массива). В данном случае ключом является имя объекта программы (модуля, функции, типа, переменной), а значением - соответствующая семантическая и синтаксическая информация.
Абстракция «словаря» с повторениями была выбрана с. целью упрощения реализации поддержки механизма «перегрузки» функций. Механизм перегруженных функций позволяет программисту использовать одно, имя функции для операций, выполняемых с различными типами. В случае использования целевым языком данного механизма, абстракция «словаря» с повторениями позволяет наиболее простым и естественным способом осуществлять навигацию по таблице символов.
Класс CSearchStorage (рис. 16) реализует интерфейс таблиц поиска. Скрытый член класса Storage представляет собой объект типа multimap, в котором ключом является строка символов (имя переменной, модуля, функции), а элементом - семантическая информация.о хранимом объекте.
Использование метода генерации тестовых данных в системе генерации тестов matlaber
При этом ряд схем пришлось упрощать в связи с псевдодинамической сущностью данных схем: ряд блоков могут возвращать значение на основе ранее вычисленных значений. Для таких блоков должен проводиться дополнительный анализ.
Приведенные описания показывают, что разработанный метод генерации тестовых данных для обнаружения дефектов может быть расширен и для генерации тестовых данных на основе требований. Кроме того, это показывает, что разработанный метод был достаточно легко адаптирован и расширены его возможности, позволяющие оперировать даже относительно слабо формализуемыми требованиями.
Вместе с тем был отмечен и ряд недостатков, присущих ядру XMath: достаточно большое генерируемое количество целевых функций и невысокая скорость работы ядра в случае, если для логического ограничения не существует ни одного решения.
В связи с этим было принято решение о разработке комбинированного ядра генерации тестовых XBool+XMath, в котором ядро XBool будет отвечать за генерацию тестовых данных исключительно для логических переменных и блоков, а ядро XMath — только для математических блоков. Это позволит и сократить количество целевых функций для ядра XMath и, соотвественно, существенно увеличить общую скорость их решения.
Исследование эффективности прототипа системы поддержки моделирования и тестирования встроенного программного обеспечения ADACS и ядра генератора тестовых данных для логических схем XMath показало, что разработанный метод генерации тестовых данных может быть использован в реальных проектах.
1. Разработанный метод генерации тестовых данных для обнаружения дефектов во встроенном программном обеспечении был использован для детектирования тяжело обнаруживаемых дефектов, вызванных несоответствием кода системы формальным требованиям. Как показала практика, даже для относительно небольших участков кода метод позволяет обнаруживать большее количество дефектов, чем способен тестировщик.
2. Прототип системы поддержки тестирования показал свою применимость в процессе обучения студентов методам и средствам тестирования встроенного бортового программного обеспечения. Ручной метод генерации логических ограничений позволил ознакомить их с деталями одного из формальных методов доказательства корректности программного обеспечения (аксиоматический метод). Наличие отладчика и средств сбора покрытий кода также позволило продемонстрировать весь жизненный цикл процесса покомпонентного тестирования в соответствии со стандартом RTCA/DO-178В.
3. Использование метода генерации тестовых данных в проекте разработки ядра генератора XMath доказало его эффективность и применимость для решения задачи генерации тестовых данных на основе формальных требований. Достаточно быстрое и простое введение дополнительных операций также показало его гибкость и настраиваемость.
4. Несмотря на положительные отзывы о работе разработанного метода генерации тестовых данных, следует отметить, что ряд моментов требуют дополнительной доработки. Одна из проблем состоит в достаточно большом времени работы метода в том случае, если для логического утверждения не существует решения. Проведенные эксперименты показывают высокую эффективность разработанных методов и средств генерации тестовых данных. Использование системы генерации тестовых данных MatLaber с ядром XMath увеличивает скорость генерации тестовых данных в 5-50 раз в зависимости от сложности схемы и квалификации тестировщика. Это позволяет сократить общее время тестирования на 20-60%.
Наличие защитных механизмов позволяет использовать систему ADACS в учебном процессе. Это позволяет ускорить процесс подготовки специалистов и повысить их общую квалификацию. Наличие математического аппарата дает возможность соединить теоретические и практические навыки, дав более глубокое понимание процесса верификации программных систем.
Кроме того, наличие таких средств, как анализатор/генератор степени покрытий исходного кода на основе метрик, совместимых со стандартом RTCA/DO-178B, позволяет более полцо понять структуру данного документа и требования, налагаемые данным документом на процедуру верификации бортовых систем различных уровней критичности.
Методы генерации тестовых данных и прототип системы поддержки тестирования ADACS были использованы в Московском Инженерно-физическом Институте (Государственном Университете) в процессе обучения студентов по курсу «Верификация и Сертификация ПО».
Система генерации тестовых данных XMath на основе разработанного метода генерации тестовых данных была внедрена в ООО «ДС БАРС» в проектах по тестированию систем встроенного бортового программного обеспечения
Похожие диссертации на Методы и средства генерации данных для тестирования встроенного бортового программного обеспечения
