Секреты тестирования Wiren Board: test-suite и крафтовые стенды
Мы продолжаем рассказывать о внутренней кухне Wiren Board. В предыдущей статье мы заставили работать китайский паяльный робот, который выполняет рутинную часть работы монтажников на нашем производстве. Но производство — лишь один из этапов. Все наши «железки» должны поступать клиентам в рабочем состоянии и служить максимально долго. Именно по этой причине после производства все устройства проходят тестирование.
Настало время рассказать о фирменном программном пакете test-suite, который мы разработали специально для тестирования устройств Wiren Board на разных стендах. Причем стенды мы тоже разрабатывали и собирали своими руками, некоторые из них мы покажем в статье.
Структурная схема test-suite. В центре ядро, в которое с помощью плагинов добавляются нужные функции
Каким должно быть тестирование?
Тестировать нужно каждый выпускаемый продукт — с этим, вряд ли, кто-то будет спорить. С одной стороны, тестирование должно быть быстрым, чтобы успевать за производством. С другой стороны, полнофункциональным, чтобы гарантировать корректную работу всех функций. Но на каждый тест уходит время. Наша задача — получить правильный баланс, то есть разработать набор тестов, который будет гарантировать выполнение всех заявленных функций устройством, но вместе с тем занимать приемлемое время.
По этой причине перед тем, как собрать тестовый стенд и написать тестовые сценарии, мы проводим мозговой штурм. Инженеры-разработчики устройства совещаются с инженерами тестирования и программистами. Тестирование у нас функциональное, то есть мы подключаемся к устройству снаружи, как к «черному ящику», и проводим тесты. Есть исключения, но их немного. Мы проверяем отсутствие аппаратных неисправностей. Если все узлы устройства исправны, то переходим к небольшой проверке софтовой части. Для одних устройств программных тестов больше, для других — меньше.
Например, у modbus-устройств мы проверяем исправность отдельных реле, сенсоров, цепей питания, внутренней памяти. Для контроллеров важна исправность процессорного модуля, часовых кварцев, всех видов внутренней памяти, портов USB, CAN, RS-485, Ethernet, и т.д. Конкретный набор тестов может отличаться в зависимости от типа, партии и ревизии устройства.
Дополнительные фото
Софтовые тесты выполняются, в первую очередь, на стендах отделов разработки прошивок/софта, но самые «узкие места» также проверяются и на наших стендах при производстве. Порой, кстати, именно на производстве вскрываются софтовые проблемы: будь то в прошивке modbus-устройства или софте контроллера.
Набор тестов для каждого устройства — ноу-хау компании, поэтому подробности мы будем раскрывать в следующих статьях цикла. Пока лишь скажем, что инженерам много раз пришлось поломать голову при поиске оптимальных сценариев проверки устройств. Например, пришлось помучиться с током удержания реле.
Как мы разрабатывали test-suite
Много лет назад, когда партии измерялись десятками устройств, для тестирования привлекали монтажников. Каждое устройство проверяли вручную. Например, нужно было «потыкать» мультиметром в правильных местах и снять показания согласно тестовому сценарию. Конечно, такой способ медленный, и из-за человеческого фактора возможны ошибки. Для нынешних партий в тысячи устройств ручное тестирование уже не подходит.
При первой попытке автоматизации мы взяли фреймворк unittest на Python, который адаптировали под наши нужды, собрали первые стенды и запустили процесс. Стенды были сделаны на нашем оборудовании, которое всегда под рукой, и при необходимости его можно заменить или быстро пересобрать стенд. С течением времени функционал производимых устройств расширялся и для его проверки стали требоваться устройства других производителей: так мы начали использовать логические анализаторы для проверки частоты часовых кварцев контроллера и скважности выходных сигналов некоторых modbus-устройств.
Изначально test-suite был только про тестирование, но хотелось добавить к нему и другие задачи. Так появилась печать наклеек с серийником, чтобы можно было легко идентифицировать каждое устройство. Затем для некоторых устройств (например, счетчиков WB-MAP) появилась калибровка. Позднее мы стали выпускать обновления прошивок и добавили к test-suite возможность прошивки устройств на тестовом стенде (при этом процесс записи загрузчика выполняется предварительно, до тестирования). Теперь мы контролируем версии ПО, с которыми выпускаются устройства, и проводим повторные тесты, если в конкретной версии обнаружились ошибки. Кстати, мы рекомендуем регулярно обновлять прошивку для получения новых функций и исправлений.
Дополнительные фото
Как стал выглядеть процесс тестирования? До этапа тестирования необходимо прошить загрузчик в устройство, поэтому сначала доверенные сотрудники выполняют эту операцию при помощи суперзащищенных «серых коробок» (ниже мы их покажем). Затем специалисты, проводящие тестирование, получают в свое распоряжение терминал (простенький ноутбук), на котором через SSH открыт доступ к нужному стенду. Каждый тестовый стенд оснащен контроллером Wiren Board, на котором работает пакет test-suite, все стенды независимы друг от друга и могут работать одновременно.
В итоге test-suite из инструмента тестирования устройств превратился в комплексный продукт, который научился прошивать, проверять нужные функции, собирать статистику проверки и калибровки.
Но при этом появились проблемы, которые заставили нас разработать test-suite-ng.
Суперсекретная серая коробка N7 для прошивки загрузчика
Вторая версия test-suite: лучше и гибче
С какими проблемами пришлось столкнуться?
Test-suite писал один человек, который был одновременно и инженером-электронщиком, и программистом, что и позволило ему охватить весь комплекс задач. Но сложность проекта росла, разобраться во всех нюансах кода мог только его создатель. Неудивительно, что к нему возникла очередь желающих внести изменения в test-suite. Хотели набрать еще людей, но оказалось, что таких инженеропрограммистов на рынке труда просто нет. Суть в том, что отличные специалисты обычно ограничены одной областью: инженер-электронщик не программирует, а программисту тяжело быть инженером-электронщиком. Если мы хотим сделать что-то кросс-дисциплинарное за короткий срок, то надо либо задействовать обоих, как мы сделали в итоге спустя много лет, либо искать кого-то универсального, как было изначально. С универсальными получается быстрее — нет затрат на коммуникацию, но хуже — тяжело поддерживать.
Архитектуру первого test-suite придумали «на коленке» буквально за полчаса, затем добавляли слой за слоем. Конструкция со временем перестала быть гибкой. Например, она не могла использоваться для параллельного выполнения тестов.
Как мы решили эти проблемы? Перешли на модные современные технологии программирования: поменяли фреймворк и начали использовать pytest с testinfra. Разделили задачи: теперь сценарии тестирования пишут инженеры-тестировщики, для них был создан удобный интерфейс. А программисты отвечают за работу непосредственно самого фреймворка. Если нужно что-то изменить в работе фреймворка — это делают программисты. А поправить тестовые сценарии инженеры могут самостоятельно.
Стенд тестирования контроллера Wiren Board
Дополнительные фото
Стенд тестирования контроллера Wiren Board
Стенд тестирования контроллера Wiren Board
Стенд тестирования памяти контроллеров Wiren Board
Нам удалось сделать выполнение некоторых тестов параллельным. Здесь речь идет о тестировании нашего самого сложного продукта — контроллера Wiren Board. Там довольно много разных функциональных блоков, которые не связаны друг с другом, а значит, их можно проверять параллельно. Всего там несколько десятков тестов — test-suite-ng умеет выполнять их синхронно. В итоге время тестирования контроллеров удалось сократить в два раза, что увеличило общую производительность конвейера.
Добавили интеграцию с мессенджером Telegram. Теперь вся информация доступна в соответствующих каналах.
Изменили базу данных. Теперь в нее сохраняются все измеряемые параметры и логи тестирования. Также добавили сведения о том, к какой партии принадлежат компоненты контроллера. В итоге мы получили инструмент анализа качества каждой партии компонентов. Если по аналитике видим, что какой-то параметр вызывает сомнения, значит, надо задать вопросы поставщику.
Мы используем базу данных test-suite не только для отложенной аналитики, но и для отслеживания работы конвейера. На каждом конвейере стоит монитор с Grafana, на нем бригадиры в реальном времени видят рабочий процесс. Если процент брака на выходе превышает заданное значение, бригадир останавливает конвейер и привлекает инженеров для выяснения причин. Такой подход позволяет мгновенно выявлять бракованные или поддельные компоненты и не допускать отгрузку таких устройств пользователям.
Дашборд Grafana на одном из конвейеров производства
Структура test-suite-ng
С точки зрения программной структуры в основе test-suite-ng лежит фреймворк pytest. Тестирование запускаем из консоли с указанием множества параметров. На основании их значений настраивается инфраструктура для запуска самого pytest, который, в свою очередь, управляет непосредственным проведением тестов. В зависимости от типа тестируемого устройства определяется, будут ли тесты запущены последовательно или параллельно на нескольких потоках.
Для каждого тестируемого устройства (стенда) мы определяем список тестов, который проверяет нужный набор функций. Здесь могут быть сочетания входов и выходов, значения измеряемых параметров и т.д. Так выглядит проверка входов некоторых реле:
В составе pytest есть так называемые фикстуры, которые используем для предварительной настройки устройства. Внутри фикстуры можно выполнять некоторые действия: прописывать серийный номер, вносить базовые настройки шины Modbus и т.д.
Кроме того фикстуры используются и для конфигурации стендов, их можно назвать своего рода «ручками» тестирования. Пример: к контроллеру подключены wbio-модули: WBIO-DO-R1G-16 и WBIO-DI-WD-14 — их мы и определяем в коде с помощью фикстур и впоследствии используем в тестах для взаимодействия с проверяемым устройством.
Следующий более крупный компонент pytest — плагины. Они позволяют выполнить более сложные задачи помимо тестирования. Кроме того плагины сделали test-suite-ng модульным и намного более гибким. Мы можем конфигурировать test-suite-ng под разные сценарии, выбирая набор плагинов. Например, все плагины активны по умолчанию на производстве при проверке устройств, но у разработчиков (в том числе удаленных) активна лишь необходимая часть, что особенно полезно при проведении длительных стресс-тестов.
Так, например, происходит инициализация плагинов для тестирования контроллера:
Мы разработали несколько плагинов, расскажем о самых интересных.
Плагин печати наклеек — плагин создает наклейку с информацией об устройстве и QR-кодом, содержащем информацию о партии, версии устройства, серийном номере. После печати приклеиваем наклейку на корпус. Если тест не пройден, то плагин печатает черный квадрат и название сбойного теста. Затем устройство возвращают с производства дежурному инженеру по ремонту для исследования. Так выглядит функция формирования наклейки для контроллера:
Плагин сводки результатов собирает информацию о проверках в ходе проведения тестов, которая позднее будет записана в базу данных. Так выглядит функция сохранения информации об успешной проверке. Из аргументов хука pytest берем информацию об именах и значениях сравниваемых переменных
Плагин записи в базу данных подготавливает общую информацию по итогам тестов и сохраняет ее в базу данных (серийный номер, версия устройства, номер партии, общее время и результат тестирования и т.д.). На фрагменте кода производится сбор информации о тестах из кеша запуска pytest, а также из директорий логов и результатов проверок:
Плагин баннера — если тестирование завершилось неудачно, он выводит в консоль баннер с информацией о том, что сломалось, и ссылку на запись в базе данных
Плагин логирования собирает логи от одного или нескольких потоков и формирует из них файлы логирования по уровням: warning, info, debug. На фрагменте приведена инициализация файлов логирования для одного потока:
Плагин управления порядком тестов помогает, если нужно исследовать зависимость успешного прохождения тестов от их порядка. Обычно тесты выполняются по порядку, но с теми же датчиками MSW бывает полезно изменить порядок прохождения, чтобы предыдущий тест не влиял на следующий. На приведенном фрагменте из файла, указанного при запуске, прочитывается и применяется запуск тестов:
Плагин алертов в telegram — в telegram-чаты производства отправляет информацию об устройствах, не прошедших тестирование. В сообщении содержится основная информация, логи неудачной проверки и ссылка на запись в базе данных
Самый базовый сценарий использования можно запустить вот так:
Достаточно указать имя сотрудника и модель устройства (а для modbus-устройств еще и адрес и название партии), и test-suite-ng автоматически определит нужный набор тестов, настроит всю инфраструктуру и проведет тестирование. Для демонстрационных целей используется флаг пропуска печати наклейки, по умолчанию он включен. Так как test-suite-ng ориентирован на серийное производство, есть возможность перезапуска тестов по нажатию Enter или специальной кнопки на стенде.
Наши «золотые руки»
Программисты дорабатывают test-suite-ng, инженеры-тестировщики создают и редактируют сценарии, а непосредственно с тестовыми стендами работают наши «золотые руки» — монтажники. Мы учим монтажников работать с тестовыми стендами, но вот для тестов контроллера требуется дополнительный курс, там все сложнее.
Тесты проходят полуавтоматически: монтажник вставляет устройство в стенд, нажимает кнопку, смотрит результат, убирает устройство. Параллельно с этим обычно получается выполнить другие задачи: собрать устройство в корпус, проверить пайку, наклеить этикетки.
Монтажник наклеивает маркировку на модули реле после тестирования
Крафтовые стенды
Мы собираем стенды тестирования самостоятельно. Как говорили выше, предпочитаем использовать собственный контроллер автоматизации. Ведь тестовый стенд — тоже установка автоматизации, не так ли? Поэтому все оборудование у нас всегда под рукой, можно пересобрать стенд например. Опыт работы со своими «железками» у нас гигантский. Хотя к некоторым тестам добавили и «чужое» оборудование (там, где не обойтись).
Большинство тестовых стендов у нас мобильные, за исключением самых громоздких. То есть мы разворачиваем такой стенд при старте производства соответствующего устройства, а потом сворачиваем и храним включенными на стеллажах, чтобы работал удаленный доступ.
Есть еще особенность: мы оставляем стенды включенными после рабочего дня, чтобы с ними могли работать удаленщики. Здесь два момента: удаленные разработчики test-suite-ng могут тестировать написанный код, не надо постоянно дергать кого-то в офисе. Кроме того мы можем обновлять стенды при необходимости.
Стеллаж со стендами
Для каждого стенда на стеллаже выделена своя полочка
Стенд тестирования WB-MIR
Дополнительные фото
Стенд тестирования WB-MIR
Суперсекретная серая коробка 4 для прошивки загрузчика
Заключение
Ранее мы уже рассказывали о входном тестировании Wiren Board в статьях »1-Wire датчик QT18B20 — долгожданный аналог DS18B20 или очередная подделка? Исследуем в лаборатории» и «Тестируем новые ионисторы: взорвутся или нет?». Уделили мы внимание и производству, на которое как раз прикупили паяльный робот: «Китайский паяльный робот: тыкаем палкой и заставляем работать». Сейчас решили погрузиться в тему тестирования наших устройств.
Надеемся, рассказ про test-suite и тестовые стенды оказался интересным. К сожалению, мы не можем раскрыть всех подробностей по понятным причинам. Но постарались быть максимально откровенными там, где можно. Кроме того мы планируем продолжать цикл статей про «нашу кухню» и будем понемногу делиться секретами.
Что вам еще интересно узнать про наше производство? Пишите в комментариях.
Если вы разработчик и хотите делать устройства, которыми пользуются десятки компаний и сотни тысяч людей, приходите к нам работать. Мы ищем Linux-программистов, Embedded-программистов, инженеров по внедрению, инженеров техподдержки и продактов. Присылайте резюме на info@wirenboard.com с пометкой в теме «Я с хабра, хочу работать».
Приходите 25 и 26 апреля к нам ежегодную выставку и конференцию WBCE. Там можно пообщаться с разработчиками оборудования Wiren Board, посетить производство с экскурсией, пощупать устройства и посмотреть готовые решения партнеров из самых разных отраслей.
