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

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

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

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

Совершенно определенно.

Вы нашли хорошее решение или процесс, чтобы справиться с этим видом проблема?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Проверьте код головки соединительной линии из управление исходным кодом.
2. Постройте проект и загрузите его в целевой объект.
3. Запустите автоматизированные сценарии тестирования, управляемые ПК.

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

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

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

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

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