Единичное тестирование встроенного программного обеспечения

Ответ 1

Встроенное программное обеспечение, возможно, прошло долгий путь за последние 10 лет, но мы обычно делали следующее:

• для алгоритмов, не зависящих от целевого оборудования, у нас просто были модульные тесты, которые были построены и протестированы на не встроенной платформе.
• для тех вещей, которые требовали аппаратного обеспечения, модульные тесты были условно скомпилированы в код для использования любого оборудования. В нашем случае это был последовательный порт на целевом компьютере, который подталкивал результаты к другой, более способной машине, где тесты были проверены на правильность.
• В зависимости от аппаратного обеспечения вы иногда можете подделывать "виртуальное" устройство на не встроенной платформе. Обычно это состояло в том, что другой поток выполнения (или сигнальная функция) менял память, используемую программой. Полезно для ввода/вывода с памятью, но не для IRQ и т.д.
• обычно вы могли бы только unit test создать небольшое подмножество полного кода за раз (из-за ограничений памяти).
• для тестирования чувствительных к времени вещей мы этого не сделали. Легко и просто. Аппаратное обеспечение, которое мы использовали (8051 и 68302), не всегда было функциональным, если оно работало слишком медленно. Такая отладка должна была быть выполнена первоначально с помощью CRO (осциллографа) и (когда у нас было больше денег) ICE (внутрисхемный эмулятор).

Надеюсь, ситуация улучшилась с тех пор, как я в последний раз это делал. Я бы не пожелал этой боли моему злейшему врагу.

Ответ 2

Многое может быть достигнуто путем тестирования модулей в среде ПК (компиляция вашего кода с помощью компилятора ПК C и запуск вашего кода в рамках тестирования модулей ПК) с несколькими оговорками:

• Это не относится к тестированию вашего низкоуровневого кода, включая код запуска, тесты RAM, аппаратные драйверы. Вам придется использовать более прямое модульное тестирование.
• Ваш встроенный системный компилятор должен быть надежным, поэтому вы не будете искать ошибки, созданные компилятором.
• Ваш код должен быть многоуровневой архитектурой с аппаратной абстракцией. Возможно, вам понадобится написать симуляторы драйверов устройств для вашей платформы тестирования модулей ПК.
• Вы всегда должны использовать типы stdint.h, такие как uint16_t, а не просто unsigned int и т.д.

Мы следовали этим правилам и обнаружили, что после модульного тестирования кода прикладного уровня в системе ПК unit test у нас может быть хорошая уверенность в том, что он работает хорошо.

Преимущества модульного тестирования на платформе ПК:

• Вы не сталкиваетесь с проблемой нехватки места на диске на встроенной платформе из-за добавления модульной системы тестирования.
• Цикл цикла компиляции обычно выполняется быстрее и проще на платформе ПК (и избегает этапа "запись/загрузка", который может быть несколько минут).
• У вас есть больше возможностей для визуализации прогресса (некоторые встроенные приложения имеют ограниченные периферийные устройства ввода-вывода), хранение входных/выходных данных для анализа, выполнение более трудоемких тестов.
• Вы можете использовать легко доступные фреймворки unit test на базе ПК, которые недоступны/пригодны для встроенной платформы.

Ответ 3

Встроенные системы - это широкая тема, но в целом, подумайте об этом как о продукте специального назначения, сочетающем в себе как аппаратное, так и программное обеспечение. Мой встроенный фон - это мобильные телефоны, которые являются лишь небольшим подмножеством всех встроенных систем. Я попытаюсь немного учесть следующие моменты:

• Освобождайте аппаратные зависимости, когда это возможно. Таким образом, вы можете запускать свои модульные тесты на издеваемое "оборудование", а также тестировать различные редкие/исключительные случаи, которые было бы сложнее проверить на целевом уровне. Чтобы предотвратить затраты на абстракцию, вы можете использовать, например, условная компиляция.

• Как можно меньше зависит от оборудования.

• Модульные тесты, запущенные в среде эмулятора или кросс-компилятора, по-прежнему не гарантируют, что код работает на целевом оборудовании. Вы должны также проверить цель. Проведите тест как можно раньше.

Ответ 4

Возможно, вы захотите проверить Test Driven Development for Embedded C от Джеймса У. Греннинга. Книга должна быть опубликована в августе 2010 года, но бета-книга теперь доступна на The Pragmatic Bookshelf.

Ответ 5

Голос неопытности здесь, но об этом я и думал в последнее время. Мне кажется, что лучшим подходом будет либо

A) Напишите как можно больше вашего аппаратно-независимого кода приложения, как вы можете в среде ПК, прежде чем писать его на целевой странице, и одновременно записывайте свои модульные тесты (это делается на ПК в первую очередь заставляют вас отделять аппаратно-независимые материалы). Таким образом, вы можете использовать свой выбор тестеров модулей, а затем проверить аппаратно-зависимый материал старомодным способом - с RS-232 и/или осциллографами и выводами ввода-вывода, сигнализирующими зависящие от времени данные, в зависимости от того, насколько быстро он должен работать,

