Тестирование и верификация встраиваемого ПО

1. Введение: зачем нужны тестирование и верификация

Встраиваемое программное обеспечение (ПО) управляет критически важными системами: от медицинских приборов до авиационных бортов. Ошибки в таком ПО могут привести к:

• потере данных;
• материальному ущербу;
• угрозе здоровью и жизни людей;
• репутационным рискам производителя.

Ключевые отличия встраиваемого ПО от десктопного:

• жёсткие ограничения ресурсов (память, процессор, энергия);
• работа в реальном времени (real‑time constraints);
• тесная связь с аппаратурой;
• длительные сроки эксплуатации (10+ лет);
• сложность обновления в полевых условиях.

Цели тестирования и верификации:

• подтверждение соответствия требованиям;
• выявление дефектов на ранних этапах;
• снижение рисков эксплуатации;
• документирование уровня надёжности.

2. Основные понятия: тестирование vs верификация

2.1. Тестирование (Testing)

• Суть: выполнение ПО с целью обнаружения ошибок.
• Методы: запуск кода с тестовыми данными, проверка выходных результатов.
• Фокус: «что ПО делает» (поведение системы).

2.2. Верификация (Verification)

• Суть: доказательство соответствия ПО спецификациям и стандартам.
• Методы: статический анализ, формальные методы, инспекции кода.
• Фокус: «соответствует ли ПО требованиям» (корректность реализации).

Взаимосвязь:
Тестирование — часть процесса верификации. Верификация включает не только выполнение кода, но и анализ документации, архитектуры, безопасности.

3. Уровни тестирования встраиваемого ПО

3.1. Модульное тестирование (Unit Testing)

• Объект: отдельные функции, классы, модули.
• Цель: проверка корректности работы изолированных компонентов.
• Инструменты: Unity, CMock, Google Test (для C/C++).
• Особенности для встраиваемых систем:
  • запуск на ПК (с эмуляцией периферии);
  • использование тестовых двойников (mocks) для аппаратных регистров;
  • ограничение использования динамической памяти.

Пример теста (Unity):

void test_TemperatureConverter_ShouldConvertCelsiusToFahrenheit(void) {
    float result = convertCtoF(0.0f);
    TEST_ASSERT_EQUAL_FLOAT(32.0f, result);
}

3.2. Интеграционное тестирование (Integration Testing)

• Объект: взаимодействие модулей, драйверов, стеков протоколов.
• Цель: выявление ошибок интерфейсов и зависимостей.
• Подходы:
  • «снизу вверх» (от модулей к системе);
  • «сверху вниз» (от высокоуровневых компонентов);
  • сэндвич‑тестирование (комбинация).
• Примеры проверок:
  • корректность передачи данных между задачами RTOS;
  • обработка ошибок в цепочках вызовов;
  • синхронизация через семафоры/очереди.

3.3. Системное тестирование (System Testing)

• Объект: полная система (ПО + аппаратная платформа).
• Цель: проверка соответствия требованиям в реальных условиях.
• Виды тестов:
  • функциональное тестирование (все сценарии использования);
  • нагрузочное тестирование (максимальная нагрузка);
  • стресс‑тестирование (работа за пределами норм);
  • тестирование устойчивости (сбои питания, помехи).
• Инструментарий:
  • автоматизированные тестовые стенды;
  • осциллографы, логические анализаторы;
  • имитаторы датчиков и сетей.

3.4. Приёмочное тестирование (Acceptance Testing)

• Объект: релиз‑версия ПО.
• Цель: подтверждение готовности к эксплуатации.
• Участники: заказчик, независимый тестировщик.
• Критерии: чек‑листы, пользовательские сценарии.

4. Методы верификации

4.1. Статический анализ кода

• Цель: обнаружение потенциальных ошибок без выполнения кода.
• Что проверяет:
  • нарушения стандартов кодирования (MISRA C/C++, AUTOSAR C++);
  • утечки памяти, неинициализированные переменные;
  • переполнения буферов;
  • мёртвый код.
• Инструменты:
  • PC‑Lint, Splint (C/C++);
  • SonarQube (мультиязыковой);
  • Coverity (промышленный уровень).

