18-04-2018

implantacion de sistemas

unidad V

prubas de software

fundamentos
visio interna y extrema
prubas de caja blanca
pruebas de ruta basica
prueba de la estructura de control
pruebas de caja negra
prueba basada en modelo
patrones para pruebas de software

ing de sistemas
telematica
informatica
computacion

fundamentos de la pruba de software

la meta de probar es encontrar error y una pruba es aquella que tiene una alta
probabilidad de encontrar uno (1)
Por lo tanto un sistema basado en computadora un producto debe dise�arse o
comprobarse la comprobabilidad
al mismo tiempo las prubas en si misma de mostrar un producto de caracteriscas que
logre
la meta de ecnontrar la mayor cantidad de errores con el minimo esfuerso

comprobabilidad
cooperatibidad
observabilidad
controlabilidad
descompobinilidad
simplisidad
estabilidad
compresavilidad

caracteristicas de la pruba
una buena pruba tiene una alta probabilidad de encontrar un error
para encontrar esta meta el examindor debe comprender el software e intentar
desarrollar una imagen mental de mcomo pueda fallar
una imagen mental de como puede fallar
de manera ideal se prueban las clases de fallas por ejemplo

una clase fallas potenciales en una intefas graficas de usuario potencial es la

fala para reconocer la posicion adecuada del raton
se dise�a entonces un conjunto de prubas para revisar el raton con la intencion de
demostrar un error en el reconocimiento de la posicion del raton

una buea pruba no es redundante. el tiempo y los recursos de la pruba son

limitados. no se trata de realizar una pruba que tenga el msmo proposito que otra
cada una debe tener un proposito diferente incluso si es sutilmente diferente una
buena pruba debe ser la mejor de la camanda. en un grupo de prubas que tenga una
intencion simlar
la simulaciones de timepo y recursos pueden mitigar la ejecucion de solo un
subconjunto de dichas prubas. en tales casos debe usarse la pruba que tenga la
mayor probabilidad
de descubir toda clase de errores.

una buena pruba no debe ser demasiado simpre o demasiado compleja. aunque en
ocasiones es posible combinar una serie de prubas en un caso de pruba, los efectos
colaterales posibles
asociados con este enfoque puedan enmascarar errores en general cada pruba debe
ejcutarse por separado

visiones iternas y externas de la prubas

cualquier proiducto sometido a ing puede probarce en una de o dos formas: al
conocer la funcion espesifica que asigno a un producto para su realizacion,
puden llevarse acabo prubas que demuestren que cada funcion es completamente
operativa mientras que al mismo tiempo se buscan erroes en cada funcion, dos al
conocer el funcionamiento interno
de un producto, pueden realizarse prubas para garantizar que todos los engranes
embonan; es decir que las operaciones internas se realizan deacuerdo con las
especificaciones y que todos los componestes internos
se revisaran de manera adecuada. el primer enfoque de prubas considera una vision
externa y sellma pruba de caja negra.
el segundo requiere una vision interna y se denomina pruba de caja blanca.

la pruba de caja de negra se refiere a las prubas que se llevan a cabo en la

interfaz de software una pruba de caja negra examina algunos aspectos fundamentales
de un sistema con poca preocupacion por la estructura interna logica del software.
la pruba de caja blanca se basa en el examen cercano de los detalles de
procedimientos. las
rutas logicas atra vez del software y las colaboraciones entre componesntes se
ponen a prueba al revisar conjuntos espesificas o bucles
a primera vista parecia que las prubas de caja blanca muy extensas conducirian a
programas 100% correctos lo unico que se necesita es definir todas las rutas
logicas, desarrolar casos de prubas desarrolar casos de pruybas para evaluar y
resultados, es decir, generar casos de pruba para revisar de manera exautiva la
logica del programa.
por desgracia las prubas exautivas presenta ciertos problemas logisticos hasta para
programas peque�os el numero de posibles rutas logicas puede ser muy grande. sin
embargo las prubas de caja blanca no deben descartarse como impracticas pueden
selecionar y revisarse importantes
puede probarse la validez de estructuras de datos importantes

