Tecnicas de Diseño de Casos de Prueba. Logo@Copyright www.bstriker.com 1
Objetivos 1. Compartir conocimiento adquirido en distintos proyectos con la comunidad de Testing. 2. Generar un espacio donde se generen nuevas relaciones entre los participantes. (Francisco) 3. Proveer herramientas de desarrollo profesional para los referentes de la comunidad. 4. Facilitar teoría y fuentes de información académica. www.bstriker.com
Historia del Testing Antes de 1956. Periodo orientado a debugging. En el 49 A.M. Touring es el precursor (Checking a large routine). Entre 1957 y 1978. Periodo orientado a demostración. Entre 1979 y 1982. Periodo orientado a destrucción. Myers - The Art of Software Testing. Entre 1983 y 1984. Periodo orientado a evaluación. (V,V&T). Entre 1985 y la actualidad. Periodo orientado a prevención. STEP (Systematic Test and Evaluation Process) www.bstriker.com
Por qué? Modelo de trabajo incorrecto. (Ágiles o Estructurados) Los objetivos del Testing no son claros. Se realiza más Testing basado en la experiencia de los testers. Testers sin formación o habilidad. No se cuenta con información relevante a las pruebas. No hay criterios claros de comienzo o fin de Prueba. Testing como cuello de botella. La infraestructura de Testing no se condice con la del ambiente productivo. Herramientas obsoletas o demasiadas herramientas. Equipo de Testing muy lejos. ( Testers en Desarrollo o un área de Testing?) Proceso de trabajo incorrecto. Muchas otras razones www.bstriker.com
Mejora Continua
Modelos Básicos
Otros modelos
Criterios Comunes. Iniciar Medir Priorizar/Planificar Redefinir Operar Validar Evolucionar
Comparativo
Resumen Antes '56 57-78 79-82 (Myers) 83-84 85. TESTING Debbuging Demo Destruccion Evaluacion (V,V &T) Prevención MODELOS DE DESARROLLO Cascada (Benignton - Royce) 92 Modelo V / W 94 RUP Primer Agil 99 TDD MODELOS DE MEJORA CONTINUA STEP - 86 (3) TMM - 90 (5) CTP (12) TPI - 97 (4) (SOGETI) CMMi - 02 SPICE - '04 (6) MODELOS GENERALES Deming PDCA Kaizen TQM EFQM - 88 Six Sigma - 86
Técnicas De Diseño También son técnicas de esamación. Ayudan a generar escenarios de pruebas eficaces. Tienen el concepto de probar lo menos posible pero tanto como haga falta. Es donde mayor parte del esfuerzo de Tesang debe concentrarse. Miden la CALIDAD de un objeto de prueba desde disantos puntos de vista.
Cuando tiene calidad? - Exactitud ( accuracy ) - Adecuación ( suitability ) - Interoperabilidad ( interoperability ) - Seguridad funcional ( functional security ) - Usabilidad ( usability ) - Accesibilidad ( accessibility ) - Seguridad técnica (technical security) - Fiabilidad ( reliability ) - Eficiencia ( efficiency ) - Mantenibilidad ( maintainability ) - Portabilidad ( portability ) Atributos de calidad para pruebas del dominio (funcionales) Atributos de calidad para pruebas técnicas
Invitado Especial Carlos R. Cusmai Director de QAustral SA Formador ISTQB
General - Las pruebas funcionales están dirigidas a verificar la corrección y la completitud de una función - Están disponibles en el módulo todas las funciones especificadas? - 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 / completo - Probar lo menos posible, pero - Probar tanto como sea necesario Página 14
Partición de equivalencia o clase de equivalencia (CE) - La partición en clases de equivalencia es lo que la mayoría de los probadores hacen de forma intuitiva: dividen los posibles valores en clases, mediante lo cual observan - Valores de entrada ( input values ) de un programa (uso habitual del método CE) - Valores de salida ( output values ) de un programa (uso poco habitual del método CE) - El rango de valores definido se agrupa en clases de equivalencia para las cuales se aplican las siguientes reglas: - Todos los valores para los cuales se espera que el programa tenga un comportamiento común se agrupan en una clase de equivalencia (CE) - Las clases de equivalencia no pueden superponerse y no pueden presentar ningún salto (discontinuidad) - Las clases de equivalencia pueden consistir en un rango de valores (por ejemplo, 0<x<10) o en un valor aislado (por ejemplo, x = Verdadero)
Partición de equivalencia - ejemplo - Las clases de equivalencia se escogen para entradas ( inputs) válidas y no válidas - Si el valor x se define como 0 x 100, entonces, inicialmente, se pueden identificar tres clases de equivalencia: 1. x < 0 (valores de entrada no válidos) 2. 0 x 100 (valores de entrada válidos) 3. x > 100 (valores de entrada no válidos) - Se pueden definir CE adicionales, conteniendo, pero no limitadas a: - Entradas no numéricas - Números muy grandes o muy pequeños - Formatos numéricos no admitidos < 0 0-100 > 100
Partición de equivalencia: variables de entrada - Todas las variables de entradas ( input variables ) del objeto de prueba son identificadas, por ejemplo, - Campos de una Interfaz Gráfica de Usuario ( GUI ) - Parámetros de una función (por ejemplo, componente de prueba) - Se define un rango para cada valor de entrada ( input ) - Este rango define la suma del todas las clases de equivalencia válidas (CE v ) - Las clases de equivalencia no válidas (CE nv ) están constituidas por aquellos valores no pertenecientes al rango - Aquellos valores que deben ser tratados de una forma diferente (conocidos o sospechosos) son asignados a una clase de equivalencia aparte Página 17
Partición de equivalencia - ejemplo El porcentaje será presentado en un diagrama de barra. Se aplicarán los siguientes requisitos adicionales (ambos valores incluidos: Valores entre 0 y 15: barra color gris Valores entre 16 y 50: barra color verde Valores entre 51 y 85: barra color amarillo Valores entre 86 y 100: barra color rojo Ahora hay cuatro clases de equivalencia válidas en lugar de una: 1ra clase de equivalencia válida: 0 x 15 2da clase de equivalencia válida:16 x 50 3ra clase de equivalencia válida: 51 x 85 4ta clase de equivalencia válida: 86 x 100 < 0 0-15 16-50 51-85 86-100 > 100
Clase de equivalencia selección de representantes En el último paso, se determina un representante de cada clase de equivalencia así como el resultado esperado para cada uno de ellos Variable Clase de equivalencia Representantes Valor porcentaje (válido) Valor porcentaje (no válido) EC 1 : 0 x 15 + 10 EC 2 : 16 x 50 + 20 EC 3 : 51 x 85 + 80 EC 4 : 86 x 100 + 90 EC 5 : x < 0-10 EC 6 : x > 100 +200 EC 7 : x no entero 1,5 EC 8 : x non numérico fred
Ejemplo de Tabla de Análisis Variable Clase de equivalencia Estado Representante T01 T02 T03 Precio de venta al público EC 11 : x >= 0 válido 1000,00 EC 12 : x < 0 no válido -1000,00 EC 13 : x valor no numérico no válido fred Descuento EC 21 : 0% < x < 100% válido 10% EC 22 : x < 0% no válido -10% EC 23 : x > 100% no válido 200% EC 24 : x valor no numérico no válido fred Precio del porte EC 31 : x = 6 válido 6 EC 32 : x = 9 válido 9 EC 33 : x = 12 válido 12 EC 34 : x {6, 9, 12} no válido 4 EC 35 : x valor no numérico no válido fred
Partición en clases de equivalencia : ejemplo 2/3 - Los siguientes casos de prueba han sido generados utilizando CE no válidas, cada una en combinación con CE válidas de otros elementos: Variable Clase de equivalencia Estado Representante T04 T05 T06 T07 T08 T09 T10 Precio de venta al público EC 11 : x >= 0 válido 1000,00 EC 12 : x < 0 no válido -1000,00 EC 13 : x valor no numérico no válido fred Descuento EC 21 : 0% < x < 100% válido 10% Precio del porte EC 22 : x < 0% no válido -10% EC 23 : x > 100% no válido 200% EC 24 : x valor no numérico no válido fred EC 31 : x = 6 válido 6 EC 32 : x = 9 válido 9 EC 33 : x = 12 válido 12 EC 34 : x {6, 9, 12} no válido 4 EC 35 : x valor no numérico no válido fred
Partición en clases de equivalencia: ejemplo 2/4 - Se obtienen 10 casos de prueba: 3 casos de prueba positivos (valores válidos) y 7 casos de prueba negativos (valores no válidos) Variable Estado Representante T01 T02 T03 T04 T05 T06 T07 T08 T09 T10 Precio de venta al público válido 1000,00 no válido -1000,00 no válido fred Descuento válido 10% Precio del porte no válido -10% no válido 200% no válido fred válido 6 válido 9 válido 12 no válido 4 no válido fred
Partición en clases de equivalencia - Transición - La transición de la especificación o definición de la funcionalidad a la creación de las clases de equivalencia - Con frecuencia es una tarea difícil debido a la carencia de documentación precisa y completa - Los límites no definidos o las descripciones faltantes hacen difícil la definición de las clases de equivalencia - Con frecuencia, es necesario mantener contacto con el cliente con el objeto de completar la información
Análisis de valores límite /1 - El análisis de valores limite amplía la técnica de partición en clases de equivalencia introduciendo una regla para seleccionar representantes - Los valores frontera (valores límite) de la clase de equivalencia deben ser probados de forma intensiva - Porqué prestar más atención a los límites? - Frecuentemente los límites del rango de valores no están bien definidos o conducen a distintas interpretaciones - Comprobar si los límites han sido implementados (programados) correctamente - Observación importante - La experiencia demuestra que, con mucha frecuencia, los errores tienen lugar en los límites del rango de valores! El análisis de los valores límite puede ser aplicado en todos los niveles de prueba. Es fácil de aplicar y su capacidad de detección de defectos es alta en el caso de especificaciones detalladas
Análisis de valores límite /2 - El análisis de valores límite asume que: - La clase de equivalencia está compuesta de un rango continuo de valores (no por un valor individual o un conjunto de valores discretos) - Se pueden definir los límites para el rango de valores - Como extensión a la partición en clases de equivalencia el análisis de valores límite es un método que sugiere la selección de representantes - Partición en clases de equivalencia: - Evalúa un valor (típico) de la clase de equivalencia - Análisis de valores límite: - Evalúa los valores límite (frontera) y su entorno - Se utiliza el siguiente esquema: Rango de valores: Valor Máximo x Valor Mínimo Valor Mínimo - δ Límite Inferior Límite Inferior + δ Valor Máximo - δ Límite Superior Valor Máximo + δ δ es el menor incremento definido para el valor. Por ejemplo: 1 para valores enteros.
Definición de valores límite - El esquema básico sólo puede ser aplicado cuando el rango de valores ha sido definido de conformidad con el mismo esquema. - En este caso no son necesarias pruebas adicionales para un valor en el interior del rango de valores - Si un CE está definido como un único valor numérico, por ejemplo, x = 5, los valores correspondientes al entorno también serán utilizados - Los representantes (de la clase y su entorno) son: 4,5 y 6
Análisis de valores límite ejemplo 3a - Ejemplo 3a: - Rango de valores para un descuento en %: 0,00 x 100,00 - Definición de CE 3 clases: - 1. CE: x < 0,00-2. CE: 0,00 x 100,00-3. CE: x > 100,00 - Análisis de valores límite Extiende los representantes a: 2. EC: -0,01; 0,00; 0,01; 99,99; 100,00; 100,01 - Nota importante: - En lugar de un representante para la CE válida, ahora hay seis representantes (cuatro válidos y dos no válidos)
Pruebas de tabla de decisión ( decision table testing ) - La partición en clases de equivalencia y el análisis de valores límite tratan entradas en condiciones aisladas - Sin embargo, una condición de entrada puede tener efectos sólo en combinación con otras condiciones de entrada - Todos los métodos descritos previamente no tienen en cuenta el efecto de dependencias y combinaciones - El uso del conjunto completo de las combinaciones de todas las clases de equivalencia de entrada conduce, normalmente, a un número muy alto de casos de prueba (explosión de casos de prueba) - Con la ayuda del gráfico causa-efecto ("cause-effect graph") y tablas de decisión obtenidas a partir de aquellos, la cantidad de combinaciones posibles se puede reducir de forma sistemática a un subconjunto de las mismas
Pruebas de tabla de decisión ( decision table testing ) - Ejemplo 5: Banca Online ( Online-Banking ). - El usuario se identifica a través de su número de cuenta y PIN. Si tuviera suficiente cobertura podrá realizar una transferencia. Para poder realizar la transferencia debe introducir los datos del receptor y un TAN válido. Cobertura ( ^ Realizar transferencia Receptor correcto TAN válido ~ ~ V ( ^ TAN identificado como utilizado Denegar transferencia ~ Solicitar TAN nuevamente
Pruebas de tabla de - Ejemplo 5: Banca Online ( Online-Banking ) T01 T02 T03 T04 T05 Precondiciones (Causas) Suficiente cobertura SI NO - - Receptor correcto SI - NO - TAN válido SI - - NO Actividades (Efectos) Realizar transferencia SI NO NO NO Marcar TAN como utilizado SI NO NO NO Denegar transferencia NO SI SI NO Solicitar TAN nuevamente NO NO NO SI - Cada columna de la tabla representa un caso de prueba - Construcción de la tabla de decisión: - Seleccionar un efecto - Retroceder en el diagrama para identificar la causa - Cada combinación de causas está representada por una columna en la tabla de decisión (un caso de prueba) - Combinaciones de causas idénticas, conducentes a efectos distintos, se pueden fusionar para formar un único caso de prueba
Pruebas de transición de estado Para determinar los casos de prueba utilizando un diagrama de transición de estado se construye un árbol de transición El estado inicial es la raíz del árbol Para cada estado que pueda ser alcanzado desde el estado inicial se crea un nodo que está conectado a la raíz por una rama Esta operación se repite y finaliza cuando: El estado del nodo es un estado final (una hoja del árbol) O El mismo nodo con el mismo estado ya es parte del árbol casado "casarse divorciarse muerto "morir divorciado casarse ser soltero" casado soltero No nacido muerto "morir viudo morir "morir m.d.p. casado "casarse muerto muerto Evento: m.d.p.. : muerte de pareja
Pruebas de transición de estado Cada camino desde la raíz a una hoja entonces representa un caso de prueba de prueba de transición de estado El árbol de transición de estado para este ejemplo conduce a los siguientes seis casos de prueba M o M o estado 1 estado 2 estado 3 estado 4 estado 5 estado final C C no nacido soltero muerto muerto no nacido soltero casado muerto muerto D V no nacido soltero casado viudo muerto muerto. no nacido no nacido no nacido soltero soltero soltero casado casado casado viudo divorciado divorciado casado muerto casado casado muerto casado C M o S M o NN
Árbol de transición de estado error muerto muerto casado casado "morir "morir "casarse "casarse divorciado viudo divorciarse m.d.p. casado muerto morir casarse muerto divorciarse soltero "morir ser soltero" No nacido m.d.p. error - El árbol de transición de estado de nuestro ejemplo puede ser extendido ualizando transiciones inválidas (casos de prueba negaavos, pruebas de robustez - Ejemplo: dos transiciones inválidas posibles hay más - Las transiciones imposibles entre estados no se pueden probar Evento: m.d.p.. : muerte de pareja Página 33
IV - Técnicas de diseño de pruebas 03 - Técnicas basadas en la especificación o de caja negra Pruebas basadas en casos de uso /2 - Ejemplo de un diagrama de caso de uso sencillo (fuente: Wikipedia). - El diagrama de la izquierda describe la funcionalidad de un Sistema Restaurant sencillo - Los casos de uso están representados por óvalos y los actores están representados por figuras de palo - El actor Patron puede comer comida ( Eat Food ), pagar por la comida ( Pay for Food )o beber vino ( Drink Wine ) - El actor cocinero ( Chef ) sólo puede preparar comida. Observar que los actores Patron y Cashier están involucrados en el caso de uso Pay for Food (pagar por la comida) - La caja define los límites del sistema Restaurant, es decir, los casos de uso representados son parte del sistema a modelar y no los actores Página 34
Tester Profesional de Software Consejos: Test de LIMITES: Diseñar el test case teniendo en cuenta los limites de los campos en que se va a grabar la información. (ídem para el test de particiones) Test de Estados: Comenzar por este tipo de tests cuando no es clara la definición de partición de datos. Test de Componentes Funcional: Prestar mayor Atención a las propiedades y a los componentes que tengan impacto en la información que se esta ingresando. Tests basados en experiencia anterior: Analizar información resumida, la abundancia de información puede ser nocivo. Recordar que no esta mal consultar o preguntar distintas opiniones de hecho se espera que un tester sea un generador de dialogo.
Using structural coverage Spec Tests SoMware Enough tests? Results OK? More tests What's covered? Coverage OK? Stronger structural techniques (different structural elements) Increasing coverage
Statement coverage percentage of executable statements exercised by a test suite number of statements exercised total number of statements example: program has 100 statements = tests exercise 87 statements statement coverage = 87%? Statement coverage is normally measured by a software tool. Typical ad hoc tesqng achieves 60-75%
Example of statement coverage 1 2 3 4 5 read(a) IF a > 6 THEN b = a ENDIF print b Test Input Expected case output 1 7 7 As all 5 statements are covered by this test case, we have achieved 100% statement coverage Statement numbers
Decision coverage (Branch coverage) percentage of decision outcomes exercised by a test suite number of decisions outcomes exercised = total number of decision outcomes example: program has 120 decision outcomes tests exercise 60 decision outcomes decision coverage = 50% Decision coverage is normally measured by a software tool. True? False Typical ad hoc tesqng achieves 40-60%
Paths through code 1 2 3 4 1 2 1 2 1 2 3??????
Paths through code with loops 123 4 5 6 7 8.? for as many times as it is possible to go round the loop (this can be unlimited, i.e. infinite)
Tips CC >= BC/DC >= SC Cyclomatic complexity Minimum no. of tests to achieve 100% Branch Coverage/ Decision Coverage Minimum no. of tests to achieve 100% Statement Coverage
One decision, no ELSE IF Read A A > 0 THEN Print A positive ENDIF ELSE s = 0 + 1 = 1 = SC Indentations (Tabs) = 2 = BC Read THEN A>0 Otherwise (ELSE) Print cyclomatic complexity: 2 minimum tests to achieve: statement coverage: 1 branch coverage: 2 ENDIF
Read stock level for item IF Item in stock THEN ELSE Get from stores Order from supplier Print Item back-ordered ENDIF Print Item processed cyclomatic complexity: 2 minimum tests to achieve: statement coverage: 2 branch coverage: 2 Self-draw 1 ELSE Read THEN In? Order & Draw the diagram Print in your notes ENDIF Print Get
WHILE loop Read Read order line FALSE? WHILE more items ordered DO Check availability Get from stores ENDDO Print Finished processing cyclomatic complexity: 2 minimum tests to achieve: statement coverage: 1 branch coverage: 1 TRUE Get & Check ENDDO Print
Pseudo- code: Result = 0 Right = 0 DO WHILE more QuesQons IF Answer = Correct THEN Right = Right + 1 ENDIF END DO Result = (Right / QuesQons) IF Result > 60% THEN Print "pass" ELSE Print "fail END IF WHILE and IFs complex: 4 st cov: 2 br cov: 2 init do if end res if fail end r=r+1 pass
Self draw 2 Wait Valid card? Then Display Enter.. Wait for card to be inserted IF card is a valid card THEN display Enter PIN number WHILE PIN is valid DO Else Valid PIN? False ENDDO select transaction ELSE (otherwise) reject card Reject card True select trans. Print record ENDIF ENDDO Indentation Shows End of IF complx: 3 st cov: 2 br cov: 2 ENDIF Print rec
LCSAJ Stress Performance Carga Volumen L10N I18N Regression Recovery Usability MMD Ethical Hacking Taxonomy Configuraaon API Smoke Fuzz.
EJERCICIO
Tienes 1000, sumale 40. Sumale 1000 más. Agrégale 30 y nuevamente 1000. Sumale 20. Sumale 1000 y añádele 10.
FINISHED FILES ARE THE RE- SULT OF YEARS OF SCIENTIF- IC STUDY COMBINED WITH THE EXPERIENCE OF YEARS.
Técnicas De Diseño También son técnicas de esamación. Ayudan a generar escenarios de pruebas eficaces. Tienen el concepto de probar lo menos posible pero tanto como haga falta. Es donde mayor parte del esfuerzo de Tesang debe concentrarse. Miden la CALIDAD de un objeto de prueba desde disantos puntos de vista. Reducen la posibilidad de un error humano mientras se testea.
Muchas gracias! Logo@Copyright www.bstriker.com