PRUEBAS DE SOFTWARE - sophia.javeriana.edu.colcdiaz/ingSw2007-1/EXP_Pruebas... · ¾Test Manager...
Transcript of PRUEBAS DE SOFTWARE - sophia.javeriana.edu.colcdiaz/ingSw2007-1/EXP_Pruebas... · ¾Test Manager...
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