Sie sind auf Seite 1von 23

4. Verificacin y validacin.

La verificacin y validacin es el nombre que se da a los procesos de comprobacin y anlisis que aseguran que el software que se desarrolla est acorde a su especificacin y cumple las necesidades de los clientes. La V&V es un proceso de ciclo de vida completo. Inicia con las revisiones de los requerimientos y contina con las revisiones del diseo y las inspecciones del cdigo hasta la prueba del producto. Verificacin: Estamos construyendo el producto correctamente? El papel de la verificacin comprende comprobar que el software est de acuerdo con su especificacin. Se comprueba que el sistema cumple los requerimientos funcionales y no funcionales que se le han especificado. La verificacin y la validacin no son la misma cosa, aunque es muy fcil confundirlas, Boehm (1979) expres la diferencia entre ellas de forma sucinta: Validacin: Estamos construyendo el producto concreto? La validacin es un proceso ms general. Se debe asegurar que el software cumple las expectativas del cliente. Va ms all de comprobar si el sistema est acorde con su especificacin, para probar que el software hace lo que el usuario Es importante llevar a cabo la validacin de los requerimientos del sistema de forma inicial. Es fcil cometer errores y omisiones durante la fase de anlisis de requerimientos del sistema y, en tales casos, el software final no cumplir las expectativas de los clientes. Sin embargo, en la realidad, la validacin de los requerimientos no puede descubrir todos los problemas que presenta la aplicacin. Algunos defectos en los requerimientos solo pueden descubrirse cuando la implementacin del sistema es completa. Dentro del proceso de Verificacin y validacin se utilizan dos tcnicas de comprobacin y anlisis de sistemas: 1. Las inspecciones del software analizan y comprueban las representaciones del sistema como el documento de requerimientos, los diagramas de diseo y el cdigo fuente del programa. Se aplica a todas las etapas del proceso de desarrollo. Las inspecciones se complementan con algn tipo de anlisis automtico del texto fuente o de los documentos asociados. Las inspecciones del software y los anlisis automatizados son tcnicas de verificacin y validacin estticas puesto que no requieren que el sistema se ejecute. 2. Las pruebas del software consiste en contrastar las respuestas de una implementacin del software a series de datos de prueba y examinar las respuestas del software y su comportamiento operacional, para comprobar que se desempee conforme a lo requerido. Llevar a cabo las pruebas es una tcnica dinmica de la verificacin y validacin ya que requiere disponer de un prototipo ejecutable del sistema.

4.1. Pruebas. Las pruebas del software consisten en contrastar las respuestas de una implementacin del software a series de datos de prueba y examinar las respuestas del software y su comportamiento operacional, para comprobar que se desempee conforme a lo requerido. Llevar a cabo las pruebas es una tcnica dinmica de la verificacin y validacin ya que requiere disponer de un prototipo ejecutable del sistema. 4.1. Objetivo. Detectar las fallas probables que tenga nuestro software y mejorarlas y as lograr tener existo en su aplicacin y ejecucin. 4.2. Justificacin. Tener la certeza de que nuestro software este trabajado bien y no tendr errores. 4.2. Tipos de pruebas. La confirmacin de un sistema de software es un proceso continuo en cada etapa del ciclo de vida del software. La prueba de los programas sigue siendo la tcnica de confirmacin de sistemas ms utilizada. La prueba de los programas es parte del proceso de confirmacin que suele realizarse durante la aplicacin y tambin, en una forma distinta, cuando este ha terminado. La prueba consiste en ejercitar el programa utilizando datos similares a los datos reales que harn de ser ejecutados por el programa, observar los resultados y deducir la existencia de errores o insuficiencias del programa a partir de las anomalas de este resultado. En ocasiones, se piensa que las pruebas y la depuracin de programas son una misma cosa. Aunque estn muy relacionadas, en realidad son procesos distintos. La prueba es el proceso de establecer la existencia de errores en el programa. Depuracin es el proceso de localizar dnde se produjeron esos errores y corregir el cdigo incorrecto. Es muy importante comprender que la prueba nunca demuestra que un programa es correcto. Siempre es posible que existan errores aun despus de la prueba ms completa. La prueba de programas slo puede demostrar la presencia de errores en un programa, no su ausencia. De acuerdo con Myers, se considera prueba acertada aquella que establece la presencia de uno o ms errores en el software objeto de la prueba. La prueba de programas es un proceso destructivo. Se disea para hacer que el comportamiento de un programa sea distinto del que intentaba su diseador o aplicador. Como es una caracterstica humana natural que un individuo tenga cierta afinidad con los objetos que ha construido, el programador responsable de la aplicacin del sistema no es la persona ms

apropiada para probar un programa. Psicolgicamente, el programador no querr destruir su creacin, lo cual har que, de manera consciente o inconsciente, elija pruebas que fallan, por lo que no sern adecuadas para demostrar la presencia de errores en el sistema. Flujo de la Informacin de la Prueba Se proporcionan dos clases de entradas al proceso de prueba: Una configuracin del software que incluye la Especificacin de requerimientos, la Especificacin de diseo y el Cdigo fuente; y en Una Configuracin de prueba que incluye un Plan y Procedimiento de prueba, casos de prueba y resultados esperados. En realidad la configuracin de prueba es un subconjunto de la configuracin del software cuando se considera el proceso de ingeniera del software completo.

