Vous êtes sur la page 1sur 28

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

Ingeniera del Software II

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

Copyright UDI Educacin A Distancia

Pgina 3

Ingeniera del Software II

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.

Copyright UDI Educacin A Distancia

Pgina 4

Ingeniera del Software II

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
Copyright UDI Educacin A Distancia

Pgina 5

Ingeniera del Software II

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.

Copyright UDI Educacin A Distancia

Pgina 6

Ingeniera del Software II

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
Copyright UDI Educacin A Distancia

Pgina 7

Ingeniera del Software II

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.
Copyright UDI Educacin A Distancia
Pgina 8

Ingeniera del Software II

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.

Copyright UDI Educacin A Distancia

Pgina 9

Ingeniera del Software II

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

Copyright UDI Educacin A Distancia

Pgina 10

Ingeniera del Software II

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

Copyright UDI Educacin A Distancia

Pgina 11

Ingeniera del Software II

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
Copyright UDI Educacin A Distancia
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

Ingeniera del Software II

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

Copyright UDI Educacin A Distancia

Pgina 13

Ingeniera del Software II

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.

Copyright UDI Educacin A Distancia

Pgina 14

Ingeniera del Software II

PRUEBAS ESTRUCTURALES

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

Copyright UDI Educacin A Distancia

Pgina 15

Ingeniera del Software II

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;

Copyright UDI Educacin A Distancia

Pgina 16

Ingeniera del Software II

Grafo de Control
3 6 18 3 9 10 18 3 9 12 13 18 3 9 12 17 18

Copyright UDI Educacin A Distancia

Pgina 17

Ingeniera del Software II

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

Copyright UDI Educacin A Distancia

Pgina 18

Ingeniera del Software II

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

Copyright UDI Educacin A Distancia

Pgina 19

Ingeniera del Software II

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
Copyright UDI Educacin A Distancia
Pgina 20

Ingeniera del Software II

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
Copyright UDI Educacin A Distancia
Pgina 21

Ingeniera del Software II

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")

Copyright UDI Educacin A Distancia

Pgina 22

Ingeniera del Software II

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.

Copyright UDI Educacin A Distancia

Pgina 23

Ingeniera del Software II

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.

Copyright UDI Educacin A Distancia

Pgina 24

Ingeniera del Software II

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.

Copyright UDI Educacin A Distancia

Pgina 25

Ingeniera del Software II

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.

Copyright UDI Educacin A Distancia

Pgina 26

Ingeniera del Software II

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

Copyright UDI Educacin A Distancia

Pgina 27

Ingeniera del Software II

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.

Copyright UDI Educacin A Distancia

Pgina 28