Unid. 4 - MÉTODOS CONVENCIONALES DE LA ING. DE SW

Pontificia Universidad Catlica del Ecuador
Ingeniera de Software
INDICE
UNIDAD 4: METODOS CONVENCIONALES DE LA INGENIERIA DE SOTWARE.........................................1 4.4 METODOS DE PRUEBA DEL SOFTWARE.........................................................................................................1 4.4.1 FUNDAMENTOS DE LAS PRUEBAS DE SOFTWARE...................................................................................1 4.4.1.1 DIRECTRICES DE LA PRUEBA..............................................................................................................1 4.4.1.2 PRINCIPIOS DE LA PRUEBA..................................................................................................................1 4.4.1.3 FACILIDAD DE LA PRUEBA..................................................................................................................1 4.4.1.4 CLASES DE PRUEBAS.............................................................................................................................2 4.4.2 PRUEBAS DE CAJA BLANCA..........................................................................................................................2 4.4.2.1 PRUEBA DEL CAMINO BASICO............................................................................................................2 A. MATRICES DE GRAFO...............................................................................................................................3 4.4.2.2 PRUEBA DE LA ESTRUCTURA DE CONTROL...................................................................................4 A. PRUEBA DE CONDICION...........................................................................................................................4 A. PRUEBA DE BUCLES..................................................................................................................................4 4.4.3 PRUEBAS DE CAJA NEGRA............................................................................................................................5 4.4.3.1 PRUEBAS BASADAS EN GRAFOS........................................................................................................6 4.4.3.2 PARTICION EQUIVALENTE...................................................................................................................6 4.4.3.3 ANALISIS DE VALORES LIMITE...........................................................................................................7 4.4.3.4 PRUEBA DE COMPARACION.................................................................................................................7 4.4.4 PRUEBA DE ENTORNOS ESPECIALIZADOS................................................................................................7 4.4.4.1 PRUEBA DE INTERFACES GRAFICAS DE USUARIO........................................................................7 4.4.4.2 PRUEBA DE ARQUITECTURA CLIENTE / SERVIDOR......................................................................7 4.4.4.3 PRUEBA DE DOCUMENTACIN Y AYUDA.......................................................................................8 4.4.4.4 PRUEBA DE SISTEMAS EN TIEMPO REAL.........................................................................................8 4.4.2 ESTRATEGIA DE PRUEBA DEL SOFTWARE.................................................................................................9 4.4.5.1 ORGANIZACIN DE LA PRUEBA DEL SOFTWARE..........................................................................9 4.4.2.2 CRITERIOS PARA COMPLETAR LA PRUEBA DEL SOFTWARE...................................................10 4.4.2.3 ASPECTOS ESTRATGICOS PREVIOS...............................................................................................10 4.4.2.4 PRUEBA DE UNIDAD............................................................................................................................11 4.4.2.5 PRUEBA DE INTEGRACION.................................................................................................................11 A. INTEGRACIN DESCENDENTE.............................................................................................................11 B. INTEGRACIN ASCENDENTE................................................................................................................12 C. PRUEBA DE REGRESION.........................................................................................................................13 d. SUGERENCIAS GENERALES PARA LA APLICACIN DE LA PRUEBA DE INTEGRACION........13 4.4.2.6 PRUEBA DE VALIDACION...................................................................................................................13 A. PRUEBAS ALFA Y BETA..........................................................................................................................14 4.4.2.7 PRUEBA DEL SISTEMA.........................................................................................................................14 A. PRUEBA DE RECUPERACION.................................................................................................................14 B. PRUEBA DE SEGURIDAD........................................................................................................................14 C. PRUEBA DE RESISTENCIA......................................................................................................................14 D. PRUEBA DE RENDIMIENTO...................................................................................................................15 e. ESTRATEGIA DE DESARROLLO DE LA PRUEBA DE SISTEMA.......................................................15 4.4.2.8 DOCUMENTACION DE LA PRUEBA..................................................................................................15 4.4.2.9 EL ARTE DE LA DEPURACION...........................................................................................................16 A. FUERZA BRUTA........................................................................................................................................16 b. VUELTA ATRAS.........................................................................................................................................16 C. ELIMINACION DE CAUSAS.....................................................................................................................16 D. RECOMENDACIONES ADICIONALES...................................................................................................16 4.5 IMPLANTACION (CONVERSIN).....................................................................................................................16 4.5 PRODUCCION.......................................................................................................................................................17 4.6 MANTENIMIENTO...............................................................................................................................................18
Ing. Mario Santamara
UNIDAD 4: METODOS CONVENCIONALES DE LA INGENIERIA DE SOTWARE

4.4 METODOS DE PRUEBA DEL SOFTWARE
La prueba del software es un elemento crucial para garantizar la calidad de un software y permite validar las especificaciones, el diseo y de la programacin. Con esto en mente, en esta seccin del documento se busca detallar de la mejor forma los mtodos y estrategias de prueba de software que pueden aplicarse, razn por la cual la misma se basa en los captulos 16 y 17 Mtodos de prueba del software y Estrategias de prueba del software del libro Ingeniera del Software: Un enfoque prctico, 4ta. Edicin, de Roger S. Pressman, al presentar estos un compendio de conceptos, conocimientos y elementos claros y concisos.
4.4.1 FUNDAMENTOS DE LAS PRUEBAS DE SOFTWARE

Las pruebas de software se fundamentan en cuatro elementos que sern detallados a continuacin: Las directrices a seguir; Los principios a ser considerados; Su facilidad; y, Las clases de pruebas.
4.4.1.1DIRECTRICESDELAPRUEBA
Proceso de ejecucin de un programa con la intencin de descubrir un error; Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces; y, Una prueba tiene xito si descubre un error no detectado hasta entonces.
Sin embargo de esto, la prueba no puede asegurar la ausencia de defectos, solo puede demostrar que existen defectos de software1.
4.4.1.2PRINCIPIOSDELAPRUEBA
A todas las pruebas se les debera poder hacer un seguimiento hasta los requisitos del cliente; Las pruebas deberan planificarse mucho antes de que empiecen (la planificacin puede comenzar al final de la fase de anlisis y la definicin de casos de prueba al final de la fase de diseo); El principio de Pareto es aplicable a la prueba de software (80% de los errores descubiertos durante las pruebas surgen al hacer un seguimiento de solo el 20% de todos los mdulos del programa); Las pruebas deberan empezar por lo pequeo y progresar hacia lo grande; No son posibles las pruebas exhaustivas; y, Para ser ms efectivas, las pruebas deberan ser conducidas por un equipo independiente.
4.4.1.3FACILIDADDELAPRUEBA
Un software debe ser diseado con facilidad para hacer pruebas en mente, es decir, que permita ser probado ms fcilmente, para esto, Roger Pressman recomienda considerar los siguientes parmetros determinados por James Bach: Operatividad: Cuanto mejor funcione el software, ms eficientemente se puede probar; Observabilidad: Lo que se ve es lo que se prueba; Controlabilidad: Cuanto mejor se pueda controlar el software, ms se puede automatizar y optimizar; Capacidad de descomposicin: Si se controla el alcance de las pruebas, se puede aislar ms rpidamente los problemas y llevar a cabo mejores pruebas de regresin; Simplicidad: Cuanto menos haya que probar, ms rpidamente podremos probarlo; Estabilidad: Cuanto menos cambios, menos interrupciones a las pruebas; y, Facilidad de la comprensin: Cuanta ms informacin tengamos, ms inteligentes sern las pruebas.
Adems, segn Kaner, Falk y Nguyen una buena prueba debe tener los siguientes atributos:
PressmanRoger,Ingenieradelsoftware:unenfoqueprctico,McGrawHill,4ta.Edicin,pgina302.

Alta probabilidad de encontrar un error; Falta de redundancia; Ser la mejor de todas las propuestas; y, No debera ser ni demasiado sencilla ni demasiado compleja.
4.4.1.4CLASESDEPRUEBAS
El diseo de caso de pruebas se basa en los tipos de prueba existentes, que bsicamente son dos: Pruebas de caja blanca; y, Pruebas de caja negra
En las dos secciones siguientes hablaremos de las caractersticas de las mismas y los tipos especficos de pruebas existentes.
4.4.2 PRUEBAS DE CAJA BLANCA