Se lleva a cabo la prueba y se evala los resultados. O sea, se comparan los resultados de la prueba con los esperados. Cuando se descubren datos errneos, esto indica la existencia de un error y comienza la depuracin. A medida que se van recopilando y evaluando los resultados de la prueba, comienza a vislumbrarse una medida cualitativa de la calidad y fiabilidad del software. Si se encuentran con regularidad errores serios que requieren modificaciones en el diseo; la calidad y la fiabilidad del software queda en entredicho, siendo necesarias posteriores pruebas. Si, por otro lado el funcionamiento del software parece ser correcto y los errores que se encuentran son de fcil correccin, se puede sacar dos conclusiones: La calidad y la fiabilidad del software son aceptables. Las pruebas son inadecuadas para descubrir errores serios.

Finalmente, si la prueba no descubre errores, quedar la sospecha que la configuracin de la prueba no ha sido la ms ptima y que los errores estn escondidos en el software. Estos defectos sern descubiertos por el usuario y reparados por el profesional en la etapa de mantenimiento con un costo por arreglo que puede ser entre 40 y 60 veces superior al costo por arreglo en la fase de desarrollo. Diseo de casos de prueba Cualquier producto de ingeniera puede ser probado de una de dos formas:

Conociendo la funcin especfica para la que fue diseado el producto, se pueden llevar a cabo pruebas que demuestren que cada funcin es completamente operativa.

Conociendo el funcionamiento del producto, se puede desarrollar pruebas que aseguren que todas las piezas encajan, o sea, que la operacin interna se ajusta a las especificaciones y que todos los componentes internos se han comprobado en forma adecuada.

La primera aproximacin de prueba se denomina Prueba de la caja negra y la segunda Prueba de la caja blanca. Prueba de la Caja Blanca La prueba de la caja blanca es un mtodo de diseo de casos de prueba que usa la estructura de control del diseo procedimental para derivar los casos de prueba. Mediante los mtodos de prueba de la caja blanca el ingeniero del software puede derivar casos de prueba que:

Garanticen que se ejercitan al menos una vez todos los caminos independientes de cada mdulo. Se ejercitan todas las decisiones lgicas en sus caras verdaderas y falsas. Se ejecutan todos los bucles en sus lmites y con sus lmites operacionales. Se ejercitan las estructuras de datos internas para asegurar su validez.

En estas encrucijadas se puede exponer una pregunta razonable: Por qu gastar tiempo y energa probando y preocupndose de las minuciosidades lgicas cuando podramos gastar mejor el esfuerzo asegurando que se han alcanzado los requerimientos del programa?. La respuesta se encuentra en la naturaleza misma de los defectos del software.

Los errores lgicos y las suposiciones incorrectas son inversamente proporcionales a la probabilidad de que se ejecute un camino del programa. Los errores tienden a producirse en nuestro trabajo cuando diseamos o implementamos funciones, condiciones o controles que se encuentran fuera del normal. El procedimiento habitual tiende a hacer ms comprensible, mientras que el procesamiento de casos especiales tiende a caer en el caos. A menudo creemos que un camino lgico tiene pocas posibilidades de ejecutarse cuando, de hecho, se puede ejecutar de forma regular. El flujo lgico de un programa a veces no es nada intuitivo, lo que significa que nuestras suposiciones intuitivas sobre el flujo de control y los datos nos pueden llevar a tener errores de diseo que solo se descubren cuando comienza la prueba del camino.

Los errores tipogrficos son aleatorios. Cuando se traduce un programa a cdigo fuente de un lenguaje de programacin, es muy probable que se den algunos errores de escritura. Muchos sern descubiertos por los mecanismos de comprobacin de sintaxis, pero otros permanecern indetectados hasta que comience la prueba. Es igual de probable que haya un error tipogrfico en un oscuro camino lgico que en un camino principal.

Cada una de estas razones nos da un argumento para llevar a cabo las pruebas de caja blanca. La prueba de caja negra, sin tener en cuenta como sea de completa, puede pasarse los tipos de errores que acabamos de sealar. Como estableci Beizer: Los errores se esconden en los rincones y se aglomeran en los lmites. Es mucho ms fcil de descubrirlos con la prueba de caja blanca. Pruebas del Camino Bsico La prueba del camino bsico es una tcnica de prueba de la caja blanca propuesta inicialmente por Tom McCabe. El mtodo del camino bsico permite al diseador de casos de prueba derivar una medida de complejidad lgica de un diseo procedural y usar esa medida como gua para la definicin de un conjunto bsico de caminos de ejecucin. Los casos de prueba derivados del conjunto bsico garantizan que durante la prueba se ejecuta por lo menos una vez cada sentencia del programa. Notacin de grafo de flujo Antes de considerar el mtodo del camino bsico se debe introducir una sencilla notacin para la representacin del flujo de control, denominada grafo de flujo. Cada construccin estructurada tiene un correspondiente smbolo en el grafo de flujo. Cuando en un diseo procedural se encuentran condiciones compuestas, la generacin del grafo de flujo se hace un poco ms complicada. Una condicin compuesta se da cuando aparecen uno o ms operadores booleanos (OR, AND, NAND, NOR lgicos) en una sentencia condicional. Prueba de Bucles Los bucles son la piedra angular de la mayora de los algoritmos implementados en software. Y por ello debemos prestarle normalmente un poco de atencin cuando llevamos a cabo la prueba del software. La prueba de bucles es una tcnica de prueba de caja blanca que se centra exclusivamente en la validez de las construcciones de bucles. Se pueden definir cuatro clases diferentes de bucles: Bucles simples, Bucles concatenados, Bucles Anidados, y bucles no estructurados.

