Pruebas de Software

• Asignatura: Ingeniería de Software

• Carrera: Ingeniería en Informática /04

• Alumna: de Paula, Luisina Alejandra

• Matrícula: 65812

• Año: 2014

Pruebas de Software

• Las pruebas intentan demostrar que un programa hace lo que se intenta que haga.

• Al probar el software, se ejecuta un programa con datos artificiales

• El proceso de Prueba tiene dos metas distintas:

1- Demostrar al desarrollador y al cliente que el software cumple con los requerimientos. (Prueba de validación)

2- Encontrar situaciones donde el comportamiento del software sea incorrecto, indeseable o no esté de acuerdo con su especificación. (Pruebas de Defectos/Verificación).

Pruebas de Validación y Verificación

• Boehm planteó dos preguntas básicas para diferenciar los dos tipos de pruebas:

1- VALIDACIÓN: ¿Construimos el producto correcto?

2- VERIFICACIÓN: ¿Construimos bien (de manera correcta) el producto?

• “Las pruebas pueden mostrar sólo la presencia de errores, mas no su ausencia.” (Edsger Dijkstra)

Pruebas de Validación y Verificación

• El objetivo final de los procesos de verificación y validación es establecer confianza de que el sistema de software es “adecuado”.

• El nivel de confianza adquirido depende de:

1. Propósito del Software: Cuanto más crítico sea el software, más importante debe ser su confiabilidad.

2. Expectativas del usuario: A algunos usuarios no les sorprende que el sistema falle. (La necesidad de prueba es baja).

3. Entorno de Mercado: Se debe considerar el producto de la competencia (cuando un producto de software es comercializado).

Inspecciones

• Se enfocan principalmente en el código fuente de un sistema.

• Se utiliza conocimiento del sistema para descubrir errores.

• Ventajas sobre las pruebas:

• Durante las pruebas los errores pueden ocultar a otras fallas

• Las versiones incompletas se inspeccionan sin costos adicionales.

• No solo busca defectos, sino también aspectos de calidad (portabilidad, estándares y mantenibilidad).

Etapas donde se realizan pruebas e inspecciones

Etapas de pruebas

• Por lo general, un sistema de software comercial debe pasar por tres etapas de pruebas:

• Pruebas de desarrollo: El sistema se pone a prueba durante el proceso de desarrollo del software para descubrir errores (bugs) y defectos.

• Versiones de Prueba: Un equipo de prueba por separado experimenta una versión completa del sistema, antes de presentarlo a los usuarios.

• Pruebas de usuario: Donde los usuarios reales o potenciales de un sistema prueban el sistema en su propio entorno.

Pruebas de desarrollo

• Características:• Incluyen todas las actividades de prueba que realiza el equipo que elabora el

sistema. • El examinador del software puede ser el programador que diseñó dicho software.• Algunos procesos de desarrollo usan parejas de programador/examinador.• Durante el desarrollo, las pruebas se realizan en tres niveles:

1. Pruebas de Unidad: Se ponen a prueba unidades de programa o clases de objetos. Se comprueba la funcionalidad de objetos (clases) y métodos de cada uno de ellos.

2. Pruebas de Componente: Partes individuales del sistema se integran para crear componentes compuestos. (Interfaces)

3. Pruebas del sistema: Algunos o todos los componentes del sistema se integran y se prueba el comportamiento del sistema como un todo.

Pruebas de Unidad

• Cuando las pruebas de unidad evalúan los objetos o las clases, deben tener en cuenta:

• Probar todas las operaciones asociadas con el objeto.

• Establecer el valor o que tipo de datos irá en cada uno de los atributos del objeto o clase.

• Simular el objeto según todos los posibles estados que pueda tomar.

• Ejemplo:

•Para probar los estados de la estación meteorológica, se usa un modelo de estado. Hay que probar cualquier secuencia posible de transición de estado, aunque en la práctica ello resulte muy costoso. Por ejemplo:

Pruebas de Unidad

• Prueba de partición: Grupos de entradas con características comunes que se procesan de la misma forma.

Particiones de equivalencia

Pruebas de Componentes

