Aca se presenta un poco de información hacerca de los test y tratar de hacer conciencia de probar las cosas de manera adecuada.
1) Definiciones - Testing.
Según IEEE standards 1999. “El testing de software es el proceso de analizar un producto de software para detectar las diferencias entre el comportamiento real y el pretendido, y para evaluar las funcionalidades y características no funcionales del software”
2) ¿Por qué es necesario el testing?
- Identificar fallos
- Reducir defectos en producción
- Mejorar la calidad de la aplicación de los usuarios
- Incrementar la fiabilidad
- Para asegurar que los fallos no impactan a los costes y a la rentabilidad
- Para asegurar que los requisitos son satisfechos
- Para asegurar que los requisitos legales son conocidos
- Proveer una medida de calidad
3) El gran axioma del testing.
Axioma: “El Testing sólo puede mostrar la presencia de defectos, no su ausencia” (Dijkstra).
Corolario: Un test sólo es exitoso si encuentra errores.
4) Conceptos: Casos vs datos de test.
- Casos de test: descripciones de condiciones o situaciones a testear.
- Según IEEE standards 1999: “Es un conjunto de condiciones de ejecución sobre los valores de entrada y resultados esperados generadas para satisfacer un objetivo particular”
- Crear casos de test es un proceso creativo.
- Datos de test: lotes de datos necesarios para ejecutar un caso de test.
- Crear datos de test es muy laborioso... Y poco creativo.
5) Casos de test.
- Lo ideal sería probar el programa en todas las situaciones posibles
- Una de las mayores dificultades es encontrar un conjunto de tests adecuado:
- Suficientemente grande para abarcar el dominio y maximizar la probabilidad de encontrar errores
- Suficientemente pequeño para poder ejecutar el proceso de testing con cada elemento del conjunto y minimizar el costo del testing
6) Equipo de trabajo.
Líder de proyecto
- Definición de la estrategia de testing
- Elaboración del plan
- Control del proyecto
- Interacción con el cliente
Tester Diseñador
- Definición de los casos de prueba
- Poblado de las condiciones de prueba
Tester ejecutor
- Ejecución de los casos de prueba
- Detección y registro de incidentes
7) Testing de Unidades.
- Se trata de probar módulos sueltos
- Fase informal previa:
- Ejecutar pequeños ejemplos
- Hay herramientas que analizan automáticamente la sintaxis de los programas (¡e incluso “opinan” sobre fuentes potenciales de error!)
- Fase de prueba sistemática:
- Pruebas de caja blanca (o transparente): Se mira con lupa la estructura del código escrito
- Pruebas de caja negra: Se prueba la funcionalidad del módulo sin atender a su contenido
8) Testing de Integración.
- Involucran varios módulos
- Pueden ser estructurales o funcionales
- Estructurales: como las de caja blanca, pero analizando llamadas entre módulos
- Funcionales: como las de caja negra, pero comprobando funcionalidades conjuntas
- Se siguen utilizando clases de equivalencia y análisis de valores frontera
- Las pruebas finales consideran todo el sistema, cubriendo plenamente la especificación de requisitos del usuario
9) Testing del Sistema.
Realiza una batería de pruebas completa del sistema para tener información fiable de que el software cumple los requerimientos de prestaciones y funcionales solicitados.
Ejemplos:
- Pruebas de Desempeño
- Pruebas de Carga
- Pruebas de Stress
10) Testing de regresión.
- Repetir las pruebas tras cada modificación
- Repetir sólo pruebas de verificación
- Pruebas de unidades
- Pruebas de integración
- Conservar y actualizar los programas de prueba
11) Plan de Testing.
Es un conjunto de pruebas
Cada prueba debe:
- Dejar claro qué tipo de propiedades se quieren probar
- Dejar claro cómo se mide el resultado
- Especificar en qué consiste la prueba
- Definir cuál es el resultado que se espera
- Las pruebas “angelicales” carecen de utilidad
12) TDD (Desarrollo guiado por pruebas, o Test-driven development).
Es una práctica de programación que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring). Para escribir las pruebas generalmente se utilizan las pruebas unitarias (unit test en inglés). En Primer Lugar se escribe una prueba y se verifica que las pruebas fallen, luego se implementa el código que haga que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito. El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione (Del inglés: Clean code that works). La idea es que los requerimientos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que los requerimientos se hayan implementado correctamente.
14) Metodologías basados en pruebas.
TDD
DDD
BDD
Se puede encontrar mas información de estos temas en las VAN de Alt Net Hispano, en donde se han tratado y mostrado ejemplos de los mismos.
No hay comentarios:
Publicar un comentario