tutorial: pruebas funcionales y trabajo en equipo - ati · 2009. 2. 15. · 1 simo tci 2007 8-11-07...

1

SIMO TCI 20078-11-07 - 1 -

Luis Fernández Sanz

Tutorial: pruebas funcionales y trabajo en equipo

Luis Fernández SanzUniversidad Europea de Madrid

Coordinador grupo de Calidad de Software de ATI

Tutorial sobre pruebas funcionales y trabajo en equipoMadrid, 8-11-07 © Luis Fernández, 2007 Nº 2

Objetivos

• Lógicamente limitados

• Algunos de ellos:– Conciencia de los distintos aspectos y la situación de

las pruebas en general– Revisar definiciones y conceptos básicos– Diseño básico funcional– Conciencia de las especificaciones como clave– Conciencia del trabajo en equipo– Conocer las posibilidades de generar casos

funcionales

2


Pruebas

Si tienen interés en ahorrar costes,

ENHORABUENA

han elegido la mejor opción:

LAS PRUEBAS DE SOFTWARE


Pruebas de software

• Gasto medio sobre proyecto de pruebas y depuración sobre costes de proyecto:– 33% (The Original Software Group): 130

compañías– 35,1% (ISE-TR-06-03): 12 compañías– 33% de gasto y 85% de eficiencia de detección

(C.Jones, 1998)• NIST 7007-011:

– Coste de pruebas ineficientes USA: 21.200 M$– Reducción de costes potencial: 10.700 M$

• Eficiencia:– 13,5 % eficientes, 19% automatizan

3


Sondeo sobre prácticas de pruebas

Rellenar el cuestionario adjunto anónimo

Aprovechar a meditar sobre nuestro proceso

Obtener una autoevaluación comparativa

Si me lo permiten, ampliaré el número de respuestas del sondeo


Muestra

• Muestra:– Total: 194

• Período:– 1999 a 2007

• Distribución sectorial– 15,79% banca y finanzas– 16,45% consultoría– 12,50% informática y telecomunicaciones– 5,92% industria y energía– 5,92% defensa– 9,87% variado: I+D, seguros, aeroespacial, etc.– 26,32% no declarado

0

10

20

30

40

50

60

1999 2000 2001 2002 2003 2004 2005 2006 2007 Web

0

10

20

30

40

50

60

1999 2000 2001 2002 2003 2004 2005 2006 2007 Web

Ingeniero6%

Consultor5%

Director5%

Jefe de desarrollo4%

Resto6%

Tester14%

Analista12%

Jefe de proyecto9%Ingeniero de software

9%Gerente

7%

Experto en calidad5%

No definido5%

Analista programador4%

Programador4%

Resp.Calidad3%

Testing manager2%

Ingeniero6%

Consultor5%

Director5%

Jefe de desarrollo4%

Resto6%

Tester14%

Analista12%

Jefe de proyecto9%Ingeniero de software

9%Gerente

7%

Experto en calidad5%

No definido5%

Analista programador4%

Programador4%

Resp.Calidad3%

Testing manager2%

4


Procesos de prueba

• El cuestionario se basa en un modelo del QAI

Proceso como arte: 15,13%Habilidad individual: 42,76%Proceso definido: 32,24%Organización avanzada: 21,71%Calidad de primera clase: 15,79%

Proceso como arte: 15,13%Habilidad individual: 42,76%Proceso definido: 32,24%Organización avanzada: 21,71%Calidad de primera clase: 15,79%

• Media de resp. positivas: 8,45– Varianza: 4,07


Análisis de procesos

23

65

49

33

24

0

10

20

30

40

50

60

70

% nivel de arte % nivel de habilidad individual % nivel de proceso definido % nivel de organizaciónavanzada de pruebas

% nivel de calidad de primeraclase

23

65

49

33

24

0

10

20

30

40

50

60

70

% nivel de arte % nivel de habilidad individual % nivel de proceso definido % nivel de organizaciónavanzada de pruebas

