В чем разница между тестированием и проверкой?

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

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

Я видел некоторые объяснения, которые прибегают к «физическому» или «ощутимому» различию: если речь идет о произведенном устройстве, то оно тестируется. Это вся история? Если да, то почему слово «тест» так часто встречается при верификации (особенно при функциональной верификации, мы говорим о тестовых наборах, тестовых стендах, DUT (тестируемом устройстве), направленных тестах, случайных тестах и ​​т. Д ...)

Был инженером по проверке дизайна ASIC в Qualcomm. Самым простым способом я могу объяснить это:

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

Проверка: Убедитесь, что продукт работает, прежде чем вы создали его.

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

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

Добавьте проверку. Инженеры-верификаторы создают модели, имитирующие поведение чипа, они создают испытательный стенд, который будет тестировать эти конкретные модели. Они получают результаты этих моделей, а затем сравнивают их с результатами RTL (модели записи схем на языке проектирования аппаратуры). Если они совпадают, все (обычно) в порядке.

Существует ряд различных методологий для процесса проверки, популярной из которых является Универсальная методология проверки (UVM) .

В этой области много глубины, и люди могут потратить на нее всю свою карьеру.

Еще одна случайная информация: обычно вам требуется 3 инженера-верификатора на 1 инженера-конструктора. Это то, что все в области говорят в любом случае.

РЕДАКТИРОВАТЬ: Многие люди думают о проверке как о роли тестирования, но это не так; это сама по себе роль проектирования, потому что вы должны понимать все тонкости вашей IC, как это делает дизайнер, а затем вы должны знать, как проектировать модели, испытательные стенды и все тестовые случаи, которые будут охватывать все функциональные возможности вашей IC , а также пытаясь поразить каждую строку кода RTL для всех возможных битовых комбинаций. Помните, что в настоящее время процессор имеет миллиарды транзисторов благодаря процессу изготовления, позволяющему все меньше и меньше (теперь 14 нм).

Кроме того, в крупных корпорациях, таких как Intel, AMD, Qualcomm и т. Д., Дизайнеры на самом деле не проектируют чип. Обычно архитектор определяет все спецификации, размечает типы частей, которые должны объединяться, чтобы получить определенную функцию с определенным требованием (например, скорость, разрешение и т. Д.), А затем дизайнер кодирует это в RTL. Это ни в коем случае не простая работа, это просто не столько проектирование, сколько многие инженеры, выходящие из школы, думают, что это так. Каждый хочет быть архитектором, но для этого нужно много образования и опыта. Многие архитекторы имеют докторскую степень и 15-20-летний опыт работы в этой области в качестве дизайнера. Это замечательные люди (а иногда и безумные), которые заслуживают того, чтобы делать то, что делают, и у них это хорошо получается. Архитектор самого первого чипа, над которым я работал, был немного неуклюжим и не следовал некоторым социальным нормам, но он мог решить все, что вы застряли в отношении чипа, и иногда он решал это в своей голове и говорил вам посмотреть на один сигнал, и вы будете как, «как, черт возьми, он это сделал?». Затем вы просите его объяснить, и он делает, и это выходит за рамки вашей головы. На самом деле вдохновил меня на чтение учебников, хотя я уже закончил.

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

Тем не менее, тестирование позволяет убедиться, что все, что делает «устройство», сделано правильно. У вас есть набор функций, и вы тестируете каждую функцию, чтобы убедиться, что она работает правильно.

Короче говоря, Verification проверяет дизайн, а Testing проверяет продукт.

Исходя из основы проектирования ASIC (аппаратного обеспечения), существуют три важных термина: валидация , верификация и тестирование . Предыдущие ответы обычно говорят об одном или двух из этих терминов, но не дают четкого противопоставления всем трем, как я бы. Вот как я их понимаю:

• Проверка: соответствует ли спецификация (часто модель C) требованиям рынка или клиента
• Проверка: соответствует ли реализация (RTL, netlist или GDS2) спецификации
• Тест: соответствует ли изготовленное устройство реализации

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

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

Валидационные испытания подтверждают, что требования к дизайну были правильными. Действительно ли дизайн, который мы получили для вентилятора, дал нам тот вентилятор, который мы хотели? Например, вы должны убедиться, что вентилятор действительно охлаждает оборудование по назначению.

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

Некоторые стандарты программного обеспечения меняют порядок проверки и подтверждения, и это может привести к путанице, поэтому имейте это в виду.

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

Просто мой личный опыт.

Прочитав эти ответы, я теперь понимаю, что не существует определенного определения того, как «тестирование» отличается от «верификации» в отрасли.

При работе с HW-дизайном («реальный» HW-проект, например, на печатной плате, а не VHDL-программированием), мы проходим этап проверки и валидации, а также этап производственного тестирования (фактически, просто сами производим производственные испытания и доставляем их на производственную площадку). - Проверка - (1) проверка того, что прототип / серийно выпускаемый предмет соответствует требованиям HW (2) проверка соответствия HW требованиям SYS. - Производственные испытания - тесты на дым и упрощенные и быстрые контрольные тесты, адаптированные для выявления дефектов массового производства без необходимости проходить весь процесс проверки для каждого из 500000 единиц, производимых в год.

Так что в этой конкретной многонациональной компании «тестирование» относится к производственным испытаниям и ничего более.