5/10/2007

1

PRUEBAS DE SOFTWARE

PCPM

PRUEBAS DE SOFTWAREPor: Paola Constanza Peña MeloIngeniería de Software – Mayo de 2007

1

AGENDA GENERAL

PCPM

2

5/10/2007

2

AGENDA…PC

PM

3

¿QUE SON LAS PRUEBAS DE SOFTWARE?Proceso de análisis de un sistema.

Detectar diferenciasDetectar diferencias.

C t i t

PCPM

Comportamiento

4

5/10/2007

3

OBJETIVO DE LAS PRUEBAS

Maximizar la cantidad de defectos descubiertos.Permite que los desarrolladores los corrijan e Permite que los desarrolladores los corrijan e incrementen la confiabilidad del sistema.

mmm… Nuevamente… ¿Qué son las

Pruebas?

Son el intentosistemático de localizar

errores en forma planeada en el software

implementado.

PCPM

5

¿QUIENES SON LOS ENCARGADOS DELAS PRUEBAS?

Roles:

DesarrolladoresDesarrolladores

Test Manager

Líder de Pruebas

Ingeniero de Usabilidad

Ingeniero de Pruebas Manuales

Ingeniero de Pruebas Automatizadas

Ingeniero de Pruebas de Red

PCPM

Probador IndependienteProbador Independiente

Ingeniero de Pruebas de Red

Especialista de Ambiente de Pruebas

Ingeniero de Pruebas de Seguridad

6

5/10/2007

4

¿PORQUÉ ES IMPOSIBLE PROBAR PORCOMPLETO UN SISTEMA?

Las pruebas no son determinantes.

CONSECUENCIA:Los sistemas se determinantes.

Es necesario realizar las pruebas bajo restricciones de tiempo y presupuesto.

Los sistemas se entregan sin estar probados por completo, lo que conduce a defectos que son descubiertos por los usuarios finales.

PCPM

7

PANORAMA DE LAS PRUEBAS

PCPM

8

5/10/2007

5

CONFIABILIDAD DEL SOFTWAREProbabilidad de que un sistema de software no causará la falla del sistema

durante un tiempo especificado bajo condiciones específicas.

PANORAMA

FALLADEFECTOEs cualquier desviación del comportamiento observado

respecto al especificado.

Es la causa mecánica o algorítmica de un error

PCPM

ERRORSignifica que el sistema está en un estado en el cual el procesamiento adicional del

sistema conducirá a una falla, lo cual causa que el sistema se desvie del comportamiento pretendido. 9

TÉ

CN

ICA

SD

EEC

ON

TR

OL

DE

C

PCPM

CA

LID

AD

10

5/10/2007

6

TÉCNICAS PARA EVITAR DEFECTOS (1)Evitar defectos trata de impedir la ocurrencia de errores y fallas encontrando defectos en el sistema antes de lanzarlo.en el sistema antes de lanzarlo.Incluyen:

Desarrollo de metodologías:Evita los defectos proporcionando técnicas que minimizan la introducción de defectos en los modelos del sistema y en el código.

Administración de la configuración

PCPM

Administración de la configuración.Evita los defectos causados por cambios sin disciplina en los modelos del sistema. (Ejm: cambio de interfaz del sistema sin notificación previa a los desarrolladores que dependen de ella)El sistema contiene mucho menos defectos si se controla el cambio. 11

TÉCNICAS PARA EVITAR DEFECTOS (2)Técnicas de verificación.

Trata de encontrar defectos antes de cualquier ejecución delsistema.

La verificación tiene sus límites, pues no se encuentra en unestado bastante maduro como para que pueda aplicarsepara asegurar la calidad de grandes sistemas complejos.

PCPM

Supone que los requerimientos son correctos, lo cual raravez sucede.

12

5/10/2007

7

TÉCNICAS PARA EVITAR DEFECTOS (3)Revisión.

Es la inspección manual de algunos o todos los aspectosEs la inspección manual de algunos o todos los aspectosdel sistema sin ser ejecutado.

