Está en la página 1de 84

Tema 9. Pruebas del Software 1. Definiciones asociadas 2. El proceso de prueba 3. Tcnicas de diseo de casos de prueba 4. Pruebas estructurales 5.

Pruebas funcionales 6. Pruebas aleatorias 7. Enfoque prctica de diseo de casos 8. Documentacin del diseo de pruebas 9. Ejecucin de pruebas 10. Estrategia de aplicacin de pruebas en el ciclo de vida

PRUEBAS DEL SOFTWARE 12.005 Cuando ya dispongamos del cdigo ejecutable de la aplicacin Ciclo de vida Activid. Activid. Activ. software Pruebas . 1 2 N-1 Controles Todo Sistema debe haber sido probado Pretenden una evaluacin de exhaustivamente a travs de una ejecucin la calidad de los productos controlada antes de ser entregado al generados cliente ......... ........

PRUEBAS DEL SOFTWARE 12.010 Verificacin: El proceso de evaluacin de un sistema (o de uno de sus componentes para determinar si los productos de una fase dada satisfacen las condiciones impuestas al comienzo de dicha fase Estamos construyendo correctamente Estamos el producto? construyendo el producto correcto? Validacin: El proceso de evaluacin de un sistema o de uno de sus componentes durante o al final del proceso de desarrollo para determinar si satisface los requisitos marcados por el usuario

PRUEBAS DEL SOFTWARE 12.020 Proceso de ejecutar un programa con el fin de encontrar errores Instruccin incorrecta DEFI DEFIDEFINI NINICI CICIONES ONESONES ..Pruebas (test): una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluacin de algn aspecto ..Caso de prueba (test case): un conjunto de entradas, condiciones de ejecucin y resultados esperados desarrollados para un objetivo particular ..Defecto (defect, fault, bug): un defecto en el software como, por ejemplo, un proceso, una definicin de datos o un paso de procesamiento incorrectos en un programa

PRUEBAS DEL SOFTWARE 12.030 DEFI DEFIDEFINI NINICI CICIONES ONESONES Fallo (failure): La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados Error (error): tiene varias acepciones: ..La diferencia entre un valor calculado, observado o medio y Fallo el valo verdadero, especificado o tericamente correcto. Defecto

Un defecto Fallo ..Un resultado incorrecto ..Una accin humana que conduce a un resultado incorrecto . Error

2 + 2 = 5 Error Defecto (calidad) Xyx// ??? Sistema de gestin de aeropuerto S.Aproximacin Accidente (seguridad) Equivocacindel programador 2 + 2 = 5 Error Defecto (calidad) Xyx// ??? Sistema de gestin de aeropuerto S.Aproximacin Accidente (seguridad) Equivocacindel programador PRUEBAS DEL SOFTWARE 12.040 REL RELRELA AACION E CION ECION EN NNT TTR RRE ERROR, DEFECTO Y FALLO E ERROR, DEFECTO Y FALLOE ERROR, DEFECTO Y FALLO Fallo (fiabilidad) Error Defecto Da lugar a Fallo Efectos negativosQue provoca (del programador) (en el software) (el sistema no se (dependiendo de la comporta como debera) criticidad del sistema) Se Plasma

PRUEBAS DEL SOFTWARE IDEAS P IDEAS PIDEAS PARADGICAS DE LAS PRUEBAS ARADGICAS DE LAS PRUEBASARADGICAS DE LAS PRUEBAS La prueba exhaustiva del software es impracticable (no se pueden probar todas las posibilidades de su funcionamiento ni siquiera en programas sencillos El objetivo de las pruebas es la deteccin de defectos en el software (descubrir un error es el xito de una prueba) ..Mito un defecto implica que somos malos profesionales y que debemos sentirnos culpables todo el mundo comete errores El descubrimiento de un defecto significa un xito para la mejora de la calidad

PRUEBAS DEL SOFTWARE 12.050 RECOMENDACIONES PARA UNAS PRUEBAS EXITOSAS RECOMENDACIONES PARA UNAS PRUEBAS EXITOSASRECOMENDACIONES PARA UNAS PRUEBAS EXIT OSAS Cada caso de prueba debe definir el resultado de salida esperado que se comparar con el realmente obtenido. El programador debe evitar probar sus propios programas, ya que desea (consciente o inconscientemente) demostrar que funcionan sin problemas. Adems, es normal que las situaciones que olvid considerar al crear el programa queden de nuevo olvidados al crear los casos de prueba Se debe inspeccionar a conciencia el resultado de cada prueba, as, poder descubrir posibles sntomas de defectos. Al generar casos de prueba, se deben incluir tanto datos de entrada vlidos y esperados como no vlidos e inesperados.

PRUEBAS DEL SOFTWARE 12.060 RECOMENDACIONES PARA UNAS PRUEBAS EXITOSAS RECOMENDACIONES PARA UNAS PRUEBAS EXITOSASRECOMENDACIONES PARA UNAS PRUEBAS EXIT OSAS Las pruebas deben centrarse en dos objetivos (es habitual olvidar el segundo) : ..Probar si el software no hace lo que debe hacer ..Probar si el software hace lo que debe hacer, es decir, si provoca efectos secundarios adversos ..Se deben evitar los casos desechables, es decir, los no documentados ni diseados con cuidado. Ya que suele ser necesario probar muchas veces el software y por tanto hay que tener claro qu funciona y qu no ..No deben hacerse planes de prueba suponiendo que, prcticamente, no hay defectos en los programas y, por lo tanto, dedicando pocos recursos a las pruebas ........siempre hay defectos

PRUEBAS DEL SOFTWARE 12.070 RECOMENDACIONES PARA UNAS PRUEBAS EXITOSAS RECOMENDACIONES PARA UNAS PRUEBAS EXITOSASRECOMENDACIONES PARA UNAS PRUEBAS EXIT OSAS La experiencia parece indicar que donde hay un defecto hay otros, es decir, la probabilidad de descubrir nuevos defectos en una parte del software es proporcional al nmero de defectos ya descubierto. ..Las pruebas son una tarea tanto o ms creativa que el desarrollo de software. Siempre se han considerado las pruebas como una tarea destructiva y rutinaria. Es interesante planificar y disear las pruebas para poder detectar el mximo nmero y variedad de defectos con el mnimo consumo de tiempo y esfuerzo

PRUEBAS DEL SOFTWARE CI CICICLO COMPLETO DE LAS P CLO COMPLETO DE LAS PCLO COMPLETO DE LAS PR RRUEBAS UEBASUEBAS

PRUEBAS DEL SOFTWARE PROCESO DE PRUEBA PROCESO DE PRUEBAPROCESO DE PRUEBA ACTIVIDAD ACTIVIDADACTIVIDADES ESES La depuracin (localizacin y correccin de defectos) El anlisis de la estadstica de errores Sirve para realizar predicciones de la fiabilidad del software y para detectar las causas ms habituales de error y por tanto mejorar los procesos de desarrollo

PRUEBAS DEL SOFTWARE 12.100 ENFOQUE ENFOQUEENFOQUES SS DE DI DE DIDE DISE SESEO DE P O DE PO DE PR RRUEB UEBUEBA AAS SS Existen tres enfoques principales para el diseo de casos: 1.-El enfoque estructural o de caja blanca. Se centra en la estructura interna del programa (analiza los caminos de ejecucin). 2.-El enfoque funcional o de caja negra. Se centra en las funciones, entradas y salidas. 3.-El enfoque aleatorio consiste en utilizar modelos (en muchas ocasiones estadsticos) que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba

PRUEBAS DEL SOFTWARE 12.110 LOS ENFOQUES DE DIS LOS ENFOQUES DE DISLOS ENFOQUES DE DISE EEO DE PRUEB O DE PRUEBO DE PRUEBA AAS SS DE CAJA BLANCA Y DE CAJA NEGRA DE CAJA BLANCA Y DE CAJA NEGRADE CAJA BLANCA Y DE CAJA NEGRA Caja blanca Entrada Salida Estructural Caja negra Funcional Entrada Salida Funciones

PRUEBAS DEL SOFTWARE 12.120 PR PRPRUEBA UEBAUEBAS ESTRU S ESTRUS ESTRUC CCTUR TURTURA AALES LESLES GRAFO DE FLUJO DE UN PROGRAMA GRAFO DE FLUJO DE UN PROGRAMAGRAFO DE FLUJO DE UN PROGRAMA (PSEUDOCODI (PSEUDOCODI(PSEUDOCODIGO) GO)GO) El diseo de casos de prueba tiene que estar basado en la eleccin de caminos importantes que ofrezcan una seguridad aceptable 1 2 4 3 6 5 12,13 7a 7b 8,9 10,11 Abrir archivos; Leer archivo ventas, al final indicar no ms registros; Limpiar lnea de impresin; WHILE (haya registros ventas) DO Total nacional = 0; Total extranjero = 0; WHILE (haya reg. ventas) y (mismo producto) IF (nacional) THEN Sumar venta nacional a total nacional ELSE Sumar venta extranjero a total extranjero ENDIF; Leer archivo ventas, al final indicar no ms registros; ENDWHILE; Escribir lnea de listado; Limpiar rea de impresin; ENDWHILE; Cerrar archivos. de que se descubren defectos (un programa de 50 lneas con 25 sentencias if en ser

ie da lugar a 33,5 millones de secuencias posibles), para lo que se usan los criterios de cobertura lgica.

PRUEBAS DEL SOFTWARE 12.130 PR PRPRUEBA UEBAUEBAS ESTRU S ESTRUS ESTRUC CCTUR TURTURA AALES LESLES GRAFO DE FLUJO DE LAS ESTRUCT GRAFO DE FLUJO DE LAS ESTRUCTGRAFO DE FLUJO DE LAS ESTRUCTURA URAURAS SS BASICAS DE BASICAS DEBASICAS DE PROGRAMAPROGRAMA x x x Hacer... hasta x Secuencia Si x entonces... Mientras x hacer... (Do...until x) (If x then...else...) (While x do...) Repetir Consejos: -Separar todas las condiciones -Agrupar sentencias simples en bloques -Numerar todos los bloques de sentencias y tambin las condiciones

PRUEBAS DEL SOFTWARE 12.140 Menos riguroso PR PRPRUEBA UEBAUEBAS ESTRU S ESTRUS ESTRUC CCTUR TURTURA AALES LESLES (ms barato) CRITER CRITERCRITERIOS DE COBERTURA LGICA IOS DE COBERTURA LGICAIOS DE COBERTURA LGICA Cobertura de sentencias. Se trata de generar los casos de prueba necesarios para que cada sentencia o instruccin del programa se ejecute al menos una vez. Cobertura de decisiones. Consiste en escribir casos suficientes para que cada decisin tenga, por lo menos una vez, un resultado verdadero y, al menos una vez, uno falso. (Incluye a la cobertura de sentencias) Cobertura de condiciones. Se trata de disear tantos casos como sea necesario para que cada condicin de cada decisin adopte el valor verdadero al menos una vez y el falso al menos una vez. (No incluye cobertura de condiciones) Criterio de decisin/condicin. Consiste en exigir el criterio de cobertura de condiciones obligando a que se cumpla tambin el criterio de decisiones. Criterio de condicin mltiple. En el caso de que se considere que la evaluacin de las condiciones de cada decisin no se realiza de forma simultnea, se puede considerar que cada decisin multicondicional se descompone en varias condiciones unicondicionales. Ejemplo en la siguiente diapositiva. Criterio de cobertura de caminos. Se recorren todos los caminos (impracticable) Ms riguroso (ms caros)

PRUEBAS DEL SOFTWARE PR PRPRUEBA UEBAUEBAS ESTRU S ESTRUS ESTRUC CCTUR TURTURA AALES LESLES EJEMPLO DE EJEMPLO DEEJEMPLO DE DESCOMPOSICION DE UNA DESCOMPOSICION DE UNADESCOMPOSICION DE UNADECIS DECISDECISI IION MULTICOND ON MULTICONDON MULTICONDIC ICICIONAL IONALIONAL (a=1)and(c=4) thenelsethenelse(a=1)(c=4)

PRUEBAS DEL SOFTWARE 12.160 PR PRPRUEBA UEBAUEBAS ESTRU S ESTRUS ESTRUC CCTUR TURTURA AALES LESLES LA COMPLEJIDAD DE LA COMPLEJIDAD DELA COMPLEJIDAD DE McCABE McCABEMcCABE V(G) (COMPLEJIDAD CICLOMTIC V(G) (COMPLEJIDAD CICLOMTICV(G) (COMPLEJIDAD CICLOMTICA) A)A) ..La mtrica de McCabe ha sido muy popular en el diseo de pruebas ..Es un indicador del nmero de caminos independientes que existen en un grafo 1. V (G) = a -n + 2, siendo a el nmero de arcos o aristas La complejidad de del grafo y n el nmero de nodos. McCabe se puede 2. V (G) = r, siendo r el nmero de regiones cerradas del calcular de cualquiera de estas 3 grafo. formas 3. V(G) = c + 1, siendo c el nmero de nodos de condicin.

PRUEBAS DEL SOFTWARE 12.165 PR PRPRUEBA UEBAUEBAS ESTRU S ESTRUS ESTRUC CCTUR TURTURA AALES LESLES LA COMPLEJIDAD DE LA COMPLEJIDAD DELA COMPLEJIDAD DE McCABE McCABEMcCABE V(G) V(G)V(G) El criterio de prueba de McCabe es: Elegir tantos casos de prueba como caminos independientes (calculados como V(G)) La experiencia en este campo asegura que: V(G) marca el lmite mnimo de casos de prueba para un programa Cuando V(G) > 10 la probabilidad de defectos en el mdulo o programa crece mucho quizs sea interesante dividir el mdulo

PRUEBAS ESTRUCTURALESPRUEBAS ESTRUCTURALES CALCULO DE LA COMPLEJIDAD CICLOMATICA SOBRE UN GRAFOCALCULO DE LA COMPLEJIDAD CI CLOMATICA SOBRE UN GRAFO 12436511 8 910 a1 a3 a4a5 a7 a8a10 a11 a12 a13 a14 Regin 4 Regin 3 Regin 1 12436511 8 910 a1 a3 a4a5 a7 a8a10 a11 a12 a13 a14 Regin 4 Regin 3 Regin 1 a2 a6 Regin 2 a9 Regin 5 7 PRUEBAS DEL SOFTWARE 12.170 a) V(G) = 14-11+2 = 5b) V(G) = 5 regiones cerradasc) V(G) = 5 condiciones

PRUEBAS DEL SOFTWARE 12.180 PRUEBAS FUNCIONALES PRUEBAS FUNCIONALESPRUEBAS FUNCIONALES Se centran en las funciones, entradas y salidas Es impracticable probar el software para todas las posibilidades. De nuevo hay que tener criterios para elegir buenos casos de prueba Un c Un cUn ca aaso de so deso de pr prpru uue eeba func ba funcba funcional es bie ional es bieional es bien nn e eel lle eeg ggido si se ido si seido si se c ccu uumple mple quemple que: :: Reduce el nmero de otros casos necesarios para que la prueba sea razonable. Esto implica que el caso ejecute el mximo nmero de posibilidades de entrada diferentes para as reducir el total de casos. Cubre un conjunto extenso de otros casos posibles, es decir, no indica algo acerca de la ausencia o la presencia de defectos en el conjunto especfico de entradas que prueba, as como de otros conjuntos similares.

PRUEBAS DEL SOFTWARE 12.190 Cualidades que definen un buen caso de prueba PRUEBAS FUNCIONALES PRUEBAS FUNCIONALESPRUEBAS FUNCIONALES TCNIC TCNICTCNICA AA: PARTICIPA : PARTICIPA: PARTICIPAC CCIO IOIONES O CLASES DE EQUIVA NES O CLASES DE EQUIVANES O CLASES DE EQUIVALENCIA LENCIALENCIA Cada caso debe cubrir el mximo nmero de entradas Debe tratarse el dominio de valores de entrada dividido en un nmero finito de clases de equivalencia que cumplan la siguiente propiedad: la prueba de un valor representativo de una clase permite suponer razonablemente que el resultado obtenido (existan defectos o no) ser el mismo que el obtenido probando cualquier otro valor de la clase Identificar clases de equivalencia Lo que hay que hacer es: Crear casos de prueba correspondiente