Adems de un anlisis del camino bsico que asle todos los caminos de un bucle, se recomienda un conjunto especial de pruebas adicionales para cada tipo de bucles. Estas pruebas buscan errores de inicializacin, errores de indexacin o de incremento y errores en los lmites de los bucles. Bucles Simples: A los bucles simples se les debe aplicar el siguiente conjunto de pruebas, donde n es el nmero mximo de pasos permitidos por bucle.

Saltar totalmente el bucle. Pasar una sola vez por el bucle. Pasar dos veces por el bucle. Hacer m pasos por el bucle con m<n. Hacer n-1, n y n+1 pasos por bucle.

Bucles Anidados: Si extendiramos el enfoque de prueba de los bucles simples a los bucles anidados, el nmero de posibles pruebas crecera geomtricamente a medida que aumenta el nivel de anidamiento. Esto nos llevara a un nmero impracticable de pruebas. Beizer sugiere un enfoque que ayuda a reducir el nmero de pruebas:

Comenzar en el bucle ms interior. Disponer todos los dems bucles en sus valores mnimos. Llevar a cabo las pruebas de bucles simples con el bucle ms interno mientras se mantiene los bucles exteriores con los valores mnimos para sus parmetros de iteracin. Aadir otras pruebas para los valores fuera de rango o para valores excluidos. Progresar hacia afuera, llevando a cabo las pruebas para el siguiente bucle, pero manteniendo todos los dems bucles exteriores en sus valores mnimos y los dems bucles anidados con valores tpicos. Continuar hasta que se hayan probado todos los bucles.

Bucles Concatenados: los bucles concatenados se pueden probar mediante el enfoque anteriormente definido para los bucles simple, mientras que cada uno de los bucles sea independiente del resto. Por ejemplo, si hay dos bucles concatenados y se usa el contador del bucle 1 como valor inicial del bucle 2, entonces los bucles no son independientes. Cuando los bucles no son independientes, se recomienda usar el enfoque aplicado para los bucles anidados. Bucles No Estructurados: Siempre que sea posible, esta clase de bucles se deben redisear para que se ajuste a las construcciones de la programacin estructurada. Prueba de la Caja Negra Los mtodos de prueba de la caja negra se centran en los requerimientos funcionales del software. O sea, le prueba de la caja negra permite al ingeniero del software derivar conjuntos de condiciones de entrada que ejerciten completamente

todos los requerimientos funcionales de un programa. La prueba de la caja negra no es una alternativa a las tcnicas de prueba de la caja blanca. Ms bien se trata de un enfoque complementario que intenta descubrir diferentes tipos de errores que los mtodos de la caja blanca. La prueba de la caja negra intenta encontrar errores de las siguientes categoras:

Funciones incorrectas o ausentes Errores de interfaz Errores en estructura de datos o en acceso a base de datos externas Errores de rendimiento Errores de inicializacin y de terminacin.

A diferencia de la prueba de la caja blanca, que se lleva a cabo previamente en el proceso de prueba, la prueba de la caja negra tiende a ser aplicadas en posteriores fases de prueba. Ya que la prueba de la caja negra intencionadamente ignora la estructura de control, concentra su atencin en el dominio de la informacin. Las pruebas se disean para responder a las siguientes preguntas:

Cmo se prueba la validez funcional? Qu clase de entrada compondrn unos buenos casos de prueba? Es el sistema particularmente sensible a ciertos valores de entrada? De qu forma estn aislados los lmites de una clase de datos? Qu volmenes y niveles de datos tolerar el sistema? Qu efectos sobre la operacin del sistema tendrn combinaciones especficas de datos?

Mediante las tcnicas de prueba de la caja negra se derivan un conjunto de casos de prueba que satisfacen los siguientes criterios:

Casos de prueba que reducen, en un coeficiente que es mayor que uno, el nmero de casos de prueba adicionales que se deben disear para alcanzar una prueba razonable. Casos de prueba que nos dicen algo sobre la presencia o ausencia de clases de errores asociados solamente con la prueba en particular que se encuentra disponible.

