Introducción a las pruebas de caja negra
Las técnicas de prueba de caja negra son un método que involucra la estructura interna, el diseño o la implementación del artículo que se va a probar. Las pruebas que se llevan a cabo pueden ser funcionales o no funcionales. Esto se conoce como prueba de caja negra, ya que la persona que prueba el sistema no conoce la estructura interna del código. El probador no sabe nada sobre los detalles de implementación y las rutas internas. La prueba se realiza completamente sobre la base de los requisitos y especificaciones de software que recibe el probador. El enfoque principal en esta prueba es la entrada y salida que se proporciona al sistema.
Técnicas de prueba de caja negra
Los casos de prueba que están diseñados para probar un sistema juegan un papel importante en la prueba. La forma en que se crean y los escenarios que cubren deben tenerse en cuenta. Los probadores pueden crear un documento de especificación de requisitos utilizando las siguientes técnicas:
- Partición de equivalencia
- Análisis de valor límite
- Prueba de tabla de decisiones
- Prueba de transición estatal
- Error Adivinando
- Métodos de prueba basados en gráficos
- Prueba de comparación
- Técnica de caso de uso
Las siguientes son las técnicas explicadas a continuación:
1. Pruebas de equivalencia
- Esta técnica divide los valores de entrada que se proporcionan al software en diferentes grupos o clases. Esto se hace sobre la base de la salida que vendrá como resultado. Esta técnica también se conoce como Particionamiento de clase de equivalencia. Al hacer esto, ahorramos el esfuerzo de dar diferentes entradas. En cambio, le damos un valor al grupo o clase para probar el resultado de ese grupo o clase. Esto ayuda a mejorar la cobertura de la prueba y, a su vez, reduce el retrabajo. El tiempo también se guarda ya que no se deben dar entradas separadas. La entrada para cada clase es suficiente.
- Tomemos un ejemplo de las calificaciones que obtienen los estudiantes. Si un estudiante obtiene un puntaje superior al 75%, entonces él / ella ha asegurado la Primera clase con Distinción. Del mismo modo, si el puntaje está entre 60% y 75%, entonces él / ella ha asegurado la Primera Clase. Si el puntaje está entre 50% y 60%, segunda clase. Si el puntaje está entre 40% y 50%, entonces pasa la clase, de lo contrario, falla. Aquí habrá cuatro clases. Estos casos de prueba se forman y se asegura de que todas las posibilidades estén cubiertas. Por lo tanto, la prueba con cualquier valor en este conjunto es suficiente.
2. Análisis del valor límite
- Aquí el foco está en los valores que están presentes en los límites. Esto se debe a que generalmente se encuentran muchos problemas cuando se trata de probar con valores que se centran en los límites. El límite se centra en valores cercanos al límite donde cambia el comportamiento del sistema. En el análisis del valor límite, se deben probar ambas entradas, que son válidas e inválidas.
- Por ejemplo, si queremos probar valores que oscilan entre 1 y 100, entonces deberíamos verificar si el programa funciona para valores como 1-1, 1 + 1, 1, 100-1, 100 + 1, etc. Esto ayuda en ahorrando tiempo nuevamente ya que solo podemos verificar valores como 0, 1, 2, 99, 100 y 101.
3. Prueba de tabla de decisiones
Siempre que existan condiciones lógicas o pasos para la toma de decisiones, se utilizará esta técnica. Estos pueden ser como si una condición particular no se cumple, entonces se debe realizar la Acción A, de lo contrario, se debe realizar la Acción B. El probador necesita identificar la entrada y las acciones que se realizarán según las condiciones. Se crea una tabla de decisión basada en estos. Considere un ejemplo en el que se permite un número impar de vehículos solo los lunes, miércoles, viernes y domingo, mientras que los vehículos de número par se permiten los martes, jueves y sábados. En este caso, hay dos condiciones y dos acciones. La condición 1 son vehículos impares y la condición 2 son vehículos pares. Las acciones son los días en que estos vehículos pueden estar en las carreteras. El número total de casos de prueba, en este caso, puede ser cuatro y, por lo tanto, la tabla de decisiones se puede derivar en consecuencia.
4. Prueba de transición estatal
En esta técnica, el caso de prueba intenta probar el sistema en diferentes estados. Este estado puede cambiar dependiendo de diferentes condiciones o eventos. Cuando ocurre un evento particular, estos escenarios pueden ser probados.
5. Error Adivinando
Esta técnica se basa principalmente en la experiencia. Una vez que un probador tiene experiencia trabajando en cualquier aplicación, conoce su comportamiento y funcionalidades. Esta es una manera a través de la cual se pueden encontrar muchos problemas. Al usar esta experiencia, es fácil para los evaluadores adivinar dónde la mayoría de los desarrolladores son propensos a cometer errores. Estos pueden manejar valores nulos, aceptar el botón de envío sin ningún valor, cargar un archivo sin ningún archivo adjunto, cargar un archivo con un tamaño inferior o superior al límite especificado, etc.
6. Pruebas basadas en gráficos
Cada aplicación se crea utilizando algunos objetos. Se anotan todos los objetos que se usan y se prepara un gráfico. A partir de este gráfico, se identifica la relación de cada objeto y los casos de prueba se escriben en consecuencia.
7. Pruebas de comparación
En esta técnica, se utilizan diferentes versiones del mismo software y luego se comparan para probar todo el sistema. El comportamiento se observa y se compara para todas las versiones y se observa cualquier desviación.
8. Técnica de caso de uso
Esta técnica se utiliza para identificar todos los casos de prueba en uso según el sistema. Se observan todos los escenarios que ayudan a comprender la funcionalidad completa de cada función de un extremo a otro. Los casos de prueba deben tener casos que cubran todos los escenarios de principio a fin según el uso del sistema.
Conclusión
La prueba de Black Box no entra en los detalles de la codificación. Se centra principalmente en probar y validar el comportamiento y la funcionalidad del software. No hay necesidad de antecedentes técnicos y las pruebas pueden iniciarse tan pronto como se complete el desarrollo del proyecto. Tanto los probadores como los desarrolladores pueden trabajar en silos. Es más efectivo para aplicaciones grandes donde la funcionalidad es más importante que el código. También ayuda a identificar defectos y problemas en la etapa inicial de las pruebas. Una vez que se realiza la nueva prueba, se puede verificar si los problemas persisten y el sistema se verifica nuevamente.
Artículos recomendados
Esta es una guía de las técnicas de prueba de Black Box. Aquí discutimos la Introducción a Black Box Testing, Técnicas y Técnicas Top 8 en Black Box. También puede consultar nuestros otros artículos sugeridos para obtener más información:
- Prueba de fuzz
- Pruebas negativas
- Prueba de tabla de decisiones
- Prueba de caja gris