Fundamentos del proceso de testing funcional I – (Pruebas de Componentes)
Modelo de desarrollo en V
El siguiente gráfico muestra el modelo de desarrollo en V
Pruebas de componentes
Generalidades
Las fuentes de los casos de prueba de los componentes son
- La especificación del componente
- El diseño del software
- El modelo de datos
Los defectos suelen corregirse según se prueba, no se suelen documentar los errores. Una posible aproximación es preparar y automatizar las pruebas antes de codificar (“test first approach” o “test driven development”). Son modelos iterativos válidos para cuando las modificaciones suelen ser pequeñas.
Definición
Las pruebas de componentes so las pruebas de cada uno de los componentes básicos del software, por ejemplo:
- Pruebas de módulo (en C
- Pruebas de clase (en Java o C++)
- Pruebas de unidad (en Pascal)
¿Qué se prueba?
Se realizan pruebas completas de los componentes individuales. Se deben buscar errores internos y los efectos hacia otros componentes quedan fuera de consideración
¿Dónde y como se prueba?
En este caso el probador dispone del código de programa. El orobador normalmente es el desarrollador (lo más habitual). A menudo se utilizan pruebas funcionales y se realiza una utilización de procedimientos de caja blanca
Para la ejecución de los casos de prueba se utilizan, por regla general, stubs (maquetas) y, según el caso, controladores de pruebas
Los controladores de pruebas, simulan entradas, por ejemplo, del usuario, recogen valores de salida, proporcionan entornos de ejecución de software y pueden ser programados por uno mismo si, se tiene conocimiento de programación, se dispone del código del programa y se dispone de herramientas de programación.
Los Stubs reemplazan o simulan componentes que aún no están disponibles, no contienen lógica de programación y en ocasiones proporcionan datos de prueba.
Pruebas Funcionales
Las pruebas de componentes deben asegurar su funcionalidad , se deben realizar las siguientes preguntas, ¿Se cumplen todas las especificaciones?, ¿Se ejecutan correctamente todas las funciones?.
Cada una de las funciones de un componente se comprueba, al menos, con un caso de prueba.
Entre los errores frecuentes que se pueden encontrar con estas pruebas se encuentran, los errores en la elaboración y la ausencia de funciones.
No se prueba lo que debería haber, si no que lo que hay funciona tal y como ha sido implementado.
Pruebas de robustez
Se prueba cómo de robusto es un componente. La robustez describe la capacidad de respuesta de un software frente a entradas incorrectas, etc.
La robustez se prueba mediante casos de prueba negativos. Los casos de prueba negativos son casos que contienen datos de entrada incorrectos o no permitidos. Si el componente dispone de un tratamiento de excepciones para cada posible entrada de datos errónea, se considera robusto. Sin el correspondiente tratamiento de excepción los datos erróneos se introducen en el proceso y pueden ocasionar errores. Las posibles consecuencias son caídas y mal funcionamiento de los componentes
Otras pruebas posibles son pruebas de eficiencia y la capacidad de modificación
Tanto si estás buscando trabajar full time, como suplementar tus actuales ingresos con desarrollos adicionales a los que estás haciendo en tu actual trabajo, o quieres implicarte en el desarrollo de proyectos opensource y apoyar a la comunidad, rellena el formulario que hay a continuación y nos pondremos en contacto contigo para ver los proyectos en los que podemos colaborar.