TALLER SEIS

PRUEBAS DE CAJA NEGRA

Las pruebas de caja negra comprenden todo tipo de tests que se ejecuten contra una       aplicación software sin conocimiento de cómo trabaja a nivel interno el módulo específico a   auditar.  Cuando esto se aplica a un producto software, el personal encargado de        ejecutar   las pruebas  únicamente conoce las entradas que debe introducir y las salidas  que debe esperar.

Este tipo de pruebas están enfocadas a los requisitos funcionales  del programa, ya que  no se requiere de ningún conocimiento añadido para ejecutarlas. De esta  forma, el          equipo de pruebas y el de desarrollo pueden ser totalmente independientes, lo que           permite  que el plan de pruebas pueda ser desarrollado una vez que este definido el         conjunto de requisitos de  la aplicación.

Ventajas

El personal de pruebas no necesita ningún conocimiento del lenguaje de programación     en el que está codificado el producto.

● El probador y el desarrollador son independientes el uno del otro.

● Las pruebas se realizan desde el punto de vista del usuario.

● Ayudan a encontrar inconsistencias y elementos ambiguos en las especificaciones.

● Los casos de pruebas son diseñados una vez que se termina de definir los requisitos.

Pruebas funcionales

Las pruebas funcionales se ocupan de evaluar cómo de bien el sistema a auditar ejecuta una  determinada función en el contexto en el que se le supone, incluyendo comandos de usuario,  manipulación de datos, búsquedas y procesos de negocio.

Pruebas de estrés

Un entorno de test de este tipo se establece definiendo distintos puntos de prueba. En      cada  punto se cuenta con un script que se ejecuta contra el sistema. Estos scripts normalmente están  basados en pruebas de regresión. Paulatinamente se van añadiendo más   puntos de pruebas que  probarán la aplicación hasta que el sistema incurra en algún fallo. 

Es común encontrar los siguientes errores en las pruebas de estrés:

● Condiciones de carrera: son conflictos entre dos o más tests.

●Pérdidas de memoria: ocurren cuando una prueba reserva una determinada memoria y  no la libera una vez acabada la ejecución.

Pruebas de carga

Este tipo de  pruebas operan en un nivel de carga predefinido, normalmente el más alto   que admite la aplicación.  Sin embargo, el objetivo no es provocar un fallo en la aplicación, sino mantener el sistema  funcionando con una alta carga de trabajo.

En este tipo de tests cobra gran importancia el contar con una base de datos de casos de prueba bastante extensa.

Pruebas a medida

Su objetivo consiste en que el personal de pruebas opere con total libertad a la hora de    utilizar la aplicación, de esta forma pueden explorarse vías de ejecución que no hayan      sido  contempladas en el plan de pruebas.

Pruebas de usabilidad

 Este tipo de tests suelen ejecutarse si el interfaz de la aplicación está en alta                     consideración y  existe uno específico para cada uno de los tipos de usuarios. Por ello, en estas pruebas se trabaja de  forma directa e indirecta con el usuario final para comprobar de qué manera perciben el software y  cómo interactúan con él.

PRUEBAS DE CAJA BLANCA

 Las pruebas de caja blanca están enfocadas principalmente hacia la lógica interna y la estructura del código de la aplicación. Esto implica que debe existir un conocimiento         suficiente de las tecnologías empleadas para desarrollar el software.

Las ventajas que comportan este tipo de pruebas son:

● Al tener que contar con un conocimiento determinado del código, es muy fácil encontrar qué tipo de entradas ayudan a probar la aplicación de forma efectiva.

● Ayuda en la optimización del código.

● Se evitan elementos innecesarios en las fuentes que pueden dar lugar a errores. Por contra, presentan las siguientes desventajas:

●Siendo el conocimiento de la tecnología un requisito fundamental, se incrementa el coste de las pruebas, ya que se necesita personal cualificado.

● Es imposible probar cada línea de código y ver si puede incurrir en algún fallo del sistema.

Pruebas unitarias

El   desarrollador   ejecuta   un   conjunto   de   pruebas   determinadas   para   comprobar módulo o unidad integrante de la aplicación está funcionando de forma correcta. El ámbitocomprenden este tipo de pruebas depende del desarrollador y de la arquitectura bajo la   que se encuentre el sistema.

Análisis estático

Consiste en analizar el código fuente con el fin de detectar cualquier posible defecto que haga incurrir en algún fallo.

Análisis dinámico

Este tipo de pruebas consisten a grandes rasgos en ejecutar el código y analizar las salidas que genera. Son el siguiente paso a dar después de un análisis estático del código.

Cobertura de sentencias Estos tests están enfocados de tal forma que toda sentencia que comprende la aplicación ejecutada  al  menos   una  vez.   Se  trata  de  una   aproximación   completa   al               funcionamiento   de  la aplicación.

Pruebas de seguridad

 Están enfocadas a comprobar cómo de bien el sistema está  protegido frente a distintas amenazas. Se considerará que el sistema es seguro si reúne las siguientes                       características:

● Integridad: La información sólo   puede ser modificada por quien está autorizado y de manera controlada.

● Confidencialidad: La información debe ser sólo legible para los usuarios autorizados.

● Disponibilidad: Debe ser disponible cuando se necesita.

● Irrefutabilidad: El uso y/o modificación de la información por parte del usuario debe ser irrefutable, es decir, que el usuario no pueda negar dicha acción. Pruebas de mutación En este tipo de pruebas los desarrolladores prueban una parte concreta del sistema después de haber ejecutado un cambio determinado en él.

TEST DE PERFORMANCE

Los tests de performance son aquellos que sirven para determinar qué tan rápido o qué tan bien se comporta un sistema sometido a una carga en particular. También pueden ser utilizados para validar y verificar otros requerimientos no funcionales del sistema como ser estabilidad, escalabilidad, disponibilidad o consumo de recursos.

Los tests de performance pueden buscar diferentes objetivos. Pueden servir para demostrar que un sistema cumple con determinado criterio de aceptación, para comparar dos sistemas y determinar cuál se comporta mejor o bien para detectar qué sistema externo o qué componente interno es el cuello de botella. Para el último caso, los tests de performance se pueden utilizar junto a profilers para medir y determinar cómo se distribuye el uso de recursos (tiempo, CPU, I/O, memoria, etc.) entre los diferentes componentes del sistema.

TEST DE ESTRES

Verificar que el sistema funciona apropiadamente y sin errores, bajo estas condiciones de stress:

• Memoria baja o no disponible en el servidor.
• Máximo número de clientes conectados o simulados (actuales o físicamente posibles)
• Múltiples usuarios desempeñando la misma transacción con los mismos datos.
• El peor caso de volumen de transacciones (ver pruebas de desempeño).
• La meta de las pruebas de stress también es identificar y documentar las condiciones bajo las cuales el sistema FALLA.

Las pruebas de stress se proponen encontrar errores debidos a recursos bajos o completitud de recursos. Poca memoria o espacio en disco puede revelar defectos en el sistema que no son aparentes bajo condiciones normales. Otros defectos pueden resultar de incluir recursos compartidos, como bloqueos de base de datos o ancho de banda de la red. Las pruebas de stress identifican la carga máxima que el sistema puede manejar.

TEST VOLUMEN

Verificar que la aplicación funciona adecuadamente bajo los siguientes escenarios de volumen:

Máximo (actual o físicamente posible) número de clientes conectados (o simulados), todos ejecutando la misma función (peor caso de desempeño) por un período extendido.

Máximo tamaño de base de datos (actual o escalado) y múltiples consultas ejecutadas simultáneamente

Ejemplos de escenarios de prueba de volúmenes:

1.    Un compilador puede ser alimentado por un programa para compilar que sea absurdamente grande.

2.    Un editor de nexos puede recibir un programa que contenga miles de módulos.

3.    Un simulador de circuito electrónico puede recibir un circuito diseñado con miles de componentes.

