Menú

¿Qué son las pruebas de componentes o las pruebas de módulos (aprender con ejemplos)?

what is component testing

Pruebe Nuestro Instrumento Para Eliminar Los Problemas

¿Qué es la prueba de componentes también llamada prueba de módulo en la prueba de software?

Un componente es la unidad más baja de cualquier aplicación. Entonces, prueba de componentes; como sugiere el nombre, es una técnica de prueba de la unidad más baja o más pequeña de cualquier aplicación.

Las pruebas de componentes a veces también se conocen como pruebas de programas o módulos.

Una aplicación se puede pensar en una combinación e integración de muchos pequeños módulos individuales. Antes de probar todo el sistema, es imperativo que cada componente O la unidad más pequeña de la aplicación se pruebe a fondo.

cómo ejecutar un .swf

En este caso, los módulos o las unidades se prueban de forma independiente. Cada módulo recibe una entrada, realiza algún procesamiento y genera la salida. Luego, la salida se valida con la característica esperada.

¿Qué es la prueba de componentes?

Las aplicaciones de software son enormes por naturaleza y es un desafío probar todo el sistema. Puede dar lugar a muchas lagunas en la cobertura de la prueba. Por lo tanto, antes de pasar a las pruebas de integración o las pruebas funcionales, se recomienda comenzar con las pruebas de componentes.

También leer=> Diferencia de pruebas unitarias, de integración y funcionales

Lo que vas a aprender:

Prueba de componentes

Es una especie de prueba de caja blanca.

Por lo tanto, la prueba de componentes busca errores y verifica el funcionamiento de los módulos / programas que se pueden probar por separado.

Existe una estrategia de prueba y un plan de prueba para la prueba de componentes. Y, para cada componente, hay un escenario de prueba que se desglosará más en los casos de prueba. El siguiente diagrama representa lo mismo:

Prueba de componentes

El objetivo de las pruebas de componentes

El objetivo principal de las pruebas de componentes es verificar el comportamiento de entrada / salida del objeto de prueba. Asegura que la funcionalidad del objeto de prueba funcione correctamente y completamente bien según la especificación deseada.

Entradas para pruebas de nivel de componentes

Las cuatro entradas principales para las pruebas a nivel de componentes son:

  • Plan de prueba del proyecto
  • Requisitos del sistema
  • Especificaciones de los componentes
  • Implementaciones de componentes

¿Quién realiza las pruebas de componentes?

Las pruebas de componentes las realizan los servicios de control de calidad o el probador.

¿Qué se prueba en las pruebas de componentes?

La prueba de componentes puede tener en cuenta la verificación de características funcionales o no funcionales específicas de los componentes del sistema.

Puede probar el comportamiento de los recursos (por ejemplo, determinar fugas de memoria), pruebas de rendimiento, pruebas estructurales, etc.

¿Cuándo se realizan las pruebas de componentes?

La prueba de componentes se realiza después de la prueba unitaria.

Los componentes se prueban tan pronto como se crean, por lo que existe la posibilidad de que los resultados recuperados de un componente bajo prueba dependan de otros componentes que, a su vez, no se han desarrollado hasta ahora.

Dependiendo del modelo de ciclo de vida de desarrollo, las pruebas de componentes se pueden realizar de forma aislada con otros componentes del sistema. El aislamiento se realiza para prevenir influencias externas.

Entonces, para probar ese componente, usamos Stubs y Driverspara simular la interfaz entre componentes de software.

La prueba de integración se realiza después de la prueba de los componentes.

Estrategia de prueba de pruebas de componentes

Dependiendo de la profundidad del nivel de prueba, la prueba de componentes se divide en dos partes:

  1. Prueba de componentes en pequeño (ctis)
  2. Prueba de componentes en grande (CTIL)

Cuando la prueba de componentes se realiza de forma aislada con otros componentes, se denomina prueba de componentes en pequeño. Esto se hace sin considerar la integración con otros componentes.

Cuando la prueba de componentes se realiza sin aislamiento con otros componentes del software, se denomina prueba de componentes en general. Esto sucede cuando existe una dependencia del flujo de funcionalidad de los componentes y, por lo tanto, no podemos aislarlos.

Si los componentes de los que dependemos aún no se han desarrollado, entonces usamos objetos ficticios en lugar de los componentes reales. Estos objetos ficticios son el stub (función llamada) y el controlador (función llamada).

