Pruebas de software

Pruebas de software

Son los procesos que permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementación, calidad, o usabilidad de un programa de ordenador o videojuego. Básicamente es una fase en el desarrollo de software consistente en probar las aplicaciones construidas.

Las pruebas de software se integran dentro de las diferentes fases del ciclo del software dentro de la Ingeniería de software. Así se ejecuta un programa y mediante técnicas experimentales se trata de descubrir que errores tiene.

Proceso De Pruebas

Proceso de Pruebas

El proceso de pruebas involucra consideraciones similares al del proceso de desarrollo, incluyendo estrategias, actividades y métodos, los cuales deben ser aplicados de manera concurrente con el proceso de desarrollo de software.

1. ESTRATEGIA DE LA PRUEBA:

• Orden de Pruebas: Tienen como propósito definir en que momento y en que orden se aplicarán las pruebas. Diseño, implementación y operación del sistema. Existen dos enfoques generales para el orden en que se efectuarán las pruebas:

1. De arriba hacia abajo: Se deben desarrollar inicialmente las interfaces entre subsistemas, para probar protocolos de alto nivel antes de ir a probar los niveles inferiores.
2. De abajo hacia arriba: Certificar primero las unidades de bajo nivel y luego las interfaces entre ellos.

• Alcance de pruebas: Tiene como propósito identificar el tipo, número y casos de pruebas que se aplicarán para revisar los diferentes aspectos del sistema
• Automatización de la Prueba: Tiene como propósito reducir el esfuerzo y costo de las pruebas mediante automatización del proceso o aspectos de él.

         2. PLANEACION DE LA PRUEBA:

Comienza con el establecimiento de las estrategias de pruebas, lo que incluye la cuestión si estás se harán automática o manualmente y si existen programas y datos de prueba que puedan ser usados, posiblemente modificados o desarrollados de nueva cuenta

• Estrategia de la prueba
• Alcance de la prueba
• Recurso

          3. CONSTRUCCION DE LA PRUEBA:

Se describe cada prueba y su propósito de manera general y detallada. Se debe describir exactamente cómo se deberá ejecutar el caso de prueba, de manera que personas no familiarizadas con la aplicación puedan ejecutar el caso.

• Ambiente de desarrollo o real
• Tipo de software
• Tipo de hardware
• Equipo de prueba
• Versión del sistema

          4. EJECUCION DE LA PRUEBA:

Durante esta etapa se utiliza la especificación del diseño de prueba y los reportes de ésta.

• La estrategia es aplicar de manera paralela el mayor caso de pruebas posibles.
• Se Ejecutan las pruebas automáticas y manuales de manera correspondiente y se indican los resultados esperados.
• Si alguna prueba falla, se interrumpe su aplicación y se anota el resultado para luego analizar el defecto y corregirlo.

Pruebas De Unidad

PRUEBAS DE UNIDAD