% nivel de calidad de primeraclase

5


Evolución

0,00%5,00%

10,00%15,00%20,00%25,00%30,00%35,00%40,00%45,00%50,00%

% nivel de arte % nivel dehabilidadindividual

% nivel deprocesodefinido

% nivel deorganizaciónavanzada de

pruebas

% nivel decalidad de

primera clase

1999-2005

2006

2007

0,00%5,00%

10,00%15,00%20,00%25,00%30,00%35,00%40,00%45,00%50,00%

% nivel de arte % nivel dehabilidadindividual

% nivel deprocesodefinido

% nivel deorganizaciónavanzada de

pruebas

% nivel decalidad de

primera clase

1999-2005

2006

2007


Preguntas detalladas

Hasta 2007

Hasta 2006

Aspectos más implantados

48,68%40%6. (¿Se valida que las especificaciones están correctas?)

52,63%40%9. (¿Personal de pruebas informa de defectos al equipo de desarrollo y no a otros como dirección?)

61,84%53,6%7. (¿Se valida que, además de bien implementadas, se cumplan las expectativas del cliente?)

6


Preguntas detalladas

Hasta 2007

Hasta 2006

Aspectos menos implantados

13,16%12,8%10. (¿El personal de pruebas identifica los riesgos de negocio antes de desarrollar el plan de pruebas?)

12,50%18,37%20. ¿Supone el uso de herramientas automatizadas de prueba un componente significativo del proceso de pruebas?

9,87%6,4%18. (¿Se usan métricas (p.ej., defectos/KLOC) para planear y evaluar los procesos de pruebas?)


Formación

• Profesionales recibieron formación específica de pruebas:– 26,97% (23,08% hasta 2006)– 6,74% no contesta

• Estudio desde 2003:– Preguntas de conceptos básicos

Preguntas Sin formación Con formación P1 35,59% 45,83%P2 25,42% 41,67%P3 28,81% 54,17%P4 10,17% 12,50%P5 20,34% 33,33%

Preguntas Sin formación Con formación P1 35,59% 45,83%P2 25,42% 41,67%P3 28,81% 54,17%P4 10,17% 12,50%P5 20,34% 33,33%

7


Equilibrio

Área constante

PlazosDefectos

Área constante

Presupuesto

Presupuesto

Área constante

PlazosDefectos

Área constante

Principio del triángulo (¿McConnell, 1997?)


Huir del codificar y corregir

Especificacióndel sistema(con suerte)

Codificary corregir

Entrega(con suerte)

8


• Es muy complejo centrarse sólo en el producto final

• Controlar en todo el proceso de producción:– Aseguramiento de calidad

• Control de productos• Control de procesos

– IEEE 830:• Gestión de configuración, V&V (revisiones y

pruebas), medición

Evaluación de software (II)

Desarrollo deSOFTWARE

SOFTWARE


Enfoque integral de aseguramiento de calidad de software

Revisión deespecificación

Pruebasdel software

Inspecciónde código

Revisión del diseño

Confianza

Diseño sistemático y planificado de acciones para proporcionar la confianza en que el producto se ajusta a los requisitos técnicos establecidos

Software

No existen pruebas o comprobaciones exhaustivas

Rentabilidad económica

Rentabilidad económica

9


Peter Neumann: Inside Risks

http://www.csl.sri.com/users/neumann/illustrative.html

• Barclays Bank casi transfiere 21.000 millones de euros a Grecia (1992)• Un granjero recibe un cheque de 4 millones de dólares del Gobierno de EE.UU en vez de

uno de 31$ (1992)• Un defecto en la aplicación del Departamento de Vehículos a Motor de Alaska hace

encarcelar a un conductor inocente (abril, 1985)• El nuevo sistema informático holandés de justicia ordena liberar a criminales y arrestar

a inocentes: el sistema anterior se eliminó y ¡no hay backup posible! (1987)• Un defecto de software inutiliza las líneas de teléfono de Singapur (1995)• Un pequeño fallo en el software de la lotería de Maryland Lottery distribuye números