Las pruebas de caja blanca constituyen un minucioso examen de los detalles procedimentales, usando la estructura de control del diseo procedimental para crear casos de pruebas con lo cual: Se garantiza que se recorra por lo menos una vez los caminos independientes de cada mdulo; Se ejecuten todas las decisiones lgicas en sus opciones verdadera y falsa; Se ejerciten todos los bucles en sus lmites y con sus bucles operacionales; y, Se usen las estructuras internas de datos para asegurar su validez.
Todo esto debido a que: Los errores lgicos y las suposiciones incorrectas son inversamente proporcionales a la probabilidad de que se ejecute un camino del programa; Cualquier camino lgico puede ejecutarse de forma normal independientemente de nuestras suposiciones; y, Los errores tipogrficos son aleatorios y no siempre pueden ser descubiertos por los compiladores y ambientes integrados de desarrollo.
Por otro lado, existen bsicamente dos tipos de pruebas de caja blanca: Camino bsico; y, Estructura de control.
4.4.2.1PRUEBADELCAMINOBASICO
Este tipo de prueba constituye una medida de la complejidad lgica de un diseo procedimental para usarla como gua bsica de un conjunto bsico de caminos de ejecucin y se basa en la teora de grafos. Se trata de representar el flujo de control lgico de un procedimiento mediante grafos de flujo considerando que: Un nodo del grafo representa 1 ms sentencias procedimentales, que pueden ser un conjunto de secuencias procedimentales o un rombo de decisin (sentencias if o case) Las aristas o enlaces representan el flujo de control de cada nodo; Una regin constituye un rea delimitada por nodos y aristas que incluye el rea exterior; Un nodo predicado es aquel del cual emergen 2 ms aristas (por lo general representa una sentencia de condicin); y, Se realiza el grfico considerando las construcciones estructurales en formas de grafo de flujo detalladas en la figura 4.1
Luego de obtener el grfico respectivo, se debe calcular la Complejidad Ciclomtica, que permite determinar el nmero de caminos independientes del conjunto de caminos bsicos del programa, que constituye el lmite superior de nmero de pruebas que se deben realizar para asegurar que se ejecuta cada sentencia por lo menos una vez. Para esto se pueden usar cualquiera de las siguientes frmulas: V(G) = Nmero de regiones V(G) = A N + 2 Donde A es el nmero de aristas del grafo y N el nmero de nodos V(G) = P + 1

Donde P es el nmero de nodos predicado contenidos en el grafo
FIGURA 4.1: NOTACIN DE GRAFOS DE FLUJO Secuencia Bucle (While) Seleccin Mltiple (Case)
Condicin IF
Bucle (Hasta)
CADA CIRCULO REPRESENTA UNA O MAS SENTENCIAS, SIN BIFURCACIONES EN LDP O CODIGO FUENTE
FUENTE: Ingeniera del Software: Un enfoque prctico, Pressman S. Roger, Captulo 16, Figura 16.1, pgina 306, 4ta. Edicin. Entonces, para obtener los casos de prueba, se deben realizar los siguientes pasos: 1. 2. 3. Usando el diseo o el cdigo como base, se dibuja su grafo de flujo respectivo; Se determina la complejidad ciclomtica para conseguir el conjunto bsico de caminos linealmente independientes; y, Se prepara los casos de prueba que forzarn la ejecucin de cada camino del conjunto bsico
A. MATRICES DE GRAFO
El proceso descrito anteriormente puede ser automatizado, construyendo una matriz cuadrada cuyos tamao (nmero de filas y columnas) equivale al nmero de nodos del grafo y cada entrada de la misma corresponde a las conexiones (aristas) del grafo. Si se asignan pesos a los enlaces de la matriz (1 = existe conexin, 0 = no existe conexin), la misma puede servir para: Determinar la complejidad ciclomtica; Establecer la probabilidad de que un enlace sea ejecutado; Obtener el tiempo de procesamiento asociado al recorrido de cada enlace; Determinar la cantidad de memoria requerida durante el recorrido de un enlace; y, Establecer los recursos requeridos durante el recorrido de un enlace.
La figura 4.2 muestra un ejemplo de aplicacin
FIGURA 4.2: MATRIZ DE GRAFOS
1 a e 5 g
3 b f 4 c 2
3
N O D O
Matriz de grafo Conectado al nodo 1 2 3 4 5 1 a 2 3 d b 4 c f 5 g e
N O D O
Matriz de conexiones Conectado al nodo 1 2 3 4 5 Conexiones 1 1 11=0 2 3 1 1 21=1 4 1 1 21=1 5 1 1 21=1 3+1=4 (Complejidad ciclomtica)
FUENTE: Ingeniera del Software: Un enfoque prctico, Pressman S. Roger, Captulo 16, Figuras 16.7 y 16.8, pgina 311, 4ta. Edicin.
4.4.2.2PRUEBADELAESTRUCTURADECONTROL
La prueba del camino bsico no es suficiente por si sola, por lo que se deben realizar pruebas adicionales como: La prueba de condicin; La prueba de flujo de datos; y, La prueba de bucles.
A. PRUEBA DE CONDICION
Este tipo de prueba obtiene casos de prueba ejercitando las condiciones lgicas contenidas en el mdulo de un programa tomando en cuenta que: Una condicin simple es una variable lgica o una expresin relacional; Una condicin compuesta son 2 ms condiciones simples, operadores lgicos y parntesis; y, Una expresin lgica es una condicin sin expresin relacional
La expresin relacional adquiere la forma: E1 < Operador relacional > E2 Donde E1 y E2 son expresiones aritmticas y operador relacional puede ser alguno de <, , =, , , >. Entonces, si una condicin est incorrecta, se asume que est incorrecto al menos un componente de la condicin lgica, por lo que pueden presentarse errores en: Operadores lgicos; Variables lgicas; Parntesis lgicos; Operadores relacionales; Expresiones aritmticas
Por esto, este tipo de prueba se basa en la prueba de cada una de las condiciones del programa, lo que presenta la ventaja de tener una cobertura sencilla y facilita la orientacin de pruebas adicionales. Concretamente, se puede aplicar los siguientes mtodos (ms importantes): Prueba de ramificaciones: Para una condicin compuesta C, se ejecuta al menos 1 vez la rama verdadera, una vez la rama falsa y una condicin simple. Prueba de dominio: Se realizan 3 4 pruebas a la expresin relacional, donde E1 puede ser menos, igual o mayor que E2. Si E1 y E2 son correctos, entonces el error se encuentra en el operador relacional. Para una prueba de n variables, se debe hacer 2n pruebas, lo cual puede ser muy grande, por lo que se recomienda este tipo de prueba cuando el valor de n es pequeo.
A. PRUEBA DE BUCLES
Todo programa cuenta con una buena cantidad de bucles, por lo que este tipo de prueba se centra en la validez de este tipo de construcciones, que bsicamente pueden ser de 4 tipos como se muestra en la figura 4.3 y cuyos esquemas de prueba se detallan a continuacin: Bucles simples: Pasar el bucles por alto, pasar por el bucle una sola vez, pasar dos veces, hacer m pasos (m < n) y hacer n 1, n y n + 1 pasos. N es el nmero mximo de pasos permitidos por el bucle. Bucles anidados: Se comienza la prueba por el bucle ms interior con los dems bucles configurados en sus valores mnimos. Se llevan a cabo pruebas de bucles simples para el bucle ms interior, manteniendo los parmetros de iteracin de los bucles externos en sus valores mnimos y aadiendo valores fuera de rango o excluidos. Una vez terminado, se progresa hacia fuera manteniendo todos los bucles externos en sus valores mnimos y los dems bucles anidados en sus valores tpicos. Para terminarse continua hasta que se hayan probado todos los bucles. Bucles concatenados: Si los bucles son independientes, se aplican pruebas de bucles simples, caso contrario se aplica el esquema usado con los bucles anidados. Un bucle de este tipo no es independiente cuando se usa el controlador del bucle 1 como valor inicial del bucle 2 Bucles no estructurados: Este tipo de bucles deben ser rediseados.
FIGURA 4.3: TIPOS DE BUCLES
Bucles simples
Bucles anidados
Bucles concatenados
Bucles no estructurados
FUENTE: Ingeniera del Software: Un enfoque prctico, Pressman S. Roger, Captulo 16, Figura 16.9, pgina 314, 4ta. Edicin.
4.4.3 PRUEBAS DE CAJA NEGRA

