“Tecnicas de Diseño de Casos de Prueba.”

“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

técnicas

Atributos de calidad para pruebas del

dominio (funcionales)

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

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 - 100 < 0 > 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 (CEv)

-  Las clases de equivalencia no válidas (CEnv) 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

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 - 15 16 - 50 51 - 85 86 - 100 < 0 > 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) EC1: 0 ≤ x ≤ 15 + 10

EC2: 16 ≤ x ≤ 50 + 20

EC3: 51 ≤ x ≤ 85 + 80

EC4: 86 ≤ x ≤ 100 + 90

Valor porcentaje (no válido)

EC5: x < 0 -10

EC6: x > 100 +200

EC7: x no entero 1,5

EC8: x non numérico fred

Variable Clase de equivalencia Estado Representante T01 T02 T03

Precio de venta al público

EC11: x >= 0 válido 1000,00

EC12: x < 0 no válido -1000,00

EC13: x valor no numérico no válido fred

Descuento EC21: 0% < x < 100% válido 10%

EC22: x < 0% no válido -10%

EC23: x > 100% no válido 200%


Precio del porte

EC31: x = 6 válido 6



EC34: x ≠ {6, 9, 12} no válido 4


•  Ejemplo de Tabla de Análisis

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

EC11: x >= 0 válido 1000,00

EC12: x < 0 no válido -1000,00


Descuento EC21: 0% < x < 100% válido 10%

EC22: x < 0% no válido -10%

EC23: x > 100% no válido 200%


Precio del porte




EC34: x ≠ {6, 9, 12} no válido 4


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%

no válido -10%

no válido 200%

no válido fred

Precio del porte

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

Receptor correcto

TAN válido

Realizar transferencia

TAN identificado como utilizado

Solicitar TAN nuevamente

Denegar transferencia

( ̂

( ̂ V

~ ~

~

Pruebas de tabla de -  Ejemplo 5: Banca Online (“Online-Banking”)

-  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

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

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

“morir”

"morir“

“ser soltero"

“divorciarse“

“casarse”

“m.d.p.“

"casarse“ "casarse“

No nacido

soltero

casado

viudo

casado

divorciado

muerto

casado

muerto

muerto

muerto

"morir“ "morir“

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

casado casado viudo casado soltero no nacido

casado casado divorciado casado soltero no nacido

divorciado

viudo

muerto

estado 4

muerto muerto soltero no nacido

muerto casado soltero no nacido

muerto muerto casado soltero no nacido

muerto. muerto casado soltero no nacido

estado final estado 5 estado 3 estado 2 estado 1

NN

S

C

V

C

D

Mo

C

Mo

Mo

Mo

Árbol de transición de estado

“morir”

"morir“

“ser soltero"

“divorciarse“

“casarse”

“m.d.p.“

"casarse“ "casarse“

No nacido

soltero

casado

viudo

casado

divorciado

muerto

casado

muerto

muerto

muerto

"morir“ "morir“

Evento: “m.d.p..”: muerte de pareja

error

error

“m.d.p.“

“divorciarse“

-  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

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

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.

Tester Profesional de Software

Stronger structural techniques (different structural elements)

More tests

Using structural coverage

Increasing coverage

Coverage OK?

What's covered?

Results OK?

Enough tests?

Spec SoMware

Tests

More tests More tests More tests More tests More tests More tests More tests

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%

=

Typical ad hoc tesQng achieves 60 -‐ 75%

Statement coverage is normally measured

by a software tool.

?

Example of statement coverage

Test case

Input Expected output

1 7 7

As all 5 statements are ‘covered’ by this test case, we have achieved

100% statement coverage

read(a) IF a > 6 THEN b = a ENDIF print b

1 2 3 4 5

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%

Typical ad hoc tesQng achieves 40 -‐ 60%

=

Decision coverage is normally measured

by a software tool.

True

False ?

Paths through code

? ?

1 2

? ?

1 2 3 1 2 ?

?

1 2 3 4

Paths through code with loops

?

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)

2 1 3

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

Read A IF A > 0 THEN Print “A positive” ENDIF

One decision, no ELSE

–  cyclomatic complexity: _____ –  minimum tests to achieve:

• statement coverage: ______ • branch coverage: _____

2

1

2

Print

ENDIF

THEN A>0

Otherwise (ELSE)

Read

Indentations (Tabs) = 2 = BC

ELSE’s = 0 + 1 = 1 = SC

Read stock level for item IF Item in stock THEN Get from stores ELSE Order from supplier Print “Item back-ordered” ENDIF Print “Item processed”

Self-draw 1



2

2

2

Get

ENDIF

THEN In?

ELSE

Read

Order & Print

Print

Draw the diagram in your notes

FALSE

ENDDO

TRUE Get & Check

Read order line WHILE more items ordered DO Check availability Get from stores

ENDDO Print “Finished processing”

WHILE loop

?

Read

Print



2

1 1

WHILE and IFs

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 end

end

do

if r=r+1

init

if

res

pass

fail

Pseudo-‐code:

– complex: _____ • st cov: _____ • br cov: _____

4 2 2

select trans.

True

Wait for card to be inserted IF card is a valid card THEN

display “Enter PIN number” WHILE PIN is valid DO select transaction ENDDO

ELSE (otherwise) reject card

Print record

Self draw 2

Display “Enter..

Valid PIN?

Else

Reject card

Then Valid card?

Wait

– complx: _____ • st cov: _____ • br cov: _____

3 2 2

ENDIF

ENDIF ENDDO

False

Print rec

Indentation Shows End of IF

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.

Logo@Copyright www.bstriker.com

¡Muchas gracias!

“Tecnicas de Diseño de Casos de Prueba.”

Documents

Transcript of “Tecnicas de Diseño de Casos de Prueba.”