Pruebas de Componente (K2 - entender, explicar , razonar)

Objetivos:

1. Comparar los distintos niveles de pruebas : Principales objetivos , objetos típicos de las pruebas, objetivos típicos de las pruebas (por ejemplo , funcionales o estructurales) y productos de trabajos asociados, personas que prueba, tipos de defectos y fallos a identificar (K2).

Términos usados en este artículo: PRUEBAS DE COMPONENTE, CONTROLADOR, PRUEBAS DE CAMPO, REQUISITO FUNCIONAL, INTEGRACIÓN, REQUISITO NO FUNCIONAL, PRUEBAS DE ROBUSTEZ, "STUB", PRUEBAS DE SISTEMA, ENTORNO DE PRUEBAS , NIVEL DE PRUEBA, DESARROLLO GUIADO POR PRUEBAS.

Pruebas de Componentes.

Base de Pruebas:

1. Requisitos de componentes.
2. Diseño de detalle.
3. Código.

Objetos de prueba típicos:

1. Componentes.
2. Programas.
3. Conversión de datos/programas de migración.
4. Módulos de bases de datos.

Las pruebas de componente conocidas también como pruebas de unidad, módulo o programa, tiene por objeto localizar defectos y comprobar el funcionamiento de módulos de software, programas, objetos, clases, etc., que pueden probarse por separado. 

Pueden realizarse de manera independiente del resto del sistema, en función del contexto del ciclo de vida de desarrollo y del sistema. Para ello pueden utilizarse "stubs", controladores y simuladores.

Las pruebas de componente pueden incluir pruebas de funcionalidad y características no funcionales específicas , tales como el comportamiento de recursos (por ejemplo , la búsqueda de filtraciones de memoria) o pruebas de robustez, además de pruebas estructurales (por ejemplo, cobertura de decisión). Los casos de prueba se derivan de productos de trabajo, tales como las especificaciones de componente, el diseño del software o el modelo de datos.

En general, las pruebas de componentes se llevan a cabo mediante el acceso al código objeto de las pruebas y con el soporte de un entorno de desarrollo, como por ejemplo un marco de pruebas de unidad o una herramienta de depuración. En la práctica, las pruebas de componente generalmente cuentan con la participación del programador que escribió el código. En general, los defectos se corrigen en el momento en que se detectan, sin gestionarlos formalmente.

Un enfoque a seguir en las pruebas de componentes es elaborar y automatizar los casos de prueba antes de codificarlos. Esto se denomina un primer enfoque de pruebas o un desarrollo guiado por pruebas, Este enfoque es altamente iterativo y está basado en la realización de ciclos de desarrollo de casos de prueba, para después construir e integrar pequeñas partes del código, y en la ejecución de las pruebas de componente corrigiendo cualquier problema e ir iterando hasta que se superen.