Las pruebas de caja negra permiten obtener conjuntos de entrada que ejerciten los requisitos funcionales del software, complementndose con las pruebas de caja blanca, obteniendo errores en las siguientes categoras: Funciones incorrectas o inexistentes; Errores de interfaz; Errores en la estructura de datos; Rendimiento; e Inicializacin y terminacin.
Por lo tanto, este tipo de pruebas se disean para: Determinar cmo se prueba la validez funcional; Establecer qu clase de entradas proporcionarn unos buenos casos de prueba; Fijar si el sistema es particularmente sensible a ciertos valores de entrada; Determinar la forma en que se aslan los lmites de una clase de datos;

Establecer el volumen y nivel de datos soportar el sistema; y, Fijar los efectos que tendrn combinaciones especficas de datos sobre el sistema
Existen bsicamente cuatro tipos de pruebas de caja negra: Basadas en grafos; Particin equivalente; Anlisis de valores lmites; y, Pruebas de comparacin.
4.4.3.1PRUEBASBASADASENGRAFOS
Se desarrolla un grafo basado en los objetos (de datos, mdulos de programa, etc.) y las relaciones que existen entre estos, considerando que: Un nodo del grafo representa a un objeto; Un enlace del grafo representa a las relaciones; El peso de un nodo son las propiedades del objeto (color, dimensiones, configuracin, etc.); El peso de un enlace son las caractersticas de la relacin (contiene a, se representa como, etc.); y, Puede haber enlaces simtricos o dirigidos.
Mediante grafos se pueden realizar obtener casos de prueba relacionados con: Modelacin del flujo de transaccin: Donde los nodos son pasos de la transaccin y los enlaces conexiones lgicas (DFD) Modelacin del estado finito: Donde los nodos son estados observables por el usuario y los enlaces las transiciones (Diagramas de transicin) Modelacin del flujo de datos: Donde los nodos son objetos de datos y los enlaces son las transformaciones Modelacin de planificacin: Donde los nodos son los objetos del programa y los enlaces son las conexiones secuenciales de los mismos.
Una vez que se ha desarrollado el grafo, se realizan pruebas respecto de: Pruebas de bucles, ya que el grafo obtenido puede contener bucles; La transitividad o no de las relaciones; La simetra o no de los enlaces; La cobertura del nodo (nodos no omitidos y pesos correctos); y, La cobertura de los enlaces (propiedades de las relaciones)
Como ejemplo de aplicacin de este tipo de prueba se puede observar la figura 4.4 que corresponde a una aplicacin de procesamiento de textos.
FIGURA 4.4: NOTACIN DE GRAFOS

Nuevo Archivo La seleccin del men genera (tiempo de generacin < .1,0 seg) Permite la edicin de Se representa como Texto del documento contiene Ventana de documento
Atriburtos: Dimensin de inicio: configuracin o preferencias por defecto Color de fondo: blanco Color de texto: color o preferencias por defecto
FUENTE: Ingeniera del Software: Un enfoque prctico, Pressman S. Roger, Captulo 16, Figura 16.10, pgina 316, 4ta. Edicin.
4.4.3.2PARTICIONEQUIVALENTE
Este tipo de prueba divide el dominio de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba, basado en la evaluacin de las clases de equivalencia para una condicin de entrada, donde:

Una condicin de entrada puede ser un valor numrico especfico, un rango de valores, un conjunto de valores relacionados o una condicin lgica; y, Una clase de equivalencia es un conjunto de valores vlidos o no para la condicin de entrada.
Para definir las clases de equivalencia se siguen las siguientes directrices si la condicin de entrada: Especifica un rango, se define una clase de equivalencia vlida y dos no vlidas; Requiere un valor especfico, se define una clase de equivalencia vlida y dos no vlidas; Especifica un miembro de un conjunto, se define una clase de equivalencia vlida y una no vlida; y, Es lgica, se define una clase de equivalencia vlida y una no vlida
4.4.3.3ANALISISDEVALORESLIMITE
Este tipo de prueba genera casos de prueba que verifican que pasa al ingresar los valores lmite de una entrada de datos y se complementa con la particin equivalente. Para desarrollar este tipo de pruebas se siguen las siguientes directrices si la condicin de entrada: Especifica un rango delimitado por los valores A y B, se generan casos de prueba para A y B y los valores justo por debajo y por encima de A y B; Especfica un nmero de valores, se disean casos de prueba para los valores mnimos, mximos, justo por debajo del valor mnimo y justo por encima del valor mximo; Aplicar las directrices anteriores a las condiciones de salida; y, Si las estructuras de datos internas son limitadas, ejercitar las mismas en sus lmites.
4.4.3.4PRUEBADECOMPARACION
Para sistemas que deben responder de forma confiable en situaciones crticas (envo de msiles, bancos de sangres, etc), se recomienda desarrollar sistemas redundantes a los cuales se les aplique casos de prueba similares para analizar los resultados obtenidos. Si las salidas obtenidas por las diversas versiones son idnticas, se asumen correctas, caso contrario se analizan todas las aplicaciones para determinar el problema. Se debe tener cuidado con este tipo de prueba, pues si el error se encuentra en la fase de anlisis, se arrastrara al desarrollo de todas las versiones y si las pruebas dan resultados similares para todos los sistemas, pero errneos, la prueba no detectar el error.
4.4.4 PRUEBA DE ENTORNOS ESPECIALIZADOS

Dada la complejidad de los sistemas actuales, se deben realizar pruebas especficas en las siguientes reas: Interfaces grficas de usuario; Arquitectura cliente / servidor; Documentacin y ayuda; y, Sistemas de tiempo real
4.4.4.1PRUEBADEINTERFACESGRAFICASDEUSUARIO
Las interfaces grficas de usuario modernas son bastante similares y apuntan a los mismos objetivos, pero su complejidad y el uso de componentes reutilizables, puede facilitar que se cometan errores en el desarrollo de las mismas. Este tipo de pruebas se enfocan en tres reas: Ventanas; Mens; y, Entradas de datos
En la seccin 16.7.1, del libro Ingeniera del Software: Un enfoque prctico, 4ta. Edicin, de Roger Pressman, se lista un conjunto de directrices aplicables para desarrollar este tipo de pruebas que sugerimos se revise.
4.4.4.2PRUEBADEARQUITECTURACLIENTE/SERVIDOR
El desarrollo de software bajo una arquitectura cliente / servidor representa varias particularidades a ser consideradas, por lo que el tema ser tratado ms adelante, sin embargo de lo cual se puede adelantar que las pruebas que se aplican en este nivel cubren las siguientes reas: Comprobaciones de funcin de la aplicacin al nivel del cliente; Comprobaciones de funcin de la aplicacin al nivel del servidor;