PRUEBAS DEL SOFTWARE 12.200 PRUEBAS FUNCIONALES PRUEBAS FUNCIONALESPRUEBAS FUNCIONALES PARTICIPA PARTICIPAPARTICIPAC CCI IIO OONES O CLASES DE EQUIVALENCI NES O CLASES DE EQUIVALENCINES O CLASES DE EQUIVALENCIA AA PASOS PASOSPASOS PARA IDENTIFICAR CLASES DE EQUIVALENCI PARA IDENTIFICAR CLASES DE EQUIVALENCIPARA IDENTIFICAR CLASES DE EQUIVALENCIA AA 1. Identificacin de las condiciones de las entradas del programa, es decir, restricciones de formato o contenido de los datos de entrada 2. A partir de ellas, se identifican clases de equivalencia que pueden ser: a) De datos vlidos b) De datos no vlidos o errneos 3. Existen algunas reglas que ayudan a identificar clase: a) Si se especifica un rango de valores para los datos de entrada, secrear una cl ase vlida y dos clases no vlidas b) Si se especifica un nmero finito y consecutivo de valores, se crear una clase vl ida y dos no vlidas

PRUEBAS DEL SOFTWARE PRUEBAS FUNCIONALES PRUEBAS FUNCIONALESPRUEBAS FUNCIONALES PARTICIPA PARTICIPAPARTICIPAC CCI IIO OONES O CLASES DE EQUIVALENCI NES O CLASES DE EQUIVALENCINES O CLASES DE EQUIVALENCIA AA PASOS PASOSPASOS PARA IDENTIFICAR CLASES DE EQUIVALENCI PARA IDENTIFICAR CLASES DE EQUIVALENCIPARA IDENTIFICAR CLASES DE EQUIVALENCIA AA c) Si se especifica una situacin del tipo debe ser o booleana (por ejemplo, el primer carcter debe ser una letra), se identifican una clase vlida (es una letra) y una no vlida (no es una letra) d) Si se especifica un conjunto de valores admitidos y se sabe que el programa trata de forma diferente cada uno de ellos, se identifica una clase vlida por cada valor y una no vlida e) En cualquier caso, si se sospecha que ciertos elementos de una clase no se tratan igual que el resto de la misma, deben dividirse en clases menores

PRUEBAS DEL SOFTWARE 12.220 PRUEBAS FUNCIONALES PRUEBAS FUNCIONALESPRUEBAS FUNCIONALES PARTICIPA PARTICIPAPARTICIPAC CCI IIO OONES O CLASES DE EQUIVALENCI NES O CLASES DE EQUIVALENCINES O CLASES DE EQUIVALENCIA AA PASOS PASOSPASOS PARA IDENTIFICAR CA PARA IDENTIFICAR CAPARA IDENTIFICAR CASOS DE PRUEBA SOS DE PRUEBASOS DE PRUEBA El ltimo paso del mtodo es el uso de las clases de equivalencia para identificar l os casos de prueba correspondientes. Este proceso consta de las siguientes fases: Asignacin de un nmero nico a cada clase de equivalencia Hasta que todas las clases de equivalencia vlidas hayan sido cubiertas por (incorporadas a) casos de prueba, se tratar de escribir un caso que cubra tantas clases vlidas no incorporadas como sea posible Hasta que todas las clases de equivalencia no vlidas hayan sido cubiertas por casos de prueba, escribir un caso para una nica clase no vlida sin cubrir

PRUEBAS DEL SOFTWARE PRUEBAS FUNCIONALES PRUEBAS FUNCIONALESPRUEBAS FUNCIONALES TABLA DE CLASES DE EQUIVALENCIA DEL EJEMPL TABLA DE CLASES DE EQUIVALENCIA DEL EJEMPLTABLA DE CLASES DE EQUIVALENCIA DEL EJ EMPLO OO Ejemplo: Aplicacin bancaria en la que el operador debe proporcionar un cdigo, un nombre y una operacin Condicin de entrada Clases vlidas Clases invlidas Cdigo rea (1) 200 =cdigo =999 (2) cdigo <200 N de 3 dgitos que no (3) cdigo >999 empieza con 0 ni 1) (4) no es nmero Nombre para identificar la (5) seis caracteres (6) menos de 6 caracteres operacin (7) ms de 6 caracteres Orden (8) cheque (12) ninguna orden vlida (9) depsito Una de las siguientes (10) pago factura (11) retirada de fondos Habra que disear casos de prueba que cubran todas las clases de equivalencia, tant o vlidas como invlidas, y para las invlidas en casos de prueba distintos

PRUEBAS DEL SOFTWARE 12.240 PRUEBAS FUNCIONALES PRUEBAS FUNCIONALESPRUEBAS FUNCIONALES TCNIC TCNICTCNICA AA: AN : AN: ANALISI ALISIALISIS SS DE VA DE VADE VALORES LIMITE (AVL) LORES LIMITE (AVL)LORES LIMITE (AVL) La experiencia indica que los casos de prueba que exploran las condiciones lmite de un programa producen un mejor resultado para detectar defectos El AVL es una tcnica de diseo de casos de prueba que complementa a la de particiones de equivalencia. Las diferencias son las siguientes: ..Ms que elegir cualquier elemento como representativo de una clase de equivalencia, se requiere la seleccin de uno o ms elementos tal que los mrgenes se sometan a prueba ..Ms que concentrarse nicamente en el dominio de entrada (condiciones de entrada), los casos de prueba se generan considerando tambin el espacio de salida

PRUEBAS DEL SOFTWARE PRUEBAS FUNCIONALES PRUEBAS FUNCIONALESPRUEBAS FUNCIONALES ANALI ANALIANALIS SSIS DE IS DEIS DE VALORES LI VALORES LIVALORES LIMITE (AVL) MITE (AVL)MITE (AVL) LAS LASLAS REGLAS PARA IDENTIFIC REGLAS PARA IDENTIFICREGLAS PARA IDENTIFICAR CLASES SON: AR CLASES SON:AR CLASES SON: 1. Si una condicin de entrada especifica un rango de valores, se deben generar casos para los extremos del rango y casos no vlidos para situaciones justo ms all de los extremos 2. Si la condicin de entrada especifica un nmero finito y consecutivo de valores, hay que escribir casos para los nmeros mximo, mnimo, uno ms del mximo y uno menos del mnimo de valores 3. Usar la regla 1 para la condicin de salida 4. Usar la regla 2 para cada condicin de salida ..Los valores lmite de entrada no generan necesariamente los valores lmite de salida (recurdese la funcin seno, por ejemplo) ..No siempre se pueden generar resultados fuera del rango de salida (pero es interesante considerarlo) 5. Si la entrada o la salida de un programa es un conjunto ordenado, los casos se deben concentrar en el primero y en el ltimo elemento

PRUEBAS DEL SOFTWARE 12.260 PRUEBAS FUNCIONALES PRUEBAS FUNCIONALESPRUEBAS FUNCIONALES TCNIC TCNICTCNICA AA: CONJETURA DE : CONJETURA DE: CONJETURA DE ERRORES ERRORESERRORES Se enumera una lista de posibles equivocaciones tpicas que pueden cometer los desarrolladores y de situaciones propensas a ciertos errores El valor cero es una situacin propensa a error tanto en la salida como en la entrada En situaciones en las que se introduce un nmero variable de valores, conviene centrarse en el caso de no introducir ningn valor y en el de un solo valor. Tambin puede ser interesante un lista que tiene todos los valores iguales Es recomendable imaginar que el programador pudiera haber interpretado algo mal en la especificacin Tambin interesa imaginar lo que el usuario puede introducir como entrada a un programa ...

PRUEBAS DEL SOFTWARE 12.270 PR PRPRUEBA UEBAUEBAS A S AS AL LLEATORIA EATORIAEATORIAS SS En las pruebas aleatorias simulamos la entrada habitual del programa creando datos de entrada en la secuencia y con la frecuencia con las que podran aparecer en la Prctica (de manera repetitiva) Para ello habitualmente se utilizan generadores automticos de casos de prueba

PRUEBAS DEL SOFTWARE 12.280 ENFOQUE ENFOQUEENFOQUE PRACTICO RECOMENDADO PARA PRACTICO RECOMENDADO PARAPRACTICO RECOMENDADO PARAEL DISEO DE CASOS EL DISEO DE CASOSEL DISEO DE CASOS Se propone un uso ms apropiado de cada tcnica (caja blanca y negra) para obtener un conjunto de casos tiles: Si la especificacin contiene combinaciones de condiciones de entrada, comenzar formando sus grafos de causa-efecto (ayudan a la comprensin de dichas combinaciones) En todos los casos, usar el anlisis de valores lmites para aadir casos de prueba: elegir lmites para dar valores a las causas en los casos generados asumiendo que cada causa es una clase de equivalencia Identificar las clases vlidas y no vlidas de equivalencia para la entrada y la salida, y aadir los casos no incluidos anteriormente

PRUEBAS DEL SOFTWARE ENFOQUE ENFOQUEENFOQUE PRACTICO RECOMENDADO PARA PRACTICO RECOMENDADO PARAPRACTICO RECOMENDADO PARAEL DISEO DE CASOS EL DISEO DE CASOSEL DISEO DE CASOS Utilizar la tcnica de conjetura de errores para aadir nuevos casos, referidos a valores especiales Ejecutar los casos generados hasta el momento y analizar la cobertura obtenida Examinar la lgica del programa para aadir los casos precisos (de caja blanca) para cumplir el criterio de cobertura elegido si los resultados de la ejecucin del punto anterior indican que no se ha satisfecho el criterio de cobertura elegido

PRUEBAS DEL SOFTWARE 12.300 Una cuestin importante es por qu son necesarias las pruebas de caja blanca si comprobamos que las funciones se realizan correctamente? Los errores lgicos y las suposiciones incorrectas son inversamente proporcionales a la probabilidad de que se ejecute un camino del programa ( a menor probabilidad de ejecutarse un camino, mayor nmero de errores) Se suele creer que un determinado camino lgico tiene pocas posibilidades de ejecutarse cuando, de hecho, se puede ejecutar regularmente Los errores tipogrficos son aleatorios; pueden aparecer en cualquier parte del programa (sea muy usada o no) La probabilidad y la importancia de un trozo de cdigo suele ser calculada de forma muy subjetiva No obstante las pruebas de caja blanca slas tampoco garantizan el xito: if (x+y+z)/3=x then print (x,y y z son iguales) else print (x,y y z no son igual es) Una prueba de caja blanca como esta x=5 y=5 z=5 x=2 y=3 z=7^12 No detecta el error lgico, que si sera detectado con otro tipo de pruebas funciona les.

PRUEBAS DEL SOFTWARE DOCUMENTOS REL DOCUMENTOS RELDOCUMENTOS RELA AACIONADOS CON E CIONADOS CON ECIONADOS CON EL LL DIDISE SESEO OO D DDE EE LAS PRU LAS PRULAS PRUE EEBA BABAS SEGU S SEGUS SEGUN NN EL ESTAN EL ESTANEL ESTANDAR DARDAR IEEEIEEE stdstd. . 829. 829 Plan de Documentacin Pruebas Especificacinde diseo de las pruebas Especificacinde diseo de las pruebas............... Especificacinde caso de prueba Especificacinde procedimientode pruebas EJECUCIN Informes

PRUEBAS DEL SOFTWARE PLAN DE PRUEBAS PLAN DE PRUEBASPLAN DE PRUEBAS Objetivo del documento Sealar el enfoque, los recursos y el esquema de actividades de prueba, as como los elementos a probar, las caractersticas, las actividades de prueba, el personal responsable y los riesgos asociados

PRUEBAS DEL SOFTWARE PLAN DE PRUEBAS PLAN DE PRUEBASPLAN DE PRUEBAS Estructura fijada en el estndar 1. Identificador nico del documento 2. Introduccin y resumen de elementos y caractersticas a probar 3. Elementos software a probar 4. Caractersticas a probar 5. Caractersticas que no se probarn 6. Enfoque general de la prueba 7. Criterios de paso/fallo para cada elemento 8. Criterios de suspensin y requisitos de reanudacin 9. Documentos a entregar 10. Actividades de preparacin y ejecucin de pruebas 11. Necesidades de entorno 12. Responsabilidades en la organizacin y realizacin de las pruebas 13. Necesidades de personal y formacin 14. Esquema de tiempos 15. Riesgos asumidos por el plan y planes de contingencias 16. Aprobaciones y firmas con nombre y puesto desempeado

PRUEBAS DEL SOFTWARE ESPECIFICACION DEL DISEO DE PRUEBAS ESPECIFICACION DEL DISEO DE PRUEBASESPECIFICACION DEL DISEO DE PRUEBAS Objetivo del documento Especificar los refinamientos necesarios sobre el enfoque general reflejado en el plan e identificar las caractersticas que se deben probar con este diseo de pruebas

PRUEBAS DEL SOFTWARE ESPECIFICACION DEL DISEO DE PRUEBAS ESPECIFICACION DEL DISEO DE PRUEBASESPECIFICACION DEL DISEO DE PRUEBAS Estructura fijada en el estndar Identificador nico para la especificacin. Proporcionar tambin una referencia del plan asociado (si existe) Caractersticas a probar de los elementos software (y combinaciones de caractersticas) Detalles sobre el plan de pruebas del que surge este diseo, incluyendo las tcnicas de prueba especfica y los mtodos de anlisis de resultados Identificacin de cada prueba: identificador casos que se van a utilizar procedimientos que se van a seguir Criterios de paso/fallo de la prueba (criterios para determinar si una caracterstica o combinacin de caractersticas ha pasado con xito la prueba o no)

PRUEBAS DEL SOFTWARE 12.360 ESPECIFICACION DE CASO DE PRUEBA ESPECIFICACION DE CASO DE PRUEBAESPECIFICACION DE CASO DE PRUEBA Objetivo del documento Definir uno de los casos de prueba identificando por una especificacin del diseo de las pruebas

PRUEBAS DEL SOFTWARE ESPECIFICACION DE CASO DE PRUEBA ESPECIFICACION DE CASO DE PRUEBAESPECIFICACION DE CASO DE PRUEBA Estructura fijada en el estndar Identificador nico de la especificacin Elementos software (por ejemplo, mdulos) que se van a probar: definir dichos elementos y las caractersticas que ejercitar este caso Especificaciones de cada entrada requerida para ejecutar el caso (incluyendo las relaciones entre las diversas entradas; por ejemplo, la sincronizacin de las mismas) Especificaciones de todas las salidas y las caractersticas requeridas (por ejemplo, el tiempo respuesta) para los elementos que se van a probar Necesidades de entorno (hardware, software y otras como, por ejemplo, el personal) Requisitos especiales de procedimiento (o restricciones especiales en los procedimientos para ejecutar este caso). Dependencias entre casos (por ejemplo, listar los identificadores de los casos que se van a ejecutar antes de este caso de prueba)

PRUEBAS DEL SOFTWARE 12.380 ESPE ESPEESPECIFI CIFICIFICACION DE PROCE CACION DE PROCECACION DE PROCED DDIMIE IMIEIMIENT NTNTO OODE P DE PDE PR RRUEB UEBUEBA AA Objetivo del documento Especificar los pasos para la ejecucin de un conjunto de casos de prueba o, ms generalmente, los pasos utilizados para analizar un elemento software con el propsito de evaluar un conjunto de caractersticas del mismo

PRUEBAS DEL SOFTWARE ESPE ESPEESPECIFI CIFICIFICACION DE PROCE CACION DE PROCECACION DE PROCED DDIMIE IMIEIMIENT NTNTO OODE P DE PDE PR RRUEB UEBUEBA AA Estructura fijada en el estndar Identificador nico de laespecificacin y referencia a la correspondiente especificacin de diseo deprueba Objetivo del procedimiento y lista de casos que se ejecutan conl Requisitos especiales para la ejecucin (por ejemplo, entorno especial personal especial) Pasos en el procedimiento. Adems de la manera deregistrarlosresultados y los incidentes de laejecucin, se debe especificar: La secuencia necesaria de acciones para preparar la ejecucin Acciones necesarias para empezar la ejecucin Acciones necesarias durante la ejecucin Cmo se realizarn las medidas ( por ejemplo, el tiempo de respuesta) Acciones necesarias para suspender la prueba (cuando los acontecimientos no previstos lo obliguen) Puntos parareinicio de la ejecucin y acciones necesarias parael reinicio en estos puntos Acciones necesarias para detenerordenadamente la ejecucin Acciones necesarias pararestaurar el entorno y dejarlo en la situacin existente a ntes de las pruebas Acciones necesarias para tratar los acontecimientos anmalos

PRUEBAS DEL SOFTWARE PROCESO DE PRUEBAS, TRAS EL DISEO DE PROCESO DE PRUEBAS, TRAS EL DISEO DEPROCESO DE PRUEBAS, TRAS EL DISEO DECASOS, SEG UN EL ESTANDAR IEEE 1008 CASOS, SEGUN EL ESTANDAR IEEE 1008CASOS, SEGUN EL ESTANDAR IEEE 1008 1.EJECUTAR

3.PRUEBAS ADICIONALES 2.COMPROBAR SI TERMIN LA PRUEBA

3.EVALUAR RESULTADOS

PRUEBAS DEL SOFTWARE 12.410 DETALLES DEL P DETALLES DEL PDETALLES DEL PR RROCESO OCESOOCESO EJECUT EJECUTEJECUTA AAR RR EJECUTAR PRUEBAS DEPURAR DEPURACIN DELLAS ALGUN FALLO? DEFECTOS SOFTWARE Si CDIGO PRUEBAS Si DEFECTOS EN LAS No PRUEBAS COMPROBAR TERMINACIN

PRUEBAS DEL SOFTWARE 12.420 DETALLES DEL P DETALLES DEL PDETALLES DEL PR RROCESO DE COMPROBACION OCESO DE COMPROBACIONOCESO DE COMPROBACIONDE L DE LDE LA AA TE TETERMINACI RMINACIRMINACIO OON DE L N DE LN DE LA AAS PRUE S PRUES PRUEBAS BASBAS PRUEBAS ADICIONALES EJECUCIN CONDICIONES ANORMALES Pruebas adicionales? No Si EVALUACIN TERMINACIN ANORMAL No Criterios de complecin descritos en el plan de pruebas TERMINACIN NORMAL

PRUEBAS DEL SOFTWARE 12.430 DOCUMENT DOCUMENTDOCUMENTACION REL ACION RELACION RELA AACIONADA CON L CIONADA CON LCIONADA CON LA AA EJEJE EEC CCUCION UCIONUCIOND DDE EE LAS PRU LAS PRULAS PRUE EEBA BABAS SEGU S SEGUS SEGUN NN EL ESTAN EL ESTANEL ESTANDAR DARDAR IEEE 829IEEE 829 Especificacin Casos de las pruebas procedimientos EJECUCIONHistricodepruebasInformedeincidenteHistricodepruebasInformedeincidenteSe pueden distinguir histricos, incidencias y resmenes Ejecucin Ejecucin Informe Resmen

PRUEBAS DEL SOFTWARE HISTORICO DE PRUEBAS HISTORICO DE PRUEBASHISTORICO DE PRUEBAS Objetivo El histrico de pruebas (test log) documenta todos los hechos relevantes ocurridos durante la ejecucin de las pruebas

PRUEBAS DEL SOFTWARE HISTORICO DE PRUEBAS HISTORICO DE PRUEBASHISTORICO DE PRUEBAS Estructura fijada en el estndar: Identificador Descripcin de la prueba: elementos probados y entorno de la prueba Anotacin de datos sobre cada hecho ocurrido (incluido el comienzo y el final de la prueba) Fecha y hora Identificador de informe de incidente Otras informaciones

PRUEBAS DEL SOFTWARE INFORME DE I INFORME DE IINFORME DE IN NNCI CICIDENT DENTDENTE EE Objetivo: El informe de incidente (test incident report) documenta cada incidente (por ejemplo, una interrupcin en las pruebas debido a un corte de electricidad, bloqueo del teclado, etc.) ocurrido en la prueba y que requiera una posterior investigacin.

PRUEBAS DEL SOFTWARE 12.470 INFORME DE I INFORME DE IINFORME DE IN NNCI CICIDENT DENTDENTE EE Estructura fijada en el estndar: Identificador Resumen del incidente Descripcin de datos objetivos (fecha/hora, entradas, resultados esperados, etc) Impacto que tendr sobre las pruebas

PRUEBAS DEL SOFTWARE INFORME RE INFORME REINFORME RESUME SUMESUMEN DE P N DE PN DE PR RRUE UEUEBAS BASBAS Objetivo: El informe resumen (test summary report) resume los resultados de las actividades de prueba (las sealadas en el propio informe) y aporta una evaluacin del software basada en dichos resultados

PRUEBAS DEL SOFTWARE INFORME RE INFORME REINFORME RESUME SUMESUMEN DE L N DE LN DE LA AAS P S PS PR RRUEB UEBUEBA AAS SS Estructura fijada en el estndar: Identificador Resumen de la evaluacin de los elementos probados Variaciones del software respecto a su especificacin de diseo, as como las variaciones en las pruebas Valoracin de la extensin de la prueba (cobertura lgica, funcional, de requisitos, etc.) Resumen de los resultados obtenidos en las pruebas Evaluacin de cada elemento software sometido a prueba (evaluacin general del software incluyendo las limitaciones del mismo) Firmas y aprobaciones de quienes deban supervisar el informe

PRUEBAS DEL SOFTWARE 12.500 REL RELRELA AACION E CION ECION EN NNT TTR RRE LAS PRUE E LAS PRUEE LAS PRUEBAS Y LA DEP BAS Y LA DEPBAS Y LA DEPU UURACION RACIONRACION Resultados Casos de prueba Ejecucin Causas ignoradas Correcciones Sntomas de Depuracin defectos Causas (errores) Depuracin: el proceso de analizar y corregir los defectos que se sospecha que contiene el software

PRUEBAS DEL SOFTWARE 12.510 CONS CONSCONSEJOS PARA L EJOS PARA LEJOS PARA LA AA DEP DEPDEPU UURACION RACIONRACION Localizacin del error Analizar la informacin y pensar (analizar bien, en lugar de aplicar un enfoque al eatorio de bsqueda del defecto) Al llegar a un punto muerto, pasar a otra cosa (refresca la mente) Al llegar a un punto muerto, describir el problema a otra persona (el simple hec ho de describir el problema a alguien puede ayudar) Usar herramientas de depuracin slo como recurso secundario (no sustituir el anlisis mental) No experimentar cambiando el programa (no s qu est mal, as que cambiar esto y ver lo que sucede ..NO) Se deben atacar los errores individualmente Se debe fijar la atencin tambin en los datos (no slo en la lgica del programa)

PRUEBAS DEL SOFTWARE CONS CONSCONSEJOS PARA L EJOS PARA LEJOS PARA LA AA DEP DEPDEPU UURACION RACIONRACION Correccin del error Donde hay un defecto, suele haber ms (lo dice la experiencia) Debe fijarse el defecto, no sus sntomas (no debemos enmascarar sntomas, sino corre gir el defecto) La probabilidad de corregir perfectamente un defecto no es del 100% (cuando se c orrige, hay que probarlo) Cuidado con crear nuevos defectos (al corregir defectos se producen otros nuevos ) La correccin debe situarnos temporalmente en la fase de diseo (hay que retocar des de el comienzo, no slo el cdigo) Cambiar el cdigo fuente, no el cdigo objeto

PRUEBAS DEL SOFTWARE 12.530 ANALISI ANALISIANALISIS SS DE E DE EDE ER RRRORE RORERORES O ANALI S O ANALIS O ANALIS SSIS IS CAUSIS CAUSA AAL LL El objetivo del anlisis causal es proporcionar informacin sobre la naturaleza de los defectos. Para ello es fundamental recoger para cada defecto detectado esta informacin: Cundo se cometi? Quin lo hizo Qu se hizo mal? Cmo se podra haber prevenido? Por qu no se detect antes? Cmo se podra haber detectado antes? Cmo se encontr el error? Esta informacin no debera ser usada para evaluar al personal, sino para la formacin del mismo sobre cmo prevenir los errores. Tambin se utiliza para predecir futuros fallos software

PRUEBAS DEL SOFTWARE 12.535 EST ESTESTR RRATE ATEATEG GGIA DE AP IA DE APIA DE APLICACIN DE L LICACIN DE LLICACIN DE LA AAS S PRUEBS PRUEBA AAS SS Se analiza cmo plantear las pruebas en el Ciclo de Vida. La estrategia de pruebas suele seguir estas etapas Comenzar pruebas a nivel de mdulo Continuar hacia la integracin del sistema completo y a su instalacin Culminar con la aceptacin del producto por parte del cliente

PRUEBAS DEL SOFTWARE 12.540 Etapas tpicas ms en detalle EST ESTESTR RRATE ATEATEG GGIA DE AP IA DE APIA DE APLICACIN DE L LICACIN DE LLICACIN DE LA AAS S PRUEBS PRUEBA AAS SS

Se comienza en la prueba de cada mdulo, que normalmente la realiza el propio personal de desarrollo en su entorno Con el esquema del diseo del software, los mdulos probados se integran para comprobar sus interfaces en el trabajo conjunto (prueba de integracin) El software totalmente ensamblado se prueba como un conjunto para comprobar si cumple o no tanto los requisitos funcionales como los requisitos de rendimien tos, seguridad, etc. (prueba funcional o de validacin). El software ya validado se integra con el resto del sistema (por ejemplo, elemen tos mecnicos, interfaces electrnicas, etc.) para probar su funcionamiento conjunto (prueba del sistema) Por ltimo, el producto final se pasa a la prueba de aceptacin para que el usuario compruebe en su propio entorno de explotacin si lo acepta como est o no (prueba de aceptacin)

PRUEBAS DEL SOFTWARE 12.550 REL RELRELA AACION E CION ECION EN NNT TTR RRE PRODUCT E PRODUCTE PRODUCTOS DE DE OS DE DEOS DE DESARROLL SARROLLSARROLLO OOY NIVELES DE PRUEBA Y NIVELES DE PRUEBAY NIVELES DE PRUEBA El usuario comprueba que elsistema hace lo especificado en el contrato Sistema (cumplimiento de objetivos) Validacin (desajustes entre elsoftware y los requisitos) Agrupacin de mdulos Requisitos de usuario Especificac. de requisitos Diseo modular Especific. y lgica de mdulo Cdigo Pruebas de unidad Pruebas de integracin Pruebas de sistema Pruebas de aceptacin Interfaces Lgica de mdulos (caja blanca) Funciones (caja negra) Existe una correspondencia entre cada nivel de prueba y el trabajo realizado en cada etapa del desarrollo

PRUEBAS DEL SOFTWARE 12.560 PRUEBA DE UNIDAD PRUEBA DE UNIDADPRUEBA DE UNIDAD Se trata de las pruebas formales que permiten declarar que un mdulo est listo y terminado (no las informales que se realizan mientras se desarrollan los mdulos) Hablamos de una unidad de prueba para referirnos a uno o ms mdulos que cumplen las siguientes condiciones [IEEE, 1986a] : Todos son del mismo programa Al menos uno de ellos no ha sido probado El conjunto de mdulos es el objeto de un proceso de prueba La prueba de unidad puede abarcar desde un mdulo hasta un grupo de mdulos (incluso un programa completo) Estas pruebas suelen realizarlas el propio personal de desarrollo, pero evitando que sea el propio programador del mdulo

PRUEBAS DEL SOFTWARE 12.570 PRUEB PRUEBPRUEBA AAS DE I S DE IS DE IN NNT TTE EEGRACION GRACIONGRACION Implican una progresin ordenada de pruebas que van desde los componentes o mdulos y que culminan en el sistema completo El orden de integracin elegido afecta a diversos factores, como lo siguientes: La forma de preparar casos Las herramientas necesarias El orden de codificar y probar los mdulos El coste de la depuracin El coste de preparacin de casos

PRUEBAS DEL SOFTWARE 12.580 PRUEB PRUEBPRUEBA AAS DE I S DE IS DE IN NNT TTE EEGRACION GRACIONGRACIONTipos fundamentales de integracin

Integracin incremental. Se combina el siguiente mdulo que se debe probar con el conjunto de mdulos que ya han sido probados ascendente. Se comienza por los mdulos hoja. descendente. Se comienza por el mdulo raz. ..Integracin no incremental. Se prueba cada mdulo por separado y luego se integran todos de una vez y se prueba el programa completo Habitualmente las pruebas de unidad y de integracin se solapan y mezclan en el tiempo.

PRUEBAS DEL SOFTWARE 12.580 INTEGRACIN INCREMENTAL ASCENDENTE INTEGRACIN INCREMENTAL ASCENDENTEINTEGRACIN INCREMENTAL ASCENDENTE El proceso es el siguiente ..Se combinan los mdulos de bajo nivel en grupos que realicen una funcin o subfuncin especfica (o quizs si no es necesario, individualmente) ........de este modo reducimos el nmero de pasos de integracin. ..Se escribe para cada grupo un mdulo impulsor o conductor ........de este modo permitimos simular la llamada a los mdulos, introducir datos de prueba y recoger resultados. ..Se prueba cada grupo mediante su impulsor ..Se eliminan los mdulos impulsores y se sustituyen por los mdulos de nivel superior en la jerarqua.

PRUEBAS DEL SOFTWARE DIS DISDISE EEO MODUL O MODULO MODULAR SOBRE E AR SOBRE EAR SOBRE EL LL QUE SE REAL QUE SE REALQUE SE REALI IIZ ZZA AALA INTEGRACION LA INTEGRACIONLA INTEGRACION Supongamos esta estructura de programa A

B C E F G

PRUEBAS DEL SOFTWARE PRIMERA FASE DE LA I PRIMERA FASE DE LA IPRIMERA FASE DE LA IN NNTEGRACION TEGRACIONTEGRACION AS ASASCENDENTE DEL EJEMPLO CENDENTE DEL EJEMPLOCENDENTE DEL EJEMPLO Se definen los impulsores para nodos hoja y se ejecutan 1 fase Impulsor de E Impulsor de F Impulsor de G Impulsor de D EF GD Pruebas de Unidad

PRUEBAS DEL SOFTWARE 12.610 SEGUNDA Y TE SEGUNDA Y TESEGUNDA Y TERCE RCERCER RRA FASE DE L A FASE DE LA FASE DE LA AA I IIN NNT TTE EEGRACION GRACIONGRACIONAS ASASCENDENTE DEL EJEMPLO CENDENTE DEL EJEMPLOCENDENTE DEL EJEMPLO 2 fase 3 fase Impulsor de E Impulsor de F A B C D B C

E F G E F G

Prueba de unidad de E Prueba de integracin de B con E

PRUEBAS DEL SOFTWARE 12.615 IN ININTEGR TEGRTEGRAC ACACIN ININ INCR INCRINCREMEN EMENEMENTAL D TAL DTAL DE EESC SCSCEND ENDENDE EEN NNT TTE EE Comienza por el mdulo de control principal y va incorporando mdulos subordinados progresivamente. No hay un orden adecuado de integracin, pero unos consejos son los siguientes: -Si hay secciones crticas (especialmente complejas) se deben integrar lo antes posible. -El orden de integracin debe incorporar cuanto antes los mdulos de entrada/salida para facilitar la ejecucin de puebas Existen dos formas bsicas de hacer esta integracin: -Primero en profundidad: Se van completando ramas del rbol (A B E C F G D) -Primero en anchura: Se van completando niveles de jerarqua (A B C D E F G)

PRUEBAS DEL SOFTWARE ETA ETAETAPAS FUN PAS FUNPAS FUND DDA AAM MMEN ENENTA TATALES LESLES D DDE EE LALAINT INTINTE EEGRACION DES GRACION DESGRACION DESC CCE EEN NNDE DEDENT NTNTE EE El mdulo raz es el primero: Se escriben mdulos ficticios que simulan los subordinados Una vez probado el mdulo raz (sin detectarse ya ningn defecto), se sustituye uno de los subordinados ficticios por el mdulo correspondiente segn el orden elegido Se ejecutan las correspondientes pruebas cada vez que se incorpora un mdulo nuevo Al terminar cada prueba, se sustituye un ficticio por su correspondiente real Conviene repetir algunos casos de prueba de ejecuciones anteriores para asegurarse de que no se ha introducido ningn defecto nuevo

PRUEBAS DEL SOFTWARE 12.630 MDULOS FICTICI MDULOS FICTICIMDULOS FICTICIO OOS SS La creacin de mdulos ficticios subordinados es ms complicada que la creacin de impulsores -Complejidad ..Mdulos que slo muestran un mensaje de traza ..Mdulos que muestran los parmetros que se les pasa ..Mdulos que devuelven un valor que no depende de los parmetros que se pasen como entrada ..Mdulos que, en funcin de los parmetros pasados, devuelven un valor de salida que ms o menos se corresponda con dicha entrada +Complejidad

PRUEBAS DEL SOFTWARE UNA POSI UNA POSIUNA POSIBLE CLAS BLE CLASBLE CLASIFICACION IFICACIONIFICACION DEDELOS MODULOS FICTICIOS LOS MODULOS FICTICIOSLOS MODULOS FICTICIOS Muestra Muestra Devuelve Recibe mensaje param. de entrada valor devuelve valor Tipo 1 Tipo 2 Tipo 3 Tipo

PRUEBAS DEL SOFTWARE UN PASO INTERMEDIO EN LA INTEGRACION UN PASO INTERMEDIO EN LA INTEGRACIONUN PASO INTERMEDIO EN LA INTEGRACIONDESCENDE NTE PRI DESCENDENTE PRIDESCENDENTE PRIM MMERO EN LA P ERO EN LA PERO EN LA PR RROFUNDIDAD OFUNDIDADOFUNDIDADDEL EJEM DEL EJEMDEL EJEMPLO PLOPLO A

B Ficticio C Ficticio

E Recordar el recorrido de rboles en profundidad

PRUEBAS DEL SOFTWARE UN PASO INTERMEDIO EN LA INTEGRACION UN PASO INTERMEDIO EN LA INTEGRACIONUN PASO INTERMEDIO EN LA INTEGRACIONDESCENDE NTE PRI DESCENDENTE PRIDESCENDENTE PRIM MMERO EN LA ANCH ERO EN LA ANCHERO EN LA ANCHURA URAURADEL EJEM DEL EJEMDEL EJEMPLO PLOPLO A ficticio DCB Ficticio E Recordar el recorrido de rboles en anchura

PRUEBAS DEL SOFTWARE 12.670 INTEGRACION NO INCREMENTAL INTEGRACION NO INCREMENTALINTEGRACION NO INCREMENTAL Cada mdulo que tiene que ser probado necesita lo siguiente: Un mdulo impulsor, que transmite o impulsa los datos de prueba al mdulo y muestra los resultados de dichos casos de prueba ..Uno o ms mdulos ficticios que simulan la funcin de cada mdulo subordinado llamado por el mdulo que se va a probar Una vez probado cada mdulo por separado, se ensamblan todos de una vez y se prueban en conjunto

PRUEBAS DEL SOFTWARE PRUEBA TIPICA DEL MODULO EN LA INTEGRACION PRUEBA TIPICA DEL MODULO EN LA INTEGRACIONPRUEBA TIPICA DEL MODULO EN LA INTEGRA CIONNO INCRE NO INCRENO INCREM MMENT ENTENTA AAL LL Impulsor

Resultados Casos de prueba Mdulo que se va a probar ficticio 3ficticio 2ficticio 1

PRUEBAS DEL SOFTWARE COMPARACION DE COMPARACION DECOMPARACION DE LOS DIS LOS DISLOS DIST TTINTOS INTOSINTOSTIPOS DE INTEGRACION TIPOS DE INTEGRACIONTIPOS DE INTEGRACION Ventajas de la no incremental: Requiere menos tiempo de mquina para las pruebas, ya que se prueba de una sola vez la combinacin de los mdulos Existen ms oportunidades de probar mdulos en paralelo Ventajas de la incremental: Requiere menos trabajo, ya que se escriben menos mdulos impulsores y ficticios Los defectos y errores en las interfaces se detectan antes, ya que se empieza antes a probar las uniones entre los mdulos La depuracin es mucho ms fcil, ya que si se detectan los sntomas de un defecto en un paso de la integracin hay que atribuirlo muy probablemente al ltimo mdulo incorporado Se examina con mayor detalle el programa, al ir comprobando cada interfaz poco a poco

PRUEBAS DEL SOFTWARE VE VEVENT NTNTAJ AJAJAS Y DE AS Y DEAS Y DES SSV VVENT ENTENTA AAJ JJA AAS DE S DES DE LLA AAS SS INTEGRACIONES ASCENDENTE Y DESCENDENTE INTEGRACIONES ASCENDENTE Y DESCENDENTEINTEGRACIONES ASCENDENTE Y DESCENDENTE Ascendente Descendente Ventajas Ventajas Es un mtodo ventajoso si aparecen Es ventajosa si aparecen grandes grandes fallos en la parte inferior del defectos en los niveles superiores del programa, ya que se prueba antes. programa, ya que se prueban antes. La entradas para las pruebas son ms Una vez incorporadas las funciones de fciles de crear, puesto que los entrada/salida, es fcil manejar los mdulos inferiores tienen funciones casos de prueba. ms especficas. Permite ver antes una estructura previa Es ms fcil observar los resultados de del programa, lo que facilita el hacer la prueba, ya que es en los mdulos demostraciones y ayuda a mantener la inferiores donde se elaboran los datos moral. (los superiores suelen ser mdulos de control). Desventajas Se requieren mdulos impulsores, que deben codificarse. El programa, como entidad, slo aparece cuando se agrega el ltimo mdulo. Desventajas Se requieren mdulos ficticios que suelen ser complejos de crear. Antes de incorporar la entrada/salida resulta complicado el manejo de los casos de prueba. Las entradas para las pruebas pueden ser difciles o imposibles de crear, puesto que, a menudo, se carece de los mdulos inferiores que proporcionan los detalles de operacin. Es ms difcil observar la salida, ya que los resultados surgen de los mdulos inferiores. Pueden inducir a diferir la terminacin de la prueba de ciertos mdulos.

PRUEBAS DEL SOFTWARE 12.710 PRUEBA DEL SISTEMA PRUEBA DEL SISTEMA Es el proceso de prueba de un sistema integrado de hardware y software para comprobar lo siguiente: Cumplimiento de todos los requisitos funcionales, considerando el producto software final al completo en un entorno de sistema El funcionamiento y rendimiento en las interfaces hardware, software, de usuario y de operador Adecuacin de la documentacin de usuario Ejecucin y rendimiento en condiciones lmite y de sobrecarga

PRUEBAS DEL SOFTWARE 12.720 FUE FUEFUEN NNTE TETES DE DIS S DE DISS DE DISE EEO DE CAS O DE CASO DE CASO OOS DE PRUEB S DE PRUEBS DE PRUEBA AA DEDEL LL SISTSISTEMA EMAEMA Casos basados en los requisitos gracias a tcnicas de caja negra aplicadas a las especificaciones Casos necesarios para probar el rendimiento del sistema y de su capacidad funcional (pruebas de volumen de datos, de lmites de procesamiento, etc.) Este tipo de pruebas suelen llamarse pruebas de sobrecarga (stress testing) Casos basados en el diseo de alto nivel aplicando tcnicas de caja blanca a los flujos de datos de alto nivel (por ejemplo, de los diagramas de flujo de datos)

PRUEBAS DEL SOFTWARE 12.730 PRUEBA DE ACEPTACION PRUEBA DE ACEPTACIONPRUEBA DE ACEPTACION Es la prueba planificada y organizada formalmente para determinar si se cumplen los requisitos de aceptacin marcados por el cliente. Sus caractersticas principales son las siguientes: Participacin del usuario Est enfocada hacia la prueba de los requisitos de usuario especificados. Est considerada como la fase final del proceso para crear una confianza en que el producto es el apropiado para su uso en explotacin

PRUEBAS DEL SOFTWARE RECOMENDACIONES GENERALES RECOMENDACIONES GENERALESRECOMENDACIONES GENERALES Debe contarse con criterios de aceptacin previamente aprobados por el usuario No hay que olvidar validar tambin la documentacin y los procedimientos de uso (por ejemplo,mediante una auditora) Las pruebas se deben realizar en el entorno en el que se utilizar el sistema (lo que incluye al personal que lo maneja)