Unidad I. Técnicas de Prueba

Universidad Politcnica del Oeste Mariscal Sucre

INGENIERIA DE SOFTWARE II

Fuentes:Pressman, Roger. Ingeniera de Software. Un Enfoque Prctico. Captulo 16. V Edicin. McGraw Hill. 1997. Sommerville, Ian. "Ingeniera del Software", Captulo 23. 7 Edicin, Pearson-Addison Wesley, 2005.

Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba


CONTENIDOUNIDAD 1. TECNICAS DE PRUEBA 1) Objetivos y Principios de las Pruebas. 2) Tipos de Fallas. 3) Estrategias de Prueba 4) Pruebas de Desarrollos WEB 5) Tcnicas de Construccin de Pruebas 6) Inspecciones y Revisiones. 7) Instrumentos y Herramientas para pruebas.



OBJETIVOS DE LAS PRUEBAS La prueba es un proceso de ejecucin con la intencin de descubrir errores. Tiene los siguientes objetivos: Asegurar una probabilidad muy alta de descubrir un nuevo error.

Una prueba no asegura la ausencia de errores, Un caso de prueba no debe ser redundante. slo puede demostrar que pruebas de propsito similar. Debe ser el mejor de un conjunto deestos existen No debe ser ni muy sencillo ni excesivamente complejo: es mejor realizar cada prueba de forma separada si se quiere probar diferentes casos. Descubrir errores no detectados hasta entonces.



PRINCIPIOS DE LAS PRUEBAS Se debe hacer un seguimiento hasta ver si se cumplen los requisitos del cliente. Las pruebas debern planificarse mucho antes de que empiecen. El principio de Pareto es aplicable a la prueba del software. El 80% de los errores est en el 20% de los mdulos. Hay que identificar esos mdulos y probarlos muy bien

Empezar por lo pequeo y progresar hacia lo grande. No son posibles las pruebas exhaustivas. Son ms eficientes las pruebas dirigidas por un equipo independiente.



TECNICAS DE PRUEBA1. Facilitan una gua sistemtica para disear pruebas con el fin de: Comprobar la lgica interna de los componentes del software. Verificar los dominios de entradas y salidas de los programas con el fin de descubrir errores en la funcionalidad, comportamiento y rendimiento.

2. Son realizadas por el Ingeniero de Software, se van incorporando personal con experticias en prueba a medida que avanza el proceso. 3. Son importantes porque permite encontrar y corregir los errores antes de entregar el software al cliente. 4. Existen dos perspectivas diferentes para aplicarlas: Lgica Interna (Caja Blanca) y comprobacin de los requisitos funcionales (Caja Negra) 5. Debemos ser disciplinados al aplicarlas.



PORQUE PROBAR? Las fallas de software ocasionan graves prdidas econmicas; stos son 100 a 1000 veces ms costosos de encontrar y reparar despus de la construccin. Evitar plazos y presupuestos incumplidos, insatisfaccin del usuario, escasa productividad y mala calidad en el software producido y finalmente la prdida de clientes. Automatizar el proceso de pruebas consigue reducciones de hasta un 75% en el costo de la fase de mantenimiento.



FACILIDAD DE PRUEBA

La facilidad de prueba del software es simplemente la facilidad con la que se puede probar un programa de computadora. (James Bach, 1994.comp.software-en)

Desarrollar con la facilidad de prueba en mente

Permite disear casos de prueba ms fcilmente



FACILIDAD DE PRUEBA (2)Caractersticas que hacen un software fcil de probar: Operatividad. Cuanto mejor funcione, ms Eficientemente se puede probar. Observabilidad. Lo que ves es lo que pruebas. Controlabilidad.Cuanto mejor podamos controlar el software, ms se puede automatizar y optimizar. Controlando el mbito de las pruebas, podemos aislar ms rpidamente los problemas y llevar a cabo mejores pruebas de regresin.

Capacidad de descomposicin.

Simplicidad. Cuanto menos haya que probar, ms rpidamente podremos probarlo. Estabilidad. Cuanto menos cambios, menos interrupciones a las pruebas. Facilidad de Comprensin:sern las pruebas. Cunta ms informacin tengamos, ms inteligentes



