Академический Документы
Профессиональный Документы
Культура Документы
Verificación:
Proceso de evaluación de un sistema para determinar si
los productos de una fase dada satisfacen las condiciones
impuestas al comienzo de la misma
¿estamos construyendo correctamente el producto?
Validación:
Proceso de evaluación de un sistema durante o al final del
proceso de desarrollo para determinar si satisface los
requisitos marcados por el usuario
¿estamos construyendo el producto correcto?
reactores nucleares),
¡de 3 a 5 veces más que el resto de pasos juntos de
la ingeniería del software!
No se detectan ausencias
Cobertura de sentencias
Para el ejemplo:
A=2, B=0, X=3
2 0 4 C C C C C C
1 1 1 F F F F F F
Bucles no estructurados:
rediseñar primero
V(G)=arcos-nodos+1= 14-11+2 = 5
V(G)=nº de regiones cerradas = 5
(contar la región exterior)
V(G)= nodos de condición + 1 = 4+1 = 5
C1: 1-2-3-4-5-6-7-9-4-10-2-11
C2: 1-2-3-4-5-6-8-9-4-10-2-11
C3: 1-2-3-4-5-10-2-11
C4: 1-2-3-4-10-2-11
C5: 1-2-11
Habría que diseñar casos de prueba que cubran todas las clases de
equivalencia, tanto para las válidas como para las no válidas, y
para éstas en casos de prueba distintos
Tema 6. Pruebas del Software 48
Casos de prueba
Para clases válidas
Caso de prueba (clases cubiertas) Salida esperada
200, reinte, cheque (1, 5, 8)
200, reinte, depósito (1, 5, 9)
200, reinte, pago factura (1, 5, 10)
200, reinte, retirada de fondos (1, 5, 11)
Para clases no válidas
Caso de prueba (clases cubiertas) Salida esperada
199, reinte, cheque (2)
1000, reinte, cheque (3)
A, reinte, cheque (4)
200, re, cheque (6)
200, reintegro, cheque (7)
200, reinte, actualizar libreta (12)
Tema 6. Pruebas del Software 49
Análisis de Valores Límite (AVL)
En todos los casos, usar el análisis de valores límite para añadir casos
de prueba
Identificar las clases válidas y no válidas de equivalencia para la entrada
y la salida, y añadir los casos no incluidos anteriormente
Utilizar la técnica de conjetura de errores para añadir nuevos casos,
referidos a valores especiales
Ejecutar los casos generados hasta el momento y analizar la cobertura
obtenida
Examinar la lógica del programa para añadir los casos precisos (de caja
blanca) para cumplir el criterio de cobertura elegido si los resultados de
la ejecución del punto anterior indican que no se ha satisfecho el criterio
de cobertura elegido
Especificación de
Pruebas de sistema
requisitos
Especificación
Pruebas de unidad
lógica del módulo
Código
Tema 6. Pruebas del Software 57
Prueba de unidad
Si se dispone del código (caja blanca) y los métodos get y set acceden
directamente (sin ninguna “traducción” intermedia), la prueba descrita
anteriormente parece absurda, solo puede fallar si falla la plataforma
(compilador,...)
Aun así, no es descartable esta prueba. La razón es la mantenibilidad
preventiva, si la implementación de los métodos get y set cambia, el
software de pruebas estaría preparado para ello
El coste de la depuración
Ventajas de la incremental:
Requiere menos trabajo, ya que se escriben menos módulos
impulsores y ficticios
Los defectos y errores en las interfaces se detectan antes, ya que
se empieza antes a probar las uniones entre los módulos
La depuración es mucho más fácil, ya que si se detectan los
síntomas de un defecto en un paso de la integración hay que
atribuirlo muy probablemente al último módulo incorporado
Se examina con mayor detalle el programa, al ir comprobando
cada interfaz poco a poco
sistema
El funcionamiento y rendimiento en las interfaces
sobrecarga
Adecuación de la documentación de usuario
XMLUnit (http:xmlunit.sourceforge.net)
Facilita las pruebas de código que maneja y genera archivos XML
HttpUnit/HtmlUnit/JWebUnit (http:httpunit.sourceforge.net,
http:htmlunit.sourceforge.net, http:jwebunit.sourceforge.net)
Facilita las pruebas de aplicaciones web
JFunc/JUnitPerf/JMeter (http:jfunc.sourceforge.net,
http:clarkware.com/software/JUnitPerf.html,
http:jakarta.apache.org/jmeter/)
Facilita las pruebas de funcionalidad
Pruebas de integración
Pruebas de implantación
Pruebas de aceptación