Тестирование инструментов для анализа покрытия по метрике MC/DC на соответствие требованиям

ИСП РАН
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