Patrones de Prueva de Software

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

PATRONES DE PRUEBA Freddy Laura Castaeda

Arequipa, Per

Resumen Los patrones de prueba ayudan a un equipo de software a comunicarse mejor sobre la prueba y tambin a comprender mejor las fuerzas que llevan a un enfoque especifico de prueba.

I.

INTRODUCCIN

La construccin o desarrollo de software se encuentra en constante cambio, a la vez los errores en el software son ms propensos a suceder debido a la falta de anlisis y planificacin. Existen soluciones que nos ayudaran a desarrollar software de manera optima, ahorrando tiempo, y costos; Un ejemplo de solucin son los patrones de pruebas. PATRONES DE PRUEBAS Los patrones de prueba no solo proporcionan a los ingenieros del software una directriz til cuando empiezan las actividades de prueba, sino que tambin proporcionan varios beneficios adicionales descritos por Marick: Proporciona una terminologa a los encargados de la resolucin de los problemas Concentran la atencin en las fuerzas que se encuentran detrs del problema. Eso permite a los diseadores (de casos de prueba) comprender
II.

mejor cuando se aplica una solucin, y porque. Estimulan el razonamiento iterativo. Cada solucin crea un nuevo contexto para resolver nuevos problemas. Los patrones de prueba ayudan a un equipo de software a comunicarse mejor sobre la prueba y tambin a comprender mejor las fuerzas que llevan a un enfoque especfico de prueba. Los patrones de prueba se describen de manera muy parecida a los de anlisis y diseo.
III. PATRONES DE PRUEBA

TESTIGO PAR: Este patrn est orientado a procesos. Describe una tcnica anloga a la programacin par, en la cual dos responsables de una prueba trabajan de manera conjunta para disear y ejecutar una serie de pruebas aplicables a actividades de prueba de unidad, integracin o validacin. INTERFAZ DE PRUEBA SEPARADA En sistemas orientados a objetos es necesario probar cada clase, incluidas las clases internas, es decir clases que no exponen ninguna interfaz fuera del componente que las utiliza. Este patrn describe la manera de crear una interfaz de prueba que permita describir pruebas especficas en clases que solo son visibles internamente para un componente. PRUEBA DE ESCENARIO Describe una tcnica para ejercitar el software desde el punto de vista del usuario. Una falla en este nivel

indica que el software no satisface los requisitos de un usuario visible.

Clasificacin de patrones de diseo de pruebas


I. Alcance o mbito a. mbito del mtodo Nombre Patrn: Particin por categoras Intencin: Disear una conjunto de casos de prueba basada en anlisis de entrada/salida. Nombre Patrn: Prueba de combinatoria de funciones Intencin: Disear un conjunto de pruebas para los comportamientos seleccionados por lgica combinatoria Nombre Patrn: Prueba de funcin recursiva Intencin: Disear un conjunto de pruebas para un mtodo recursivo. Nombre Patrn: Prueba de mensajes polimrficos Intencin: Disear un conjunto de pruebas para un cliente de servidor polimrfico. b. mbito del clase Nombre Patrn: Prueba sin variacin de lmite Intencin: Identificar los vectores de prueba basados en la clase que no vara. Nombre Patrn: Prueba de clase No-modal Intencin: Disear un conjunto de pruebas para una clase sin restricciones de secuencia. Nombre Patrn: Prueba de clase modal Intencin: Disear Disear un conjunto de pruebas para una clase con restricciones de secuencia. Nombre Patrn: Prueba de clase Cuasi-Modal. Intencin: Disear un conjunto de pruebas para una clase con determinado contenido de restricciones de secuencia. Nombre Patrn: Prueba de funcin recursiva Intencin: Disear un conjunto de pruebas para un mtodo recursivo. Nombre Patrn: Prueba de funcin recursiva Intencin: Disear un conjunto de pruebas para un mtodo recursivo. Nombre Patrn: Prueba de funcin recursiva Intencin: Disear un conjunto de pruebas para un mtodo recursivo. c. mbito del clase Integracin mbito de la clase

