IS-II Modulo 5. Estrategia de Pruebas de Validacion de Software

Educacin a Distancia
INGENIERIA DEL SOFTWARE II

Ing. Gustavo Eduardo Medina Ramos
Universitaria de Investigacin y Desarrollo

Bucaramanga - 2012
Ingeniera del Software II
Definiciones ....................................................................................................................................... 4 Error: Es una equivocacin cometida por un desarrollador. ................................................................ 4 Algunos ejemplos de errores son: ......................................................................................................... 4 Un error de digitacin ................................................................................................................... 4 Una malinterpretacin de un requerimiento................................................................................ 4 Una malinterpretacin de una funcionalidad ............................................................................... 4 Defecto: ......................................................................................................................................... 5 Falla: .............................................................................................................................................. 5 Prueba: .......................................................................................................................................... 5 Caractersticas ................................................................................................................................... 5 Pruebas sin Estrategia ....................................................................................................................... 5 Conflicto de Intereses ....................................................................................................................... 6 Cmo organizarse? .......................................................................................................................... 6 Estrategia de Pruebas........................................................................................................................ 7 Cuatro Niveles ................................................................................................................................... 7 Ideas paradjicas de las pruebas ...................................................................................................... 8 Recomendaciones para unas pruebas exitosas ................................................................................ 8 CICLO COMPLETO DE LAS PRUEBAS ................................................................................................ 10 ENFOQUES DE DISEO DE PRUEBAS ............................................................................................... 11 PRUEBAS ESTRUCTURALES .............................................................................................................. 12 Criterios de cobertura lgica ........................................................................................................... 13 Pruebas Estructurales...................................................................................................................... 13 Pruebas Estructurales...................................................................................................................... 14 LA COMPLEJIDAD DE McCABE V(G) (COMPLEJIDAD CICLOMTICA) .............................................. 14 PRUEBAS ESTRUCTURALES .............................................................................................................. 15 Prueba de ciclos simples ............................................................................................................. 18 Prueba de ciclos anidados ........................................................................................................... 18 Condiciones mnimas para probar ciclos anidados ..................................................................... 18 1. 2. Iniciar en el ciclo ms interno. Asignar a todos los ciclos sus valores de iteracin mnimos 18 Probar para este ciclo los valores (min + 1), tpico, (max - 1) y max ................................... 18
Pgina 2
Copyright UDI Educacin A Distancia
3. Se pasa al siguiente ciclo ms externo y se fijan sus valores de iteracin como en el paso 2, manteniendo los otros ciclos en sus valores tpicos ............................................................... 18 Ejemplo: La evaluacin final ........................................................................................................ 19 PRUEBAS FUNCIONALES .................................................................................................................. 20 Escogiendo los Casos de Prueba ................................................................................................. 20 TCNICA: PARTICIPACIONES O CLASES DE EQUIVALENCIA ......................................................... 20 PASOS PARA IDENTIFICAR CLASES DE EQUIVALENCIA ................................................................ 21 Clases de Equivalencia................................................................................................................. 21 Ejemplo 1. Pruebas funcionales .................................................................................................. 23 Ejemplo 2. Pruebas funcionales .................................................................................................. 24 TCNICA: ANALISIS DE VALORES LIMITE (AVL) ................................................................................ 25 LAS REGLAS PARA IDENTIFICAR CLASES SON: ............................................................................. 25 TCNICA: CONJETURA DE ERRORES ................................................................................................ 26 PRUEBAS ALEATORIAS..................................................................................................................... 26 EJERCICIOS....................................................................................................................................... 27 Ejercicio 1: La fiesta ......................................................................................................................... 27 Ejercicio 2: Pasajes ...................................................................................................................... 28
Pgina 3
Los buenos programadores resuelven problemas, los mejores los evitan
Definiciones
Error: Es una equivocacin cometida por un desarrollador.

Algunos ejemplos de errores son: Un error de digitacin Una malinterpretacin de un requerimiento Una malinterpretacin de una funcionalidad
El estndar 829 de la IEEE coincide con la definicin de diccionario de error como una idea falsa o equivocada. Por ende un programa no puede tener o estar en un error, ya que los programas no tienen ideas; las ideas las tienen la gente.
Pgina 4
Defecto: Un error puede conducir a uno o ms defectos.

Un defecto se encuentra en un artefacto y puede definirse como una diferencia entre la versin correcta del artefacto y una versin incorrecta.
Falla: Es la discrepancia visible que se produce al ejecutar un programa con un defecto, respecto
a la ejecucin del programa correcto.
Prueba:
La prueba es un conjunto de actividades que se pueden planificar por adelantado y llevar a cabo sistemticamente. Por esta razn se debe definir en el proceso de la ingeniera del software una plantilla para la prueba del software: un conjunto de pasos en los que podamos situar los mtodos especficos de diseo de casos de prueba.
Caractersticas
Se han propuesto varias estrategias de prueba del software y todas tienen las siguientes caractersticas generales: La prueba comienza en el nivel de mdulo y trabaja hacia fuera, hacia la integracin de todo el sistema basado en computadora. Segn el momento son apropiadas diferentes tcnicas de prueba. La prueba la lleva a cabo el responsable del desarrollo del software y (para grandes proyectos) un grupo independiente de pruebas. La prueba y la depuracin son actividades diferentes, pero la depuracin se debe incluir en cualquier estrategia de prueba.
Pruebas sin Estrategia

Motivacin Las pruebas son incomodas Las pruebas son aburridas Estoy seguro de que lo he hecho bien Big Bang: Probar todo junto al final Fallas por todas partes Difcil diagnosticar las causas de las fallas Muy costoso de arreglarlas Resultado => Productos finales defectuosos
Pgina 5
Conflicto de Intereses
Pedir a las personas que han construido el software que lo pruebe

Esto parece totalmente inofensivo: Quin puede conocer mejor un programa que los que lo han desarrollado? Desgraciadamente, los programadores tienen un gran inters en demostrar que el programa est libre de errores, que funciona de acuerdo con las especificaciones del cliente y que estar listo de acuerdo con los plazos y el presupuesto. Cada uno de estos intereses se convierte en inconveniente a la hora de encontrar errores a lo largo del proceso de prueba.
Cmo organizarse?
El responsable del desarrollo del software es responsable de probar las unidades individuales (mdulos) del programa, asegurndose de que la una lleva a cabo la funcin para la que fue diseada. En muchos casos, tambin se encargar de la prueba de integracin, el paso de prueba que lleva a la construccin (y prueba) de la estructura total del sistema. Una vez que la arquitectura del software est completa entra en juego un grupo independiente de prueba.(GIP) cuyo papel es eliminar los problemas inherentes asociados con el hecho de permitir al constructor que pruebe lo que ha construido. Una prueba independiente elimina el conflicto de intereses que, de otro modo, estara presente. El responsable del desarrollo del software no entrega simplemente el programa al GIP y se desentiende. El responsable del desarrollo y el GIP trabajan estrechamente a lo largo del proyecto de software para asegurar que se realizan pruebas exhaustivas. Mientras se realiza la prueba, el desarrollador debe estar disponible para corregir los errores que se van descubriendo.
Pgina 6
Estrategia de Pruebas
Pruebas del Sistema Pruebas de Validacin Pruebas de Integracin

Pruebas de Unidad Pruebas de Unidad Pruebas de Unidad
Inicialmente la prueba se centra en cada unidad del software respecto del cdigo fuente. En la prueba de integracin, el foco de atencin es el diseo y la construccin de la arquitectura del software. En la prueba de validacin, se validan los requisitos establecidos como parte del anlisis de requisitos del software, comparndolos con el sistema que ha sido construido. Finalmente, llegamos a la prueba del sistema, en la que se prueban como un todo el software y otros elementos del sistema. Cuatro Niveles Prueba de Unidad. La prueba se centra en cada mdulo individualmente, asegurando que funcionan adecuadamente como una unidad. La prueba de unidad ejercita caminos especficos de la estructura de control del mdulo para asegurar un alcance completo y una deteccin mxima de errores. Prueba de Integracin. A continuacin se deben ensamblar o integrar los mdulos para formar el paquete de software completo. La prueba de integracin se dirige a
Pgina 7
todos los aspectos asociados con el doble problema de verificacin y de construccin del programa. Prueba de Validacin. Despus de que el software se ha integrado (construido), se deben comprobar los criterios de validacin (establecidos durante el anlisis de requisitos). La prueba de validacin proporciona una seguridad final de que el software satisface todos los requisitos funcionales, de comportamiento y de rendimiento. Prueba del Sistema. El ltimo paso de prueba de alto nivel queda fuera de los lmites de la ingeniera del software, entrando en el ms amplio contexto de la ingeniera de sistemas de computadora. El software, una vez validado, se debe combinar con otros elementos del sistema (p.ej.: hardware, gente, bases de datos). La prueba del sistema verifica que cada elemento encaja de forma adecuada y que se alcanza la funcionalidad y el rendimiento del sistema total. Ideas paradjicas 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. Recomendaciones para unas pruebas exitosas 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.
Pgina 8
Al generar casos de prueba, se deben incluir tanto datos de entrada vlidos y esperados como no vlidos e inesperados. 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. 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.
Pgina 9
CICLO COMPLETO DE LAS PRUEBAS
Plan de pruebas
Configuracin de las pruebas (Revisada) Casos y Procedimientos
Informacin sobre el proyecto
Informacin sobre el software
Configuracin del Software (Revisada) Correcciones Notificacin de defectos del Sw (Si la hubiera) Resultados
Errores
Estadstica De errores Actividades preventivas Resultados Esperados
Prediccin de fiabilidad
Pgina 10
ENFOQUES DE DISEO DE PRUEBAS

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.
Caja Blanca
Entrada Salida
Estructural
Caja Negra
Entrada Salida
Funcional
Pgina 11
PRUEBAS ESTRUCTURALES
Abrir archivo; Leer el archivo ventas, al final indicar no ms registros; Limpiar lnea de impresin;
WHILE (haya registros ventas) DO
3
1
2
Total Nacional = 0; Total Extranjero = 0; WHILE (haya reg ventas) AND (mismo producto) DO IF (nacional) THEN
4 5 6
Sumar venta nacional a total nacional; ELSE ENDIF Leer el archivo ventas, al final indicar no ms registros; ENDWHILE Escribir lnea de listado; Limpiar lnea de impresin; ENDWHILE Cerrar Archivos
10,11
Sumar venta extranjero a total extranjero;
7a 8,9
7b
12,13
El diseo de casos de prueba tiene que estar basado en la eleccin de caminos importantes que ofrezcan una Seguridad Aceptable de que se descubren defectos.
Pgina 12
Criterios 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 decisiones) 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)
Pruebas Estructurales
Ejemplo de descomposicin de una decisin multicondicional
Pgina 13
Pruebas Estructurales
LA COMPLEJIDAD DE McCABE V(G) (COMPLEJIDAD CICLOMTICA)

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 La complejidad de McCabe se puede calcular de alguna de estas tres formas.
1. V (G) = a - n + 2, siendo a el nmero de arcos o aristas del grafo y n el nmero de nodos. 2. V (G) = r, siendo r el nmero de regiones cerradas del grafo. 3. V(G) = c + 1, siendo c el nmero de nodos de condicin.
Pgina 14
PRUEBAS ESTRUCTURALES
V (G) = 14 - 11 + 2 = 5 V (G) = 5 regiones cerradas V (G) = 5 condiciones
Pgina 15
Ejemplo Programa para calcular el costo de um producto em ventas normales y al mayoreo.
program venta; const preciobase=5.00; preciomayoreo=4.50; var cant: integer, costo: real; 1 function calcula(k:int):real; 2 begin 3 if (k<1) then 4 begin 5 println(error. Debe ordenar una cantidad positiva); 6 calcula:=-1; 7 end; 8 else 9 if (k<=50) then 10 calcula:=k*preciobase 11 else 12 if(k<1000) then 13 calcula:=k*preciomayoreo 14 else 15 begin 16 println(error. No podemos surtir ms de mil); 17 calcula:=-2; 18 end; end;
Pgina 16
Grafo de Control
3 6 18 3 9 10 18 3 9 12 13 18 3 9 12 17 18
Pgina 17
Prueba de ciclos simples
Condiciones mnimas para probar ciclos simples 1. Saltar el ciclo completamente 2. Slo pasar una sola vez a travs del ciclo 3. Pasar dos veces a travs del ciclo 4. Pasar m veces a travs del ciclo (m < n) 5. Pasar (n - 1), n y (n + 1) veces a travs del ciclo Donde n es el nmero mximo de pasadas permitidas a travs del Ciclo.
Prueba de ciclos anidados
Condiciones mnimas para probar ciclos anidados 1. Iniciar en el ciclo ms interno. Asignar a todos los ciclos sus valores de iteracin mnimos 2. Probar para este ciclo los valores (min + 1), tpico, (max - 1) y max 3. Se pasa al siguiente ciclo ms externo y se fijan sus valores de iteracin como en el paso 2, manteniendo los otros ciclos en sus valores tpicos
Pgina 18
Ejemplo: La evaluacin final
Ha terminado el presente semestre y el profesor necesita validar si ha hecho una buena gestin, para ello ha confeccionado un algoritmo que le permite evaluar cual es el porcentaje de alumnos del curso que ha aprobado la materia, y que adicionalmente le informa cuantos alumnos aprobaron la materia y cuantos no. Dmosle un vistazo a como lo realiz
Pgina 19
PRUEBAS 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 caso de prueba funcional es bien elegido si se cumple 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, nos 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. Escogiendo los Casos de Prueba
En la pruebas de sistema, los datos de prueba deber cubrir los posibles valores de cada parmetro basado en los requerimientos. Debido a que probar cada uno de los valores es imprctico, se debern de escoger unos cuantos valores de cada clase de equivalencia. Una clase de equivalencia es un conjunto de valores que debern ser tratados igual. Idealmente, los casos de prueba que evalan condiciones de error son escritos de forma separada del los casos de prueba funcionales y debern incluir pasos para verificar los mensajes de error y los registros. En la realidad, los casos de prueba para errores no se han escrito an, es correcto que los evaluadores revisen las condiciones de error cuando estn realizando casos de prueba de funcionamiento normal. Debera estar claro que datos de prueba, si existen, se espera que disparen errores. TCNICA: PARTICIPACIONES O CLASES DE EQUIVALENCIA 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. Lo que hay que hacer es: Identificar las clases de equivalencia Crear casos de prueba correspondiente
Pgina 20
PASOS PARA IDENTIFICAR CLASES DE EQUIVALENCIA
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 Existen algunas reglas que ayudan a identificar clase: a) Si se especifica un rango de valores para los datos de entrada, se crear una clase vlida y dos clases no vlidas b) Si se especifica un nmero finito y consecutivo de valores, se crear una clase vlida y dos no vlidas e) 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. Clases de Equivalencia Cadenas cadena vaca cadena consistente de nicamente un espacio vaco cadena que empieza o termina en un espacio en blanco sintcticamente correcta: valores cortos y largos sintcticamente correcta: valores semnticamente vlidos e invlidos valor sintcticamente incorrecto: caracteres o combinaciones ilegales asegrese de probar caracteres especiales como #, ", ', &, y < asegrese de probar caracteres "extranjeros" escritos desde teclados internacionales Nmeros cadena vaca, si es posible 0 pequeos y largos en rangos positivos pequeos y largos en rangos negativos fuera del rango de positivos fuera del rango de negativos
Pgina 21
que comiencen con ceros sintcticamente invlidos (por ejemplo, que incluya letras) Identificadores cadena vaca valor sintcticamente correcto sintcticamente correcto: referencia a un ID existente, referencia invlida valor sintcticamente incorrecto Botones de opcin (radio) un objeto seleccionado nada seleccionado, si es posible Botones de opcin mltiple seleccionados sin seleccionar Menus de pestaa seleccione un elemento en cada turno Listas con Scroll no seleccione ningn elemento, si es posible seleccione un elemento en cada turno seleccione combinaciones de elementos, si es posible seleccione todos los elementos, si es posible Subir archivos en blanco archivo de 0 byte archivos grandes archivo con nombre corto archivo con nombre grande nombre de archivo sintcticamente incorrecto, si es posible (por ejemplo, "Nombre Con Espacios.tar.gz")
Pgina 22
Ejemplo 1. Pruebas funcionales
Ejemplo: Aplicacin bancaria en la que el operador debe proporcionar un cdigo, un nombre y una transaccin.
Condicin de Entrada Clases Vlidas Clases no Vlidas
Cdigo rea N de 3 dgitos que no empieza con 0 ni 1) Nombre para identificar la transaccin
(1) 200 cdigo 999
(2) cdigo <200 (3) cdigo >999 (4) no es nmero
(5) seis caracteres
(6) menos de 6 caracteres (7) ms de 6 caracteres
Orden Una de las siguientes
(8) cheque (9) depsito (10) pago factura (11) retirada de fondos
(12) ninguna orden vlida
Habra que disear casos de prueba que cubran todas las clases de equivalencias, tanto vlidas como invlidas, y para las invlidas en casos de prueba distintos.
Pgina 23
Ejemplo 2. Pruebas funcionales
Se est desarrollando un sistema de informacin de una empresa, el cual tiene como requerimiento importante el limitar el acceso a diversas partes del sistema a los empleados y slo de acuerdo a los permisos con que cuente cada uno. Al analizar el problema se decide que debe existir una clave de identificacin para cada empleado y su clave como mecanismo de control. Antes o despus de programar el mdulo correspondiente, se analizan las diferentes situaciones que pueden ocurrir: que un empleado real de su clave correcta (el caso ms deseable), que un empleado real proporcione una clave errnea y que un empleado no registrado intente ingresar. Se preparan casos de prueba, como los que siguen:
Entrada
Salida esperada
Nombre: Gonzlez Clave: g12nP14
Mensaje: Bienvenido Sr. Gonzlez
Nombre: Gonzlez Clave: g1nP14
Mensaje: Sr Gonzlez, su clave est equivocada
Nombre: Pineda Clave: g12nP14
Mensaje: Sr. Pineda no est registrado
Una vez desarrollado el mdulo, se ejecuta con cada caso de prueba y se compara el resultado observado con el que se tena planeado. Suponga que el primer caso produjo el resultado Bienvenido Sr Gonzlez; entonces ese caso pasa. Si el segundo produce una salida como Gonzlez no es empleado registrado, que no corresponde al resultado esperado, se anotar una falla. Si el tercer caso responde Bienvenido Sr. Pineda, se debe anotar otra falla.
El conteo final ser un caso pasado y dos fallas.
Pgina 24
TCNICA: ANALISIS DE VALORES 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. LAS REGLAS PARA IDENTIFICAR 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. a) Los valores lmite de entrada no generan necesariamente los valores lmite de salida (recurdese la funcin seno, por ejemplo) b) 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.
Pgina 25
TCNICA: CONJETURA DE ERRORES
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 ALEATORIAS
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.
Pgina 26
EJERCICIOS Ejercicio 1: La fiesta

A una fiesta asistieron personas de diferentes edades y sexos. Construir un algoritmo dadas las edades y sexos de las personas que obtenga:
Cuantas personas mayores asistieron a la fiesta. Cuantos hombres y cuantas mujeres. Promedio de edades por sexo. La edad de la persona ms joven que asisti.
No se computan los menores de edad asistentes a la fiesta Solo aceptar edades superiores a cero
Pgina 27
Ejercicio 2: Pasajes
Se desean realizar pruebas de la caja negra sobre un programa utilizado por una empresa de transporte para calcular la tarifa de cada billete segn el trayecto, la antelacin en la que se obtiene el billete y la edad del pasajero. Dicha empresa slo opera viajes entre Bucaramanga, Tunja y Yopal. Como datos de entrada toma: CiudadOrigen que es un campo que puede tomar los valores BGA, TNJ y YPL. CiudadDestino que puede tomar los mismos valores BGA, TNJ y YPL. Fecha es un campo del tipo fecha que indica el da en el que se pretende realizar el viaje. Edad es un campo numrico positivo de 3 cifras (incluyendo el 000). La tarifa obtenida adems de estar en funcin del trayecto realizado, ofrece los siguientes descuentos por antelacin y edad del pasajero. Los descuentos no son acumulables y siempre se aplicar el de mayor valor. 15% de descuento sacando el billete con antelacin superior a 1 semana y 25% con antelacin superior a 1 mes. 30% a los pasajeros con edad inferior a 25 aos y 40% a los pasajeros con edad superior a 65 aos. Se solicita: 1. Realizar una tabla con las clases de equivalencia indicando las clases vlidas y no vlidas para cada variable de entrada. 2. Obtener casos de prueba de dicha tabla, indicando las clases de equivalencia que cubrira cada caso (numerar previamente las clases). 3. Aplicar la tcnica de anlisis de valores lmite para obtener ms casos de prueba que pudieran presentar un tratamiento diferenciado.
Pgina 28

IS-II Modulo 5. Estrategia de Pruebas de Validacion de Software

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

IS-II Modulo 5. Estrategia de Pruebas de Validacion de Software

Uploaded by

Copyright:

Available Formats

Educacin a Distancia

INGENIERIA DEL SOFTWARE II

Universitaria de Investigacin y Desarrollo

Ingeniera del Software II

Copyright UDI Educacin A Distancia

Ingeniera del Software II

Copyright UDI Educacin A Distancia

Ingeniera del Software II

Los buenos programadores resuelven problemas, los mejores los evitan

Error: Es una equivocacin cometida por un desarrollador.

Copyright UDI Educacin A Distancia

Ingeniera del Software II

Defecto: Un error puede conducir a uno o ms defectos.

Pruebas sin Estrategia

Ingeniera del Software II

Pedir a las personas que han construido el software que lo pruebe

Copyright UDI Educacin A Distancia

Ingeniera del Software II

Pruebas del Sistema Pruebas de Validacin Pruebas de Integracin

Ingeniera del Software II

Ingeniera del Software II

Copyright UDI Educacin A Distancia

Ingeniera del Software II

CICLO COMPLETO DE LAS PRUEBAS

Configuracin de las pruebas (Revisada) Casos y Procedimientos

Informacin sobre el proyecto

Informacin sobre el software

Estadstica De errores Actividades preventivas Resultados Esperados

Copyright UDI Educacin A Distancia

Ingeniera del Software II

ENFOQUES DE DISEO DE PRUEBAS

Copyright UDI Educacin A Distancia

Ingeniera del Software II

Sumar venta extranjero a total extranjero;

Ingeniera del Software II

Criterios de cobertura lgica

Copyright UDI Educacin A Distancia

Ingeniera del Software II

LA COMPLEJIDAD DE McCABE V(G) (COMPLEJIDAD CICLOMTICA)

Copyright UDI Educacin A Distancia

Ingeniera del Software II

V (G) = 14 - 11 + 2 = 5 V (G) = 5 regiones cerradas V (G) = 5 condiciones

Copyright UDI Educacin A Distancia

Ingeniera del Software II

Ejemplo Programa para calcular el costo de um producto em ventas normales y al mayoreo.

Copyright UDI Educacin A Distancia

Ingeniera del Software II

Copyright UDI Educacin A Distancia

Ingeniera del Software II

Prueba de ciclos simples

Prueba de ciclos anidados

Copyright UDI Educacin A Distancia

Ingeniera del Software II

Ejemplo: La evaluacin final

Copyright UDI Educacin A Distancia

Ingeniera del Software II

Ingeniera del Software II

PASOS PARA IDENTIFICAR CLASES DE EQUIVALENCIA

Ingeniera del Software II

Copyright UDI Educacin A Distancia

Ingeniera del Software II

Ejemplo 1. Pruebas funcionales

(1) 200 cdigo 999