CC BY
492
Ицыксон В.М., Моисеев М.Ю., Цесько В.А., Карпенко A.B. Исследование систем автоматизации обнаружения
дефектов в исходном коде программ
В настоящее время программное обеспечение (ПО) является составной частью большинства технических систем. Качество ПО, его надежность и безопасность являются важными характеристиками, влияющими на функционирование системы в целом. В то же время известно, что большинство программных систем содержит ошибки: дефекты, недоработки, уязвимости. Природа возникновения программных ошибок связана с особенностями самих программных систем как одних из самых сложных продуктов деятельности человека. Современные программные системы состоят из множества составных частей и могут содержать до нескольких десятков миллионов строк кода.
Общего решения проблем управления процессом разработки, контроля качества, тестирования и верификации таких сложных систем в настоящее время не существует. Многие фирмы-разработчики вкладывают значительные средства в различные направления программной инженерии, позволяющие повысить качество ПО за счет уменьшения количества дефектов [1]. Некоторыми из этих направлений являются:
• разработка интегрированных средств сквозного проектирования ПО и автоматическая генерация программного кода;
• автоматизация динамического анализа и тестирования;
• верификация программного обеспечения (model checking);
• статический анализ программного кода.
Способы обнаружения дефектов можно
разделить на три группы:
• ручные методы анализа кода: аудит кода, парное программирование, ручное тестирование. ручная верификация программы на соответствие спецификации;
• динамические методы: различные виды тестирования (модульное, функциональное, производительности, стресс-тестирование), анализ трасс выполнения программы, профилирование;
• статические методы: компиляция, статический анализ исходного кода, проверка на
соблюдение стиля кодирования, методы верификации на основе моделей.
Процесс выявления дефектов в ПО является чрезвычайно трудоемким и может занимать значительную часть от всего времени разработки, поэтому задача автоматизации выявления дефектов является актуальной [2]. В данной статье проводится сравнительный анализ существующих средств автоматизации обнаружения дефектов в исходном коде программ.
Автоматизация поиска дефектов
Различные способы обнаружения дефектов характеризуются различной степенью автоматизации. Методы ручной проверки кода имеют высокую трудоемкость и обычно используются только для небольших частей программной системы. Возможности автоматизации этого процесса ограничиваются обеспечением удобного просмотра и навигации по исходному коду программы, а также управлением списком дефектов.
Динамические методы, в частности различные виды тестирования, допускают частичную автоматизацию некоторых стадий (запуск, выполнение, анализ простых результатов). При этом создание тестов, организация воздействия на программу при функциональном тестировании, анализ сложных результатов трудно формализуем и обычно выполняется вручную. Количество тестов, обеспечивающее приемлемый уровень тестового покрытия для любой нетривиальной программы, достаточно велико. Так, общее количество строк кода модульных тестов обычно сопоставимо с размером программы, сложность создания таких тестов зачастую не уступает сложности разработки самой программы. Задачи получения и анализа трасс выполнения программы также плохо автоматизируются.
Среди статических методов обнаружения дефектов компиляция программы выполняется полностью автоматически, при этом современные компиляторы могут обеспечивать обнаружение некоторых дефектов. Средства обнаружения несоответствия стилю кодирова-
ння также решают свою задачу автоматически. Средства, реализующие верификацию кода программы на соответствие спецификации, требуют ручного создания модели программы и формального описания требований спецификации, автоматизируется только сам процесс проверки модели. Известны попытки автоматизации процесса извлечения моделей программ из исходного кода, однако в настоящее время такие подходы имеют серьезные ограничения [3]. Методы статического анализа исходного кода программ также допускают частичную или полную автоматизацию. В этой области ведутся активные исследования [4], результаты которых реализуются в средствах автоматического поиска дефектов.
Можно сделать вывод, что статические методы обнаружения дефектов, особенно методы статического анализа исходного кода, наилучшим образом подходят для автоматизации, поэтому далее будут рассматриваться средства автоматизации поиска дефектов, основанные на этих методах.
Классификация дефектов
Для проведения сравнительного анализа средств поиска дефектов необходимо выделить множество программных дефектов, выявление которых позволит характеризовать качество алгоритмов обнаружения. Использование классификации дефектов при проведении экспериментов позволяет более точно оценить возможности и специализацию каждого исследуемого средства обнаружения дефектов.
Одним из возможных решений является использование одного из существующих стандартов в области информационной безопасности в качестве основы для построения классификации.
На данный момент в области безопасности исходного кода не существует международных или общепринятых стандартов [5]. в частности стандартов таких комитетов, как ISO, IEC и национальных комитетов - NIST. BSI. На статус общепринятого стандарта претендуют стандарты CERT Secure Coding Standard в вариантах для С и С++. Их содержание обобщает многочисленные практики и руководства безопасного кодирования, принятые в различных организациях. Интерес к совместной работе над стандартами с CMU CERT проявляет группа OWGV при комитете ISO/IEC JTC 1/SC 22.
Помимо инициативы CMU CERT существует ряд отраслевых стандартов в области безопасного кодирования. Например, для автомобильной промышленности таким стандартом является MISRA С. Специфика программного обеспечения в этой области накладывает значительный отпечаток на требования к безопасности исходного кода, ограничивая использование многих конструкций языка программирования, что делает этот стандарт неприменимым к программному обеспечению общего назначения.
В области классификации дефектов нужно различать классификации проявлений дефектов. или сбоев, и дефектов как ошибок в исходном коде. В отличие от большого количества классификаций сбоев, ошибки в исходном коде обычно классифицируются неформально. Отдельные организации имеют свои внутренние классификации дефектов. Общепринятыми классами ошибок являются ошибки выделения ресурсов, инициализации, переполнения буфера и др.
В данной работе предлагается собственная классификация дефектов, учитывающая наиболее важные свойства дефектов:
• тип - определяется сущностью дефекта и способом его проявления (способом его влияния на программу);
• частота проявления - насколько часто возникают условия для проявления дефекта в данной программе:
• серьезность - каково негативное влияние проявления дефекта на программу в целом (выдача неверных результатов, зависание, авария);
• распространенность - насколько часто данный дефект встречается в реальных программах;
• стадия - стадия разработки, на которой был внесен дефект:
• сложность - трудоемкость поиска и исправления дефекта, вероятность внесения новых дефектов в процессе исправления:
• приоритет - насколько важно найти и исправить данный дефект.
Разработанная классификация дефектов по типам приведена в таблице 1. Классификация дефектов по типам основана на соотнесении дефектов с объектами и свойствами объектов. Например, тип дефектов RES соотносится с объектами, являющимися ресурсами (динамическая память, файловый дескриптор и другие).
Таблица 1
Классификация дефектов по типам
Номер Тип / Полiип Описание / Примеры
RES Ошибки управления ресурсами
RES-Ol Утечка динамической памяти Повторное выделение памяти, потеря ссылки
RES-02 Утечка дескрипторов Повторное открытие, потеря дескриптора
RES-03 Множественное освобождение памяти Освобождение уже освобожденного указателя
RES-04 Множественное освобождение дескрипторов Повторное закрытие
RES-05 Корректная обработка ошибок выделения ресурса Отсутствие проверок успешности операции выделения ресурса до его использования
RES-06 Ошибки протокола работы с ресурсом Запись в файл, открытый на чтение
BUF Ошибки работы с буферами/массивамн/строками
BUF-0! Ошибка индекса массива Индекс выходит за границу массива
BUF-02 Ошибка арифметики указателей Разыменование указателя, выведенного за границу буфера
BUF-03 Ошибка переполнения буфера Попытка записи в буфер недостаточного размера
BUF-04 Ошибка отсутствия завершающего нуля строки символов Завершающий символ изменен
BUF-05 Арифметические операции с указателями на разные массивы Вычитание, сравнение таких указателей
BUF-06 Арифметические операции с указателем на объект, не являющийся массивом Инкрементирование такого указателя
INI Ошибки отсутствия инициализации
INI-01 Использование неинициализированной переменной В выражениях, условиях, в качестве индекса массива или аргумента аннотированной функции
INl-02 Использование неконтролируемого значения переменной Значение из потока ввода используется в качестве индекса массива, аргумента аннотированной функции
IN 1-03 Разыменование неинициализированного (освобожденного) или нулевого указателя Нулевой указатель передается в аннотированную функцию
IN 1-04 Разыменование неконтролируемого указателя Значение из потока ввода используется в качестве указателя, производится разыменование
1NI-05 Чтение неинициализированного (освобожденного) или неконтролируемого указателя без разыменования, или чтение неинициализированной переменной Не является непосредственно ошибкой, однако может быть потенциальной угрозой
FRM Уязвимость форматной строки
FRM-01 Использование в качестве строки формата неконтролируемого значения Например, прочитанного из потока ввода
FRM-02 Использование опасных функций ввода Функции без контроля размера вводимых данных (gets)
FRM-03 Проверка соответствия списка аргументов форматной строке В форматных функциях (print/)
TYP Ошибки типов
TYP-01 Неявное приведение несовместных типов Преобразование переменной типа int к типу char
TYP-02 Преобразование типов с разным выравниванием Преобразование типов для массивов и структур
Окончание табл. 1
Номер Тип / Подтип Описание / Примеры
TYP-03 Разыменование в неправильный тип Преобразование указателя к указателю на другой тип и разыменование
TYP-04 Ошибки разыменования указателей на функции Вызов такой функции с некорректным набором аргументов
TYP-05 Наличие объявлений функций без аргументов Могут быть вызваны с любым набором аргументов
SCP Ошибки нарушения области видимости
SCP-01 Выдача из функции указателей на локальные переменные Выдача указателя на локальную переменную
ЕХР Ошибки в выражениях
ЕХР-01 Ошибки применения побитовых операторов Побитовый сдвиг переменной с отрицательным значением
ЕХР-02 Наличие побочных эффектов в логических выражениях и некоторых функциях Использование оператора ++ для аргумента 5(геоГ
ЕХР-03 Предположение определенного порядка вычисления подвыражений в выражении Порядок вычисления значений аргументов в вызове функций не установлен
ЕХР-04 Ошибка использования неременных типа int для lloat-арифметики Вычисления части выражения могут быть целочисленными
МАС Ошибки макросов
МАС-01 Ошибки изоляции аргументов Отсутствие скобок вокруг аргументов макроса в теле макроса
МАС-02 Многократное вычисление аргумента Использование вызовов функций в качестве аргумента макроса
Примером связи дефектов со свойствами объектов программы является тип дефектов INI, в котором анализируется свойство наличия/отсутствия инициализации. Выделение подтипов дефектов позволяет детализировать объекты и их свойства, а также структурировать возможные представления дефекта в исходном коде.
Методика исследований средств обнаружения дефектов
Для сравнения возможностей средств автоматизации обнаружения дефектов необходимо провести ряд экспериментов. Методика проведения экспериментов включает в себя выбор показателей, разработку тестов, запуск исследуемых средств на этих тестах, фиксацию результатов и расчет выбранных показателей. Целью проведения этих экспериментов является оценка эффективности обнаружения дефектов различными средствами. Эффективность обнаружения дефекта - комплексное свойство, отражающее качество получаемого результата, степень автоматизации процесса анализа и
сложность его организации, ресурсоемкость. применимость для программ различного размера и класса.
Нас будут интересовать только качество получаемых результатов, которое можно оценить с помощью показателей эффективности. Предлагается использовать в качестве показателей полноту и точность результатов анализа.
Полнота результатов анализа - это показатель. характеризующий долю обнаруживаемых дефектов среди всех дефектов в программе.
Точность результатов анализа - это показатель. характеризующий долю истинных дефектов среди всех обнаруженных дефектов.
Эти показатели зависят от набора дефектов, выявляемых данным средством, а также от возможностей анализа сложных конструкций языка. Рисунок 1 поясняет рассмотренные показатели.
С учетом этих факторов сформированы две группы тестов: простые тесты и комплексные тесты. Простые тесты предназначены для определения перечня обнаруживаемых дефектов.
Найденные дефекты
Дефекты в программе
Ложные
предупреждения
Необнаруженные дефекты
Истинные
обнаруженные
дефекты
Рис. 1. Показатели эффективности
комплексные тесты - для оценки возможностей анализа сложных конструкций языка. Любой тест представляет собой программу на языке С, состоящую из одного файла. Программа содержит один или несколько контролируемых дефектов - дефектов, специально внесенных в код программы. Тестовая программа не содержит других дефектов. Тестовые программы не используют библиотечных функций, требующих аннотирования для выполнения анализа. Решение проводить эксперименты на специально разработанных тестах объясняется необходимостью контролировать все дефекты в анализируемых программах, чего практически невозможно добиться для любой реальной программной системы.
При проведении экспериментов фиксируются пропуски имеющихся в анализируемой программе дефектов и ложные предупреждения. На основе числа пропусков, ложных предупреждений и общего известного числа дефектов рассчитываются выбранные показатели. Результаты обнаружения фиксируются отдельно для каждого типа дефектов, что позволяет сравнивать эффективность обнаружения разных типов дефектов выбранными средствами. Ложные предупреждения фиксируются только для комплексных тестов. Это связано с тем, что простые тесты состоят всего из 10-20 строк кода, в них отсутствуют конструкции языка, не связанные с представляемым дефектом. поэтому они плохо подходят для оценки показателя точности.
Простые тесты направлены на определение способностей обнаружения незамаскированных дефектов рассматриваемыми средствами. В каждом простом тесте присутствует один или несколько локализованных дефектов одного типа. Тестовая программа содержит одну функцию - функцию main.
Разработанный набор простых тестов покрывает все рассмотренные типы и подтипы дефектов, имеющиеся в разработанной классификации. Для каждого подтипа дефектов разработан один или несколько тестов. Некоторые дефекты реализованы в нескольких тестах в разных вариантах представления.
Комтексные тесты разработаны с целью выявления свойств реализованных алгоритмов, они не содержат конструкций, которые нельзя проанализировать статическими методами. В отличие от простых тестов в комплексных тестах дефекты замаскированы в коде программы, для этого используются различные возможности языка программирования, представляющие сложность для статического анализа. Некоторые дефекты являются распределенными: отдельные части дефекта находятся в разных частях программы.
Всего было разработано четыре комплексных теста, покрывающих основные возможности языка С. при этом каждый комплексный тест включает в себя несколько дефектов разных типов. Распределение дефектов по комплексным тестам приведено в таблице 2.
Тест UNI-01 использует основные возможности изменения потока управления, операторы if for. while, break, continue и goto, а также их различные комбинации. Тест UN 1-02 состоит из нескольких процедур с вложенными вызовами и рекурсией. Тест UNI-03 использует указатели, в том числе указатели на функции. Тест UN 1-04 является программой, которая решает задачу интегрирования функции: этот тест использует все возможности языка, использованные в предыдущих тестах.
также продукт компании Fortify Software, специализирующейся на разработке средств анализа программ. Другие программные продукты не исследовались по причине несоответствия предъявленным требованиям или из-за трудностей их получения.
Рассмотрим средства, выбранные для исследования.
Коммерческий продукт IBM RSA предназначен для поиска дефектов в коде на языках C/C++ и Java, интегрируется в среду Eclipse,
Таблица 2
Распределение дефектов по комплексным гестам
Номер Описание RES BUF INI FRM TYP SCP MAC EXP
UNI-01 Ветвления, циклы, break, continue, goto 13 5 6 7 0 0 0 1
UNI-02 Вызовы процедур, в том числе и сложные, рекурсии 11 7 9 4 0 0 0 3
UNI-03 Указатели, в том числе на функции 4 4 8 0 0 0 0 4
UNI-04 Программа расчета интеграла функции 2 6 7 3 0 0 0 0
Проведение экспериментов с использованием комплексных тестов позволяет оценить такие свойства алгоритмов анализа, как способность анализировать указатели и сложные типы данных, способность вычисления условий переходов и циклов, наличие выведения и проверки типов, наличие межпроцедурного анализа и другие свойства.
Все разработанные тесты доступны в [7].
Выбор средств поиска дефектов
Выбранные для исследований средства должны обладать необходимой функциональностью. широко использоваться на рынке проектирования ПО, должны осуществляться их поддержка и развитие разработчиками.
Для проведения экспериментальных исследований были выбраны следующие средства: IBM Rational Software Analyzer 7.0.0. Gimpel FlexeLint 9.0. Microsoft Code Analysis 2008, Fortify Source Code Analysis 5.2, Splint 3.1.2. Среди выбранных продуктов присутствуют средства от лидеров мировой индустрии разработки программного обеспечения: IBM и Microsoft, наследники одного из первых средств поиска дефектов lint - коммерческий продукт компании Gimpel - FlexeLint и поддерживаемое сообществом разработчиков средство Splint, а
существуют версии для ОС Linux и Windows. Статический анализ производится согласно набору правил, структурированных по категориям и важности. Анализ кода разделен на три этапа:
• ревизия кода - каждый исходный файл анализируемой программы проверяется синтаксическим анализатором, который осуществляет поиск шаблонов кода, нарушающих установленные правила;
• поиск зависимостей - осуществляется поиск зависимостей между исходными файлами и межпроцедурный анализ;
• анализ сложности - выполняется расчет метрик сложности программы, определяются части программы с избыточной сложностью и выдаются рекомендации для проведения рефакторинга.
Коммерческие продукты PC-Lint для ОС Windows и FlexeLint для ОС Unix, Linux, Mac OS X. Solaris предназначены для поиска дефектов в программах на языках C/C++. Система производит синтаксический анализ исходного кода, анализ потоков данных и управления, осуществляет межпроцедурный анализ. Средство PC-Lint может быть интегрировано в среду Visual Studio. Основные обнаруживаемые дефекты: ошибки нулевого указателя, работы с памятью.
потока управления, переполнения буфера, переполнения при арифметических операциях, а также нарушение стиля кодирования.
Коммерческий продукт Microsoft Code Analysis является инструментом статического анализа кода на языках С/С++, интегрированным в среду разработки Visual Studio. Средство реализовано в виде набора правил, сгруппированных по категориям. Имеются следующие возможности: создание политики проверки кода, настройка интерпретации найденных уязвимостей. Средство позволяет обнаруживать достаточно широкий перечень дефектов. Принципы построения и используемые методы анализа, реализованные в данном средстве, производителем не описываются.
Коммерческий продукт Fortify SCA предназначен для анализа кода на языках С/С++ и Java. Продукт является кроссплатформенным и может быть интегрирован в различные среды разработки (Visual Studio. Eclipse). В данном средстве реализован межпроцедурный анализ потоков данных и управления. Производится поиск уязвимостей в более чем 200 категориях. Поддерживается возможность глубокой параметризации и настройки проводимого анализа с целью уменьшения числа ложных срабатываний.
Некоммерческий проект Splint предназначен для статического анализа программ на языке С на наличие дефектов. Splint поддерживает внешнее аннотирование, реализует функциональность препроцессора. Выявляемые дефекты: разыменование нулевого указателя. использование неинициализированных переменных или возвращение не полностью определенных структур и объединений, несоответствие типов ошибки области видимости, ошибки управления памятью, в том числе утечки памяти, ошибки работы с аннотированными сущностями, ошибки потока управления. ошибки переполнения буфера, ошибки в макроопределениях, нарушение стиля кодирования.
Проведение экспериментов и анализ результатов
Выбранные средства были исследованы в соответствии с разработанной методикой. Каждый продукт был протестирован на всем множестве простых и комплексных тестов, результаты экспериментов приведены в таблице 3 и таблице 4. Для простых тестов приводится показатель полноты результатов анализа, для комплексных тестов в ячейках таблицы - показатель полноты / показатель точности.
Таблица 3
Результаты простых гестов
Номер теста IBM RSA FlexcLint Microsoft CA Fortify SCA Splint
RES 0% 33% 0% 33% 11%
BUF 3% 48% 16% 44% 6%
INI 16% 73% 50'/» 47% 32'/.
FRM 57% 86% 71% 43% 85%
TYP 0% 46% 50% 0% 38%
SCP 0% 100% 100% 100% 0%
MAC 0% 100% 0% 0% 0%
EXP 11% 88% 33% 11% 50°/,
Таблица 4
Результаты комплексных тестов
Номер теста IBM RSA FlexeLint Microsoft CA Fortify SCA Splint
UNI-01 38%/41% 56%/100% 34%/91% 53%/ 100% 0 %/-
UN 1-02 32% / 50% 47%/100% 35%/92% 56%/ 100% 38%/ 100%
UN 1-03 35% / 39% 20 %/ 100% 35%/ 100% 20°/. / 80°/» 20% / 67%
UN 1-04 56% / 90% 22%/100% 22%/100% 22%/100% 6%/100%
Итог 40% / 55% 35%/100% 32%/96% 34%/95% 16%/89%
Результаты, полученные на простых тестах, существенно различаются, при этом FlexeLint заметно опережает остальные средства. Однако на комплексных тестах все средства, за исключением Splint, показали примерно одинаковые результаты по показателю полноты.
Точность получаемых результатов на комплексных тестах у исследуемых средств достаточно высока, за исключением IBM RSA. Несмотря на то, что это средство показало плохие результаты на простых тестах, оно достигло наилучшей полноты результатов на комплексных тестах. Возможно. это связано с низким порогом принятия решения об обнаружении дефекта в IBM RSA. Обобщенные результаты сравнительного анализа рассмотренных средств приведены на рис. 2.
Заключение
В ходе исследования была предложена классификация дефектов программного обеспечения и методика проведения сравнительного анализа средств обнаружения дефектов, использующая наборы простых и комплексных тестовых программ. На основе предложенной методики были получены оценки показателей эффективности выбранных средств анализа кода.
Все рассмотренные средства обеспечивают автоматизацию процесса выявления дефектов в исходном коде программ. Полнота результатов наилучшего из рассмотренных средств не превышает 40%. Кроме того, все средства анализа, за исключением FlexeLint. позволяют обнаруживать только дефекты определенных типов. Необходимо отметить, что использо-
вание этих средств применительно к реальным системам характеризуется высокой сложностью и трудоемкостью анализа результатов.
Разработанные тесты являются достаточно простыми и несопоставимы по сложности с реальными программными системами. Можно ожидать ухудшения показателей эффективности рассмотренных средств при анализе реальных программ.
Проведенные исследования выявили существенные различия в результатах работы рассмотренных средств. Это позволяет сделать вывод о том. что в средствах используются различные алгоритмы анализа, сама область автоматизированного обнаружения дефектов в исходном коде активно развивается, нет устоявшихся решений и подходов.
Возможные перспективы развития в данной области заключаются в разработке новых, более эффективных алгоритмов статического анализа, комплексировании различных подходов с целью повышения полноты и точности результатов работы средств автоматизированного обнаружения дефектов [6].
Исследование выполнено в рамках работ по государственному контракту № 02.514.11.4081 "Исследование и разработка системы автоматического обнаружения дефектов в исходном коде программного обеспечения" Федерального агентства по науке и инновациям в рамках Федеральной целевой программы "Исследования и разработки по приоритетным направлениям развития научно-технологического комплекса России на 2007-2012 годы".
Рис. 2. Эффективность средств статического анализа
СПИСОК ЛИТЕРАТУРЫ
1. Static analysis for security / В. Chess. G. McGraw // IEEE Security & Privacy. - IEEE. 2004. - Volume 2, Issue 6. - p. 76-79.
2. Брукс Ф. Мифический человеко-месяц или как создаются программные системы. - Символ-Плюс, 2006. - 304 с.
3. First Steps in the Verified Software Grand Challenge /J. Woodcock // IEEE Computer. - IEEE. 2006. -Volume 39, Number 10, p. 57-64.
4. Software Analysis: a Roadmap] / D. Jackson, M. Rinard // Proceedings of the Conference on The
Future of Software Engineering. - Limerick. Ireland: ACM. 2000.-p. 133-145.
5. Secure Coding: Principles & Practices / Mark G. Graff. Kenneth R. Van Wyk. - OReilly. 2003. - 200 p.
6. Principles of Program Analysis/Flemming Niel-son. Hanne R. Nielson. Chris Hankin. - Corr. 2nd printing. - Berlin [etc.]: Springer. 2005. - XXI. 452 p., 56 illus.
7. http://aivt.ftk.spbstu.ru/projects/gk2008/tests/ nov08
Ицыксон В.М., Захаров A.B., Ахин М.Х., Мясное A.B.
Автоматическое обнаружение дефектов программных
систем на основе метода проверки модели
Введение
В настоящее время одной из основных особенностей большинства программных систем (ПС) является их сложность. В некоторых областях объемы исходных кодов ПС могут достигать десятков миллионов строк. Такие объемы и сложная структура ПС. сложность языков программирования могут приводить к появлению ошибок в ПС. Особое место занимает специальный класс ошибок - программные дефекты - ошибки, приводящие к деградации программного обеспечения.
Программные дефекты, как правило, возникают на этапе кодирования по следующим причинам:
• неправильная интерпретация семантики языковых конструкций;
• некорректное использование системных и/или библиотечных функций;
• использование программных объектов и ресурсов без соблюдения требуемых протоколов вызовов;
• и др.
Дефекты в ПС в процессе работы могут приводить к отказам ПС. а также могут быть причиной возникновения потенциальных уяз-вимостей, тем самым значительно ухудшая их безопасность и надежность. То есть программные дефекты являются причиной снижения качества ПС [1].
Стоимость выявления и исправления ошибок в ПС очень высока, при этом стоимость возрастает на каждой следующей стадии жизненного цикла проектирования программного обеспечения. Таким образом, задача разработки технологий автоматического или автоматизированного обнаружения программных дефектов является актуальной.
Состояние предметной области
Выделяют две основные группы методов обнаружения дефектов: на базе статического или динамического анализа [2].
Динамический анализ заключается в проверке программного обеспечения во время или по результатам его выполнения. Основным достоинством такого подхода является то, что анализ выполняется на основе информации о реальном поведении программы во время выполнения. К недостаткам динамического анализа следует отнести сложность повторения пути выполнения программы, изменение временной диаграммы анализируемой системы в результате внедрения в исходный код дополнительных служебных вызовов, учет ограниченного множества возможных путей выполнения программы.
Статический анализ осуществляет проверку программного обеспечения без его выполнения, только на основе исходного кода программ. Преимуществом статического анализа перед