ganadores erróneos (1997)• Un fallo en el software de sorteos de la lotería de Arizona: debe escoger 3 números

aleatoriamente pero el 9 nunca sale (1994)

Defecto de Ariane: 10 años y 7000 millones de $39 sg. después del lanzamiento, a una altura de 4,5 km, un mecanismo de autodestrucción acabó con el Ariane 5 y su carga de 4 caros y no asegurados satélites científicos. Cuando el ordenador intentó convertir un dato de velocidad lateral del cohete de 64 bits a 16 bits hubo error de overflow. Se había decidido que este número nunca sería tan grande porque no lo había sido con el Ariane 4. Pero el Ariane 5 era más rápido.Algo absurdo adicional: el cálculo contenía un defecto que tumbó el sistema de guía (que confundió al ordenador de a bordo, que forzó al cohete fuera de ruta) sólo servía para alinear el cohete antes del lanzamiento pero se decidió, mucho antes (en versiones anteriores de Ariane) que siguiera funcionando los primeros 40 segundos de vuelo.

Defecto de Ariane: 10 años y 7000 millones de $39 sg. después del lanzamiento, a una altura de 4,5 km, un mecanismo de autodestrucción acabó con el Ariane 5 y su carga de 4 caros y no asegurados satélites científicos. Cuando el ordenador intentó convertir un dato de velocidad lateral del cohete de 64 bits a 16 bits hubo error de overflow. Se había decidido que este número nunca sería tan grande porque no lo había sido con el Ariane 4. Pero el Ariane 5 era más rápido.Algo absurdo adicional: el cálculo contenía un defecto que tumbó el sistema de guía (que confundió al ordenador de a bordo, que forzó al cohete fuera de ruta) sólo servía para alinear el cohete antes del lanzamiento pero se decidió, mucho antes (en versiones anteriores de Ariane) que siguiera funcionando los primeros 40 segundos de vuelo.


Definiciones• Pruebas

– Ejecución de software con datos controlados (casos) con el fin de descubrir defectos

• Caso de prueba

– Conjunto específico de entrada, procedimientos y salida esperada para una situación de operación

• Salida esperada: especificada (¿diseñada?¿esperada por el usuario?)

• Pruebas como una técnica más de V y V

– Verificar: ¿construir correctamente el producto? Comprobar coherencia en el ciclo de vida

– Validar ¿construir el producto correcto? Comprobar si satisface los requisitos

10


Definiciones

• Definición y relación de error (error, mistake), defecto (fault, defect) y fallo (failure)

2 + 2 = 5Error

Defecto (calidad)

¡Xyx//???

Sistema de gestión de aeropuerto

Fallo (fiabilidad)

S.Aproximación

Accidente(seguridad)

Error (discrepancia)

Resultado esperado


Filosofía

• Objetivo– Descubrir defectos

• Buen caso de prueba– Gran probabilidad de detectar defectos no

encontrados antes• Éxito

– Descubrir un defecto no detectado

• Dijkstra: las pruebas no pueden asegurar la ausencia de defectos, sólo demostrar que (los que localizamos) existen en el software

11


Problemática

• Actitud frecuente– Mito: buen trabajo = cero defectos– Defecto = culpa por mal trabajo– Descubrir defecto = fracaso

• Actitud apropiada– Siempre existen defectos. Tasas tras entrega de

software (defects/KLOC) – Causa de defecto no es siempre negligencia.

Comunicación humana defectuosa– Descubrir defectos es un éxito (diagnóstico médico)

• Evitamos problemas mayores• “Pay now or pay much more later”


Ciclo completo de pruebas

• Ciclo básico: planear, especificar/diseñar, ejecutar, comprobar

DESARROLLODESARROLLO

Información sobre proyectoInformación sobre software(ERS, diseño, etc)

Planear pruebasPlanear pruebas

Plan de pruebasDiseñar pruebasDiseñar pruebas

