Laura Patricia Pinto Prieto
PRUEBAS DEL SOFTWARE PARTE 2
Diseño de casos de prueba
1.
2.
Prueba de caja negra :Conociendo la función
específica para la que fue diseñado el producto,
se pueden llevar a cabo pruebas que demuestren
que cada función es completamente operativa y,
al mismo, tiempo buscando errores en cada
función;
Prueba de caja blanca : Conociendo el
funcionamiento del producto, se pueden
desarrollar pruebas que aseguren que «todas las
piezas encajan», o sea, que la operación interna
se ajusta a las especificaciones y que todos los
componentes internos se han comprobado de
forma adecuada.
Diseño de casos de prueba.
Enfoques principales
Profesor: Juan
Antonio López
Quesada
Pruebas de Software
(Piattini et al. 96)
3
Diseño de casos de prueba.
Comparación de los Enfoques principales
a) Enfoque estructural o de caja blanca
(transparente):



se centra en la estructura interna del programa para
elegir los casos de prueba
la prueba exhaustiva consistiría en probar todos los
posibles caminos de ejecución
nº caminos lógicos  ( buscar los más importantes)
b) Enfoque funcional o de caja negra:


para derivar los casos, se estudia la especificación de
las funciones, la entrada y la salida.
NoProfesor:
sonJuan
excluyentes.
Antonio López
Quesada
Pruebas de Software
4
Prueba de caja Negra


Las pruebas de caja negra, también denominada prueba
de comportamiento, se centran en los requisitos
funcionales del software. O sea, la prueba de caja negra
permite al ingeniero del software obtener conjuntos de
condiciones de entrada que ejerciten completamente
todos los requisitos funcionales de un programa.
La prueba de caja negra intenta encontrar errores de las
siguientes categorías: (1) funciones incorrectas o
ausentes, (2) errores de interfaz, (3) errores en
estructuras de datos o en accesos a bases de datos
externas, (4) errores de rendimiento y (5) errores
de inicialización y de terminación.
Profesor: Juan
Antonio López
Quesada
Pruebas de Software
5
Preguntas







¿Cómo se prueba la validez funcional?
¿Cómo se prueba el rendimiento y el comportamiento del
sistema?
¿Qué clases de entrada compondrán unos buenos casos
de prueba?
¿Es el sistema particularmente sensible a ciertos valores
de entrada?
¿De qué forma están aislados los límites de una clase de
datos?
¿Qué volúmenes y niveles de datos tolerará el sistema?
¿Qué efectos sobre la operación del sistema tendrán
combinaciones específicas de datos?
Partición equivalente
La partición equivalente es un método de prueba de caja
negra que divide el campo de entrada de un programa en
clases de datos de los que se pueden derivar casos de
prueba.
Las clases de equivalencia se pueden definir de acuerdo con
las siguientes directrices:
1. Si una condición de entrada especifica un rango, se define
una clase de equivalencia válida y dos no válidas.
2. Si una condición de entrada requiere un valor
específico, se define una clase de equivalencia válida y dos
no válidas.
3. Si una condición de entrada especifica un miembro de
un conjunto, se define una clase de equivalencia válida y
una no válida.
4. Si una condición de entrada es lógica, se define una
clase de equivalencia válida y una no válida.

Análisis de valores límite

Por razones que no están del todo
claras, los errores tienden a darse más
en los límites del campo de entrada que
en el «centro». Por ello, se ha
desarrollado el análisis de valores
límites (AVL) como técnica de prueba.
El análisis de valores límite nos lleva a
una elección de casos de prueba que
ejerciten los valores límite.
Las directrices de AVL
1. Si una condición de entrada especifica un rango delimitado por los valores a y
b, se deben diseñar casos de prueba para los valores a y b, y para los valores
justo por debajo y justo por encima de a y b, respectivamente.
2. Si una condición de entrada especifica un número de valores, se deben desarrollar
casos de prueba que ejerciten los valores máximo y mínimo. También se deben
probar los valores justo por encima y justo por debajo del máximo y del mínimo.
3. Aplicar las directrices 1 y 2 a las condiciones de salida. Por ejemplo,
supongamos que se requiere una tabla de «temperatura / presión» como salida de
un programa de análisis de ingeniería. Se deben diseñar casos de prueba que creen
un informe de salida que produzca el máximo (y el mínimo) número permitido
de entradas en la tabla.
4. Si las estructuras de datos internas tienen límites preestablecidos (por
ejemplo, una matriz que tenga un límite definido de 100 entradas), hay que
asegurarse de diseñar un caso de prueba que ejercite la estructura de datos en sus
límites.
Prueba de comparación