Stubs y controladores

Antes de pasar al resumen sobre stubs y controladores, debo informar sobre el diferencia entre las pruebas de componentes y las pruebas de integración. La razón es que los stubs y los controladores también se utilizan en las pruebas de integración, por lo que esto puede generar cierta confusión entre estas dos técnicas de prueba.

La técnica de prueba de integración es una técnica en la que combinamos 2 componentes secuencialmente y probamos el sistema integrado juntos. Los datos de un sistema se transfieren a otro sistema y la exactitud de los datos se valida para el sistema integrado.

A diferencia de las pruebas de módulo, en las que el módulo / componente individual se prueba a fondo antes de integrarlo a otros componentes. Por lo tanto, podemos decir que las pruebas de componentes se realizan antes de las pruebas de integración.

Usos de integración y componentes Stubs y controladores .

'Conductores' son los programas ficticios que se utilizan para llamar a las funciones del módulo más bajo en caso de que la función de llamada no exista.

'Stubs' puede denominarse código, un fragmento que acepta las entradas / solicitudes del módulo superior y devuelve los resultados / respuesta

Como se explicó anteriormente, los componentes se prueban de forma individual e independiente. Por lo tanto, puede haber algunas características de los componentes, dependiendo del otro componente que no está desarrollado actualmente. Entonces, para probar los componentes con estas características 'no desarrolladas', tenemos que usar algunos agentes estimulantes que procesarían los datos y los devolverían a los componentes que llaman.

De esta manera nos aseguramos de que los componentes individuales se prueben a fondo.

los componentes individuales se prueban a fondo

Aquí vemos que:

  • C1, C2, C3, C4, C5, C6, C7, C8, C9 ————— son los componentes
  • C1, C2 y C3 juntos forman la Subunidad 1
  • C4 y C5 juntos forman la unidad secundaria 2
  • C6, C7 y C8 juntos forman la unidad secundaria 3
  • C9 solo hace la subunidad 4
  • La subunidad 1 y la subunidad 2 se combinan para formar la unidad de negocio 1
  • La subunidad 3 y la subunidad 4 se combinan para formar la unidad de negocio 2
  • La Unidad de negocio 1 y la Unidad de negocio 2 se combinan para realizar la aplicación.
  • Entonces, la prueba de componentes, en este caso, sería probar los componentes individuales que son C1 a C9.
  • los Red La flecha entre la subunidad 1 y la subunidad 2 muestra el punto de prueba de integración.
  • Del mismo modo, el Red La flecha entre la subunidad 3 y la subunidad 4 muestra el punto de prueba de integración
  • La flecha verde entre la Unidad de negocio 1 y la Unidad de negocio 2 muestra el punto de prueba de integración

Por lo tanto estaríamos haciendo:

  • COMPONENTE prueba de C1 a C9
  • INTEGRACIÓN pruebas entre las subunidades y las unidades de negocio
  • SISTEMA pruebas de la Aplicación en su conjunto

Un ejemplo

Hasta ahora, debemos haber establecido que la prueba de componentes es una especie de técnica de prueba de caja blanca . Bueno, puede que sea correcto. Pero esto no significa que esta técnica no pueda usarse en la técnica de prueba de caja negra.

mejor limpiador de disco gratis windows 10

Considere una gran aplicación web que comienza con una página de inicio de sesión. Como tester (eso también en un mundo ágil) no podíamos esperar hasta que se desarrollara toda la aplicación y estuviera lista para probar. Para aumentar nuestro tiempo de comercialización, debemos comenzar a realizar pruebas con anticipación. Entonces, cuando veamos que la página de inicio de sesión está desarrollada, debemos insistir en que esté disponible para que podamos probarla.

Tan pronto como tenga la página de inicio de sesión disponible para que la pruebe, puede ejecutar todos sus casos de prueba (positivos y negativos) para asegurarse de que la funcionalidad de la página de inicio de sesión funcione como se esperaba.

Las ventajas de probar su página de inicio de sesión en este momento serían:

java web services entrevista preguntas y respuestas para experimentados
  • Se prueba la usabilidad de la interfaz de usuario (errores ortográficos, logotipos, alineación, formato, etc.)
  • Tratar de usar técnicas de prueba negativas como de autenticación y autorización. Existe una gran probabilidad de encontrar defectos en estos casos.
  • Uso de técnicas como inyecciones SQL garantizaría probar la violación de la seguridad en una etapa muy temprana.