Configuración depruebas (casos yprocedimientos)

Configuración desoftware revisada

Ejecutar pruebas

Ejecutar pruebas

Evaluar pruebasEvaluar pruebas

Resultadosesperados

Resultados

DepuraciónDepuración

Análisis deerrores

Análisis deerrores

Errores:histórico einformes de pruebas

Correcciones

Estadística deerrores

Acciones preventivas(formación, mejora deprocesos, etc)

Predicción de fiabilidad

12


Diseño de pruebas

Entrada Salida

Funciones

FUNCIONAL(CAJA NEGRA)

Entrada Salida

ESTRUCTURAL(CAJA TRANSPARENTE)

ALEATORIASalida

EntradaaleatoriaUso

Modelode uso


Enfoque funcional

• Centradas en dominio de entrada y de salida• Distintas técnicas:

– Mejores resultados: combinando varias y complementando sus ventajas

• Prueba exhaustiva impracticable– A+B (sumandos 2 dígitos y signo) ≅ 40.000

casos– Quedan todas las entradas no válidas

• Buscar subconjuntos de casos bien elegidos

13


Particiones de equivalencia• Caso bien elegido:

– Invocar máximo número de entradas (mínimo nº de casos)

– Partir dominio en clases equivalentes (probar un valor supone lo mismo que probar cualquier otro)

• Etapas:

1. Identificar clases de equivalencia (tabla de clases):

• Válidas (entradas válidas)

• No válidas (errores o entradas no válidas)

2. Crear los casos de prueba (entrada y salida)


Particiones de equivalencia

• Cada condición o restricción de entrada divide el dominio en dos o más grupos

• Sugerencias para clases:– Rango (“identificador entre 1 y 99”):

• clase válida (1≤ id ≤ 99)• dos clases no válidas (id < 1, id > 99)

– Número de valores (“de 1 a 3 beneficiarios”)• clase válida (1≤ nº benefic. ≤ 3)• dos clases no válidas (nº ben. < 1, nº ben. > 3)

– Situación booleana (“primer carácter es letra”)• clase válida (car. = letra)• clase no válida (car. ≠ letra)

14



• Sugerencias para clases:– Conjunto de valores (“vehículo puede ser

moto, coche, camión”) con distinto tratamiento (“tipo de seguro”):

• una clase válida para cada uno– moto – coche– camión

• una clase no válida (p.ej., “trailer”)– Regla genérica:

• todos los elementos con mismo tratamiento• si no, dividir la clase en otras menores



• Reglas para diseño de casos:

– Asignar identificador a cada clase

– Hasta incorporar todas las clases válidas:

• crear un nuevo caso que cubra tantas como sea posible

– Hasta incorporar todas las clases no válida:

• crear un nuevo caso que cubra una y sólo una clase no válida

Se trata de evitar que unos errores enmascaren a otros o invaliden otros controles similares

15


Ejemplo de formateo numérico

• Prueba funcional:– Selección de valores límite – Tratamiento de combinaciones

• Especificación de entrada y de salida esperada:– Entrada: 25 caracteres

• >1 dígito, ≤ 14 enteros, ≤ 4 decimales• Combinaciones de signo, coma y puntos• Posibles espacios a dcha o izda (no interemedios)• Vale: “+0”, “1234,”, “-,012”, “12.345,6”

– Salida: PIC S9(14)V9(4)• Nº enteros, Nº decimales, signo (T/F), coma (T/F),

puntos (T/F)• Códigos de error


Enfoque recomendado

Diseño de caja negra:• Combinaciones de entrada• Siempre análisis de valores límite• Identificar clases válidas y no válidas y completar

casos• Añadir casos por conjetura de errores

Ejecutar casosControlar cobertura:– Manera de verificar que nos acercamos

continuamente al objetivo y que lo alcanzamos– Ratio: Nº Objetos Probados/Nº Objetos totales a

probarAñadir casos para lograr cobertura prevista

16


Enfoque recomendado

Cobertura caja negra

Cobertura

Cobertura caja blanca sin herramienta

Cobertura caja blanca con herramientaCasi 100%

Volumen de casos


Recomendaciones generales

☺ Cada caso debe definir en detalle la salida esperada

☺ Evitar que el autor pruebe su software☺ Inspeccionar con detalle la salida obtenida☺ Incluir tanto entradas no válidas e inesperadas como

válidas y esperadas☺ Comprobar si el software:

– No hace lo que debe hacer (fallo de funciones)– Hace lo que supone no debe hacer (efectos

secundarios)

17


Recomendaciones generales

☺ Evitar utilizar casos desechables (control y economía)

☺ No planear suponiendo ausencia de defectos☺ Estudios:

– Probabilidad de nuevos defectos es proporcional al número de defectos ya encontrados

☺ Pruebas:– Tarea creativa (no destructiva)– Desafío intelectual


Visión práctica

• El diseño de casos es totalmente dependiente de una buena especificación

– Muchas veces, el trabajo de pruebas supone hacer el trabajo que no hicieron los analistas

• En cuanto tenemos una buena especificación se pueden diseñar los casos de prueba

– En especial, si contamos con casos de uso– No se diseña justo antes de probar

• Eficiencia y limitación de recursos– Sin pruebas perfectas: sólo equilibrio riesgo-coste– Coste = 1/ Nº defectos

• El trabajo en equipo puede proporcionar grandes mejoras de eficacia y de eficiencia

• Como última fase, sufren los retrasos de fases previas– La planificación de pruebas debe contemplar plazos generosos

18


Buena especificación buenas pruebas funcionales (y no funcionales)

• Una buena especificación facilita el diseño de pruebas– IEEE 830: no ambigua, completa, fácil de verificar,

coherente, fácil de modificar, ordenación por prioridades y/o estabilidad, trazabilidad directa e inversa

• El lenguaje natural es ambiguo:– Uso de modelos, técnicas, etc.

• Reaprovechamiento del esfuerzo en modelos para generar pruebas (model driven testing)

• Pensar en pruebas como ayuda al análisis y especificación– XP, etc: pruebas es parte de la especificación


Especificaciones y trabajo en equipo

Leer especificaciónLeer especificación

Responder cuestionario

individualmente

Responder cuestionario

individualmente

Registrar respuestas individuales

Registrar respuestas individuales

Reunirse en grupos de 3 y consensuar

respuestas

Reunirse en grupos de 3 y consensuar

respuestas

Analizar qué ha ocurrido

Analizar qué ha ocurrido

19


Casos de uso

• Describen interacciones actor-sistema– Eficaces para vincular especificación y pruebas– Recogen combinaciones y opciones no válidas

(flujos alternativos)• Generar casos de prueba:

– Caminos/escenarios de ejecución de caso• Diagrama de interacción o de estados

– Sobre cada escenario, diseño de caja negra:• Clases de equivalencia y límites• Tratamiento de combinaciones• Centrado en datos de E/S manejados en el caso


Ejemplo de caso de uso

M u e s t ra M e n u P r in c ip a l

S e le c c io n a r E l im in a r R e s e rva

M ue s t ra p a nt a l l a E l im in a r R e s e rva

Id e n t i fic a c ió n O b ra

O b ra i d e n t i fic a d a

M u e s t ra d a t o s o b ra

S I

Id e n t i fic a c ió n u s u a rio

U s u a rio id e n t i fic a d o

M e n s a je o b ra n o id e n ti fic a d aN O

M e n s ag e u s ua rio n o id e n t i fic a d o

N O

M u e s t ra d a t o s u s u a rio

S I

A c e p t a r e l im in a c ió n

C A N C E L A R

C o n fi rm a r e l im in a c ió n

E l im in a r o t ra re s e rva

N O

C e rra r s e s ió n

S I

O p e ra c io n fa l l id a

A C E P T A R

N O

M e n s a je d e e r ro r

S I