Comprobaciones de la base de datos; Comprobaciones de las transacciones; y, Comprobaciones de comunicacin a travs de la red.
4.4.4.3PRUEBADEDOCUMENTACINYAYUDA
Los errores en la documentacin que se entrega al usuario puede ser tan dainos como los que presente el software y ponen en entredicho la imagen de los desarrolladores, motivo por el cual se debe verificar el estado de la documentacin, lo cual normalmente se realiza en dos fases: Revisin tcnica formal para revisar la claridad editorial del documento; y, Uso de la documentacin junto al programa para verificar su validez, para lo cual se pueden emplear algunos de las tcnicas descritas en la seccin 4.4.3.
Segn Roger Pressman, en la seccin 16.7.3, de su libro Ingeniera del Software: Un enfoque prctico, 4ta. Edicin, este tipo de prueba debe responder a las siguientes preguntas: Describe con exactitud la documentacin como conseguir cada modo de empleo de la aplicacin? Es exacta la secuencia de cada interaccin? Son claros y exactos los ejemplos? Son consistentes con el programa real la terminologa, las descripciones del men y las respuestas del sistema? Es relativamente fcil localizar ayuda en la documentacin? Se pueden solucionar problemas fcilmente con la documentacin? Son exactos y completos la tabla de contenido y el ndice? Facilita el diseo del documento la comprensin y rpida asimilacin de la informacin? Estn descritos con gran detalle los mensajes de error para el usuario en el documento as como en su presentacin? Si se utilizan enlaces de hipertexto son exactos y completos? Si se usan mensajes de ayuda en la aplicacin son claros? (aumentado)
Se recomienda que un equipo independiente pruebe la documentacin usando el programa y anota los problemas encontrados, luego de lo cual se debe rescribir el documento o en su defecto los elementos de ayuda en lnea.
4.4.4.4PRUEBADESISTEMASENTIEMPOREAL
En las aplicaciones de tiempo real, a ms de las pruebas de caja blanca y negra, se deben considerar el tratamiento de sucesos, la temporizacin de los datos, el paralelismos de tareas (procesos) que administran los datos y el impacto de los fallos de hardware asociado. Presman, en la seccin 16.7.4, de su libro Ingeniera del Software: Un enfoque prctico, 4ta. Edicin, sugiere la siguiente estrategia de aplicacin de pruebas: Prueba de tareas: Se examina cada tarea independientemente mediante pruebas de caja blanca y caja negra sin considerar errores de temporizacin o de comportamiento; Prueba de comportamiento: Mediante herramientas CASE se examina el comportamiento del sistema en tiempo real y como consecuencia de sucesos externos, tratando de categorizar los mismos mediante particin equivalente. Cada suceso debe ser probado individualmente para detectar los errores asociados Prueba intertareas: Se prueban las tareas asncronas que se comunican con otras con diferentes tasas de datos y cargas de proceso para determinar errores de sincronizacin. Para las tareas que trabajan mediante colas de mensajes, se trata de detectar errores en el tamao de las zonas de almacenamiento de datos Prueba del sistema: Se prueba el software y hardware trabajando en conjunto
Adems, como este tipo de sistemas administran un gran cantidad de interrupciones, mediante un diagrama de estado transicin y la especificacin de control, se cruza informacin de todas las posibles interrupciones y el proceso que ocurre como consecuencia de las mismas para disear casos de prueba que respondan las siguientes preguntas: Se han asignado y administrado apropiadamente las prioridades de interrupcin? Se administra correctamente el procesamiento para todas las interrupciones? Se ajusta a los requisitos el rendimiento de todos los procedimientos de gestin de interrupciones? Crea problemas de funcionamiento o rendimiento la llegada de un gran volumen de interrupciones en momentos crticos?
4.4.2 ESTRATEGIA DE PRUEBA DEL SOFTWARE

La prueba de software es un conjunto de actividades que pueden ser planificadas por adelantado, mediante algn tipo de esquema. En general, segn Pressman, en la seccin 17.1, de su libro Ingeniera del Software: Un enfoque prctico, 4ta. Edicin, la mayora de esquemas propuestos tienen las siguientes caractersticas: Las pruebas comienza a nivel de mdulos y trabajan hacia fuera hasta integrar todo el sistema; Segn el momento y caractersticas son apropiadas diferentes tcnicas de prueba; La prueba la lleva a cabo el responsable del desarrollo y un grupo independiente de pruebas; y, La prueba y la depuracin son actividades diferentes, pero la depuracin debe ser parte de la estrategia de prueba.
En general, se puede hablar de la aplicacin de los siguientes conceptos: Verificacin: Conjunto de actividades que aseguran que el software implementa correctamente una funcin especfica; y, Validacin: Conjunto de actividades que aseguran que el software construido se ajusta a los requisitos del cliente.
Es importante indicar que la prueba constituye el ltimo bastin desde el que se puede evaluar la calidad de una aplicacin y por ende descubrir los posibles errores pero si la calidad no esta ah antes de comenzar la prueba, no estar cuando est termine. La calidad se incorpora al software durante todo el proceso de ingeniera del software, que incluye la aplicacin adecuada de los mtodos y herramientas, revisiones tcnicas formales efectivas y una slida gestin y medicin, que permiten que la prueba la confirme.
4.4.5.1ORGANIZACINDELAPRUEBADELSOFTWARE
Los siguientes conceptos deben ser descartados al organizar la prueba del software: El responsable del desarrollo no debera ser parte del proceso para evitar conflictos de intereses; El software no debe ser probado por extraos para evitar que los mismos lo hagan de forma despiadada; y, Los encargados de la prueba solo deben incorporarse a las actividades del proyecto cuando comience la etapa de prueba.
En realidad, se aplica lo siguiente: El responsable del desarrollo es responsable de probar los mdulos del programa y en muchos casos tambin se encargar de probar la integracin de estos mdulos. Es importante estructurar un Grupo independiente de prueba (GIP), que evita los conflictos de intereses, el mismo que debe estar implicado durante el proceso de especificacin y a lo largo del mismo (planificacin y especificacin de los procedimientos de prueba), en especial para proyectos grandes. En muchos casos, el GIP depende del equipo de garanta de calidad de software, para que tenga un buen grado de independencia; y, El responsable del desarrollo no entrega simplemente la aplicacin al GIP y se desentiende. Ambos deben trabajar estrechamente a lo largo del proyecto de software para asegurar pruebas exhaustivas y los cambios correspondientes.
Tanto el proceso de ingeniera de software como la estrategia de prueba del software pueden verse como la espiral que se detalla en la figura 4.5, que permite determinar el tipo de pruebas a realizar y su orden de precedencia, que se detallan a continuacin.
FIGURA 4.5: ESTRATEGIA DE PRUEBA
Ingeniera del sistema Requisitos Diseo Codificacin
S R D C U I V ST Prueba de unidad Prueba de integracin Prueba de validacin Prueba de sistema

