Драйверы устройств поблочного тестирования

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

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

Возвращаясь к самому низкому уровню - если он зависит от аппаратного обеспечения, тогда в тестовом джиге должно быть аппаратное обеспечение. Вы можете создать тестовый джиг, который включает аппаратное обеспечение, драйвер и некоторое тестовое программное обеспечение. Я думаю, что главное - вывести из теста код приложения нормального продукта и вместо него вставить некоторый тестовый код. Тестовый код может систематически проверять все возможности и «углы» драйвера (чего не может быть в коде приложения), а также может действительно интенсивно ударять драйвер за короткое время (чего, вероятно, нет в приложении). Таким образом, это более эффективно использует ваше ограниченное оборудование, чем просто приложение, и дает вам лучшие результаты.

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

• Записать тестовый код для встроенного устройства, которое отправляет различные известные потоки данных.
• Подключите его к последовательному порту ПК, запустив тестовый код, который проверяет передаваемые потоки данных.
• То же в другом направлении - ПК отправляет данные; встроенное устройство получает его, проверяет и уведомляет ПК о любых ошибках.
• Тесты могут выполнять потоковую передачу данных на полной скорости и воспроизводить различные интервалы времени байтов (однажды я обнаружил кремниевую ошибку микроконтроллера UART, которая появлялась только в том случае, если байты были отправлены с задержкой ~ 5 мс между байтами).

Вы можете сделать то же самое с драйвером Ethernet, драйвером Wi-Fi.

Если вы тестируете драйвер запоминающего устройства, например, для EEPROM или микросхемы Flash, то ПК не может подключиться таким же образом. В этом случае ваш тестовый комплект может протестировать все виды условий записи (однобайтовые, блочные ...) и проверить целостность данных, используя всевозможные условия чтения.

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

• сбой только одного процесса, в отличие от способности одной системы
• использовать стандартный набор инструментов (отладчик, проверка памяти ...)
• преодолеть ограничение доступности оборудования
• более быстрая обратная связь: нет установки в устройстве, просто скомпилируйте и протестируйте
• ...

Что касается именования, это можно назвать тестированием компонентов.

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

У меня была похожая проблема два или три года назад. Я перенес драйвер устройства из VxWorks в Integrity. Мы изменили только зависимые от операционной системы части драйвера, но это был критически важный проект с точки зрения безопасности, поэтому все модульные тесты, интеграционные тесты были переделаны. Для наших модульных тестов мы использовали инструмент автоматического тестирования, называемый LDRA testbed. 99% наших модульных тестов выполняются на машинах Windows с компиляторами Microsoft. Теперь я объясню, как это сделать

. Прежде всего, когда вы выполняете модульное тестирование, вы тестируете программное обеспечение. Когда вы включаете реальное устройство в свои тесты, вы также тестируете устройство. Иногда могут возникнуть проблемы с оборудованием или документацией на оборудование. Если при разработке программного обеспечения вы четко описали поведение каждой функции, сделать модульное тестирование очень просто, например, подумайте о функции;

readMessageTime(int messageNo, int* time); 
//This function calculates the message location, if the location is valid, 
//it reads    the time information 
address=calculateMessageAddr(messageNo); 
if(address!=NULL) { 
    read(address+TIME_OFFSET,time); 
    return success; 
} 
else { 
return failure; 
} 

Ну, здесь вы просто проверяете, выполняет ли readMessageTime то, что он должен делать. Вам не нужно проверять, вычисляет ли calculateMessageAddr правильный результат или read читает правильный адрес. Это ответственность некоторых других модульных тестов. Итак, что вам нужно сделать, это написать заглушки для calculateMessageAddr и read (функция ОС) и проверить, вызывает ли он функции с правильными параметрами. Это тот случай, если вы не обращаетесь к памяти напрямую из драйвера. Вы можете протестировать любой код драйвера без какой-либо ОС или устройства с таким менталитетом.

Если вы сопоставили память устройства непосредственно с пространством вашей памяти, и драйвер устройства читает и записывает в память устройства, поскольку это его собственная память, он получает немного сложно. Используя инструменты автоматического тестирования, теперь вы должны следить за значениями указателей и определять критерии «годен / не годен» в соответствии со значениями этих указателей. если вы читаете значение из памяти, вы должны определить ожидаемое значение. В некоторых случаях это может быть сложно.

Есть еще одна проблема, разработчики всегда путают при модульном тестировании драйверов, например:

 readMessageTime(int messageNo, int* time); 
 //This function calculates the message location, if the location is valid,
 //it does some jobs to make the device ready to read then 
 //it reads the time information 
 address=calculateMessageAddr(messageNo); 
 if(address!=NULL) { 
      do_smoething(); // Get the device ready to read!    
      do_something_else() // do some other stuff so you can read the result in 3us.
      status=NOT_READY;
      while(status==NOT_READY) // mustn't be longer than 3us.
           status=read(address+TIME_OFFSET,time); 
      return success; 
  } else 
  { 
  return failure; 
  } 

