La estrategia de pruebas de software proporciona un mapa que describe los pasos que se daran como parte de la prueba indica cuando se planea y cuando se daran dichos pasos ademas cuanto tiempo, esfuerzo y recursos consumiran.
un software se prueba para descubrir los errores cometidos, si se realiza sin ningun plan seguramente se desperdiciara tiempo, se dedicara un esfuerzo innecesario y lo que es peor puede que no se detecten los errores.
Las pruebas se deben planificar con anticipacion y realizarlas de manera sistematica por lo que es importante tener una plantilla existen diferentes y en general tienen los siguientes pasos.
1. Revisiones tecnicas formales y efectivas
2. Se inicia a nivel de componentes y se trabaja hacia afuera hacia la integracion del sistema
3. Diferentes tecnicas en diferentes momentos
4. las pruebas las dirige el desarrollador
5. la prueba y la depuracion son actividades diferentes, pero la segunda debe incluirse en cualquier estrategia de pruebas.
las pruebas integran un elemento mas amplio el cual se llama verificacion y validacion.
La verificacion es un conjunto de actividades que aseguren que el software implemente correctamente la funcion especifica.
Validacion asegura que el software responde a las necesidades del cliente.
El desarrollador debe siempre ser responsable de probar las unidades individales del software y en muchos casos tambien la integracion. solo despues que la arquitectura este completa participara un grupo independiente el uso de un equipo independiente elimina el conflicto de intereses que provoca que quien ha construido el sistema lo pruebe.
la estrategia de pruebas deberia seguir el siguiente esquema
un software se prueba para descubrir los errores cometidos, si se realiza sin ningun plan seguramente se desperdiciara tiempo, se dedicara un esfuerzo innecesario y lo que es peor puede que no se detecten los errores.
Las pruebas se deben planificar con anticipacion y realizarlas de manera sistematica por lo que es importante tener una plantilla existen diferentes y en general tienen los siguientes pasos.
1. Revisiones tecnicas formales y efectivas
2. Se inicia a nivel de componentes y se trabaja hacia afuera hacia la integracion del sistema
3. Diferentes tecnicas en diferentes momentos
4. las pruebas las dirige el desarrollador
5. la prueba y la depuracion son actividades diferentes, pero la segunda debe incluirse en cualquier estrategia de pruebas.
las pruebas integran un elemento mas amplio el cual se llama verificacion y validacion.
La verificacion es un conjunto de actividades que aseguren que el software implemente correctamente la funcion especifica.
Validacion asegura que el software responde a las necesidades del cliente.
El desarrollador debe siempre ser responsable de probar las unidades individales del software y en muchos casos tambien la integracion. solo despues que la arquitectura este completa participara un grupo independiente el uso de un equipo independiente elimina el conflicto de intereses que provoca que quien ha construido el sistema lo pruebe.
la estrategia de pruebas deberia seguir el siguiente esquema
pasos de las pruebas de software
Prueba de unidad, utiliza tecnicas que recorren caminos especificos en una estructura de control del componente que asegura una cobertura completa y una deteccion maxima de errores.
Las pruebas de integracion atiende todos los ascpectos asociados con el doble problema de verificacion y construccion del programa
Las pruebas de alto nivel de validacion nos proporciona un aseguramiento final de que el software cumple con todos los requisitos funcionales de comportamiento y desempeño.
Al igual que las pruebas convencionales las pruebas orientadas a objetos inician por lo pequeño y se dirigen hacia lo grande pero en este caso un modulo o componente o una unidad puede ser una clase o un conjunto de clases que colaboren entre si.
Criterios para completar pruebas
muchas veces surje la pregunta ¿cuando se termina de hacer pruebas? la verdad no existe una respuesta concreta puesto que la carga se transfiere del ingeniero de software al cliente ya que cada ves que el software se ejecuta este se esta probando.
Otra respuesta cinica pero correcta es las pruebas se terminan cuando se agota el tiempo y el dienero.
Otro enfoque practico es el utilizar pruebas estadisticas que nos aseguren con un nivel de confianza alto que las pruebas estan completas.
Aspectos estrategicos
si se desea implementar con exito una estrategia de pruebas de software se debe seguir los siguientes aspectos
Especificar los requisitos del producto de manera cuantificable mucho antes de que empiecen las pruebas
Establecer explicitamente los objetivos de la prueba
Comprender cuales son los usuarios del software y desarrollar un perfil para cada categoria del usuario.
Desarrollar un plan de pruebas que destaque la prueba del ciclo rapido
Construir un software robusto diseñado para probarse a si mismo
Utilizar revisiones tecnicas formales y efectivas como filtro previo a la prueba
Realizar revisiones tecnicas formales para evaluar la estrategia de prueba y los propios casos de la prueba
Desarrollar un enfoque de mejora continua para la prueba
ESTRATEGIAS DE PRUEBA PARA EL SOFTWARE CONVENCIONAL
Uno de los mejores enfoques que se pueden realizar y es muy efectivo es realizar pruebas diarias del componente que este desarrollando. aun que muchos equipos no les guste, la mayoria elige un enfoque en el cual hace pruebas a un conjunto de unidades.
Entre los errores mas comunes durante las pruebas de unidad se encuentran:
1. mal aplicacione de la precedencia aritmetica.
2. operaciones de modo mescladas
3. inicializacion incorrecta
4. falta de precicion
5. representacion simbolica incorrecta de una expresion.
es importante llevar al software a sus limites durante las pruebas de unidad
hay situaciones en los cuales no se pueden realizar pruebas completas de unidad para lo cual debe seleccionarse un conjunto de actividades criticas sobre las cuales se realizaran las pruebas.
El utilizar un enfoque de big bang puede conducir a el caos y posiblemente al fracaso pueso que no se pueden aislar los componentes por separado y es muy dificil encontrar el problema. Y en contra a este enfoque se recomienda la integracion incremental en el cual se avanza sobre pequeños incrementos en los cuales se propone
Integracion descendentes, sobre la jerarquia de control iniciando con el modulo de control principal
Integracion ascendente como su nombre lo indica se inicia con la construccion y pruebas de modulos atomicos hacia los principales. una integridad ascendente elimna la necesidad de resguardos complejos.
Las preubas de regresion es una estrategia importante para reducir efectos colaterales debe aplicarse una prueba de regresion cada vez que se haga un cambio importante en el software.
Pruebas de humo puede caracterisarse como una estrategia de integracion continua. se configura el software con nuevos componentes integrados y se aplica una prueba de humo todos los dias. Se utiliza en proyectos en las cuales el tiempo es critico esto permite que el equipo de software evalue el software con frecuencia.
Beneficios de las pruebas de humo se encuentran
minimizar los riesgos de integracion
se mejora la calidad del producto final
se simplifica el diagnostico y correccion de errores
el progreso es mas facil de evaluar
Documento de prueba de integracion
se debe generar el documento de especificacion de prueba, este documento contiene un plan de prueba un procedimiento de prueba es un producto del proceso de software y se vuelve parte de la configuracion.
las prueba alfa son los usuarios finales quienes las realizan en el lugar de trabajo del desarrollador
las prueba beta en el lugar de trabajo de los usuarios finales
Comentarios