Particin Equivalente La particin equivalente es un mtodo de prueba de la caja negra que divide el dominio de entrada de un programa en clases de datos de los que se pueden derivar casos de prueba. Un caso de prueba ideal descubre de forma inmediata una clase de error (por ejemplo procesamiento incorrecto de todos los datos de carcter) que de otro modo requeriran la ejecucin de muchos casos antes de detectar el error genrico. La particin equivalente se dirige a la definicin de casos de prueba que descubran clases de errores, reduciendo as el nmero total de casos de prueba que hay que desarrollar. El diseo de casos de prueba para la particin equivalente se basa en una evaluacin de las clases de equivalencia para una condicin de entrada. Una clase de equivalencia representa un conjunto de estados vlidos o invlidos para condiciones de entrada. Tpicamente una condicin de entrada es un valor numrico especifico, un rango de valores, un conjunto de valores relacionados o una condicin booleana (si o no). Las clases de equivalencia se pueden definir de acuerdo a las siguientes directrices: Si una condicin de entrada especifica un rango, se define una clase de equivalencia vlida y dos invlidas. Si una condicin de entrada requiere un valor especifico, se define una clase de equivalencia vlida y dos invlidas. Si una condicin de entrada especifica un miembro de un conjunto, se define una clase de equivalencia vlida y una invlidas. Si una condicin de entrada es booleana, se define una clase vlida y una invlida.

Aplicando esas directrices para la derivacin de clases de equivalencia, se pueden desarrollar y ejecutar casos de prueba para cada elemento de datos del dominio de entrada. Los casos de prueba se seleccionan de forma que se ejercite el mayor nmero de atributos de cada clase de equivalencia a la vez. Tcnicas de Grafos Causa - Efecto El uso de grafos de causa - efecto es una tcnica de casos de prueba que proporciona una concisa representacin de las condiciones lgicas y sus correspondientes acciones. La tcnica sigue cuatro pasos: Se alistan para un mdulo las causas (condiciones de entrada) y los efectos (acciones), asignando un identificador a cada uno de ellos. Se desarrolla un grafo causa efecto. Se convierte el grafo en una tabla de decisin. Se convierten las reglas de la tabla de decisin a casos de prueba.

Si se ha usado una tabla de decisin como herramienta de diseo, los grafos causa - efecto ya no son necesarios. Prueba de Correccin Hemos visto que la prueba se puede usar perfectamente para descubrir errores, pero no se puede usar para demostrar la correccin de un programa. Si se pudiese realizar una herramienta infalible de prueba de la correccin del programa, el esfuerzo de la prueba se reducira considerablemente, desaparecera la necesidad de modelos de fiabilidad y no existira ms que una de las mayores contribuciones a la crisis del software (la pobre calidad del software). Las pruebas de correcciones manuales, tales como el uso de induccin matemtica o de clculo de predicado, puede ser de algn valor en la prueba de pequeos programas, pero tienen muy poca utilidad cuando se deben validar grandes subsistemas de software. Si alguna vez se desarrolla un buen mtodo de propsito general para la prueba de correccin de software, probablemente incluira lo siguiente:

Un mtodo validado y que se aplique de forma sencilla para especificar afirmaciones sobre la correcta operacin del software. Un mtodo para indicar la variacin respecto de la operacin correcta (errores). Una tcnica para descubrir la causa del error. Una aproximacin totalmente automatizada que coja el cdigo fuente o algn otro elemento de la configuracin del software (por ejemplo, una representacin del diseo) como entrada.

Durante la dcada pasada se han desarrollado varias aproximaciones automatizadas a la prueba de correccin de software de computadoras. Las herramientas automatizadas de comprobacin de la correccin, que no se deben confundir con las herramientas automticas de prueba, generalmente encierran una especificacin formal de la lgica del programa. Esa especificacin se puede obtener con un macro compilador que produzca una representacin simblica del software. La correccin de un programa es comprobada mediante el uso de tcnicas automatizadas [SMI85] basada en la teora de la inteligencia artificial y del clculo de predicados. El proceso de Prueba Excepto para programas de computador muy pequeos, no es realista intentar la prueba de los sistemas como si se tratara de una sola unidad. Los sistemas grandes se componen por subsistemas formados por mdulos que, a su vez,

pueden componerse de procedimientos. Si se intenta probar el sistema como una sola entidad, es posible que no se identifiquen ms que un pequeo porcentaje de errores. El proceso de prueba, al igual que el de programacin, debe avanzar en etapas, siendo cada una de ellas la continuacin lgica de la anterior. En el proceso de prueba se pueden encontrar 5 etapas: Prueba de Unidad. Este tipo de prueba es considerada una de las primordiales ya que los resultados obtenidos de esta repercutirn directamente en la ejecucin de las dems pruebas. El modo de operacin de este tipo de prueba se basa directamente en concepto de caja blanca controlando, a base de condiciones limites, el buen funcionamiento interno del mdulo, esto se refiere al manejo de flujos de datos internos en el mdulo controlando las iteraciones, bucles y comparaciones que este realice para verificar todos los posibles caminos que puedan tomar la informacin recibida. Si los datos no son ingresados correctamente, o no se tratan de igual manera, esto nos indicar especialmente problemas en los clculos internos como por ejemplo:

Precedencia aritmtica incorrecta o mal interpretada. Operaciones de modo mixto. Inicializaciones incorrectas. Falta de precisin. Incorrecta representacin simblica de una expresin.

Tomando en cuenta los errores antes mencionados, las pruebas de unidad deben descubrir errores como:

Comparaciones entre tipos de datos distintos. Operadores lgicos o precedencia incorrecta. Igualdad esperada cuando los errores de precisin la hacen poco probable. Variables o comparadores incorrectos. Terminacin de bucles inapropiada o inexistente. Fallo de salida cuando se encuentra una iteracin divergente. Variables de bucle modificadas de forma inapropiadas.

