MODELO DE PRUEBAS DE SOFTWARE

DARWIN JIMENEZ

CARLOS EDUARDO AGUIRRE

INGENIERIA DE SISTEMAS

CONTENIDO

1. Definición de conceptos

2. Fundamentos de las pruebas de software

3. Objetivos de la prueba

4. Principios de la prueba

5. Facilidad de la prueba

6. Tipos de Pruebas

7. Proceso de Pruebas

CONTENIDO

8. Enfoques de pruebas

• Prueba de la caja blanca

• Prueba del camino básico

• Prueba de la estructura de control

• Prueba de la caja negra

1. DEFINICIONES DE CONCEPTOS

1. Falla (failure): Ocurre cuando un programa nose comporta de manera adecuada.

2. Falta (fault): Tiene lugar en el código delprograma. La existencia de una falta en elprograma puede generar una falla en elsistema.

1. Definiciones de Conceptos

3. Error: Es una acción humana que provoca que un software contenga una falta. Un error puede significar la existencia de una falta en el programa, lo cual hace que el sistema falle.

1. Definiciones de Conceptos

No se puede garantizar ni probar

que un sistema jamás falle, si no

que sólo se puede demostrar que

contiene faltas. No encontrar

faltas no significa que la prueba

haya sido exitosa. Solo lo es si se

han encontrado faltas.

2. Fundamentos de las pruebas de Software

• El ingeniero intenta construir el software partiendo de un concepto abstracto y llegando a una implementación tangible.

• El ingeniero crea una serie de casos de prueba que intentan “demoler “ el software construido.

3. Objetivos de las pruebas

• La prueba es un proceso de ejecución de unprograma con la intención de descubrir unerror.

• Un buen caso de prueba es aquel que tieneuna alta probabilidad de mostrar un error nodescubierto hasta entonces.

• Una prueba tiene éxito si descubre un errorno detectado hasta entonces.

4. Principios de la Prueba

• A todas las pruebas se les debería poder hacerun seguimiento has los requisitos del cliente.

• Las pruebas debería planificarse mucho antesde su inicio.

• El principio de Pareto es aplicable a la pruebadel Software: el 80% de todos los erroresdescubiertos durante las pruebas surgen alhacer un seguimiento de sólo el 20% de todoslos módulos del programa.

4. Principios de la Prueba

• Las pruebas deberían empezar por lopequeño y progresar hacia lo grande.

• No son posible las pruebas exhaustivas.

• Para ser más efectivas, las pruebas deberíanser conducidas por un equipo independiente.

5. Facilidad de Prueba

• Es simplemente lo fácil que se puede probarun programa de computadora. Como laprueba es tan profundamente difícil, merecela pena saber que puede hacer para hacerlomás sencillo.

Debe existir una lista de comprobación

que proporcione un conjunto de

características que llevan a un

software fácil de probar.

5. Facilidad de Prueba

• Principios:

• Operatividad: Cuanto mejor funcione máseficientemente se pude probar.

• Observabilidad: Lo que ves es lo que pruebas.

• Controlabilidad: Cuanto mejor podamos controlar el software, más se puede automatizar y optimizar.

5. Facilidad de Prueba

• Principios:

• Capacidad de Descomposición: Controlandoel ámbito de las pruebas, podemos aislar másrápidamente los problemas y llevar a cabomejores pruebas de regresión.

• Simplicidad: Cuanto menos haya que probar, más rápidamente podremos probarlo.

5. Facilidad de Prueba

• Principios:

• Estabilidad: Cuanto menos cambios, menosinterrupciones a las pruebas.

• Facilidad de comprensión: Cuanta más información tengamos, más inteligentes serán las pruebas.

6. Tipos de Prueba

Pruebas de Verificación: Se revisa si el resultadocorresponde a la especificación del sistema,es decir, si se está construyendo el sistemade manera correcta.

Pruebas de Validación: Se revisa si el resultadoes realmente lo que el cliente quería.

6.1 Técnicas de Pruebas

Pruebas de Regresión: Tiene como propósitoverificar el sistema luego, de haberleintroducido cambios, por ejemplo despuésde corregir una falta, de manera que semantenga la funcionalidad especificada.

Pruebas de Operación: Su objetivo es verificar elsistema en operación por un largo períodobajo condiciones normales de uso.

6.1 Técnicas de Pruebas

Pruebas de Escala Completa: Trata de verificar el sistemaen su carga máxima mediante de los parámetros a suvalor límite y la interconexión del sistema con unmáximo de equipos y usuarios simultáneos.