9
FUENTE: Ingeniera del Software: Un enfoque prctico, Pressman S. Roger, Captulo 17, Figura 17.2, pgina 327, 4ta. Edicin. Prueba de Unidad: Comienza en el vrtice del espiral y se centra en la implementacin de la codificacin de cada unidad de software (mdulos), asegurando que funcione adecuadamente como una unidad. En este nivel se hace un uso intensivo de las pruebas de caja blanca, ejercitando los caminos especficos de la estructura de control del mdulo; Prueba de integracin: Se centra en los aspectos asociados con el doble problema de la verificacin del diseo y la construccin de la arquitectura del software. En este nivel se usen de forma intensiva pruebas de caja negra y de ser necesarias, algunas pruebas de caja blanca; Prueba de validacin: En este nivel se validan los requisitos funcionales, de comportamiento y de rendimientos establecidos como parte del anlisis, comparndolos con el sistema construido. Se usan exclusivamente tcnicas de prueba de caja negra; y, Prueba del sistema: Para terminar se prueban como un todo el software y los elementos externos asociados, tales como hardware, bases de datos, personal y etc.
4.4.2.2CRITERIOSPARACOMPLETARLAPRUEBADELSOFTWARE
Actualmente, no existe un parmetro formal que permita asegurar que la prueba de un software ha terminado, pero mediante modelado estadstico y la teora de fiabilidad del software, se pueden desarrollar modelos de fallos de software (que se descubren durante la prueba) como una funcin del tiempo de ejecucin como el modelo logartmico de Poisson de tiempo de ejecucin, que presenta la siguiente forma: f (t) = (1 / p) ln (lopt +1) donde f(t) = nmero acumulado de fallos que se espera que se produzcan una vez que se ha probado el software durante una cierta cantidad de tiempo de ejecucin t. lo = la intensidad de fallos inicial del software (fallos por unidad de tiempo) al principio de la prueba p = la reduccin exponencial de intensidad de fallo a medida que se encuentran los errores y se van haciendo las correcciones
derivando f(t) se puede obtener la intensidad de fallos instantneos, l(t) l(t) = lo / (lopt + 1) Usando est ltima ecuacin se puede predecir la disminucin de errores a medida que avanza la prueba, comparando si los valores reales recopilados durante la prueba y el modelo logartmico de Poisson de tiempo de ejecucin estn razonablemente cercanos, sobre un nmero de puntos de datos. De ser este el caso, el modelo puede predecir el tiempo de prueba de total requerido para alcanzar un intensidad de fallos aceptablemente baja.
4.4.2.3ASPECTOSESTRATGICOSPREVIOS
Segn Tom Gilb, citado por Pressman en la pgina 329 de Ingeniera del Software: Un enfoque estructurado, cuarta edicin, se debe considerar los siguientes puntos si se piensa implementar con xito una estrategia de prueba de software: Especificar los requisitos del producto de manera cuantificable mucho antes de que comiencen las pruebas: Una buena estrategia evala adems aspectos asociados a la calidad como transportabilidad, facilidad de mantenimiento y facilidad de uso. Establecer los objetivos de la prueba de manera explcita: Efectividad de la prueba, la cobertura de la prueba, tiempo medio de fallos, coste de encontrar y arreglar errores, frecuencia de ocurrencia de fallos, horas de trabajo por prueba de regresin, etc. Comprender que usuarios va a tener el software y desarrollar un perfil para cada categora de usuario: Determinar casos de escenarios posibles para cada tipo de usuario. Desarrollar un plan de prueba que haga hincapi en la prueba de ciclo rpido: Ciclos rpidos (2 por ciento del esfuerzo del proyecto) de incrementos de funcionalidad o mejora de la calidad tiles para el cliente y que se puedan probar en el terreno. Construir un software robusto diseado para probarse a si mismo: El software debera ser capaz de diagnosticar ciertos tipos de errores y su diseo debera incluir pruebas automatizadas y pruebas de regresin. Usar revisiones tcnicas formales como filtro antes de la prueba Llevar a cabo revisiones tcnicas formales para evaluar la estrategia de prueba y los propios casos de prueba: Las revisiones tcnicas formales pueden descubrir inconsistencias, omisiones y errores claros en el enfoque de la prueba, lo que ahorra tiempo y mejora la calidad del producto. Desarrollar un enfoque de mejora continua al proceso de prueba: El proceso de prueba debera ser medido.
10
4.4.2.4PRUEBADEUNIDAD
La prueba de unidad se puede llevar en paralelo en cada mdulo y consta de las siguientes clases de pruebas listadas en orden de realizacin: Interfaz: Se prueba el flujo de datos de la interfaz del mdulo, puesto que si los datos no ingresan correctamente las dems pruebas no tienen sentido. En la pgina nmero 331 de Ingeniera del Software: Un enfoque estructurado, cuarta edicin, de Roger Pressman, se lista un conjunto de preguntas base para realizar est prueba, tanto al nivel de interfaz de usuario como externa, que sugerimos se revise. Estructuras de datos locales: Se disean casos de prueba para descubrir errores de los siguientes tipos: tipificacin impropia o inconsistente, inicializacin o valores implcitos errneos, nombres de variables incorrectos, tipos de datos inconsistentes, y, excepciones de desbordamiento por arriba o por abajo, o de direccionamiento. Adems se debe tratar de comprobar el impacto de los datos globales sobre los mdulos. Caminos independientes: Se aplican pruebas del camino bsico y de bucles para descubrir errores como: precedencia aritmtica incorrecta o mal interpretada, operaciones de modo mezcladas, inicializaciones incorrectas, falta de precisin, incorrecta representacin simblica de una expresin, comparaciones entre tipos de datos distintos, variables o comparaciones incorrectas, terminacin de bucles inapropiada o inexistente, fallo de salida cuando se encuentra iteracin divergente, bucles que manejan variables modificadas de forma inapropiada. Caminos de manejo de errores: Se debe contar con una ruta de accin ante errores claramente establecida que evite: descripcin ininteligible del error, errores que sealados que no corresponden, que el sistema intervenga antes del mecanismo de manejo de errores, proceso de condicin excepcional incorrecto, y, descripcin no clara del error. Condiciones lmite: Esta prueba talvez es la ms importante. Se debe realizar casos de prueba que ejerciten las estructuras de datos, el flujo de control y los valores de los datos por debajo, en y por encima de los mximos y los mnimos determinados.
4.4.2.5PRUEBADEINTEGRACION
La prueba de integracin es una tcnica sistemtica cuyo objetivo es coger los mdulos probados mediante la prueba de unidad y construir con ellos una estructura de programa que este de acuerdo con el diseo planteado tratando de detectar los errores asociados al iteracin. Normalmente se realiza est actividad mediante un enfoque de integracin vertical, es decir, el programa se construye y prueba en segmentos pequeos en los que es ms fcil de aislar y corregir errores, se pueden probar completamente las interfaces y se puede aplicar un enfoque sistemtico. Se usan bsicamente tres estrategias: Integracin descendente; Integracin ascendente; y, Prueba de regresin.
A. INTEGRACIN DESCENDENTE
Se integran los mdulos movindose hacia abajo de la jerarqua de control, comenzando por el mdulo de control principal, incorporando a los mdulos subordinados bajo alguno de los siguientes enfoques de integracin: Primero en profundidad: Integra todos los mdulos de un camino de control principal de la estructura (ramal casi completo de la estructura), el cual se selecciona de forma arbitraria dependiendo de las caractersticas de la aplicacin. (Figura 4.6: M1, M2 y M5, luego M8 M6) Primero en anchura: Incorpora todos los mdulos directamente subordinados de cada nivel, de forma horizontal (Figura 4.6: M2, M3 Y M4, luego M5, M6, etc.)
FIGURA 4.6: INTEGRACIN DESCENDENTE
11
M1
M2
M3
M4
M5
M6
M7
M8
FUENTE: Ingeniera del Software: Un enfoque prctico, Pressman S. Roger, Captulo 17, Figura 17.7, pgina 333, 4ta. Edicin. El proceso se realiza siguiendo los siguientes pasos: 1. 2. 3. 4. 5. 6. Se usa el mdulo de control principal como controlador de la prueba, disponiendo de resguardos para todos los mdulos directamente subordinados al mdulo de control principal; Dependiendo del enfoque de integracin se van sustituyendo los resguardos subordinados uno a uno por los mdulos reales; Se llevan a cabo pruebas cada vez que se integra un nuevo mdulo; Tras terminar un conjunto de pruebas, se reemplaza otro respaldo con el mdulo real; Se hace la prueba de regresin para asegurarse que no se han introducido errores; y, Retornar al paso 2 hasta construir la estructura del programa completo verificar los puntos de decisin o control principales al principio del proceso de estructura de programa bien fabricada, la toma de decisiones debe darse en los y si existen problemas con esto, es importante encontrarlos cuanto antes. Si se profundidad, se puede ir implementando y demostrando las funciones completas
Esta estrategia es excelente para prueba, considerando que en una niveles superiores de la jerarqua, selecciona el enfoque primero - en del software.
En la prctica esta estrategia puede presentar problemas de logstica al tratar de probar los mdulos superiores con los inferiores, ya que se usan resguardos y puede ser que los mismos no brinden los datos necesarios o se deba esperar a que los mdulos finales estn listos para realizar pruebas reales, aparte de que hacer resguardos implica tiempo.
B. INTEGRACIN ASCENDENTE
Esta estrategia comienza la prueba con los mdulos atmicos de la aplicacin, integrando los mismos hacia arriba de la jerarqua de la misma, con lo que se elimina la necesidad de resguardos. Para aplicarla se siguen los siguientes pasos, como se ve en la figura 4.7: 1. 2. 3. 4. Se combinan los mdulos de bajo nivel en grupos (a veces denominados construcciones); Se escribe un controlador (un programa de control de la prueba) para coordinar la entrada y la salida de los casos de prueba; Se prueba el grupo; y, Se elimina los controladores y se combinan los grupos movindose hacia arriba por la estructura del programa.
FIGURA 4.7: INTEGRACIN ASCENDENTE
12