Pruebas de procedimientos o subrutinas. En un sistema orientado a objetos se aplican en un nivel más alto, a partir de las clases. Una prueba de unidad consiste en una prueba estructural (o caja blanca), lo cual requiere conocer el diseño interno de la unidad, y una prueba de especificación(de caja negra, basada sólo en la especificación del comportamiento externamente visible de la unidad.


Tipos:

• Prueba de Especificación o de Caja Negra: Tiene como propósito verificar las relaciones de entrada y salida de una unidad. Su objetivo es verificar que hace la unidad, pero sin averiguar como lo hace.

• Prueba basada en estado: Verifica las interacciones entre operaciones de una clase según cambios en los atributos de un objeto. Es necesario hacer pruebas del objeto de acuerdo con su ciclo de vida.

• Prueba Estructural o de Caja Blanca: Verifica que la estructura interna de la unidad sea correcta.

Pruebas de validación
Las pruebas de validación en la ingeniería de software son el proceso de revisión que el sistema de software producido cumple con las especificaciones y que cumple su cometido. Es normalmente una parte del proceso de pruebas de software de un proyecto, que también utiliza técnicas tales como evaluaciones, inspecciones, y tutoriales. La validación es el proceso de comprobar lo que se ha especificado es lo que el usuario realmente quería.
Se trata de evaluar el sistema o parte de este durante o al final del desarrollo para determinar si satisface los requisitos iniciales. La pregunta a realizarse es: ¿Es esto lo que el cliente quiere?.

Señales de prueba determinísticas pruebas de sistemas.
Una señal de entrada del tipo escalón permite conocer la respuesta del sistema frente a cambios abruptos en su entrada. Así mismo, nos da una idea del tiempo de establecimiento de la señal, es decir, cuanto se tarda el sistema en alcanzar su estado estacionario. Otra de las características de esta señal es que producto de la discontinuidad del salto, contiene un espectro de frecuencia en una amplia banda lo cual hace que sea equivalente a aplicar al sistema una gran cantidad de señales senoidales con un intervalo de frecuencias grande. Matemáticamente, esta señal se expresa como: . Donde u(t):escalón unitario; A: constante
En la figura que se muestra a continuación (hay un error en la figura, el escalon comienza en 0, no en 1 en el eje x) A = 3 y

Prueba unitaria Es una forma de probar el correcto funcionamiento de un módulo de código.

Para que una prueba unitaria sea buena se deben cumplir los siguientes requisitos

Automatizable No debería requerirse una intervención manual.

Completas: deben cubrir la mayor cantidad de código

Repetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser ejecutadas una sola ves

Independientes: la ejecución de una prueba no debe afectar a la ejecución de otra

Profesionales: las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación

Ventajas

Su objetivo es aislar cada parte del programa y mostrar que las partes individuales son correctas

Simplifica la integración: permiten llegar a la fase de integración con un grado alto de seguridad de que el código está funcionando correctamente.

Documenta el código que ahí se puede ver cómo utilizarlo.

Separación de la interfaz y la implementación

Caja negra (sistemas)

Se denomina caja negra a aquel elemento que es estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras palabras, de una caja negra nos interesará su forma de interactuar con el medio que le rodea (en ocasiones, otros elementos que también podrían ser cajas negras) entendiendo qué es lo que hace, pero sin dar importancia a cómo lo hace. Por tanto, de una caja negra deben estar muy bien definidas sus entradas y salidas, es decir, su interfaz; en cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento.

Pruebas de regresión

Se denominan Pruebas de regresión a cualquier tipo de pruebas de software que intentan descubrir las causas de nuevos errores (bugs), carencias de funcionalidad, o divergencias funcionales con respecto al comportamiento esperado del software, inducidos por cambios recientemente realizados en partes de la aplicación que anteriormente al citado cambio no eran propensas a este tipo de error. Esto implica que el error tratado se reproduce como consecuencia inesperada del citado cambio en el programa.

Este tipo de cambio puede ser debido a prácticas no adecuadas de control de versiones, falta de consideración acerca del ámbito o contexto de producción final y extensibilidad del error que fue corregido (fragilidad de la corrección), o simplemente una consecuencia del rediseño de la aplicación.

Pruebas de Aceptación

Las pruebas de aceptación son definidas por el usuario del sistema y preparadas por el equipo de desarrollo, aunque la ejecución y aprobación final corresponden al usuario.

La validación del sistema se consigue mediante la realización de pruebas de caja negra que demuestran la conformidad con los requisitos y que se recogen en el plan de pruebas, el cual define las verificaciones a realizar y los casos de prueba asociados. Dicho plan está diseñado para asegurar que se satisfacen todos los requisitos funcionales especificados por el usuario teniendo en cuenta también los requisitos no funcionales relacionados con el rendimiento, seguridad de acceso al sistema, a los datos y procesos, así como a los distintos recursos del sistema.

Pruebas de rendimiento del software

Las pruebas de rendimiento son las pruebas que se realizan, desde una perspectiva, para determinar lo rápido que realiza una tarea un sistema en condiciones particulares de trabajo. También puede servir para validar y verificar otros atributos de la calidad del sistema, tales como la escalabilidad, fiabilidad y uso de los recursos. Las pruebas de rendimiento son un subconjunto de la ingeniería de pruebas, una práctica informática que se esfuerza por mejorar el rendimiento, englobándose en el diseño y la arquitectura de un sistema, antes incluso del esfuerzo inicial de la codificación.

ESTANDARES INTERNACIONALES

ESTÁNDARES INTERNACIONALES

1. ISO 9126:

Modelo de evaluación de calidad de software; aporta características sencillas de evaluación y medición.

- Modelo de calidad

- Métricas externas(Aseguramiento de calidad)

- Métricas internas(Desarrollo)

- Métricas de calidad en uso(Producto final)

2. BS 7935-2:

- Estándar británico para pruebas de componentes de software (Standard for software component testing)

- Describe técnicas para el diseño y medición de casos de prueba, trata la ejecución y análisis de los resultados, comparar y mejorar la calidad de la prueba.

3. IEEE 829:

Estándar para documentar pruebas de software. Especifica 8 etapas del proceso de documentación.

- planeación de las pruebas

- especificación del diseño de prueba

- especificación de los casos de prueba

- especificación del procedimiento

- reporte de avance de los cinco probados

- registro de la prueba

- reporte de incidentes

- sumario de la prueba

4. TPI (TEST PROCESS IMPROVEMENT):

Metodología para evaluar el nivel de madurez de pruebas en una organización, así como para mejorar el proceso