- Escribir casos de prueba a partir de modelos de software dados aplicando partición de equivalencia, análsiis de valores límites , tablas de decisión y diagramas / tablas de transición de estado (K3).
- Explicar el objeto principal de cada una de las cuatro técnicas de pruebas, así como qué nivel y que tipo de pruebas podría utilizar la técnica y cómo puede medirse la cobertura (K2).
- Explicar el concepto de las pruebas de caso de uso y sus ventajas (K2).
Partición de equivalencia (K3).
En el caso de la partición de equivalencia, los valores de entrada del software o del sistema se dividen en grupos que se espera demuestren un comportamiento similar, de manera que puedan ser procesados de la misma forma.
Las particiones de equivalencia (o clases) son aplicables a datos válidos, o valores que deben aceptarse, y datos no válidos, o valores que deben rechazarse.
Las particiones también pueden aplicarse a los valores de salida, valores internos, valores relativos al tiempo (por ejemplo, antes o después de un evento) o a los parámetros de interfaz (por ejemplo, componentes integrados probados durante las pruebas de integración). Pueden diseñarse pruebas que cubran todas las particiones no válidas.
La partición de equivalencia es aplicable a todos los niveles de pruebas.
Análisis de valores límite (K3).
El comportamiento en el límite de cada partición de equivalencia tiene más posibilidades de ser incorrecto que el comportamiento dentro de la partición, por lo tanto los límites constituyen un área en el que las pruebas tenderán a incluir defectos.
Los valores máximos y mínimos de una partición son sus límite.
El valor límite de una partición válida constituye un valor límite válido, mientras que los límites de una partición no válida constituyen valores límites no válidos.
Las pruebas pueden diseñarse para cubrir valores límite tanto válidos como no válidos. Al diseñar casos se selecciona una prueba por cada valor límite.
El análisis de valores límite puede aplicarse a todos los niveles de prueba. Es relativamente fácil de aplicar y su capacidad para detectar defectos es alta. Las especificaciones detalladas son útiles a la hora de establecer los límites interesantes.
Esta técnica a menudo se considera como una extensión de la partición de equivalencia u otras técnicas de diseño de pruebas de caja negra. Puede utilizarse en clases de equivalencia para los valores que los usuarios introducen en pantalla y , por ejemplo, en rangos de tiempo (tales como tiempo agotado o requisitos de velocidad de transacciones) o rangos de tabla (por ejemplo , el tamaño de la tabla es 256 * 256).
Pruebas de Tabla de decisión (K3).
Las tablas de decisión constituyen una buena manera de reflejar los requisitos del sistema que contienen condiciones lógicas, y de documentar el diseño del sistema interno.
Pueden utilizarse para registrar normas comerciales complejas que el sistema debe aplicar.
Al crear las tablas de decisión, se analiza la especificación y se identifican las condiciones y acciones del sistema. Por lo general las condiciones y acciones de entrada se sentencias de manera que deben ser verdaderas o falsas (Booleano).
La tabla de decisión incluye las condiciones de activación, a menudo combinaciones de verdadero y falso para todas las condiciones de entrada, y las acciones resultantes para cada combinación de condiciones.
cada columna de la tabla corresponde a una regla comercial que define una combinación única de condiciones y que resulta en la ejecución de aquellas acciones asociadas a dicha regla.
El estándar de cobertura que generalmente se utiliza en las tablas de decisión es disponer al menos de una prueba pro columna en la tabla, lo que generalmente implica cubrir todas las combinaciones de condiciones de activación.
La ventaja de la tabla de decisión es que crea combinaciones de condiciones que de otros modo no se habría practicado durante las pruebas. Puede aplicarse a todas las situaciones en aquellos casos en que la acción del software depende de varias decisiones lógicas.
Pruebas de transición de estado (K3).
Un sistema puede mostrar respuestas diferentes en función de sus condiciones actuales o su historial previo (su estado). En esta caso , ese aspecto del sistema puede mostrarse con un diagrama de transición de estado. Esto permite al probador ver el siftware en términos de sus estados, transiciones entre estados, entradas o eventos que activan los cambios de estado (transiciones) y acciones que pueden derivarse de dichas transiciones. Los estados del sistema u objeto de la prueba son independientes, identificables y finitos en número.
Una tabla de estado muestra la relación entre los estados y entradas, y eventualmente puede poner de manifiesto posibles transiciones no válidas.
Pueden diseñarse pruebas para cubrir una secuencia típica de estados, cubrir todos los estadps, ejercitar todas las transiciones , ejercitar secuencias de transiciones o probar transiciones inválidas.
Pruebas de caso de uso (K2).
Las pruebas pueden derivarse de casos de uso. Un caso de uso describe las interacciones entre los actores, incluyendo usuarios y el sistema , para producir un resultado de valor para un usuario de sistema o para el el cliente.
Los casos de uso pueden describirse tanto a nivel abstracto (caso de uso comercial, sin tecnología, nivel de proceso empresarial) como a nivel de sistema (caso de uso de sistema a nivel de funcionalidades del sistema).
Cada caso de uso tiene precondiciones que deben cumplirse para que el caso de uso funcione correctamente.
Cada caso de uso termina con postcondiciones, que son los resultados observables y el estado final del sistema una vez finalizado el caso de uso.
Generalmente, un caso de uso tiene un escenario principal (o más probable) y caminos alternativos.
Los casos de uso describen los "flujos de proceso" mediante un sistema basado en su uso probable real, de manera que los casos de prueba derivados de los casos de uso resultan muy útiles a la hora de descubrir defectos en los flujos de proceso durante el uso real del sistema. Los casos de usp son de gran utilidad para diseñae las pruebas de aceptación con la participación del cliente/usuario. Así mismo , ayudan a descubrir eventuales defectos de integración , provocados por la interacción y la interferencia de distintos componentes, que las pruebas de componente a nivel individual no pueden detectar. El diseño de los casos de uso a partir de casos de uso, puede combinarse con otras técnicas de pruebas basadas en la especificación.
Resumiendo:
- Técnica Caja negra ("black box"):
- El probador observa el objeto de prueba como una caja negra.
- La estructura interna del objeto de prueba es irrelevante o desconocida.
- Los casos de prueba se obtienen a partir del análisis de la especificación (funcional y no funcional) de un componente o sistema.
- Prueba del comportamiento entrada / salida/ ("input/output").
- La funcionalidad es el foco de atención.
- La técnica de caja negra también se denomina prueba funcional de prueba orientada a especificación.
En general podemos decir:
- Las pruebas funcionales están dirigidas a verificar la corrección y la completitud de una función.
¿Las funciones ejecutadas presentan resultados correctos?
- La ejecución de casos de prueba deberían ser ejecutados con una baja redundancia pero, sin embargo con carácter integral y completo.
- Probar tanto como sea necesario.
No hay comentarios:
Publicar un comentario