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

Question

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

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

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

Кто-нибудь распознает проблему? Нашли ли вы хорошее решение или процесс для решения этой проблемы?

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

Определенно.

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

Сочетание приемов:

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

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

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

Answer 5

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

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

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

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

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

Answer 6

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

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

Answer 7

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

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

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

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

Answer 8

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

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

Answer 9

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