prubas de caja blancas en ocaciones llamadas prubas de vidrio, es una filosofia de

cosos de pruebas que usa la estructura de control descrito como parte del dise�o a
nivel de componentes para derivar casos de prubas al usar los metodos de pruba de
caja blanca puede derivar 1 garantiza que todas las rutas independientes dentro de
un modulo se revisaran al menos una vez,
dos revisen todas las desiciones logicas en su lados verdadero y falso, 3 ejecuten
todos los bucles en su fontreas y dentro de fontreras operativas 4 revisen
estructuras de datos internas para garantizar su validez
pruba de ruta basica: es u8na tecnica de prueba de caja blanca propuesta por
primera vez por tom McCabe. El metodo de ruta basica permite al dise�ador de casos
de prueba derivar una medida de complejidad logica de un dise�o de procedimientos y
usar esta medida como guia para definir un conjunto basico de rutas de ejecuciones.
Los casos de prueba derivados para revisar el conjunto basico tiene garantia para
ejecutar todo enunciado en el programa, al menos una vez durante la prueba.

prueba de la estructura de control: La tecnica de prueba de ruta basica es una de

varias tecnicas para probar la estructura de control. Aunque la prueba de ruta
basica es simple y enormemente efectiva, no es suficiente en si misma. Esta prueba
mas amplica cubre y mejora la calidad de la prueba de caja blanca.
investigar: prueba de condicion, prueba de flujo de datos, prueba de bucle.
prueba de caja negra: las pruebas de caja negra, tambien llamadas pruebas de
comportamiento, se enfocan en los requerimientos funcionales del software, es
decir, las tecnicas de pruebas de caja negra le permiten derivar conjuntos de
condiciones de entradas que reavisaran por completo todos los requerimientos
funcionales de un programa. Las pruebas de caja negra no son una alternativa paras
las tecnicas de caja blanca. En vez de ello, es un enfoque complementario que es
probable que descubra una clase de errores diferentesque los metodos de caja
blanca.

las pruebas de caja negra intentan encontrar errores en las categorias siguientes:
1) funciones incorrectas o faltantes.
2) errores de interfaz.
3) errores e las estructuras de datos o en el acceso a bases de datos externas.
4) errores de comportamiento o rendimiento.
5) errores de inicializacion y terminacion.

A diferencia de las pruebas de caja blanca, que se realizan tempranamente en el

proceso de pruebas, la prueba de caja negra tiende a aplicarse durante las ultimas
etapas de la prueba. Puesto que, a proposito, la prueba de caja negra no considera
la estructura de control, la atencion se enfoca en el dominio de la informacion.
Las pruebas se dise�an para responde a las siguientes preguntas:

�C�mo se prueba la validez funcional?

�C�mo se prueba el comportamiento y el rendimiento del sistema?
�Qu� clases de entrada har� buenos casos de prueba?
�El sistema es particularmente sensible a ciertos valores de entrada?
�C�mo se aislan las froteras de una clase de datos?
�Qu� tasas y volumen de datos pueden tolerar el sistema?
�Qu� efectos tendran sobre la operacion del sistema algunas combinaciones
especificas de datos?

Al aplicar las tecnicas de caja negra, se deriva un conjunto de casos de prueba que
satisfacen los siguientes criterios:

1) casos de prueba que reducen, por una cuenta que es mayor que uno, el numero de
casos de pruebas adicionales que deben dise�arse para lograr pruebas razonables.
2) casos de prueba que dicen algo acerca de la presencia o ausencia de clases de
errores, en lugar de un error asociado solamente con la prueba especifica a mano.

investigar: metodos de prueba basados en graficos (modelado de flujo de

transaccion, de estado initos, de flujo datos, de temporizacion), particion de
equivalencia, analisis de valor de fronteras, pruebas de arreglo ortogonal.

pruebas basados en modelo: La prueba basada en modelo es una tecnica de prueba de

