Автоматизация тестирования со встроенным оборудованием

Question

Кто-нибудь успешно автоматизировал тестирование непосредственно на встроенном оборудовании?

В частности, я имею в виду автоматизацию батареи модульных тестов для модулей аппаратного уровня. Нам нужно быть более уверенными в нашем коде аппаратного уровня. Во многих наших проектах используются таймеры, управляемые прерываниями, АЦП, последовательные порты ввода-вывода, устройства с последовательным интерфейсом SPI (флэш-память) и т. Д.

Стоит ли даже усилий?

Обычно мы нацелены:

Процессор: 8 или 16-битные микроконтроллеры (некоторые вещи DSP)
Язык: C (иногда c ++).

Answer 1

Конечно. В автомобильной промышленности мы используем тестеры по 100 000 долларов США для каждого нового продукта для проверки правильности работы оборудования и программного обеспечения.

Разработчики, однако, также строят более дешевый (менее 1000 долларов) тестер, который включает в себя набор USB I / O, A / D, PWM in / out и т. Д. И использует либо скрипты на рабочей станции, либо специально созданный HIL / Программное обеспечение для тестирования SIL, такое как MxVDev.

Возможно, вы имеете в виду тестирование оборудования в контуре (HIL), и оно просто включает в себя некоторый аппаратный ввод-вывод USB, подключенный к вводу-выводу вашего устройства, с программным обеспечением на компьютере, на котором выполняются тесты.

Стоит ли это того, зависит.

В отрасли высокой надежности (самолет, автомобилестроение и т. Д.) Заказчик проводит очень обширные испытания оборудования, поэтому его нужно просто получить, чтобы получить предложение.

В легкой промышленности, когда речь идет о не сложных проектах, это обычно не стоит.

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

Тестирование сразу показывает, когда проблема вошла в сборку.

Как правило, вы выполняете тестирование «черного ящика» и «белого ящика» - на устройстве работает диагностический код, который позволяет вам следить за сигналами и памятью на аппаратном обеспечении (это может быть просто отладчик или написанный вами код, который реагирует на к сообщениям в автобусе, например). Это будет тестирование белого ящика, где вы сможете увидеть, что происходит внутри (и даже вызвать некоторые вещи, такие как критические ошибки памяти, которые невозможно протестировать без введения ошибки самостоятельно).

Мы также запускаем серию тестов «черного ящика», в которых путь диагностики игнорируется и стимулируется / считывается только ввод / вывод.

Для гораздо более дешевой установки вы можете получить платы микроконтроллера за 100 долларов с USB и / или Ethernet (например, семейство Atmel UC3), которые вы можете подключить к своему устройству и запустить базовое тестирование.

Это особенно полезно для обслуживания продукта - когда проект будет завершен, сохраните несколько рабочих плат, тестер и полный комплект программного обеспечения на компакт-диске. Когда вам нужно внести изменения или отладить проблему, легко настроить все это и работать с ним с некоторыми знаниями (после тестирования), что ваши основные изменения не были затронуты.

-Adam

Answer 2

Да. Я добился успеха, но это не проблема, которую нужно решить. Вкратце вот что сделала моя команда:

1. Определяется множество модульных тестов с использованием собственной структуры модульного тестирования на Си. В основном, просто много макросов, большинство из которых были названы TEST_EQUAL, TEST_BITSET, TEST_BITVLR и т. Д.

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

3. Отдельные тесты будут регистрировать свои выходные данные, используя последовательный порт. Это было хорошо для нашего дизайна, потому что последовательный порт был свободен. Вам нужно будет найти способ сохранить ваши результаты, если все ваши операции ввода-вывода потребляются.

Это сработало! И это было здорово иметь. Используя наш собственный регистратор данных, вы можете нажать кнопку «Тест», и через пару минут вы получите все результаты. Я очень рекомендую это.

Обновлено , чтобы пояснить, как работает тестовый драйвер.

Answer 3

Да.

Сложность зависит от типа оборудования, которое вы пытаетесь протестировать. Как уже говорили другие, проблема заключается в сложности внешнего стимула, который вам нужно применить. Внешний стимул, вероятно, лучше всего достигается с помощью некоторого внешнего испытательного стенда (как описал Адам Дэвис).

Однако нужно учитывать, что точно что вы пытаетесь проверить.

Заманчиво предположить, что для проверки взаимодействия аппаратного и микропрограммного обеспечения у вас действительно нет другого выбора, кроме как непосредственно применить внешний стимул (т.е. применить ЦАП ко всем входам АЦП и т. Д.). В этих случаях, тем не менее, в угловых случаях, которые вы действительно хотите протестировать, часто возникают проблемы синхронизации (например, прерывания, поступающие при выполнении функции foo ()), которые будут невероятно трудны для тестирования в осмысленный путь - и еще труднее получить значимые результаты. (То есть. Первые 100К раз, когда мы запускали этот тест, он был в порядке. В последний раз, когда мы его запускали, он проваливался. Почему?!?)

Но проверка оборудования должна выполняться отдельно. Как только это будет сделано, если только оно не меняется регулярно (через загружаемые образы fpga и т. П.), Вы должны быть в состоянии предположить, что оборудование работает, и просто протестировать вашу прошивку.

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

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

Answer 4

Мы получили хорошие результаты благодаря автоматическому тестированию наших встроенных систем. У нас есть тесты, написанные на языках высокого уровня (простой в программировании и отладке), которые работают на выделенных тестовых машинах. Эти тесты обычно выполняют проверку работоспособности или генерируют случайные входы в устройства, а затем проверяют правильность поведения. Существует много работы для генерации и поддержки этих тестов. Мы разработали структуру, а затем позволили стажерам самим работать над тестами.

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

