Hispanopedia Wiki
Articulo de referencia

Pruebas 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 s...

Hispanopedia WikiContenido en espanolLectura gratuita

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 acceder a su estructura interna ni a su funcionamiento. Este método se puede aplicar prácticamente a todos los niveles de pruebas de software: unitarias , de integración , de sistema y de aceptación . Las pruebas de caja negra también se utilizan en las pruebas de penetración , donde un hacker ético simula un ataque de piratería informática o ciberataque externo sin conocer el sistema 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 requiere conocimiento específico del código de la aplicación, su estructura interna ni conocimientos generales de programación. [ 3 ] El evaluador sabe lo que se supone que debe hacer el software, pero desconoce cómo lo hace. Por ejemplo, el evaluador sabe que una entrada determinada produce una salida invariable, pero desconoce cómo el software genera dicha salida. [ 4 ]

Casos de prueba

Los casos de prueba se construyen en torno a las especificaciones y los requisitos , es decir, lo que se supone que debe hacer la aplicación. Generalmente, los casos de prueba se derivan de descripciones externas del software, incluidas las especificaciones, los requisitos y los parámetros de diseño. Si bien las pruebas utilizadas son principalmente funcionales , 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 prueba o un resultado previo que se sabe que es bueno, sin tener 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 , partición de equivalencia , análisis de valores límite , gráfico de causa-efecto , adivinación 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 que se ejecuta el código fuente de un programa cuando se ejecuta un conjunto de pruebas. [ 8 ] Medir la cobertura de pruebas permite detectar y eliminar rápidamente defectos, crear un conjunto de pruebas más completo y eliminar pruebas que no son relevantes para los requisitos dados. [ 8 ] [ 9 ]

Eficacia

Las pruebas de caja negra pueden ser necesarias para asegurar el correcto funcionamiento, pero son insuficientes 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. Cualesquiera que sean los sesgos que hayan tenido los programadores, es probable que el evaluador tenga un conjunto diferente y pueda enfatizar distintas áreas de funcionalidad. Por otro lado, se ha dicho que las pruebas de caja negra son "como caminar en un laberinto oscuro sin 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 garantía de calidad para software basado en componentes . Artech House. págs.  170–. ISBN 978-1-58053-735-3.
  2. ↑ Laycock, Gilbert T. (1993). The Theory and Practice of Specification Based Software Testing (PDF) (tesis doctoral). Departamento de Informática, Universidad de Sheffield . Recuperado 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.ª ed.). Indianápolis: Sams Publishing. ISBN  978-0672327988.
  5. ↑ Forgács, István; Kovács, Attila (2019). Diseño práctico de pruebas: Selección de técnicas de diseño de pruebas tradicionales y automatizadas . BCS Learning & Development Limited. ISBN 978-1780174723.
  6. ↑ Black, R. (2011). Pragmatic Software Testing: Becoming an Effective and Efficient Test Professional . John Wiley & Sons. pp. 44–6 . ISBN  978-1-118-07938-6.
  7. ↑ Glosario estándar de terminología de ingeniería de software de IEEE (Informe técnico). IEEE . 1990. 610.12-1990.
  8. 1 2 "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 mejores técnicas de cobertura de pruebas en pruebas de software" . ACCELQ Inc. Recuperado el 13 de abril de 2024 .
  10. ↑ Bach, James (junio de 1999). "Pruebas basadas en riesgos y requisitos" (PDF) . Computer . 32 (6): 113–114 . Archivado del original (PDF) el 29 de diciembre de 2009. Recuperado 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.
  • BCS SIGIST (British Computer Society Specialist Interest Group in Software Testing): Estándar para pruebas de componentes de software Archivado el 26/02/2021 en Wayback Machine , borrador de trabajo 3.4, 27 de abril de 2001.