Ensayo (de código): El desarrollador presenta de modo informal el modelo, el código y la documentación ante el equipo de revisión.

Inspección: Es similar a un ensayo, con la diferencia de que la

PCPM

presentación de la unidad es formal. (No lo presenta el desarrollador sino el equipo de revisión).

El desarrolador solo está presente cuando la revisión necesita aclaraciones específicas de la definición, los algoritmos o las estructuras de datos.

13

TÉCNICAS PARA LA DETECCIÓN DEDEFECTOS (1)

Ayudan a encontrar defectos en los sistemas pero no tratan de recuperar las fallas que lo causan. (Ejm: tratan de recuperar las fallas que lo causan. (Ejm: Cajas negras de los aviones)

Depuración: asume que los defectos puedenencontrarse iniciando a partir de una falla no planeada.

Depuración para Corrección.

PCPM

Depuración para Corrección.Es encontrar cualquier desviación entre los requerimientos no funcionales observados y los especificados.

Depuración del Desempeño.Trata la desviación entre los requerimientos funcionalesobservados y los especificados, como el tiempo de respuesta. 14

5/10/2007

8

TÉCNICAS PARA LA DETECCIÓN DEDEFECTOS (2)

PruebaEs una técnica de detección de defectos que trata de Es una técnica de detección de defectos que trata de crear fallas o errores en forma planeada.

PCPM

15

AC

TIV

IDA

DE

S D

Pruebas Unitarias

Pruebas de Integración

Pruebas de Estructura.

Pruebas del Sistema.

Pruebas Funcionales.

Pruebas de Desempeño.DE

PR

UE

BA

Pruebas de Aceptación e Instalación.

PCPM

16

5/10/2007

9

TÉCNICAS PARA LA TOLERANCIA DEDEFECTOS

Es la recuperación de una falla mientras elsistema se está ejecutando.sistema se está ejecutando.

Ejm: Los sistemas de bases de datosproporcionan transacciones atómicas (todo onada), para recuperarse de una falla durante unasecuencia de acciones.

PCPM

La redundancia modular está sustentada en lasuposición de que las fallas del sistema se basan,por lo general, en fallas de componentes.

17

CONCEPTOS DE LAS PRUEBAS

PCPM

18

5/10/2007

10

ELEMENTOS DEL MODELO USADODURANTE LAS PRUEBAS (1)

PCPM

19

ELEMENTO SIGNIFICADOCASO DE PRUEBA Es un conjunto de entradas y resultados esperados,

que ejercita a un componente con el propósito decausar fallas y detectar defectos.

FALLA Es una desviación entre la especificación de uncomponente y su comportamiento Es producida porcomponente y su comportamiento. Es producida poruno o más errores.

COMPONENTE Es una parte del sistema que puede aislarse para laprueba (Objeto, Grupo de Objetos)

STUB DE PRUEBA Es una implementación parcial de componentes de loscuales depende el componente probado.

MANEJADOR DE PRUEBAS

Es una implementación parcial de un componente quedepende del componente probado.

ERROR E l d l l f ll

PCPM

ERROR Es el que da lugar a las fallas

CORRECCIÓN Es el cambio que se le realiza a un componente.Propósito: Reparar un defecto.

DEFECTO Es un error de diseño o codificación que puede causarun comportamiento anormal de un componente. 20

5/10/2007

11

EJEMPLO (DEFECTO)PC

PM

21

EJEMPLO (ERROR)

PCPM

22

5/10/2007

12

EJEMPLOPC

PM

Un defecto debe tener alguna causa algorítmica 23

EJEMPLO

PCPM

Un defecto puede tener una causa mecánica 24

5/10/2007

13

CASOS DE PRUEBA

Es un conjunto de datos de entrada y resultados esperados que ejercitan a un componente con el esperados que ejercitan a un componente con el propósito de causar fallas y detectar defectos.

PCPM

25

MODELO DE PRUEBA CON CASOS DEPRUEBA

PCPM

Un buen modelo de prueba tiene la menor cantidad de asociaciones posibles, debido a que laspreubas que no están asociadas entre ellas pueden ejecutarse de forma independiente.

26

5/10/2007

14

STUBS Y MANEJADORES DE PRUEBAS

Se usan para sustituir las partes faltantes de un sistema mientras estas se encuentran aisladas en sistema mientras estas se encuentran aisladas en una ejecución de casos de pruebas.

Simula la parte del sistema que llama al componente a probar.

PCPM

Simula a los componentes que son llamados por el componente a probar.

27

EJEMPLO

U d l P t ó d Di ñ P t h l i t fá d

PCPM

Uso del Patrón de Diseño Puente para hacer la interfáz de uncomponente que todavía no se ha terminado, o que no se conoce o nose tiene disponible durante la prueba de otro componente.

28

5/10/2007

15

CORRECCIONES (1)Es un cambio a un componente con el propósitode reparar un defecto.de reparar un defecto.

Las correcciones pueden ir desde una simplemodificación de un solo componente, hasta elrediseño completo de una estructura de datos oun subsistema.

PCPM

29

CORRECCIONES (2)Existe una probabilidad alta de que el desarrollador introduzca nuevos defectos en el componente revisado.

ÉTÉCNICAS SEGUIMIENTO DEL PROBLEMADocumentación de cada falla, error, defecto detectado, sucorrección y revisiones de

componentes.

PRUEBAS DE REGRESIÓNVolver a ejecutar todas laspruebas anteriores después

del cambio

PCPM

del cambio.

MANTENIMIENTO DE LA FUNDAMENTACIÓN.

Incluye la documentación de la fundamentación de los cambios y surelación con la fundamentación del

componente revisado.30

5/10/2007

16

ACTIVIDADES DE LAS PRUEBASPC

PM

31

ACTIVIDADES DE LAS PRUEBAS

Entre estas actividades se incluyen:ACTIVIDAD SIGNIFICADOACTIVIDAD SIGNIFICADO

INSPECCIÓN DE COMPONENTES

Encuentran defectos en componentesindividuales mediante la inspecciónmanual de su código fuente.

PRUEBAS UNITARIAS Encuentran defectos aislando un componente individual utilizandomanejadores de pruebas.

PRUEBAS DE INTEGRACIÓN Encuentran defectos integrando

PCPM

varios componentes.

PRUEBAS DEL SISTEMA Se enfocan en el sistema completo, sus requerimientos funcionales y no funcionales y su ambiente de destino. 32

5/10/2007

17

INSPECCIÓN DE COMPONENTES (1)Su objetivo es encontrar defectos en un componente revisando su código fuente manualmente.revisando su código fuente manualmente.

Para esto se tiene un equipo de trabajo constituido por:DesarrolladoresEl autor del componenteUn moderadorUno ó más revisores

PCPM

Uno ó más revisores

33

2) PREPARACIÓN