Hay situaciones (por ejemplo, aviónica de aeronaves, control de
planta nuclear) en las que la fiabilidad del software es algo
absolutamente crítico. En ese tipo de aplicaciones, a menudo se
utiliza hardware y software redundante para minimizar la posibilidad
de error.
Cuando se desarrolla software redundante, varios equipos de
ingeniería del software separados desarrollan versiones
independientes de una aplicación, usando las mismas
especificaciones.
En esas situaciones, se deben probar todas las versiones con los
mismos datos de prueba, para asegurar que todas proporcionan una
salida idéntica. Luego, se ejecutan todas las versiones en paralelo y
se hace una comparación en tiempo real de los resultados, para
garantizar la consistencia.
Pruebas de entornos especializados,
arquitecturas y aplicaciones




Prueba de interfaces gráficas de usuario
Prueba de arquitectura cliente/servidor
Prueba de sistemas de tiempo-real
Prueba de la documentación y
facilidades de ayuda :

La prueba de la documentación se puede
enfocar en dos fases. La primera fase, la
revisión e inspección , examina el documento
para comprobar la claridad editorial. La segunda
fase, la prueba en vivo, utiliza la
documentación junto al uso del programa real
ESTRATEGIAS DE PRUEBA DEL SW
UN ENFOQUE ESTRATÉGICO PARA
LAS PRUEBAS DEL SW




Las pruebas comienzan a nivel de modulo y
trabajan hacia fuera.
Según el momento son apropiadas diferentes
técnicas de prueba.
La prueba la lleva acabo el responsable del
desarrollo del SW.
La prueba y la depuración son actividades
diferentes, pero la depuración se debe incluir en
cualquier estrategia de prueba.
EL ARTE DE LA DEPURACIÓN.
La depuración ocurre como consecuencia de una prueba
efectiva. Es decir, cuando un caso de prueba descubre
un error, la depuración es el proceso que provoca la
eliminación del error.
Aunque la depuración puede y debe ser un proceso
ordenado, sigue teniendo mucho de arte. Un ingeniero
del software, al evaluar los resultados de una prueba, se
encuentra frecuentemente con una indicación
«sintomática» de un problema en el software. Es decir,
la manifestación externa de un error, y la causa interna
del error pueden no estar relacionadas de una forma
obvia. El proceso mental, apenas comprendido, que
conecta un síntoma con una causa es la depuración.
La depuración no es una prueba, pero siempre ocurre como
consecuencia de la prueba. El proceso de depuración siempre
tiene uno de los dos resultados siguientes:
1. se encuentra la causa, se corrige y se elimina;
2. o no se encuentra la causa.
En este último caso, la persona que realiza la depuración debe
sospechar la causa, diseñar un caso de prueba que ayude a
confirmar sus sospechas y el trabajo vuelve hacia atrás a la
corrección del error de una forma iterativa.
Durante la depuración encontramos errores que van desde lo
ligeramente inesperado (por ejemplo, un formato de salida
incorrecto) hasta lo catastrófico (por ejemplo, el sistema falla,
produciéndose serios daños económicos o físicos).
EL PROCESO DE DEPURACIÓN
VERIFICACIÓN Y VALIDACIÓN (V &V)


La verificación se refiere al conjunto de
actividades que asegura que el software
implementa
adecuadamente
una
función
específica.
La validación se refiere a un conjunto diferente de
actividades que aseguran que el software
construido se ajusta a lo requerimientos del
cliente.
Bohem, lo define de otra forma:


Verificación “¿Estamos construyendo el producto
correctamente?”
Validación “¿Estamos construyendo el producto
correcto?”
UNA ESTRATEGIA DE
PRUEBA DEL SW

La prueba en el contexto de espiral
UNA ESTRATEGIA DE PRUEBA DEL SW

Desde el punto de vista procedimental
Requisitos
Diseño
Pruebas de
alto nivel
Codificación
Dirección del
la prueba
Prueba de
Integración
Prueba de
unidad
Etapas de prueba del SW
CRITERIOS PARA COMPLETAR
LA PRUEBA
Cada vez que se tratan de las pruebas del SW
surgen unas preguntas clásicas:
¿Cuándo hemos terminado la prueba?
¿Cómo sabemos que hemos probado lo suficiente?
‘¿Cuando debemos probar?’
Una respuesta a la “La prueba nuca termina ya que el
responsable carga o pasa el problema al cliente”
Otra respuesta algo cínica es “Se termina la prueba
cuando se agota el tiempo o el dinero disponible para
cada efecto”
ASPECTOS ESTRATÉGICOS




Ton Gilb, plantea que se deban abordar los
siguientes puntos si se desea implementar con
éxito una estrategia de prueba del SW:
Especificar los requisitos del producto de
manera cuantificable mucho antes que
comiencen las pruebas.
Establecer los objetivos de la prueba de
manera explicita.
Comprender que usuarios van a manejar el SW
y desarrollar un perfil para cada categoría de
usuario.
PRUEBA DE UNIDAD.

