4.1 DEFINICIONES 1. 2. 3. 4. 5. 6.

Verificacin: 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. 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 marcados por el usuario. Pruebas (test): Una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluacin de algn aspecto. Caso de prueba (test case): Un conjunto de entradas, condiciones de ejecucin y resultados esperados desarrollados para un objetivo particular. Fallo (failure): La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados. Defecto (defect, fault, bug): Un defecto en el software como, por ejemplo, un proceso, una definicin de datos o un paso de procesamiento incorrectos en un programa. 4.1.2 Relacin entre defecto falla error Ideas paradgicas de las prueba La prueba exhaustiva del software es impracticable (no se pueden probar todas las posibilidades de su funcionamiento ni siquiera en programas sencillos).El objetivo de las pruebas es la deteccin de defectos en el software (descubrir un error es el xito de una prueba). Recomendaciones para unas pruebas exitosas: -Cada caso de prueba debe definir el resultado de salida esperado que se comparar con el realmente obtenido. -Se debe inspeccionar a conciencia el resultado de cada prueba, y as, poder descubrir posibles sntomas de defectos. -se deben incluir tanto datos de entrada vlidos y esperados como no vlidos e inesperados -Se deben evitar los casos desechables, es decir, los no documentados ni diseados con cuidado. Ya que suele s -er necesario probar muchas veces el software y por tanto hay que tener claro qu funciona y qu no. - la probabilidad de descubrir nuevos defectos en una parte del software es proporcional al nmero de defectos ya descubierto. 4.1.3Enfoque de diseo de pruebas 1.- El enfoque estructural o de caja blanca. Se centra en la estructura interna del programa (analiza los caminos de ejecucin). 2.- El enfoque funcional o de caja negra. Se centra en las funciones, entradas y salidas 3.- El enfoque aleatorio consiste en utilizar modelos (en muchas ocasiones estadsticos) que representen las posibles entradas al programa para crear a partir de ellos los casos de prueba. -----PRUEBAS ESTRUCTURALES El diseo de casos de prueba tiene que estar basado en la eleccin de caminos importantes que ofrezcan una seguridad aceptable de que se descubren defectos, para lo que se usan los criterios de cobertura lgica. ------Criterios de cobertura lgica *Cobertura de sentencias. Se trata de generar los casos de prueba necesarios para que cada sentencia o instruccin del programa se ejecute al menos una vez. *Cobertura de decisiones. Consiste en escribir casos suficientes para que cada decisin tenga, por lo menos una vez, un resultado verdadero y, al menos una vez, uno falso. (Incluye a la cobertura de sentencias). *Cobertura de condiciones. Se trata de disear tantos casos como sea necesario para que cada condicin de cada decisin adopte el valor verdadero al menos una vez y el falso al menos una vez. (No incluye cobertura de condiciones). *Criterio de decisin/condicin. Consiste en exigir el criterio de cobertura de condiciones obligando a que se cumpla tambin el criterio de decisiones. *Criterio de condicin mltiple. En el caso de que se considere que la evaluacin de las condiciones de cada decisin no se realiza de forma simultnea, se puede considerar que cada decisin multicondicional se descompone en varias condiciones unicondicionales.. *Criterio de cobertura de caminos. Se recorren todos los caminos (impracticable) -----PRUEBAS FUNCIONALES