caja negra que usa la informacion contenida en el modelo de requerimientos como la
base para la generacion de casos de prueba. En muchos casos, la tecnica de pruebas
basada en modelos usa diagramas de estado (UML), un elemento del modelo de
comportamiento, como la base para el dise�o de casos de prueba. La tecnica PBM
requiere 5 pasos:

1) analizar un modelo de comportamiento existente para el software o crear uno.

2) recorrer el modelo de cmportamiento y especificar las entradas que forzaran al
software a realizar la transicion de estado a estado.
3) revisar el modelo de comportamiento y observar las salidas esperadas, conforme
al software realiza la transicion de estado a estado.
4) ejecutar los casos de prueba.
5) comparar los resultados reales y esperados y adoptar una accion correctiva segun
se requiera.
Prueba para entornos, arquitectura y aplicaciones especializadas:

En ocasiones los lineamientos y enfoques unicos para pruebas se garantizan cuando

se consideran entorAunque otras tecnicas de pruebas con frecuencia pueden adaptarse
a situaciones especialziadas, vale la pena considerar individualmente sus
necesidades unicas.

investigar:
1) pruebas de interfaces graficas de usuario.
2) pruebas de arquitectura cleinte/servidor (pruebas de funcion de aplicacion,
prueba de servidor, pruebas de base de datos, pruebas de transaccion, pruebas de
comunicacion de red).
3) documentacion de prueba y centros de ayuda.
4) pruebas para sistemas de tiempo real (pruebas de tareas, prueba de
comportamiento, prueba de intertarea, pruebas de sistemas).

patrones para pruebas de software:

Los patrones de prueba describen problemas y soluciones de pruebas comunes que

puedan auxiliar en su tratamiento.
Los patrones de prueba no solo proporcionan lineamientos utilies conforme comienzan
las actividades de pruebas; tambien proporcionan 3 beneficios adicionales descritos
por Marick.
1) proporcionan un vocabulario para los que solucionan problemas.
2) enfocan la tension en las fuerzas que hay detras de un problema. Esto permite
que los dise�adores de caso de prueba entienda mejor cuando y por que se aplica una
solucion.
3) alientan el pensamiento iterativo. Cada solucion crea un nuevo contexto en el
que pueden resolverse nuevos problemas.

Aunque estos beneficios son leves no deben pasarse por alto.Gran parteb de las
pruebas del software incluso durante la decada pasada han sido actividades Ad Hoc.
Si los patrones de prueba pueden ayudar a un equipo de software a comunicarse de
manera mas efectiva acerca de las pruebas, a comprender las fuerzas de motivacion
que conducen a un enfoque especifico para las pruebas y a abordar el dise�o de las
pruebas como una actividad evolutiva en la que cada iteracion resulta en una suit
mas completa de casos de prueba, entonces losm patrones logran muchos.

Los patrones de prueba se describen en forma muy similar a los patrones de dise�o.
En la literatura se ha propuesto decenas de patrones de prueba. Los siguientes 3
proporcionan ejemplos representativos:

1) Pairtesting: patron orientado a procesos, describe la tecnica que es analoga a

la programacion porpareja en la que 2 examinadores trabajan en conjunto para
dise�ar y ejecutar una serie de pruebas que puedan aplicarse a actividades de
pruebas de unidad, integracion o validacion.
2) Separate test interface: Hay necesidad de probar cada clase en un sistema
orientado a objetos incluidas clases internas. El patron separate test interface
describe como crear una iterfaz de prueba que pueda usarse para describir pruebas
especificas sobre clases que son visibles solamente de manera interna en un
componente.
3) Scenario testing: Una vez realizada las pruebas de unidades e integracion, hay
necesida de determinar si el software se desempe�ara en forma que satisfaga a los
usuarios. El patron describe una tecnica para revisar el software desde el punto de
vista del usuario. Un fallo en este nivel indica que el software fracaso para
satisfacer un requisito visble para el usuario.