Los defectos que registraría en esta etapa actuarían como 'lecciones aprendidas' para el equipo de desarrollo y se implementarían en la codificación de la página consecutiva. Por lo tanto, al probar con anticipación, se ha asegurado una mejor calidad de las páginas que aún no se han desarrollado.

Debido a que las otras páginas consecutivas aún no están desarrolladas, es posible que necesite códigos auxiliares para validar la funcionalidad de la página de inicio de sesión. Por ejemplo ,es posible que desee una página simple que indique 'registro exitoso', en caso de que las credenciales sean correctas y una ventana emergente de mensaje de error en caso de que las credenciales sean incorrectas.

Puede seguir nuestro tutorial anterior en Pruebas de integración para tener más información sobre stubs y controladores.

¿Cómo escribir casos de prueba de componentes?

Los casos de prueba para las pruebas de componentes se derivan de productos de trabajo, por ejemplo, el diseño de software o el modelo de datos. Cada componente se prueba a través de una secuencia de casos de prueba donde cada caso de prueba cubre una combinación específica de entrada / salida, es decir, funcionalidad parcial.

A continuación se muestra un fragmento de muestra de un caso de prueba de componente para el módulo de inicio de sesión.

Podemos escribir otros casos de prueba de manera similar.

Casos de prueba

Pruebas de componentes frente a pruebas unitarias

La primera diferencia entre la prueba de componentes y la prueba unitaria es que la primera es realizada por probadores, mientras que la segunda la realizan desarrolladores o profesionales de SDET.

Las pruebas unitarias se realizan a nivel granular. Por otro lado, las pruebas de componentes se realizan a nivel de aplicación. En las pruebas unitarias, se verifica si un programa individual o el fragmento de código se está ejecutando según lo especificado. En la prueba de componentes, cada objeto del software se prueba por separado con o sin aislamiento con otros componentes / objetos del sistema.

Por lo tanto, la prueba de componentes es bastante similar a la prueba unitaria, pero se realiza en un nivel superior de integración y en el contexto de la aplicación (no solo en el contexto de esa unidad / programa como en la prueba unitaria).

Componente Vs Interfaz Vs Integración Vs Pruebas de sistemas

Componente , como expliqué, es la unidad más baja de una aplicación que se prueba de forma independiente.

Un interfaz es la capa de unión de los 2 componentes. La prueba de la plataforma o la interfaz en la que interactúan los 2 componentes se denomina prueba de interfaz.

Ahora, probar la interfaz es un poco diferente. Estas interfaces son principalmente API o servicios web , por lo que la prueba de estas interfaces no sería similar a la técnica de Black Box, sino que estaría realizando algún tipo de prueba de API o prueba de servicio web utilizando IU de SOAP o cualquier otra herramienta.

Una vez que se realiza la prueba de interfaz, viene el Pruebas de integración .

Durante la prueba de integración, combinamos los componentes individuales probados uno por uno y los probamos de forma incremental. Validamos durante la integración que los componentes individuales cuando se combinan uno por uno, se comportan como se esperaba y los datos no se alteran cuando fluyen de 1 módulo a otro módulo.

Una vez que todos los componentes estén integrados y probados, realizamos el Prueba de sistemas para probar toda la aplicación / sistema como un todo. Esta prueba valida los requisitos comerciales frente al software implementado.

Conclusión

yo diría que Examen de la unidad y las pruebas de componentes se realizan en paralelo.

A diferencia de las pruebas unitarias que realiza el equipo de desarrollo, las pruebas de componentes / módulos las realiza el equipo de pruebas. Siempre se recomienda realizar una prueba completa de los componentes antes de iniciar la prueba de integración.

Si la prueba de componentes es sólida como una roca, encontraremos menos defectos en la prueba de integración. Habría problemas, pero esos problemas estarían relacionados con el entorno de integración o los desafíos de configuración. Puede asegurarse de que la funcionalidad de los componentes integrados funcione correctamente.

Espero que este tutorial haya sido útil para comprender las pruebas de componentes, integración y sistema. Si aún tiene dudas, no dude en consultarnos en los comentarios.

Lectura recomendada

^