Se centran en las funciones, entradas y salidas. Seria imprctico probar el software para todas las posibilidades. De nuevo hay que tener criterios para elegir buenos casos de prueba. 1. 2. *Reduce el nmero de otros casos necesarios para que la prueba sea razonable. Esto implica que el caso ejecute el mximo nmero de posibilidades de entrada diferentes para as reducir el total de casos. *Cubre un conjunto extenso de otros casos posibles, es decir, no indica algo acerca de la ausencia o la presencia de defectos en el conjunto especfico de entradas que prueba, as como de otros conjuntos similares. ----PRUEBAS ALEATORIAS En las pruebas aleatorias simulamos la entrada habitual del programa creando datos de entrada en la secuencia y con la frecuencia con las que podran aparecer en la prctica (de manera repetitiva). Para ello habitualmente se utilizan generadores automticos de casos de prueba. 4.1.4 Documentacin del diseo de las pruebas. La documentacin del diseo de pruebas se compone de los siguientes pasos: Generar un plan de pruebas. Disear pruebas especficas. Especificar los casos de prueba (tomar configuracin del sw a probar). Especificar los procedimientos de las pruebas (configurar las pruebas). 4.2 PROCESO DE PRUEBAS Sealar el enfoque, los recursos y el esquema de actividades de prueba, as como los elementos a probar, las caractersticas, las actividades de prueba, el personal responsable y los riesgos asociados. Estructura del documento segn el estndar: 1. Identificador nico del documento. 2.Introduccin y resumen de elementos y caractersticas a probar. 3.-Elementos de software a probar. 4.-Caractersticas a probar. 5 Caractersticas que no se probarn 6 Enfoque general de la prueba 7 Criterios de paso / fallo para cada elemento. 8 Criterios de suspensin y requisitos de reanudacin 9 Documentos a entregar. 10 Actividades de preparacin y ejecucin de pruebas 11 Necesidades de entorno. 4.2.2Especificacin del diseo de pruebas. Especificar los refinamientos sobre el enfoque general reflejado en el plan e identificar las caractersticas que se deben probar con este diseo de pruebas. Estructura del documento segn el estndar: 1. 2. 3. 4. Identificador nico para la especificacin (proporcionar tambin una referencia del plan asociado (si existe). Caractersticas a probar de los elementos de software (y combinaciones de caractersticas). Identificacin de cada prueba: Criterios de paso / fallo de la prueba (criterios para determinar si una caracterstica o combinacin de caractersticas ha pasado con xito la prueba o no) 4.2.3Especificacin de caso de pruebas. Definir uno de los casos de prueba identificado por una especificacin del diseo de las pruebas. Estructura del documento segn el estndar: 1. 2. Identificador nico de la especificacin. Elementos de software (por ejemplo, mdulos) que se van a probar: definir dichos elementos y las caractersticas que ejercitar este caso.

3. 4. 5. 6. 7.

Especificaciones de cada entrada requerida para ejecutar el caso ( incluyendo las relaciones entre las diversas entradas; por ejemplo: la sincronizacin de las mismas). Especificaciones de todas las salidas y las caractersticas requeridas (por ejemplo, el tiempo respuesta) para los elementos que se van a probar. Necesidades de entorno (hardware, software y otras, como por ejemplo el personal). Requisitos especiales de procedimiento para ejecutar este caso. Dependencias entre casos (por ejemplo, listar los identificadores de los casos que se van a ejecutar antes de este caso de prueba). 4.2.4Especificacin de procedimiento de prueba.

Especificar los pasos para la ejecucin de un conjunto de casos de prueba, o ms generalmente, los pasos utilizados para analizar un elemento de software con el propsito de evaluar un conjunto de caractersticas del mismo. Especificar los pasos para la ejecucin de un conjunto de casos de prueba, o ms generalmente, los pasos utilizados para analizar un elemento de software con el propsito de evaluar un conjunto de caractersticas del mismo. Estructura del documento segn el estndar: 1. 2. 3. Identificador nico de la especificacin y referencia a la correspondiente especificacin de diseo de prueba. Objetivo del procedimiento y lista de casos que se ejecutan con el. Requisitos especiales para la ejecucin (por ejemplo, entorno especial o personal especial) 4.2.5Evaluar resultados. Ejecutar, comprobar evaluar 1. 2. 3. 4. Documentacin de resultados. Histrico de pruebas: Documenta todos los hechos relevantes ocurridos durante la ejecucin de las pruebas. Informe de incidentes: Documenta cada incidente (por ejemplo, una interrupcin en las pruebas debido a un corte de electricidad, bloqueo del teclado, etc.) ocurrido durante la prueba y que requiera una posterior investigacin. Resumen de pruebas: Lista los resultados de las actividades de prueba y aporta una evaluacin del software basada en dichos resultados. 4.2.5.1Depuracin. Es el proceso de analizar y corregir los defectos que se sospecha que contiene el software.. Consejos para la depuracin. Localizacin del error: 1. 2. 3. 4. Analizar la informacin y pensar (analizar bien, en lugar de aplicar un enfoque aleatorio de bsqueda del defecto) Al llegar a un punto muerto, pasar a otra cosa (refresca la mente) Al llegar a un punto muerto, describir el problema a otra persona (el simple hecho de describir el problema a alguien puede ayudar) Usar herramientas de depuracin slo como recurso secundario (no sustituir el anlisis mental)

Correccin del error: 1. 2. 3. Donde hay un defecto, suele haber ms (lo dice la experiencia) Debe fijarse el defecto, no sus sntomas (no debemos enmascarar sntomas, sino corregir el defecto) La probabilidad de corregir perfectamente un defecto no es del 100% (cuando se corrige, hay que probarlo) a. Cuidado con crear nuevos defectos (al corregir defectos 4.2.5.2Anlisis de errores. proporcionar informacin sobre la naturaleza de los defectos. Para ello es fundamental recoger para cada defecto detectado esta informacin: Cundo se cometi?, Quin lo hizo Qu se hizo mal? 4.3 TECNICAS DE DISEO DE CASOS DE PRUEBAS TECNICA: Participaciones o clases de equivalencia.

Pasos para identificar las clases de equivalencia. 1. 2. .- Identificacin de las condiciones de las entradas del programa, es decir, restricciones de formato o contenido de los datos de entrada. .- A partir de ellas, se identifican clases de equivalencia que pueden ser: a) De datos vlidos. b) De datos no vlidos errneos.

