Métodos de Pruebas Orientado A Objetos

Descargar como docx, pdf o txt
Descargar como docx, pdf o txt
Está en la página 1de 5

MTODOS DE PRUEBAS ORIENTADO A OBJETOS

El objetivo de las pruebas, dicho de manera simple, es encontrar la mayor


cantidad posible de errores con una cantidad manejable de esfuerzo aplicado
durante un lapso realista. Aunque este objetivo fundamental permanece
invariable para el software orientado a objetos (OO), la naturaleza de los
programas OO cambia en la estrategia y en las tcticas de las pruebas. Podra
argumentarse que, conforme las bibliotecas de clase reutilizables crecen en
tamao, un reso mayor mitigar a los sistemas OO en su necesidad de
pruebas pesadas. Lo opuesto es exactamente cierto.
Para probar adecuadamente los sistemas OO, deben realizarse tres cosas:
1) Ampliar la definicin de prueba para incluir las tcnicas de descubrimiento
de error aplicadas al anlisis orientado a objetos y a modelos de diseo.
2) Cambiar significativamente la estrategia para prueba de unidad e
integracin.
3) Explicar las caractersticas nicas del software OO mediante el diseo de
casos de prueba.

Prueba de validacin en el software Orientado a Objetos:


La arquitectura del software orientado a objetos (OO) da como resultado una
serie de subsistemas en capas que encapsulan clases colaboradoras. Cada uno
de estos elementos de sistema (subsistemas y clases) realiza funciones que
ayudan a lograr los requerimientos del sistema. Es necesario probar un sistema
OO en varios niveles diferentes con la intencin de descubrir errores que
puedan ocurrir conforme las clases colaboran unas con otras y conforme los
subsistemas se comunican a travs de capas arquitectnicas
La validacin en el software OO se enfoca en las acciones visibles para el
usuario y en las salidas del sistema reconocibles por l mismo. Para auxiliar se
deben de recurrir a casos de uso.
Cada caso de prueba debe identificarse de manera nica y explcita.
Otros requisitos:

Establecer el propsito de la prueba.


Desarrollar una lista de pasos de prueba.
Una lista de estados especificados.
Una lista de mensajes y operaciones que se ejercitarn con la prueba.
Una lista de excepciones que pueden ocurrir.
Una lista de condiciones externas.
Informacin complementaria.
Diseo de pruebas basadas en escenario

Contempla errores de:


Especificaciones incorrectas
Interacciones entre subsistemas
jemplo,
Considere una clase en la que se define un nmero de atributos durante la
primera iteracin de anlisis. Un atributo extrao se anexa a la clase (debido a
una mala interpretacin del dominio del problema). Entonces pueden
especificarse dos operaciones para manipular el atributo. Se lleva a cabo una
revisin y un experto en el dominio puntualiza el problema.

Cules son los pasos?


Las pruebas OO son estratgicamente anlogas a la prueba de sistemas
convencionales, pero tcticamente diferentes. Puesto que el anlisis OO y los
modelos de diseo son similares en estructura y contenido con el programa OO
resultante, las pruebas se inician con la revisin de dichos modelos. Una vez
generado el cdigo, la prueba OO comienza en lo pequeo, con las pruebas
de clase. Se disea una serie de pruebas que ejercitan las operaciones de clase
y que examinan si existen errores conforme una clase colabora con otras
clases. En la medida en la que las clases se integran para formar un
subsistema, se aplican pruebas basadas en hebra, en uso y de grupo, junto con
enfoques basados en fallo, a fin de ejercitar por completo clases colaboradoras.
Finalmente, se usan casos de uso (desarrollados como parte del modelo de
requerimientos) para descubrir errores de validacin del software

APLICACIN DE MTODOS CONVENCIONALES DE DISEO DE CASOS DE


PRUEBA

Los mtodos de prueba de caja blanca pueden aplicarse a las operaciones


definidas para una clase. Las tcnicas de ruta bsica, prueba de bucle o flujo
de datos pueden ayudar a garantizar que se probaron todos los enunciados en
una operacin. Sin embargo, la estructura concisa de muchas operaciones de
clase hace que algunos argumenten que el esfuerzo aplicado a la prueba de
caja blanca puede redirigirse mejor para probar en un nivel de clase.
Los mtodos de prueba de caja negra son tan apropiados para los sistemas
Orientado a Objetos como para los sistemas desarrollados, usando mtodos de
ingeniera del software convencional. Los casos de uso pueden proporcionar
entrada til en el diseo de las pruebas de caja negra y en las basadas en
estado.

PRUEBAS BASADAS EN FALLAS

Las pruebas basadas en fallo pierden dos tipos principales de errores:


1) Especificaciones incorrectas
2) Interacciones entre subsistemas.
Cuando ocurren errores asociados con una especificacin incorrecta, el
producto no hace lo que el cliente quiere. Puede hacer lo correcto u omitir
funcionalidad importante. Pero en cualquier circunstancia, la calidad
(conformidad con los requerimientos) se resiente. Los errores asociados con la
interaccin de subsistemas ocurren cuando el comportamiento de un
subsistema crea circunstancias (por ejemplo, eventos, flujo de datos) que
hacen que otro subsistema falle.
Esto requiere disear casos de prueba que revisen el diseo o el cdigo.
Pueden encontrarse 3 tipos de fallas: resultado inesperado, operacin
incorrecta e invocacin incorrecta.
Pruebas
basadas en fallas, diseo de pruebas que tengan una alta
probabilidad de descubrir fallas aqu podemos encontrar dos tipos principales
de errores:
Especificaciones incorrectas.
Interaccin entre subsistemas.

CONCLUSIN

Como se ha visto, el objetivo de las pruebas OO sigue siendo el mismo que el


de las pruebas convencionales. Pero en este caso lo que cambia es la
estrategia a travs de la cual se llega a ese objetivo. El entorno OO el foco de
las pruebas ya no es de los mdulos sino que ahora son de las clases.
Las pruebas comienzan cuando se realiza el modelado, luego continan con
pruebas de unidad para cada clase (como son las pruebas basadas en fallo,
prueba aleatoria y prueba de particin).se realizan despus las pruebas de
integracin (basada en hebra o en uso) y, por ltimo se realizan pruebas de
validacin, para las cuales se pueden realizar los mtodos convencionales de
caja negra.

También podría gustarte

pFad - Phonifier reborn

Pfad - The Proxy pFad of © 2024 Garber Painting. All rights reserved.

Note: This service is not intended for secure transactions such as banking, social media, email, or purchasing. Use at your own risk. We assume no liability whatsoever for broken pages.


Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy