ESTRATEGIAS DE LECTURA

Universidad Privada TELESUP

PRUEBAS PRUEBAS DE ESTRUCTURA DE CONTROL

Curso:COMPROBACION DE SOFTWARE

Ciclo:VII

Tutores:Jorge Carmona Espinoza

Carrera Profesional: Ingeniera de Sistemas

Alumnos:Augusto Cesar Llerena Espinoza : Juan Carlos Curillo Rodrguez

2014Agradecimiento

A Dios por permitirnos seguir superndonos en el da a da y por dotarnos de salud.A nuestros familiares ms cercanos por su apoyo incondicional y su comprensin, por ser ellos esa motivacin que nos impulsan a ser mejores cada da.

NDICEPg.

1.INTRODUCCION05

2.PRUEBAS DE SOFTWARE06

3.OBJETIVOS DE LA PRUEBA10

4.CASOS DE PRUEBA11

5.VERIFICACION Y VALIDACION11

6.NIVELES DE PRUEBAS6.1. PRUEBAS UNITARIAS6.2. PRUEBAS DE INTEGRACION6.3. PRUEBAS DEL SISTEMA6.4. PRUEBAS DE IMPLANTACION6.5. PRUEBAS DE ACEPTACION6.6. PRUEBAS DE REGRESION13

7.DISEO DE CASOS DE PRUEBA7.1. PRUEBA DE CAJA BLANCA7.2. PRUEBA DEL CAMINO BASICO7.3. PRUEBA DE ESTRUCTURA DE CONTROL7.4. PRUEBA DE CAJA NEGRA7.5. PRUEBA DE ENTORNOS ESPECIALIZADOS, ARQUITECTURAS Y APLICACIONES18

8.CONCLUSIONES27

9.WEB GRAFA28

DedicatoriaDedicamos este trabajo a nuestros familiares ms cercanos por su apoyo incondicional y su comprensin, por ser ellos esa motivacin que nos impulsan a ser mejores cada da, gracias por entendernos en aquellos momentos que dedicamos a nuestros estudios y dejamos de estar con ellos.

Agradecimiento

Agradecemos a Dios en primer lugar por darnos la vida, por permitirnos ser mejor cada da; a la universidad por darnos la oportunidad de superarnos en el aspecto profesional y como persona, y un agradecimiento especial .a nuestras familias por cuanto nos brinda en el da a da.

1. INTRODUCCIONEn un proyecto de desarrollo de software los errores (bugs en ingls) pueden presentarse en cualquiera de las etapas del ciclo de vida del software.

Aun cuando se intente detectarlos despus de cada fase utilizando tcnicas como la inspeccin, algunos errores permanecen sin ser descubiertos.

Por lo tanto es muy probable que el cdigo final contenga errores de requerimientos y diseo, adicionales a los introducidos en la codificacin

Las pruebas de software son una parte importante pero muy costosa del proceso de desarrollo de software. Pueden llegar a representar entre el 30 y 50 % del costo total del desarrollo del software. Sin embargo, los costos de las fallas en un software en operacin pueden llegar a ser muchos mayores (catastrficos).

Se colapsa el aeropuerto de Los ngeles (2007) Ms de 17 mil personas se quedaron en tierra por un problema de software que provoc conflictos en una tarjeta de red que bloque toda la red informtica

Como pueden observar las pruebas de software tienen un rol muy. Importante en el aseguramiento de la calidad ya que permiten detectar los errores introducidos en las fases previas del proyecto. Analizaremos algunas de las estrategias y tcnicas ms importantes para efectuar las pruebas de software.

2. PRUEBAS DE SOFTWARE

Las pruebas de software son los procesos que permiten verificar y revelar la calidad de un producto software antes de su puesta en marcha. Bsicamente, es una fase en el desarrollo de software que consiste en probar las aplicaciones construidas.

Las pruebas de software se integran dentro de las diferentes fases del ciclo de vida del software dentro de la Ingeniera de software. En este sentido, se ejecuta el aplicativo a probar y mediante tcnicas experimentales se trata de descubrir qu errores tiene.

Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto de las especificaciones iniciales del sistema.

Otros especialistas de pruebas manifiestan que las pruebas de software son actividades claves para que los procesos de validacin y verificacin tengan xito, ya que ayudan a entregar el producto con la calidad suficiente para satisfacer las necesidades del cliente y con la certeza de que el producto cumple las especificaciones definidas. En este sentido, las pruebas pueden considerarse como un proceso que intenta proporcionar confianza en el software y cuyo objetivo fundamental es demostrar al desarrollador y al cliente que el software satisface sus requisitos.

