реклама на сайте
подробности

 
 
 
Reply to this topicStart new topic
> Как писать или генерировать тест - кейсы(векторы) для автоматического тестирования встроенной электроники и ПО?
syoma
сообщение May 1 2018, 17:15
Сообщение #1


Профессионал
*****

Группа: Свой
Сообщений: 1 817
Регистрация: 14-02-07
Из: наших, которые работают за бугром
Пользователь №: 25 368



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

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

Спецификаций на ПО или функциональность изделия, как таковых, нет, а точнее функциональность ушла от них далеко вперед.
Спасибо.
Go to the top of the page
 
+Quote Post
mantech
сообщение May 1 2018, 17:54
Сообщение #2


Гуру
******

Группа: Участник
Сообщений: 2 213
Регистрация: 16-08-12
Из: Киров
Пользователь №: 73 143



Цитата(syoma @ May 1 2018, 20:15) *
Собственно вопрос такой


Честно не понял в чем вопрос, вам нужно проверять сами блоки (аппаратную часть) или тестить программу?
Go to the top of the page
 
+Quote Post
syoma
сообщение May 1 2018, 19:51
Сообщение #3


Профессионал
*****

Группа: Свой
Сообщений: 1 817
Регистрация: 14-02-07
Из: наших, которые работают за бугром
Пользователь №: 25 368



Цитата(mantech @ May 1 2018, 19:54) *
Честно не понял в чем вопрос, вам нужно проверять сами блоки (аппаратную часть) или тестить программу?

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

А для отладки и тестирования программы использовать unit-тесты, созданные на основе анализа исходников? Или что-то другое?
Go to the top of the page
 
+Quote Post
mantech
сообщение May 8 2018, 12:58
Сообщение #4


Гуру
******

Группа: Участник
Сообщений: 2 213
Регистрация: 16-08-12
Из: Киров
Пользователь №: 73 143



Цитата(syoma @ May 1 2018, 22:51) *
И то и другое. Я так понимаю, что вы предлагаете прошивать тестовые программки в сам контроллер устройства и по ним проверять только железо, рассчитывая, что однажды отлаженная программа не может сбоить?

А для отладки и тестирования программы использовать unit-тесты, созданные на основе анализа исходников? Или что-то другое?


Отладка железа - это самое простое, закидываем тестовую прогу, подключаем железку к стенду, лампочкам с кнопками или все это ввиде автомата, эмулирующего работу входных\выходных каналов, и запускаем тест.

С программой все намного сложнее, составляем план тестовых испытаний того функционала, который должна выполнять программа, и пошагово тестируем все это N раз.
Затем стресс-тестирование, проверяем исключительные ситуации (внезапное включение\выключение питания, изятие носителей информации, если есть усб и пр. хотплаг порты - проверяем на подкл\отключение) имитация "дурака" - защита от всяких непонятных поведений клиента, нажатие кучи кнопок в разных режимах и т.п.
По результатам пишется отчет(а 100% работоспособности после таких тестов никогда с первого раза не бывает) и устраняем... Потом снова, и так до полного работоспособного устройства biggrin.gif
Go to the top of the page
 
+Quote Post
juvf
сообщение May 8 2018, 13:44
Сообщение #5


Профессионал
*****

Группа: Свой
Сообщений: 1 261
Регистрация: 14-05-09
Из: Челябинск
Пользователь №: 49 045



Цитата(syoma @ May 1 2018, 22:15) *
как можно применить данный стенд для автоматического разностороннего тестирования производимых блоков на этапе производства, чтобы выявить возможные дефекты ... ПО.
То есть должно быть возможным написание тестовых векторов, которые бы в итоге покрыли 100% ПО ...
Что касается тестирования ПО при производстве - то ни как! вернее можно наверно..... но зачем ПО тестировать на этапе производства? ПО тестируется на этапе разработки этого ПО. Допустим у вас устройство считывает данные с датчика по SPI, обрабатывает ОЧЕНЬ ОЧЕНЬ сложным алгоритмом и отправляет в уарт. При производстве возможен брак деталей, а возможен непропай, залипуха, обрыв дорожки. Нужно проверять чтобы аппаратно было всё исправно. а зачем тестировать при производстве ПО? Или вы хотите тестировать алгоритм при производстве? Думаете он будет разный? ПО - это набор машинных кодов. ПО тестируется путем верификации при прошивании. Или вы думаете, что в одна и таже программа будет работать по разному в одинаковых устройствах и её нужно тестировать?

