Тестирование инструментов для анализа покрытия по метрике MC/DC на соответствие требованиям стандарта DO-178B и пояснениям к нему Евгений Герлиц Отдел технологий программирования, ИСП РАН ИСП РАН

2 Определение MC/DC. Первые 3 условия 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. Пример: 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; }

3 Определение 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, bool c) { if(a & (b | c)) return 1; return 0; } abca & (b | c)abc ftff* ttft** tfff** tftt*

4 История появления MC/DC MC/DC определен в стандарте DO-178B; MC/DC выбран в качестве альтернативы MCC. MCC MC/DC CDC DCCC SC

5 Цель работы Выявление слабых мест и ограничений инструментов для измерения покрытия по MC/DC.

6 Актуальность На данный момент мало знаний о качестве инструментов для анализа покрытия по MC/DC; Инструменты уходят с рынка, полный актуальный список инструментов не обнаружен; Разработчики бортового ПО смогут выбрать инструмент для анализа MC/DC; Разработчики инструментов смогут улучшить свой продукт.

7 Новизна Тестовые ситуации от FAA реализованы для языка Ада; Тестовых наборов для C/C++ не обнаружено; Статей по анализу инструментов для C/C++ не обнаружено.

8 Разбиение на задачи Целевой язык программирования – С (по возможности С++). 1. Составить список инструментов и их свойств; 2. Разработать тестовый набор; 3. Выполнить тестирование инструментов; 4. Выявить слабые места и ограничения инструментов; 5. Оформить результаты в виде статьи; 6. Опубликовать тестовый набор.

9 Разработка тестового набора. Подзадачи 1. Составить список требований к MC/DC, выполнение которых инструментами будет оцениваться; 2. Выявить интерпретации MC/DC, допускаемые сертификационными органами; 3. Выделить тестовые ситуации для проверяемых требований; 4. Реализовать тесты.

10 Источники требований к MC/DC 1. Стандарт DO-178B; 2. Разъяснение стандарта DO-248B; 3. CAST papers; 4. Статьи разработчиков стандарта (FAA, Boeing и др.); 5. Научные статьи посвященные аспектам MC/DC.

11 Перевод DO-178B на русский язык Change control - Управление изменениями. (1) Процесс записи, оценки, утверждения или отказа в утверждении, координации изменений в элементах конфигурации, и формальное присвоение им идентификации конфигурации или внесение их в базовую версию после присвоения идентификации. (2) Систематическая оценка, координация, утверждение или отказ в утверждении и реализация утвержденных изменений в конфигурации или в элементах конфигурации после формального присвоения им идентификации конфигурации или в базовой версии после присвоения идентификации.

12 Пример требования. Decision vs. branch 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; } Требование: все логические выражения, влияющие на поток управления в программе, должны быть объектом покрытия по MC/DC. Пример:

13 Пример требования. Выделение элементарного логического условия и логической операции Требование: логической операцией над логическими операндами должна считаться всякая встроенная в ЯП операция которая: является таковой согласно правилам ЯП либо; используется в качестве таковой и влияет на поток управления в программе. Пример: int f(bool a, bool b, bool c) { if(a & (b | c)) return 1; return 0; }

14 Разработка тестового набора. Подзадачи Составить список требований к MC/DC, выполнение которых будет оцениваться; Выявить интерпретации MC/DC, допускаемые сертификационными органами; Выделить тестовые ситуации для проверяемых требований; Реализовать тесты.

15 Интерпретации MC/DC. Coupled conditions Могут существовать зависимости между значениями элементарных логических условий в логическом выражении. Примеры: Strong coupling: (a & b) | (a & c); Weak coupling: (x > 3) & (x < 5). Каждое вхождение эл. условия – отдельное эл. условие для MC/DC. Unique Cause MC/DC не применим в случае strong coupling.

16 Интерпретации 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.

17 Интерпретации MC/DC. Masking MC/DC Примеры: 1) a & b; 2) a | b; 3) (a & b) | (a & c). Элементарные условия, отличные от целевого, тоже могут изменять свои значения; Только изменение значения целевого элементарного условия должно влиять на значение логического выражения. abac(a&b)|(a&c)abca tttft** ftftf** tfttt** tftff**

18 Разработка тестового набора. Подзадачи Составить список требований к MC/DC, выполнение которых будет оцениваться; Выявить интерпретации MC/DC, допускаемые сертификационными органами; Выделить тестовые ситуации для проверяемых требований; Реализовать тесты.

19 Тестовые ситуации для проверки инструментов Тестовые ситуации, выделенные FAA; логические выражения с операциями короткой логики (&&, ||) и без связанных (coupled) элементарных условий; логические выражения с операциями длинной логики (&, |) и со связанными (coupled) элементарными условиями; Дополнительные тестовые ситуации. Цель – покрыть все требования к MC/DC, выполнение которых оценивается.

20 Стадии разработки тестового набора Составить список требований к MC/DC, выполнение которых будет оцениваться; Выявить интерпретации MC/DC, допускаемые сертификационными органами; Выделить тестовые ситуации для проверяемых требований; Реализовать тесты.

21 Пример типового теста /* * 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; }

22 Обеспечение корректности тестов Вспомогательные утилиты для проверки покрытия Пример утилиты: Вход - логическое выражение и набор векторов из таблицы истинности; Выход - список элементарных условий (conditions), для которых не выполнено требование 4 определения MC/DC. Соблюдение правил кодирования принятых при написании бортового ПО.

23 Стандарт на кодирование 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 ?:).

24 Стандарт на кодирование MISRA C/C++. Пример int32_t f(bool a, bool b, bool c) { int32_t result; if(a && (b || c)) { result = 1; } else { result = 0; } return result; } int f(bool a, bool b, bool c) { if(a & (b | c)) return 1; return 0; }

25 Соблюдать ли MISRA в коде тестов? С одной стороны: Код тестов должен быть адекватным предметной области. С другой стороны: DO-178B не требует соблюдения правил MISRA. Решение: Нарушать только если это необходимо для проверки; Помечать, какие правила MISRA нарушены в тесте.

26 Предполагаемые результаты Актуальный список инструментов; Таблица свойств инструментов; Оценка соответствия инструментов проверяемым требованиям (по каждому требованию); Рекомендации по использованию инструментов – обязательно понимание MC/DC, выявление ограничений инструмента, использование стандарта на кодирование и др.

27 Спасибо за внимание! Вопросы?