{"id":2129,"date":"2023-08-23T15:28:40","date_gmt":"2023-08-23T13:28:40","guid":{"rendered":"https:\/\/ittester.sk\/sin-categorizar\/prueba-del-sistema\/"},"modified":"2024-07-04T06:38:07","modified_gmt":"2024-07-04T04:38:07","slug":"prueba-del-sistema","status":"publish","type":"post","link":"https:\/\/ittester.sk\/es\/pruebas-manuales\/prueba-del-sistema\/","title":{"rendered":"Pruebas del sistema"},"content":{"rendered":"<div class=\"wp-block-aioseo-table-of-contents\"><ul><li><a class=\"aioseo-toc-item\" href=\"#aioseo-co-je-systemove-testovanie\">\u010co je syst\u00e9mov\u00e9 testovanie?<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-priklad-testovania-systemu\">Pr\u00edklad testovania syst\u00e9mu<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-preco-pri-testovani-softveru-potrebujeme-systemove-testovanie\">Pre\u010do pri testovan\u00ed softv\u00e9ru potrebujeme syst\u00e9mov\u00e9 testovanie?<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-co-overovat-pri-testovani-systemu\">\u010co overova\u0165 pri testovan\u00ed syst\u00e9mu?<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-vstupne-a-vystupne-kriteria\">Vstupn\u00e9 a v\u00fdstupn\u00e9 krit\u00e9ri\u00e1<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-typy-testovania-systemu\">Typy testovania syst\u00e9mu<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-proces-testovania-systemu\">Proces testovania syst\u00e9mu<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-vyhody-a-nevyhody-testovania-systemu\">V\u00fdhody a nev\u00fdhody testovania syst\u00e9mu<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-systemove-testovanie-vs-akceptacne-testovanie\">Syst\u00e9mov\u00e9 testovanie vs. akcepta\u010dn\u00e9 testovanie<\/a><\/li><li><a class=\"aioseo-toc-item\" href=\"#aioseo-zaver\">Z\u00e1ver<\/a><\/li><\/ul><\/div>\n<p>Las pruebas de software son una actividad cuyo objetivo es detectar posibles errores y fallos en las aplicaciones de software antes de que se pongan a disposici\u00f3n de los usuarios finales. Tiene lugar en cuatro niveles diferentes: pruebas unitarias, pruebas de integraci\u00f3n, pruebas del sistema y pruebas de aceptaci\u00f3n. En este art\u00edculo, examinaremos en detalle las pruebas del sistema.  <\/p>\n\n<p>Antes, sin embargo, es esencial conocer los distintos niveles de las pruebas de software.  <\/p>\n\n<p><strong>\n  <a href=\"https:\/\/ittester.sk\/es\/pruebas-manuales\/pruebas-unitarias\/\" title=\"\">Pruebas unitarias<\/a>\n<\/strong> &#8211; Consiste en probar cada componente del software por separado para asegurarse de que funciona correctamente. Generalmente, los desarrolladores o programadores realizan pruebas unitarias durante la fase de desarrollo del SDLC.  <\/p>\n\n<p><strong>\n  <a href=\"https:\/\/ittester.sk\/es\/pruebas-manuales\/pruebas-de-integracion\/\" title=\"Pruebas de integraci&#xF3;n\">Pruebas de integraci\u00f3n<\/a>\n<\/strong> &#8211; Siguen las pruebas de integraci\u00f3n. Combina l\u00f3gicamente los componentes de las pruebas unitarias en grupos y verifica su interacci\u00f3n. Detecta los errores que puedan surgir debido a la interacci\u00f3n de los m\u00f3dulos de software.  <\/p>\n\n<p><strong>Pruebas del sistema<\/strong> &#8211; Cuando todo el sistema est\u00e1 conectado e integrado en una sola unidad, se eval\u00faa como un todo. El objetivo es comprobar el sistema desde el punto de vista del usuario.  <\/p>\n\n<p><strong>\n  <a href=\"https:\/\/ittester.sk\/es\/pruebas-manuales\/pruebas-de-aceptacion\/\" title=\"Pruebas de aceptaci&#xF3;n\">Pruebas de aceptaci\u00f3n<\/a>\n<\/strong> &#8211; El \u00faltimo nivel son las pruebas de aceptaci\u00f3n. Un peque\u00f1o grupo de usuarios reales o el equipo interno de la organizaci\u00f3n comprueba que el producto de software cumple todos los requisitos especificados.  <\/p>\n\n<p>Pasemos ahora a una comprensi\u00f3n detallada de las pruebas del sistema.<\/p>\n\n<h2 class=\"wp-block-heading\" id=\"aioseo-co-je-systemove-testovanie\">\u00bfQu\u00e9 es la prueba del sistema?<\/h2>\n\n<p>La prueba de sistemas es un tipo de prueba de software que eval\u00faa un producto de software en su conjunto bas\u00e1ndose en requisitos funcionales y no funcionales. Determina el rendimiento y la funcionalidad generales de un producto de software totalmente integrado.  <\/p>\n\n<p>El objetivo principal de este tipo de pruebas es comprobar que todos los componentes del software funcionan juntos sin errores y que funcionan como deben, cumpliendo todos los requisitos especificados. Se ocupa de la verificaci\u00f3n del dise\u00f1o del producto de software, su comportamiento y el cumplimiento de los requisitos del cliente.  <\/p>\n\n<p>El equipo de control de calidad realiza pruebas del sistema despu\u00e9s de las pruebas de integraci\u00f3n y antes de las pruebas de aceptaci\u00f3n. Eligen un entorno de prueba que se parezca mucho a un entorno de producci\u00f3n real. Como el equipo de control de calidad est\u00e1 probando todo el sistema sin conocer su funcionamiento interno, entra dentro de las pruebas de caja negra.  <\/p>\n\n<p>Los m\u00f3dulos integrados que han superado las pruebas de integraci\u00f3n sirven de entrada para las pruebas del sistema. Las pruebas de integraci\u00f3n detectan errores o incoherencias entre las unidades integradas. Sin embargo, las pruebas del sistema revelan errores entre las unidades integradas y el sistema completo.<\/p>\n\n<p>En resumen, este tipo de prueba de software consiste en ejecutar una serie de pruebas para comprobar todo el software.<\/p>\n\n<h2 class=\"wp-block-heading\" id=\"aioseo-priklad-testovania-systemu\">Ejemplo de prueba del sistema<\/h2>\n\n<p>Tomemos un ejemplo del mundo real. Piensa en el proceso de fabricaci\u00f3n de un coche. Al principio, el fabricante del coche fabrica todos los componentes b\u00e1sicos, como los frenos, el motor, los asientos, la direcci\u00f3n, las ruedas, etc. Tras la producci\u00f3n de estos componentes, llega el momento de probarlos individualmente, lo que en desarrollo de software se denomina prueba unitaria.  <\/p>\n\n<p>Una vez confirmada la funcionalidad de todos estos componentes individuales, el fabricante los ensamblar\u00e1. El siguiente paso es comprobar que la combinaci\u00f3n ensamblada no provoca ning\u00fan error ni tiene efectos secundarios en la funcionalidad de los componentes individuales. Denominamos a este procedimiento pruebas de integraci\u00f3n.  <\/p>\n\n<p>Tras asegurarse de que no hay errores entre la combinaci\u00f3n ensamblada, el fabricante comprueba la combinaci\u00f3n en su conjunto, lo que constituye la prueba del sistema. El veh\u00edculo en su conjunto se somete a una serie de comprobaciones para verificar que cumple los requisitos especificados, por ejemplo, que el veh\u00edculo funciona suavemente, que todos los dem\u00e1s componentes (frenos, caja de cambios, ruedas, etc.) funcionan correctamente.  <\/p>\n\n<p>Si el veh\u00edculo cumple las expectativas de los clientes, es m\u00e1s probable que lo compren.  <\/p>\n\n<h2 class=\"wp-block-heading\" id=\"aioseo-preco-pri-testovani-softveru-potrebujeme-systemove-testovanie\">\u00bfPor qu\u00e9 necesitamos pruebas de sistema cuando probamos software?<\/h2>\n\n<ul class=\"wp-block-list\">\n<li>Incluso despu\u00e9s de realizar con \u00e9xito pruebas unitarias y de integraci\u00f3n, muchos escenarios complejos pueden tener problemas no detectados. Las pruebas del sistema ayudan a detectar estos errores.<\/li>\n\n\n\n<li>Prueba el software en funci\u00f3n de los requisitos funcionales y no funcionales. Es la primera vez que esto ocurre en todo el ciclo de vida del desarrollo de software. Por tanto, verifica la arquitectura o el dise\u00f1o del software y los requisitos empresariales.  <\/li>\n\n\n\n<li>El entorno de pruebas es exactamente igual que el de producci\u00f3n. Por lo tanto, el \u00e9xito de las pruebas del sistema aporta una sensaci\u00f3n de confianza en el producto final entregado. Las partes interesadas tambi\u00e9n pueden comprender c\u00f3mo reaccionan los usuarios finales ante el software.<\/li>\n\n\n\n<li>Esto minimiza los problemas posteriores a la implantaci\u00f3n, la resoluci\u00f3n de problemas y las llamadas al servicio de asistencia.<\/li>\n<\/ul>\n\n<h2 class=\"wp-block-heading\" id=\"aioseo-co-overovat-pri-testovani-systemu\">\u00bfQu\u00e9 hay que verificar al probar el sistema?  <\/h2>\n\n<p>Este tipo de prueba eval\u00faa un producto de software en los siguientes aspectos:  <\/p>\n\n<ul class=\"wp-block-list\">\n<li>Interacciones entre los componentes del software, incluidos los perif\u00e9ricos externos, para verificar c\u00f3mo funciona el software en su conjunto. Se trata de un escenario de pruebas de extremo a extremo.  <\/li>\n\n\n\n<li>Las entradas dadas al programa inform\u00e1tico producen los resultados esperados.  <\/li>\n\n\n\n<li>Se cumplen los requisitos funcionales y no funcionales.  <\/li>\n\n\n\n<li>Experiencia del usuario final con el software.  <\/li>\n<\/ul>\n\n<p>Hemos enumerado aqu\u00ed algunos de los par\u00e1metros m\u00e1s importantes. Sin embargo, probar el sistema implica verificar muchos otros aspectos. Requiere casos de prueba detallados y archivos de prueba sobre cada aspecto del software desde el exterior, sin examinar sus detalles internos.  <\/p>\n\n<h2 class=\"wp-block-heading\" id=\"aioseo-vstupne-a-vystupne-kriteria\">Criterios de entrada y salida  <\/h2>\n\n<p>Cada nivel de las pruebas de software tiene criterios de entrada y de salida. A continuaci\u00f3n se indican los criterios de entrada y salida para probar el sistema:  <\/p>\n\n<p><strong>Criterios de acceso  <\/strong><\/p>\n\n<ul class=\"wp-block-list\">\n<li>El software debe superar todos los criterios de salida de las pruebas de integraci\u00f3n, es decir j. debe completarse la ejecuci\u00f3n de todos los casos de prueba y no debe haber fallos cr\u00edticos o prioritarios en el estado abierto.  <\/li>\n\n\n\n<li>El plan de pruebas debe ser aprobado y firmado.  <\/li>\n\n\n\n<li>Los casos de prueba, los escenarios de prueba y los guiones de prueba deben estar listos para su ejecuci\u00f3n.  <\/li>\n\n\n\n<li>El entorno de pruebas deber\u00eda estar listo.  <\/li>\n\n\n\n<li>Los requisitos no funcionales deben estar disponibles.  <\/li>\n<\/ul>\n\n<p><strong>Criterios de salida  <\/strong><\/p>\n\n<ul class=\"wp-block-list\">\n<li>Deben ejecutarse todos los casos de prueba previstos para probar el sistema.  <\/li>\n\n\n\n<li>Ning\u00fan fallo prioritario o cr\u00edtico debe estar en estado abierto.  <\/li>\n\n\n\n<li>Aunque los fallos abiertos sean de prioridad media o baja, deben pasar al siguiente nivel de pruebas: las pruebas de aceptaci\u00f3n.  <\/li>\n\n\n\n<li>Debe elaborarse un informe de salida.<\/li>\n<\/ul>\n\n<h2 class=\"wp-block-heading\" id=\"aioseo-typy-testovania-systemu\">Tipos de pruebas del sistema  <\/h2>\n\n<p>Como ya se ha dicho, este tipo de prueba eval\u00faa el software en funci\u00f3n de los requisitos funcionales y no funcionales. Por lo tanto, el software tiene que pasar por varias t\u00e9cnicas de prueba para evaluar todo el sistema y sus diferentes aspectos.<\/p>\n\n<p>Los distintos tipos de pruebas del sistema son:<\/p>\n\n<ol class=\"wp-block-list\">\n<li><strong>Pruebas funcionales<\/strong>: eval\u00faan el software para comprobar que cada funci\u00f3n funciona como debe y cumple los requisitos especificados. Si los probadores descubren que faltan algunas funciones, se las comunican al equipo de desarrollo para que las implemente. Tambi\u00e9n sugieren funciones adicionales para mejorar el programa.  <\/li>\n\n\n\n<li><strong>Pruebas de rendimiento<\/strong>: Es un tipo de prueba no funcional que verifica la estabilidad, escalabilidad, capacidad de respuesta y velocidad del sistema bajo una carga determinada.  <\/li>\n\n\n\n<li><strong>Pruebas de usabilidad<\/strong>: tambi\u00e9n son pruebas no funcionales que verifican la facilidad de uso y la eficacia del software. En pocas palabras, determina la facilidad con la que los usuarios pueden gestionar y controlar el software y acceder a sus funciones.  <\/li>\n\n\n\n<li><strong>Pruebas de fiabilidad<\/strong>: esta t\u00e9cnica de pruebas eval\u00faa el software para verificar que funciona correctamente y de forma constante en determinadas condiciones durante un periodo de tiempo.  <\/li>\n\n\n\n<li><strong>Pruebas de seguridad<\/strong>: detectan todos los riesgos y vulnerabilidades de seguridad del software y garantizan que no permite el acceso no autorizado a datos y otros recursos.  <\/li>\n\n\n\n<li><strong>Pruebas de escalabilidad<\/strong>: este tipo de pruebas de carga eval\u00faa el rendimiento del software a medida que aumenta y disminuye el n\u00famero de usuarios.  <\/li>\n\n\n\n<li><strong>Pruebas de recuperabilidad<\/strong>: esta t\u00e9cnica de prueba determina la capacidad del software para recuperarse de fallos y ca\u00eddas.  <\/li>\n\n\n\n<li><strong>Pruebas de interoperabilidad<\/strong>: analizan lo bien que funciona el software con sus componentes y productos de terceros.  <\/li>\n\n\n\n<li><strong>Pruebas de regresi\u00f3n<\/strong>: estas pruebas garantizan que los nuevos cambios en el c\u00f3digo fuente del software no afectan a la funcionalidad existente. Garantiza la estabilidad del software integrando subsistemas y procedimientos de mantenimiento.<\/li>\n<\/ol>\n\n<h2 class=\"wp-block-heading\" id=\"aioseo-proces-testovania-systemu\">Proceso de prueba del sistema<\/h2>\n\n<p>Aqu\u00ed tienes los pasos individuales para probar el sistema:  <\/p>\n\n<ol class=\"wp-block-list\">\n<li>Configurar <strong>el entorno de pruebas <\/strong>&#8211; El primer paso es crear un entorno de pruebas que coincida con el entorno de producci\u00f3n para realizar pruebas de calidad. El entorno de prueba incluye la selecci\u00f3n de lenguajes de programaci\u00f3n, marcos y herramientas de prueba, y la creaci\u00f3n de las dependencias y configuraciones necesarias.  <\/li>\n\n\n\n<li><strong>Crear <\/strong> casos de prueba &#8211; El siguiente paso es crear casos de prueba para el proceso de prueba exhaustiva. Tambi\u00e9n incluye la creaci\u00f3n de un documento de prueba que contenga el n\u00famero de casos de prueba con \u00e9xito y sin \u00e9xito.  <\/li>\n\n\n\n<li><strong>Desarrollar datos <\/strong> de prueba &#8211; Este paso implica la recogida de datos de prueba. Debe contener toda la informaci\u00f3n y los campos necesarios. Identifica las combinaciones de entrada\/salida favorables y desfavorables.  <\/li>\n\n\n\n<li><strong>Ejecutar<\/strong> casos de prueba &#8211; Utiliza los casos de prueba y los datos de prueba que has creado para ejecutar casos de prueba. Esto te ayudar\u00e1 a saber si los casos de prueba tienen \u00e9xito o no.  <\/li>\n\n\n\n<li><strong>Identificaci\u00f3n de errores\/deficiencias <\/strong>&#8211; Si se produce alg\u00fan error o deficiencia, los probadores deben comunicarlo en el documento de prueba creado en el Paso 2.  <\/li>\n\n\n\n<li><strong>Pruebas de regresi\u00f3n<\/strong> &#8211; Para corregir los errores encontrados, los desarrolladores realizan cambios en el c\u00f3digo fuente. As\u00ed, los probadores realizan pruebas de regresi\u00f3n para asegurarse de que las \u00faltimas modificaciones del c\u00f3digo fuente no afectan a su funcionalidad existente.<\/li>\n\n\n\n<li><strong>Volver a probar<\/strong> &#8211; Si se encuentran errores durante las pruebas de regresi\u00f3n, el equipo de pruebas los comunicar\u00e1 al equipo de desarrollo. El ciclo de pruebas contin\u00faa hasta que el software est\u00e1 listo para pasar a la fase de producci\u00f3n.  <\/li>\n<\/ol>\n\n<h2 class=\"wp-block-heading\" id=\"aioseo-vyhody-a-nevyhody-testovania-systemu\">Ventajas y desventajas de las pruebas del sistema<\/h2>\n\n<p>He aqu\u00ed algunas ventajas y desventajas significativas de probar el sistema:  <\/p>\n\n<p><strong>Beneficios  <\/strong><\/p>\n\n<ul class=\"wp-block-list\">\n<li>Las pruebas de sistemas no requieren que los probadores tengan conocimientos de programaci\u00f3n.  <\/li>\n\n\n\n<li>Verifica todo el producto de software y revela errores y fallos que las pruebas unitarias y de integraci\u00f3n no pueden detectar.  <\/li>\n\n\n\n<li>El entorno de prueba es similar a un entorno de producci\u00f3n real.  <\/li>\n\n\n\n<li>Las pruebas minuciosas de un producto de software se traducen, en \u00faltima instancia, en una alta calidad.  <\/li>\n\n\n\n<li>Mejora el rendimiento general del sistema, el mantenimiento y la fiabilidad.  <\/li>\n\n\n\n<li>Como expone todos los posibles errores y fallos, los equipos de desarrollo y pruebas tienen la confianza suficiente para lanzar los productos a los usuarios.<\/li>\n<\/ul>\n\n<p><strong>Desventajas  <\/strong><\/p>\n\n<ul class=\"wp-block-list\">\n<li>Probar el sistema lleva mucho tiempo.<\/li>\n\n\n\n<li>Requiere probadores altamente cualificados.<\/li>\n\n\n\n<li>Es un reto para los proyectos grandes y complejos.  <\/li>\n\n\n\n<li>Los probadores no tienen acceso al c\u00f3digo fuente del software.  <\/li>\n\n\n\n<li>Ninguna prueba revelar\u00e1 el 100% de los errores. Aunque las pruebas del sistema verifiquen todos los aspectos del c\u00f3digo fuente, pueden seguir existiendo errores.<\/li>\n<\/ul>\n\n<h2 class=\"wp-block-heading\" id=\"aioseo-systemove-testovanie-vs-akceptacne-testovanie\">Pruebas del sistema frente a pruebas de aceptaci\u00f3n  <\/h2>\n\n<p>La siguiente tabla destaca la diferencia entre las pruebas del sistema y las pruebas de aceptaci\u00f3n:<\/p>\n\n<figure class=\"wp-block-table\"><table><tbody><tr><td><strong>Pruebas del sistema<\/strong><\/td><td><strong>Pruebas de Aceptaci\u00f3n<\/strong><\/td><\/tr><tr><td>Prueba el producto de software en su conjunto y verifica que cumple los requisitos funcionales y no funcionales.<\/td><td>Un peque\u00f1o grupo de usuarios reales prueba el producto de software para asegurarse de que cumple los requisitos del cliente.<\/td><\/tr><tr><td>Incluye pruebas funcionales y no funcionales.<\/td><td>Incluye s\u00f3lo pruebas funcionales.<\/td><\/tr><tr><td>Tiene lugar despu\u00e9s de las pruebas de integraci\u00f3n.<\/td><td>Tiene lugar despu\u00e9s de que se haya probado el sistema.<\/td><\/tr><tr><td>Utiliza entradas ficticias creadas por los probadores.<\/td><td>Utiliza entradas aleatorias proporcionadas por los usuarios.<\/td><\/tr><tr><td>Cualquier error encontrado puede corregirse.<\/td><td>Cualquier defecto encontrado se considera un defecto del producto.<\/td><\/tr><tr><td>Se centra tanto en los casos positivos como en los negativos.<\/td><td>Se centra s\u00f3lo en los casos positivos.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n<h2 class=\"wp-block-heading\" id=\"aioseo-zaver\">Conclusi\u00f3n<\/h2>\n\n<p>Se trataba de la comprobaci\u00f3n de sistemas en ingenier\u00eda de software. Se trata de un nivel clave en las pruebas de software, ya que comprueba a fondo los productos de software bas\u00e1ndose en requisitos funcionales y no funcionales. Cuando se hace correctamente, mejora la calidad, el rendimiento, la mantenibilidad y la fiabilidad del software. De lo contrario, podr\u00edan descubrirse errores que no se detectan cuando el programa entra en funcionamiento.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>La prueba de sistemas es un tipo de prueba de software que eval\u00faa un producto de software en su conjunto bas\u00e1ndose en requisitos funcionales y no funcionales.<\/p>\n","protected":false},"author":8,"featured_media":2130,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[40],"tags":[],"class_list":["post-2129","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\/2129","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=2129"}],"version-history":[{"count":2,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts\/2129\/revisions"}],"predecessor-version":[{"id":2177,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/posts\/2129\/revisions\/2177"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/media\/2130"}],"wp:attachment":[{"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/media?parent=2129"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/categories?post=2129"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/ittester.sk\/es\/wp-json\/wp\/v2\/tags?post=2129"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}