Автоматизация тестирования с помощью встроенного оборудования

Ответ 1

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

Разработчики, однако, также строят более дешевый (под $1,000) тестер, который включает в себя кучу ввода/вывода USB, A/D, PWM в/в и т.д. и либо используют сценарии на рабочей станции, либо специально созданные HIL/SIL, например MxVDev.

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

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

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

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

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

Затем тестирование сразу же появляется, когда проблема вступила в сборку.

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

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

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

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

-Adam

Ответ 2

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

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

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

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

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

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

Ответ 3

Да.

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

Одна вещь, которую следует учитывать, это именно то, что вы пытаетесь проверить.

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

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

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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

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

Ответ 7

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

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

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

Ответ 8

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

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

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

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

Ответ 9

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

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

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