Algo que los especialistas de pruebas deben considerar es que las pruebas de software nunca se deben realizar en un entorno de produccin. Es necesario probar los nuevos sistemas en un entorno de pruebas separado fsicamente del de produccin. Para crear un entorno de pruebas en una mquina independiente de la mquina de produccin, es necesario crear las mismas condiciones que existe en la de produccin.

Como parte del proceso de validacin y verificacin, se debera tomar decisiones sobre quin debera ser responsable de las diferentes etapas de las pruebas.

Dichas etapas de pruebas se integran dentro de las diferentes fases del ciclo del software dentro de la Ingeniera de Software.

En la figura 1 se observa un modelo de cmo las etapas de pruebas se integran en el ciclo de vida de desarrollo de software genrico. Durante la etapa de planificacin es importante establecer una buena estrategia de pruebas y seleccionar las tcnicas adecuadas de estimacin en funcin de los factores que afecten a las pruebas del proyecto. La siguiente fase de desarrollo es el diseo del producto, que trae consigo el diseo de casos de prueba. Durante las siguientes fases de codificacin y pruebas del producto, se ejecutan las pruebas unitarias, de sistemas, de integracin, etc.

Figura 1 - Proceso de pruebas en el ciclo de vida de desarrollo de software

Un software debe ser fcil de probar, para lo cual se puede tener en cuenta las siguientes caractersticas que propone Pressman:CaractersticaObservacin

OperatividadCunto mejor funcione, ms eficientemente se puede probar: El sistema tiene pocos errores. Ningn error bloquea la ejecucin de las pruebas. El producto evoluciona en fases funcionales.

ObservabilidadLo que se ve es lo que se prueba Se genera una salida distinta para cada entrada. Todos los factores que afectan a los resultados estn visibles. Un resultado incorrecto se identifica fcilmente. Los errores internos se detectan automticamente. Se informa automticamente de los errores internos. El cdigo fuente es accesible.

ControlabilidadCunto mejor se pueda controlar el software, ms se puede automatizar y optimizar Todo el cdigo es ejecutable a travs de alguna combinacin de entrada. El ingeniero de pruebas puede controlar los estados y las variables del hardware y software. Los formatos de las entradas y los resultados son consistentes y estructurados.

Capacidad de descomposicinControlando el mbito de las pruebas, podemos aislar ms rpidamente los problemas y llevar a cabo pruebas de regresin El software est construido con mdulos independientes Los mdulos de software se pueden probar independientemente.

SimplicidadCunto menos haya que probar, ms rpidamente se puede probar Simplicidad funcional. Simplicidad estructural. Simplicidad del cdigo.

EstabilidadCuanto menos cambios, menos interrupciones a las pruebas Los cambios del software son infrecuentes. Los cambios del software estn controlados. Los cambios del software no invalidan las pruebas existentes. El software se recupera bien de los fallos.

Facilidad de comprensinCuanta ms informacin se tenga, ms inteligentes eran las pruebas El diseo se ha entendido perfectamente. Las dependencias entre los componentes internos, externos y compartidos se han entendido perfectamente. Se han comunicado los cambios del diseo. La documentacin tcnica es accesible.

3. OBJETIVOS DE LA PRUEBA La prueba es un 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.

Una prueba tiene xito si descubre un error no detectado hasta entonces.

El objetivo es disear casos de prueba que, sistemticamente, saquen a la luz diferentes clases de errores, hacindolo con la menor cantidad de tiempo y de esfuerzo.

La prueba no puede asegurar la ausencia de errores; slo puede demostrar que existen defectos en el software.

4. CASOS DE PRUEBAEl proceso de prueba tiene dos entradas: Configuracin del software: Incluye la especificacin de requisitos del software, la especificacin del diseo y el cdigo fuente. Configuracin de prueba: Incluye un plan y un procedimiento de prueba.Si el funcionamiento del software parece ser correcto y los errores encontrados son fciles de corregir, podemos concluir con que: La calidad y la fiabilidad del software son aceptables, o que Las pruebas son inadecuadas para descubrir errores serios.

Figura 2 Diagrama de casos de prueba

5. VERIFICACION Y VALIDACIONLos procesos de validacin y verificacin determinan si un producto software satisface las necesidades del negocio y si se est construyendo acorde a las especificaciones.

Con respecto a las tareas asociadas a estos procesos, las pruebas estn ms relacionadas con el proceso de validacin, mientras que las revisiones son tareas ms orientadas al proceso de verificacin.

El objetivo principal de la validacin y verificacin es comprobar que el sistema est hecho para un propsito, es decir, que el sistema debe ser lo suficientemente bueno para su uso previsto. El nivel de confianza requerido depende de tres factores:

