Prueba para entornos, arquitecturas y aplicaciones especializados

Prueba para entornos, arquitecturas y aplicaciones especializados

Annotations:

• En ocasiones, los lineamientos y enfoques únicos para pruebas se garantizan cuando se consideran entornos, arquitecturas y aplicaciones especializados.
• El objetivo principal para el diseño de casos de prueba es derivar un conjunto de pruebas que tienen la mayor probabilidad de descubrir errores en el software. Para lograr este objetivo, se usan dos categorías diferentes de técnicas de diseño de caso de prueba: pruebas de caja blanca y pruebas de caja negra.

1. Pruebas de interfaces gráficas de usuario

   Annotations:

   • Las interfaces gráficas para usuario (GUI, por sus siglas en inglés) presentan interesantes retos de prueba. Es posible usar las gráficas de modelado de estado finito para derivar una serie de pruebas que aborden objetos de datos y programa específicos que sean relevantes para la GUI.
2. Prueba de arquitecturas cliente-servidor

   Annotations:

   • En general, la prueba del software cliente-servidor ocurre en tres niveles diferentes: 1) las aplicaciones cliente individuales se prueban en un modo “desconectado”; no se considera la operación del servidor ni la red subyacente. 2) El software cliente y las aplicaciones servidor asociadas se prueban en concierto, pero las operaciones de red no se revisan de manera explícita. 3) Se prueba la arquitectura cliente-servidor completa, incluidos la operación de red y el rendimiento.
3. Documentación de prueba y centros de ayuda

   Annotations:

   • El término prueba de software invoca imágenes de gran número de casos de prueba preparados para revisar los programas de cómputo y los datos que manipulan.
4. Prueba para sistemas de tiempo real

   Annotations:

   • El diseñador de casos de prueba no sólo debe considerar los casos de prueba convencionales, sino también la manipulación de eventos (es decir, el procesamiento de interrupciones), la temporización de los datos y el paralelismo de las tareas (procesos) que manejan los datos.
   • Prueba de tareas. El primer paso en la prueba del software en tiempo real es probar cada tarea de manera independiente.
   • Prueba de comportamiento: Estas actividades de análisis pueden servir de base para el diseño de los casos de prueba que se realizan cuando se construye el software en tiempo real.
   • Prueba intertarea: Una vez aislados los errores en las tareas individuales y en el comportamiento del sistema, las pruebas se cambian a los errores relacionados con el tiempo
   • Prueba de sistema: Al integrar software y hardware, se lleva a cabo un amplio rango de pruebas del sistema con la intención de descubrir errores en la interfaz software hardware.
5. PATRONES PARA PRUEBAS DE SOFTWARE

   Annotations:

   • Los patrones también pueden usarse para proponer soluciones a otras situaciones de ingeniería de software; en este caso, prueba del software.
   • Proporcionan un vocabulario para quienes solucionan problemas. “Oiga, usted sabe, debemos usar un objeto nulo”.
   • Enfocan la atención en las fuerzas que hay detrás de un problema. Esto permite que los diseñadores de caso de prueba] entiendan mejor cuándo y por qué se aplica una solución.
   • Alientan el pensamiento iterativo. Cada solución crea un nuevo contexto en el que pueden resolverse nuevos problemas