Tipos De Pruebas

Contenido

TIPOS DE PRUEBAS DE SOFTWARE 4

PRUEBAS UNITARIAS 4

Objetivo de la Prueba: 4

Descripción de la Prueba: 4

Técnica: 4

Criterio de Completitud: 4

Consideraciones Especiales: 4

PRUEBAS DE INTEGRACIÓN 5

Objetivo de la Prueba: 5

Descripción de la Prueba: 5

Técnica: 5

Criterio de Completitud: 5

Consideraciones Especiales: 5

PRUEBA DE REGRESIÓN 6

Objetivo de la Prueba: 6

Descripción de la Prueba: 6

Técnica: 6

Criterio de Completitud: 6

Consideraciones Especiales: 6

PRUEBAS DE HUMO (SMOKE TESTING O AD HOC) 6

Objetivo de la Prueba: 6

Descripción de la Prueba: 7

Técnica: 7

Criterio de Completitud: 7

Consideraciones Especiales: 7

PRUEBAS DEL SISTEMA 7

Objetivo de la Prueba: 7

Descripción de la Prueba: 7

Técnica: 8

Criterio de Completitud: 9

Consideraciones Especiales: 9

PRUEBAS DE DESEMPEÑO 9

Objetivo de la Prueba: 9

Descripción de la Prueba: 9

Técnica: 10

Criterio de Completitud: 10

Consideraciones Especiales: 10

PRUEBAS DE RECUPERACION Y TOLERANCIA A FALLAS 11

Objetivo de la Prueba: 11

Descripción de la Prueba: 11

Técnica: 11

Criterio de Completitud: 12

Consideraciones Especiales: 12

PRUEBAS DE COMPATIBILIDAD Y CONVERSION 12

Objetivo de la Prueba: 12

Descripción de la Prueba: 13

Técnica: 13

Criterio de Completitud: 13

Consideraciones Especiales: 13

PRUEBAS DE INTEGRIDAD DE DATOS Y BASE DE DATOS 13

Objetivo de la Prueba: 13

Descripción de la Prueba: 13

Técnica: 13

Criterio de Completitud: 14

Consideraciones Especiales: 14

PRUEBAS DE CONFIGURACION 14

Objetivo de la Prueba: 14

Descripción de la Prueba: 14

Técnica: 14

Criterio de Completitud: 15

Consideraciones Especiales: 15

PRUEBAS DE ESTILO 15

Objetivo de la Prueba: 15

Descripción de la Prueba: 15

Técnica: 15

Criterio de Completitud: 15

Consideraciones Especiales: 15

PRUEBA DE ACEPTACION 16

Objetivo de la Prueba: 16

Descripción de la Prueba: 16

Técnica: 16

Criterio de Completitud: 16

Consideraciones Especiales: 16

PRUEBA DE INSTALACION 17

Objetivo de la Prueba: 17

Descripción de la Prueba: 17

Técnica: 17

Criterio de Completitud: 17

Consideraciones Especiales: 17

PRUEBA DE USABILIDAD 17

Objetivo de la Prueba: 18

Descripción de la Prueba: 18

Técnica: 18

Criterio de Completitud: 18

Consideraciones Especiales: 18

Bibliografía 19

TIPOS DE PRUEBAS DE SOFTWARE

Se describen diferentes tipos de pruebas que se pueden realizar para cualquier tipo de software y cabe destacar que cada prueba contendrá los siguientes aspectos.

 Objetivo de la prueba

 Descripción de la prueba

 Técnica

 Criterio de Completitud

 Consideraciones Especiales

PRUEBAS UNITARIAS

Objetivo de la Prueba:

Se focaliza en ejecutar cada módulo (o unidad mínima a ser probada, ej = una clase) lo que provee un mejor modo de manejar la integración de las unidades en componentes mayores.

Busca asegurar que el código funciona de acuerdo con las especificaciones y que el módulo lógico es válido.

Descripción de la Prueba:

 Particionar los módulos en pruebas en unidades lógicas fáciles de probar.

 Por cada unidad hay que definir los casos de prueba (pruebas de caja blanca).

 Para esto los casos de prueba deben diseñarse de forma tal que se recorran todos los caminos de ejecución posibles dentro del código bajo prueba; por lo tanto el diseñador debe construirlos con acceso al código fuente de la unidad a probar.

Los aspectos a considerar son los siguientes: Rutinas de excepción, Rutinas de error, Manejo de parámetros, Validaciones, Valores válidos, Valores límites, Rangos, Mensajes posibles.

Técnica:

 Comparar el resultado esperado con el resultado obtenido.

 Si existen errores, reportarlos.