DEFINICIONES (1) Prueba (test): Actividad en la cual se somete a un sistema o uno de sus componentes a una evaluacin de los resultados que arroja en base a la ejecucin de ste en condiciones especificadas. Caso de Prueba (test case): Conjunto de atributos a los cuales se les asignan valores especficos de acuerdo con una serie de condiciones dadas ante un escenario, y se ha identificado un resultado esperado una vez que han sido procesados por el sistema. Son la esencia de la prueba. Escenarios de Prueba: Es una coleccin de condiciones que poseen un conjunto de datos procesados por el sistema para verificar su comportamiento. Se pueden derivar diferentes casos de prueba para un mismo escenario



DEFINICIONES (2)

Responsable: Daniela Prez Mdulo: Ventas Pantalla: Facturacin

Situacin 1

CONDICIONESCaso 1 Caso 2

Antigedad del Monto de Status del Cliente > 2 la Venta Producto Aos >10.0003 3 12000 5000 Promocin Promocin

Resultado EsperadoDescuento 10% Sin Descuento

Resultado ObtenidoDescuento 10% Descuento 10%

ErrorNo S



DEFINICIONES (3) Guiones (scripts): Elemento que contiene la secuencia de pasos o tareas que se deben realizar para ejecutar la prueba. Puede funcionar para diferentes escenarios, dependiendo de las condiciones especificadas y de la operatividad del sistema. Error: Accin humana que produce o genera un resultado incorrecto. Defecto: Es la manifestacin de un error en el software. Un defecto es encontrado porque causa una FALLA, la cul es una desviacin del servicio o resultado esperado. Criterios de Aceptacin: Es la definicin de los resultados que esperan obtener los usuarios en los procesos realizados por el sistema. Deben ser diseados y aprobados por los usuarios antes de ejecutar las pruebas, sirven de base para el diseo de los casos de prueba.Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba


DEFINICIONES (4) Verificacin: Determinar si los productos de una fase dada satisfacen las condiciones impuestas al inicio de la fase. Consiste en responder la pregunta: Estamos construyendo correctamente el producto?. El cdigo que estamos construyendo debe estar en armona con la especificacin que hemos tomado del usuario. El resultado final del desarrollo software debe concordar con la especificacin (requisitos) del sistema, por lo que debemos asegurarnos que el desarrollo final coincida con dicha especificacin



DEFINICIONES (5)

Validacin: Evaluacin de un sistema o uno de sus componentes durante o al final de su desarrollo para determinar si satisface los requisitos. Responde a la pregunta: Estamos construyendo el producto correcto? El resultado final del desarrollo software se debe ajustar a lo que el usuario quera (sus necesidades)? En la mayora de las ocasiones el producto desarrollado no casa con la ideas del cliente, normalmente porque a ste suele faltarle capacidad tcnica de expresin.



DEFINICIONES (6)

Completitud: Nos da una idea del grado de fiabilidad de las pruebas y por consiguiente la fiabilidad del software. Depuracin: Ejecucin controlada del software que nos permite corregir un error (Ejemplo: Usar el debugger de undeterminado lenguaje, uso de policias).



TIPOS DE PRUEBA (1)En funcin de qu conocemos:

Pruebas de Caja Negra: No conocemos la implementacin del cdigo, slo la interfaz. Tan slo podemos probar dando distintos valores a las entradas y salidas. Pruebas de Caja Blanca: Conocemos el cdigo (la implementacin de ste) que se va a ejecutar y podemos definir las pruebas que cubran todos los posibles caminos del cdigo.



TIPOS DE PRUEBA (2)Segn el Grado de Automatizacin:

Pruebas Manuales: son las que se hacen normalmente al programar o las que ejecuta una persona con la documentacin generada durante la codificacin (Ejemplo: Comprobar cmo se visualiza elcontenido de una pgina web en dos navegadores diferentes).

Pruebas Automticas: se usa un determinado software para sistematizar las pruebas y obtener los resultados de las mismas(Ejemplo: Verificar un mtodo de bsqueda).



