par JOHANA PERDOMO Il y a 5 années
387
Plus de détails
CRUD Matrix
tener una vista general sobre el ciclo de vida de las entidades, y cómo es afectado en las distintas funcionalidades que estamos probando
Tener una vista general sobre el ciclo de vida de las entidades, y cómo es afectado en las distintas funcionalidades que estamos probando
(Crear, Leer, Actualizar, Eliminar, del inglés: create, read, update, delete).
CTWEB PARA DERIVAR PRUEBAS CON MÁQUINAS DE ESTADO
Permite diseñar los casos de prueba que cubren una máquina de estados dada,
APLICACIÓN DE LA TÉCNICA EN UN EJEMPLO
Gestión de Artículos
Los artículos pueden tener distintos estados, y el comportamiento esperado para cada acción o funcionalidad del sistema, dependerá del estado asociado al artículo.
Modelar el comportamiento de los artículos con una máquina de estados y a partir de ella derivar los casos de prueba
Estructura
-Cobertura de estados: Este criterio se satisface cuando los casos de prueba recorren todos los estados. - Cobertura de transiciones: En este caso cuando se recorren todas las transiciones. - Cobertura de pares de transiciones: Para cada estado se cubren las combinaciones de transiciones de entrada y salida.
Es un grafo dirigido cuyos nodos representan estados y cuyas aristas representan transiciones entre dichos estados.
Este tipo de técnicas es de las más usadas en el mundo del Model-based Testing (MBT),
Conocida como FSM del inglés finite state machine
Muestra las reglas de la lógica del sistema
Se listan las causas (entradas o acciones del usuario) y los efectos (salidas o acciones del sistema esperadas), y luego se unen indicando relaciones entre ellos.
Representan la relación lógica entre distintas causas y los posibles efectos.
Aplica a programas donde la lógica predominante es del tipo
la representación en Tablas de Decisión
Cada columna indicará una posible combinación entre condición y acción
Identifica los posibles valores para esas condiciones y cómo están relacionadas.
Completar con las combinaciones de datos que formarán los casos de prueba. Básicamente se listan las condiciones y acciones identificadas en una matriz.
- Si A es mayor que X entonces… - Si el cliente C tiene deuda entonces… - etc.
- Primero seleccionando los casos de uso más importantes - Para cada caso de uso, cuáles son los flujos más importantes - Para cada flujo, ver qué datos son los más importantes a utilizar
Este tipo de información generalmente está disponible en las descripciones de los diagramas de uso
Solo podremos seleccionar algunas clases de equivalencia para algunos flujos.
FLUJO DEL TC5
(donde se quiere recordar el password y para ello se debe ingresar la cuenta de e-mail registrada) solo se puede ejecutar si se selecciona una cuenta de e-mail válida, con lo cual para ese caso de prueba no consideraremos todos los valores posibles para esa variable, sino que solo los que aplican para el flujo correspondiente.
FLUJOS ALTERNATIVOS
Debería ser recorrido al menos una vez. Con esto nos garantizamos de visitar cada posible interacción del usuario con el sistema, y cada grupo de datos que hace que se vaya por un flujo u otro. Para
BUCLES
Deberíamos al menos seleccionar un caso en el que no se ejecute el bucle, uno en el que se ejecute una vez, y en algunos casos, si se considera que es oportuno, repetir el bucle varias veces. Se podrían distinguir dos tipos de bucles, los que tienen una cantidad de repeticiones definida.
diagramas UML
Muestran qué tipo de actor o usuario puede ejecutar cada caso de uso o funcionalidad
Se captura conocimiento del negocio y de cómo se desea que trabaje el sistema
Representación, en forma de grafo, para poder desde ahí visualizar más fácilmente los distintos flujos que se pueden seguir y seleccionarlos como casos de prueba.
Abstraerse de la letra, representarlo como un grafo dirigido que muestre fácilmente cuáles son los flujos del sistema.
Se comienza describiendo el flujo principal, y luego se enriquece describiendo cada uno de los posibles flujos alternativos y excepciones.
Se representan en lenguaje natural, pero generalmente se intenta seguir cierta estructura, indicando el flujo de interacción como pasos numerados.
pre-condiciones y post-condiciones
Deben cumplirse antes y luego de la ejecución del mismo respectivamente.
Vamos a ver que vamos a tener que tomar muchas decisiones, plantear algunas alternativas, o algunas cosas que podríamos tener que considerar.
Saber el antes y el después
AD-HOC TESTING
sin seguir un orden determinado
QUIERO PROBAR UNA FUNCIONALIDAD ESPECIFICA
Probar una funcionalidad especifica
5. La efectividad del testing se apoya en el conocimiento, habilidades y experiencia del tester
4. Es un acercamiento a las actividades de testing que consisten en una serie de actividades que se realizan en simultáneo, tales como el aprendizaje del sistema, diseño y ejecución de las pruebas.
3. Su foco está en encontrar problemas y defectos por medio de la exploración del sistema bajo prueba.
2. Los resultados obtenidos durante pruebas anteriores guiarán las acciones, los pasos y los siguientes escenarios de prueba a ejecutar, construyendo así un conjunto de pruebas más eficaz
Herramientas que los ayudaban en su actividad
- Brújula, para indicar en qué dirección iban; - Catalejo, para enfocar a lo lejos y “acercar” los lugares; - Compás, que permitía medir y ubicar más precisamente los sitios explorados.
Tomar notas de lo que se va descubriendo ya sea en forma esquemática o en forma tabulada
tiempo, objetivos y reportes.
1. Proporcionar información y resultados de forma rápida; 2. Para obtener nueva información y conocimiento a lo largo de nuestro trabajo de testing; 3. Revelar nuevos tipos de defectos y problemas; 4. Mejorar las habilidades del tester y equipo de testing en general, además del conocimiento sobre la lógica del negocio; 5. Por último, notamos que el modo de registrar y guardar información en las sesiones, es una tarea muy importante, tanto para el tester, equipo de testing, como para el resto de los actores que forman parte del equipo.
NOMENCLATURA
Crear casos de prueba temporales, los cuales se los puede nombrar con un prefijo común como pru o tmp
Definir una estructura de carpetas que permita separar los casos de prueba generales
Utilizar nombres para los casos de prueba de forma tal que sea fácil distinguir
Definir y dejar clara la organización y nomenclatura a utilizar, que a futuro nos permita manejar lo más simple posible el enorme set de pruebas que vamos a tener
Criticidad: podríamos definir un grupo de pruebas que se debe ejecutar siempre (en cada build), ya que son las más críticas, otro de nivel medio, que lo ejecutamos con menos frecuencia (o tal vez que se seleccionan solo si hay cambios en determinadas funcionalidades), y uno de poca criticidad, que ejecutaríamos opcionalmente si
Módulo o Funcionalidad: agrupando todos los casos de prueba que actúan sobre una misma funcionalidad.
Definido en dos niveles de abstracción
Casos de prueba con datos
Se instancian los casos de prueba abstractos con valores concretos
Casos de prueba abstractos o conceptuales,
Son guiones de prueba, que al indicar que se utilizarán datos no hacen referencia a valores concretos, sino a clases de equivalencia, o a grupos de valores válidos
Se comienza por el inventario de funcionalidades asignaríamos prioridades a cada caso de prueba que tenemos preparado para cada una de las distintas funcionalidades.
- Importancia o criticidad para la operativa del negocio. -Costo del impacto de errores. - Probabilidad de que hayan fallos (esto hay que preguntárselo a los desarrolladores, que seguramente sabrán que determinado módulo lo tuvieron que entregar en menor tiempo del que necesitaban, entonces ellos mismos dudan de la estabilidad o calidad del mismo). -Acuerdos de nivel de servicio (SLA). - Dinero o vidas en juego (suena dramático, pero sabemos que hay muchos sistemas que manejan muchas cosas muy sensibles).
Nos basamos en algo llamado “testing basado en riesgos”
1. Testing consistente y repetible, asegurando que se ejecutan siempre exactamente las mismas acciones, con los mismos datos, y verificando cada una de las cosas que siempre hay que verificar, tanto a nivel de interfaz como a nivel de base de datos. 2. Correr casos de prueba desatendidos. 3. Encontrar errores de regresión, a menor costo y en forma más temprana. 4. Correr casos de prueba más seguidos (después de cada commit al repositorio de código por ejemplo). 5. Mejorar la calidad del software (más testing, más oportunidades de mejora), y así incrementar la confianza de los usuarios. 6. Medir performance. 7. Testear en diferentes sistemas operativos, navegadores, configuraciones, gestores de bases de datos, etc., sin duplicar el costo de ejecución. 8. Disminuir el tiempo de salida al mercado/correr las pruebas más rápido. 9. Mejorar la moral en los testers, haciendo que las tareas rutinarias sean ejecutadas en forma automática.
La herramienta sea capaz de capturar las acciones del usuario (record) sobre el sistema que estamos probando.
Luego a un script que sea reproducible (playback).
Lenguajes pueden ser específicos, conocer el lenguaje o API de la herramienta, los distintos elementos con los que interactuamos del sistema bajo pruebas, los botones en una página web, los métodos de la lógica que queremos ejecutar, o los parámetros a enviar en un pedido GET de un sistema web
al automatizar pruebas logramos
obtener un rápido feedback
sobre el estado de calidad del sistema
Al ejecutar las pruebas automatizadas más rápido
permite detectar antes los errores introducidos sobre funcionalidades ya existentes del sistema
(a mediano y largo plazo
reducir el tiempo insumido en las pruebas de una determinada funcionalidad, con lo cual podremos disminuir el tiempo de salida al mercado.
se analiza el servidor
CALCULAR VALORES ESPERADOS
Esta es la única forma de determinar si la aplicación funciona como es esperado o no.
Estamos incluyendo a lo que el sistema muestra en pantalla, archivos que se tengan que modificar, estados de la base de datos, o cualquier otro tipo de acción que deba realizar el software que estamos probando.
Testing Negativo
Incluir escenarios con aquellas cosas que el sistema debe estar preparado para no hacer, o no fallar por tratarse de una situación incorrecta.
COMBINACIÓN DE VALORES
Busca obtener el conjunto de datos más eficiente posible (eficiente = encontrar la mayor cantidad de errores con la menor cantidad de ejecuciones).
Permiten seleccionar una cantidad acotada de datos de prueba, siguiendo teorías de errores que indican cómo combinar los datos para aumentar esa probabilidad de encontrar errores
NO ENMASCARAMIENTO DE ERRORES
En los conjuntos de datos de prueba se utilizará solo un valor de una clase inválida a la vez, pues si se utilizan dos se corre el peligro de no identificar qué valor inválido produce el error.
COMBINACIÓN POR PARES
Una de las técnicas de combinación de datos más usada es all-pairs, o sea todos los pares, y justamente lo que se hace es intentar utilizar todos los pares posibles.
PROW (pairwise with restrictions, order and weight).
Utilizando este algoritmo podemos excluir pares que nos resulten inválidos, e incluso darle distintas prioridades a los distintos pares, pues siempre será necesario repetir algunos pares para lograr todas las combinaciones,
SELECCIONAR VALORES INTERESANTES
Ya identificadas las variables, para cada una hay que seleccionar los valores que se le asignarán en las pruebas.
Un grupo de valores pertenece a una misma clase de equivalencias si deben producir un comportamiento similar en el sistema.
Distinguir opciones significativamente diferentes cuando:
-Disparan distinto flujo sobre el sistema (al ingresar un valor inválido me lleva a otra pantalla distinta). - Dispara un mensaje de error diferente (no es lo mismo ingresar un password corto que uno vacío). -Cambia la apariencia de la interfaz del usuario, o el contenido del form (al seleccionar pago con tarjeta de crédito aparecen los campos para ingresar el número de tarjeta, titular y fecha de expiración, pero si se selecciona pago por transferencia entonces aparecen los campos para ingresar información de la cuenta bancaria). -Cambian las opciones disponibles para otras variables (al seleccionar un país distinto se pueden seleccionar sus estados o provincias). 34 Introducción a las Pruebas Funcionales - Si dispara distintas condiciones para una regla de negocio (si se ingresa una edad será distinto el comportamiento si es menor o mayor de edad). - Valores por defecto o cambiados (en ocasiones el sistema sugiere datos que se habían ingresado previamente para un cliente, como por ejemplo su dirección, pero si se cambian en el formulario de entrada entonces el sistema actualizará ese dato). -Cambios de comportamiento por distintas configuraciones o distintos países (formato de números, formatos de fecha, moneda, etc.). - ¿Qué más se les ocurre? Seguro que hay más, estos fueron ejemplos para mostrar cómo analizar los casos significativamente diferentes.
Para cada variable utilizar distintos datos
IDENTIFICAR VARIABLES
Se identifican las variables que están en juego en la funcionalidad
Para cada variable se diseñan valores interesantes
Las variables, de cualquier entrada que al cambiar su valor hace que cambie el comportamiento o resultado del sistema bajo pruebas.
conformar las variables de una funcionalidad
-Entradas del usuario por pantalla. - Parámetros del sistema (en archivos de configuración, parámetros de invocación del programa, tablas de parámetros, etc.). - Estado de la base de datos (existencia –o no– de registros con determinados valores o propiedades).
FLUJO
Se almacenan los datos de entrada y salida esperados.
Definiendo con casos de prueba abstractos
Casos de prueba específicos
Data-driven testing
Casos de prueba abstracto y específico
Al momento de ser ejecutados con un juego específico de datos,
Serie de pasos para ejecutar el caso de prueba
Permite agregar nuevos casos de prueba fácilmente, ingresando simplemente nuevos datos de entrada y de salida esperados, que sirvan para ejecutar el mismo flujo.
ESPECIFICO
Se determinan valores específicos para cada variable de entrada.
Si utilizamos información interna del sistema que estamos probando, tal como el código, esquema de base de datos, etc.,
CAJA GRIS
Combinación de caja blanca y caja negra
CAJA NEGRA
Observación de entradas y salidas del sistema
Subtema
Deberá comparar el valor esperado contra valor obtenido, el estado final esperado con el estado final alcanzado, el tiempo de respuesta aceptable con el tiempo de respuesta obtenido, etc.
Flujo: secuencia de pasos a ejecutar Datos entrada Estado inicial Valor de respuesta esperado Estado final esperado
Lo más importante el flujo, o sea la serie de pasos a ejecutar sobre el sistema, los datos de entrada, ya sean entradas proporcionadas por el usuario al momento de ejecutar, o el propio estado de la aplicación, y por último las salidas esperadas, el oráculo, lo que define si el resultado fue positivo o negativo.
“Una idea de prueba es una breve declaración de algo que debería ser probado. Por ejemplo, si se está probando la función de la raíz cuadrada, una idea de prueba sería el ‘probar un número que sea menor que cero’. La idea es chequear si el código maneja un caso de error.”
Se pide a la gente que construyó el software que lo pruebe.
Si dejamos para el final nos costará mucho más, más tiempo, más horas, y más costo de reparación, pues si encontramos un problema en la arquitectura del sistema cuando este ya se implementó, entonces los cambios serán más costosos de implementar.
El testing es algo que queda para el final
El objetivo no tiene por qué ser el mismo a lo largo del tiempo, pero sí es importante que se tenga claro en cada momento cuál es.
Si no encontramos fallos entonces tenemos más confianza en que los usuarios encontrarán menos problemas.
Es un proceso diseñado para asegurar que el código hace lo que se supone que debe hacer y no hace lo que se supone que no debe.
Un proceso en el que se ejecuta un programa con el objetivo de encontrar errores.
Se define, o se calcula, o se le asigna un valor, en base a un conjunto de propiedades (seguridad, performance, usabilidad, etc.),