Некоторые вещи, которые следует учитывать:

• Что такое штраф за ошибку прошивки? Как проще обновить прошивку в полевых условиях.
• Какое покрытие обеспечивает мой тест? Это простая проверка вменяемости? Достаточно ли настраивается, чтобы можно было тестировать множество различных сценариев?
• Если тест не пройден, как вы воспроизведете это значение для его отладки? Записали ли вы все настройки устройства и теста, чтобы исключить как можно больше переменных? Конфигурация устройства, версия прошивки, тестовая версия программного обеспечения, все внешние входы, все наблюдаемое поведение?
• Что вы тестируете? Достаточно ли ясна спецификация относительно ожидаемого поведения устройства, которое вы тестируете, или вы сравниваете его с тем, что, по вашему мнению, должен делать код?

Answer 5

Если ваша цель - протестировать код вашего низкоуровневого драйвера, вам, вероятно, потребуется создать какой-нибудь тестовый прибор, используя петлевые кабели или несколько соединенных между собой устройств, чтобы вы могли тренировать каждый драйвер. Сопряжение платы с известным хорошим программным обеспечением и платой, на которой выполняется сборка разработки, позволит вам проверить регрессии в протоколах связи и т. Д.

Конкретные стратегии тестирования зависят от оборудования, которое вы хотите протестировать. Например, АЦП можно проверить, представив известную форму волны и преобразовав серию выборок, а затем проверив правильность диапазона, частоты, среднего значения и т. Д.

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

Answer 6

Да, я делаю это, хотя у меня всегда был доступный последовательный порт для тестового ввода-вывода.

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

ИМХО, это лучше, чем отсутствие юнит-тестирования вообще. И, конечно же, вам также необходимо выполнить полную интеграцию / тестирование системы.

Answer 7

Я знаю, что сейчас это старо, но, возможно, это поможет. Да, вы можете сделать это, но это зависит от того, сколько вы хотите инвестировать в решение, которое вы хотите. Более двух лет я работал над тестированием и валидацией для уровня MCAL AUTOSAR. Это самое низкое значение, которое вы можете получить, когда дело доходит до тестирования программного обеспечения. Это было своего рода тестирование на уровне компонентов. Кто-то может назвать это единичным уровнем, но он был немного выше, потому что мы тестировали API-интерфейсы компонентов MCAL. Такие вещи, как: АЦП, SPI, ICU, DIO и т. Д.

Используемое решение включало: - тестовая структура, которая работала на целевой микро - блок dSPACE для предоставления и считывания сигналов от цели и при необходимости - Доступ к XCP через Vector CANape для запуска выполнения теста и сбора результатов. - Python Framework для выполнения контрольного контроля и проверки результатов

Контрольные примеры были написаны на языке C, и они были помечены на мишени вместе с тестируемым программным обеспечением. Это был тест «черного ящика», потому что мы никак не изменили реализацию MCAL. И я думаю, что даже последовательность запуска не была затронута. Задача Idle использовалась для непрерывной проверки состояния флага, который был сигналом для начала выполнения теста. Задача 10 мс была использована для фактического запуска теста. Тестовый случай был фактически переключателем. Каждый случай в этом переключателе был тестовым шагом. Python запускал выполнение теста на уровне шага теста. Хорошо с этим подходом было повторное использование шагов с различными параметрами. Этот тестовый контроль, что выполнять и как, был выполнен Python посредством структуры данных контрольного теста, выступающей в качестве API между реализацией теста и механизмом запуска и оценки теста. Это то, для чего использовалась CANape. Установить тест для выполнения и прочитать результаты теста. Каждое значение, полученное на шаге теста, было сохранено в части массива структуры данных. Сам этап тестирования не участвовал в какой-либо проверке, поскольку цель считалась не заслуживающим доверия компонентом тестовой среды. Проверка была сделана Python на основе спецификаций теста. Python анализировал эти спецификации и мог автоматически создавать сценарии запуска теста, включая критерии проверки для каждого шага тестирования. Спецификация каждого теста представляла собой серию описаний этапов тестирования вместе с критериями их валидации. Некоторые из этих шагов были шагами, связанными с dSPACE. Например, одним шагом была инициализация чего-либо и требовалось захватить некоторые границы в уже настроенном канале, а следующий шаг - применить сигнал к этому каналу, дав команду оборудованию dSPACE.

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

Answer 8

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

Мы успешно разработали внешний последовательный протокол (сообщения rs232 или udp или tcpip) с базовыми командами для выполнения hw с ведением журнала отладки в драйверах низкого уровня, ищущих ошибочные условия или даже слегка ненормальные условия (особенно для ограничения проверка)

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

Answer 9

Если ваша цель заключается в производственном тестировании (обеспечение правильной сборки модулей, непреднамеренного короткого замыкания / размыкания / и т. Д.), Сначала следует сосредоточиться на тестировании кабелей и разъемов, затем на разъемах с разъемами и пайкой, а затем на самой печатной плате. Все эти элементы можно проверить на наличие коротких замыканий и открытий, найдя шаблоны доступа, которые повышают каждую отдельную линию, в то время как у ее соседей низкий уровень, и наоборот, а затем считывают значения линий.

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

Если вы не проводите тестирование «ложных гвоздей» на своих PCA, это тестирование следует считать обязательным первым шагом для вновь изготовленных плат.