Как выполнить регрессионные тесты во встроенных системах

Ответ 1

Лично я большой поклонник компиляции встроенного кода как на целевом оборудовании, так и на моем собственном компьютере. Например, при настройке 8086 я включил точку входа, которая отображается на reset на оборудовании 8086 и точке входа DOS. Аппаратное обеспечение было сконструировано таким образом, чтобы все IO были отображены в память. Затем я условно скомпилировался в аппаратном симуляторе и условно менял места расположения аппаратной памяти на смоделированную аппаратную память.

Если бы я работал на платформе, отличной от x86, я бы, скорее всего, написал эмулятор.

Другой подход заключается в создании тестовой установки, где все входы и выходы для аппаратного обеспечения контролируются с помощью программного обеспечения. Мы много используем это при тестировании factory.

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

Ответ 2

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

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

Ответ 3

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

Наиболее определенно.

Вы нашли хорошее решение или процесс борьбы с такими проблема?

Комбинация методов:

• Автоматизированные тесты;
• Тесты грубой силы, т.е. не такие интеллектуальные, как автоматизированные тесты, но которые неоднократно проверяют функцию в течение длительного периода (часов или дней) и могут быть оставлены без вмешательства человека;
• Ручные тесты (часто трудно избежать);
• Тестирование на программном эмуляторе на ПК (или, в крайнем случае, аппаратный эмулятор).

Что касается компиляции на компиляторе ПК: это, безусловно, имеет смысл для модулей высокого уровня, а для низкоуровневых модулей с подходящей проводкой для тестирования.

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

Ответ 4

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

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

Ответ 5

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

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

Ответ 6

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

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

Для запуска аппаратных тестов низкого уровня я написал простой читатель script которые анализировали тестовые скрипты и вводили команды в IPC моего Водитель. Поскольку выход был основан на видео, было сложно автоматизировать проверка обработки, отличная от глаз, но она, безусловно, была сохранена меня RSI. Это также очень полезно при создании сценариев, которые подчеркивают испытанных или смоделированных известных условиях отказа, чтобы ошибки не повторно происходят.

Если я, когда делаю это сначала, я, вероятно, библиотека, используемая тестовой жгутом и реальный код для отправки ядра Сообщения. Затем я завершаю lib в python (или что-то аналогично), поэтому мое тестирование может быть немного более "scriptable".

Ответ 7

Я согласен со всеми, кто говорит, что автоматическое оборудование является обязательным - мы используем этот подход для тестирования встроенного программного обеспечения с некоторыми нашими подразделениями. Мы создали большие двухстоечные тестовые станции, оснащенные аппаратными тренажерами, и мы используем NI TestStand с сочетанием Labview VI, кода С#, DLL поставщиков и т.д., Чтобы управлять всем этим. Мы должны проверить множество аппаратных средств - вот почему у нас есть все это дерьмо. Если вы просто тестируете программное обеспечение, вы можете масштабировать его до нужных предметов. Тестирование последовательного интерфейса? Просто создайте устройство для имитации последовательного трафика и выполните все сообщения (и несколько недопустимых сообщений), чтобы обеспечить правильное выполнение программного обеспечения. Тестирование DIO? Это легко: есть много периферийных устройств USB или встроенных устройств для имитации DIO. Если синхронизация важна, вам придется использовать другое встроенное устройство, чтобы получить точные допуски, которые вы ищете, в противном случае ПК будет прекрасно работать.

Важная часть - всегда знать, что вы тестируете, и не тестировать ничего, кроме этого. Если это программное обеспечение, убедитесь, что тест не зависит от оборудования в максимально возможной степени. Если вы тестируете генерацию сигналов или что-то с помощью D/A, отделите задачи - проверьте аппаратное обеспечение D/A со специальной сборкой программного обеспечения на встроенном устройстве, которое не делает ничего необычного, кроме выплескивания заранее заданной последовательности уровень напряжения. Затем вы можете увидеть, отключены ли ваши ссылки, если ваши фильтры установлены на неправильную частоту и т.д. Затем вы должны иметь возможность протестировать программное обеспечение независимо от аппаратного обеспечения - используйте плату разработки для тестирования программного обеспечения и проверки поведения на процессоре правильные контакты.

Ответ 8

Используемое решение, где я работаю, - это автоматическая процедура сборки и тестирования в ночное время.

• Проверьте код головки соединительной линии от источника управления.
• Создайте проект и загрузите его в цель.
• Запустите автоматизированные тестовые сценарии, управляемые ПК.

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

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

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

Ответ 9

По моему опыту, автоматическое тестирование оборудования было критическим. - Инвестирование в двойную компиляцию как на ПК, так и на целевую - это "хорошо иметь", но, учитывая выбор, я бы скорее инвестировал в автоматическое тестирование оборудования. В конце концов, это будет более экономичное решение, так как производственные вооружения захотят/нуждаются в возможности в любом случае для анализа отказов.