d. mbito del mtodo cacin propuesta por Robert V. Binder de patrones de diseo de pruebas [RB Integracin Explosin Orden del cdigo/prueba

mbito de la clase

pequea (Small en el mbito del Pop) mtodo/clase. Ciclo AlfaOmega Orden del cdigo/prueba en el mbito del mtodo/clase. Disear una conjunto de pruebas para comprobar la conformidad LSP 5.1 de una jerarqua de servidor polimrfico. Disear un conjunto de pruebas para una jerarqua de clases modal.

Simplificacin Prueba del mbito de servidor la clase polimrfico

Prueba modal de jerarqua. Componentes reutilizables

Desarrollar y probar la Prueba de clase implementacin de una abstracta interfaz. Desarrollar y probar la Prueba de clase implementacin de una genrica. clase parametrizada. Prueba sobre el Desarrollar y probar un nuevo demo de la aplicacin 5.2 framework para el nuevo Framework. Prueba framework general Probar los cambios ampliamente en el framework empleado. Disear una conjunto de pruebas basada en asociaciones de clase.

Subsistema

Prueba de asociacin de clase

Disear un conjunto de Prueba de pruebas para el escenario ida y comportamiento agregado vuelta. basado en estados. Prueba para controlar la excepcin Disear un conjunto de pruebas para verificar el manejo de una excepcin. Disear un conjunto de pruebas basadas en escenarios de restricciones de secuencia estimulo-respuesta.

Prueba modo mquina

Integracin

Integracin Big Intenta todo al mismo Bang (Gran tiempo. explosin)

Integracin Bottom up (enfoque de abajo hacia arriba) Integracin Top Down (enfoque de arriba hacia abajo)

Integracin por dependencias.

Integracin por control de jerarqua .

Integracin por Integracin por grupo de colaboracin escenarios. Integracin Backbone (columna vertebral) Integracin hbrida de subsistemas.

Integracin por Integracin por capas de capas la arquitectura. Integracin para la Integracin arquitectura cliente/servidor cliente/servidor. Integracin de servicios distribuidos Integracin de alta frecuencia Integracin para la arquitectura distribuida. Construir y probar en intervalos frecuentes, regulares. Desarrollar casos de uso que se puedan probar, disear un conjunto de pruebas para cubrir relaciones de la aplicacin de entradasalida. Ejecutar todas las operaciones bsicas. Asignar el esfuerzo a las prueba del sistema para maximizar la confiabilidad operacional. Volver a ejecutar todas las pruebas. Volver a ejecutar las

mbito de la aplicacin

Prueba extendida de casos de uso

Cobertura CRUD 5.3 Asignar pruebas por frecuencia Pruebas de regresin Re-probar todo Re-probar los

casos de uso de pruebas en el cdigo de riesgo riesgo. Re-probar por perfiles. Re-probar el cdigo que cambia. Re-probar dentro de un cortafuegos (firewall) Volver a ejecutar las pruebas por frecuencia de uso. Volver a ejecutar las pruebas para el cdigo que depende de cambios. Volver a ejecutar las pruebas para el cdigo que es afectado por los cambios.

En la siguiente tabla se muestra la clasificacin de patrones de diseo propuesta por Robert V. Binder para la automatizacin de las pruebas [RBS01a]: Tabla 5.2: Patrones de diseo para la automatizacin de las pruebas. Traducido de http://www.rbsc.com/pages/HarnessPatternList.htm
IV. UNA PLANTILLA PARA PATRONES DE PRUEBA DEBE TENER:

Nombre: Nombre de Patrn. Contexto en el cual se aplica: cuando aplicarlo Modelo de fallas: a que tipo de fallas ataca el patrn o Principio de Myers: un buen caso de prueba es aquel que tiene una alta probabilidad de encontrar errores o Un testing efectivo debe enfocarse en encontrar pocas fallas que se esconde en la mayor parte del cdigo bueno. o Hamlet dice: Las pruebas que no son guiadas por un modelo de fallas son menos eficientes que las pruebas hechas aleatoriamente. o Un modelo de fallas debe de explicar como un conjunto de pruebas debe encontrar las fallas y como provocarlas para que sean observadas por el inspector. Estrategia: Como el conjunto de fallas es diseado o implementado. o La estrategia debe de ser presentada a travs de ejemplos y comentada sobre los resultados obtenidos a partir de su aplicacin. Criterios de entrada: precondiciones para poder usar el patrn. Criterios de Salida: Son las condiciones que deben lograrse para que los objetos del patrn sean satisfechos.

V.

CONCLUSIN

REFERENCIAS

Ingenieria.del.Software.Roger.Pressman.6th.Ed.McGraw-Hill-Box-Libro-Ebook http://ldc.usb.ve/~teruel/southpark/DP/pruebas/documentos/capitulo9.htm http://barranquillo.ucaldas.edu.co/rgarcia/ingsoft/recursos/13-IS1pruebas_orientadas_a_objetos.pdf

También podría gustarte