Mc
Ma
Mb
D1
D2
D3
GRUPO 2 GRUPO 1
GRUPO 3
FUENTE: Ingeniera del Software: Un enfoque prctico, Pressman S. Roger, Captulo 17, Figura 17.9, pgina 335, 4ta. Edicin. El principal inconveniente de este tipo de prueba, es que el programa como un todo no existe hasta que no se haya agregado el ltimo mdulo.
C. PRUEBA DE REGRESION
La prueba de regresin consiste en volver a ejecutar un subconjunto de las pruebas que se han llevado a cabo previo la integracin de un nuevo mdulo a la prueba de integracin, puesto que al aadir un nuevo mdulo, el software cambia, se pueden establecer nuevos caminos de flujo de datos, nuevas entradas y / o salidas, nueva lgica de control y por ende se pueden presentar problemas con funciones que antes trabajaban correctamente. En general, segn Pressman, existen tres clases diferentes de casos de prueba que se realizan durante la prueba de regresin: Una muestra representativa de pruebas que ejercite todas las funciones del software; Pruebas adicionales que se centran en las funciones del software que se van a ver probablemente afectadas por el cambio; y, Pruebas que se centran en los componentes del software que han cambiado.
Es importante indicar que a medida que se aumentan mdulos, el universo de pruebas de regresin puede crecer demasiado, razn por la cual, se debe seleccionar solo aquellas pruebas que se enfoque en una o ms clases de errores de las funciones principales.
D. SUGERENCIAS GENERALES PARA LA APLICACIN DE LA PRUEBA DE INTEGRACION

La estrategia de prueba de integracin a ser seleccionada, depende de las caractersticas del software y a veces de la planificacin del proyecto, considerando las ventajas y desventajas de cada estrategia. Sin embargo, implementar un enfoque combinado, que use la prueba descendente para los niveles superiores de la estructura del programa y la descendente para los niveles subordinados, puede ser la mejor solucin. Es importante que para aplicar la prueba de integracin, se identifiquen los mdulos crticos, que son aquellos que cumplen algunas de las siguientes caractersticas: Est dirigido a varios requisitos del software; Tiene un mayor nivel de control (cercano o en l pice de la estructura de control); Es complejo o propenso a errores; y, Tiene unos requisitos de rendimiento muy definidos
Estos mdulos deben ser probados lo antes posible y las pruebas de regresin se deben centrar en su funcionamiento.
4.4.2.6PRUEBADEVALIDACION
La prueba de validacin se realiza al finalizar la prueba de integracin y consiste en determinar que el software funcione de acuerdo a las expectativas razonables del cliente, que por lo general se definen en la seccin Criterios de validacin del documento de Especificacin de requisitos de Software
13
Se debe desarrollar un plan que define las clases de pruebas de caja negra a efectuarse, los procedimientos y los casos de pruebas de acuerdo a los criterios de validacin. Si se descubre desviaciones de las especificaciones se crea una lista de deficiencias y se negocia con el cliente un mtodo para resolver las mismas, puesto que a estas alturas del proceso, raramente se pueden corregir este tipo de errores cumpliendo los plazos previstos inicialmente. Para finalizar esta prueba se debe determinar el estado de la configuracin del software, tema que se expondr ms adelante, para determinar si se cuenta con los elementos suficientes y necesarios que faciliten el mantenimiento durante el ciclo de vida del software.
A. PRUEBAS ALFA Y BETA

Cuando se desarrolla software para uso genrico, es decir varios usuarios diferentes lo usarn, es sumamente difcil realizar un conjunto de pruebas de aceptacin especficas como las que se hace con un producto a la medida, en este caso se acostumbra a desarrollar el siguiente esquema de pruebas: Pruebas alfa: Prueba llevada a cabo en el lugar de desarrollo pero por un usuario final, que es supervisada por el desarrollador, mismo que registra los errores y problemas de uso, y, Pruebas beta: Pruebas de uso llevadas a cabo por un conjunto diverso de usuarios finales, seleccionados o invitados a participar, en sus lugares de trabajo, sin el control de los desarrolladores. Los usuarios deben realizar informes de todos los problemas encontrados y remitirlos a los desarrolladores, mismos que realizarn las modificaciones necesarias para el lanzamiento final de la aplicacin.
4.4.2.7PRUEBADELSISTEMA
Un software no es un elemento que funciona independientemente sino que es parte de un conjunto de elementos como hardware, telecomunicaciones, etc., que si funcionan mal o no tienen las caractersticas mnimas necesarias, pueden echar al traste cualquier sistema, por bien que este desarrollado. Para evitar esto deben realizarse los siguientes tipos de pruebas: Prueba de recuperacin; Prueba de seguridad; Prueba de resistencia; y, Prueba de rendimiento.
A. PRUEBA DE RECUPERACION
La prueba de recuperacin consiste en forzar un fallo de sistema y determinar si el software puede recuperarse del mismo. Si la recuperacin se puede hacer de forma automtica (sistemas RAID, servidores redundantes, etc) debe evaluarse la correccin de la inicializacin, mecanismos de recuperacin de estado y datos del sistema. Si la recuperacin debe ser hecha de forma manual, debe determinarse si el tiempo medio de reparacin est en lmites aceptables.
B. PRUEBA DE SEGURIDAD
La prueba de seguridad intenta verificar que los mecanismos de proteccin incorporados en el sistema y las polticas asociadas, que incluye el control de no presencia de puertas traseras, podrn protegerlo de accesos impropios. El desarrollador debe hacer el papel de un intruso que desea ingresar al sistema y realizar todo el conjunto de actividades posibles que determinen si el sistema es seguro o no. De ser necesario, se debe considerar la contratacin de personal especializado en este tipo de pruebas que determinen si el conjunto del sistema: servidores, red, clientes, aplicaciones, polticas, son seguros. Es importante considerar que con tiempo y recursos suficientes, una buena prueba de seguridad logra acceder al sistema, lo que implica que el papel del diseador consiste en conseguir que el costo de acceder ilegalmente sea mayor que la informacin obtenida.
C. PRUEBA DE RESISTENCIA
La prueba de resistencia sirve para determinar si las aplicaciones pueden funcionar en situaciones anormales, como demanda de recursos en cantidad, frecuencia o volmenes extraos. Esto implica disear pruebas como: Desarrollo de rutinas que genera ms interrupciones por segundo que las normales; Incremento extremo de frecuencia de ingreso de datos de inicio para comprobar el funcionamiento de las funciones de entrada; Ejecutar casos de prueba que se sabe de antemano que requieren el mximo de memoria u otros recursos; Disear casos de prueba que produzcan excesivas bsquedas de datos residentes en disco; Desarrollar pruebas de sensibilidad, para determinar si rangos de datos extremadamente pequeos dentro de los lmites de una entrada vlida puede producir procesos exagerados, errneos o que degraden el rendimiento; y,
14
Uso del sistema con diferentes tipos de equipos que representen el posible universo de configuraciones donde funcionar la aplicacin.
D. PRUEBA DE RENDIMIENTO
La prueba de rendimiento permite probar el rendimiento del software en tiempo de ejecucin dentro del contexto de un sistema integrado. Este tipo de pruebas deben realizarse durante todo el proceso de prueba. Cuando el sistema ya se encuentra totalmente integrado, por lo general se realizan este tipo de pruebas conjuntamente con las de resistencia y requieren instrumentos tanto de software como de hardware para realizarlas. Muchas veces se requiere medir la utilizacin de recursos (ciclos de procesador, paginacin, etc.) de modo exacto, para determinar si la aplicacin presente degradaciones y posibles fallos de sistemas. Este tipo de pruebas son crticas para sistemas en tiempo real y empotrados.
E. ESTRATEGIA DE DESARROLLO DE LA PRUEBA DE SISTEMA

