Patrones de Prueva de Software
Patrones de Prueva de Software
Patrones de Prueva de Software
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
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.
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
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.
Integracin
Integracin Bottom up (enfoque de abajo hacia arriba) Integracin Top Down (enfoque de arriba hacia abajo)
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
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