Модульное тестирование встроенного программного обеспечения [закрыто]

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

 Dmitri10 нояб. 2014 г., 23:11
@BilltheLizard: выглядит как идеальный пример конструктивного субъективного для меня.
 Ian Goldby28 авг. 2013 г., 12:39
@BillTheLizard Это очень хороший вопрос, с несколькими хорошими ответами ниже. Пожалуйста, вы проголосуете, чтобы открыть его?
 Dmitry Frank18 янв. 2017 г., 10:07
Я написал основательную статью на эту тему:Unit-testing (embedded) C applications with CeedlingЯ долгое время пользовался описанными там приемами и до сих пор доволен ими.
 Bill the Lizard28 авг. 2013 г., 13:04
@IanGoldby Нет, это прямо подпадает подWhat types of questions should I avoid asking?
 Ian Goldby29 авг. 2013 г., 14:59
@BilltheLizard Какой тест не пройден? Я рассматриваю это как законный запрос о помощи в решении проблем с модульным тестированием, свойственных встроенным системам. На это можно ответить совершенно объективно. (Тот факт, что вопрос и некоторые ответы имеют высокую оценку, указывает на то, что другие, кроме меня, сочли это полезным.) Поможет ли это, если я перефразирую вопрос?

Ответы на вопрос(10)

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

Abstract out hardware dependencies whenever possible. This way you can run your unit tests on mocked "hardware" and also test various rare/exceptional cases that would be harder to test on target. To prevent abstraction costs, you can use e.g. conditional compilation.

Have as little as possible depend on the hardware.

Unit tests running on an emulator or cross-compiler environment still does not guarantee the code works on target hardware. You must test on target as well. Test on target as early as possible.

 03 июл. 2009 г., 15:56
Я добавлю в "Тест на цель как можно раньше". - это удваивается, если это пользовательское оборудование или оборудование со значительными пользовательскими компонентами.

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

A) Напишите как можно больше своего аппаратно-независимого кода приложения в среде ПК, прежде чем писать его в целевой системе, и одновременно писать свои модульные тесты (выполнение этого на ПК должно сначала заставить вас отдельный аппаратно-независимый материал). Таким образом, вы можете использовать свой выбор тестеров модулей, а затем протестировать аппаратно-зависимые компоненты старомодным способом - с помощью RS-232 и / или осциллографов и выводов ввода / вывода, сигнализирующих данные, зависящие от времени, в зависимости от того, насколько быстро он должен работать ,

Б) Напишите все это на целевом оборудовании, но у вас есть цель make для условной компиляции сборки модульного теста, которая будет запускать модульные тесты и выводить результаты (или данные, которые можно проанализировать для результатов) через RS-232 или каким-либо другим способом. Если у вас недостаточно памяти, это может быть сложно.

Изменить 3/3/2009 У меня просто была другая мысль о том, как провести модульное тестирование аппаратно-зависимых вещей. Если ваши аппаратные события происходят слишком быстро, чтобы записывать их с RS-232, но вы не хотите вручную просеивать тонны данных осциллографа, проверяя, не поднимаются ли и не падают ли флаги выводов ввода-вывода, как ожидалось, вы можете использовать ПК. карта со встроенным DIO (например, линейка карт сбора данных National Instruments) для автоматической оценки синхронизации этих сигналов. Затем вам просто нужно написать программное обеспечение на вашем ПК для управления картой сбора данных для синхронизации с текущим модульным тестом.

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

Log HAL events (interrupts, bus messages, etc) Have code to keep track of your resources, (all active semaphores, thread activity) Have a capture ram mechanism to copy the heap and memory content to persistent storage (hard disk or equivalent) to detect and debug deadlocks, livelocks, memory leaks, buffer overflows, etc.
Решение Вопроса

Возможно, за последние 10 лет встроенное программное обеспечение прошло долгий путь, но мы обычно делали следующее:

for algorithms that didn't depend on the target hardware, we simply had unit tests that were built and tested on a non-embedded platform. for stuff that did require the hardware, unit tests were conditionally compiled into the code to use whatever hardware was available. In our case, it was a serial port on the target pushing the results to another, more capable, machine where the tests were checked for correctness. Depending on the hardware, you could sometimes dummy up a "virtual" device on a non-embedded platform. This usually consisted of having another thread of execution (or signal function) changing memory used by the program. Useful for memory mapped I/O but not IRQs and such. typically, you could only unit test a small subset of the complete code at a time (due to memory constraints). for testing of time-sensitive things, we didn't. Plain and simple. The hardware we used (8051 and 68302) was not always functional if it ran too slow. That sort of debugging had to be done initially with a CRO (oscilloscope) and (when we had some more money) an ICE (in-circuit emulator).

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

 30 июн. 2009 г., 06:42
Есть TONS в системах, которые строятся и проектируются сегодня с uC на основе 8051, и даже больше с PIC, который очень похож на уровень архитектуры / производительности, как современные 8051.
 30 июн. 2009 г., 06:11