У нас автоматизированное тестирование аппаратной части. Заливаем тестовую прошивку, она генерирует тестовые сигналы которые проверяет стенд, получает тестовые сигналы и выдает ответ стенду. На этом этапе проверяется вся аппаратная часть. Чтобы SPI долетал до процессора, чтобы GPIO были пропаяны, чтобы шина DDR была пропаяна. Чтобы внешняя периферия работала исправно. А алгоритмы рабочей программы - они постоянны и не зависят ни от чего.
Go to the top of the page
 
+Quote Post
mantech
сообщение May 8 2018, 14:22
Сообщение #6


Гуру
******

Группа: Участник
Сообщений: 2 213
Регистрация: 16-08-12
Из: Киров
Пользователь №: 73 143



Цитата(juvf @ May 8 2018, 16:44) *
А алгоритмы рабочей программы - они постоянны и не зависят ни от чего.


Если ПО не меняется, то тестируем один раз, как написал выше, но есть изменения, нововведения вот их приходится тестировать снова...
Go to the top of the page
 
+Quote Post
turnon
сообщение May 8 2018, 18:18
Сообщение #7


Местный
***

Группа: Свой
Сообщений: 340
Регистрация: 17-10-14
Пользователь №: 83 207



Если я правильно понял, вам хочется тестировать все многообразие логики и реакция системы на многообразие раздражителей (входных сигналов). Лучше всего для этого логику отделить слоем асбтракции от железа. В этом случае логика у вас выйдет например на чистом С/С++. И вот для этого уже можно пеисать автоматические тесты на "большом брате", а в качестве слоя железа в это время подсунуть реализацию с выводом в текстовый файл, содержимое тесктовых файлов в этом случае будут проверяться в тестах.

А то встречал код GSM сигализации, где "бизнес логика" зашита прямо в обработчике приема SMS и все в таком стиле. Жуть какая, как они в этом разбираются, это надо иметь супермозг, чтобы производить такое ПО без тонны глюков.


Цитата(syoma @ May 1 2018, 20:15) *
Возможно ли автоматизировать написание таких тестов, если их надо будет достаточно много?

Возможна автоматизация запуска тестов. Можно даже на МК - cutest
Go to the top of the page
 
+Quote Post
syoma
сообщение May 9 2018, 11:17
Сообщение #8


Профессионал
*****

Группа: Свой
Сообщений: 1 817
Регистрация: 14-02-07
Из: наших, которые работают за бугром
Пользователь №: 25 368



Цитата(juvf @ May 8 2018, 15:44) *
У нас автоматизированное тестирование аппаратной части. Заливаем тестовую прошивку, она генерирует тестовые сигналы которые проверяет стенд, получает тестовые сигналы и выдает ответ стенду. На этом этапе проверяется вся аппаратная часть. Чтобы SPI долетал до процессора, чтобы GPIO были пропаяны, чтобы шина DDR была пропаяна. Чтобы внешняя периферия работала исправно. А алгоритмы рабочей программы - они постоянны и не зависят ни от чего.

Я и хотел что-то такое услышать. Я тоже думаю, что ПО в тестировании на производстве не нуждается, хотя вроде как слышал утверждения, что нифига - ПО на производстве тоже надо проверять.
Go to the top of the page
 
+Quote Post
one_eight_seven
сообщение May 9 2018, 12:30
Сообщение #9


Знающий
****

Группа: Участник
Сообщений: 915
Регистрация: 3-10-08
Из: Москва
Пользователь №: 40 664



Цитата(syoma @ May 9 2018, 14:17) *
Я и хотел что-то такое услышать. Я тоже думаю, что ПО в тестировании на производстве не нуждается, хотя вроде как слышал утверждения, что нифига - ПО на производстве тоже надо проверять.

Если абсолютно всё ПО, включая бутлодыри - ваше, то достаточно проверить как хорошо собрано устройство (ну и версию кремния). Это можно делать с помощью тестового ПО, если не осилили или если нет нужды превозмогать Boundary Scan, или, если превозмогли, то с помощью Boundary Scan через тот же JTAG.

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

ПО в данном случае нужно проверять на самые критические функции - собственно, обеспечение канала связи и возможность изменения прошивки устройства.

Сообщение отредактировал one_eight_seven - May 9 2018, 12:32
Go to the top of the page
 
+Quote Post

Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 24th September 2018 - 05:55
Рейтинг@Mail.ru


Страница сгенерированна за 0.01056 секунд с 7
ELECTRONIX ©2004-2016