2. Pasos para crear los casos de prueba. Asignacin de un numero nico a cada clase de equivalencia Hasta que todas las clases de equivalencia vlidas hayan sido cubiertas por (incorporadas a) casos de prueba, se tratara de escribir un caso que cubra tantas clases vlidas no incorporadas como sea posible. TECNICA: Conjetura de errores. Se enumera una lista de posibles equivocaciones tpicas que pueden cometer los desarrolladores y de situaciones propensas a ciertos errores 1. 2. El valor cero es una situacin propensa a error tanto en la salida como en la entrada. En situaciones en las que se introduce un nmero variable de valores, conviene centrarse en el caso de no introducir ningn valor y en el de un solo valor. Tambin puede ser interesante una lista que tiene todos los valores iguales. 4.5 ESTRATEGIAS DE APLICACIN DE LAS PRUEBAS 1. 2. Se analiza como plantear las pruebas en el ciclo de vida del software. La estrategia de pruebas suele seguir estas etapas: a. Comenzar pruebas a nivel de modulo b. Continuar hacia la integracin del sistema completo y su instalacin c. Culminar con la aceptacin del producto por la parte del cliente 4.5.1PRUEBAS DE UNIDAD Se trata de las pruebas formales que permiten declarar que un mdulo est listo y terminadoLa prueba de unidad puede abarcar desde un mdulo hasta un grupo de mdulos (incluso un programa completo) Estas pruebas suelen realizarlas el propio personal de desarrollo, pero evitando que sea el propio programador del mdulo 4.5.2PRUEBAS DE INTEGRACIN Implican una progresin ordenada de pruebas que van desde los componentes o mdulos y que culminan en el sistema completo. 4.5.3PRUEBAS DE SISTEMA Es el proceso de prueba de un sistema integrado de hardware y software para comprobar lo siguiente: +Cumplimiento de todos los requisitos funcionales, considerando el producto software final al completo en un entorno de sistema. +El funcionamiento y rendimiento en las interfaces hardware, software, de usuario y de operador. 4.5.4PRUEBAS DE ACEPTACION Es la prueba planificada y organizada formalmente para determinar si se cumplen los requisitos de aceptacin marcadospor el cliente.