Bibliotecario Sistema

1.- Muestra por pantalla el menú principal

2.- Selecciona la opción Eliminar Reserva

3.- Muestra la pantalla de Eliminar Reserva

4.- Introduce el idObra

5.- Muestra los datos de la obra y pide el DNI del usuario.

6.- Introduce el DNI

7.- Muestra los datos del usuario y pide confirmar la eliminación reserva

8.- Pulsa ACEPTAR 9.- Muestra mensaje de confirmación y pregunta si desea eliminar otra reserva.

10.- Pulsa NO 11.- Cierra sesión y muestra menú principal

20


Diseño de casos

• Estudio previo:– Uso de casos de usos y diagramas de actividad– Estudiantes y profesionales– 36% más casos de prueba que sin especificaciones– Detección de más de 70% de casos:

• Sin especificación: 17%• Con especificación: 65%

– Expertos:• Detectan 50% más que estudiantes

024

68

1012

1416

G1 G2 G3 ATABUS

Nº d

e C

asos

de

Prub

ea

024

68

1012

1416

G1 G2 G3 ATABUS

Nº d

e C

asos

de

Prub

ea


Pruebas en la práctica

Pruebas = algo que se hace después de codificar¿Hay que hacer algo más que ejecutar?Diseño: un poco antes de probar

☺ Diseñar lo antes posible☺Ayuda a analizar y reflexionar sobre

especificaciones☺Hay que mantener diseño pero es rentable☺Detectar problemas antes de crear sistema

☺ Incluso diseñar antes de especificar☺Un requisito más que cumplir

21


Naturaleza de las pruebas

• Ejecución de código:– Entorno controlado/observado

• Reproducibilidad de pruebas– Entrada

• Muestra de la posible entrada (limitaciones)– Resultados correctos predichos

• Comparación con resultados reales• Problemas de predicción o especificación

– Salida analizada• Evidente aunque descuido por

volumen/repetición


Ejecución

EJECUTAR PRUEBASEJECUTAR PRUEBAS

COMPROBAR TERMINACIÓN

COMPROBAR TERMINACIÓN

¿ALGÚNFALLO?

¿ALGÚNFALLO?

DEPURARPRUEBAS

DEPURARCÓDIGO

¿PRUEBASADICIONALES?¿PRUEBAS

ADICIONALES?CONDICIONESANORMALESCONDICIONESANORMALES

NO

SÍ SÍ

EVALUARRESULTADOSEVALUAR

RESULTADOS

PRUEBASADICIONALES

(DEFECTODEL SOFTWARE)

(DEFECTODE PRUEBAS)

TERMINACIÓNANORMAL

TERMINACIÓNNORMAL

NO

SÍ

NO

SÍ

CRITERIOS DECOMPLECIÓN DELPLAN DE PRUEBAS

Priorización de casosPriorización de casos

22


Análisis del diseño de casos

• Programa sencillo de gestión de datos (DVD):– http://esp.uem.es/testRecord/pro– Especificación y registro de pruebas– Comparar con solución correcta– 71 participantes con datos fiables

• Análisis de selección sobre 100 expertos:– Casos propuestos vs solución– Prioridad de casos y eficiencia– Opinión


¿Cómo se diseñan? (I)

• Promedio: 42,36% de opciones• Casos repetidos (total ):

– Inserción: 135% adicional– Consulta: 15,4%– Borrado: 13,8%

• Resultados diferenciados:– Por grupos de participantes– Por resultados de diseño y prioridad de

casos

23


¿Cómo se diseñan? (II)

Porcentaje de caminos ejercitados sobre el total de ATABUS 39% Media de Pruebas realizadas 23 Media de Caminos ejercitados 20 Media de Caminos ejercitados más de una vez 20 Media de Caminos con Defectos ejercitados 4 Media de Defectos detectados 2 Media de Falsos defectos detectados 8 Nº de Participantes que han encontrado más de la mitad de los defectos existentes 29 Nº de Participantes que no han encontrado ninguno de los defectos existentes 10

