Diseño y realización de pruebas

Depurador

Un depurador es un programa que ejecuta a otro programa (es decir, su código), lo que le permitirá ejercitar un nivel de control por encima del código mientras que se ejecuta, y examinar elementos particulares cuando las cosas salen mal

Procedimientos de pruebas y
casos de pruebas

Planificación de pruebas

Pruebas unitarias

Se realizan pruebas a nivel de objeto
y luego a nivel de paquete

Pruebas de integración

El objetivo es probar que el sistema en conjunto funcione correctamente

Pruebas de aceptación

Comprueba que se cumplan todos los requisitos
uno por uno, y si es estable o tiene fallos

Automatización de pruebas

Puede ser necesario automatizar las pruebas
o repetirlas tras realizar mantenimiento,
modificaciones o correcciones de software

Calidad del software

Puede ser orientado

Al usuario

Al sistema (uso de la CPU, carga de trabajo...)

Pruebas principales

Pruebas de cargas

Se realizan sobre el sistema simulando una serie de peticiones, evaluando los tiempos de respuestas de las transacciones

Pruebas de estrés

Se expone la aplicación a un número de usuario y transacciones extremas para ver cómo actúa

Pruebas de estabilidad

Se somete al programa a una carga determinada donde ka carga va cambiando

Factores de calidad

Facilidad de expansión

Modularidad

Tolerancia a errores

Estandarización de los datos

Procedimiento de pruebas

Un procedimiento de prueba es la definición del objetivo que desea conseguirse con las pruebas, qué es lo que va a probarse y cómo.

La ausencia de errores no significa que el software esté correcto, en muchas ocasiones se pide una interfaz determinada o que cumpla unas características

En los planes de prueba, se prueban los siguientes aspectos:

- Introducción, Módulos o partes del software a probar, Características del software por probar, Características del software que no lía de probarse, Enfoque de las pruebas, Criterio de validez o invalidez del software, Proceso de pruebas, Requerimientos del entorno, Homologación o aprobación del plan

Casos de pruebas

El objetivo de esta fase es encontrar fallos,
mediante la realización de pruebas

Es importante hacer buenas pruebas de errores, que no sean
ni muy sencillas ni muy complejas, ya que, si es muy sencilla es probable no encontrar errores y si es muy compleja es probable no encontrar el origen del error

Codificación y ejecución
de las pruebas

Una vez diseñados los casos de pruebas hay que generar
las condiciones necesarias para ejecutar estos casos. En muchos casos hay que usar datos disparatados o inválidos para ver las respuestas del sistema.

El tester se basa en la documentación existente (manual de usuario y otros manuales) para la realización de pruebas

Pruebas

Pruebas de caja
blanca

Pruebas de cubrimiento

El objetivo es ejecutar todas las sentencias o líneas del programa. Habrá que generar el número suficiente de casos de pruebas para poder cubrir los distintos caminos independientes del código

Prueba de condiciones

Se necesitan varios casos de prueba. Se asegura que cualquiera de las combinaciones de valores de la condición funcionará tal y como el programa fue concebido

Pruebas de bucles

La pruebas de bucles se basará en la repetición de un número especial de vece

Pruebas de caja
negra

Pruebas de clases de
equivalencia de datos

Para testear las interfaces, lo que debe hacerse es establecer
clases de equivalencia para cada uno de los campos. Tendrán
que crearse clases válidas y clases inválidas por cada uno de los campos

Pruebas de valores límite

El objetivo es generar valores que puedan probar si la interfaz
y el programa funcionan correctamente

Pruebas de interfaces

Una interfaz de usuario o GUI (graphical user interface), generalmente se testea con una técnica que se denomina prueba de interfaces

Tipos de pruebas

Funcionales

Buscan que los componentes software diseñados
cumplan con la función con la que fueron diseñados y desarrollados. Todos los sistemas tienen una serie de características con las que van a testearse

Estas pruebas se consideran de "caja negra". No se evalúa cómo el sistema funciona internamente, sino qué es lo que hace

Estructurales

Examinan de forma más detallada la arquitectura
de la aplicación

Son de "caja blanca", puesto que, se utilizan
técnicas de análisis de código. Normalmente
se utilizan herramientas especializadas para
este tipo de herramientas

Regresión

Estas pruebas intentan descubrir si existe algún error o problema tras las modificaciones. Estas pruebas solo se realizan en caso de una modificación de software. Que no aparezcan errores en esta prueba no significa que el programa esté exento de ellos

Se conoce o se tiene en cuenta
el código que quiere probarse

Aquellas que simplemente prueban la
interfaz sin tener en cuenta el código