Las pruebas de lmites son las ltimas y probablemente las ms importantes dentro de las pruebas de unidad, ya que normalmente un software falla en sus condiciones lmites, o sea, cuando sus datos son tratados a n repeticiones. Los casos de prueba que ejercitan las estructuras de datos, el flujo de control y los valores de datos por debajo, en y por encima de los mximos y los mnimos son muy apropiados para descubrir este tipo de errores. Pruebas de Validacin Tras la culminacin de las pruebas de integracin, el software est completamente ensamblado como un paquete; se han encontrado y corregido los errores de interfaces, y debe comenzar una serie final de pruebas del software -la prueba de validacin. La validacin puede ser definida de muchas formas, pero una simple indicacin es que la validacin se logra cuando el software funciona de acuerdo con las expectativas razonables del cliente. En este punto, un realizador de software estricto podra protestar: Quin o qu es el rbitro de las expectativas razonables? Las Expectativas razonables estn definidas en la Especificacin de Requerimientos del Software. Las especificaciones contienen una seccin denominada Criterios de Validacin. La informacin contenida en esa seccin forma la base de la aproximacin a la prueba de validacin. Criterios de Validacin La validacin del software se consigue mediante una serie de pruebas de caja negra que demuestre la conformidad de los requerimientos que fueron entregados con anterioridad. Un plan de prueba traza las pruebas que han de llevarse a cabo, y un procedimiento de prueba define los casos de pruebas especficos que se aplicaran para demostrar la conformidad de los requerimientos. Una vez que se procede con cada uno de los casos de prueba de validacin, puede darse uno de dos condiciones 1. Las caractersticas de funcionamiento o de rendimiento estn de acuerdo con las especificaciones y son aceptadas. 2. Se descubre una desviacin de la especificacin y se crea una lista de diferencias. Las desviaciones o errores descubiertos en esta fase del proyecto raramente se pueden corregir antes de terminar el plan. A menudo es necesario negociar con el cliente un mtodo para resolver las diferencias. Pruebas alfa y beta: Es virtualmente imposible que un encargado del desarrollo pueda prever como un cliente usar realmente un programa, se puede interpretar mal las instrucciones de

uso, se pueden usar regularmente extraas combinaciones de datos y una salida que puede estar clara para el que realiza la prueba pero puede resultar ininteligible para un usuario normal. Al memento de construir un software a medida se llevan a cabo una serie de pruebas de aceptacin para que el cliente valide todos los requerimientos. Estas pruebas pueden tener lugar a lo largo de semanas o meses, descubriendo as, errores acumulados que podran degradar el sistema. Si el software se desarrolla como un producto para muchos clientes, no es practico realizar pruebas de aceptacin para cada una de ellos. La mayora de los constructores de productos de software llevan a cabo un proceso denominado pruebas alfa y beta para descubrir errores que parezcan que solo el usuario final pueda descubrir. La prueba alfa es conducida por un cliente en el lugar de desarrollo. Se usa el software de forma natural, con el encargado del desarrollo mirando por encima del hombro del usuario y registrando errores y problemas de uso. Las pruebas alfa se desarrollan en un entorno controlado. La prueba beta se lleva a cabo en uno o ms lugares de clientes por los usuarios finales del software. A diferencia de la prueba alfa, el encargado del desarrollo normalmente no est presente. As, la prueba beta es una aplicacin en vivo del software en un entorno que no puede ser controlado por el equipo de desarrollo. El cliente registra todos los problemas (reales o imaginarios) que encuentra durante la prueba beta e informa a intervalos regulares al equipo de desarrollo. Como resultado de los problemas anotados durante la prueba beta, el equipo de desarrollo del software lleva a cabo modificaciones y as prepara una versin del producto de software para toda la base de clientes. Pruebas de Recuperacin Muchos sistemas basados en computadoras deben recuperarse de los fallos y resumir el procesamiento en un tiempo previamente especificado. En algunos casos un sistema debe ser tolerante a fallos, o sea, los fallos de procesamiento no deben hacer que cese el funcionamiento de todo el sistema. En otros casos, se debe corregir un fallo del sistema en un determinado periodo de tiempo a riesgo que se produzca un serio dao econmico. La prueba de Recuperacin es una prueba de sistema que fuerza el fallo del software de muchas formas y verifica que la recuperacin se lleva a cabo apropiadamente. Si la recuperacin es automtica hay que evaluar la correccin de la re inicializacin, de los mecanismos de recuperacin del estado del sistema, de la recuperacin de datos y del re arranque. Si la recuperacin requiere la intervencin humana hay que evaluar los tiempos medios de reparacin para determinar si estn dentro de los lmites aceptables.

Pruebas de Seguridad: Estas pruebas intentan verificar que los mecanismos de proteccin incorporados en el sistema, lo protejan, de hecho, de la penetracin impropia. Durante la prueba de seguridad, el encargado de la prueba juega el papel de un individuo que desea penetrar el sistema. Todo vale! Debe intentar hacerse con las claves de acceso por cualquier medio externo del oficio; debe atacar el sistema con cualquier software a medida, diseado para romper cualquier defensa que haya sido construida; debe bloquear el sistema, negando as el servicio a otras personas; debe producir a propsito errores del sistema, intentando penetrar durante la recuperacin; o debe curiosear en los datos pblicos intentando encontrar las claves de acceso al sistema. Con el suficiente tiempo y los suficientes recursos, una buena prueba de seguridad termina por penetrar el sistema. El papel del diseador del sistema es hacer que el costo de la penetracin sea mayor que el valor de la informacin obtenida mdiate la penetracin. 4.2.1. Integracin. Se prueban la respuesta de grupos de mdulos interconectados a fin de detectar fallos resultantes de la interaccin entre los componentes. Las pruebas de integracin se realizan con referencia a las especificaciones del programa. La principal dificultad de las pruebas de integracin es la Localizacin de los fallos. Para facilitar la deteccin de los errores se utilizan tcnicas incrementales. Prueba de Integracin: Dando un caso como ejemplo, una persona despus de terminar las pruebes de unidad en todos los mdulos que intervienen en el programa y que estos los hayan pasado sin ningn problema, podra considerar que el programa en su totalidad debera funcionar sin problemas; lo cual no es cierto, porque uno es fusin total de todos los mdulos que fueron probados de manera independiente que fueron probados de una sola vez, nos producira el concepto de Big-Bang y es casi seguro que se llegar a un caos total debido a que los errores producidos sern muy difcil aislarlos y a su vez corregirlos. A este concepto se aplica la prueba de integridad con la finalidad de producir la anttesis de Big-Bang. Las pruebas de integracin atacan directamente a un acoplamiento paulatino de los mdulos anteriormente probados, este tipo de prueba maneja dos conceptos fundamentales. 4.2.1.1. Descendente. Integracin Descendente. Esta ataca directamente a la implementaron de los mdulos desde el programa principal hacia los mdulos inferiores de manera jerrquica. El modo de funcionamiento consiste en que el mdulo de control

principal maneje toda la informacin de las pruebas y las distribuya directamente a los mdulos que se encuentren inmediatamente subordinados, y a su vez estos van realizando el mismo procedimiento a sus mdulos dependientes. Hay que tener presente que las pruebas se tienen que realizar cada vez que se va incorporando un nuevo mdulo. La estrategia descendente suena relativamente fcil, pero en la realidad pueden producirse algunos problemas logsticos que podran llegar a repercutir en los resultados de nuestras pruebas, esto se refiere a, que ocurrira si un mdulo de nivel jerrquico superior depende de clculos realizados en un mdulo de nivel inferior. El encargado de realizar la prueba tiene tres opciones ante esta problemtica:

Retrasar muchas de las pruebas hasta que se fusionen los mdulos faltantes. Realizar resguardos que realicen funciones limitadas que simulen los mdulos reales. Integrar el software desde el fondo de la jerarqua hacia arriba.

La primera aproximacin hace que perdamos cierto control sobre la correspondencia de ciertas pruebas especficas con la incorporacin de estos mdulos y por ende el control que realicemos no ser tan exacto y acabado, adems de producir incongruencia en los resultados, por ende, dificulta la determinacin de la causa del error y tiende a violar la naturaleza altamente de restrictiva de la aproximacin descendente. La segunda aproximacin es factible, pero puede llevar a un significativo incremento del esfuerzo a medida que los resguardos se hagan ms y ms complejos. 4.2.1.2. Ascendente. Las pruebas de integracin ascendente, como su nombre lo indica, consiste bsicamente en tratar el mdulo atmico (mdulo de nivel jerrquico ms bajo) hacia arriba. Dado que los mdulos son integrados de abajo hacia arriba, e procesamiento requerido de los mdulos subordinados siempre est disponible y se elimina la necesidad de resguardo. Una estrategia de integracin ascendente puede ser implementada mediante los siguientes pasos:

Se combinan los mdulos de bajo nivel en grupos que realicen una funcin especfica del software. Se escribe un conductor (Programa de control de la prueba) para coordinar la entrada y la salida de los casos de prueba. Se prueba el grupo. Se eliminan los conductores y se combinan los grupos movindose hacia arriba por la estructura del programa.

A medida que la integracin progresa hacia arriba, disminuye la necesidad de conductores de pruebas separados. De hecho si los niveles superiores del programa se integran de forma descendente, se pueden reducir sustancialmente en nmero de conductores y se simplifica enormemente la integracin de grupos. Hay muchas discusiones sobre las ventajas y desventajas de las pruebas de integracin ascendentes frente a las descendentes, pero los que tenemos que tener claro, que se lleg a la conclusin que las ventajas de una, son las desventajas de la otra. La seleccin de un tipo de prueba de integracin depender directamente del software y a veces del plan del proyecto. En general el mejor compromiso puede ser una aproximacin combinada (a veces denominada prueba sndwich) que use la descendente para los niveles superiores de la estructura del programa junto con la ascendente para los niveles subordinados. A medida que progresen las pruebas de integracin, el encargado debe identificar los mdulos crticos. Un mdulo crtico es aquel que tiene una o ms de las siguientes caractersticas:

Est dirigido a varios requerimientos del software. Tiene un mayor nivel de control (Reside relativamente alto en la estructura del programa). Es complejo o propenso a errores. Tiene unos requerimientos de rendimientos muy definidos.

Los mdulos crticos deben ser probados lo antes posible. Adems las pruebas de regresin se deben centrar en el funcionamiento de los mdulos crticos.

4.2.1.3. Regresin.

Cualquier tipo de pruebas de software que intentan descubrir nuevos errores inducidos por cambios recientemente realizados en partes de la aplicacin que anteriormente al citado cambio no eran propensas a este tipo de error. Volver a ejecutar un subconjunto de pruebas que se han llevado a cabo anteriormente para asegurarse de que los cambios no han propagado efectos colaterales no deseados. La prueba de regresin es la actividad que ayuda a asegurar que los cambios no introducen un comportamiento no deseado o errores adicionales.

Cada vez que se aade un nuevo mdulo como parte de una prueba de integracin, el software cambia. Se establecen nuevos caminos de flujo de datos. Pueden ocurrir nuevas E/S. Se invoca una nueva lgica de control. Estos cambios pueden causar problemas con funciones que antes trabajaban perfectamente. La prueba de regresin es una estrategia importante para reducir efectos colaterales. Se deben ejecutar pruebas de regresin cada vez que se realice un cambio importante en el software (incluyendo la integracin de nuevos mdulos).

El conjunto de pruebas de regresin contiene tres clases diferentes de casos de prueba: 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. Pruebas que se centran en los componentes del software que han cambiado. Tipos de regresin segn el mbito: Local-Los cambios introducen nuevos errores en un mdulo concreto. Desenmascarada-Los cambios revelan errores previos. Remota-Los cambios vinculan algunas partes del programa (mdulo) e introducen errores en ella.

4.2.2. Validacin.

La validacin se refiere a la construccin de un modelo correcto. La validacin es el proceso de determinar si el modelo, como abstraccin, es una buena representacin del sistema. Usualmente la validacin se consigue a travs de la calibracin del modelo, en un proceso iterativo de comparacin del comportamiento del modelo con el del sistema y usar las diferencias entre ambos para mejorar el modelo. Este proceso se repite hasta que el modelo se considera aceptable. Las pruebas de validacin en la ingeniera de software son el proceso de revisin que verifica que el sistema de software producido cumple con las especificaciones y que logra su cometido. Es normalmente una parte del proceso de pruebas de software de un proyecto, que tambin utiliza tcnicas tales como evaluaciones, inspecciones y tutoriales. La validacin es el proceso de comprobar que lo que se ha especificado es lo que el usuario realmente quera.

4.2.2.1. Alfa. Prueba alfa: Se lleva a cabo, por un cliente, en el lugar de desarrollo. Se usa el software de forma natural con el desarrollador como observador del usuario y registrando los errores y problemas de uso. Las pruebas alfa se llevan a cabo en un entorno controlado. 4.2.2.2. Beta. Prueba beta: Se llevan a cabo por los usuarios finales del software en los lugares de trabajo de los clientes. A diferencia de la prueba alfa, el desarrollador no est presente normalmente. As, la prueba beta es una aplicacin en vivo del software en un entorno que no puede ser controlado por el desarrollador. El cliente registra todos los problemas que encuentra durante la prueba beta e informa a intervalos regulares al desarrollador. 4.2.3. Sistema.

Antes del proceso de la implantacin del sistema es necesario un periodo de prueba para poder determinar si an existen problemas no resueltos y no hacer un doble trabajo de acondicionamiento al sistema. Un problema tpico es la delegacin de culpabilidad, esto ocurre cuando se descubre un error y cada uno de los creadores de cada elemento del sistema echa la culpa del problema a los otros. Se debe anticipar a los posibles problemas y: 1. Disear caminos de manejo de errores que prueben toda la informacin procedente de los elementos del sistema. 2. 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. 3. Registrar los resultados de las pruebas como evidencia en el caso de que se le seale con el dedo. 4. Participar en la planificacin y el diseo de pruebas del sistema para asegurarse de que el software se prueba de forma adecuada.

4.2.3.1. Recuperacin. La prueba de recuperacin es una prueba del sistema que fuerza el fallo del software de muchas formas y verifica que la recuperacin se lleva a cabo apropiadamente. Si la recuperacin es automtica hay que evaluar la correccin de la inicializacin, de los mecanismos de recuperacin del estado del sistema, de la recuperacin de datos y del proceso de re-arranque. Si la recuperacin requiere la intervencin humana, hay que evaluar los tiempos medios de reparacin (TMR) para determinar si estn dentro de unos lmites aceptables. 4.2.3.2. Seguridad.

Este acceso al sistema incluye un amplio rango de actividades: piratas informticos que intentan entrar en los sistemas por deporte, empleados disgustados que intentan penetrar por venganza e individuos deshonestos que intentan penetrar para obtener ganancias personales ilcitas. La prueba de seguridad intenta verificar que los mecanismos de proteccin incorporados en el sistema lo protegern, de hecho, de accesos impropios. 4.2.3.3. Resistencia

