_UF2 Vts Flashcards
Diseño y realización de pruebas
B/N
- De caja blanca
- De caja negra
Estrategias de pruebas de software: automatización de pruebas
U-I-V-S
- Prueba de unidad
- Prueba de integración
- Prueba de validación
- Prueba de sistema
Tipos de anotaciones en JUnit
@Before
@After
@BeforeClass
@AfterClass
Pruebas parametrizadas con JUnit
@RunWith(Parameterized.class)
@Parameters
Pruebas de integración
-
Prueba de validación
A|B
- Pruebas alfa
- Pruebas beta (Técnicas caja negra)
Prueba del sistema
RSR
- Prueba de recuperación
- Prueba de seguridad
- Prueba de resistencia (stress)
Pruebas de código (caja blanca):
Cob-VL-Equiv
- Cobertura
- Valores límite
- Clases de equivalencia
Complejidad ciclomática
1) V(G) = número de regiones del grafo
2) V(G) = aristas - nodos + 2
3) V(G) = nodos predicado + 1
- Entre 1 y 10: programas o métodos sencillos, sin mucho riesgo.
- Entre 11 y 20: programas o métodos más complejos, riesgo moderado
- Entre 21 y 50: Programas o métodos complejos, alto riesgo.
- Mayor que 50: programas o métodos no testeables, muy alto riesgo.
Partición o clases de equivalencia (casos de prueba)
-
Tipos de pruebas
FER
- Funcionales
- Estructurales
- De regresión
Calidad del software (ISO/IEC 25000 SQuaRE
GMMRE-EEx
- ISO/IEC 2500n. Div GESTION de Calidad
- ISO/IEC 2501n. Div de MODELO de Calidad
- ISO/IEC 2502n. Div de MEDICIÓN de Calidad
- ISO/IEC 25030n. Div de REQUISITOS de Calidad
- ISO/IEC 25040n. Div de EVALUACIÓN de Calidad
- ISO/IEC 25050n-25099n. Estándares de Extensión SQuaRE
Medidas de calidad del software
n1: número de operadores únicos que aparecen en un programa
n2: número de operandos únicos que aparecen en un programa
N1: número total de ocurrencias de operadores
N2: número total de ocurrencias de operandos
- Longitud: N = N1 + N2
- Volumen: V = N * log2(n)
- Dificultad: D = ((n1 * N2)/(n2 * 2))
- Esfuerzo: E = V * D
- Nivel: L = 1 / D
Documentación y optimización:
Refactorización: concepto, limitaciones, patrones de refracción más usuales
-
Cuando refactorizar
- Código duplicado (duplicated code)
- Métodos muy largos (long method)
- Clases muy grandes (large class)
- Lista de parámetros extensa (long paremeter list)
- Cambio divergente (divergent change)
- Cirugía a tipo de pistola (shotgun surgery)
- Envidia de funcionalidad (feature envy)
- Clase de sólo datos (data class)
- Legado rechazado (refused bequest)
Refactorización en Eclipse:
Aspectos importantes al refactorizar
- Se reestructura el código sin que haya cambios significativos en él.
- El IDE conoce las relaciones entre los métodos y las clases permitiendo hacer cambios.
- Definir correctamente los casos de pruebas antes de refactorizar.
Refactorización y pruebas:
Casos de pruebas
- Automáticos.
- Reportar los casos de fallo y errores que se encuentren.
- Deben poder ejecutarse de forma independiente.
Importancia de las pruebas al refactorizar:
Pruebas unitarias
- Nos previenen de las pruebas de regresión
- Facilitan refactorizar
- Mejoran como está diseñada la implementación
Ventajas e inconvenientes de refactorizar
Ventajas:
- Facilita la comprensión de nuestro código
- Favorece la detección de errores
- Mayor rapidez en la programación
- Mayor calidad durante el proceso
Inconvenientes:
- Migraciones implican cambios estructurales en los datos.
- El cambio de interfaz sin acceso al código fuente puede ser problemático.
Patrones de diseño:
Estructura patrón
- Nombre
- Problema
- Solución
- Consecuencias
Tipos de patrones
- Estructurales
- Comportamiento
- Creacionales
Control de versiones:
Estructura de las herramientas de control de versiones
(Estructura patrón)
- Repositorio
- Revisión o versión
- Etiquetar o rotular (tag)
- Tronco (trunk)
- Rama o ramificar (Branch)
- Desplegar (checkout)
- Confirmar (commit o check-in)
- Exportación (export)
- Importación
- Actualizar (update)
- Fusión (update)
- Conflicto
- Resolver conflicto
Repositorio
- Branches
- Trunk
- Tag
Tipos de herramientas de control de versiones
- GIT
Documentación: uso de comentarios, alternativas
- Especificaciones:
> Introducción
> Descripción de la información
> Descripción funcional
> Descripción del comportamiento
> Criterios de validación
- Diseño
- Código fuente:
> Todos los programas poseen errores
> Todos los programas sufren modificaciones
- Usuario finalUso de etiquetas de documentación:
@author: Auto de la clase (sólo para clases)
@version: Versión de la clase (solo para clases)
@see: referencia a otra clase
@param: Descripción del parámetro (una etiqueta por cada parámetro)
@return: Descripción de lo que devuelve (solo si no es void)
@throws: Descripción de la excepción que puede propagar (habrá una etiqueta throws por cada tipo de excepción)
@since: número de versión del producto