Pruebas de Rendimiento: Tiene como propósito medir lacapacidad de procesamiento del sistema bajodiferentes cargas, incluyendo espacio dealmacenamiento y utilización de la unidad deprocesamiento.

6.1 Técnicas de Pruebas

Pruebas de Sobrecarga: Pretende observar como secomparta el sistema cuando se le aplica unasobrecarga, más allá de las pruebas de escalacompleta y rendimiento.

Pruebas negativa: Tiene como propósito medir el estrésdel sistema en situaciones inesperadas, como casosde uso que normalmente no serían utilizados demanera simultánea.

6.1 Técnicas de Pruebas

Pruebas basada en requisitos o prueba de casos de uso:Intenta llevar a cabo pruebas basadas directamenteen la especificación de requisitos.

Pruebas ergonómicas: Tienen como propósito probar losaspectos ergonómicos del sistema, en otraspalabras, las interfaces hombre-máquina en el casode que éstas existan. Ejemplo: Si los menús sonlógicos y legibles, si los mensajes del sistema sonvisibles, si se puede entender los mensajes de falla,etc.

6.1 Técnicas de Pruebas

Pruebas de documentación de usuario: Tiene comopropósito probar la documentación de usuario,incluyendo el manual de éste y la documentación demantenimiento y servicio.

Pruebas de aceptación o de validación: Pretende lograruna revisión final por parte de la organización quesolicitó el sistema, lo cual, a menudo, significavalidación del sistema. Llamado Prueba Alfa oPrueba Beta.

6.1 Técnicas de Pruebas

Pruebas de documentación de usuario: Tiene comopropósito probar la documentación de usuario,incluyendo el manual de éste y la documentación demantenimiento y servicio.

Pruebas de aceptación o de validación: Pretende lograruna revisión final por parte de la organización quesolicitó el sistema, lo cual, a menudo, significavalidación del sistema. Llamado Prueba Alfa oPrueba Beta.

6.2 Nivel de Pruebas

Pruebas de unidad: Mediante esta prueba sólo unaunidad es probada como tal, como una clase, upaquete de servicio o un subsistema.

Pruebas de Integración: En ella se verifica que lasunidades trabajen juntas correctamente.

Pruebas de Sistema: Verifica el sistema completo o suaplicación como tal. Se toma el punto de vista delusuario final y los casos de uso de pruebas.

PRUEBA DE UNIDAD

Pruebas de procedimientos o subrutinas. En

un sistema orientado a objetos se aplican en

un nivel más alto, a partir de las clases.

Una prueba de unidad consiste en una

prueba estructural (o caja blanca), lo cual

requiere conocer el diseño interno de la