El propsito o funcin del sistema. El nivel de confianza necesario depende de lo crtico que sea el software para una organizacin. Las expectativas del usuario. Actualmente, es menos aceptable entregar sistemas no fiables, por lo que las compaas deben invertir ms esfuerzo en llevar a cabo las actividades de verificacin y validacin. Entorno de mercado actual. Cuando un sistema se comercializa, los vendedores del sistema deben tener en cuenta los sistemas competidores, el precio que sus clientes estn dispuestos a pagar por el sistema y los plazos requeridos para entregar dicho sistema. Cuando una compaa tiene pocos competidores, puede decidir entregar un programa antes de que haya sido completamente probado y depurado, debido a que quiere ser el primero en el mercado. Cuando los clientes no estn dispuestos a pagar precios altos por el software, pueden estar dispuestos a tolerar ms defectos en l.

Todos estos factores pueden considerarse a fin de decidir cunto esfuerzo debera invertirse en el proceso de validacin y verificacin.

Validacin. El propsito de la Validacin en CMMI es demostrar que un producto o componente del mismo satisface el uso para el que se cre al situarlo sobre el entorno previsto. Segn Boehm, la validacin responde la siguiente pregunta: Se est construyendo el producto correcto?

Verificacin. El propsito de la Verificacin en CMMI es asegurar que los productos seleccionados cumplen los requisitos especificados. Para diferenciar esta tarea con la validacin, Boehm indica que debe responderse a la siguiente pregunta: Se est construyendo el producto de la manera correcta?

6. NIVELES DE PRUEBASLos niveles de prueba son diferentes ngulos de verificar y validar un producto de software. Es como el tomar una radiografa a un cuerpo humano desde diferentes lados y buscar donde hay un problema en los huesos.6.1. PRUEBAS UNITARIASLas pruebas unitarias constituyen la prueba inicial de un sistema y las dems pruebas deben apoyarse sobre ellas.Tipos: Enfoque estructural o de caja blanca. Se verifica la estructura interna del componente con independencia de la funcionalidad establecida para el mismo. Por tanto, no se comprueba la correccin de los resultados si stos se producen. Enfoque funcional o de caja negra. Se comprueba el correcto funcionamiento de los componentes del sistema de informacin, analizando las entradas y salidas y verificando que el resultado es el esperado.

Figura3 - Flujo de control de pruebas unitarias

6.2. PRUEBAS DE INTEGRACIONEl objetivo de las pruebas de integracin es verificar el correcto ensamblaje entre los distintos componentes una vez que han sido probados unitariamente con el fin de comprobar que interactan correctamente a travs de sus interfaces, tanto internas como externas, cubren la funcionalidad establecida y se ajustan a los requisitos no funcionales especificados en las verificaciones correspondientes.

Figura 4 - Flujo de control de pruebas de integracin

6.3. PRUEBAS DEL SISTEMALas pruebas del sistema tienen como objetivo ejercitar profundamente el sistema comprobando la integracin del sistema de informacin globalmente, verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de informacin con los que se comunica. Pruebas funcionales. Dirigidas a asegurar que el SI realiza correctamente todas las funciones que se han detallado en las especificaciones dadas por el usuario del sistema. Pruebas de comunicaciones. Determinan que las interfaces entre los componentes del sistema funcionan adecuadamente, tanto a travs de dispositivos remotos, como locales. Asimismo, se han de probar las interfaces hombre/mquina. Pruebas de rendimiento. Determinar que los tiempos de respuesta estn dentro de los intervalos establecidos en las especificaciones del sistema. Pruebas de volumen. Examinar el funcionamiento del sistema cuando est trabajando con grandes volmenes de datos, simulando las cargas de trabajo esperadas. Pruebas de sobrecarga. Comprobar el funcionamiento del sistema en el umbral lmite de los recursos, sometindole a cargas masivas. El objetivo es establecer los puntos extremos en los cuales el sistema empieza a operar por debajo de los requisitos establecidos. Pruebas de disponibilidad de datos. Consisten en demostrar que el sistema puede recuperarse ante fallos, tanto de equipo fsico como lgico, sin comprometer la integridad de los datos. Pruebas de facilidad de uso. Consisten en comprobar la adaptabilidad del sistema a las necesidades de los usuarios, tanto para asegurar que se acomoda a su modo habitual de trabajo, como para determinar las facilidades que aporta al introducir datos en el sistema y obtener los resultados. Pruebas de operacin. Consisten en comprobar la correcta implementacin de los procedimientos de operacin, incluyendo la planificacin y control de trabajos, arranque y rearranque del sistema, etc. Pruebas de entorno. Verificar las interacciones del sistema con otros sistemas dentro del mismo entorno. Pruebas de seguridad. Consisten en verificar los mecanismos de control de acceso al sistema para evitar alteraciones indebidas en los datos.

