Comments 14
Ребята, такой подход к тестированию конкретной отладочной платы рулит, в том случае когда производство ее на потоке рассчитано как минимум на 3 - 5 лет без каких либо изменений в ее процессорной архитектуре. Опять же такую "станцию" никак нельзя строить на опенсорсе, или сразу с себя снимать ответственность перед клиентом за ее стабильность и функционал. Обычно производители такие тесты хранят как зеницу ока, т.к. это часть их конкуренции в условиях агрессивного рынка.
Что касается среды исполнения тест бенча, применительно к фикстуре испытуемой платы (разработчики платы обязаны в процессе ее разводки размещать тест поинты по по всем точкам, подлежащим контролю, с целью выявления отклонений от рабочих параметров).
В статье есть ряд тестов, которые перенасыщают алгоритм теста.
Так к примеру:
Проверить наличие приборов;
Проверить наличие прошивки для DUT;
Прошить DUT;
Если прибор это встроенный в отладочную плату модуль, то это не прибор, а четкое понятие к примеру схема шлюза, интерфейсного преобразователя, драйвер и т.п. и если он отвечает за обмен данными с внешним ПК, то успешная прошивка (перезапись) это часть одного теста, при том, что предшествующие тесты питаний в определенных тест поинтах прошли успешно.
Далее переход к следующим тестам согласно сценария тет бенча.
Я не стал разбирать всю логику алгоритма в приведеном примере, т.к. что захотели, то и протестировали, Самый важный аспект во всех тест бенчах - минимализм с охватом всей процессорной архитектуры с конечным результатом того, что имеем на GPIO, при условии что обратная связь отладочной карты так же тестируется по сценарию - счет/триггер/индикация события.
Ну и самый важный момент - станция должна нести на себе среду визуального построения тестов, которые можно быстро, без привлечения кодеров (программистов - разрабов) отдать в личное пользование клиенту (его сервисному персоналу).
Никак нельзя строить на опенсурсе - шта? Питон нельзя использовать? Он тоже опенсурсный сам по себе если что.
Строить (писать) тестбенч можно на всем, на чем Вы умеете, но он должен иметь достаточную защиту несанкционированного доступа, в т.ч. и среды разработки таких тестов, к слову тесты могут быть финальными с функциями автоматизированной юстировки ряда параметров по результатам промежуточного сбора данных и т.п.
Все прочие опенсорсные хотелки применимы исключительно с целью дать волю народному творчеству в таком развлечении, но кто будет такие карты покупать в свои ответственные прототипы или проекты.... это грабли, где никто не несет ответсвенность за последствия.
Никто никому ничего не должен, пока мы не определимся что мы делаем, для кого мы делаем и по каким требованиям. В статье про это не было ничего сказано.
Как не тратить время на велосипеды, а просто написать тесты на python и наслаждаться стабильно работающими тестовыми станциями на производстве электроники? Конечно, используя open source решение HardPy.
И далее речь идет об использования функций HardPy - открытого фреймворка .
Так из статьи и не понял, что в фреимворке открыто, его логическое ядро или его инструменты для работы с исходниками (тестбенчи). Если доступ к ядру, то это то о чем я говорю, все остальное круги по воде, если Вы предлагаете в открытых ресурсах людям строить эти загрузочные файлы для проведения тестов на свой страх и риск что в результате не спалите порты по причине ошибки написания тб.
Обычно производители такие тесты хранят как зеницу ока
Очень разные встречаются производители. Некоторые не дают тестовые станции на контрактное производство, всю партию везут себе в офис. А другие не в курсе, какую именно версию теста запускали на производстве сегодня. Это всё реальные истории, если что. разработчики платы обязаны в процессе ее разводки размещать тест поинты по по всем точкам, подлежащим контролю, с целью выявления отклонений от рабочих параметров
Мы даже статью когда-то про это написали Если прибор это встроенный в отладочную плату модуль, то это не прибор
Так это же для примера. Представьте, что программатор внешний, если смущает что тут он встроен в плату. самый важный момент станция должна нести на себе среду визуального построения тестов, которые можно быстро, без привлечения кодеров (программистов - разрабов) отдать в личное пользование клиенту (его сервисному персоналу).
Почему визуальная среда это самый важный момент? Если у заказчика нет экспертизы или нет разработчиков, он не полезет исправлять тесты. Зачем это ему? А если у заказчика есть экспертиза и разработчики — они скорее выберут знакомый пайтон, чем осваивать новую визуальную среду, да ещё под виндоуз.
Почему визуальная среда это самый важный момент? Если у заказчика нет экспертизы или нет разработчиков, он не полезет исправлять тесты. Зачем это ему? А если у заказчика есть экспертиза и разработчики — они скорее выберут знакомый пайтон, чем осваивать новую визуальную среду, да ещё под виндоуз.
Потому что такова мировая стратегия современного рынка сборщиков. Есть компактная самостоятельная R&D структура (Стартап или грамотные ребята) которые создают и выбрасывают решение в открытый космос по какой то коммерческой модели и есть сборщики, которые мало что понимают в схемотехнике, при этом они отвечают за качество сборки. Чем выше качество, тем сборщик дороже. Наши веселые толковые ребята обязаны сборщикам отдать полный пакет инструкций по сборке и контролю качества включая и методы. Сборщик не вникая в детали берет все это на вооружение своим не так чтоб продвинутым персоналом (вахтовики ктай однако) в составе PCB автоматизированных паяльных станков (принтера), печи, мойщики, визуальный контроль и финальный контроль, где сидят какие то Сян, Зын и Пины и с умным выражением лица втыкают готовые PCB в фикстуры, жмут на кнопку и ждут пока тест не выдает результат и выглядит это так, как я Вам указал в линке выше в ответах. Есть там как правили и парень по имени Чо, который отвечает за QСI и в случае проблем держит связь с веселыми R&D ребятами.
Как Вы думаете какая плата на полке магазина будет дешевле? Та которую полуобразованный Чо проверял по инструкциям R&D И в случае необходимомсти правил инструкцию для теста в среде ее разработки или дорогой парень Ху, который для изменения плохого параметра тестируемого этапа правил в скрипте на языке в котором R&D понимают только скрипт и диктуют парню Ху этот скрипт (Ху говорит на английском как птица).
Дальше все по эффекту падающего домино с OC и прочими шишчаками...
Это всего лишь опыт более 20 лет в этой и смежным темам...)
Не все ваши мысли мне понятны, постараюсь ответить, где смог разобраться. Насколько я понял, вы занимаетесь построением тестовых решений на LabView, приобретая лицензии для каждой тестовой станции. По нашим исследованиям, большая часть продуктовых команд делают стенды сами, программируя на том, что им удобно(C, python,...). Наша целевая аудитория - такие команды, которые и так используют python в своём тестировании.
Я сходил по ссылке и посмотрел ваше рекламное видео. Вот примеры интерфейсов оператора из него:
Если вы прочитали статью, то заметили, что предлагаемый фреймворк как раз даёт возможность получить панель оператора, когда тесты написаны на python. На рабочей станции запускается не LabView, а HardPy, вот и вся разница. Для вашего удобства приведу пример интерфейса из статьи:
На наш взгляд, подробное информирование оператора стенда о результатах всех измерений (например, напряжение до десятков мВ) избыточно в большинстве случаев. Возможно, это полезно при ремонте дефектных изделий или отладке.
Мне показалось, что вы имеете в виду, что на производстве сами меняют тестовый план, поэтому нужно иметь визуальный инструмент автоматизации. Нам эта позиция не близка, заказчик должен контролировать объём и глубину тестирования, на производстве доступа к модификации тестового ПО и железа быть не должно.
Про критику отдельных шагов тестирования и план тестирования в целом - статья не про это, пример может быть любым.
P.S.Ваши высказывания о людях другой национальности это, конечно, дно.
полуобразованный Чо проверял по инструкциям R&D И в случае необходимомсти правил инструкцию для теста в среде ее разработки
Эээ. Зачем разрешать персоналу на производстве что-либо исправлять в тесте?
По личному опыту кооперации с разными сборщиками, более менее серьезные имеют подразделение QCI которые отвечают за финальное тестирование.и если их клиенты требуют проведение QCI то сборщики, основным условием проведения выставляют требование оснащения их комплектным стендом (фикстура и ПО), включая и консультации со стороны такого заказчика. Среди них есть инженеры, которые принимают это у клиентов ( разрабов) и получают от них доступ к функциям среды построения тест бенчей. Делается это по согласованию с клиентом и под его надзором, часто удаленно. По месту сборки всегда есть какие то тонкости настройки или изменений верификации. К примеру некоторые PCB компоненты, те же кварцы или конденсаторы и т.п. идут на потоке с отклонениями что в целом влияет на контролируемые параметры, такие ситуации довольно часто происходят и чтоб не сидеть в безвылазных командировках с авиа перелетами, часть ответственных задач возлагается на местный персонал, который ни бельмеса в скрипт языках не понимает и ничего на них никогда не писал. Как правило это среднего уровня специалисты - электронщики и годятся для работы под удаленным надзором клиента. Вот для этого и создаются такие инструменты, которые расширяют аудиторию пользователей без тех или иных навыков. Но это уже история другая не про эту публикацию, а минусатры с чем не согласны или отпишитесь здесь, что не так, или засуньте свои минусы себе в сад.
Насколько я понял, вы занимаетесь построением тестовых решений на LabView, приобретая лицензии для каждой тестовой станции. По нашим исследованиям, большая часть продуктовых команд делают стенды сами, программируя на том, что им удобно(C, python,...). Наша целевая аудитория - такие команды, которые и так используют python в своём тестировании.
Верно то, что наша IDE построена на базе LabView (логическое ядро), что по сути так же выполняет роль софт контроллера с функциями внешнего визуального программирования.
Что касается лицензирования, то политика NI допускает бесплатную передачу аппликаций на сторону в виде скомпилированного в закрытый exe формат исходника включая пользовательский интерфейс и при этом нет необходимости в установке на стороне клиентов LabView. В процессе компиляции проектных файлов в состав исходника подгружается рантаим и все дела.
Что касается целевой аудитории, то она довольно обширна но как правило на 80% это все же сборщики которые выполняют массовый процесс. Так же среди клиентов есть и те, которым требуются не только тесты но и испытания на по требованиям 3-х лиц и органов контроля. Речь идет о готовом приборе. Кроме в.п. у нас так же некоторые R&D просят стенды для собственных исследований в процессе прототайпинга. Замечу многие из них отказались от штатного персонала разработчиков таких тестбенчей и стендов по причине их (человеко часов) стоимости.
P.S.Ваши высказывания о людях другой национальности это, конечно, дно.
К национальности это никаким боком не имеет отношения, кок понимаю Вы не имели раньше опыта кооперации с китайскими сборщиками. Все остальные Ваши домыслы и догадки оставьте на опенсорс растерзание. Желаю успехов.
Спасибо за статью и отдельное - за приверженность опенсорсным идеям! Вопросы:
Как осуществляется работа с версионированием тестов И версионированием самих отчетов? Поясню: на протяжении всего product lifetime могут использоваться разные компоненты, или реальность вынуждает вносить изменения в сами тесты без модификаций DUT. В этом случае отчет должен отличаться, но все еще должна сохраняться возможность сравнения результатов тестов из отчетов с разными конфигами. Есть ли у вас какое-то красивое решение для этого?
Предлагает ли hardpy инструменты для реализации тестирования различных вариаций DUT с незначительными отличиями на одной и той же станции, когда flow должен идти по-разному, например региональная локализация? Если ветвление в этом случае должно осуществляться внутри самих тестов, то какие способы вы предлагаете, чтобы перед тестированием сообщить станции, какую именно модификацию мы сейчас собираемся тестировать?
Практическое: как обрабатываются кейсы, когда DUT отваливается в процессе теста? Что будет в отчете в этом случае? Речь про ошибки, происходящие на уровне фикстур, умеет ли hardpy их перехватывать?
Прямо сейчас в схеме json документа отчета нету раздела под версионирование. Однако, есть разделы, в которые может быть записана требуемая информация. Для этого могут быть использованы функции set_dut_info() для хранении информации, характерной для DUT (конфиг), и set_run_artifact(), куда, например, можно записывать версию отчета. Но так как продукт развивается, всё может быть добавлено в будущем :)
Ветвление однозначно должно происходить внутри тестов. Сейчас примера запуска hardpy (или pytest) с различными конфигами нету.
Если ошибка произошла после создание экземпляра драйвера, то далее она может быть перехвачена pytest, и HardPy транслирует её в панель оператора и БД, как
assertion_msg. Случай перехвата ошибки на этапе вызова фикстуры с созданием экземпляра драйвера не реализован.
Очень круто! Спасибо. Я для тестирования своего устройства подключаю к его входам ESP , которая по Wi-Fi подключена к ПК и пишут тесты, которые управляют выводом и проверяют вводы ESP, также ESP опрашивает по i2c проверяемый контроллер.
https://github.com/dontsovcmc/metfapi = ESPTestFramework(host)
api.pinMode(D5, INPUT_PULLUP)
# оператор нажимает кнопку
assert api.wait_digital(D5, LOW, 5.0), "Button wasn't pressed (5 sec elapsed)"
Hardpy. Nucleo-f401 example — автоматизируем тестирование электроники на производстве на Python