Permite observar la demanda que tiene el sistema en cuanto a cantidad de recursos, la prueba de resistencia ejecuta un sistema de forma que demande recursos en cantidad, frecuencia o volmenes anormales. Por ejemplo: 1. Incrementar las frecuencias de datos de entrada en un orden de magnitud con el fin de comprobar cmo responden las funciones de entrada. 2. Disear pruebas especiales que generen diez, interrupciones por segundo, cuando las normales son una o dos. 3. Ejecutar casos de prueba que requieran el mximo de memoria o de otros recursos. 4. Disear casos de prueba que puedan dar problemas en un sistema operativo virtual.

Los tipos de resistencia a las cuales se somete el sistema son: 4.2.3.4. Diseo de pruebas sobre interrupciones por segundo. Aumento de la frecuencia de datos de entrada. Pruebas que requieran uso excesivo de memoria u otro recurso. Pruebas sobre el sistema operativo u otro software. Crear excesivas bsquedas de datos. Rendimiento

La prueba de rendimiento est diseada para probar el rendimiento del software en tiempo de ejecucin dentro del contexto de un sistema integrado. La prueba de rendimiento se da durante todos los pasos del proces de la prueba. Incluso al nivel de unidad, se debe asegurar el rendimiento de los mdulos individuales a medida que se llevan a cabo las pruebas de caja blanca. Sin embargo, hasta que no estn completamente integrados todos los elementos del sistema no se puede asegurar realmente el rendimiento del sistema.

La prueba en el contexto de espiral

4.3. Mantenimiento. 4.3.1. Concepto. El mantenimiento de un sistema es la continuacin del ciclo de vida, luego de haber completad una versin de este. Aunque parte del objetivo es resolver problemas, durante el mantenimiento se deben consideran las extensiones del sistema de acuerdo con las nuevas necesidades. De cierta manera, el mantenimiento significa seguir un nuevo ciclo de actividades de desarrollo, pero a partir de un sistema existente. 4.3.2. Objetivo. La capacidad de mantenimiento es la habilidad que se tiene para realizar cambios al producto en el tiempo y la capacidad de actualizacin es la habilidad que se tiene para entregar las versiones del producto a bajo costo a los clientes con un mnimo de tiempo de descarga. Una caracterstica clave para apoyar este objetivo es la descarga automtica de parches o actualizaciones y actualizaciones del equipo del usuario final. Tambin debemos utilizar formatos para archivos de datos que incluyan suficientes metadatos para permitirnos trasformar con seguridad la informacin existente del usuario durante una actualizacin.

Es la ltima fase del Ciclo de Vida de Desarrollo de Sistemas, en donde los SI son sistemticamente reparados y mejorados. Por definicin, el proceso de mantenimiento de un SI es un pr oceso de devolucin al principio del Ciclo de Vida y de repeticin de los pasos de desarrollo para la implementacin de cambios. Las 4 actividades ms importantes que ocurren dentro del mantenimiento son: Obtencin de los requerimientos de mantenimiento. Transformacin de los requerimientos en cambios. Diseo de los cambios. Implementacin de los cambios.

4.4. Caractersticas del mantenimiento. Con posterioridad a la fase de implementacin de los sistemas, se impone la fase de mantenimiento. El mantenimiento de sistemas es el mantenimiento continuo despus del inicio del funcionamiento. Cuando se elaboran planes para la estrategia de informacin, las organizaciones no pueden dejar de considerar que el mantenimiento de sistemas es la fase ms prolongada y costosa del ciclo de vida de los sistemas. Las implicaciones del volumen de trabajo para mantenimiento para los planes de estrategia de informacin en una organizacin es un tema que merece atencin especial. La estructura de organizacin necesita flexibilidad para apoyar el mantenimiento de los sistemas existentes concurrentemente con la ejecucin de nuevas tecnologas. Es importante considerar la evaluacin y el monitoreo de un sistema en trminos del mantenimiento necesario y, en consecuencia, reducir o contener los costos implcitos. 4.4.1. Costos.

4.4.2. Efectos.

4.4.3. Tipos. 4.4.3.1. Correctivo. Mantenimiento correctivo. Independientemente de cun bien diseado, desarrollado y probado est un sistema o aplicacin, ocurrirn errores inevitablemente. Este tipo de mantenimiento se relaciona con la solucin o la correccin de problemas del sistema. Atae generalmente a problemas no identificados durante la fase de ejecucin. Un ejemplo de mantenimiento correctivo

es la falta de una caracterstica requerida por el usuario, o su funcionamiento defectuoso. Correctivo: son aquellos cambios precisos para corregir errores del producto software. 4.4.3.2 Preventivo/perfectivo. Mantenimiento preventivo. Este tipo de mantenimiento es probablemente uno de los ms eficaces en funcin de los costos, ya que si se realiza de manera oportuna y adecuada, puede evitar serios problemas en el sistema. Perfectivo: son las acciones llevadas a cabo para mejorar la calidad interna de los sistemas en cualquiera de sus aspectos: reestructuracin del cdigo, definicin ms clara del sistema y optimizacin del rendimiento y eficiencia.

4.4.3.3. Adaptativo. Adaptativo: son las modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo, cambios de configuracin del hardware, software de base, gestores de base de datos, comunicaciones, etc.

4.4.4.4. Actividades.

Das könnte Ihnen auch gefallen