6.4. PRUEBAS DE IMPLANTACIONEl objetivo es comprobar el funcionamiento correcto del sistema integrado de hardware y software en el entorno de operacin, y permitir al usuario que, desde el punto de vista de operacin, revise el sistema en base al cumplimiento de los requisitos no funcionales especificados.

6.5. PRUEBAS DE ACEPTACIONEl objetivo de las pruebas de aceptacin es validar que un sistema cumple con el funcionamiento esperado y permitir al usuario de dicho sistema que determine su aceptacin, desde el punto de vista de su funcionalidad y rendimiento.

Figura 5 - Flujo de control de pruebas de aceptacin

6.6. PRUEBAS DE REGRESIONEl objetivo de las pruebas de regresin es eliminar el efecto onda, es decir, comprobar que los cambios sobre un componente de un sistema de informacin, no introducen un comportamiento no deseado o errores adicionales en otros componentes no modificados.

7. DISEO DE CASOS DE PRUEBAEl diseo de casos de prueba, tiene un nico objetivo: tener la mayor probabilidad de encontrar el mayor nmero de errores con la mnima cantidad de esfuerzo y tiempo posible.Cualquier producto software puede aprobarse de una las siguientes formas:a) Conociendo la funcin para la que fue diseado el producto.- Se pueden utilizar pruebas para: comprobar su funcin operativa y buscar errores de cada funcin.b) Conociendo el funcionamiento del producto.- Se pueden utilizar pruebas para: comprobar que las operaciones est de acuerdo con las especificaciones y para comprobar que los componentes internos funcionan de forma adecuada.

7.1. PRUEBA DE CAJA BLANCAEsta prueba se centra en la estructura interna del programa. En este caso la prueba consiste en probar todos los posibles caminos de ejecucin a travs de las instrucciones del cdigo, que puedan trazarse. Mediante esta prueba, el ingeniero del software puede:

a) Garantizar que se recorre por lo menos una vez todos los caminos independientes de cada mdulo.b) Recorrer todas las decisiones lgicas en sus condiciones verdadera y falsa.c) Recorrer todos los bucles en sus lmites y con sus lmites operacionales.d) Recorrer las estructuras internas de datos para asegurar su validez

7.2. PRUEBA DEL CAMINO BASICOEsta prueba permite obtener una medida de la complejidad de la lgica de un diseo procedimental y usar sa medida como gua para la definicin de un conjunto bsico de camino de ejecucin. Esta prueba permite que se ejecute por lo menos una vez cada sentencia del programa. Complejidad ciclomtica.- Es una mtrica que proporciona una medicin cuantitativa de la complejidad lgica de un programa.

7.3. PRUEBA DE ESTRUCTURA DE CONTROLComprende las siguientes pruebas: a) Prueba de condicin.- Se centra en la prueba de cada una de las condiciones del programa y tiene como propsito detectar los errores en las condiciones de un programa y los errores del programa.

Es un mtodo de diseo de casos de prueba que ejercita las condiciones lgicas contenidas en el mdulo de un programa.

Esta prueba asegura en que cada condicin del programa no contenga errores.

La expresin relacional tiene la forma: E1 E2; donde E1 y E2 son expresiones aritmticas y puede ser "=, ".

Una condicin compuesta est formada por dos o ms condiciones simples, operadores lgicos o parntesis. Los operadores lgicos permitidos en una condicin compuesta incluyen OR (|), AND (&), NOT.

Errores de una condicin: Error en el operador lgico. Error en la variable lgica. Error en el parntesis lgico. Error en el operador relacional. Error en la expresin aritmtica.

b) Prueba del flujo de datos.- Se centra en la seleccin de caminos de prueba de un programa de acuerdo con la ubicacin de las definiciones y los usos de las variables del programa. Esta prueba es til para seleccionar caminos de prueba de un programa que contenga sentencias if o bucles anidados.

c) Prueba de bucles.- Se centra en la validez de las construcciones de bucles. Se definen los siguientes tipos de bucles: Bucles Simples

Se debe aplicar: Pasar por alto 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 el bucle Donde n, es el nmero mximo de pasos permitidos por el bucle.

Bucles Anidados

Se debe: Comenzar por el bucle ms interior Llevar a cabo las pruebas de bucles simples para el bucle ms interior Progresar hacia fuera, llevando a cabo pruebas para el siguiente bucle Continuar hasta cuando se prueben todos los bucles.

