Presentacin de PowerPoint

El proceso de pruebas de software1es una fase muy importante en la mayora de los modelos conocidos que hablan acerca del ciclo de vida del software, este aspecto, busca resaltar y generar mayor confianza a los desarrolladores en el proceso de pruebas del Software. Debido a lo anterior, se hace necesaria la implementacin de mecanismos que permitan garantizar la calidad del Software, estos se denominan modelos

Las pruebas en el mbito de la Ingeniera de SoftwareDependiendo del esquema de ingeniera de software, las pruebas se ajustan al ciclo de desarrollo del producto.

El modelo Cascada, permite que se realicen las pruebas, una vez terminada la construccin del sistema.El modelo Incremental mediante este modelo, se realizan pruebas en cada etapa o incremento del sistema.El modelo Evolutivo, este modelo, se enfoca en el fundamento de uso y la retroalimentacin de los usuarios.El modelo espiral, este modelo, admite diversas pruebas cclicas durante la verificacin y validacin del desarrollo.El modelo XP ( Xtreme Programming ), efecta pruebas repetidas de cada una de las mejoras que se encuentren, debido a su desarrollo iterativo e incremental.

Las pruebas en el mbito de la Ingeniera de Software

Para el caso de Software Quality Assurance (SQA) permite asegurar la calidad de los resultados de cada una de las fases del ciclo de vida del software, debido a esto, dicho modelo de prueba, es un ejemplo del modelo Incremental que realiza pruebas en cada etapa o incremento del sistema asegurando la calidad del producto final.

Para cumplir con un procedimiento de pruebas de software, se deben definir estndares y establecer procedimientos mediante los cuales, se pueda comparar lo alcanzado durante cada una de las fases.

Para el caso de la implementacin del Modelo Cascada en el desarrollo de un software, se establecen los siguientes procedimientos:

Las pruebas en el ambito de la Ingeniera de Software

En la fase de anlisis, se define un tipo de documento que se requiere para pasar a la fase de diseo, ese documento, deber cumplir con lo establecido para cada fase debido que una fase que no se ejecut de forma correcta causar defectos en las fases posteriores.

Una parte de vital importancia para este tipo de implementacin es que mientras ms temprano se detecten las fallas, menor ser el costo de repararlas y mayor la calidad del producto final. De acuerdo con esto, ser ms sencillo sealar un par de diferencias y relaciones entre dos modelos comunes que son el modelo Cascada y el QA de software o SQA, estas, se realizan a partir de:

Las pruebas en el ambito de la Ingeniera de Software

Las Pruebas de Software se realizan en una de las fases del ciclo de vida del software; mientras que QA de software se deber ejecutar en todas las fases (incluida la fase de Pruebas).Las Pruebas de Software utilizarn casos de pruebas para ser ejecutados, en cambio QA de software, utilizar los estndares y procedimientos establecidos para cada una de las fases del ciclo de vida del software.Asegurar que las desviaciones del trabajo y los productos del software se documenten y se manejen de acuerdo con el procedimiento establecido.Ambas permitirn verificar y afirmar la calidad del producto final, el software.Ambas definen un conjunto de actividades a realizarse dentro del ciclo de vida del software, para mejorar y asegurar la calidad del mismo.

Las pruebas en el mbito de la Ingeniera de Software

Objetivos del proceso de Pruebas de Software:

Encontrar fallas y defectos en el software.Una prueba tiene xito si descubre un defecto.Una prueba fracasa si hay defectos pero no se les descubre.

Pruebas de Verificacin

Es el proceso de evaluacin de un sistema o de uno de sus componentes para determinar si los productos de una fase dada satisfacen las condiciones impuestas al comienzo de dicha fase [IEEE 90] En otras palabras pretenden determinar si el producto est siendo construido correctamente.

Pruebas de Validacin

El proceso de evaluacin de un sistema o de uno de sus componentes durante o al final del proceso de desarrollo para determinar si satisface los requisitos especificados. [IEEE 90], En otras palabras pretenden determinar si se est desarrollando el producto correcto.

Pruebas Unitarias.

En las pruebas de unidad o unitarias se evala el funcionamiento individual de cada mdulo, escribiendo casos de prueba para cada funcionalidad o mtodo en el mdulo, de forma que se determine la integridad del mismo.

Pruebas de IntegracinLas pruebas de integracin pretenden verificar que el conjunto de los mdulos de un sistema funcionan adecuadamente en conjunto.

Objetivos del proceso de pruebas de software:

Una manera por medio de la cual se establecen los objetivos para realizar pruebas en un software, corresponden a dos grandes tem, que son:

Demostrar que el software satisface requerimientos del cliente, determinado a partir de:El software a medida: para este tipo de software, se efecta una prueba para cada requerimiento del sistema y del usuario.

El software genrico: para este tipo de software, se prueban todas las caractersticas del sistema que se incorporarn en la entrega del producto.Pruebas de validacin: estas pruebas, permiten determinar el funcionamiento correcto del software, usando un conjunto determinado de casos de prueba que reflejan el uso esperado del sistema.

