Las pruebas de Caja Negra.-
Dentro de los tipos de prueba existe una clasificación, que engloba la mayor parte de las pruebas de software, estas son las pruebas de caja blanca y las de caja negra. En este apartado conoceremos algunas pruebas ce caja negra y sus ámbitos de aplicación en los sistemas.
Las pruebas de caja negra llevan este nombre debido que el tester NO sabe lo que ocurre a nivel de código no puede ver nada dentro de la interfaz que se muestra y por lo tanto se pueden aplicar por personal calificado para la tarea de testing, que no necesariamente conoce de código. Las cajas negras pueden verse como un objeto que no sabes lo que pasa adentro, introduces unos datos, haces una serie de acciones y salen los datos procesados de alguna u otra manera. Los casos de prueba que aca se definen, viene dados por los requerimientos funcionales y no funcionales, pues estan orientadas a la funcionalidad del sistema o componente del sistema.
Hoy conoceremos 3 técnicas de pruebas de caja negra, que normalmente los programadores usan, pero poco conocen su teoria y aplicación.
Particiones de equivalencia:
Las particiones de equivalencia, permiten dividir los posibles valores en clases o grupos, donde SE ESPERA que el programa tenga UN COMPORTAMIENTO COMÚN. Estas clases de equivalencia no pueden suponerse, ni saltarse, deben tener una continuidad, bien sea dentro de un rango de valores, o de un valor aislado. Por ejemplo:
0 < x < 10 ó x = Verdadero
Dentro de las particiones de equivalencia podemos encontrar 2 clasificaciones mas:
Del formato correcto, pero un valor fuera del rango.
Del formato incorrecto.
Para efectos de las pruebas, es necesario un único representante de cada partición de equivalencia, ya que para cualquier valor dentro de la misma, se espera el mismo comportamiento.
Valores límite:
Este análisis amplía la técnica de las particiones de equivalencia, con una nueva regla que indica que los valores frontera, de cada clase de equivalencia, deben probarse de forma intensiva y minuciosa. Es frecuente que los límites no estén bien definidos en los rangos, o puedan conducir a distintas interpretaciones. Estas pruebas pueden ser aplicadas en todos los Niveles.
Los valores límite consideran la frontera y su entorno, para ello empleamos el siguiente esquema:
Límite inferior - x | Límite inferior | Límite inferior + x
Límite superior - x | Límite superior | Límite superior + x
Siendo ‘x’ el incremento mínimo definido para ese valor.
Pruebas basadas en casos de uso:
Este tipo de pruebas es empleado para probar un objeto completo, verlo como un sistema, que involucra ACTORES, PRECONDICIONES Y POSTCONDICIONES. Cuando definimos las pruebas mediante los casos de uso, estamos midiendo la reacción del sistema desde EL PUNTO DE VISTA DEL USUARIO, ya que describe como debe ser el comportamiento.
Normalmente cada caso de uso puede ser empleado como fuente de al menos UN caso de prueba y cada alternativa en el diagrama de caso de uso se considera un caso de prueba SEPARADO.
Ejemplo: Suponga el caso de uso, iniciar sesión de un sistema.- Tenemos 3 actores, Invitado, Administrador, Usuario no Autorizado.
Se definen los casos de prueba:
Invitado - No debe poseer credenciales, y ver una parte del sistema al que esté autorizado.
Administrador - Definimos más de un caso de prueba:
Sin credenciales,
Credenciales erradas,
Credenciales correctas,
Usuario no Autorizado - Definimos el comportamiento esperado, sea un mensaje o advertencia.
Las pruebas basadas en Casos de uso deben combinarse con otros métodos para definir casos de prueba, logrando así la mayor cobertura de casos.