• Se encarga de demostrar PRINCIPALMENTE que la interfaz entre los componentes de un sistema, se comportan según su especificación.

Prueba de interfaz

Tipos de errores de interfaz:

• Uso incorrecto de la interfaz

• Mala interpretación de la interfaz

• Errores de temporización

Pruebas de Componentes

• “Tips” (guidelines) para buenas pruebas de interfaz:

1. Examinar el código a probar y listar cada llamado de un componente a otro.

2. Donde existan punteros como parámetros, probar que sucede si el puntero es nulo.

3. Realizar pruebas donde falle a propósito un componente.

4. Prueba de esfuerzos donde se pasan mensajes. Generar mayor cantidad de mensajes que de costumbre para ver como reacciona el sistema.

5. Realizar que algunos componentes interactúen con memoria compartida. Establecer el orden correcto en que estos la usan y proponer órdenes adversos para ver como reaccionará el sistema.

Pruebas del Sistema

• Incluyen la integración de componentes para crear una versión del sistema y probarlo como un todo.

• Demuestran si los componentes son compatibles entre si y que transmiten datos correctos en el momento correcto.

• Se confunden con las pruebas de componentes, pero poseen diferencias:

1. En las pruebas del sistema los componentes reutilizables y los sistemas nuevos pueden integrarse.

2. Los componentes desarrollados por diferentes miembros de un equipo pueden integrarse.

Pruebas del Sistema

• Los casos de prueba son muy útiles para este tipo de pruebas

• Un diagrama de secuencia puede identificar las operaciones que se probarán

• Es difícil conocer que cantidad de pruebas que deben realizarse

• Las pruebas exhaustivas son prácticamente imposibles

• Ejemplos de pruebas del Sistema:

• Probar todas las funciones del sistema que partan de un menú.

• Experimentar combinación de funciones. (Por ejemplo: al apretar botón que se formatee el texto de los

Text Fields).

• Donde hayan entradas proporcionadas por el usuario, hay que probar como

responderán las funciones, tanto si son correctas como incorrectas.

Aviso de datos mal ingresados

Formateo de cuadros de texto al finalizar

acción

Desarrollo dirigido por pruebas (TDD)

• Características:

• TDD (Test-Driven Development).

• Se entrelazan el desarrollo de pruebas y el de código.

• El código se desarrolla incrementalmente, junto con la prueba para ese incremento.

• No se realiza el próximo incremento, sin haber probado el anterior.

• Se introdujo como parte de los métodos ágiles (Programación extrema)

Desarrollo dirigido por pruebas (TDD)

• Pasos para un TDD:1. Identificar el incremento de una funcionalidad a realizar.

2. Escribir una prueba para esta funcionalidad (automatizada).

3. Correr la prueba, junto con otras pruebas de otros incrementos.

4. Si falla, se implementa la funcionalidad y se vuelve a ejecutar la prueba.

5. Si todas las pruebas se realizan con éxito, se avanza a implementar la siguiente funcionalidad

Diagrama de un TDD básico

Desarrollo dirigido por pruebas (TDD)

• Ventajas:

• Cobertura de código: El código se prueba a medida que se escribe.

• Pruebas de regresión: Es posible volver atrás con las pruebas realizadas para demostrar que los cambios no introdujeron nuevos bugs.

• Depuración Simplificada: Cuando falla una prueba, es evidente donde está el problema. (Código recién escrito).

• Documentación del Sistema: Las pruebas en si actúan como una forma de documentación. Leer las pruebas suele facilitar la comprensión del código.

Pruebas de Versión

• Se pone a prueba una versión en particular del sistema.

• La versión puede ser para clientes, usuarios, otros equipos de desarrollo, etc.

• Las pruebas de versión y de sistema no son lo mismo:• Las pruebas de sistema se basan en las pruebas de Verificación/defectos.

• Las pruebas de versión, en el cumplimiento de requerimientos, es decir, pruebas de Validación.

• También se llaman “pruebas funcionales”.

• La principal meta es convencer al proveedor del sistema, que esté es suficientemente apto para su uso.

Pruebas de Versión

• Las pruebas de versión utilizan la ayuda de otros 3 tipos de prueba:

• Pruebas basadas en Requerimientos: • Los requerimientos deben ser comprobables.• Se pueden llevar a cabo mediante casos de prueba.• Cada requerimiento deriva de un conjunto de pruebas de éste. • Son pruebas de validación más que de verificación. • Se intenta demostrar que el sistema implementó adecuadamente sus requerimientos.

• Pruebas de Escenario:• Se crean escenarios típicos de uso.• Se utilizan casos de uso.• Un escenario describe una forma de usar el sistema.• Los escenarios deben ser realistas.• Los usuarios REALES deben relacionarse con ellos.

• Pruebas de Rendimientos:• Prueban el rendimiento y la confiabilidad.• Se diseñan para garantizar que el sistema procesa su carga pretendida.• En las pruebas se aumenta la carga hasta que el rendimiento del sistema sea inaceptable.• Demuestran que el sistema cumple con sus requerimientos y descubre nuevos errores• Construye perfiles operativos (conjunto de pruebas que reflejan la mezcla de trabajo que maneja el sistema)• Tienen dos funciones: Prueba el comportamiento de fallas del sistema, y lo fuerza a que salgan defectos difíciles de descubrir

Pruebas de Usuario

• Los usuarios o clientes proporcionan entrada y asesoría sobre las pruebas del sistema.

• Pueden haber pruebas formales o informales.

• El entorno de trabajo del usuario es SUMAMENTE importante, y causa efectos sobre la fiabilidad, rendimiento, uso, etc del sistema.

• En la práctica, hay tres tipos de pruebas de usuario:

• Pruebas alfa: Los usuarios trabajan con el equipo de desarrollo en conjunto.

• Pruebas beta: Una versión del software se pone a disposición de los usuarios para que experimenten y descubran problemas que no encontraron los desarrolladores.

• Pruebas de aceptación: Los clientes prueban el sistema para decidir si está o no listo para ser aceptado y usado.

Pruebas de Aceptación

• Se realizan sobre todo en sistemas personalizados.

• Se llevan a cabo generalmente después de las pruebas de versión.

• Implica la prueba formal del sistema por parte del cliente.

ACEPTACIÓN = PAGO POR EL SISTEMA

Pruebas de Aceptación

• Las pruebas de aceptación tienen 6 pasos:

1- Definir los criterios de aceptación: Se definen los criterios entre usuarios y desarrolladores antes de firmar el contrato

2- Plan de pruebas de aceptación: Se deciden los recursos, el tiempo y el presupuesto para las pruebas de aceptación.

3- Derivar pruebas de aceptación: Se diseñan pruebas para ver si el sistema es aceptable o no. Se dirige tanto a las características funcionales como no funcionales.

4- Correr pruebas de aceptación: Se ejecutan las pruebas. Debería ocurrir en el entorno real, pero sería poco posible.

5- Negociar los resultados de las pruebas: En caso que no se encuentren problemas, la prueba es concretada y el producto aceptado.

6- Rechazo/aceptación del sistema: El cliente y los desarrolladores deciden si aceptar o no el sistema.

• Pro

Proceso de prueba de aceptación

Cultura General…

• ¿Qué es JUnit?• Es un conjunto de bibliotecas que son utilizadas en programación para hacer

pruebas unitarias de aplicaciones Java. Permite realizar la ejecución de clases Java de manera controlada, para poder evaluar si el funcionamiento de cada uno de los métodos de la clase se comporta como se espera.

• En función de algún valor de entrada se evalúa el valor de retorno esperado; Si cumple, devolverá que la clase pasó la prueba, o viceversa si no lo hizo, adjuntando el fallo.

• También controla pruebas de regresión (parte del código se modificó y se ve si la nueva cumple con los requisitos anteriores).

• Netbeans y Eclipse cuentan con plugins que permiten que la generación de las plantillas necesarias para la creación de las pruebas de una clase Java se realice de manera automática.

Ejemplo en Netbeans:

• Test que se aplicó a un sistema de gestión de estudiantes en una universidad:

Ejemplo de Resultados Junit en Netbeans

¡GRACIAS!

¿PREGUNTAS?