Para simplificar el proceso de pruebas de software
Principio 1 - Sirven para demostrar si existen defectos
en el software
Principio 2 - No es posible realizar una prueba que
cubra todas las variables y las necesidades del
cliente
Principio 3 - Se realizan al principio del ciclo de vida de los productos
Principio 4 - Agrupalas por tipo para revisar el software
Para detectar el mismo tipo de defecto para más rápido
Principio 5 - Deben actualizarse periodicamente para detectar nuevos errores
Principio 6 - Se efectúan dependiendo del funcionamiento del software
Comprobar la seguridad en una aplicación bancaria que en una
donde se compran boletos por internet
7 - El producto final debe de cumplir con las espectativas del usuario
2 - Proceso de pruebas
Planificación y control
Planificación de pruebas
Definición de los objetivos y cumplir metas establecidas
Identificar defectos
Aumentar la calidad del software
Facilitar la información para la toma de decisiones
Evitar la aparición de defectos
Análisis y diseño de pruebas
Transforma los objetivos en tareas que debemos hacer
Revisar la base de pruebas, requisitos e
informes de análisis de riesgos
Identificar y dar prioridad a las condiciones de la prueba con base a los
análisis de los elementos, la especificación, el comportamiento y la
estructura del sistema
Diseñar y ordenar los casos de prueba
Identificar los datos de prueba
Diseñar la configuración del entorno de las pruebas
Ejecución
Actividad donde se especifican los procedimientos
Verificar que el entorno de las pruebas haya sido debidamente configurado
Implementar los casos de prueba
registrar los resultados de la ejecución
Evaluación de los criterios de salida
Actividad que compara la ejecución de
las pruebas contra los objetivos definidos
Comprobar los resultados con los valores
previstos en la planificación de la prueba
Evaluar si se requieren más pruebas
Elaborar un resumen de las pruebas para tu equipo de trabajo y tu cliente
Actividades de cierre
Se recopilan los datos de las pruebas terminadas
Comprobar qué documentos han sido entregados
Cerrar los informes de incidencia
Documentar cuántos usuarios aceptaron el sistema
Archivar los productos de soporte, entorno y la
infraestructura para usarlos en futuras pruebas
Utilizar la información recopilada
Para mejorar la madurez de las pruebas
3 - Modelos de prueba
Contiene la forma en la que puedes aplicar
los diferentes tipos de pruebas
Modelo V
Desarrollo secuencial
Nivel 1 - Pruebas de componente
Localizar los defectos y probar el funcionamiento de los módulos del software de forma neutral
Enfocadas en los requisitos de los componentes
Ejemplo
Módulo: Inicio de sesión
Cómo reacciona el sistema cuando se ingresan datos
correctos, incorrectos y cuando el campo está vacío
Módulo: Saldo pendiente
Módulo: Pagos y recargas
Módulo: Historial de llamadas
Nivel 2 . Pruebas de integración
Se hacen en base a la arquitectura del sistema o a las tareas funcionales
Consisten en checar el flujo de información entre los módulos
Verificar el funcionamiento entre la interfaz y sus componentes
Nivel 3 - Pruebas de sistema
Sirven para revisar el funcionamiento de un software en su totalidad
Su objetivo es que el software cumplan con los requisitos funcionales
y no funcionales para minimizar la posibilidad de errores
Nivel 4 - Pruebas de aceptación
El cliente determina si el sistema tiene éxito
Confirma si es confiable en su uso y su comportamiento
Este modelo podría componerse de más niveles
Modelo de desarrollo iterativo - Incremental
Proceso que forma un grupo de tareas
Pertenecen a una pequeña parte del sistema y sirven para probarlo
Las iteraciones son el número de veces que realizas
una prueba modificando algunas condiciones
Cada tarea debes realizarla las veces que sean necesario
Así comprobarás la funcionalidad de cada una de sus partes
Es incremetnal porque no se puede pasar a la siguiente prueba sin haber terminado la anterior
Existen más modelos de prueba que se pueden adaptar al proyecto o a la arquitectura del sistema
4 - Clasificación de pruebas
Pruebas funcionales
Pueden aplicarse en cualquier NIVEL del proceso
Verifican que cada función del software opere en base a sus especificaciones
Validar tanto sus funciones principales como las de uso básico
Pruebas no funcionales
Pueden aplicarse en cualquier NIVEL del proceso
Deben realizarse después de las funcionales
Su objetivo es checar que el software funciona bien
Fiabildiad
Probabilidad de que un sistema, aparato o dispositivo cumpla una determinada
función bajo ciertas condiciones durante un tiempo determinado.
Rendimiento
Es la cantidad de trabajo realizado por un sistema informático.
Ejmeplo:
Tiempo de respuesta corto para una determinada pieza de trabajo.
Pruebas de caja blanca
Pruebas de estructura
Basadas en el código interno del software
Verifica los siguientes puntos
Fallas en la seguridad interna
Trayectorias mal estructuradas o rotas en los procesos de codificación
El flujo de los valores de entrada a través del código y los resultados esperados
La funcionalidad de los bucles condicionales
Con el objetivo de fortalecer
La seguridad
Mejorar el diseño
Usabilidad de los los sistemas
Verificar el conjunto de caminos independientes y
confeccionar casos de prueba que garanticen que se
verifican dichos caminos de ejecución
El camino independiente es que introduce por lo menos una nueva secuencia (arista en el grafo de
flujo) que no estaba considerada en el conjunto de caminos independientes ya calculados
Pruebas de caja negra
Verifican la funcionalidad del software
SIN examinar la estructura del código interno
Pasos
Reconoce los requerimientos y
especificaciones del software que probarás
Escoger los valores de entrada que son válidos e inválidos
Determina cuáles son las respuestas esperadas
para cada uno de los valores elegidos
Construye casos de prueba para los valores de entrada y ejecutalos
Compara las respuestas obtenidas con las esperadas y determinar si hay errores
Probar la funcionalidad del módulo sin disponer el código fuente
Intentar encontrar errores de ESTRUCTURAS de datos, INICIALIZACIÓN Y FINALIZACIÓN, RENDIMIENTO, interfaces E/S
En base a los parámetros de entrada y los resultados esperados de salida
Técnica de partición equivalente
Consiste en derivar casos de prueba mediante la división del dominio
de entrada en clases de equivalencia, evaluando su comportamiento
para un valor cualquiera representativo de dicha clase
Una clase de equivalencia representa al conjunto de estados válidos o inválidos
para todas las condiciones de entrada que satisfagan dicha clase
Nota:
Heurístico:
Técnica diseñada para resolver un problema más rápidamente cuando los métodos clásicos son demasiado lentos, o para encontrar una solución aproximada cuando los métodos clásicos no logran encontrar una solución exacta. Esto se logra intercambiando la optimización, la integridad, la precisión o la precisión por velocidad. En cierto modo, puede considerarse un atajo.
Repetición de pruebas y pruebas de regresión
Se ejecutan para confirmar que los cambios hechos en el
código no han afectado otras funciones
Estas variantes pueden incluir corrección de fallas
Cambios en el código
Nuevas características del software
Es necesario repetir una prueba para que un defecto ha sido corregido
5 - Métricas y mediciones
Métrica
Al conjunto de mediciones de un software
Con la finalidad de tener una idea clara sobre el estado actual
del producto y si existe una mejora en la corrección de errores
Tipos
Métricas de tamaño
Sirven para determinar la longitud del sw
Contando las líneas del código que lo forman
Métricas de calidad
Número de defectos encontrados en el producto
Métricas de seguridad
Para determinar si el sistema podrá resistir a ataques de acceso no autorizado
Definir métricas
1 - Definir un número limitado de métricas que sean útiles
Para evitar problemas de intepretación
2 - Se definen por metas
Para un proceso
Una tarea
Un componente
Un sistema
3 - Seguimiento y recopilación de métricas
Debe estar automatizado para reducir los tiempos de medición
4 - El uso de métricas te permitirá comunicar a tu
cliente y a tu equipo de trabajo información
importante