ИСП РАН 10.12.12 Тестирование инструментов для анализа покрытия по метрике MC/DC на соответствие требованиям стандарта DO-178B и пояснениям к нему Евгений Герлиц Отдел технологий программирования, ИСП РАН Определение MC/DC. Первые 3 условия 1. 2. 3. Every point of entry and exit in the program has been invoked at least once; Every condition in a decision has taken all possible outcomes at least once; Every decision in the program has taken all possible outcomes at least once. Пример: int main(int argc, char* argv[]) { int a; a = f(false, true, false) + f(true, false, true); return a; } int f(bool a, bool b, bool c) { if(a & (b | c)) return 1; return 0; } 2 Определение MC/DC. Условие 4 4. Each condition in a decision has been shown to independently affect that decisions outcome. A condition is shown to independently affect a decisions outcome by varying just that condition while holding fixed all other possible conditions. Пример: int f(bool a, bool b, { if(a & (b | c)) return 1; return 0; } bool c) a b c a & (b | c) a f t t t t t f f f f f t f t f t * * b * * c * * 3 История появления MC/DC MC/DC определен в стандарте DO-178B; MC/DC выбран в качестве альтернативы MCC. MCC MC/DC CDC DC CC SC 4 Цель работы Выявление слабых мест и ограничений инструментов для измерения покрытия по MC/DC. 5 Актуальность На данный момент мало знаний о качестве инструментов для анализа покрытия по MC/DC; Инструменты уходят с рынка, полный актуальный список инструментов не обнаружен; Разработчики бортового ПО смогут выбрать инструмент для анализа MC/DC; Разработчики инструментов смогут улучшить свой продукт. 6 Новизна Тестовые ситуации от FAA реализованы для языка Ада; Тестовых наборов для C/C++ не обнаружено; Статей по анализу инструментов для C/C++ не обнаружено. 7 Разбиение на задачи Целевой язык программирования – С (по возможности С++). 1. 2. 3. 4. 5. 6. Составить список инструментов и их свойств; Разработать тестовый набор; Выполнить тестирование инструментов; Выявить слабые места и ограничения инструментов; Оформить результаты в виде статьи; Опубликовать тестовый набор. 8 Разработка тестового набора. Подзадачи 1. 2. 3. 4. Составить список требований к MC/DC, выполнение которых инструментами будет оцениваться; Выявить интерпретации MC/DC, допускаемые сертификационными органами; Выделить тестовые ситуации для проверяемых требований; Реализовать тесты. 9 Источники требований к MC/DC 1. 2. 3. 4. 5. Стандарт DO-178B; Разъяснение стандарта DO-248B; CAST papers; Статьи разработчиков стандарта (FAA, Boeing и др.); Научные статьи посвященные аспектам MC/DC. 10 Перевод DO-178B на русский язык Change control - Управление изменениями. (1) Процесс записи, оценки, утверждения или отказа в утверждении, координации изменений в элементах конфигурации, и формальное присвоение им идентификации конфигурации или внесение их в базовую версию после присвоения идентификации. (2) Систематическая оценка, координация, утверждение или отказ в утверждении и реализация утвержденных изменений в конфигурации или в элементах конфигурации после формального присвоения им идентификации конфигурации или в базовой версии после присвоения идентификации. 11 Пример требования. Decision vs. branch Требование: все логические выражения, влияющие на поток управления в программе, должны быть объектом покрытия по MC/DC. Пример: int f(bool a, bool b, bool c) { if(a & (b | c)) return 1; return 0; } int f(bool a, bool b, bool c) { bool d = a & (b | c); if(d) return 1; return 0; } 12 Пример требования. Выделение элементарного логического условия и логической операции Требование: логической операцией над логическими операндами должна считаться всякая встроенная в ЯП операция которая: является таковой согласно правилам ЯП либо; используется в качестве таковой и влияет на поток управления в программе. Пример: int f(bool a, bool b, bool c) { if(a & (b | c)) return 1; return 0; } 13 Разработка тестового набора. Подзадачи Составить список требований к MC/DC, выполнение которых будет оцениваться; Выявить интерпретации MC/DC, допускаемые сертификационными органами; Выделить тестовые ситуации для проверяемых требований; Реализовать тесты. 14 Интерпретации MC/DC. Coupled conditions Могут существовать зависимости между значениями элементарных логических условий в логическом выражении. Примеры: Strong coupling: (a & b) | (a & c); Weak coupling: (x > 3) & (x < 5). Каждое вхождение эл. условия – отдельное эл. условие для MC/DC. Unique Cause MC/DC не применим в случае strong coupling. 15 Интерпретации MC/DC. Основное отличие в интерпретациях 1. Every point of entry and exit in the program has been invoked at least once; 2. Every condition in a decision has taken all possible outcomes at least once; 3. Every decision in the program has taken all possible outcomes at least once; 4. Each condition in a decision has been shown to independently affect that decisions outcome. 16 Интерпретации MC/DC. Masking MC/DC Элементарные условия, отличные от целевого, тоже могут изменять свои значения; Только изменение значения целевого элементарного условия должно влиять на значение логического выражения. Примеры: 1) a & b; 2) a | b; 3) (a & b) | (a & c). a t f t t b t t f f a t f t t c (a&b)|(a&c) a f t * t f * t t f f b * * c a * * * * 17 Разработка тестового набора. Подзадачи Составить список требований к MC/DC, выполнение которых будет оцениваться; Выявить интерпретации MC/DC, допускаемые сертификационными органами; Выделить тестовые ситуации для проверяемых требований; Реализовать тесты. 18 Тестовые ситуации для проверки инструментов Тестовые ситуации, выделенные FAA; логические выражения с операциями короткой логики (&&, ||) и без связанных (coupled) элементарных условий; логические выражения с операциями длинной логики (&, |) и со связанными (coupled) элементарными условиями; Дополнительные тестовые ситуации. Цель – покрыть все требования к MC/DC, выполнение которых оценивается. 19 Стадии разработки тестового набора Составить список требований к MC/DC, выполнение которых будет оцениваться; Выявить интерпретации MC/DC, допускаемые сертификационными органами; Выделить тестовые ситуации для проверяемых требований; Реализовать тесты. 20 Пример типового теста /* * f_1: f(false,true,false), f(true,true,false), * f(true,false,false), f(true,false,true). * Unique Cause MC/DC achieved. * * f_1: f(false,true,false), f(true,false,true). * Unique Cause MC/DC not achieved. * Independence of a, b, c not shown. * * Req_MCDC_N */ int f(bool a, bool b, bool c) { if(a & (b | c)) return 1; return 0; } 21 Обеспечение корректности тестов Вспомогательные утилиты для проверки покрытия Пример утилиты: Вход - логическое выражение и набор векторов из таблицы истинности; Выход - список элементарных условий (conditions), для которых не выполнено требование 4 определения MC/DC. Соблюдение правил кодирования принятых при написании бортового ПО. 22 Стандарт на кодирование MISRA C/C++ Пример правила: The operands of logical operators (&&, || and !) should be effectively Boolean. Expressions that are effectively Boolean should not be used as operands to operators other than (&&, ||, !,=, ==, != and ?:). 23 Стандарт на кодирование MISRA C/C++. Пример int f(bool a, bool b, bool c) { if(a & (b | c)) return 1; return 0; } int32_t f(bool a, bool b, bool c) { int32_t result; if(a && (b || c)) { result = 1; } else { result = 0; } return result; } 24 Соблюдать ли MISRA в коде тестов? С одной стороны: Код тестов должен быть адекватным предметной области. С другой стороны: DO-178B не требует соблюдения правил MISRA. Решение: Нарушать только если это необходимо для проверки; Помечать, какие правила MISRA нарушены в тесте. 25 Предполагаемые результаты Актуальный список инструментов; Таблица свойств инструментов; Оценка соответствия инструментов проверяемым требованиям (по каждому требованию); Рекомендации по использованию инструментов – обязательно понимание MC/DC, выявление ограничений инструмента, использование стандарта на кодирование и др. 26 Спасибо за внимание! Вопросы? 27