Como realizar una prueba de sistema implica no solamente trabajar con los desarrolladores de las aplicaciones, sino tambin con responsables de otros elementos del sistema, como administradores de red, telecomunicaciones, hardware, etc, Roger Pressman en la pgina 338 de su libro Ingeniera del Software: Un enfoque prctico, 4ta. Edicin, recomienda seguir las siguientes directrices para desarrollar de forma eficiente este tipo de pruebas y evitarse problemas con el resto de personas involucradas: Disear caminos de manejo de errores que prueben toda la informacin procedente de otros elementos del sistema; Llevar a cabo una serie de pruebas que simulen la presencia de datos en mal estado o de otros posibles errores en la interfaz del software; Registrar los resultados de las pruebas como evidencia en caso de que se le culpe; y, Participar en la planificacin y el diseo de pruebas del sistema para asegurarse de que el software se prueba de forma adecuada.
4.4.2.8DOCUMENTACIONDELAPRUEBA
Las pruebas a desarrollarse para determinar la funcionalidad del software, se determinan al final de la fase de anlisis de requerimientos y se van ajustando conforme pasan la fase de Diseo, Pruebas como tal e Implementacin. Tanto el Documento de Especificacin del sistema como el de Especificacin de Diseo, sirven de base para establecer el conjunto de pruebas a desarrollar. Los resultados obtenidos en las fases de pruebas e implementacin sirven tambin para ajustar este documento. Dependiendo de la fase, los responsables de realizar el documento pueden variar y los objetivos diferir de alguna forma. A menos que el desarrollo sea interno o se venda una licencia de uso exclusivo, este documento es de uso exclusivo del arquitecto de software, jefe de proyecto, ingeniero de software, desarrolladores y revisores. De igual forma existen varios formatos disponibles (IEEE, NASA , Pressman, Brueggue) y el que detallamos a continuacin resume las mejores caractersticas de varios de ellos. I. Introduccin a. Propsito de las pruebas b. Tipos de pruebas a realizar c. Definiciones, Acrnimos y Abreviaturas: Todas las que se va a utilizar durante el desarrollo del documento e incluso el funcionamiento del sistema. d. Responsables Relacin con otros documentos: Se describe brevemente la relacin de este documento con otros. Arquitectura del sistema a probar: Descripcin rpida de los mdulos a ser probados. Incluye matriz que relacione cada requerimiento y especificacin funcional con uno o ms casos de prueba. Caractersticas a probar o no: Resumen general de lo que se piensa probar o no y las razones justificativas correspondientes Criterios de xito o fracaso: Descripcin general de los criterios de xito o fracaso que se usarn para ejecutar este plan de pruebas Aproximacin tcnica: Describe el orden de integracin de las pruebas y el motivo de seleccin de dicho orden. Suspensin o reinicio: Describe los criterios generales para suspender las pruebas asociadas con este plan y los criterios usados para reiniciar estas pruebas Materiales de prueba: Descripcin general del hardware, software, herramientas de prueba, documentos, espacio fsico y otros materiales que sean necesarios Casos de prueba: Para cada caso de prueba se describen los siguientes puntos a. Nombre del caso b. Localizacin: ubicacin lgica donde se realiza la prueba (men, botn, pantalla, directorio, etc.) c. Propsito de la prueba d. Dependencia entre casos e. Criterios de xito o fracaso f. Recursos requeridos: datos, hardware, etc. g. Detalle especifico del ingreso
II. III. IV. V. VI. VII. VIII. IX.
15

h. Procedimiento de prueba i. Detalle especfico de la salida resultante j. Anlisis de resultados Plan de prueba: Planificacin de las casos de prueba a ejecutar Resultados generales obtenidos Anexos
X. XI. XII.
Es importante indicar que el plan de prueba describe la estrategia general para la integracin, lo que implica dividir al software en fases y construcciones que traten caractersticas funcionales y de comportamiento del software para ser probado. En todas las fases de prueba deben seguirse los siguientes criterios con sus respectivas pruebas: Integridad de la interfaz: Prueba de interfaces internas y externas a medida que se incorpora cada mdulo o grupo a la estructura Validez funcional: Pruebas diseadas para descubrir errores funcionales Contenido de la informacin: Pruebas diseadas para descubrir errores asociados con las estructuras de datos globales o locales Rendimiento: Pruebas diseadas para verificar los lmites de rendimiento durante el diseo del software
4.4.2.9ELARTEDELADEPURACION
Una vez que se ha detectado un problema en el software, se procede a depurarlo, es decir, corregirlo. Si bien es cierto existen tcnicas e incluso herramientas que permitan mejorar este proceso, sigue teniendo mucho de arte. Los resultados de una prueba son una indicacin sintomtica del error, es decir, el resultado no necesariamente esta relacionado con la causa interna del error de forma obvia, e incluso al resolver el mismo se pueden causar errores en otras partes de la aplicacin. En general existen 3 enfoques para realizar la depuracin de un aplicacin: Fuerza bruta; Vuelta atrs; y, Eliminacin de causas
A. FUERZA BRUTA
Este enfoque es quiz el ms comn y el menos eficiente. Por lo general se aplica cuando todo lo dems falla. Se realizan volcados de memoria, trazas de ejecucin y cargan multitud de mensajes con la esperanza que con la gran cantidad de informacin obtenida se encuentra alguna pista de llegar al error. Esto puede ser til, pero es el camino menos recomendable
B. VUELTA ATRAS
Este enfoque ms estructurado puede usarse con xito en programas pequeos. A partir del sitio donde se descubri el sntoma, se recorre manualmente hacia atrs el cdigo fuente hasta que se llega a la posicin de error. Sin embargo, mientras aumenta el nmero de lneas de cdigo, el seguimiento de los caminos posibles puede hacerse inmanejable.
C. ELIMINACION DE CAUSAS
La eliminacin de causas es el enfoque ms eficiente para depurar un programa. Los datos relacionados con la ocurrencia del error se organizan de forma que permita aislar las posibles causas y mediante induccin o deduccin y particin binaria, se llega a hiptesis de causa que usan los datos recolectados para probar o no la hiptesis. Alternativamente, se lista todas las posibles causas y se llevan pruebas para eliminar cada una. Si se determina que alguna hiptesis de causa parece prometedora, se refinan los datos con el fin de tratar de aislar el error
D. RECOMENDACIONES ADICIONALES
Independientemente del enfoque usado para depurar un error, recomendamos considerar lo siguiente: Muchas veces, la carga de estrs producida por el intento de resolver el error hace que nuestro cansancio mental no permita encontrar fcilmente una solucin. En estos casos, es preferible tomar un pequeo descanso mental realizando alguna actividad diferente para retomar con la mente ms despejada la solucin del problema; Dos cabezas piensan mejor que una. Recibir ayuda de otro miembro del equipo puede agilitar el proceso de resolucin del problema, ms an si la otra persona viene con la mente fresca; La correccin de un error puede implicar el surgimiento de otros, entonces una vez que se tenga lista la posible solucin, antes de aplicarla es recomendable preguntarse lo siguiente: Se repite la causa del error en otra parte del programa?, Cul es el siguiente error que se podra presentar a raz de la correccin que se va a realizar? y Qu podramos haber hecho para prevenir este error la primera vez?
4.5 IMPLANTACION (CONVERSIN)