La prueba de unidad centra el proceso de
verificación en la menor unidad del diseño del
software(Módulo). Aquí se prueban los caminos de
control importantes, con el fin de descubrir errores
dentro del ámbito de un módulo.
¿QUÉ ERRORES SON LOS MÁS COMUNES
DURANTE LA PRUEBA DE UNIDAD :
1.
2.
3.
4.
5.
Procedencia aritmética incorrecta mal aplicada
Operaciones de modo mezcladas.
Inicializaciones incorrectas.
Falta de precisión.
Representación incorrecta de una expresión.
PRUEBA DE INTEGRACIÓN.
“Si todos funcionan bien
¿Por qué dudar de que no funcionen todos juntos?”
La prueba de Integración es una técnica sistemática
para construir la estructura del programa mientras
que al mismo tiempo, se llevan a cabo pruebas
para detectar errores asociados con la interacción.
TIPOS DE INTEGRACIÓN.
La primera es no incremental “big bang”. Se
combinan todos los módulos por anticipado, se
prueba todo el producto.
La segunda es una integración incremental en donde
se desarrollan módulos pequeños y funcionales que
hacen que los errores sean más fácil de aislar y
corregir.
LA PRUEBA DE REGRESIÓN.


Cada vez que se añade un nuevo modulo como
parte de una prueba de integración el software
cambia.
La prueba de regresión es volver a ejecutar
un subconjunto de pruebas que se han llevado a
cabo anteriormente para asegurarse de que los
cambios no han propagado efectos colaterales no
deseados.
COMENTARIOS DE LA PRUEBA
La desventaja de la integración descendente es la
necesidad de resguardos. La principal desventaja de
la integración ascendente es que el “el
programa como entidad no existe hasta que se haya
añadido el ultimo módulo”.
La selección de una estrategia de integración
depende de las características del software y, a
veces de la planificación del proyecto, en algunos de
los casos se puede usar un enfoque
combinado(denominado pruebas Sándwich).
PRUEBA DE VALIDACIÓN.
La validación puede definirse de muchas formas,
pero una simple definición es que la validación se
consigue cuando el software funciona de acuerdo
con las expectativas razonables del cliente.
CRITERIOS DE LA PRUEBA DE
VALIDACIÓN
La prueba alfa se lleva a cabo, por un cliente, en el
lugar de desarrollo. Se usa el software de forma
natural con el desarrollador como observador del
usuario y registrando los errores y los problemas de
uso. Las pruebas alfa se llevan a cabo en un entorno
controlado.
La prueba beta se lleva a cabo por los usuarios finales
del software en los lugares de trabajo de los clientes.
A diferencia de la prueba alfa, el desarrollador no está
presente normalmente. Así, la prueba beta es una
aplicación «en vivo» del software en un entorno que
no puede ser controlado por el desarrollador.
PRUEBA DE RECUPERACIÓN.
La prueba de recuperación es una prueba del sistema
que fuerza el fallo del software de muchas formas y
verifica que la recuperación se lleva a cabo
apropiadamente. Si la recuperación es automática hay
que evaluar la corrección de la inicialización, de los
mecanismos de recuperación del estado del sistema, de
la recuperación de datos y del proceso de re-arranque.
Si la recuperación requiere la intervención humana,
hay que evaluar los tiempos medios de reparación
(TMR) para determinar si están dentro de unos límites
aceptables.
PRUEBA DE SEGURIDAD.
Este acceso al sistema incluye un amplio rango de
actividades: «piratas informáticos» que intentan entrar en
los sistemas por deporte, empleados disgustados que
intentan penetrar por venganza e individuos deshonestos
que intentan penetrar para obtener ganancias personales
ilícitas.
La prueba de seguridad intenta verificar que los
mecanismos de protección incorporados en el sistema lo
protegerán, de hecho, de accesos impropios.
PRUEBA DE RESISTENCIA (STRESS)
La prueba de resistencia ejecuta un sistema de forma que
demande recursos en cantidad, frecuencia o volúmenes
anormales. Por ejemplo:
1.incrementar las frecuencias de datos de entrada en un orden
de magnitud con el fin de comprobar cómo responden las
funciones de entrada;
2.diseñar pruebas especiales que generen diez, interrupciones
por segundo, cuando las normales son una o dos;
3.ejecutar casos de prueba que requieran el máximo de memoria
o de otros recursos;
4.diseñar casos de prueba que puedan dar problemas en un
sistema operativo virtual
PRUEBA DE RENDIMIENTO.
La prueba de rendimiento está diseñada para probar el
rendimiento del software en tiempo de ejecución
dentro del contexto de un sistema integrado.
.
BIBLIOGRAFIA


Fairley R. Ingeniería de Software.
Pressman, R.S. Ingeniería del Software.
Un enfoque práctico.
Descargar

Estrategias de Prueba del SW