Здесь do_something и do_something_else выполняют некоторые действия на устройстве, чтобы подготовить его к чтению. Разработчики всегда спрашивают себя: «Что, если устройство не будет готово к работе навсегда, и мой код зайдет в тупик», и они склонны тестировать подобные вещи на устройстве.

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

Надеюсь, это поможет….

Словарь

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

Тогда вы выходите из юнит-тестирования. Может быть, вместо этого можно использовать одно из этих выражений?

• Автоматическое тестирование: тестирование происходит без участия пользователя (в отличие от тестирования Manual Testing).
• Интеграционное тестирование: тестирование нескольких компонентов вместе (в отличие от тестирования Unit).
  . В более широком масштабе, если тестировать целую систему, а не несколько компонентов вместе, то это называется тестированием System.

ДОБАВЛЕНА после комментариев и обновлений в вопросе :

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

Преимущества "реального" юнит-тестирования

С интеграционным (или системным или компонентным) тестированием, безусловно, интересно получить некоторую обратную связь, например, покрытие теста. Это, безусловно, полезно.

Но очень трудно (читай "очень дорого") добиться прогресса за пределами какого-то момента, поэтому
Я предлагаю использовать дополнительные подходы, например, добавить несколько реальных юнит-тестов. Почему? :

• Очень сложно симулировать условия края или ошибки. (Примеры: во время транзакции компьютерные часы пересекают день или год; сетевой кабель отключен; питание отключено, а затем на каком-то компоненте, или на всей системе; диск переполнен). Использование модульного тестирования, так как вы моделируете эти условия, а не пытаетесь их воспроизвести, гораздо проще. Юнит-тестирование - это ваш единственный шанс получить действительно хорошее покрытие кода.
• Интеграционное тестирование занимает время (из-за доступа к внешним ресурсам). Во время выполнения одного интеграционного теста можно выполнить тысячи юнит-тестов. Поэтому тестирование многих комбинаций возможно только с помощью юнит-тестов...
• Требуя доступа к определенным ресурсам (hardware, Licence и т.д...), интеграционное тестирование часто ограничено по времени или масштабу. Если ресурсы совместно используются другими проектами, каждый проект может использовать их только в течение нескольких часов в день. Даже при эксклюзивном доступе, возможно, только одна машина может его использовать, поэтому параллельно запускать тесты нельзя. Или же ваша компания может купить ресурс (Licence или Hardware) для производства, но не иметь его (или достаточно рано) для разработки...

У меня была именно эта задача всего два месяца назад.

Дайте угадаю: У вас, вероятно, есть «фрагменты» кода, которые сообщают устройству детали низкого уровня. Вы знаете, что эти фрагменты работают, но вы не можете охватить их, потому что они зависят от драйверов устройств.

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

Вы НЕ хотите тестировать низкоуровневые материалы. Тогда ваши модульные тесты будут отражать только то, как вы предполагаете , что устройство работает, ничего не подтверждая.

Ключевым моментом здесь является создание трех элементов: контроллера, абстракции и адаптера, реализующего эту абстракцию. В Cpp, Java или C # вы должны создать базовый класс или интерфейс для представления этой абстракции. Я предполагаю, что вы создали интерфейс. Вы разбиваете фрагменты на атомарные операции. Например, вы создаете в интерфейсе методы с названиями «start» и «add (parameter)». Вы помещаете свои фрагменты в адаптер устройства. Контроллер воздействует на адаптер через интерфейс.

Определите элементы логики в фрагментах, которые вы поместили в адаптер. Затем вам нужно решить, является ли эта логика низким уровнем (детали обработки протокола и т. Д.) Или это логика, которая должна принадлежать контроллеру.

Затем вы можете выполнить тестирование в два этапа: * Имейте простое приложение тестовой панели, которое действует на конкретный адаптер. Это используется для подтверждения того, что адаптер действительно работает. Вот и запускается при нажатии "старт". Это, например, если вы последовательно нажимаете «перейти в автономный режим», «передать (192)» и «перейти в оперативный режим», устройство будет реагировать должным образом. Это ваш интеграционный тест.

Вы не выполняете модульное тестирование деталей в адаптере. Вы проверяете это вручную, потому что единственный критерий успеха - это реакция устройства.

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

Затем вы пишете модульные тесты, чтобы подтвердить, что, например, метод «Add (1)» на самом деле вызывает «Перейти в автономный режим», затем «Transmit (1)», а затем «Перейти в онлайн» на имитируемой абстракции.

Задача состоит в том, чтобы провести различие между адаптером и контроллером. Что куда? Что сработало для меня, так это сначала создать вышеупомянутую тестовую панель, а затем управлять устройством через нее.

Адаптер должен скрыть детали, которые вам нужно будет изменить только при изменении устройства.

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

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