Professional Documents
Culture Documents
3/23/13
Tcnicas de prueba
3/23/13
El desarrollo de Sistemas de software implica la realizacin de una serie de actividades predispuestas a incorporar errores. Debido a que estos errores se deben a nuestra habilidad innata de provocar errores, tenemos que incorporar una actividad que garantice la calidad del software. Haga clic para modificar el estilo de subttulo del patrn
En la etapa de prueba del software se crean una serie de casos de prueba que intentan "destruir" el software desarrollado.
La prueba requiere que se descarten ideas preconcebidas sobre la "calidad o correccin" del software desarrollado.
Objetivos de la prueba
3/23/13
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.
Proceso de prueba
El proceso de prueba tiene dos entradas:
3/23/13
Incluye la especificacin de requisitos del software, la especificacin del diseo y el cdigo fuente. 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: Configuracin de prueba La calidad y la fiabilidad del software son aceptables, o que Las pruebas son inadecuadas para descubrir errores serios
Prueba Funcional
3/23/13
Es una prueba basada en la ejecucin, revisin y retroalimentacin de las funcionalidades previamente diseadas para el software. Las pruebas funcionales se hacen mediante el diseo de modelos de prueba que buscan evaluar cada una de las opciones con las que cuenta el paquete informtico.
prueba de Humo Las pruebas de aceptacin Pruebas de regresin Beta de prueba Prueba Alfa
Proceso de prueba
3/23/13
A todas las pruebas se les debera poder hacer un seguimiento hasta cumplir con los requisitos del cliente Principios de las pruebas
Las pruebas deberan planificarse mucho antes de que empiecen. El principio de Pareto es aplicable a la prueba del software.
Para ser ms eficaces, las pruebas deberan ser realizadas por un equipo independiente.
Las pruebas deberan empezar por lo pequeo y progresar hacia lo grande No son posibles las pruebas exhaustivas.
3/23/13
Las pruebas
DE LA CAJA NEGRA Se basan sobre la interfaz del software De sistema. El mtodo de la caja negra se centra en los requisitos fundamentales del software y permite obtener entradas que prueben todos los requisitos funcionales del programa.
3/23/13
DE LA CAJA BLANCA
Comprueban los caminos lgicos del software proponiendo Se puede examinar el estado del programa en varios puntos para determinar si el estado real coincide con el esperado o mencionado.
Consiste en realizar pruebas para verificar que lneas especficas de cdigo funcionan tal como esta definido. Tambin se le conoce como prueba de caja-transparente
Funciones incorrectas o ausentes. Errores de interfaz. a Errores en estructuras de datos o en accesos a las bases de datos externas. Errores de rendimiento. Errores de inicializacin y terminacin.
3/23/13
Se ejecutan al menos una vez todos los caminos independientes de cada mdulo Se utilizan las decisiones en su parte verdadera y en su parte falsa Se ejecuten todos los bucles en sus lmites Se utilizan todas las estructuras de datos internas.
El mtodo del camino bsico permite obtener una medida de la complejidad de un diseo procedimental, y utilizar esta medida como gua para la definicin de una serie de caminos bsicos de ejecucin, diseando casos de prueba que garanticen que cada camino se ejecuta almenos una vez.
3/23/13
Actividades de desarrollo
3/23/13
Doc. Requisitos
Integracin Mantenimiento
Prueba de bucles
3/23/13
Los bucles son la piedra angular de la inmensa mayora de los algoritmos implementados en software, por lo que tenemos que prestarles una atencin especial a la hora de realizar la prueba del software. La prueba de bucles es una tcnica de prueba de caja blanca que se centra en la validez de las construcciones de los bucles.
Bucles Anidados
3/23/13
Si extendiramos el enfoque de prueba de los bucles simples a los bucles anidados, el nmero de posibles pruebas aumenta geomtricamente a medida que aumenta el nivel de anidamiento
Bucles No Estructurados
Siempre que sea posible,esta clase de bucles se deben redisear para que se ajusten a las construcciones de programacin estructurada
Bucles concatenados
3/23/13
Los bucles concatenados se probar mediante el enfoque anteriormente definido para los bucles simples, mientras cada uno de los bucles sea independiente del resto
Complejidad ciclomtica
refleja directamente el nmero de caminos independientes que un programa puede tomar durante su ejecucin. Cualquier desarrollador que haya probado cdigo en su vida, sabe que la cantidad de pruebas necesarias para ejercitar un determinado lugar del cdigo es directamente proporcional a su rbol de decisiones. En otras palabras, cuantos ms caminos el cdigo puede tomar (ya sea por medio de condiciones o bucles), mayor es la cantidad de pruebas necesarias.
3/23/13
3/23/13
Recomendaciones Generales
Debe contarse con criterios de aceptacin previamente aprobados por el usuario No hay que olvidar validar tambin la documentacin y los procedimientos de uso (por ejemplo, mediante una auditora) Las pruebas se deben realizar en el entorno en el que se utilizar el sistema (lo que incluye al personal que lo maneja)
3/23/13