unidad, y una prueba de especificación(de

caja negra, basada sólo en la especificación

del comportamiento externamente visible de

la unidad.

PRUEBA DE UNIDAD

Prueba de Especificación o de Caja Negra: Tiene comopropósito verificar las relaciones de entrada y salidade una unidad. Su objetivo es verificar que hace launidad, pero sin averiguar como lo hace.

Prueba basada en estado: Verifica las interacciones entreoperaciones de una clase según cambios en losatributos de un objeto. Es necesario hacer pruebasdel objeto de acuerdo con su ciclo de vida.

Prueba Estructural o de Caja Blanca: Verifica que laestructura interna de la unidad sea correcta.

PRUEBA DE INTEGRACION

Después de haber probado todas las

unidades, éstas deben ser integradas en

unidades más grandes hasta generar el

sistema completo.

El propósito de la prueba de integración es

probar que las diferentes unidades trabajen

juntas de manera apropiada.

7. Proceso de Pruebas

El proceso de pruebas involucra consideraciones

similares al del proceso de desarrollo, incluyendo

estrategias, actividades y métodos, los cuales

deben ser aplicados de manera concurrente con el

proceso de desarrollo de software.

1. ESTRATEGIA DE LA PRUEBA:

• Orden de Pruebas: Tienen como propósito definir en quemomento y en que orden se aplicarán las pruebas. Diseño,implementación y operación del sistema.

7. Proceso de Pruebas

ESTRATEGIA DE LA PRUEBA:

• Orden de Pruebas: Existen dos enfoques generales para elorden en que se efectuarán las pruebas:

De arriba hacia abajo: Se deben desarrollar inicialmente lasinterfaces entre subsistemas, para probar protocolos dealto nivel antes de ir a probar los niveles inferiores.

De abajo hacia arriba: Certificar primero las unidades debajo nivel y luego las interfaces entre ellos.

7. Proceso de Pruebas

1. ESTRATEGIA DE LA PRUEBA:

• Alcance de pruebas: Tiene como propósito identificar el tipo,número y casos de pruebas que se aplicarán para revisar losdiferentes aspectos del sistema

• Automatización de la Prueba: Tiene como propósito reducirel esfuerzo y costo de las pruebas mediante automatizacióndel proceso o aspectos de él.

7. Proceso de Pruebas

2. PLANEACION DE LA PRUEBA:

Comienza con el establecimiento de las estrategias

de pruebas, lo que incluye la cuestión si estás se

harán automática o manualmente y si existen

programas y datos de prueba que puedan ser

usados, posiblemente modificados o desarrollados

de nueva cuenta

Estrategia de la prueba

Alcance de la prueba

Recursos

7. Proceso de Pruebas

3. CONSTRUCCION DE LA PRUEBA:

Se describe cada prueba y su propósito de manera

general y detallada. Se debe describir exactamente

cómo se deberá ejecutar el caso de prueba, de

manera que personas no familiarizadas con la

aplicación puedan ejecutar el caso.

Ambiente de desarrollo o real

Tipo de software

Tipo de hardware

Equipo de prueba

Versión del sistema

7. Proceso de Pruebas

3. EJECUCION DE LA PRUEBA:

Durante esta etapa se utiliza la especificación del diseño deprueba y los reportes de ésta.

La estrategia es aplicar de manera paralela el mayor caso depruebas posibles.

Se Ejecutan las pruebas automáticas y manuales de maneracorrespondiente y se indican los resultados esperados.

Si alguna prueba falla, se interrumpe su aplicación y se anota elresultado para luego analizar el defecto y corregirlo.

PRUEBA DE LA ESTRUCTURA DE CONTROL

• Las pruebas son de gran importancia en lagarantía de la calidad del software.

• Estas variantes amplían la cobertura de laprueba y mejoran la calidad de la prueba decaja blanca.

– Prueba de Condición

– Prueba de Flujo de Datos

– Prueba de Bucles

Prueba de condición

• Método de diseño de casos de prueba queejercita las condiciones lógicas contenidas en elmódulo de un programa.

• Esta prueba asegura en que cada condición delprograma no contenga errores.

• Una condición simple es una variable lógica ouna expresión relacional.

• La expresión relacional adquiere la siguienteforma: E1 <operador relacional>E2; donde E1 y E2

son expresiones aritméticas y <operadorrelacional> puede ser “<, <=, =, >, >=, ≠”

• Una condición compuesta está formada por doso más condiciones simples, operadores lógicoso paréntesis. Los operadores lógicos permitidosen una condición compuesta incluye OR(|),AND(&), NOT.

• Una condición sin expresiones relacionadas sele denomina expresión lógica.

• Si una condición es incorrecta, entonces esincorrecto al menos un componente de lacondición. Los errores de una condiciónpueden ser:

– Error en operador lógico

– Error en variable lógica

– Error en paréntesis lógico

– Error en operador relacional

– Error en expresión aritmética

• Se han propuesto series de estrategias deprueba de condiciones:– Prueba de ramificaciones: Para una condición

compuesta C, es necesario ejecutar al menos unavez las ramas verdadera y falsa de C y cada condiciónsimple de C.

– Prueba del dominio: Requiere la realización de 3 o 4pruebas para una expresión relacional.

E1 <operador relacional> E2 se requieren trespruebas para comprobar que el valor de E1 es mayor,igual o menor que el valor de E2. Por ejemplo si eloperador relacional es incorrecto y E1 y E2 soncorrectos, entonces estas tres pruebas garantizan ladetección de un error del operador relacional.

Prueba de flujo de datos

• Selecciona caminos de prueba de un programa deacuerdo con la ubicación de las definiciones y losusos de las variables del programa.

• Las estrategias de prueba de flujo de datos sonútiles para seleccionar caminos de prueba de unprograma que contenga sentencias if o buclesanidados.

• Necesitamos conocer la estructura de cadacondición o bloque (seleccionando un camino delprograma, determinamos si el camino es factiblepara el programa)

Prueba de bucles

• Técnica de prueba de caja blanca que secentra en la validez de las construcciones debucles.

• Se pueden definir 4 clases diferentes debucles:

– Simples,

– Concatenados,

– Anidados,

– No estructurados

Buclessimples

Buclesanidados

Buclesconcatenados Bucles no

estructurados

Bucles

Bucles simples:

• Se les debe aplicar el siguiente conjunto depruebas, donde n es el número máximo depasos permitidos por el bucle

1. Pasar por alto totalmente el bucle

2. Pasar una sola vez por el bucle

3. Pasar dos veces por el bucle

4. Hacer m pasos por el bucle con m<n

5. Hacer n-1 y n+1 pasos por el bucle

Bucles anidados:

• Si se extendiera el enfoque de los buclessimples a los bucles anidados, el número deposibles pruebas aumentaría geomé-tricamente a medida que aumenta el nivel deanidamiento. Esto llevaría a un númeroimprescindible de pruebas.

• Se sugiere un enfoque que ayuda a reducir elnúmero de pruebas

1. Comenzar por el bucle más interior

2. Llevar a cabo las pruebas de bucles simples

3. Progresar hacia fuera, llevando a cabo pruebaspara el siguiente bucle

4. Continuar hasta que se hayan probado todos losbucles

Bucles concatenados:

• Se pueden probar mediante el enfoquedefinido para los bucles simples, mientrascada uno de los bucles sea independiente delresto.

Bucles no estructurados:

• Esta clase de bucles se debe rediseñar paraque se ajusten a las construcciones deprogramación estructurada.

PRUEBA DE CAJA NEGRA

• Se centra en los requisitos funcionales delsoftware.

• Se trata de un enfoque complementario queintenta descubrir diferentes tipos de erroresde los métodos de caja blanca.

• La prueba de caja negra intenta encontrarerrores de las siguientes categorías:

– Funciones incorrectas o ausentes

– Errores de interfaz

– Errores es estructura de datos o en accesos abases de datos externas

– Errores de rendimiento

– Errores de inicialización y de terminación

Método de prueba basados en grafos

• La prueba empieza creando un grafo de objetosy sus relaciones y después diseñando una seriede pruebas que cubran el grafo de manera quese ejerciten todos los objetos y sus relacionespara descubrir los errores.

• Estos casos de prueba están diseñados paraintentar encontrar errores en algunas de lasrelaciones.

• El grafo ayudaría a identificar aquellos buclesque hay que probar.

• Es un método de prueba de caja negra, sedirige a la definición de casos de prueba quedescubran clases de errores, reduciendo así elnúmero total de casos de prueba que hay quedesarrollar.

• El objetivo de partición equivalente es reducirel posible conjunto de casos de prueba en unomás pequeño, un conjunto manejable queevalúe bien el software.

Partición equivalente

• El diseño de casos de prueba para la particiónequivalente se basa en una evaluación de lasclases de equivalencia para una condición deentrada.

• Una clase de equivalencia representa unconjunto de estados válidos o no válidos paracondiciones de entrada (es un valor numéricoespecífico, un rango de valores, un conjuntode valores relacionados o una condiciónlógica).

Sitio alquiler de películas

• Rango de valores

– Alquiler para personas mayores 18 años

• Valor

– Nº de películas que se alquilan

• Conjunto de valores específico

– Películas (Acción, Comedia, Infantil, Intriga)

• Lógico

– ¿Es socio?

• Es una técnica de diseño de casos de pruebaque complementa la prueba de ParticiónEquivalente. En lugar de realizar la prueba concualquier elemento de la partición equivalente,se escogen los valores en los extremos de laclase.

• Por ejemplo: si una condición de entradaespecifica un rango delimitado por los valoresa y b, se deben diseñar casos de prueba paralos valores a y b y para los valores que seencuentran por debajo y por encima.

Análisis de Valores Límite (AVL)

• Aplicación en sistemas de alta fiabilidad

• Desarrollos paralelos

• Intercambio de casos de prueba

• Desarrollo del software, las versiones de laaplicación se ejecutan en equiposindependientes, usando las mismasespecificaciones.

• Se deben probar todas las versiones con losmismos datos, para asegurar queproporcionan una salida idéntica.

Prueba de Comparación

• Pruebas de interfaces gráficas de usuario

• Prueba de documentación y de ayuda

– Es importante para la aceptación del programa.

– Revisar la guía de usuario o funciones de ayuda enlínea.

• Prueba de sistemas de tiempo real

– Prueba de tareas

– Prueba de comportamiento

– Prueba intertareas

– Prueba del sistema

PRUEBA DE ENTORNOSY APLICACIONES ESPECIALIZADAS

JTS 2008

V JORNADA DE TESTEO DE SOFTWARE 2008

2,3 Y 4 DE ABRIL DE 2008

VALENCIA ESPAÑA

VIDEO

BLOG DE LA JORNADA

BIBLIOGRAFIA

Ingenieria de Software Orientada a Objetos.-AlfredoWeitzenfeld.- Editorial Thomson