Criterio de Completitud:

 Todas las pruebas planeadas han sido ejecutadas.

 Todos los defectos que se identificaron han sido tenidos en cuenta.

Consideraciones Especiales:

Para la elaboración de pruebas unitarias en java se puede utilizar el JUNIT y CACTUS.

PRUEBAS DE INTEGRACIÓN

Objetivo de la Prueba:

Identificar errores introducidos por la combinación de programas probados unitariamente.

Determina cómo la base de datos de prueba será cargada.

Verificar que las interfaces entre las entidades externas (usuarios) y las aplicaciones funcionan correctamente.

Verificar que las especificaciones de diseño sean alcanzadas.

Determina el enfoque para avanzar desde un nivel de integración de las componentes al siguiente.

Descripción de la Prueba:

 Describe cómo verificar que las interfaces entre las componentes de software funcionan correctamente.

 Determina cómo la base de datos de prueba será cargada.

 Determina el enfoque para avanzar desde un nivel de integración de las componentes al siguiente.

 Decide qué acciones tomar cuando se descubren problemas.

Por cada Caso de Prueba ejecutado se debe de:

 Comparar el resultado esperado con el resultado obtenido.

Técnica:

 Utilizar la técnica top-down. Se empieza con los módulos de nivel superior, y se verifica que los módulos de nivel superior llaman a los de nivel inferior de manera correcta, con los parámetros correctos.

 Utilizar la técnica down-top. Se empieza con los módulos de nivel inferior, y se verifica que los módulos de nivel inferior llaman a los de nivel superior de manera correcta, con los parámetros correctos.

Criterio de Completitud:

 Todas las pruebas planeadas han sido ejecutadas.

 Todos los defectos que se identificaron han sido tenidos en cuenta.

Consideraciones Especiales:

En este caso no contiene este tipo de información

PRUEBA DE REGRESIÓN

Objetivo de la Prueba:

Determinar si los cambios recientes en una parte de la aplicación tienen efecto adverso en otras partes.

Descripción de la Prueba:

En esta prueba se vuelve a probar el sistema a la luz de los cambios realizados durante el debugging, mantenimiento o desarrollo de la nueva versión del sistema buscando efectos adversos en otras partes.

Técnica:

 La prueba de regresión es una nueva corrida de casos de prueba previos.

 Se requiere de políticas para ser creada la prueba de regresión y decidir qué casos de prueba incluir, para probar eficientemente.

 La prueba de regresión es un buen candidato para automatización. Desde que estas pruebas se repiten una y otra vez, las herramientas para minimizar el esfuerzo del trabajo son útiles.

 La prueba de viejas funcionalidades es más importante que la de nuevas funcionalidades.

Aquellos casos de uso (y los casos de prueba asociados) que descubren defectos tempranamente deben ser incluidos en la prueba de regresión.

Criterio de Completitud:

 Todas las pruebas planeadas han sido ejecutadas.

 Todos los defectos que se identificaron han sido tenidos en cuenta.

Consideraciones Especiales:

En este caso no contiene este tipo de información

PRUEBAS DE HUMO (SMOKE TESTING O AD HOC)

Objetivo de la Prueba:

 Detectar los errores en raleases tempranos y de manera fácil

 Probar el sistema constantemente

 Garantizar poco esfuerzo en la integración final del sistema

 Asegurar los resultados de las pruebas unitarias

 Se reducen los riesgos y a baja calidad.

Descripción de la Prueba:

Toma éste nombre debido a que su objetivo es probar el sistema constantemente buscando que saque “humo” o falle. En algunos proyectos este tipo de prueba va junto con las pruebas funcionales. Permite detectar problemas que por lo regular no son detectados en las pruebas normales. Algunas veces, si las Pruebas ocurren tarde en el ciclo de desarrollo está será una forma de garantizar el buen desarrollo.

Las pruebas de humo NO SON exhaustivas, pero van de extremo a extremo de la aplicación.

Técnica:

1. Realizar una integración de todo el sistema cada cierto periodo (se recomienda un día, máximo una semana)

2. Realizar los casos de prueba asignados a los casos de uso finalizados ese día más los realizados en días anteriores

3. Buscar eficientemente errores

Criterio de Completitud:

 Todas las pruebas planeadas han sido ejecutadas.

 Todos los defectos que se identificaron han sido tenidos en cuenta.

Consideraciones Especiales:

Cuando se encuentre un error en el reléase correspondiente al periodo elegido para hacer las integraciones del sistema, se detiene el desarrollo hasta que el error es corregido.

Este tipo de pruebas es útil en la programación extrema (extremme programming) y de sistemas complejos.

...