¿Cuál es la diferencia entre prueba y verificación?

Todos los libros de texto que he visto dan mucha importancia al hecho de que la prueba y la verificación son dos conceptos diferentes. Sin embargo, ninguno de ellos proporciona una distinción clara (o lo suficientemente clara para mí, por fin).

Para proporcionar algo de contexto, estoy interesado en la verificación de diseños de hardware digital mediante lenguajes de diseño de hardware (HDL).

He visto algunas explicaciones que recurren a una diferencia "física" o "tangible": si se trata de un dispositivo fabricado, entonces es una prueba. ¿Es esta toda la historia? Si es así, ¿por qué la palabra "prueba" aparece con tanta frecuencia en la verificación (especialmente en la verificación funcional, hablamos de casos de prueba, bancos de prueba, DUT (dispositivo bajo prueba), pruebas dirigidas, pruebas aleatorias, etc.)

Respuestas (8)

Fue ingeniero de verificación de diseño ASIC en Qualcomm. De la forma más sencilla te lo puedo explicar:

Pruebas: asegurarse de que un producto funcione, después de haberlo creado (piense en el control de calidad).

Verificación: asegurarse de que un producto funcione ANTES de crearlo.

Ambos están probando, solo que la verificación es más complicada porque debe encontrar una manera de probar el producto antes de que exista y debe poder asegurarse de que funciona según lo diseñado y según las especificaciones cuando realmente sale.

Por ejemplo, Intel está diseñando su próximo procesador, tienen las especificaciones, los esquemas y las simulaciones. Gastan $ 1 mil millones de dólares para pasar por la fabricación y la fabricación. Luego regresa el chip y lo prueban y descubren que no funciona. Simplemente tiraron mucho dinero por la ventana.

Agregue la verificación. Los ingenieros de verificación crean modelos que simulan el comportamiento del chip, crean el banco de pruebas que probará esos modelos particulares. Obtienen los resultados de estos modelos y luego los comparan con los resultados RTL (modelo del circuito escrito en un lenguaje de diseño de hardware). Si coinciden, las cosas (generalmente) están bien.

Hay varias metodologías diferentes para el proceso de verificación, una popular es la Metodología de Verificación Universal (UVM) .

Hay mucha profundidad en el campo y las personas pueden pasar toda su carrera en él.

Otro dato aleatorio de información: por lo general, necesita 3 ingenieros de verificación para 1 ingeniero de diseño. Eso es lo que todos en el campo dicen de todos modos.

EDITAR: Mucha gente piensa en la verificación como una función de prueba, pero no lo es; es una función de diseño en sí misma porque debe comprender todas las complejidades de su IC como lo hace un diseñador, y luego debe saber cómo diseñar modelos, bancos de prueba y todos los casos de prueba que cubrirán toda la funcionalidad de características de su IC , además de tratar de acceder a cada línea de código RTL para todas las combinaciones de bits posibles. Recuerde que un procesador hoy en día tiene miles de millones de transistores debido al proceso de fabricación que permite cada vez más pequeños (ahora 14 nm).

Además, en grandes corporaciones como Intel, AMD, Qualcomm, etc., los diseñadores en realidad no diseñan el chip. Por lo general, el arquitecto definirá todas las especificaciones, diseñará los tipos de piezas que deben combinarse para obtener una función particular con un requisito específico (es decir, velocidad, resolución, etc.), y luego el diseñador codificará eso en RTL. De ninguna manera es un trabajo fácil, simplemente no es tanto diseñar como muchos ingenieros que salen de la escuela piensan que es. Todo el mundo quiere ser arquitecto, pero se necesita mucha educación y experiencia para llegar a ese punto. Muchos arquitectos tienen doctorados y tienen entre 15 y 20 años de experiencia en el campo como diseñadores. Estas son personas brillantes (ya veces locas) que merecen estar haciendo lo que están haciendo, y son buenos en eso. El arquitecto en el primer chip en el que trabajé era un poco torpe y realmente no seguía algunas normas sociales, pero podía resolver cualquier problema relacionado con el chip y, a veces, lo resolvía en su cabeza y te lo decía. mirar una señal y dirías, "¿cómo diablos hizo eso?". Luego le pides que te explique y lo hace y te pasa por alto. En realidad me inspiró a leer libros de texto a pesar de que ya me gradué.