4.2. Формальная верификация

• Цель: математическое доказательство корректности алгоритмов.
• Методы:
  • модельное тестирование (Model Checking);
  • доказательство теорем (Theorem Proving);
  • абстрактная интерпретация.
• Применение: критичные системы (авиация, ядерная энергетика).
• Инструменты: Frama‑C, SPIN, TLA+.

4.3. Ревизия кода (Code Review)

• Цель: коллективная проверка качества и стиля кода.
• Форматы:
  • парное программирование (Pair Programming);
  • pull request‑ревью;
  • формальные инспекции (Fagan Inspection).
• Чек‑листы:
  • соответствие архитектуре;
  • читаемость и комментарии;
  • обработка ошибок;
  • безопасность.

4.4. Анализ требований

• Цель: убедиться, что ПО реализует все спецификации.
• Методы:
  • трассировка требований (Requirements Traceability Matrix);
  • валидация сценариев использования (Use Cases);
  • проверка полноты и непротиворечивости.

5. Тестирование в реальном времени (Real‑Time Testing)

5.1. Ключевые аспекты

• Дедлайны задач: замер времени выполнения критических секций.
• Джиттер (Jitter): колебания времени отклика.
• Приоритеты: проверка вытеснения низкоприоритетных задач.
• Синхронизация: корректность работы мьютексов, семафоров.

5.2. Инструменты измерения

• Счётчик тактов CPU (DWT в ARM Cortex‑M).
• Логические анализаторы — визуализация временных диаграмм.
• Трассировщики RTOS (Tracealyzer, SEGGER SystemView).

Пример замера времени (ARM Cortex‑M):

__attribute__((always_inline)) static inline uint32_t getCycleCount() {
    return DWT->CYCCNT;
}

uint32_t start = getCycleCount();
criticalFunction();
uint32_t elapsed = getCycleCount() - start;
assert(elapsed < MAX_ALLOWED_CYCLES);

6. Тестирование безопасности и надёжности

6.1. Тестирование на проникновение (Penetration Testing)

• Цель: имитация атак на систему.
• Сценарии:
  • переполнение буфера;
  • подделка команд через интерфейсы;
  • анализ уязвимостей протоколов (MQTT, CoAP).
• Инструменты: Burp Suite, Wireshark, custom fuzzers.

6.2. Стресс‑тестирование

• Цель: проверка устойчивости к экстремальным условиям.
• Методики:
  • многократные циклы включения/выключения;
  • работа при пониженном напряжении;
  • температурные тесты (от −40 °C до +85 °C);
  • электромагнитные помехи (EMC‑тесты).

6.3. Тестирование обновлений (OTA)

• Цель: гарантия корректного обновления ПО без сбоев.
• Проверки:
  • целостность образа (хеш, подпись);
  • откат к предыдущей версии при ошибке;
  • сохранение настроек пользователя;
  • энергонезависимая память (EEPROM/Flash).

7. Автоматизация тестирования

7.1. Преимущества автоматизации

• повторяемость тестов;
• сокращение времени на рутинные проверки;
• раннее обнаружение дефектов (CI/CD).

7.2. Инструментарий

• CI/CD‑системы: Jenkins, GitLab CI, GitHub Actions.
• Тестовые фреймворки:
  • CGreen ©;
  • Ceedling (Unity + CMock);
  • Robot Framework (для высокоуровневых сценариев).
• Эмуляторы: QEMU (эмуляция MCU), Renode (от Microsoft).

7.3. Пример CI‑пайплайна

1. Сборка: компиляция для целевой платформы.
2. Статический анализ: проверка MISRA C.
3. Модульные тесты: запуск на хосте (с mock‑драйверами).
4. Интеграционные тесты: выполнение на тестовом стенде.
5. Отчёт: покрытие кода, список дефектов.

8. Документирование и отчётность

8.1. Обязательные документы

• План тестирования: цели, методы, ресурсы.
• Тест‑кейсы: входные данные, ожидаемые результаты.
• Отчёты о дефектах: описание, приоритет, статус.
• **Матрица трассировки