B) Напишите все на целевом оборудовании, но у вас есть цель make, чтобы условно скомпилировать сборку unit test, которая будет запускать модульные тесты и выводить результаты (или данные, которые могут быть проанализированы для результатов) через RS-232 или некоторые другие средства. Если у вас мало памяти, это может быть сложно.

Редактировать 7/3/2009 Я просто подумал о том, как unit test аппаратно-зависимый материал. Если ваши аппаратные события происходят слишком быстро, чтобы записывать с помощью RS-232, но вы не хотите вручную просеивать тонны данных данных осциллографа, чтобы увидеть, как ваши флаги контактов ввода-вывода растут и падают, как ожидалось, вы можете использовать ПК карты со встроенным DIO (например, карты данных National Instruments) для автоматической оценки времени этих сигналов. Затем вам просто нужно было написать программное обеспечение на вашем ПК для управления карточкой сбора данных для синхронизации с текущим запуском unit test.

Ответ 6

Нам удается получить довольно много кода, зависящего от аппаратного обеспечения, с помощью симулятора, мы используем симулятор Keil и IDE (а не аффилированные только с их помощью). Мы пишем сценарии симулятора, чтобы управлять "оборудованием" так, как мы ожидаем, что он будет реагировать, и мы сможем довольно надежно проверить наш рабочий код. Конечно, это может приложить определенные усилия для моделирования аппаратного обеспечения для некоторых тестов, но для большинства вещей это очень хорошо работает и позволяет нам сделать многое без какого-либо оборудования. Нам удалось получить почти полную систему, работающую в симуляторе, прежде чем иметь доступ к аппаратным средствам, и у них было очень мало проблем, связанных с тем, как однажды поставить код на реальную вещь. Это также может значительно ускорить выпуск кода, поскольку все может быть сделано на ПК с более глубоким отладчиком, доступным во время моделирования чипа, и пытается сделать все на аппаратном обеспечении.

Получили это, чтобы надежно работать для сложных систем управления, интерфейсов памяти, пользовательских ИС с поддержкой SPI и даже моно-дисплея.

Ответ 7

Здесь есть много хороших ответов, некоторые вещи, о которых не упоминалось, - это запустить диагностический код, чтобы:

• Журнал событий HAL (прерывания, сообщения шины и т.д.)

• У вас есть код для отслеживания ваших ресурсов (все активные семафоры, активность потоков)

• Имейте механизм захвата, чтобы скопировать содержимое кучи и памяти в постоянное хранилище (жесткий диск или эквивалент) для обнаружения и отладки взаимоблокировок, livelocks, утечек памяти, переполнения буфера и т.д.

Ответ 8

Когда я столкнулся с этим прошлым годом, я действительно хотел протестировать встроенную платформу. Я разрабатывал библиотеку, и я использовал вызовы RTOS и другие функции встроенной платформы. Не было ничего конкретного, поэтому я адаптировал код UnitTest ++ для моих целей. Я программирую в семействе NetBurner, и поскольку у него есть встроенный веб-сервер, было довольно прямолинейно написать веб-интерфейс для тестирования GUI, который дать классическую обратную связь RED/GREEN. Это получилось довольно неплохо, и теперь модульное тестирование намного проще, и я чувствую себя намного увереннее, зная, что код работает на реальном оборудовании. Я даже использую модуль тестирования модулей для проведения интеграционных тестов. Сначала я обманываю/заглушаю аппаратное обеспечение и внедряю этот интерфейс для тестирования. Но в конце концов я пишу некоторые тесты "человек-в-цикле", которые используют фактическое оборудование. Оказывается, это гораздо более простой способ узнать об оборудовании и иметь простой способ восстановления от встроенных ловушек. Поскольку все тесты выполняются с обратных вызовов AJAX на веб-сервер, ловушка происходит только в результате ручного вызова теста, и система всегда перезапускается через несколько секунд после ловушки.

NetBurner достаточно быстр, чтобы цикл записи/компиляции/загрузки/запуска составлял около 30 секунд.

Ответ 9

Множество встроенных процессоров доступно на платформах eval, поэтому, хотя у вас могут не быть настоящих устройств ввода-вывода, часто вы можете выполнять множество своих алгоритмов и логики по одному из таких способов, часто с аппаратными средствами отладка доступна через jtag. И тесты "unit" обычно в большей степени касаются вашей логики, чем ваш i/o. Обычно проблема заключается в том, что ваши тестовые артефакты возвращаются из одной из этих сред.

Ответ 10

Разделить код между зависимыми от устройства и не зависящими от устройства. Независимый код можно тестировать без лишних усилий. Зависимый код просто должен быть проверен вручную, пока у вас не будет гладкого интерфейса связи.

Если вы пишете коммуникационный интерфейс, извините.