¿Qué es la prueba de componentes? Técnicas, casos de prueba de ejemplo

Por: Tomas Hamilton Tomas Hamilton
Hours Actualizado

⚡ Resumen inteligente

Las pruebas de componentes verifican cada parte de una aplicación de forma individual, sin integrarla con el resto, de modo que los defectos se encuentren y se corrijan dentro de un único módulo antes de que comience el ensamblaje.

  • 🧩 Alcance: Un componente a la vez, aislado de los componentes que lo rodean.
  • 👥 Propietario: Los evaluadores lo ejecutan después de que los desarrolladores hayan completado las pruebas unitarias.
  • 🔬 CTIS: Las pruebas de componentes en formato pequeño aíslan completamente el componente.
  • 🔗 CTIL: Las pruebas de componentes en entornos grandes mantienen las dependencias, ya sean reales o simuladas.
  • 🧱 Doubles: Un controlador llama al componente; un stub es llamado por este.
  • ✅ Salir: Ningún defecto crítico, alto o medio permanece abierto en el registro.
Descubre más

Técnicas de prueba de componentes y ejemplos de casos de prueba

¿Qué es la prueba de componentes?

Prueba de componentes es un tipo de prueba de software en la que las pruebas se realizan en cada componente individual por separado, sin integrarlo con otros componentes. Desde una perspectiva de arquitectura, también se denomina prueba de módulosy algunas referencias lo llaman prueba de programas.

Cualquier software en su conjunto está compuesto por varios componentes, y las pruebas a nivel de componentes se ocupan de probar esos componentes individualmente. Es una de las más frecuentes. prueba de caja negra tipos realizados por el equipo de control de calidad.

Una nota sobre la nomenclatura es importante hacerla desde el principio. El glosario de ISTQB trata las pruebas de componentes y examen de la unidad Como sinónimos del mismo nivel de prueba, muchos equipos de desarrollo, al igual que este artículo, los mantienen separados en la práctica: los desarrolladores ejecutan pruebas unitarias en su propio código, y los evaluadores ejecutan pruebas de componentes en la versión entregada. La tabla comparativa al final de este artículo ilustra esta distinción práctica.

Como muestra el diagrama a continuación, las pruebas de componentes tienen su propia estrategia y plan de pruebas, en los que cada parte del software o aplicación se considera individualmente. Para cada componente, escenario de prueba se define, que luego se desglosa en casos de prueba de alto nivel y finalmente en detalles de bajo nivel. Casos de prueba con requisitos previos.

Jerarquía de pruebas de componentes desde la estrategia de pruebas hasta los casos de prueba de bajo nivel.

La forma en que se utiliza el término "pruebas de componentes" varía según el ámbito y la organización. Las razones más comunes de esta diferencia de percepción son las tres que se detallan a continuación.

  1. El tipo de modelo de ciclo de vida de desarrollo elegido
  2. La complejidad del software o la aplicación bajo prueba
  3. Ya sea que las pruebas se realicen con o sin aislamiento de los demás componentes de la aplicación.

El ciclo de vida de las pruebas de software genera numerosos artefactos de prueba, es decir, los documentos creados y utilizados durante las actividades de prueba. Entre ellos se encuentran la política de pruebas y la estrategia de pruebas, que definen qué tipos de pruebas se utilizan y con qué profundidad se realizan en un proyecto determinado.

¿Quién realiza las pruebas de componentes?

Las pruebas de componentes las realizan los evaluadores. Las pruebas unitarias las realizan los desarrolladores, quienes prueban una función o procedimiento individual. Una vez finalizadas las pruebas unitarias, se procede a las pruebas de componentes, de las cuales los evaluadores se hacen cargo.

Cuándo realizar pruebas de componentes

Las pruebas de componentes se realizan poco después de que los desarrolladores hayan finalizado las pruebas unitarias y la compilación se haya entregado al equipo de pruebas. Esta compilación se conoce como compilación UT o compilación de pruebas unitarias. En esta fase se prueba la funcionalidad principal de cada componente.

Criterios de entrada para las pruebas de componentes.

  • Se ha desarrollado y probado unitariamente el conjunto mínimo de componentes que deben incluirse en la compilación UT.

Criterios de salida para las pruebas de componentes.

  • La funcionalidad de cada componente funciona según lo especificado.
  • No queda ningún defecto crítico, de gravedad alta o media, ni de prioridad, abierto en el registro de defectos.

Técnicas de prueba de componentes

En función de la profundidad del nivel de prueba, las pruebas de componentes se clasifican de dos maneras.

  1. CTIS: pruebas de componentes en pequeños
  2. CTIL — Pruebas de componentes en grandes

CTIS: pruebas de componentes en pequeños

Las pruebas de componentes pueden realizarse con o sin aislamiento de los demás componentes de la aplicación bajo prueba. Cuando se realizan con los demás componentes aislados, se denominan pruebas de componentes en pequeño.

Ejemplo 1: En un sitio web con cinco páginas web diferentes, probar cada página web por separado y de forma aislada de los demás componentes es como realizar pruebas de componentes a pequeña escala.

Ejemplo 2: La página de inicio de guru99.com que se muestra a continuación contiene muchos componentes, como Inicio, Pruebas, SAP, Web, ¡Hay que aprender!, Big Data, Proyectos en vivo y Blog.

Guru99 menús de navegación de la página de inicio tratados como componentes de prueba independientes

Cualquier software se compone de muchos componentes de la misma manera, y cada componente tiene sus propios subcomponentes. Probar cada módulo enumerado en el Ejemplo 2 por separado, sin considerar su integración con los demás componentes, es una prueba de componentes en miniatura.