Ing. Mario Santamara 16
Por lo general al hablar de modelos de desarrollo de software se considera cuatro grandes fases: Anlisis, diseo, codificacin y prueba. Sin embargo, desde un punto de vista sistmico, se debe considerar 2 fases adicionales: la implantacin (conversin) y la produccin y mantenimiento, como se ve en la figura 4.1
Produccin Y Mantenimiento
ANALISIS
DISEO CONVERSION
PRUEBA
PROGRAMACION
ORGANIZACION
FIGURA 4.1: PROCESO DE DESARROLLO DE SISTEMAS
FUENTE: Management Information Systems: New Approaches to Organization & Technology, Kenneth C. Laudon, Jane P. Laudon, Captulo 11, Pgina 401, grfico 11.5, 5ta. Edicin en ingles. La implantacin (conversin) es el proceso de cambiar desde un sistema antiguo hacia un nuevo sistema2, que no es otra cosa que alimentar de datos al nuevo sistema, tomando en cuenta que hablar de un sistema antiguo incluye sistemas de carcter manual. Existen bsicamente cuatro estrategias que permiten que este proceso se realice de forma eficiente y son: En paralelo: Cuando se utiliza ambos sistemas al mismo tiempo hasta que el nuevo sistema se muestre estable. Este esquema es ms seguro y permite realizar comparaciones de resultados, pero se debe considerar que el nuevo sistema talvez contempla procesos que el anterior no tena y que se requiere el doble de tiempo. Cambio directo: Cuando se determina que el nuevo sistema debe reemplazar por completo al anterior y se usa el mismo en vez del otro para el desarrollo de actividades diarias. Esta estrategia es la ms riesgosa pero obliga a que la organizacin acepte el cambio. Estudio piloto: Cuando se introduce el nuevo sistema en un rea limitada de la organizacin hasta probar la funcionalidad del mismo, luego de lo cual se propaga el sistema al resto de la organizacin. Este tipo de estrategia presente un nivel de riesgo intermedio, pero su eficiencia depende de la correcta seleccin del rea de prueba. Por fases: Cuando el sistema es introducido en la organizacin en etapas basadas en las funciones del mismo o las reas de la organizacin.
A ms de determinar una estrategia de conversin, es importante contar con: Plan de conversin: Que determine el calendario de actividades que se requieren para instalar el nuevo sistema; Documentacin: Tcnica y de usuario que determine de forma clara y precisa el funcionamiento y uso del sistema; y, Esquema de capacitacin: Que determine los mecanismos de capacitacin de uso del sistema, en funcin de los niveles de uso y acceso, nmero de participantes, nmero de instructores y materiales necesarios.
4.5 PRODUCCION
Se considera que un sistema est en produccin luego de ha sido instalado completamente y la fase de conversin ha concluido, lo que no implica que el sistema sea un esttico, puesto que se pueden presentar cambios debido, entre otros a:
2
Kenneth C. Laudon, JaneP. Laudon, Management Information Systems, NewApproaches toOrganization and Technology,Captulo11,Pgina406,5ta.Edicin.Traduccinliteraldeltextoeningls.
17

Determinacin que no se consideraron algunos requerimientos necesarios que deberan ser implementados; Determinacin de que el sistema no responde de forma eficiente a los requerimientos del usuario final; Falta de parametrizacin del sistema que impide la adaptacin del mismo a nuevas normativas legales o cambio inesperado de las mismas que no puede ser soportado por el esquema de parametrizacin usado; Nuevos requerimientos; y Cambio de hardware, software, documentacin.
4.6 MANTENIMIENTO
El mantenimiento esta conformado por los cambios en hardware, software, documentacin o procedimientos de un sistema en produccin que se realizan para corregir errores, mejorar procesos o implementar nuevos requerimientos y si estos cambios no son implementados de forma eficiente, el sistema puede dejar de ser til y los costos incrementarse innecesariamente. La tabla 4.1, detalla algunas de las estadsticas asociados con esta fase que pueden darnos una idea de la complejidad de esta tarea.
TABLA 4.1: EL PROBLEMA DEL MANTENIMIENTO Porcentaje anual de horas que dedica el personal
Mantenimiento y ampliacin del sistema actual Desarrollo de nuevos sistemas Otros El 20% de los recursos .... 48.0 % 46.1 % 5.9 %
Frecuencia de actividades
Errores emergencias Cambio datos, entradas, archivos, hardware Mejora ampliaciones de usuario, eficiencia, documentacin, etc. Otros 17.4 % 18.2 % 60.3 % 4.1 %
Fuente: Bennett P. Lientz y E. Burton Swanson, Software Maintenance Management, Reading, MA: Addison Wesley 1980; y L. H. Putnam y A. Fitzsimmons, Estimating Software Costs, Datamation, Septiembre 1979, Octubre 1979 , y Noviembre 1979.
FUENTE: Management Information Systems: New Approaches to Organization & Technology, Kenneth C. Laudon, Jane P. Laudon, Captulo 13, Pgina 477, tabla 13.1, 5ta. Edicin en ingles. Entonces, para poder manejar de forma eficiente este proceso se debe desarrollar la Gestin de Configuracin del Software (GCS) que es una actividad de autoproteccin que se aplica a lo largo de todo el proceso de ingeniera de software que permite: Identificar los cambios; Controlar los mismos; Garantizar que los mismos se implementen de forma adecuada; y, Informar de los cambios a todos los involucrados.
18

Unid. 4 - MÉTODOS CONVENCIONALES DE LA ING. DE SW

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Unid. 4 - MÉTODOS CONVENCIONALES DE LA ING. DE SW

Transféré par

Droits d'auteur :

Formats disponibles

Pontificia Universidad Catlica del Ecuador

Ing. Mario Santamara

Pontificia Universidad Catlica del Ecuador

UNIDAD 4: METODOS CONVENCIONALES DE LA INGENIERIA DE SOTWARE

4.4.1 FUNDAMENTOS DE LAS PRUEBAS DE SOFTWARE

Ing. Mario Santamara

Pontificia Universidad Catlica del Ecuador

4.4.2 PRUEBAS DE CAJA BLANCA

Ing. Mario Santamara

Pontificia Universidad Catlica del Ecuador

La figura 4.2 muestra un ejemplo de aplicacin

FIGURA 4.2: MATRIZ DE GRAFOS

Pontificia Universidad Catlica del Ecuador

Matriz de grafo Conectado al nodo 1 2 3 4 5 1 a 2 3 d b 4 c f 5 g e

Ing. Mario Santamara

Pontificia Universidad Catlica del Ecuador

FIGURA 4.3: TIPOS DE BUCLES

4.4.3 PRUEBAS DE CAJA NEGRA

Ing. Mario Santamara

Pontificia Universidad Catlica del Ecuador

FIGURA 4.4: NOTACIN DE GRAFOS

Ing. Mario Santamara

Pontificia Universidad Catlica del Ecuador

4.4.4 PRUEBA DE ENTORNOS ESPECIALIZADOS

Ing. Mario Santamara

Pontificia Universidad Catlica del Ecuador

Ing. Mario Santamara

Pontificia Universidad Catlica del Ecuador

4.4.2 ESTRATEGIA DE PRUEBA DEL SOFTWARE

FIGURA 4.5: ESTRATEGIA DE PRUEBA

Ingeniera del sistema Requisitos Diseo Codificacin

S R D C U I V ST Prueba de unidad Prueba de integracin Prueba de validacin Prueba de sistema

Ing. Mario Santamara

Pontificia Universidad Catlica del Ecuador

Ing. Mario Santamara

Pontificia Universidad Catlica del Ecuador

FIGURA 4.6: INTEGRACIN DESCENDENTE

Ing. Mario Santamara

Pontificia Universidad Catlica del Ecuador

FIGURA 4.7: INTEGRACIN ASCENDENTE

Ing. Mario Santamara

Pontificia Universidad Catlica del Ecuador

D. SUGERENCIAS GENERALES PARA LA APLICACIN DE LA PRUEBA DE INTEGRACION

Ing. Mario Santamara

Pontificia Universidad Catlica del Ecuador

A. PRUEBAS ALFA Y BETA

Ing. Mario Santamara

Pontificia Universidad Catlica del Ecuador

E. ESTRATEGIA DE DESARROLLO DE LA PRUEBA DE SISTEMA

II. III. IV. V. VI. VII. VIII. IX.

Ing. Mario Santamara

Pontificia Universidad Catlica del Ecuador

4.5 IMPLANTACION (CONVERSIN)

Pontificia Universidad Catlica del Ecuador

Ing. Mario Santamara

Pontificia Universidad Catlica del Ecuador

Ing. Mario Santamara

Vous aimerez peut-être aussi