TEST DE SEDURIDAD

Nivel de seguridad de la aplicación: Verifica que un actor solo pueda acceder a las funciones y datos que su usuario tiene permitido.

Nivel de Seguridad del Sistema: Verificar que solo los actores con acceso al sistema y a la aplicación están habilitados para accederla.

Las pruebas de seguridad y control de acceso se centran en dos áreas claves de seguridad:

• Seguridad del sistema, incluyendo acceso a datos o Funciones de negocios y
• Seguridad del sistema, incluyendo ingresos y accesos remotos al sistema.

Pruebas

• Controles de acceso físico
• Acceso a estructuras de datos específicas a través de los programas de aplicación.
• Seguridad en sitios remotos
• Existencia de datos confidenciales en reportes y pantallas
• Controles manuales, incluyendo aquellos para autorización y aprobación, formularios,    

 documentación numerada, transmisión de datos, balances y conversión de datos.
 Controles automáticos, incluyendo aquellos para edición de datos, chequeo de máquinas, errores del operador, acceso a datos elementales y archivos, acceso a funciones, auditoría, entre otros.

TEST USABILIDAD

Determina cuán bien el usuario podrá usar y entender la aplicación. Identifica las áreas de diseño que hacen al sistema de difícil uso para el usuario.

La prueba de usabilidad detecta problemas relacionados con la conveniencia y practicidad del sistema desde el punto de vista del usuario.

Verificar que la aplicación no presenta los siguientes problemas de usabilidad típicos:

• El sistema es demasiado complejo y difícil de usar.
• Es difícil instalar y entender el sistema
• La recuperación de errores es pobre y los mensajes de error no tienen significado
• La sintaxis de los comandos es difícil de aprender y recordar
• El sistema obliga al usuario a recordar formatos y secuencias fijas
• Los procedimientos no son simples ni obvios
• El sistema no tiene instrucciones de ayuda por computadora y tiene manuales pobres.
• Los diagramas, pantallas, reportes y gráficos son de calidad y apariencia pobre
• El sistema carece de herramientas de construcción adecuadas y requiere múltiples comandos
• La lógica y conveniencia de los botones, switches, displays y mensajes de ayuda deben ser testeados. (La prueba de usabilidad puede ser conducida por un grupo separado si es posible.

TEST DE INSTALACION

Verificar y validar que el sistema se instala apropiadamente en cada cliente, bajo las siguientes condiciones:

· Instalaciones nuevas, nuevas máquinas a las que nunca se les ha instalado el sistema.

· Actualizar máquinas previamente instaladas con el sistema.

· Instalar versiones viejas en máquinas previamente instaladas con el sistema.

Las pruebas de instalación tienen dos propósitos. El primero es asegurar que el sistema puede ser instalado en todas las configuraciones posibles, tales como nuevas instalaciones, actualizaciones, instalaciones completas o personalizadas, y bajo condiciones normales o anormales; estas últimas incluyen insuficiente espacio en disco, falta de privilegios para algunas tareas, etc.

El segundo propósito es verificar que, una vez instalado, el sistema opera correctamente. Esto usualmente implica correr un número significativo de pruebas de Funcionalidad.

TEST DE DOCUMENTOS

Evaluar la exactitud y claridad de la documentación del usuario y para determinar si el manual de procedimientos trabajará correctamente como una parte integral del sistema.

Muchos defectos son identificados cuando un probador competente chequea totalmente los manuales y documentación del usuario.

Muchos programas son parte de sistemas mayores, no completamente automatizados, que contienen procedimientos realizados por operadores. Cualquier procedimiento humano, tal como los que llevan a cabo el operador, el administrador de la base de datos, o el usuario de terminal, debe ser probado durante la prueba de sistemas.

Revisar la documentación del proyecto contra las funcionalidades del sistema y su configuración física.

• Todas las pruebas planeadas han sido ejecutadas.
• Todos los defectos que se identificaron han sido tenidos en cuenta.