Actividad 20. MĂŠtodos de prueba en entornos especializados M.C. Juan Carlos Olivares Rojas Syllabus jcolivares@itesm.edu.mx June, 2009
Introducción
• Los ingenieros de software suelen encontrarse con entornos, arquitecturas y aplicaciones especializadas, la lo cual se puede recurrir a otras técnicas de prueba del software. • Pruebas de interfaces gráficas de usuario. Son conocidas también como GUI (por sus siglas en inglés), plantean desafíos interesantes a los ingenieros de software.
Introducción
• Prueba de arquitectura cliente/servidor. La arquitectura cliente/servidor representa un importante desafío para quienes prueban el software. • La naturaleza distribuida de los entornos cliente/servidor, los aspectos de desempeño relacionados con el proceso de transacción, la posible presencia de varias plataformas de hardware diferentes, la complejidad de la comunicación en red, etc. son la mayor complejidad de este sw.
Introducción
• Algunos enfoques de prueba que suelen encontrarse en aplicaciones cliente/servidor son: • Prueba de funcionalidad de la aplicación. La funcionalidad de las aplicaciones de cliente se prueba de manera independiente y utilizando cualquier técnica común de prueba.
Introducción
• Prueba de servidor. Se prueban las funciones de coordinación y manejo de datos del servidor. • Prueba de base de datos. Se prueba la exactitud e integridad de los datos almacenados en el servidor. • Pruebas de transacción. Se crea una serie de pruebas para asegurar que cada clase de transacciones se procesa de acuerdo con sus
Introducción
• Pruebas de transacción. Se crea una serie de pruebas para asegurar que cada clase de transacciones se procesa de acuerdo con sus requisitos. • Pruebas de comunicación de red. Con estas pruebas se verifica que la comunicación entre los nodos de la red ocurre de manera correcta y que el paso de mensajes, las transacciones y el tráfico de la red relacionado se realiza sin errores.
Introducción
• Prueba de la documentación y de las funciones de ayuda. Los errores en la documentación son tan devastadores para la aceptación del programa como los errores en los datos o el código fuente. La prueba de la documentación se aborda en dos fases: en la primera, revisión e inspección, se examina la claridad editorial del documento. En la segunda fase, prueba en vivo, se emplea la documentación junto con el programa real.
Introducción
• Prueba de sistemas de tiempo real. El diseñador de caso de prueba no sólo debe considerar los casos de prueba convencional, sino también el manejo de eventos, la temporización de los datos y el paralelismo entre las tareas o procesos que manejan los datos. Los métodos exhaustivos de diseño de casos de prueba para sistemas en tiempo real siguen evolucionando. Sin embargo, se puede seguir una estrategia de cuatro pasos:
IntroducciĂłn
• Prueba de tareas. El primer paso en la prueba del software en tiempo real consiste en probar cada tarea de manera independiente. • Prueba de comportamiento. Con el empleo de modelos del sistema creados con herramientas automatizadas es posible simular el comportamiento de un sistema en tiempo real y examinarlo como una consecuencia de eventos externos.
Introducción
• Prueba intertareas. Se prueban las tareas asincrónicas de las cuales se sabe que se comunican entre sí, empleando diferentes tasas de datos y cargas de procesamiento para determinar si ocurrirán errores de sincronización intertareas. • Prueba del sistema. El software y el hardware están integrados, de modo que se aplica un rango completo de pruebas del sistema para tratar de descubrir errores en la interfaz software/hardware.
Referencias
โ ข Curso de Proyecto Integrador de Software Bรกsico, Universidad TecMilenio, 2009
Questions?