TIPOS DE PRUEBA (3)En funcin de qu se prueba: Pruebas Unitarias: Se aplican a un componente del software. Podemos considerar como componente (elemento indivisible) a una funcin, una clase, una librera, etc. Pruebas de Integracin: Consiste en construir el sistema a partir de los distintos componentes y probarlo con todos integrados. Estas pruebas deben realizarse progresivamente. Busca determinar como el software convive con su homlogos, es decir, evala el flujo de informacin a travs de las aplicaciones con las cuales el sistema debe intercambiar informacin. Pruebas Funcionales: Son aquellas que se aplican sobre el sistema funcionando a fin de comprobar si se cumple con la especificacin (normalmente a travs de los casos de uso).COMPRUEBAN LA EFICACIA DEL SISTEMAIngeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba


TIPOS DE PRUEBA (4)En funcin de qu se prueba:

Pruebas de Regresin: Consiste en volver a aplicar pruebas que se haban superado anteriormente (Ejemplo: Pruebas de integracin). Pruebas de Aceptacin: Son realizadas por los usuarios, todas las anteriores las lleva a cabo el equipo de desarrollo. Podemos distinguir entre dos pruebas:- Pruebas Alfa: las realiza el usuario en presencia del los desarrolladores del proyecto haciendo uso de una mquina preparada para tal fin. - Pruebas Beta: Las realiza el usuario despus que el equipo de desarrollo les entregue una versin casi definitiva del producto.



TIPOS DE PRUEBA (5)En funcin de qu se prueba: Pruebas de Volumen o Rendimiento: Se ejecutan para evaluar la capacidad de respuesta y rendimiento del sistema ante la ejecucin de varios procesos ejecutados concurrentemente por varios usuarios, con la finalidad de determinar si es necesario la optimizacin de algn componente. Utiliza una cantidad de datos mayor que las pruebas anteriores, simulando la participacin de varios usuarios en un ambiente de trabajo real. Pruebas de Carga y Stress: Son parecidas a las de volumen, la diferencia radica en que utilizan una mayor cantidad de datos para su ejecucin, su finalidad es evaluar al mximo el rendimiento del sistema. Crea condiciones exageradas de procesamiento. Permiten desarrollar planes de contingencia y pronosticar futuras actualizaciones.Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba


TIPOS DE PRUEBA (6)En funcin de qu se prueba: Pruebas de Falla del Sistema: En estas pruebas lo que se busca es determinar cmo es el comportamiento del sistema ante posibles fallas, bien sean internas (propias del software) o externas (fallas elctricas, sistema operativo, problemas de hardware, entre otras). Lo importante es lograr que el sistema pueda recuperarse luego de cualquier falla de la mejor manera posible y seguir funcionando normalmente.



PRUEBAS UNITARIAS (1)Razones para hacerlas

Son exhaustivas: Implica hacer pruebas por clase, funcin, etc., es decir, por la unidad mnima que se haya considerado. Permiten probar parte del cdigo sin esperar el desarrollo completo: Lo que permite la aplicacin del desarrollo interactivo. Proporcionan ms confianza para modificar el cdigo: Se pierde el miedo a hacer modificaciones y volver inconsistente el sistema. Mejoran la API: Podemos darnos cuenta de fallos en la interfaz de la clase en pasos prematuros, evitando as el costo que supone una modificacin en fases ms avanzadas. Sirven como documentacin de ejemplos de uso de la clase. Motivan: Cuando se ve que el cdigo pasa todas las pruebas.



PRUEBAS UNITARIAS (2)Qu se busca probar? Segn el tipo de componente: Funciones individuales o mtodos de objeto: probar las entradas y las salidas y comprobar que los valores obtenidos son los esperados. Clases de objetos:Hacer pruebas aisladas de operaciones Probar tambin las secuencias de las operaciones. Se tratan igual que una clase de objeto Hay que tener en cuenta si son distribuidos.

Componentes



PRUEBAS UNITARIAS (3)Qu se busca probar? Segn el aspecto en que nos centremos: Pruebas unitarias de cdigo aislado: Independientes del resto del sistema. Se implementan sustituyendo componentes por mocks, debido a que en la prctica las clases interactan entre s la mayora de las veces.

Pruebas unitarias de integracin: Se prueba cada componente, pero dentro del todo de la aplicacin, no como elemento aislado