INSPECCIÓN DE COMPONENTES (2)

1) PANORAMA )Los revisores se familiarizan

con el funcionamiento del componente.

El autor del componente presenta brevemente el propósito y alcance

del componente y los objetivos de la inspección

3)REUNIÓN DE INSPECCIÓNSe estudia el código detalladamente y

4) REPARACIÓN El autor revisa el componente.

PCPM

el equipo de inspección plantea problemas relacionados con el

componente. El moderador mantiene la reunión.

p

5) SEGUIMIENTOEl moderador revisa la

calidad de la reparación y determina si es necesario

otra inspección.34

5/10/2007

18

PRUEBA UNITARIA(1)Enfocada en la prueba de los objetos y subsistemas

de la aplicación.p

tiene 3 ventajas principales:

Reduce la complejidad de las actividades de prueba.Facilita resaltar y corregir defectos (pocos

PCPM

Facilita resaltar y corregir defectos (pocos componentes)Permite el paralelismo: cada componente puede probarse independiente de los demás.

35

PRUEBA UNITARIA(2)Prueba de Equivalencia: minimiza la cantidad de casos de prueba.p

Prueba de Frontera: su caso de prueba es estudiar el caso extremo de las variables de los objetos.

PCPM

Prueba de Ruta: estudia los caminos posibles que podría tener un caso de prueba combinado por varios parámetros

Punto Inicial: diagrama de flujo. 36

5/10/2007

19

PRUEBA UNITARIA (3)Pruebas Basadas en Estado: Se enfoca en los sistemas Orientados a Objetos Se enfoca en los sistemas Orientados a Objetos. Intenta probar el estado de un sistema en diferentes condiciones, y comparar los resultados que se obtuvieron con los esperados.

PCPM

37

PROCEDURE average;

* This procedure computes the average of 100 or fewer numbers that lie between bounding values; it also computes the sum and the total number valid.

INTERFACE RETURNS average, total.input, total.valid;INTERFACE ACCEPTS value, minimum, maximum;TYPE value[1:100] IS SCALAR ARRAY;

EJEMPLOEJEMPLO: PDL : PDL forfor test test designdesign

TYPE value[1:100] IS SCALAR ARRAY;TYPE average, total.input, total.valid;

minimum, maximum, sum IS SCALAR;TYPE i IS INTEGER;i = 1;total.input = total.valid = 0;sum = 0;DO WHILE value[i] <> -999 and total.input < 100

increment total.input by 1;IF value[i] >= minimum AND value[i] <= maximum

THEN increment total.valid by 1;sum = sum + value[i]

ELSE skip

PCPM

pENDIFincrement i by 1;

ENDDOIF total.valid > 0

THEN average = sum / total.valid;ELSE average = -999;

ENDIF

END average38

5/10/2007

20

Identificando Nodos Identificando Nodos

PROCEDURE average;

* This procedure computes the average of 100 or fewer numbers that lie between bounding values; it also computes the sum and the total number valid.

INTERFACE RETURNS average, total.input, total.valid;

12

3

64

57

INTERFACE ACCEPTS value, minimum, maximum;TYPE value[1:100] IS SCALAR ARRAY;TYPE average, total.input, total.valid;

minimum, maximum, sum IS SCALAR;TYPE i IS INTEGER;i = 1;total.input = total.valid = 0;sum = 0;DO WHILE value[i] <> -999 and total.input < 100

increment total.input by 1;IF value[i] >= minimum AND value[i] <= maximum

THEN increment total.valid by 1;sum = sum + value[i]

PCPM

89

101112

13

sum sum + value[i]ELSE skip

ENDIFincrement i by 1;

ENDDOIF total.valid > 0

THEN average = sum / total.valid;ELSE average = -999;

ENDIF

END average

39

Gráfica de control del Proceso “Gráfica de control del Proceso “averageaverage””

1

2

3

4

5

10

12 11

PCPM

6

8 7

9

13

40

5/10/2007

21

V(G) = No. de estatutos condicionales + 1[(estatutos compuestos cuentan por 2]

(No. de operadores booleanos + 1)

V(G) = 6

ResultadosResultados

V(G) 6V(G) = 18 arcos - 14 nodos + 2 = 6V(G) = 5 nodos predicados + 1 = 6(2), (3), (5), (6), (10)

Ruta 1: 1-2-10-11-13Ruta 2: 1-2-10-12-13Ruta 3: 1-2-3-10-11-13

PCPM

Ruta 4: 1-2-3-4-5-8-9-2-.....Ruta 5: 1-2-3-4-5-6-7-8-9-2-....

Una trayectoria independiente es cualquier ruta a través del programa que introduce cuando menos un nuevo conjunto de estatutos de procesamiento o una nueva condición.

41

Caso de prueba ruta 1value( k ) = valid input, where k < i defined belowvalue( i ) = -999 where 2<= i <= 100Resultado esperado: promedio correctoN t N d b l d b b t d l b d l t 4

Casos de pruebaCasos de prueba

Nota: No puede probarse solo, debe probarse como parte de las pruebas de las rutas 4, 5 y 6

Caso de prueba ruta 2value(1) = -999Resultado esperado: promedio = -999

Caso de prueba ruta 3Procesar 101 o más valores, los primeros 100 valores deben ser válidosR lt d d i l l 1

PCPM

Resultado esperado: igual que el caso 1.

Caso de prueba ruta 4value( i ) = entrada válida, donde i < 100value( k ) = mínimo, donde k <= iResultado esperado: promedio correcto, basado en k valores y totales apropiados

42

5/10/2007

22

Caso de prueba ruta 5value( i ) = entrada válida, donde i < 100value ( k ) = máximo, donde k <= iResultado esperado: promedio correcto, basado en n valores y totales apropiados

Casos de Prueba (Cont..)Casos de Prueba (Cont..)

p p , y p p

Caso de prueba ruta 6value( i ) = entrada válida, donde i < 100Resultado esperado: promedio correcto, basado en n valores y totales apropiados

PCPM

43

PRUEBAS DE INTEGRACIÓN (1)Una vez se han realizado las pruebas unitaria,frontera y ruta, las cuales son con objetosfrontera y ruta, las cuales son con objetosindividuales, se puede ahora integrar con otrosobjetos, formando un subsistema, el cual seprueba en esta fase.

Intentan detectar nuevos defectos en pequeñosgrupos de componentes

PCPM

grupos de componentes

44

5/10/2007

23

PRUEBAS DE INTEGRACIÓN (2)Se han ideado varios enfoques para implementar una estrategia de pruebas de integración.g p g

Pruebas de gran explosiónAsume que todos los componentes se prueban primero en forma individual y luego juntos como un solo sistema.

Pruebas de abajo hacia arribaPrueba primero de manera individual a todos loscomponentes de la capa inferior y luego los integra concomponentes de la siguiente capa superior

PCPM

componentes de la siguiente capa superior.Prueba Doble: Cuando dos componentes se prueban juntos.Prueba Triple: Tres componentes.Prueba Cuádruple: Cuatro componentes.

Esto se repite hasta que se combinan todos loscomponentes de todas las capas.

45

PRUEBAS DE INTEGRACIÓN (3)Pruebas de arriba hacia abajo

Prueba primero en forma unitaria los componentes de la p pcapa superior y luego integra los componentes de la siguiente capa hacia abajo.

Pruebas de emparedadoCombina las estrategias de arriba hacia abajo y de abajo hacia arriba, tratando de usar lo mejor de ambas.

PCPM

46

5/10/2007

24

EJEMPLO DE DESCOMPOSICIÓNJERÁRQUICA

PCPM

47

ESTRATEGIA DE PRUEBAS DEEMPAREDADO

PCPM

Ninguno de los componentes de la capa de destino (B,C,D) fueron probados en forma unitaria

48

5/10/2007

25

ESTRATEGIA DE PRUEBAS DEEMPAREDADO MODIFICADAS

Ventaja: Pruebas en paralelop

Desventaja: Necesidad de Stubs y Manejadores de Prueba adicionales

Conducen a un tiempo de prueba general significativamente más corto.

PCPM

49

PRUEBAS DEL SISTEMA (1)Una vez se han integrado los componentes, y corregido los errores encontrados en las pruebas corregido los errores encontrados en las pruebas de integración, es posible ahora integrar todo el sistema. El propósito de las pruebas del sistema es asegurar que el sistema completo se apegue a los requerimientos funcionales y no funcionales del sistema

PCPM

sistema

50

5/10/2007

26

PRUEBAS DEL SISTEMA (2)Actividades que se realizan:

Prueba Funcional

PRUEBAS DE ESFUERZO

Revisan si el sistema puede responder a muchas peticiones

simultáneas.

PRUEBAS DE Encuentra diferencias entre los requerimientos

funcionales y el sistema.

Prueba de desempeñoEncuentra diferencias entre los objetivos de

diseño seleccionados durante el diseño del sistema y el sistema.

PRUEBAS DE VOLUMEN

Tratan de encontrar defectos asociados con grandes cantidades de

datos.

PRUEBA DE SEGURIDAD

Tratan de encontrar fallas de seguridad en g

el sistema.

PRUEBAS DE TEMPORIZACIÓNTratan de encontrar comportamientos

que violan las restricciones de temporización descritas por los requerimientos no funcionales.

PRUEBAS DE RECUPERACIÓN:

Evalúan la habilidad del sistema para

recuperarse de errores. 51

PCPM

PRUEBAS DEL SISTEMA (3)Prueba Piloto (Prueba de Campo)

Prueba la funcionalidad común entre un grupo seleccionado d i fi l l bi t d d tide usuarios finales en el ambiente de destino.

Prueba Alfa: Los usuarios ejercitan el sistema en un ambiente de desarrollo.Prueba Beta: Una cantidad limitada de usuario finales realiza la prueba de aceptación en el ambiente de destino.

52

PCPM

5/10/2007

27

PRUEBAS DEL SISTEMA (4)Prueba de Aceptación

El cliente es el encargado de evaluar el sistema.

PRUEBA CONSISTE EN…PRUEBA PATRÓN El cliente prepara un conjunto de casos

de prueba que representan condicionestípicas bajo las cuales debe operar elsistema.

PRUEBAS COMPETIDORAS

Se prueba el nuevo sistema frente a unsistema existente o producto competidor.

PCPM

COMPETIDORAS s s e a e s e e o p o c o co pe o .

PRUEBAS DE SOMBRA Una forma de pruebas de comparación,se ejecutan en paralelo los sistemasnuevo heredado y se comparan sussalidas. 53

PRUEBAS DEL SISTEMA (5)

Prueba de instalación

Pruebas de usabilidad yde desempeño realizadaspor el cliente contracriterios de aceptación(del acuerdo del proyecto)en el ambiente dedestino.

PCPM

54

5/10/2007

28

ADMINISTRACIÓNDE LAS PRUEBASPC

PM

55

ADMINISTRACIÓN DE LAS PRUEBAS

Los desarrolladores deben detectar y reparar una cantidad de defectos suficientes para que el cantidad de defectos suficientes para que el sistema satisfaga los requerimientos funcionales y no funcionales en una amplitud aceptable por el cliente.

Planeación de las Pruebas.Documentación de las Pruebas.

Plan de Pruebas.

PCPM

Especificación de los casos de pruebas.Reportes de inicidentes de pruebas.Reporte de resumen de pruebas.

Asignación de responsabilidades.56

5/10/2007

29

BIBLIOGRAFÍA

[1] Ingeniería de Software Orientado a Objetos, Bruegge, Bernd [2] Ingeniería de Software Sommerville Ian 1951[2] Ingeniería de Software Sommerville, Ian, 1951[3] Ingeniería del Software: Un enfoque práctico Pressman, Roger S. [4] Diapositivas Clase Ingeniería de Software 2006[5] Conceptos Fundametales de ITIL e ISO 20000 – ACIS, Marzo de 2007[6]http://lml.ls.fi.upm.es/ftp/ed2/0203/Apuntes/pruebas.ppt[7] Modelo para Pruebas de Software,

http://www.monografias.com/trabajos20/pruebas-de-software/pruebas-de-software.shtml

[8] Pruebas de Software, http://www.monografias.com/trabajos20/pruebas-de-ft / b d ft ht l

PCPM

software/pruebas-de-software.shtml[9] Pruebas de Software, http://es.wikipedia.org/wiki/Pruebas_de_software[11] http://msdn2.microsoft.com/en-us/library/ms182515(VS.80).aspx[12] Probando Software, http://www.dcc.uchile.cl/~rbaeza/inf/testeo.html

57

PCPM

MUCHAS GRACIAS!58