Generación automática de casos de prueba para test de una ...
“Tecnicas de Diseño de Casos de Prueba.”
Transcript of “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
Página 14
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
Página 17
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%
EC24: x valor no numérico no válido fred
Precio del porte
EC31: x = 6 válido 6
EC32: x = 9 válido 9
EC33: x = 12 válido 12
EC34: x ≠ {6, 9, 12} no válido 4
EC35: x valor no numérico no válido fred
• 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
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%
EC24: x valor no numérico no válido fred
Precio del porte
EC31: x = 6 válido 6
EC32: x = 9 válido 9
EC33: x = 12 válido 12
EC34: x ≠ {6, 9, 12} no válido 4
EC35: 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%
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
Página 33
Á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
Página 34
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
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
– cyclomatic complexity: _____ – minimum tests to achieve:
• statement coverage: ______ • branch coverage: _____
2
2
2
Get
ENDIF
THEN In?
ELSE
Read
Order & 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
– cyclomatic complexity: _____ – minimum tests to achieve:
• statement coverage: ______ • branch coverage: _____
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!