PRUEBAS UNITARIAS (4)Tipos Pruebas Estructurales: Son pruebas de caja blanca. Pruebas de Particiones: Son pruebas de caja negra. Consisten en dividir las posibles entradas y salidas en conjuntos de caractersticas similares, identificando los casos especiales. Al probar valores debe considerarse lo siguiente:Probar siempre los lmites. Cuando tenemos listas, vectores, tablas: Probar listas de un solo valor y listas vacas. Probar siempre distintos tamaos. Comprobar primer elemento, el elemento central y el ltimo elemento. Pasar null en vez del objeto.



PRUEBAS UNITARIAS (5)Desarrollo Conducido por Pruebas (TDD Test-Drive Development)



PRUEBAS DE CAJA BLANCA (1)Se basa en un minucioso examen de las estructuras de control utilizadas en el diseo procedimental para obtener los casos de prueba, con el fin de: Garantizar que se ejecuten al menos una vez todos los caminos independientes de cada mdulo. Ejecutar todas las decisiones lgicas (V/F). Ejecutar todos los bucles en sus lmites. Comprobar la validez de las estructuras de datos internas.

1. 2. 3.

Los errores son inversamente proporcionales a la posibilidad de que se ejecute un camino del programa. Un camino lgico puede ejecutarse de forma normal, aunque pensemos que tiene pocas posibilidades. Los errores tipogrficos son aleatorios



PRUEBA DE CAJA BLANCA (2)Prueba del Camino Crtico Permite obtener una medida de la complejidad lgica de un diseo procedimental, con el objetivo de usar esa medida como gua para la definicin de un conjunto bsico de caminos de ejecucin. Pasos: 1. Generar el Grafo de Flujo a partir del cdigo. 2. Calcular la Complejidad Ciclomtica 3. Determinar un conjunto de caminos linealmente independientes 4. Generar Casos de Prueba



PRUEBAS DE CAJA BLANCA (3)Prueba del Camino Crtico Grafo de Flujo Representa el flujo de control de un programa Notacin:

Secuencia Condicin IF Bucle (While) Bucle (Hasta) Seleccin Multiple (Case)

Cada crculo (NODO) representa una o ms instrucciones, sin bifurcaciones. Cada Flecha se denomina ARISTA. Una arista debe terminar en un nodo. Las reas delimitadas por aristas y nodos se denominan regiones.Ingeniera de Software II. Trayecto III. Trimestre III. Mdulo: Pruebas y Validacin de Software. Unidad 1. Tcnicas de Prueba


PRUEBA DE CAJA BLANCA (3)Prueba del Camino Crtico Grafo de Flujo. Representa el flujo de control lgico Ejemplo:Aristas1 2,3 2 6 3 7 4 8 9 10 5 10 1

Regin 28

4,5

Regin 19

Regin 3

6 7

Regin 411

11



PRUEBA DE CAJA BLANCA (4)Prueba del Camino Crtico Complejidad Ciclomtica. Es una mtrica que proporciona una medicin cuantitativa de la complejidad lgica de un programa. Define el nmero de CAMINOS INDEPENDIENTES del conjunto bsico de un programa, a fin de determinar el lmite superior para el nmero de pruebas que deben realizarse. Est basada en la teora de grafos. Se puede calcular de tres formas.



PRUEBA DE CAJA BLANCA (5)Prueba del Camino Crtico Complejidad Ciclomtica. Formas de Clculo 1. V(G) = NR donde NR es el Nmero de Regiones del grafo. 2. V(G) = A N + 2 donde A es el nmero de aristas del grafo y N es el nmero de nodos. 3. V(G)= P + 1 donde P es el nmero de nodos predicado que contiene el grafo (Un nodo predicado es cada nodo que contiene una condicin)



PRUEBA DE CAJA BLANCA (5)Prueba de Condicin Se centra en la prueba de cada una de la las condiciones de un programa. Existen 2 tipo de condiciones. Simples y Compuestas. Condicin Simple Es una variable lgica o una expresin relacional, posiblemente precedida por el operador lgico NOT. Tiene la siguiente forma: E1 E2donde E1 y E2 son Variables, Constantes o Expresiones Aritmeticas y Operador Relacional puede ser uno de los siguientes: >, >=,

Unidad I. Técnicas de Prueba

Documents

Transcript of Unidad I. Técnicas de Prueba