stringtranslate.com

Prueba de caja negra

Las pruebas de caja negra, a veces denominadas pruebas basadas en especificaciones , [1] son ​​un método de prueba de software que examina la funcionalidad de una aplicación sin examinar sus estructuras o funcionamientos internos. Este método de prueba se puede aplicar prácticamente a todos los niveles de prueba de software: unidad , integración , sistema y aceptación . Las pruebas de caja negra también se utilizan como método en las pruebas de penetración , donde un hacker ético simula un ataque de piratería externa o de guerra cibernética sin saber que el sistema está siendo atacado.

Procedimientos de prueba

Las pruebas basadas en especificaciones tienen como objetivo probar la funcionalidad del software de acuerdo con los requisitos aplicables. [2] Este nivel de pruebas generalmente requiere que se proporcionen casos de prueba exhaustivos al evaluador, quien luego puede simplemente verificar que para una entrada dada, el valor de salida (o comportamiento), "es" o "no es" el mismo que el valor esperado especificado en el caso de prueba.

Ejemplo de un modelo de caja negra donde una determinada entrada produce una determinada salida

No se requieren conocimientos específicos del código de la aplicación, de su estructura interna ni de programación en general. [3] El evaluador sabe lo que se supone que debe hacer el software, pero no sabe cómo lo hace. Por ejemplo, el evaluador sabe que una entrada particular devuelve una salida determinada e invariable, pero no sabe cómo el software produce esa salida en primer lugar. [4]

Casos de prueba

Los casos de prueba se construyen en torno a especificaciones y requisitos , es decir, lo que se supone que debe hacer la aplicación. Los casos de prueba generalmente se derivan de descripciones externas del software, incluidas las especificaciones, los requisitos y los parámetros de diseño. Aunque las pruebas utilizadas son principalmente de naturaleza funcional , también se pueden utilizar pruebas no funcionales . El diseñador de pruebas selecciona entradas válidas e inválidas y determina la salida correcta, a menudo con la ayuda de un oráculo de pruebas o un resultado anterior que se sabe que es bueno, sin ningún conocimiento de la estructura interna del objeto de prueba.

Técnicas de diseño de pruebas

Las técnicas típicas de diseño de pruebas de caja negra incluyen pruebas de tabla de decisiones , pruebas de todos los pares , particionamiento de equivalencia , análisis de valor límite , gráfico de causa-efecto , conjetura de errores , pruebas de transición de estado , pruebas de casos de uso , pruebas de historias de usuario , análisis de dominio y pruebas de sintaxis. [5] [6]

Cobertura de pruebas

La cobertura de pruebas se refiere al porcentaje de requisitos de software que se prueban mediante pruebas de caja negra para un sistema o aplicación. [7] Esto contrasta con la cobertura de código , que examina el funcionamiento interno de un programa y mide el grado en el que se ejecuta el código fuente de un programa cuando se ejecuta un conjunto de pruebas. [8] La medición de la cobertura de pruebas permite detectar y eliminar rápidamente los defectos, crear un conjunto de pruebas más completo y eliminar las pruebas que no son relevantes para los requisitos dados. [8] [9]

Eficacia

Las pruebas de caja negra pueden ser necesarias para asegurar una funcionalidad correcta, pero no son suficientes para protegerse contra situaciones complejas o de alto riesgo. [10] Una ventaja de la técnica de caja negra es que no se requieren conocimientos de programación. Independientemente de los sesgos que puedan tener los programadores, es probable que el evaluador tenga un conjunto diferente y pueda enfatizar diferentes áreas de funcionalidad. Por otro lado, se ha dicho que las pruebas de caja negra son "como un paseo por un laberinto oscuro sin una linterna". [11] Debido a que no examinan el código fuente, hay situaciones en las que un evaluador escribe muchos casos de prueba para verificar algo que podría haberse probado con un solo caso de prueba o deja algunas partes del programa sin probar.

Véase también

Referencias

  1. ^ Jerry Gao; H.-SJ Tsao; Ye Wu (2003). Pruebas y control de calidad para software basado en componentes. Artech House. pp. 170–. ISBN 978-1-58053-735-3.
  2. ^ Laycock, Gilbert T. (1993). The Theory and Practice of Specification Based Software Testing (PDF) (tesis de disertación). Departamento de Ciencias de la Computación, Universidad de Sheffield . Consultado el 2 de enero de 2018 .
  3. ^ Milind G. Limaye (2009). Pruebas de software. Tata McGraw-Hill Education. pág. 216. ISBN 978-0-07-013990-9.
  4. ^ Patton, Ron (2005). Pruebas de software (2.ª edición). Indianápolis: Sams Publishing. ISBN 978-0672327988.
  5. ^ Forgács, István; Kovács, Atila (2019). Diseño de pruebas prácticas: selección de técnicas de diseño de pruebas tradicionales y automatizadas . ISBN 978-1780174723.
  6. ^ Black, R. (2011). Pruebas de software pragmáticas: cómo convertirse en un profesional de pruebas eficaz y eficiente. John Wiley & Sons. pp. 44–6. ISBN 978-1-118-07938-6.
  7. ^ Glosario estándar IEEE de terminología de ingeniería de software (informe técnico). IEEE . 1990. 610.12-1990.
  8. ^ ab "Cobertura de código vs. cobertura de pruebas". BrowserStack . Consultado el 13 de abril de 2024 .
  9. ^ Andrades, Geosley (16 de diciembre de 2023). "Las 8 principales técnicas de cobertura de pruebas en pruebas de software". ACCELQ Inc. Consultado el 13 de abril de 2024 .
  10. ^ Bach, James (junio de 1999). «Pruebas basadas en riesgos y requisitos» (PDF) . Computer . 32 (6): 113–114 . Consultado el 19 de agosto de 2008 .
  11. ^ Savenkov, Roman (2008). Cómo convertirse en probador de software . Roman Savenkov Consulting. pág. 159. ISBN 978-0-615-23372-7.

Enlaces externos