Bucles Concatenados

Se pueden probar con el mtodo para buques simples, siempre y cuando los bucles sean independientes. Cuando los bucles no son independientes se utiliza el enfoque para bucles anidados.

Bucles no Estructurados

Estos bucles se deben redisear.

7.4. PRUEBA DE CAJA NEGRAConsiste en estudiar la especificacin de las funciones, la entrada y la salida para derivar los casos. Aqu, la prueba ideal del software consiste en probar todas las posibles entradas y salidas del programa.La prueba de caja negra, tambin encuentra errores de: Funciones incorrectas o ausentes. Errores de interfaz. Errores en estructuras de datos o en accesos a bases de datos externas. Errores de rendimiento. Errores de inicializacin y de terminacin.

7.5. PRUEBA DE ENTORNOS ESPECIALIZADOS, ARQUITECTURAS Y APLICACIONESPrueba de interfaces grficas de usuario.- Se utilizan listas de chequeo:Para ventanas: Se abren las ventanas mediante rdenes basadas en el teclado o en un men? Se puede ajustar el tamao, mover y desplegar la ventana? Se regenera adecuadamente cuando se escribe y se vuelve a abrir? Para mens emergentes y operaciones con el ratn: Se muestra la barra de men apropiada en el contexto apropiado? Es correcto el tipo, tamao y formato del texto? Si el ratn tiene varios botones, estn apropiadamente reconocidos en el contexto?

Entrada de datos: Se repiten y son introducidos adecuadamente los datos alfanumricos? Funcionan adecuadamente los modos grficos de entrada de datos? (p.e. barra deslizante) Se reconocen adecuadamente los datos no vlidos? Son inteligibles los mensajes de entrada de datos?

Prueba de arquitectura cliente / servidor.- Debido a la complejidad del sistema, sern necesarias varias fases: Pruebas de funcionalidad de la aplicacin. Se puede llevar a cabo sobre mquinas de desarrollo y estaciones de trabajo de forma paralela Pruebas de carga del servidor Pruebas de integridad de datos: Son especialmente importantes en el caso de bases de datos distribuidas Pruebas transaccionales Pruebas de red

Prueba de la documentacin y facilidades de ayudas.- Se puede dar en dos sentidos: Revisin e inspeccin: examina la documentacin para comprobar la claridad de la misma. Prueba en vivo: se utiliza la documentacin junto al uso del software. Prueba de sistemas de tiempo real.- Se puede aplicar los siguientes pasos: Prueba de tareas: Se aplican pruebas de caja blanca y caja negra a cada tarea. Pretende descubrir errores en la lgica y en el funcionamiento. Prueba de comportamiento: Se simula el comportamiento del sistema en tiempo real y se examina el comportamiento como consecuencia de sucesos externos. Prueba intertareas: Se prueban las tareas asncronas que se comunican con otras, para determinar si se producen errores de sincronismo entre las tareas. Prueba del sistema: Se realizan pruebas completas al sistema para descubrir errores en la interfaz software/hardware.

8. CONCLUSIONESSuelen confundirse con mucha facilidad, los niveles de pruebas con los tipos de prueba, y a pesar de que se encuentren ntimamente relacionadas, tienen connotaciones diferentes en el proceso. Para entender un poco ms, vamos a partir del hecho de que las pruebas pueden ejecutarse en cualquier punto del proceso de desarrollo de software, y es aqu donde los niveles de prueba nos permiten entender con claridad los diferentes puntos o etapas en donde pueden ejecutarse ciertos tipos de prueba.

Es comn que algunas personas se refieran a los niveles de pruebas o intenten clasificarlos como: pruebas de desarrollador, pruebas funcionales y pruebas de usuario final. Sin embargo, la terminologa apropiada para referirse a los diferentes niveles corresponde a la siguientes cuatro (4) clasificaciones que son: pruebas unitarias, pruebas de integracin, pruebas de sistema y pruebas de aceptacin.

En cada uno de estos niveles de prueba, se podrn ejecutar diferentes tipos de prueba tales como: pruebas funcionales, no funcionales, de arquitectura y asociadas el cambio de los productos.

9. WEB GRAFA

http://indalog.ual.es/mtorres/LP/Prueba.pdf http://ocw.uc3m.es/ingenieria-informatica/ingeniera-del-software-iii/materialclase/ISIII_09_PRUE.pdf http://datateca.unad.edu.co/contenidos/301404/301404_ContenidoEnLinea/unidad_1_introduccin_a_la_ingeniera_de_software.html http://materias.fi.uba.ar/7548/PruebasSoftware.pdf

27Comprobacin de Software