Las pruebas de software orientado a objetos (OO) se enfocan en probar las clases individualmente y sus interacciones, comenzando con la revisión de los modelos de análisis y diseño OO. Las pruebas unitarias ejercitan las operaciones de clase y su colaboración con otras clases, mientras que las pruebas de integración prueban subsistemas de clases colaboradoras. Finalmente, las pruebas de validación utilizan casos de uso para identificar errores en las funcionalidades visibles para el usuario.
0 calificaciones0% encontró este documento útil (0 votos)
496 vistas5 páginas
Las pruebas de software orientado a objetos (OO) se enfocan en probar las clases individualmente y sus interacciones, comenzando con la revisión de los modelos de análisis y diseño OO. Las pruebas unitarias ejercitan las operaciones de clase y su colaboración con otras clases, mientras que las pruebas de integración prueban subsistemas de clases colaboradoras. Finalmente, las pruebas de validación utilizan casos de uso para identificar errores en las funcionalidades visibles para el usuario.
Las pruebas de software orientado a objetos (OO) se enfocan en probar las clases individualmente y sus interacciones, comenzando con la revisión de los modelos de análisis y diseño OO. Las pruebas unitarias ejercitan las operaciones de clase y su colaboración con otras clases, mientras que las pruebas de integración prueban subsistemas de clases colaboradoras. Finalmente, las pruebas de validación utilizan casos de uso para identificar errores en las funcionalidades visibles para el usuario.
Las pruebas de software orientado a objetos (OO) se enfocan en probar las clases individualmente y sus interacciones, comenzando con la revisión de los modelos de análisis y diseño OO. Las pruebas unitarias ejercitan las operaciones de clase y su colaboración con otras clases, mientras que las pruebas de integración prueban subsistemas de clases colaboradoras. Finalmente, las pruebas de validación utilizan casos de uso para identificar errores en las funcionalidades visibles para el usuario.
Descargue como DOCX, PDF, TXT o lea en línea desde Scribd
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.