Hallar defectos en el software, sean estos: comportamiento incorrecto, no deseable o que no cumplen su funcin, esto se determina mediante:

Prueba de defectos: la cual permite eliminar todos los comportamientos no deseables. Por ejemplo: cadas del sistema, interacciones no permitidas con otros sistemas, clculos incorrectos y corrupcin de datos.Prueba de defectos: existen casos de prueba diseados para exponer los defectos

Las pruebas de caja blanca se enfocan en el funcionamiento interno del proyecto y cumplen entre otras con las siguientes caractersticas:El conocimiento del cdigo.Diagramas de flujo y controles de cada procedimiento o mtodo.Obtener calidad uniforme o ms predecible, facilitando el trabajo tcnico.Se procura ejecutar y probar cada elemento del cdigo.Se realiza un seguimiento a los flujos internos, condicionales, ciclos, mtodos, tipos de datos y algoritmos.

Dentro de las clases de pruebas ejecutadas mediante esta tcnica, se encuentran:Pruebas de cubrimiento.Pruebas de condiciones.Pruebas de bucles.

Pruebas de cubrimiento:Permiten ejecutar al menos una vez cada sentencia, para la cual se necesitan varios casos de prueba que permitan:

Determinar posibles caminos independientesQue cada condicin se cumpla en un caso y en otro no. En general, se necesitan tantos casos como condiciones, ms uno (nmero ciclomtico)Determinar la imposibilidad de cubrir el 100%Descubrir el cdigo que nunca se ejecuta: condiciones imposibles

Pruebas de condiciones:Este tipo de pruebas permiten cumplir o no, cada parte de cada condicin para ello, se necesitan varios casos de prueba que permitan:

Determinar expresiones simples en las condiciones.Una por cada operando lgico o comparacin.Cada expresin simple debe cumplirse en un caso y en otro no, siendo decisiva en el resultado.Determinar la imposibilidad de cubrir el 100%.Validar y probar expresiones simples no independientes.

Pruebas de bucles:Se utilizan para conseguir nmeros de repeticiones especiales a travs de bucles simples que permitan:Repetir cero, una y dos veces.Repetir el mximo-1, mximo y mximo +1!.Repetir un nmero medio (tpico) de veces.Bucles anidadosRepetir un nmero medio (tpico) los bucles internos, el mnimo los externos, y variar las repeticiones del bucle intermedio ensayado.Ensayarlo con cada nivel de anidamiento.

Las pruebas de caja negra se enfocan en las entradas y salidas del proyecto, sin tener en cuenta su funcionamiento interno y cumplen entre otras con las siguientes caractersticas:

Se pretende probar el desempeo del Sistema en su entorno.Se enfocan en las entradas y salidas, independiente de su funcionamiento interno.Se enfocan en asegurar que la comunicacin entre mdulos o componentes del sistema sea acorde a lo especificado.Se procura ejercitar cada elemento de la interfaz.Pruebas en que se conoce slo la interfaz.

Algunas clases de pruebas.

Cubrimiento: invocar todas las funciones (100%)Clases de equivalencia de datosPruebas de valores lmite

Pruebas de valores lmite

Estas pruebas, sirven como complemento a las particiones de equivalencia adems de permitir varios casos de prueba por cada particin, as:

Valores tpicos, intermedios.Valores primero y segundo del rango.Valores penltimo y ltimo.Valores vecinos fuera del rango (en otra particin)

Pruebas de valores lmite

Estas pruebas, sirven como complemento a las particiones de equivalencia adems de permitir varios casos de prueba por cada particin, as:Valores tpicos, intermedios.

Valores primero y segundo del rango.Valores penltimo y ltimo.Valores vecinos fuera del rango (en otra particin)

Motivacin: Los programadores se equivocan con ms frecuencia al tratar los valores en la frontera (Ej: > en vez de >).

Prueba de integracin

Integracin descendente.Integracin ascendente.Prueba de regresin.

Prueba del sistema

Prueba de recuperacin.Prueba de seguridad.

Estoy seguro de que lo he codificado bien. La depuracin sin estrategia Motivacin.Para lograr este tipo de pruebas se parte del principio de que se deben realizar, dejando de lado afirmaciones como:

Las pruebas son incmodas.Las pruebas son aburridas.Satisfaccin: capacidad de complacer a un usuario en un contexto de uso dadoSeguridad: capacidad de lograr niveles aceptables de riesgo para las personas, el ambiente de trabajo, y la actividad, en un contexto de uso determinado

Probar todo junto, al final. Tambin llamado prueba Big-Bang.

Falla por todas partes.Muy difcil diagnosticar las causas de los fallos.Muy costoso de arreglar.Resultado: productos finales defectuosos.

La depuracin sin estrategia Motivacin.

Esta prueba, permite la verificacin de la unidad ms pequea componente o mdulo del diseo del software, adems de verificar la lgica del procesamiento interno y ser aplicable a varios componentes al tiempo.

Prueba de integracin.

Es una tcnica sistemtica para construir la arquitectura del software, mientras, se aplican las pruebas para descubrir errores asociados con la interfaz. El objetivo, es tomar componentes a los que se aplic una prueba de unidad y construir una estructura de programa que determine el diseo.

Integracin descendente.

Esta prueba, se enfoca en determinar que la principal dificultad es localizar los errores. Existen interacciones complejas entre los componentes del sistema, y cuando se descubre una salida anmala, es difcil identificar dnde ha ocurrido el error.

Para facilitar la localizacin de errores, debera utilizarse una aproximacin incremental para la integracin y pruebas del sistema. Inicialmente, debera integrarse una configuracin del sistema mnima y probar este sistema.

Integracin ascendente

En esta parte, se deben aadir componentes a esta configuracin mnima y probar despus de aadir cada incremento.

Prueba de regresin

El proceso de ejecutar un conjunto existente de pruebas, se denomina pruebas de regresin. Cuando se integra un nuevo incremento, hay que volver a ejecutar las pruebas para incrementos previos as como las nuevas pruebas requeridas para verificar la nueva funcionalidad del sistema. Si las pruebas de regresin nos muestran problemas, entonces hay que verificar si stos son problemas en el incremento previo o si son debidos al incremento aadido de funcionalidad.

Prueba de validacin.

Permiten los siguientes procesos:

Repetir las pruebas tras cada modificacinHay que repetir slo pruebas de verificacin

Se efectan pruebas de unidades.Se efectan pruebas de integracin.Se llevan records donde se conservan y actualizan los programas de prueba.Se usan herramientas de ejecucin automtica de las pruebas.

Prueba de validacin.

Las pruebas de validacin, empiezan tras la culminacin de la prueba de integracin, cuando se han ejercitado los componentes individuales, se han terminado de ensamblar el software como paquete, adems se han descubierto y corregido los errores de interfaz. La prueba, se concentra en las acciones visibles para el usuario y en la salida del sistema que ste puede reconocer.

La validacin, se define de una forma simple que se alcanza cuando el software funciona de tal manera que satisface las expectativas razonables del cliente (especificacin de requisitos-criterios de validacin).

Prueba de validacin.

Para comprobar que se satisfacen los requisitos se debe tener en cuenta que:

Se usan la mismas tcnicas, pero con otro objetivo.No hay programas de prueba, sino slo el cdigo final de la aplicacin.Se prueba el programa completoUno o varios casos de prueba por cada requisito o caso de uso especificado.Se prueba tambin rendimiento, capacidad, etc. (y no slo resultados correctos).Pruebas alfa (desarrolladores) y beta (usuarios).

Prueba del sistema.

Al final del desarrollo, el software se incorpora a otros elementos del sistema (hardware, personas, informacin) y se realiza una serie de pruebas de integracin del sistema y de validacin.

Estas pruebas, estn ms all del alcance del proceso del software y no las realizan nicamente los ingenieros de software. Sin embargo, los pasos dados durante el diseo y la prueba del software, mejorarn en gran medida la probabilidad de tener xito en la integracin del software del sistema mayor, mediante:

Prueba de seguridad.

La interrupcin abarca un amplio rango de actividades, la prueba de seguridad, comprueba que los mecanismos de proteccin integrados en el sistema realmente lo protejan de irrupciones inapropiadas.

Durante la prueba de seguridad, quin la aplica, desempea el papel del individuo que desea entrar en el sistema.

Prueba de resistenciaLas pruebas de resistencia, estn diseadas para confrontar los programas con situaciones anormales. Ejecutan un sistema de tal manera que requiera una frecuencia o un volumen anormal de recursos.

La persona que aplica la prueba, tratar de sobrecargar el programa. Una variante de la prueba de resistencia, es una tcnica denominada: prueba de sensibilidad.

Las pruebas de sensibilidad, tratan de descubrir combinaciones de datos dentro de las clases de entrada vlidas que causen inestabilidad o procesamiento inapropiado.

Prueba de rendimiento

La prueba de rendimiento, est diseada para probar el desempeo del software en tiempo de ejecucin dentro del contexto de un sistema integrado.

Esta prueba, se aplica en todos los pasos del proceso de la prueba, incluso al nivel de la unidad, basados en que el desempeo de un mdulo individual debe evaluarse mientras se realizan las pruebas. Sin embargo, solo puede tenerse certeza de las posibles fortalezas o errores de cdigo, hasta que los componentes del software se encuentren totalmente integrados de manera que mediante la puesta a prueba de todos los elementos del sistema, es posible asegurar el verdadero desempeo de este, en diversa situaciones, condiciones y contextos.

Prueba de rendimiento

La prueba de rendimiento, est diseada para probar el desempeo del software en tiempo de ejecucin dentro del contexto de un sistema integrado.

Esta prueba, se aplica en todos los pasos del proceso de la prueba, incluso al nivel de la unidad, basados en que el desempeo de un mdulo individual debe evaluarse mientras se realizan las pruebas. Sin embargo, solo puede tenerse certeza de las posibles fortalezas o errores de cdigo, hasta que los componentes del software se encuentren totalmente integrados de manera que mediante la puesta a prueba de todos los elementos del sistema, es posible asegurar el verdadero desempeo de este, en diversa situaciones, condiciones y contextos.