Clasificacion y Pruebas De Software

3. Técnicas de prueba 3.1 Conceptos básicos Técnica de prueba: es un método que se utiliza para detectar errores en el software Prueba: es el proceso de ejecutar un programa con la intención de encontrar errores. La prueba es una tarea extremadamente creativa e intelectualmente desafiante. Una prueba no es: • Demostración de que no hay errores • Demostración de que el software desempeñacorrectamente sus funciones • Establecimiento de confianza de que un programa hace lo que debe hacer Visión más apropiada de testing: proceso destructivo de tratar de encontrar errores (cuya presencia se asume!) en un programa. 3.2 Características de las pruebas 1. Primero se realiza la prueba a nivel de módulos y posteriormente se hace una prueba integral 2. Que sea un grupo independiente el que realicela prueba (SQA) 3. Se pueden elegir entre varias técnicas de prueba de acuerdo al proyecto 4. La prueba y depuración son diferentes, pero una prueba debe incluir la depuración El propósito de la prueba es mostrar que un programa tiene errores, mientras que el de la depuración es encontrarlo y corregirlo. Las pruebas facilitan: • Comprobar la lógica interna de los componentes de software • Verificarlos dominios de E/S del programa, rendimiento y comportamiento. Objetivos de la prueba 1. La prueba es el proceso de ejecución de un programa con la intención de detectar un error. 2. Un buen caso de prueba es aquel que tiene una alta probabilidad de mostrar un error no descubierto hasta entonces. 3. Una prueba tiene éxito si detecta errores no encontrados hasta entonces. 3.3 Aspectos esencialesdel proceso de prueba 1. Prevención de la migración de los defectos utilizando técnicas de prueba temprano en el ciclo de vida. 2. El testing es una disciplina profesional que requiere gente entrenada y competente 3. Se debe cultivar una actitud de equipo positiva para la destrucción creativa. 4. Una parte necesaria de un caso de prueba es la definición de la salida o resultado esperado. 5.Examinar un programa para ver si no hace lo que debe hacer es sólo la mitad de la tarea, la otra mitad es ver si hace lo que no debe hacer. 6. Evitar casos de prueba espontáneos y que no dejan registro – es sólo pérdida de tiempo 7. La probabilidad de existencia de más defectos en una sección de programa es proporcional al número de defectos ya detectados en dicha sección. 3.4 Principios de la prueba 1.Toda prueba debe poder seguirse hasta la especificación de requisitos del cliente 2. Deben planificarse antes de que empiecen 3. El principio de Pareto es aplicable a las pruebas del software. 80% de los errores se encuentran en el 20% del programa 4. Las pruebas deberían empezar por lo “pequeño” y progresar hacia lo “grande” 5. No son posibles pruebas exhaustivas. Ej: en un programa en C con 100líneas, 2 ciclos que se ejecutan 20 veces dependiendo de ciertas condiciones y 4 if´s en el ciclo anidado, se tendrían 1014 casos en un procesador que ejecute cada caso en 1ms, trabajando 24*365 se tardaría 3170 años. 6. Las pruebas debería realizarlas un equipo independiente del que desarrolló 3.5 Facilidad de prueba Las características que indican la facilidad de prueba son: Operatividad:cuanto mejor funcione, más eficientemente se puede probar. • El sistema tiene pocos errores • Se considera la recuperación de errores • Ningún error bloquea la ejecución del programa

Observabilidad: lo que ves es lo que pruebas • Se genera una salida distinta para cada entrada • Es fácil identificar una condición de error • Se informa de los errores internos • El código fuente es accesibleControlabilidad: Cuando mejor podamos controlar el software más se puede automatizar. • Los formatos son consistentes • Se pueden automatizar las pruebas de acuerdo a la funcionalidad Capacidad de descomposición: controlando el ámbito, se pueden aislar problemas • El sistema se construye utilizando módulos independientes • Se pueden probar de acuerdo a la funcionalidad Simplicidad: Cuando menos sea, más...