Яка різниця між тестуванням та верифікацією?

Кожен підручник, який я бачив, значною мірою свідчить про те, що тестування та перевірка є двома різними поняттями. Але жоден з них не дає чіткого (або для мене, нарешті, досить чіткого) розрізнення.

Щоб надати певний контекст, мені цікаво перевірити цифрові конструкції обладнання за допомогою мов дизайну апаратних засобів (HDL).

Я бачив деякі пояснення, які вдаються до "фізичної" чи "відчутної" різниці: якщо мова йде про виготовлений пристрій, то це тестування. Це ціла історія? Якщо так, чому слово "тест" виникає так часто під час перевірки (особливо у функціональній верифікації, ми говоримо про тестові вітрини, тестові стенди, DUT (пристрій, що перевіряється), спрямовані тести, випадкові тести тощо ...)

Був інженером з перевірки дизайну ASIC в Qualcomm. Найпростішим способом я можу це пояснити:

Тестування: Переконайтеся, що продукт працює після створення продукту (подумайте, питання якості).

Перевірка: Переконайтесь, що продукт працює перед тим, як ви його створили.

Вони обидва тестують, просто ця перевірка є складнішою, тому що ви повинні знайти спосіб тестування продукту до його існування, і ви зможете переконатися, що він працює як розроблений, так і проаналізувати, коли він дійсно з’явиться.

Наприклад, Intel проектує наступний процесор, у них є характеристики, у них є схеми та імітації. Вони витрачають 1 мільярд доларів на виробництво та виготовлення. Потім чіп повертається і вони тестують його і з’ясовують, що він не працює. Вони просто викинули багато грошей у вікно.

Увімкніть перевірку. Інженери з верифікації створюють моделі, що імітують поведінку чіпа, вони створюють тестовий стенд, який перевірятиме ці конкретні моделі. Вони отримують результати цих моделей, а потім порівнюють їх з результатами RTL (модель написання схеми мовою апаратного проектування). Якщо вони співпадають, речі (як правило) добре.

Існує ряд різних методологій для процесу верифікації, популярною є Універсальна методологія верифікації (UVM) .

У цій галузі багато глибини, і люди можуть провести в ній всю свою кар’єру.

Ще одна випадкова інформація: Зазвичай вам потрібні 3 інженери-перевірки для 1-го інженера-дизайнера. Це так чи інакше говорять усі на місцях.

EDIT: Багато людей вважають верифікацію тестовою роллю, але це не так; це сама дизайнерська роль, тому що ви повинні зрозуміти всі тонкощі вашого ІС, як це робить дизайнер, і тоді ви повинні знати, як проектувати моделі, тестові стенди та всі тестові справи, які охоплюватимуть всі функціональні можливості вашого ІС , а також намагатися вразити кожен рядок коду 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 одиниць, вироблених на рік.

Тож у цій конкретній багатонаціональній компанії «тестування» йдеться про виробничі випробування і нічого більше.