1. No category

“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 Debbuging Demo Evaluacion Destruccion (V,V &T) TESTING MODELOS DE DESARROLLO MODELOS DE MEJORA CONTINUA MODELOS GENERALES Cascada (Benignton -­‐ Royce) Prevención 92 Modelo 94 RUP V / W Primer Agil TMM -­‐ 90 STEP -­‐ 86 (3) (5) CTP (12) Deming PDCA Kaizen 85 …. TQM EFQM -­‐ 88 Six Sigma -­‐ 86 99 TDD TPI -­‐ 97 (4) (SOGETI) CMMi -­‐ SPICE -­‐ 02 '04 (6) 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”)
Atributos de calidad
para pruebas del
dominio
(funcionales)
- Seguridad técnica (technical security)
- Fiabilidad (“reliability”)
- Eficiencia (“efficiency”)
- Mantenibilidad (“maintainability”)
- Portabilidad (“portability”)
Atributos de calidad
para pruebas
técnicas
- Seguridad funcional (“functional security”)
- Usabilidad (“usability”)
- Accesibilidad (“accessibility”)
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
(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
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:
Valores entre 16 y 50:
Valores entre 51 y 85:
Valores entre 86 y 100:
barra color gris
barra color verde
barra color amarillo
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)
EC1: 0 ≤ x ≤ 15
+ 10
EC2: 16 ≤ x ≤ 50
+ 20
EC3: 51 ≤ x ≤ 85
+ 80
EC4: 86 ≤ x ≤ 100
+ 90
EC5: x < 0
-10
EC6: x > 100
+200
EC7: x no entero
1,5
EC8: x non numérico
fred
Valor porcentaje
(no válido)
•  Ejemplo de Tabla de Análisis Variable
Precio de venta
al público
Descuento
Precio del porte
Clase de equivalencia
Estado
Representante
T01
T02
T03
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
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
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
EC21: 0% < x < 100%
­
­
­
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
Precio de
venta al
público
Descuento
Precio del
porte
Clase de equivalencia
Estado
Representante
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
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
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
EC21: 0% < x < 100%
T04
T05
T06
T07
T08
T09
T10
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
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
Precio de
venta al
público
Descuento
Precio del
porte
Estado
válido
no válido
no válido
válido
Representante
1000,00
-1000,00
fred
10%
no válido
no válido
no válido
válido
válido
válido
no válido
no válido
-10%
200%
fred
6
9
12
4
fred
T01
­
T02
­
T03
­
T04
T05
T06
­
T07
­
T08
­
T09
­
T10
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
­
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
~
~
~
(^
V
Realizar transferencia
TAN identificado como utilizado
Denegar transferencia
Solicitar TAN nuevamente
Pruebas de tabla de
- 
Ejemplo 5: Banca Online (“Online-Banking”)
T01 T03 T04 T05
T02
Precondiciones (Causas)
Actividades (Efectos)
- 
- 
Suficiente cobertura
SI
NO
-
-
Receptor correcto
SI
-
NO
-
TAN válido
SI
-
-
NO
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
muerto muerto casado casado "morir“
"casarse“
"morir“
"casarse“
viudo divorciado “m.d.p.“
“divorciarse“
casado “morir”
muerto “casarse”
soltero "morir“
muerto “ser soltero"
No nacido 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 estado 1
estado 2
estado 3
estado 4
estado 5
estado final
no nacido
soltero
muerto
no nacido
soltero
casado
muerto
no nacido
soltero
casado
viudo
muerto
muerto.
no nacido
soltero
casado
viudo
casado
casado
no nacido
soltero
casado
divorciado
muerto
muerto
no nacido
soltero
casado
divorciado
casado
casado
M
o C C muerto
muerto
V D C S NN M
o M
o Árbol de transición de estado
- 
muerto muerto casado casado "morir“
"morir“
divorciado viudo "casarse“
"casarse“
“m.d.p.“
“divorciarse“
casado - 
muerto “morir”
error “casarse”
muerto “divorciarse“
soltero “ser soltero"
error No nacido “m.d.p.“
Evento: “m.d.p..”: muerte de pareja
Página 33
- 
"morir“
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 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? What's covered? Coverage OK? More tests 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 read(a) 2 IF a > 6 THEN 3 b = a 4 ENDIF 5 print b Test
case
Input
Expected
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
Decision coverage
is normally measured
by a software tool.
number of decisions outcomes exercised
= total number of decision outcomes
•  example:
?
True
– program has 120 decision outcomes
– tests exercise 60 decision outcomes
– decision coverage = 50%
Typical ad hoc tesQng achieves 40 -­‐ 60% False
1234
Paths through code
12
12
123
? ? ? ? ? ? Paths through code with loops
1 2 3 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
Read A
IF A > 0 THEN
Print “A positive”
ENDIF
ELSE’s = 0 + 1 = 1 = SC
Indentations (Tabs) = 2 = BC
2
–  cyclomatic complexity: _____
–  minimum tests to achieve:
1
• statement coverage: ______
• branch coverage: _____
2
Read THEN
A>0 Otherwise
(ELSE)
ENDIF Print Self-draw 1
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”
2
–  cyclomatic complexity: _____
–  minimum tests to achieve:
2
• statement coverage: ______
2
• branch coverage: _____
Read In? THEN
ELSE
Order & Draw the diagram Print in your notes ENDIF Print Get Read WHILE loop
Read order line
WHILE more items ordered DO
Check availability
Get from stores
FALSE
? TRUE
Get & Check ENDDO
Print “Finished processing”
2
–  cyclomatic complexity: _____
–  minimum tests to achieve:
1
• statement coverage: ______
1
• branch coverage: _____
ENDDO Print init WHILE and IFs
Pseudo-­‐code: Result = 0 Right = 0 do if DO WHILE more QuesQons IF Answer = Correct THEN end Right = Right + 1 ENDIF res r=r+1 END DO Result = (Right / QuesQons) IF Result > 60% THEN Print "pass" ELSE Print "fail” END IF if 4
– complex: _____ 2
• st cov: _____ 2
• br cov: _____ fail end pass Wait Self draw 2
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
Valid card? Then
Else
Reject card 3
– complx: _____ 2
• st cov: _____ • br cov: _____ 2
Valid PIN? ENDDO ENDIF
Print rec False
True
select trans. ENDIF
Indentation
Shows
End of IF
Display “Enter.. 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