+1 Gracias por el último comentario, nos ayuda a ver que el campo es realmente importante (aunque creo que RTL y la ingeniería de diseño suenan más atractivos para la mayoría de los ingenieros)
Para completar, ¿le importaría agregar qué es un caso de prueba?
Agregué un dato sobre qué es realmente la verificación debido a su primer comentario acerca de que el rol de diseño es más atractivo; Ambos son buenos papeles, solo depende de lo que te guste. En cuanto a un caso de prueba, un SoC como Snapdragon podría tener decenas a cientos de miles de casos de prueba, y con pruebas aleatorias, en millones. En pocas palabras: está aplicando un conjunto de bits de entrada y eso cambia al pasar por muchos módulos, luego obtiene algunos bits de salida como resultado que compara con los resultados de su modelo. Algo tan simple como probar una imagen que aparece en su teléfono tendría...
un gran número de casos de prueba. Digamos que quieres mostrar un solo píxel en la pantalla de tu móvil. Lo que pensará alguien fuera del campo es aplicar 1 bit para el blanco y 0 para el negro. En el mundo móvil real, ese píxel puede diferir en tamaño, intensidad, rotación, formato de color (YUV###,RGB###, etc.). Y probablemente esté probando 1 bit dentro de un conjunto de bits que se aplica a la entrada juntos. Los otros bits pueden ser 0 porque es negro, o pueden ser 1 porque está manejando otra información como cómo manejar el modo de transmisión, CLK, habilita/deshabilita, activadores, cosas sofisticadas como esa.

En mi libro Verification es asegurarse de que lo que ha diseñado "hace el trabajo", es decir, tiene un conjunto de cosas que el "dispositivo" necesita realizar, y la verificación las marca en la lista.

Sin embargo, probar es asegurarse de que las cosas que hace el "dispositivo" se hagan correctamente. Tiene un conjunto de funciones, y prueba cada función para asegurarse de que la función funcione correctamente.

En pocas palabras, Verificación es verificar el diseño y Pruebas es verificar el producto.

Creo que estoy empezando a entender... ¿Podría dar algunos ejemplos de cada uno?
¿Cómo encaja eso con un plan de verificación , que especifica qué debe implementarse y también cómo saber que la funcionalidad es correcta? De poco serviría implementar o tachar una función si no funciona.
@ Majenko - ¿Así que ha escrito un libro sobre Verificación? ¿Compartirías algunos detalles más al respecto?

Viniendo de un fondo de diseño ASIC (hardware), hay tres términos importantes: validación , verificación y prueba . Las respuestas anteriores generalmente hablan de uno o dos de estos términos, pero no contrastan claramente los tres como lo haría yo. Así es como yo los entiendo:

  • Validación: ¿la especificación (a menudo un modelo C) cumple con los requisitos del mercado o del cliente?
  • Verificación: ¿la implementación (RTL, netlist o GDS2) coincide con la especificación?
  • Prueba: ¿el dispositivo fabricado coincide con la implementación?
¿Pueden las simulaciones netlist y GDS2 dar resultados diferentes?
@CiroSantilli巴拿馬文件六四事件法轮功, supongo que estás preguntando sobre el comportamiento de las puertas frente a los transistores. Para voltajes y formas de onda digitales normales, diría que darán los mismos resultados. Pero podría haber efectos "analógicos" no considerados por las puertas idealizadas, como variaciones de potencia/tierra o compartir la carga de la señal. Si esos efectos están presentes, entonces el comportamiento digital ideal puede no ser cierto.
@CiroSantilli新疆改造中心法轮功六四事件 Sí, pueden dar resultados significativamente diferentes. Estuve allí, cometí ese error.

ISO9000 habla de verificación y validación. En el contexto de ISO9000, la verificación significa probar un diseño de prototipo para demostrar que cumple con las expectativas funcionales y de rendimiento. La validación significa que probar la primera serie de producción también cumple con las expectativas de diseño. Verificar primero, validar después es mi pequeña forma de recordar el orden de las cosas.

Varios estándares de software invierten el orden de verificar y validar y esto realmente podría causar confusión, así que tenga esto en cuenta.

La conclusión es... ¿Por qué está probando algo? ¿Es un diseño de prototipo? Si es así, los estándares de calidad tienden a llamar a esto verificación. Si está probando una ejecución de producción por primera vez, los técnicos de hardware llaman a esto validación.

Solo mis experiencias personales.

Una prueba está diseñada para ver si se cumple una especificación. La verificación es para ver si el dispositivo cumple con las entradas de diseño, es decir, todas las especificaciones. Supongo que hay muchas más interpretaciones, pero esto es lo que he visto en los documentos de orientación de la FIA.

Ya veo, he cambiado un poco la redacción (de test a testing ) para que quede más claro que ambos son procesos. Estoy de acuerdo contigo en que para las pruebas individuales la palabra prueba es apropiada (a veces siento que estoy reafirmando lo obvio con estas preguntas de terminología...) :)

Hacemos una distinción entre pruebas de verificación y pruebas de validación. Supongamos que está diseñando un ventilador que refresca algunos equipos. Se realizan pruebas de verificación para asegurarse de que el ventilador cumpla con todos los requisitos de diseño. Por lo tanto, puede probar el flujo de aire, el ciclo térmico, la vibración, etc.

Las pruebas de validación aseguran que los requisitos de diseño sean los correctos. ¿Las entradas de diseño que teníamos para el ventilador realmente nos dieron el ventilador que queríamos? Por ejemplo, se aseguraría de que el ventilador realmente enfríe el equipo según lo previsto.

Así es como se entienden los términos en los libros de Ingeniería de Software que he leído. Validación = asegurarse de que los requisitos sean correctos (verifíquelos con el cliente, regulaciones, etc.); Verificación = asegúrese de que el producto sea correcto (pruébelo con las especificaciones)

Al leer estas respuestas, ahora me doy cuenta de que no existe una definición establecida de cómo las "pruebas" difieren de la "verificación" en la industria.

Cuando trabajamos con diseño HW (diseño HW "real", como cosas en PCB, no programación VHDL), pasamos por una fase de verificación y validación, y una fase de prueba de producción (en realidad, solo diseñamos las pruebas de producción y las entregamos al sitio de producción). - Verificación: (1) verificar que el prototipo/artículo producido en masa cumpla con los requisitos de HW (2) validar los requisitos de HW contra los requisitos de SYS. - Pruebas de producción: prueba de humo y casos de prueba de verificación simplificados y rápidos adaptados para descartar defectos de producción en masa sin tener que pasar por todo el proceso de verificación para cada una de las 500000 unidades producidas al año.

Entonces, en esa empresa multinacional en particular, "pruebas" se refiere a pruebas de producción y nada más.

Siguiendo la definición del libro, "La verificación es el proceso de garantizar la corrección funcional del diseño de acuerdo con el documento de especificación", mientras que "la prueba es el proceso de verificar si el chip físico funciona según lo previsto después de la fabricación". La verificación se trata de verificar si el diseño es lógicamente correcto, mientras que la prueba se trata de si el hardware funciona.