Насколько я знаю, это звучит очень похоже на современное состояние, по крайней мере, на основе работы с TI TMS320 в течение последнего года или около того.
 10 нояб. 2014 г., 23:19
Я поддерживаю идею тестирования алгоритмов в не встроенных средах. Это сэкономило мне массу работы (идеально подходит для кодирования / декодирования связи, преобразования АЦП в расчетные единицы и т. Д.). Это похоже на то, о чем должно быть написано много книг ... (ответ Мэтью Ранкина выглядит интересным).
 30 июн. 2009 г., 06:24
Вы имеете в виду, что перечисленные методы являются «современными», я надеюсь. Конечно, никто не все еще использует 8051 (68302 было бы хорошо, так как у меня остались приятные воспоминания о Motorola 68k - этоstill более чистая архитектура, что х86 имншо)? Я надеялся, что вся новая встроенная разработка будет сделана на Intel-клонах из-за множества вариантов разработки.

Когда я столкнулся с этим в прошлом году, я действительно хотел протестировать на самой встроенной платформе. Я разрабатывал библиотеку и использовал вызовы RTOS и другие функции встроенной платформы. Ничего конкретного не было доступно, поэтому я адаптировал код UnitTest ++ для своих целей. Я программирую наNetBurner семейство, и поскольку у него есть встроенный веб-сервер, было довольно просто написать веб-интерфейс для тестирования GUI, дающий классическую обратную связь RED / GREEN. Этооказалось довольно хорошои теперь модульное тестирование стало намного проще, и я чувствую себя намного увереннее, зная, что код работает на реальном оборудовании. Я даже использую инфраструктуру модульного тестирования для интеграционных тестов. Сначала я проверяю / заглушаю аппаратное обеспечение и внедряю этот интерфейс для тестирования. Но в конце концов я пишу несколько тестов «человек в цикле», в которых используется реальное оборудование. Оказывается, это гораздо более простой способ узнать об оборудовании, а также легко избавиться от встроенных ловушек. Поскольку все тесты выполняются от обратных вызовов AJAX до веб-сервера, перехват происходит только в результате ручного вызова теста, и система всегда перезапускается чисто через несколько секунд после перехвата.

NetBurner достаточно быстр, чтобы цикл записи / компиляции / загрузки / запуска составил около 30 секунд.

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

Если выwriting интерфейс связи, извините.

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

Вы можете проверитьTest Driven Development for Embedded C Джеймсом У. Греннингом. Выход книги запланирован на август 2010 года, но бета-версия книги уже доступнаПрагматичная книжная полка.

 24 июн. 2010 г., 14:23
Я только что купил эту книгу. Сейчас я переезжаю во встроенный мир, и я хотел бы использовать модульное тестирование с Microchip C30, и у меня возникли трудности.

Нам удается протестировать немало аппаратно-зависимого кода с помощью симулятора, мы используем симулятор Keil и IDE (не аффилированные, просто используйте их инструменты). Мы пишем сценарии симулятора для управления «аппаратным обеспечением». мы ожидаем, что это отреагирует, и мы можем довольно надежно протестировать наш рабочий код. Конечно, может потребоваться некоторое усилие, чтобы смоделировать оборудование для некоторых тестов, но для большинства вещей это работает очень хорошо и позволяет нам многое сделать без доступного оборудования. Мы смогли получить почти полную систему, работающую в симуляторе, до того, как получили доступ к аппаратному обеспечению, и у нас было очень мало проблем, которые нужно было решить, как только код был реализован. Это также может значительно ускорить производство кода, так как все может быть выполнено на ПК с помощью более глубокого отладчика, имитирующего чип, и пытающегося делать все на оборудовании.

Надежно это работает для сложных систем управления, интерфейсов памяти, пользовательских микросхем, управляемых SPI, и даже для моно-дисплея.

Модульное тестирование в среде ПК может принести много пользы (компиляция кода с помощью компилятора PC C и запуск кода в среде модульного тестирования ПК) с несколькими условиями:

This doesn't apply to testing your low-level code, including start-up code, RAM tests, hardware drivers. You'll have to use more direct unit testing of those. Your embedded system's compiler has to be trustworthy, so you're not hunting for bugs created by the compiler. Your code has to be layered architecture, with hardware abstraction. You may need to write hardware driver simulators for your PC unit testing framework. You should always use the stdint.h types such as uint16_t rather than plain unsigned int etc.

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

Преимущества модульного тестирования на платформе ПК:

You don't face the problem of running out of ROM space on your embedded platform due to adding a unit testing framework. The compile-link-run cycle is typically faster and simpler on the PC platform (and avoids the 'write/download' step which can potentially be several minutes). You have more options for visualising progress (some embedded applications have limited I/O peripherals), storing input/output data for analysis, running more time-consuming tests. You can use readily available PC-based unit test frameworks that aren't available/suitable for an embedded platform.

Ваш ответ на вопрос