ГОСТ Р ИСО 26262-6—2014
Окончание таблицы 10
Методы
УПБА
АВсD
1е
♦♦+
+♦+
1dТестирование используемых ресурсов4
+♦+++
Сравнительное испытание между моделью и кодом, если
оно применимоd:
"Данный метод реализуется на основе требований к программному обеспечению на уровне модуля.
61Данный метод включает в себя введение произвольных неисправностей (например, путем повреждения зна
чений переменных, введения мутаций кода или повреждения значений регистров процессора).
е>Некоторые аспекты теста использования ресурсов могут быть оценены правильно, только когда тестирова
ние модуля программного обеспечения выполняется на целевых аппаратных средствах или если эмулятор
целевого процессора поддерживает тесты использования ресурсов.
Данный метод требует модель, которая может имитировать функциональные возможности программных
модулей. На вход модели и кода подаются одинаковые данные, а результаты сравниваются друг с другом.
9.4.4Для получения подходящих тестов для тестирования модуля программного обеспечения в
соответствии с требованиями 9.4.3 должны быть использованы методы, перечисленные в таблице 11.
Т а б л и ц а 11- Методы получения тестов для тестирования модуля программного обеспечения
Методы
Ав
УПБА
СD
1аАнализ требований
1ЬГенерация и анализ классов эквивалентности “
1сАнализ граничных значений
+♦++♦ж♦+
++♦♦+++
++♦■»+
1dПредположение ошибок4
+■f+
+
*" Классы эквивалентности могут быть определены на основе разделения входных и выходных данных так.
чтобы тестовые значения вьйрались из каждого класса.
Ь| Данный метод применяется к интерфейсам, у которых значения приближаются и пересекают границы, а
также выходят за границы диапазона значений.
11Испытания с предположением ошибок могут быть основаны на данных, полученных из «обобщения опыта» и
экспертной оценки.______________________________________________________________________________
9.4.5Для оценки полноты тестов и демонстрации того, что непреднамеренная функциональ
ность отсутствует, должен быть определен охват требований на уровне модуля программного обес печения
и должно быть измерено структурное покрытие с помощью метрик, перечисленных в таблице
12. Если достигаемое структурное покрытие считается недостаточным, то либо должны быть специ
фицированы дополнительные тесты, либо должно быть предусмотрено обоснование.
Примеры
1 Анализ структурного покрытия может выявить недостатки в контрольных при мерах
при тестировании на основе требований, несоответствия в требованиях, нвиспол-
няемый код, выводящий из строя код или непреднамеренную функциональность.
2 Для уровня покрытия, достигаемого на основе принятого неисполняемого кода
(например, кода для отладки) или сегментов кода в зависимости от различных конфигура
ций программного обеспечения, может быть предоставлено обоснование; либо не охвачен
ный покрытием код может быть верифицирован с помощью дополнительных методов
(например, с помощью проверок).
в
Т а б л и ц а12 - Метрики структурного покрытия на уровне модуля программного обеспечения
Методы
А
УПБА
СD
1аПокрытие операторов
1ЬПокрытие ветвей
1сИзменение условий / Покрытие результатов решений (МСЮС)
♦++♦♦♦
++♦ ♦+ +♦
♦ ++ +♦
П р и м е ч а н и я
1Структурное покрытие может быть определено путем использования соответствующих программных ин
струментальных средств.
2 В случае разработки на основе модели анализ структурного покрытия может быть выполнен на уровне
модели с использованием аналогичных метрик структурного покрытия для моделей.
3 Если для определения степени покрытия используется код измерительного средства, то. может быть,
необходимо показать, что измерительные средства никак не влияют на результаты испытаний. Это может быть
сделано путем повторения испытаний без кода измерительного средства.
18