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

Question

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

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

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

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

Answer 1

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

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

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

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

Answer 2

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

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

Answer 3

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

Вероятнее всего.

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

Комбинация техник:

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

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

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

Answer 4

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

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

Answer 5

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

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

Answer 6

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

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

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

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

Answer 7

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

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

Answer 8

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

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

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

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

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

Answer 9

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