75% 100% Nº de Participantes por porcentaje de caminos probados sobre el total posible 12 38 20 1 0

0

10

20

30

40

50

60

70

80

0 20 40 60 80 100

% de Caminos Ejercitados

Nº d

e Pa

rtici

pant

es

0

10

20

30

40

50

60

70

80

0 20 40 60 80 100


Nº d

e Pa

rtici

pant

es

0

1

2

3

4

5

6

0 16 22 25 29 33 37 41 45 49 53 57 63 76


Nº

de P

artic

ipan

tes

0

1

2

3

4

5

6

0 16 22 25 29 33 37 41 45 49 53 57 63 76


Nº

de P

artic

ipan

tes


¿Cómo se diseñan? (III)

Operación Director Precio Duración Nº

Pruebas Prioridad

Media

Inserción Valido Válido Entero Dentro del rango 359 1.3

Inserción De entre 2 y 29 caracteres Válido Válida 351 1.3

Inserción Valido Válido Válida 342 1.3

Inserción Valido Dentro del rango sin decimales Válida 282 1.3

Consulta Ninguna coincidencia Válido Válida 228 1.4

Borrado Ninguna coincidencia Válido Válida 203 1.4

Inserción Valido Válido Válida 157 1.3

Inserción Valido Con un carácter Indiferente 142 1.6

Inserción Indiferente Indiferente Indiferente 142 1.2

Inserción Indiferente Indiferente Indiferente 129 1.4

Consulta Ninguna coincidencia Válido Válida 101 1

0%10%20%30%40%50%60%70%80%90%

100%

0% 20% 40% 60% 80% 100%

% de Repeticiones de Más Prioritarias

% d

e Pa

rtic

ipan

tes

0%10%20%30%40%50%60%70%80%90%

100%

0% 20% 40% 60% 80% 100%

% de Repeticiones de Más Prioritarias

% d

e Pa

rtic

ipan

tes

24


Conclusiones de diseño

• De 71 testers:– 1 probó > 75% de caminos totales– 56% alcanzan

25

SIMO TCI 20078-11-07 - 49 -

Luis Fernández Sanz

Gracias por su atención

¿preguntas?

Contacto: [email protected]

Recomiendo:http://www.ati.es/gtcalidadsofthttp://www.ati.es/reicishttp://esp.uem.es/Testrecord/prohttp://in2test.lsi.uniovi.es/repris/http://esp.uem.es/rentic


¿Utiliza casos de uso para completar la especificación del sistema?

Sí (53.13%) No (28.13%) Depende (18.75%)

¿Utiliza algún diagrama UML para especificar o diseñar el sistema?

Sí (46.88%) No (34.38%) Depende (18.75%)

¿Utiliza algún diagrama UML para diseñar las Pruebas del sistema?

Sí (12.5%) No (62.5%) Depende (25%)

¿Utiliza alguna herramienta o método para diseñar las pruebas del sistema?

Herramienta (6.25%)

Método (31.25%)

Ambos (9.38%)

Ninguno (53.13%)

Resultados (IV)

Utilidad del uso del"Algoritmo Automático" para el diseño y ejecución de pruebas

Nada útil (3.33%)

Poco Útil (10%)

Útil (30%)

Muy Útil (46.67%)

Imprescindible (10%)

¿Sería rentable en su organización?

Sí (76%) No (24%)

En la simulación, los casos generados automáticamente suponen una cobertura del código de

Menos del 20% (16%)

Entre 20 y 50% (4%)

Entre 50 y 80% (52%)

Mas del 80% (28%)

En el experimento, los casos generados automáticamente, sobre el total posible, cubren

Menos del 20% (8%)

Entre 20 y 50% (8%)

Entre 50 y 80% (44%)

Mas del 80% (40%)

tutorial: pruebas funcionales y trabajo en equipo - ati · 2009. 2. 15. · 1 simo tci 2007 8-11-07...

Documents