- \u00darovne testovania<\/a><\/li>
- \u010co je integra\u010dn\u00e9 testovanie?<\/a><\/li>
- Pre\u010do by sme mali vykon\u00e1va\u0165 integra\u010dn\u00e9 testovanie?<\/a><\/li>
- V\u00fdhody integra\u010dn\u00e9ho testovania<\/a><\/li>
- Typy integra\u010dn\u00e9ho testovania<\/a><\/li>
- Big-bang integr\u00e1cia<\/a><\/li>
- Integra\u010dn\u00e9 testovanie zhora nadol (top-down integration testing)<\/a><\/li>
- Integra\u010dn\u00e9 testovanie zdola nahor (bottom-up integration testing)<\/a><\/li>
- Hybridn\u00e9 integra\u010dn\u00e9 testovanie<\/a><\/li>
- N\u00e1stroje na testovanie integr\u00e1cie<\/a><\/li><\/ul><\/div>\n
Niveles de pruebas<\/h2>\n\n
Los tipos de pruebas de software pueden dividirse a grandes rasgos en pruebas est\u00e1ticas y pruebas din\u00e1micas. En el caso de las pruebas est\u00e1ticas, no ejecutamos la aplicaci\u00f3n de software desarrollada, sino que utilizamos diversas t\u00e9cnicas para probar la aplicaci\u00f3n, como – comprobaciones, pruebas provisionales, revisiones informales y t\u00e9cnicas.<\/p>\n\n
En el caso de las pruebas din\u00e1micas, probamos la aplicaci\u00f3n de software ejecutando el c\u00f3digo y examinando su comportamiento din\u00e1mico, lo que implica analizar diversos par\u00e1metros, como el tiempo de respuesta, la utilizaci\u00f3n de la CPU, la utilizaci\u00f3n de la memoria, etc. Actualmente, las pruebas din\u00e1micas implican distintos niveles de pruebas que comienzan con las pruebas unitarias y contin\u00faan con las pruebas de integraci\u00f3n, del sistema y, por \u00faltimo, de aceptaci\u00f3n.<\/p>\n
\n![\"pruebas](\"https:\/\/ittester.sk\/wp-content\/uploads\/2023\/08\/dynamicke-testovanie-600-500.webp\")
pruebas din\u00e1micas – niveles<\/figcaption><\/figure>\n<\/div>\n Pruebas unitarias<\/strong>: es el primer nivel de las pruebas, en el que los m\u00f3dulos individuales o los bloques de construcci\u00f3n m\u00e1s peque\u00f1os de la aplicaci\u00f3n se prueban de forma aislada. La ventaja de esto es que, como s\u00f3lo nos centramos en m\u00f3dulos m\u00e1s peque\u00f1os, es m\u00e1s f\u00e1cil probar completa y exhaustivamente un m\u00f3dulo determinado. Adem\u00e1s, los errores detectados a este nivel pueden corregirse r\u00e1pida y f\u00e1cilmente con menos recursos.<\/p>\n\n
Pruebas de integraci\u00f3n<\/strong> – Este es el segundo nivel de pruebas que cubriremos en este art\u00edculo. Incluye la comprobaci\u00f3n de los m\u00f3dulos integrados en su conjunto junto con su interconexi\u00f3n.<\/p>\n\n
Pruebas del sistema<\/strong>: tercer nivel de pruebas en el que se realizan pruebas de extremo a extremo de toda la aplicaci\u00f3n. Ayuda a verificar los requisitos antes de la prueba final por parte del cliente.<\/p>\n\n
Pruebas de aceptaci\u00f3n<\/strong>: es el cuarto y \u00faltimo nivel de pruebas, en el que el cliente o las partes interesadas comprueban si la aplicaci\u00f3n cumple o no sus requisitos empresariales.<\/p>\n\n
Ahora que conocemos las pruebas est\u00e1ticas y din\u00e1micas y los distintos niveles de pruebas, podemos pasar a conocer en detalle las pruebas de integraci\u00f3n.<\/p>\n\n
\u00bfQu\u00e9 son las pruebas de integraci\u00f3n?<\/h2>\n\n
Las pruebas de integraci\u00f3n son el segundo nivel de pruebas que se realizan despu\u00e9s de las pruebas unitarias, en las que se comprueba la interconexi\u00f3n entre m\u00f3dulos junto con las pruebas de los componentes integrados. Puede realizarse utilizando t\u00e9cnicas de prueba de caja blanca y de caja negra.<\/p>\n\n
\u00bfPor qu\u00e9 debemos realizar pruebas de integraci\u00f3n?<\/h2>\n\n
- \n
- Un m\u00f3dulo puede funcionar perfectamente de forma aislada, pero puede tener problemas de integraci\u00f3n al interactuar con otro m\u00f3dulo. <\/li>\n\n\n\n
- Puede haber problemas con el tipo de datos o el rango de datos v\u00e1lido entre m\u00f3dulos. <\/li>\n\n\n\n
- En equipos grandes donde los m\u00f3dulos son creados por diferentes desarrolladores o incluso equipos, esto es muy necesario, ya que puede haber un desajuste en la comprensi\u00f3n de los diferentes desarrolladores.<\/li>\n<\/ul>\n\n
Ventajas de las pruebas de integraci\u00f3n<\/h2>\n\n
- \n
- Como ya se ha dicho, ayuda a identificar problemas de integraci\u00f3n entre m\u00f3dulos. <\/li>\n\n\n\n
- Ayuda a garantizar que los m\u00f3dulos integrados funcionan correctamente antes de pasar a probar la aplicaci\u00f3n en todo el sistema. <\/li>\n\n\n\n
- Los fallos detectados a este nivel son m\u00e1s f\u00e1ciles de resolver que los detectados en fases posteriores de las pruebas: pruebas del sistema y de aceptaci\u00f3n.<\/li>\n\n\n\n
- Mejora la cobertura de las pruebas y proporciona un nivel adicional de fiabilidad.<\/li>\n<\/ul>\n\n
Tipos de pruebas de integraci\u00f3n<\/h2>\n\n
conocemos 4 tipos:<\/p>\n\n
Integraci\u00f3n Big-bang<\/h2>\n\n
En una gran integraci\u00f3n, primero hay que completar todos los m\u00f3dulos y luego integrarlos. Tras la integraci\u00f3n, se realizan pruebas de la unidad integrada en su conjunto. Se diferencia de las pruebas del sistema porque aqu\u00ed las pruebas se centran en la interconexi\u00f3n\/comunicaci\u00f3n entre m\u00f3dulos.<\/p>\n\n
Ventaja<\/strong> – Es adecuado para proyectos m\u00e1s peque\u00f1os en los que se pueden desarrollar todos los m\u00f3dulos antes de iniciar las pruebas de integraci\u00f3n.<\/p>\n\n
Desventaja<\/strong> – Es muy dif\u00edcil de integrar, ya que no es pr\u00e1ctico ni conveniente tener todos los m\u00f3dulos listos antes de empezar las pruebas de integraci\u00f3n.<\/p>\n\n
Pruebas de integraci\u00f3n descendentes<\/h2>\n\n
La integraci\u00f3n descendente es un enfoque de pruebas de integraci\u00f3n incremental en el que el flujo de pruebas comienza desde los m\u00f3dulos de nivel superior (m\u00f3dulos m\u00e1s altos en la jerarqu\u00eda) hacia los m\u00f3dulos de nivel inferior. Como es muy probable que los m\u00f3dulos de nivel inferior no se desarrollen hasta que se inicien los de nivel superior, en esos casos se utilizan plugins (stubs).<\/p>\n\n
Los m\u00f3dulos proxy son m\u00f3dulos ficticios que simulan el funcionamiento de un m\u00f3dulo aceptando los par\u00e1metros recibidos por \u00e9ste y proporcionando un resultado aceptable. En general, los stubs tienen entradas y salidas codificadas que ayudan a probar otros m\u00f3dulos que se integran con \u00e9l.<\/p>\n\n
Ventaja<\/strong> – Con el uso de stubs no tenemos que esperar al desarrollo de todos los m\u00f3dulos. Tambi\u00e9n podemos dar prioridad a probar primero los m\u00f3dulos integrados cr\u00edticos.<\/p>\n\n
Desventaja<\/strong> – Esta t\u00e9cnica requiere la creaci\u00f3n de muchos m\u00f3dulos hijos para simular m\u00f3dulos de nivel inferior. Tambi\u00e9n puede ocurrir que los m\u00f3dulos de nivel inferior no est\u00e9n suficientemente probados.<\/p>\n\n
Pruebas de integraci\u00f3n ascendentes<\/h2>\n\n
La integraci\u00f3n ascendente tambi\u00e9n se basa en un enfoque incremental, partiendo de m\u00f3dulos de nivel inferior y ascendiendo hacia m\u00f3dulos de nivel superior. Una vez m\u00e1s, los m\u00f3dulos de nivel superior pueden no estar desarrollados en el momento en que se prueban los m\u00f3dulos de nivel inferior. En estos casos, se utilizan controladores. Estos controladores simulan la funcionalidad de m\u00f3dulos de nivel superior para probar m\u00f3dulos de nivel inferior.<\/p>\n\n
Ventaja<\/strong>: al igual que en las pruebas descendentes, no tenemos que esperar a que se desarrollen todos los m\u00f3dulos para empezar a probarlos.<\/p>\n\n
Desventaja<\/strong> – Los m\u00f3dulos de nivel superior que se prueban en fases posteriores pueden no estar suficientemente probados y contener errores.<\/p>\n\n
Pruebas de integraci\u00f3n h\u00edbridas<\/h2>\n\n
El enfoque de integraci\u00f3n h\u00edbrida tambi\u00e9n se denomina enfoque s\u00e1ndwich. Este enfoque es una combinaci\u00f3n de pruebas de integraci\u00f3n descendentes y ascendentes. En este enfoque, la integraci\u00f3n comienza en la capa intermedia y las pruebas se realizan en ambas direcciones: hacia los m\u00f3dulos de nivel superior (hacia arriba) y hacia los m\u00f3dulos de nivel inferior (hacia abajo). Este m\u00e9todo incorpora las ventajas de los enfoques descendente y ascendente, y ayuda a probar m\u00e1s r\u00e1pidamente las interfaces de los m\u00f3dulos.<\/p>\n\n
Ventaja<\/strong> – Como podemos movernos hacia arriba y hacia abajo, \u00e9ste es el m\u00e9todo m\u00e1s eficaz en cuanto al tiempo, con la posibilidad de priorizar m\u00f3dulos en el nivel superior o inferior.<\/p>\n\n
Inconveniente <\/strong>– este enfoque es dif\u00edcil de aplicar porque tenemos que integrar y desplazarnos en ambas direcciones del m\u00f3dulo sometido a prueba.<\/p>\n\n
Retos de las pruebas de integraci\u00f3n<\/strong><\/p>\n\n
- \n
- Dif\u00edcil de ejecutar<\/strong>: es muy dif\u00edcil de ejecutar en comparaci\u00f3n con las pruebas del sistema, en las que podemos considerar la aplicaci\u00f3n como una caja negra.<\/li>\n\n\n\n
- Lleva mucho tiempo<\/strong> – Probar todas las interconexiones entre los distintos m\u00f3dulos vinculados consume mucho tiempo y recursos.<\/li>\n\n\n\n
- Esfuerzo adicional<\/strong> – Requiere la creaci\u00f3n de subgrupos y controladores que, si no se crean correctamente, pueden dar lugar a pruebas inadecuadas.<\/li>\n<\/ul>\n\n
Herramientas de pruebas de integraci\u00f3n<\/h2>\n\n
Rational Integration Tester<\/strong> – Rational integration tester es una herramienta de pruebas de integraci\u00f3n de IBM. Proporciona un entorno sin c\u00f3digo para desarrollar pruebas de integraci\u00f3n.<\/p>\n\n
TESSY<\/strong> – Tessy, de Razorcat Development GmbH, ayuda a automatizar el ciclo de pruebas unitarias y de integraci\u00f3n del software embebido en C y C++.<\/p>\n\n
LDRA <\/strong>– El conjunto de herramientas LDRA proporciona capacidades de pruebas unitarias, de integraci\u00f3n y del sistema. Se utiliza sobre todo para aplicaciones de software cr\u00edticas, como: aeroespacial, dispositivos m\u00e9dicos, automoci\u00f3n, etc.<\/p>\n\n
Protractor<\/strong> – Protractor es un marco de pruebas de c\u00f3digo abierto para aplicaciones Angular y AngularJS que admiten secuencias de comandos Javascript.<\/p>\n\n
Pruebas de integraci\u00f3n<\/strong> de Citrus – Citrus es un marco de pruebas de c\u00f3digo abierto que ayuda a desarrollar pruebas de integraci\u00f3n automatizadas para protocolos y formatos de mensajes HTTP REST, TCP\/IP, SOAP, FTP, XML, JSON, etc.<\/p>\n\n
Steam <\/strong>– Steam es un marco de automatizaci\u00f3n de pruebas de c\u00f3digo abierto que proporciona pruebas de integraci\u00f3n sin cabeza.<\/p>\n\n
Jasmine <\/strong>– Jasmine es un marco BDD de c\u00f3digo abierto que puede utilizarse para automatizar cualquier aplicaci\u00f3n basada en Javascript.<\/p>\n","protected":false},"excerpt":{"rendered":"
Tradicionalmente, las pruebas de software se han considerado una forma de encontrar errores una vez […]<\/p>\n","protected":false},"author":8,"featured_media":2127,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[40],"tags":[],"class_list":["post-2125","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\/2125","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=2125"}],"version-history":[{"count":1,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts\/2125\/revisions"}],"predecessor-version":[{"id":2128,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts\/2125\/revisions\/2128"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/media\/2127"}],"wp:attachment":[{"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/media?parent=2125"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/categories?post=2125"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/tags?post=2125"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}
- Lleva mucho tiempo<\/strong> – Probar todas las interconexiones entre los distintos m\u00f3dulos vinculados consume mucho tiempo y recursos.<\/li>\n\n\n\n
- Dif\u00edcil de ejecutar<\/strong>: es muy dif\u00edcil de ejecutar en comparaci\u00f3n con las pruebas del sistema, en las que podemos considerar la aplicaci\u00f3n como una caja negra.<\/li>\n\n\n\n
- \u010co je integra\u010dn\u00e9 testovanie?<\/a><\/li>