Las pruebas son esenciales en el desarrollo de software para garantizar la entrega de productos de software de alta calidad y sin errores. Los probadores utilizan diversas t\u00e9cnicas de prueba de software para identificar diversos problemas, fallos y errores en los productos de software. Una de ellas es la prueba de caja blanca. Se ocupa de la evaluaci\u00f3n de la estructura interna del software y de los detalles de implementaci\u00f3n. <\/p>\n\n
En este art\u00edculo, trataremos los aspectos b\u00e1sicos de las pruebas de caja blanca.<\/p>\n
La prueba de caja blanca es una t\u00e9cnica de prueba de software que comprueba el dise\u00f1o interno del sistema, la estructura del c\u00f3digo fuente, las estructuras de datos utilizadas y los detalles de funcionamiento. Su principal objetivo es mejorar el dise\u00f1o del software, el flujo de E\/S, la usabilidad y la seguridad. Tambi\u00e9n se llama prueba transparente, prueba estructural y prueba de caja de cristal. <\/p>\n\n
Poner en pr\u00e1ctica esta t\u00e9cnica de prueba requiere que los probadores est\u00e9n familiarizados con el c\u00f3digo del sistema, su arquitectura y los detalles de implementaci\u00f3n. Bas\u00e1ndose en estos conocimientos, crean casos de prueba y los ejecutan para verificar la correcci\u00f3n del sistema a nivel de c\u00f3digo. Por lo tanto, estas pruebas tambi\u00e9n se denominan pruebas basadas en el c\u00f3digo. <\/p>\n\n
En general, los desarrolladores realizan pruebas de caja blanca. Tener una comprensi\u00f3n completa del c\u00f3digo fuente y del funcionamiento interno del software. En algunos casos, sin embargo, tambi\u00e9n pueden realizarla expertos en control de calidad (QA) y probadores que entiendan el c\u00f3digo complejo. <\/p>\n\n
Esta t\u00e9cnica de prueba se denomina \u00abCaja Blanca\u00bb porque los desarrolladores o probadores observan el funcionamiento interno del sistema desde fuera de la caja. <\/p>\n\n
Se aplica en los dos primeros niveles de las pruebas de software: pruebas unitarias y pruebas de integraci\u00f3n. Las pruebas unitarias verifican cada m\u00f3dulo de software por separado. A continuaci\u00f3n, las pruebas de integraci\u00f3n conectan l\u00f3gicamente los m\u00f3dulos sometidos a prueba y comprueban su interacci\u00f3n o comunicaci\u00f3n.<\/p>\n\n
Las pruebas de caja blanca en las pruebas de software eval\u00faan el c\u00f3digo fuente del software para verificar los siguientes par\u00e1metros: <\/p>\n\n
En resumen, esta t\u00e9cnica de prueba verifica el flujo de trabajo del software. Consiste en proporcionar una serie de datos de entrada y comparar los resultados esperados y los reales. Si la salida real no coincide con la salida esperada, se produce un error o fallo.<\/p>\n\n
Generalmente, los desarrolladores o probadores verifican las aplicaciones utilizando esta t\u00e9cnica de prueba de software en dos pasos: <\/p>\n\n
Esto les ayudar\u00e1 a crear casos de prueba eficaces para descubrir posibles vulnerabilidades de seguridad y garantizar el m\u00e1ximo porcentaje de cobertura de las pruebas.<\/p>\n\n
Ahora sabemos que el objetivo de las pruebas de caja blanca es verificar la estructura del c\u00f3digo, como las sentencias de bucle, las sentencias condicionales, las ramas de decisi\u00f3n, etc. Lo entenderemos con un ejemplo sencillo:<\/p>\n\n
Prueba (a, b)\n{\nint n;\nsi (n % 2 ==0)\n{\nprint(\"N\u00famero impar\")\n}\nsi no\n{\nprint(\"N\u00famero impar\")\n}\n}<\/pre>\n\nPara verificar este c\u00f3digo, tenemos los dos casos de prueba siguientes: <\/p>\n\n
Para el primer caso de prueba, n = 25, no se aplica la condici\u00f3n \u00absi\u00bb. Por lo tanto, el flujo del programa pasa al bloque \u00abelse\u00bb e imprime la declaraci\u00f3n que contiene. En el segundo caso de prueba, n = 50, la condici\u00f3n \u00absi\u00bb es verdadera y se ejecuta la declaraci\u00f3n que contiene. <\/p>\n\n
De este modo, las pruebas de caja blanca recorr\u00edan cada l\u00ednea del c\u00f3digo fuente de la aplicaci\u00f3n y descubr\u00edan posibles fallos a nivel de c\u00f3digo. <\/p>\n\n
Los distintos tipos de t\u00e9cnicas de prueba de caja blanca son los siguientes: <\/p>\n\n
1. Cobertura de la declaraci\u00f3n<\/strong><\/p>\n\n Esta t\u00e9cnica requiere que repases y pruebes cada declaraci\u00f3n del c\u00f3digo fuente al menos una vez. Como resultado, se ejercita todo el c\u00f3digo fuente. <\/p>\n\n La cobertura de sentencias determina el porcentaje de c\u00f3digo fuente que ejercitar\u00e1 un determinado conjunto de casos de prueba. La f\u00f3rmula para cubrir las declaraciones es <\/p>\n\n Cobertura de declaraciones = (n\u00famero de declaraciones realizadas \/ n\u00famero total de declaraciones) * 100<\/strong><\/p>\n\n 2. Cobertura de decisiones\/cobertura de sucursales<\/strong><\/p>\n\n El mejor ejemplo de rama (punto de decisi\u00f3n) en programaci\u00f3n es la sentencia \u00absi\u00bb. Tiene dos ramas: Verdadero y Falso. La t\u00e9cnica de cobertura de ramas garantiza que cada rama del c\u00f3digo fuente se ejecute al menos una vez.<\/p>\n\n Por cobertura de ramas se entiende el porcentaje de ramas o puntos de decisi\u00f3n ejecutados durante las pruebas.<\/p>\n\n Cobertura de ramas = (n\u00famero de ramas implementadas \/ n\u00famero total de ramas) * 100%<\/strong><\/p>\n\n 3. Cobertura de condiciones<\/strong><\/p>\n\n La prueba de condiciones consiste en probar cada condici\u00f3n para obtener resultados tanto VERDADEROS como FALSOS. Por tanto, para obtener una cobertura estatal del 100% es necesario aplicar cada condici\u00f3n tanto para los resultados VERDADEROS como para los FALSOS. Para n condiciones tendremos 2n guiones de prueba.<\/p>\n\n El objetivo principal de la cobertura de condiciones es determinar la salida de cada condici\u00f3n en el c\u00f3digo fuente. Sin embargo, s\u00f3lo comprueba las condiciones con operandos l\u00f3gicos cuyo resultado sea verdadero o falso.<\/p>\n\n 4. Pruebas multicondici\u00f3n<\/strong><\/p>\n\n Su objetivo es probar todas las combinaciones posibles de cada estado de la rama. Vamos a entenderlo con un ejemplo.<\/p>\n\n Los casos de prueba para el c\u00f3digo anterior ser\u00e1n<\/p>\n\n A=TRUE, B=TRUE<\/p>\n\n A=VERDADERO, B=FALSO<\/p>\n\n A=FALSO, B=VERDADERO<\/p>\n\n A=FALSO, B=FALSO<\/p>\n\n Nuestro ejemplo tiene 2 condiciones -A y B- y 4 casos de prueba. Si hubiera 3 expresiones, el n\u00famero de casos de prueba ser\u00eda 8.<\/p>\n\n Por tanto, para una cobertura del 100% tendremos 2n guiones de prueba. Esto es muy agotador y es muy dif\u00edcil conseguir una cobertura del 100%.<\/p>\n\n 5. Pruebas de trayectoria<\/strong><\/p>\n\n La prueba de rutas garantiza que todas las rutas posibles del c\u00f3digo fuente se ejecuten al menos una vez. Consiste en crear un diagrama de flujo de control utilizando el c\u00f3digo fuente o un diagrama de flujo. Despu\u00e9s, determina la complejidad ciclom\u00e1tica, que se refiere a los caminos independientes. As\u00ed, los probadores crean casos de prueba m\u00ednimos para esas rutas independientes. <\/p>\n\n Cobertura del viaje = (n\u00famero de viajes realizados \/ n\u00famero total de viajes del programa) x 100 %.<\/strong><\/p>\n\n 6. Comprobaci\u00f3n de los ciclos del bucle<\/strong><\/p>\n\n Los ciclos son construcciones de programa comunes y se utilizan en la mayor\u00eda de los programas grandes. Las pruebas de ciclo son esenciales porque existe una alta probabilidad de que se produzcan errores al principio o al final de un ciclo. Por lo tanto, la realizaci\u00f3n de pruebas revela errores o fallos en cualquier ciclo concreto. El principal error que se produce en los ciclos son los \u00edndices incorrectos.<\/p>\n\n He aqu\u00ed los distintos tipos de pruebas de caja blanca: <\/p>\n\n Pruebas unitarias:<\/strong> es el primer nivel de las pruebas de software. Comprueba individualmente la correcci\u00f3n de cada m\u00f3dulo de la aplicaci\u00f3n, llamado unidad. Garantiza que cada componente funcione como se espera de \u00e9l.<\/p>\n\n Pruebas de integraci\u00f3n:<\/strong> son posteriores a las pruebas unitarias. Combina los componentes individuales probados l\u00f3gicamente y confirma la interacci\u00f3n entre ellos. Su objetivo es detectar cualquier error en la interacci\u00f3n de los componentes. <\/p>\n\n Pruebas de penetraci\u00f3n de caja blanca: <\/strong>los probadores tienen pleno acceso al c\u00f3digo fuente de la aplicaci\u00f3n y a los datos de la red, la IP y el servidor, incluidas las contrase\u00f1as y los mapas. El objetivo principal de las pruebas de penetraci\u00f3n es detectar \u00e1reas del c\u00f3digo fuente con puntos d\u00e9biles de seguridad. <\/p>\n\n Pruebas de mutaci\u00f3n de caja blanca:<\/strong> como su nombre indica, las pruebas de mutaci\u00f3n dependen de los cambios. Los probadores realizan peque\u00f1as modificaciones en el c\u00f3digo fuente para comprobar que la ejecuci\u00f3n de los casos de prueba no revela ning\u00fan error. Si los casos de prueba tienen \u00e9xito, esto indica un error en el c\u00f3digo fuente. Sin embargo, si los casos de prueba fallan, el c\u00f3digo fuente no tiene errores.<\/p>\n\n Aclaremos ahora las ventajas e inconvenientes de las pruebas de caja blanca. <\/p>\n\n Aqu\u00ed tienes una lista de algunas herramientas de prueba de caja blanca de uso com\u00fan: <\/p>\n\n La siguiente tabla destaca las principales diferencias entre las pruebas de armarios blancos y negros:<\/p>\n\n La prueba de caja blanca es una t\u00e9cnica de prueba de software que requiere que los probadores conozcan a fondo el funcionamiento interno y la estructura del c\u00f3digo de una aplicaci\u00f3n. Por tanto, revela lagunas estructurales y de seguridad. El objetivo principal es verificar la funcionalidad y correcci\u00f3n de la aplicaci\u00f3n a nivel de c\u00f3digo. <\/p>\n\n Aunque esta t\u00e9cnica de comprobaci\u00f3n requiere mucho tiempo y esfuerzo, es la \u00fanica forma de asegurarte de que compruebas cada l\u00ednea de tu c\u00f3digo fuente. Si se hace correctamente, las pruebas de caja blanca mejorar\u00e1n mucho la calidad del software.<\/p>\n","protected":false},"excerpt":{"rendered":" Las pruebas de caja blanca comprueban el dise\u00f1o interno del sistema, la estructura del c\u00f3digo fuente, las estructuras de datos utilizadas y los detalles de funcionamiento. <\/p>\n","protected":false},"author":8,"featured_media":2120,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[40],"tags":[],"class_list":["post-2119","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-pruebas-manuales"],"acf":[],"aioseo_notices":[],"_links":{"self":[{"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts\/2119","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/users\/8"}],"replies":[{"embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/comments?post=2119"}],"version-history":[{"count":1,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts\/2119\/revisions"}],"predecessor-version":[{"id":2121,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts\/2119\/revisions\/2121"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/media\/2120"}],"wp:attachment":[{"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/media?parent=2119"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/categories?post=2119"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/tags?post=2119"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}si (A||B) \nimprimir C<\/pre>\n\n
Tipos de pruebas de caja blanca<\/h2>\n\n
Ventajas e inconvenientes de las pruebas de caja blanca <\/h2>\n\n
Beneficios <\/h2>\n\n
\n
Desventajas <\/h2>\n\n
\n
Herramientas de prueba de caja blanca <\/h2>\n\n
\n
La diferencia entre las pruebas de caja blanca y de caja negra<\/h2>\n\n
Pruebas de caja blanca<\/strong><\/td> Pruebas de caja negra<\/strong><\/td><\/tr> Requiere conocer la estructura interna y el funcionamiento de la aplicaci\u00f3n.<\/td> No se requiere ning\u00fan conocimiento interno de la aplicaci\u00f3n.<\/td><\/tr> Podemos probar muchos aspectos detallados de la aplicaci\u00f3n.<\/td> Estamos probando la funcionalidad integral de la aplicaci\u00f3n.<\/td><\/tr> Estas pruebas las realizan desarrolladores o profesionales de control de calidad con buenos conocimientos de programaci\u00f3n y arquitectura de aplicaciones.<\/td> De las pruebas de caja negra se encarga un equipo independiente de control de calidad.<\/td><\/tr> Se aplica a los niveles inferiores de las pruebas: pruebas unitarias y pruebas de integraci\u00f3n.<\/td> Se aplica a los niveles superiores de las pruebas: las pruebas del sistema y las pruebas de aceptaci\u00f3n, en las que tenemos que probar la aplicaci\u00f3n en su conjunto.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n Conclusi\u00f3n<\/h2>\n\n