Как выполнить регрессионные тесты во встроенных системах
Какие существуют хорошие практики и стратегии для проведения регрессионных тестов во встроенных средах или в других ситуациях, когда возможность автоматизации тестов очень ограничена.
По моему опыту, многие тесты должны выполняться вручную, т. Е. Тестировщик должен нажать последовательность кнопок и убедиться, что машина работает правильно. Как разработчику, действительно трудно убедить себя, что ваши изменения не нарушают что-то еще.
Без надлежащих регрессионных тестов ситуация становится еще хуже во время больших рефакторингов и тому подобного.
Кто-нибудь признает проблему? Вы нашли хорошее решение или процесс для решения этой проблемы?
9 ответов
Лично я большой поклонник компиляции моего встроенного кода как на целевом оборудовании, так и на моем собственном компьютере. Например, при нацеливании на 8086 я включил и точку входа, которая отображается для сброса на оборудовании 8086, и точку входа DOS. Оборудование было спроектировано таким образом, чтобы все операции ввода-вывода отображались в памяти. Затем я условно скомпилировал в аппаратном симуляторе и условно изменил расположение аппаратной памяти на симулированную аппаратную память.
Если бы я работал на платформе не-x86, я бы вместо этого написал эмулятор.
Другой подход заключается в создании испытательного стенда, где все входы и выходы для аппаратного обеспечения контролируются с помощью программного обеспечения. Мы часто используем это в заводских испытаниях.
Однажды мы встроили симулятор в аппаратное обеспечение ввода-вывода. Таким образом, можно протестировать остальную часть системы, отправив несколько команд по CAN, чтобы перевести оборудование в режим имитации. Аналогичным образом, хорошо продуманное программное обеспечение может иметь "имитированный режим", в котором ввод-вывод моделируется в ответ на команды программного обеспечения.
Что касается встроенного тестирования, я бы посоветовал вам разработать свой выход из этого очень рано в процессе разработки. Песочница для вашего встроенного кода для запуска на платформе ПК очень помогает, а потом и насмешливо:)
Это обеспечит целостность для большей части этого, но вам все равно придется позже провести тестирование системы и приемочное тестирование вручную.
В отличие от большинства респондентов, я до сих пор работаю со встроенными средами, которые совсем не похожи на настольные системы и поэтому не могут эмулировать встроенную систему на рабочем столе.
Чтобы написать хорошие тестовые системы, вам нужна ваша тестовая система, чтобы иметь обратную связь и обратную связь. JTAG является наиболее распространенным способом прямой связи для управления устройством. Вы можете установить полное состояние устройства (возможно, даже всю плату, если вам повезет), а затем установить тестовый код для запуска. В этот момент вы получите свой отзыв. JTAG также может служить устройством обратной связи. Тем не менее, логический анализатор с программным API является лучшим в этой ситуации. Вы можете искать определенные уровни на выводах, считать импульсы и даже анализировать потоки данных от потоковых периферийных устройств.
Кто-нибудь признает проблему?
Вероятнее всего.
Вы нашли хорошее решение или процесс для решения этой проблемы?
Сочетание методик:
- Автоматизированные тесты;
- Тесты грубой силы, то есть те, которые не настолько интеллектуальны, как автоматические тесты, но которые многократно проверяют функцию в течение длительного периода (часов или дней) и могут быть оставлены для выполнения без вмешательства человека;
- Ручные тесты (часто трудно избежать);
- Тестирование на программном эмуляторе на ПК (или, в крайнем случае, на аппаратном эмуляторе).
Что касается компиляции на компиляторе для ПК: это, безусловно, имело бы смысл для модулей высокого уровня и для модулей низкого уровня с подходящей для тестирования системой.
Например, когда речь идет о частях кода, которые имеют дело с сигналами в реальном времени из нескольких источников, эмуляция - это хорошее место для начала, но я не думаю, что этого достаточно. Часто нет альтернативы для тестирования кода на реальном оборудовании в максимально реалистичной среде.
Я согласен со всеми, кто говорит, что автоматизированное оборудование является обязательным - мы используем этот подход для тестирования встроенного программного обеспечения с некоторыми из наших устройств. Мы создали большие двухстоечные тестовые станции, заполненные аппаратными симуляторами, и мы используем NI TestStand со смесью VI Labview, кода C#, DLL-библиотек поставщиков и т. Д. Для управления всем этим. Мы должны протестировать много оборудования - вот почему у нас есть все это дерьмо. Если вы просто тестируете программное обеспечение, вы можете масштабировать его до самого необходимого. Тестирование последовательного интерфейса? Просто создайте устройство для имитации последовательного трафика и выполните все сообщения (и несколько недействительных сообщений), чтобы программное обеспечение отвечало правильно. Тестирование DIO? Это просто - есть множество периферийных USB-устройств или встроенных устройств для имитации DIO. Если важна синхронизация, вам придется использовать другое встроенное устройство, чтобы получить жесткие допуски, которые вы ищете, в противном случае с ПК все будет в порядке.
Важной частью является то, чтобы всегда знать, что вы тестируете, и не проверять ничего, кроме этого. Если это программное обеспечение, убедитесь, что тест не зависит от оборудования в максимально возможной степени. Если вы тестируете генерацию формы сигнала или что-то с помощью D/A, выделите задачи - протестируйте оборудование D / A с помощью специальной сборки программного обеспечения на встроенном устройстве, которое не делает ничего сложного, кроме как выполняя заранее подготовленную последовательность уровни напряжения. Затем вы можете увидеть, не включены ли ваши ссылки, установлены ли ваши фильтры на неправильную частоту и т. Д. Затем вы сможете протестировать программное обеспечение независимо от аппаратного обеспечения - используйте плату разработки для тестирования программного обеспечения и проверки поведения на процессоре. булавки это правильно.
Помимо предложений о том, что ваше приложение может создавать и хотя бы частично тестировать на обычных ПК (что также полезно при использовании таких инструментов, как Valgrind), я бы подумал о дизайне вашего программного обеспечения.
В одном проекте, над которым я работал, был компонент для управления оборудованием, один для решения задач управления, а другой - для управления сетью. Управление сетью осуществлялось с помощью SNMP, поэтому было легко писать сценарии, которые выполнялись удаленно, чтобы заставить аппарат делать что-то.
Для запуска аппаратных тестов низкого уровня я написал простую программу чтения сценариев, которая анализировала тестовые сценарии и вводила команды в IPC моего драйвера. Поскольку вывод был основан на видео, было трудно автоматизировать проверку обработки, кроме как на глаз, но это, безусловно, спасло меня от RSI. Это также было очень полезно при создании сценариев, которые подвергались стресс-тестированию или моделировали известные условия отказа, чтобы избежать повторного появления ошибок.
Если бы я делал это снова и снова, я бы, вероятно, реализовал разделяемую библиотеку, используемую тестовым комплектом, и реальный код для отправки основных сообщений. Затем я бы обернул библиотеку в python (или что-то подобное), чтобы моё тестирование могло быть немного более "скриптовым".
Решение, в котором я работаю, - это автоматическая ночная процедура сборки и тестирования.
- Проверьте код заголовка магистрали из системы контроля версий.
- Построить проект и загрузить на цель.
- Запустите управляемые ПК автоматизированные сценарии тестирования.
Тестовые сценарии легко запустить, если вы используете какой-то протокол связи. Это хорошо для внутренних юнит-тестов. Что делает ситуацию более интересной (и тщательной), так это создание жгута проводов, который вставляется в плату для имитации внешнего ввода-вывода.
Эмуляция хороша для разработки и базового начального тестирования, но реальное физическое время работы является единственным надежным методом проверки системы. Физическая работа может выявлять проблемы, не связанные с кодом (вызванные методами кодирования), такие как провалы напряжения, шум, сбои, проблемы отказов, условия гонки и т. Д.
Длительное тестирование системы также важно. Настройка автоматического теста на постоянное злоупотребление системой в течение нескольких дней / недель - это хороший способ устранить проблемы, которые могут возникать только через несколько месяцев в полевых условиях. Говорить покупателю, чтобы он просто включал питание всякий раз, когда все начинает вести себя забавно, - это не роскошь, которую могут развлечь все отрасли.
Предоставьте тестовые наборы / песочницы / макеты для отдельных подсистем и для всего проекта, которые эмулируют целевую среду.
Это не устраняет необходимость в тестах в реальной среде, но значительно сокращает их количество, так как симуляция улавливает большинство проблем, поэтому к тому времени, когда они все пройдут, и вы проведете дорогостоящий тест, управляемый человеком, вы достаточно уверены, что пройдете этот первый время.
По моему опыту, автоматизированное тестирование оборудования имеет решающее значение. - Инвестиции в двойную компиляцию как для ПК, так и для целевой системы - это отличная возможность, но если бы у меня был выбор, я бы предпочел инвестировать в автоматическое тестирование оборудования. В конце концов, это будет более рентабельное решение, так как производственные кронштейны в любом случае будут нуждаться / нуждаются в возможности для анализа отказов.