Home

Автор: Алексей Старцев

Оригинальная публикация: https://habrahabr.ru/company/yadro/blog/336822/

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

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

Сразу пример из личного опыта: на некоторой фабрике для одной из компаний, где я работал, выпустили полсотни серверных материнских плат с одинаковыми прошитыми MAC-адресами сетевых интерфейсов, что привело к интересным эффектам при их работе в одной сети. А так как такой подставы от них никто не ожидал — причина, по которой собранный из этих плат кластер отказывается работать, была обнаружена не сразу, и исследование причин неисправности заняло значительное время.

Конечно, можно предъявить претензию и отправить обратно на фабрику все «плохие» платы, но во-первых это долго, а во-вторых дорого, и не гарантирует того, что новые присланные платы не будут иметь какого-то другого недостатка. Всех этих проблем можно было бы избежать, если бы уникальность MAC-адресов в том случае кто-то проверил до того, как эти платы попали к заказчику.

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

Прекратите это безобразие!

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

Наше решение для обеспечения контроля качества серийной продукции — «чёрный ящик». Устройство, которое максимально неинтерактивно в процессе теста, занимает мало места и требует минимум манипуляций со стороны персонала на производстве. Грубо говоря, коробочку подключают к тестируемой плате, затем через какое-то время загорается зелёная или красная лампочка. Зелёная — всё ок, плату можно упаковывать и отправлять, она исправна. Красная — не ок, с платой есть проблемы, их нужно устранить и затем протестировать ещё раз, и так далее до победного.

Конечно же, мы достаточно оцениваем изобретательность наших китайских коллег, поэтому предусмотрели несколько ступеней защиты от подтасовки результатов, получить 146% процентов успешных тестов не выйдет. Для этого каждая процедура тестирования логируется, логи хранятся в «чёрном ящике» в зашифрованном виде и присылаются к нам. Например, если плата не проходила тестирование с помощью «чёрного ящика» на фабрике, то мы об этом узнаем, посмотрев логи и записи в базе данных. Нет записи — плата не тестировалась, значит не должна была быть отправлена к нам. От ручной «генерации» логов и результатов тестов также есть защита. Описывать её мы, конечно же, не будем.

Что в чёрном ящике?

Сам «чёрный ящик» — это компактный компьютер типа Intel NUC или Gigabyte BRIX, подключаемый к сети через Wi-Fi или Ethernet, а также через USB-переходники к тестируемой плате. К компьютеру может быть подключен монитор, на котором отображается ход тестирования, и в случае ошибок — сами ошибки. Вообще подумываем перейти на использование формата Mini-ITX, чтобы можно было шире варьировать конфигурацию.

На диске компьютера содержится образ на основе Linux с набором тестовых утилит, необходимых для проведения тестирования конкретного типа плат. Для каждого типа готовится свой образ и набор тестовых скриптов. Если говорить конкретно про серверные материнские платы, то помимо образа тестового сервера на компьютере содержится ещё и образ тестового PXE-клиента.

Материнская плата загружает тестовый образ по PXE. Она подключается по Ethernet к «чёрному ящику» и её BMC получает IP адрес по DHCP. Процесс включения питания материнской платы инициируется через BMC, загружается тестовый образ, выполняются тесты. На экране монитора, подключенного к «чёрному ящику», отображаются результаты теста, затем питание платы автоматически отключается через BMC. После этого работник производства может отключать от тестового стенда плату и тестировать следующую. Так происходит до тех пор, пока нужное количество плат не будет протестировано.



Наш «чёрный ящик» подключен по Ethernet не только к тестируемой плате, но и в интернет: периодически «стучится» на наш сервер и присылает логи тестов, сделанных, например, за день. Таким образом мы видим, сколько плат было протестировано, как много брака, и можем примерно спрогнозировать, когда же мы получим долгожданную партию тех или иных плат.

Что и как проверяется?

Немного про сами тесты. Так как время для тестирования ограничено и производство не наше, то на тесты отводится небольшое время — около 5 минут на плату. Если говорить про тестирование материнских плат, то за это время наше тестовое ПО успевает загрузить на плате операционную систему, проверить уникальность MAC-адресов и других уникальных ID, версии прошивок микроконтроллеров и BMC, значения и работу сенсоров, работу всех слотов расширения, процессорных сокетов, видны ли операционной системе все процессоры и модули памяти и т.д.

Также запускается короткий цикл нагрузочных тестов для того чтобы «прогреть» плату и оценить по производительности возможные проблемы её сборки. То есть эти тесты — своеобразный smoke test, чтобы быстро увидеть какие-то явные проблемы. Для простоты поддержки и разработки тестов они в своём большинстве делаются на bash и под Linux.

Результаты тестов для сотрудника фабрики на экране монитора выглядят примерно следующим образом (варьируется от типа тестируемой платы):

PASSED 34 of 36 tests
FAILED: CPU2 temp; BMC version

Это пример для случая тестов с ошибками. Расшифровка ошибок и их описание обычно составляется отдельным файлом, либо распечатывается на бумажке — чтобы сотрудник на фабрике мог понять, что конкретно «не понравилось» тесту.

Сам список тестов и предполагаемые значения результатов тестов содержатся в отдельном конфигурационном файле. В нём прописаны, например, минимальные и максимальные значения температур датчиков какой-либо платы, количество устройств, которые должны быть видны на шине PCI или, например, USB. В ходе теста полученные значения сравниваются с указанными в конфигурационном файле. В зависимости от того, «попадают» ли полученные значения в ходе тестирования в конфигурационный файл или нет, тест считается успешно или неуспешно пройденным.

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

Использование «чёрного ящика» решило для нас сразу несколько задач:

• удалённый контроль за ходом тестирования плат,
• контроль объективности оценки результатов и их аутентичности,
• обеспечение проверки каждой платы, выходящей с производства, до отправки нам,
• и уменьшение частоты взаимодействия с производством в случае каких-либо неполадок или ошибок.

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

QA и QC

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

Специалист QC как правило не знает, да и не обязан знать, как именно работает та или иная плата. Его задача следовать инструкции, и грубо говоря, следить за цветом лампочки на выданном ему стенде тестирования. QC нет разницы что проверять — сложные аппаратные комплексы или яркость свечения светодиодов. Он следует инструкции, и в соответствии с ней получает результат о прохождении или провале проверки качества.

После проверки силами QC всей партии и получения заказчиком, то есть нами, в дело снова вступает QA, о чём красочно написал asmolenskiy в одной из предыдущих наших статей. При этом отдельные образцы полученной партии тестируются снова, как по отдельности, так и в комплексе с другими платами и устройствами. А вот уже по результатам проверок QA может возникнуть новая ревизия одной или нескольких плат, и всё начинается снова.

Обсудить в форуме