Al abrir el menú desplegable Pruebas, se muestran los subcomponentes del componente Pruebas: Prueba manual , SOAPUI, QTP, JUnit, Selenium, Gestión de pruebas y Pruebas móvilesEn la imagen que aparece a continuación, esos subcomponentes están resaltados en rojo.

Prueba del menú desplegable con sus subcomponentes resaltados en rojo.

ARTÍCULOS RELACIONADOS

CTIL — Pruebas de componentes en grandes

Las pruebas de componentes realizadas sin aislarlas de los demás componentes de la aplicación que se está probando se denominan pruebas de componentes en conjunto.

Un ejemplo aclara la diferencia. Supongamos que una aplicación consta de tres componentes: Componente A, Componente B y Componente C.

El desarrollador ha creado el Componente B y desea probarlo. Para probar el Componente B por completo, parte de su funcionalidad depende del Componente A y parte del Componente C, como se ilustra en el siguiente diagrama.

El componente B se probó con un controlador que reemplaza al componente A y un stub que reemplaza al componente C.

El flujo de funcionalidad es A → B → C, lo que significa que el componente B depende tanto de A como de C. En ese flujo, la función llamada es la función auxiliar y la función que realiza la llamada es la función principal.

Los componentes A y C aún no se han desarrollado. Para probar completamente el componente B, A y C se reemplazan por un controlador y un stub según sea necesario, de modo que las dos piezas faltantes actúan como objetos ficticios hasta que existan las reales.

  • Talón: El componente que se está probando llama a una función simulada. El componente C no está listo, por lo que una función simulada lo reemplaza y devuelve las respuestas que B espera.
  • Conductor: Un controlador llama al componente que se está probando. El componente A no está listo, por lo que un controlador lo reemplaza e invoca al componente B con las entradas requeridas.

Casos de prueba de ejemplo para pruebas de componentes

Las dos páginas web que aparecen a continuación están interrelacionadas desde el punto de vista funcional, lo que las convierte en un par de componentes útiles para realizar pruebas.

La página web 1 es la página de inicio de sesión del sitio web de demostración de banca.

Componente de página de inicio de sesión con campos para ID de usuario y contraseña.

Cuando el usuario introduce un nombre de usuario y una contraseña válidos y hace clic en el botón de enviar, la página le redirige a la página de inicio del sitio web de demostración del banco, que se muestra a continuación.

Componente de la página de inicio del administrador con enlaces de navegación e imágenes.

Aquí, la página de inicio de sesión es un componente y la página principal es otro. Probar la funcionalidad de cada página por separado se denomina prueba de componentes.

Escenarios de prueba de componentes en la página web 1:

  • Introduzca un ID de usuario no válido y verifique que se muestre una advertencia fácil de entender al usuario final.
  • Introduzca un nombre de usuario y una contraseña incorrectos, haga clic en Restablecer y verifique que los campos de nombre de usuario y contraseña se hayan borrado.
  • Introduzca un nombre de usuario y una contraseña válidos y haga clic en el botón Iniciar sesión.

Escenarios de prueba de componentes en la página web 2:

  • Verifique que el mensaje de bienvenida de la página del administrador se muestre en la página de inicio.
  • Verifique que todos los enlaces del lado izquierdo de la página web sean clicables.
  • Verifique que el ID del administrador se muestre en el centro de la página principal.
  • Verifique la presencia de las tres imágenes diferentes en la página de inicio, según el diagrama.

Pruebas unitarias versus pruebas de componentes

La tabla que aparece a continuación resume las diferencias entre ambos niveles en la práctica diaria.

Examen de la unidad Prueba de componentes
Realizar pruebas a programas y módulos individuales para demostrar que el programa se ejecuta según las especificaciones. Probar cada objeto o parte del software por separado, con o sin aislamiento de otros objetos.
Validado conforme a los documentos de diseño. Validado conforme a los requisitos de prueba y los casos de uso.
Realizado por desarrolladores. Realizado por los evaluadores.
Hecho primero. Se realiza una vez finalizadas las pruebas unitarias por parte de los desarrolladores.
Los defectos suelen corregirse en el acto y no se registran formalmente. Los defectos se registran y tracsometido al proceso de gestión de defectos.

Preguntas Frecuentes

Reducir el riesgo, verificar el comportamiento funcional y no funcional del componente, generar confianza en su calidad, encontrar defectos y evitar que esos defectos se propaguen.ping a niveles de prueba más altos.

Los modelos leen un componente contracy propone las entradas no válidas, los valores límite y las rutas de error que una pasada manual tiende a pasar por alto. Un probador aún confirma cada resultado esperado antes de la ejecución.

Sí. Un programa auxiliar que devuelve respuestas predefinidas y un controlador que introduce datos fijos son códigos formulados que un asistente escribe rápidamente. Decidir qué respuestas son realistas sigue siendo una decisión humana.

Las pruebas de componentes examinan un componente por sí solo. Componente pruebas de integración Examina las interfaces e interacciones entre los componentes y se ejecuta después de las pruebas de los componentes.

Codemarcos de nivel como JUnit, TestNG, NUnit y pytest, además de ejecutores de componentes de interfaz de usuario como Cypress Pruebas de componentes, Storybook y Jest. Todos ellos encajan en un mismo sistema. la automatización tubería.

Creación y mantenimiento de réplicas. Un stub que se aleja del componente real oculta defectos hasta la integración, por lo que cada respuesta simulada debe revisarse una vez que se implementa la dependencia real.

Invierte el orden. Los casos se escriben y automatizan antes de que exista el componente, y luego se agrega código hasta que se superan las pruebas. El componente llega con su conjunto de pruebas ya implementado.

Ambos, dependiendo de quién lo ejecute. Los probadores trabajan con caja negra contra la especificación del componente, mientras que los desarrolladores con acceso al código aplican caja blanca cobertura dentro del mismo componente.

Resumir este post con: