- Interview ot\u00e1zky na pohovory o manu\u00e1lnom testovan\u00ed pre nov\u00e1\u010dikov<\/a><\/li>
- Ot\u00e1zky na pohovory o manu\u00e1lnom testovan\u00ed pre pokro\u010dil\u00fdch<\/a><\/li><\/ul><\/div>\n
- \n
- <\/li>\n<\/ul>\n\n
Preguntas de entrevista sobre pruebas manuales para principiantes<\/h2>\n\n
Pregunta n\u00ba. 1. \u00bfQu\u00e9 entiendes por pruebas de software?<\/strong><\/p>\n\n
Respuesta: La prueba de software es el proceso de evaluaci\u00f3n de un sistema para comprobar si cumple los requisitos de la empresa. Mide la calidad global del sistema en t\u00e9rminos de atributos como: correcci\u00f3n, integridad, usabilidad, rendimiento, etc. B\u00e1sicamente, se utiliza para garantizar la calidad del software a los interesados en la aplicaci\u00f3n.<\/p>\n\n
Pregunta n\u00ba. 2. \u00bfPor qu\u00e9 son necesarias las pruebas?<\/strong>
- \n
- Las pruebas garantizan a las partes interesadas que el producto funciona seg\u00fan lo previsto.<\/li>\n\n\n\n
- Los errores evitables que se filtran al usuario\/cliente final sin las pruebas adecuadas dan mala reputaci\u00f3n a la empresa de desarrollo.<\/li>\n\n\n\n
- Los errores descubiertos antes en el SDLC conllevan menores costes y menor uso de recursos para su reparaci\u00f3n.<\/li>\n\n\n\n
- Ahorra tiempo de desarrollo al detectar los problemas en una fase m\u00e1s temprana del desarrollo.<\/li>\n\n\n\n
- El equipo de pruebas a\u00f1ade otra dimensi\u00f3n al desarrollo de software, aportando una perspectiva diferente al proceso de desarrollo del producto.<\/li>\n<\/ul>\n\n
Pregunta 3. \u00bfCu\u00e1ndo debemos dejar de probar el software?<\/strong>
- \n
- Tras la ejecuci\u00f3n de los casos de prueba: la fase de prueba puede detenerse cuando se haya ejecutado un ciclo completo de casos de prueba con un valor de porcentaje de \u00e9xito acordado tras la \u00faltima correcci\u00f3n de error conocida.<\/li>\n\n\n\n
- Una vez cumplidos los plazos de las pruebas – Las pruebas pueden detenerse una vez cumplidos los plazos, cuando no queden problemas de alta prioridad en el sistema.<\/li>\n\n\n\n
- Basado en el tiempo medio entre fallos (MTBF): el MTBF es el intervalo de tiempo entre dos fallos. Seg\u00fan las decisiones de las partes interesadas, si el MTBF es relativamente grande, se puede detener la fase de pruebas.<\/li>\n\n\n\n
- Basado en el valor de la cobertura del c\u00f3digo – La fase de pruebas puede detenerse cuando la cobertura automatizada del c\u00f3digo alcance un determinado valor umbral con un porcentaje suficiente de \u00e9xito y sin un error cr\u00edtico.<\/li>\n<\/ul>\n\n
Pregunta n\u00ba. 4. \u00bfQu\u00e9 es la garant\u00eda de calidad y cu\u00e1les son las distintas actividades que intervienen en ella?<\/strong><\/p>\n\n
R: La garant\u00eda de calidad es un enfoque de proceso que comprueba que el proceso de desarrollo del producto es correcto y cumple todas las normas. Se considera una medida preventiva. Identifica fallos en el proceso de desarrollo del software. Incluye actividades como revisi\u00f3n de documentos, revisi\u00f3n de casos de prueba, recorridos, inspecci\u00f3n, etc.<\/p>\n\n
Pregunta n\u00ba. 5. \u00bfQu\u00e9 es el control de calidad y cu\u00e1les son los distintos tipos de pruebas que intervienen en el control de calidad?<\/strong><\/p>\n\n
R: El control de calidad es un enfoque centrado en el producto que comprueba si la soluci\u00f3n desarrollada cumple todos los requisitos especificados. Se considera una medida correctiva porque pone a prueba el producto creado para encontrar errores. Incluye distintos tipos de pruebas, como pruebas funcionales, pruebas de rendimiento, pruebas de usabilidad, etc.<\/p>\n\n
Pregunta n\u00ba. 6. \u00bfCu\u00e1l es la diferencia entre verificaci\u00f3n y validaci\u00f3n?<\/strong>
1.<\/span><\/td> La verificaci\u00f3n es el proceso de evaluaci\u00f3n de diversos artefactos, as\u00ed como del proceso de desarrollo del software. Se lleva a cabo para garantizar que el producto que se est\u00e1 desarrollando cumple las normas.<\/td> La validaci\u00f3n es el proceso de verificar que un producto de software desarrollado se ajusta a los requisitos empresariales especificados.<\/td><\/tr> 2.<\/span><\/td> Es un proceso est\u00e1tico de an\u00e1lisis de documentos, no el producto final real.<\/td> Consiste en probar din\u00e1micamente un producto de software ejecut\u00e1ndolo.<\/td><\/tr> 3.<\/span><\/td> La verificaci\u00f3n es un enfoque orientado al proceso.<\/td> La validaci\u00f3n es un enfoque orientado al producto.<\/td><\/tr> 4.<\/span><\/td> Responde a la pregunta: \u00ab\u00bfEstamos construyendo bien el producto?\u00bb.<\/td> Responde a la pregunta: \u00ab\u00bfEstamos construyendo el producto adecuado?\u00bb<\/td><\/tr> 5.<\/span><\/td> Los errores detectados durante la validaci\u00f3n requieren menos costes\/recursos para corregirlos que los errores detectados durante la fase de validaci\u00f3n.<\/td> Los errores detectados durante la validaci\u00f3n requieren m\u00e1s costes\/recursos. Una aver\u00eda descubierta m\u00e1s tarde tiene un coste mayor para arreglarla.<\/td><\/tr><\/tbody><\/table><\/figure>\n\n Pregunta n\u00ba. 7. \u00bfQu\u00e9 es el SDLC – Ciclo de vida del desarrollo de software?<\/strong>
Pregunta 8. Explica el STLC – ciclo de vida de las pruebas de software.<\/strong>
- \n
- An\u00e1lisis y validaci\u00f3n de requisitos – En esta fase se analizan y validan los documentos de requisitos y se define el alcance de las pruebas.<\/li>\n\n\n\n
- Planificaci\u00f3n de las pruebas – Esta fase define la estrategia del plan de pruebas, la estimaci\u00f3n del esfuerzo de las pruebas junto con la estrategia de automatizaci\u00f3n y la selecci\u00f3n de herramientas.<\/li>\n\n\n\n
- Dise\u00f1o y an\u00e1lisis de pruebas – Aqu\u00ed se dise\u00f1an los casos de prueba, se preparan los datos de prueba y se implementan los scripts de automatizaci\u00f3n.<\/li>\n\n\n\n
- Preparaci\u00f3n del entorno de prueba – Se prepara un entorno de prueba que simule con precisi\u00f3n el entorno real.<\/li>\n\n\n\n
- Ejecuci\u00f3n de pruebas – Se preparan los casos de prueba, se informa de los errores y se vuelven a probar una vez resueltos.<\/li>\n\n\n\n
- Cierre de la prueba e informes – Se preparar\u00e1 un informe de cierre de la prueba que resuma los resultados finales de la prueba, las conclusiones y las m\u00e9tricas de la prueba.<\/li>\n<\/ul>\n\n
Pregunta n\u00ba. 9. \u00bfCu\u00e1les son los distintos tipos de pruebas?<\/strong>
- \n
- Pruebas funcionales – Las pruebas funcionales consisten en verificar las especificaciones funcionales del sistema.<\/li>\n\n\n\n
- Pruebas no funcionales – Las pruebas no funcionales son un tipo de prueba que consiste en comprobar los requisitos no funcionales de un sistema, como el rendimiento, la escalabilidad, la seguridad, la resistencia, la portabilidad, etc.<\/li>\n<\/ul>\n\n
Seg\u00fan c\u00f3mo se realice la prueba, puede clasificarse en:<\/p>\n\n
- \n
- Pruebas de caja negra: en las pruebas de caja negra, el probador no necesita tener ning\u00fan conocimiento de la arquitectura interna ni de la implementaci\u00f3n del sistema. El comprobador se comunica con el sistema mediante una interfaz, proporciona entradas y verifica las salidas recibidas.<\/li>\n\n\n\n
- Pruebas de caja blanca – En las pruebas de caja blanca, el probador analiza la arquitectura interna del sistema, as\u00ed como la calidad del c\u00f3digo fuente, bas\u00e1ndose en diversos par\u00e1metros, como la optimizaci\u00f3n del c\u00f3digo, la cobertura del c\u00f3digo, la reutilizaci\u00f3n, etc.<\/li>\n\n\n\n
- Pruebas de caja gris – En las pruebas de caja gris, el probador tiene acceso parcial a la arquitectura interna del sistema, por ejemplo el probador puede tener acceso a los documentos de dise\u00f1o o a la estructura de la base de datos. Esta informaci\u00f3n ayuda al probador a probar mejor la aplicaci\u00f3n.<\/li>\n<\/ul>\n\n
Pregunta n\u00ba. 10. \u00bfQu\u00e9 es la prueba manual?<\/strong>
Pregunta.11. \u00bfQu\u00e9 son las pruebas automatizadas?<\/strong>
Pregunta n\u00ba. 12. \u00bfCu\u00e1les son algunas ventajas de las pruebas automatizadas?<\/strong>
- \n
- Ejecutar pruebas mediante automatizaci\u00f3n es r\u00e1pido y ahorra mucho tiempo.<\/li>\n\n\n\n
- Los guiones de prueba cuidadosamente redactados eliminan la posibilidad de error humano durante las pruebas.<\/li>\n\n\n\n
- La ejecuci\u00f3n de las pruebas puede programarse para una ejecuci\u00f3n nocturna mediante herramientas de CI como Jenkins, que tambi\u00e9n pueden configurarse para entregar diariamente los resultados de las pruebas a las partes interesadas.<\/li>\n\n\n\n
- Las pruebas automatizadas consumen muchos recursos. Tras la automatizaci\u00f3n de las pruebas, la ejecuci\u00f3n de las mismas casi no requiere tiempo de control de calidad.<\/li>\n<\/ul>\n\n
Pregunta n\u00ba. 13. \u00bfCu\u00e1les son algunas desventajas de las pruebas automatizadas?<\/strong>
- \n
- Requiere expertos en pruebas automatizadas que escriban guiones de prueba.<\/li>\n\n\n\n
- Se requiere un esfuerzo adicional por adelantado para escribir los guiones.<\/li>\n\n\n\n
- Los scripts de automatizaci\u00f3n se limitan a validar las pruebas codificadas. Esta prueba puede pasar por alto alg\u00fan error que sea muy perceptible y f\u00e1cilmente identificable para un humano (control de calidad manual).<\/li>\n\n\n\n
- Incluso un peque\u00f1o cambio en la aplicaci\u00f3n requiere actualizaciones de script y mantenimiento.<\/li>\n<\/ul>\n\n
Pregunta n\u00ba. 14. \u00bfQu\u00e9 son las pruebas de rendimiento?<\/strong>
\n![\"Pruebas](\"https:\/\/ittester.sk\/wp-content\/uploads\/2023\/06\/perfomance-testing-1024x1008.webp\")
Pruebas de rendimiento<\/figcaption><\/figure>\n<\/div>\n Pregunta n\u00ba. 15. \u00bfQu\u00e9 es un entorno de pruebas?<\/strong>
Pregunta 16. \u00bfQu\u00e9 es un plan de pruebas?<\/strong>
Pregunta n\u00ba. 17. \u00bfQu\u00e9 es un escenario de prueba?<\/strong>
Pregunta n\u00ba. 18. \u00bfQu\u00e9 es un caso de prueba?<\/strong>
Pregunta n\u00ba. 19. \u00bfCu\u00e1les son algunos atributos de un caso de prueba?<\/strong>
- \n
- TestCaseId – identificador \u00fanico del caso de prueba.<\/li>\n\n\n\n
- Resumen de la prueba – Un resumen inequ\u00edvoco del caso de prueba.<\/li>\n\n\n\n
- Descripci\u00f3n – Descripci\u00f3n detallada del caso de prueba.<\/li>\n\n\n\n
- Prerrequisito o condici\u00f3n previa – Conjunto de requisitos previos que deben cumplirse antes de que puedan ejecutarse los pasos de la prueba.<\/li>\n\n\n\n
- Pasos de la prueba – Pasos detallados para ejecutar un caso de prueba.<\/li>\n\n\n\n
- Resultado esperado – Resultado esperado para que la prueba pase.<\/li>\n\n\n\n
- Resultado real – El resultado real despu\u00e9s de realizar los pasos de la prueba.<\/li>\n\n\n\n
- Resultado de la prueba – Estado de aprobado\/no aprobado de la prueba.<\/li>\n\n\n\n
- Estado de automatizaci\u00f3n – Identificador de automatizaci\u00f3n, si la aplicaci\u00f3n est\u00e1 automatizada o no.<\/li>\n\n\n\n
- Fecha – La fecha en que se realiz\u00f3 la prueba.<\/li>\n\n\n\n
- Ejecutado por (Ejecutado por – Nombre de la persona que ejecuta el caso de prueba).<\/li>\n<\/ul>\n\n
Pregunta n\u00ba. 20. \u00bfQu\u00e9 son los datos de prueba?<\/strong>
Pregunta n\u00ba. 21. \u00bfQu\u00e9 es un script de prueba?<\/strong>
Pregunta n\u00ba. 22. \u00bfQu\u00e9 es un error de prueba de software?<\/strong>
Pregunta n\u00ba. 23. \u00bfQu\u00e9 es un \u00abbicho\u00bb?<\/strong>
Pregunta n\u00ba. 24. \u00bfQu\u00e9 es un \u00abdefecto\u00bb?<\/strong>
Pregunta n\u00ba. 25. \u00bfCu\u00e1les son algunos atributos de la notificaci\u00f3n de defectos?<\/strong>
- \n
- DefectId – identificador \u00fanico del defecto.<\/li>\n\n\n\n
- Resumen del defecto – un resumen de una l\u00ednea del defecto, en lugar del nombre del defecto.<\/li>\n\n\n\n
- Descripci\u00f3n del defecto: descripci\u00f3n detallada del defecto.<\/li>\n\n\n\n
- Pasos para reproducir – pasos para reproducir el error.<\/li>\n\n\n\n
- Resultado esperado – el comportamiento esperado del que se desv\u00eda la aplicaci\u00f3n debido a un error.<\/li>\n\n\n\n
- Resultado real: el estado actual de la aplicaci\u00f3n en relaci\u00f3n con el error.<\/li>\n\n\n\n
- Gravedad del error – En funci\u00f3n de la gravedad del error, este campo puede establecerse como leve, medio, grave o \u00abshow stopper\u00bb.<\/li>\n\n\n\n
- Prioridad – En funci\u00f3n de la urgencia del error, este campo puede ajustarse en una escala de P0 a P3.<\/li>\n<\/ul>\n\n
Pregunta n\u00ba. 26. \u00bfCu\u00e1les son algunas de las herramientas para gestionar errores o defectos?<\/strong>
Pregunta n\u00ba. 27. \u00bfQu\u00e9 es la densidad de defectos?<\/strong>
Pregunta n\u00ba. 28. \u00bfQu\u00e9 es la prioridad por defecto?<\/strong>
Pregunta n\u00ba. 29. \u00bfQu\u00e9 es la gravedad del defecto?<\/strong>
Pregunta n\u00ba. 30. Pon un ejemplo de defectos con prioridad baja – gravedad baja, prioridad baja – gravedad alta, prioridad alta – gravedad baja y prioridad alta – gravedad alta.<\/strong>
- \n
- Prioridad baja-Gravedad baja: un error ortogr\u00e1fico en una p\u00e1gina por la que los usuarios no navegan con frecuencia.<\/li>\n\n\n\n
- Prioridad baja-Gravedad alta: aplicaciones de choque en algunos casos muy marginales.<\/li>\n\n\n\n
- Prioridad alta-Gravedad baja: Un ligero cambio en el color del logotipo o un error ortogr\u00e1fico en el nombre de la empresa.<\/li>\n\n\n\n
- Prioridad alta-Gravedad alta: problema con la funci\u00f3n de inicio de sesi\u00f3n.<\/li>\n<\/ul>\n\n
Pregunta 31. \u00bfQu\u00e9 es un \u00abbloqueador\u00bb?<\/strong>
Pregunta n\u00ba. 32. \u00bfQu\u00e9 es un fallo cr\u00edtico?<\/strong>
Pregunta n\u00ba. 33. Explica el ciclo de vida de un bicho o los distintos estados de un bicho.<\/strong><\/p>\n\n
Contesta: Un fallo en el desarrollo de software pasa por las siguientes fases<\/p>\n\n
- \n
- Nuevo – el error o defecto est\u00e1 en estado Nuevo cuando se detecta.<\/li>\n\n\n\n
- Asignado – El fallo reci\u00e9n detectado est\u00e1 en estado Asignado tras ser asignado al desarrollador adecuado.<\/li>\n\n\n\n
- Abierto – Cuando el desarrollador est\u00e1 trabajando en un fallo, \u00e9ste se encuentra en estado Abierto.<\/li>\n\n\n\n
- Rechazado\/No es un fallo – Un fallo se encuentra en el estado Rechazado si el desarrollador considera que el fallo no es aut\u00e9ntico.<\/li>\n<\/ul>\n\n
- \n
- Aplazado – Un fallo aplazado es un fallo cuya correcci\u00f3n se aplaza durante un cierto periodo de tiempo (para futuras versiones) en funci\u00f3n de la urgencia y criticidad del fallo.<\/li>\n\n\n\n
- Corregido – Cuando el desarrollador resuelve el error, se marca como corregido.<\/li>\n\n\n\n
- Probado(Test) – Cuando se arregla un fallo, se asigna a un probador y se marca como probado durante este periodo.<\/li>\n\n\n\n
- Reabierto – Si el probador no est\u00e1 satisfecho con la resoluci\u00f3n del problema, el fallo pasa al estado Reabierto.<\/li>\n\n\n\n
- Verificado – Tras la fase de Pruebas, si el probador considera que el fallo est\u00e1 resuelto, se marca como verificado.<\/li>\n\n\n\n
- Cerrado – Una vez verificado el error, \u00e9ste pasa al estado Cerrado.<\/li>\n<\/ul>\n\n
Pregunta n\u00ba. 34. \u00bfCu\u00e1les son las diferentes t\u00e9cnicas de dise\u00f1o de pruebas?<\/strong><\/p>\n\n
Respuesta: Las t\u00e9cnicas de dise\u00f1o de pruebas son diversas normas de dise\u00f1o de pruebas que permiten crear casos de prueba sistem\u00e1ticos y generalmente aceptados. Las distintas t\u00e9cnicas de dise\u00f1o de pruebas pueden dividirse en t\u00e9cnicas de dise\u00f1o de pruebas est\u00e1ticas y t\u00e9cnicas de dise\u00f1o de pruebas din\u00e1micas.<\/p>\n\n
1. T\u00e9cnicas de dise\u00f1o de pruebas est\u00e1ticas: t\u00e9cnicas de dise\u00f1o de pruebas que implican probar sin ejecutar c\u00f3digo. Las distintas t\u00e9cnicas de dise\u00f1o de pruebas est\u00e1ticas pueden dividirse a su vez en dos partes: manuales y mediante herramientas.<\/p>\n\n
- \n
- T\u00e9cnicas manuales de dise\u00f1o de pruebas est\u00e1ticas<\/li>\n\n\n\n
- Recorrido<\/li>\n\n\n\n
- Revisiones informales<\/li>\n\n\n\n
- Revisiones t\u00e9cnicas<\/li>\n\n\n\n
- AuditControl<\/li>\n\n\n\n
- Revisi\u00f3n de la gesti\u00f3n (Revisi\u00f3n t\u00e9cnica)<\/li>\n<\/ul>\n\n
2. T\u00e9cnicas de dise\u00f1o de pruebas est\u00e1ticas mediante herramientas<\/p>\n\n
- \n
- An\u00e1lisis est\u00e1tico del c\u00f3digo: implica analizar diferentes rutas y flujos en la aplicaci\u00f3n y diferentes estados de los datos de prueba.<\/li>\n\n\n\n
- Conformidad con las normas de programaci\u00f3n – Se eval\u00faa la conformidad del c\u00f3digo con diversas normas de programaci\u00f3n.<\/li>\n\n\n\n
- An\u00e1lisis de m\u00e9tricas de c\u00f3digo – Se necesita una herramienta de an\u00e1lisis est\u00e1tico para evaluar diversas m\u00e9tricas, como l\u00edneas de c\u00f3digo, complejidad, cobertura del c\u00f3digo, etc.<\/li>\n<\/ul>\n\n
3. T\u00e9cnicas de dise\u00f1o de pruebas din\u00e1micas – Las t\u00e9cnicas de dise\u00f1o de pruebas din\u00e1micas implican realizar pruebas ejecutando el sistema sometido a prueba.<\/p>\n\n
- \n
- T\u00e9cnicas de dise\u00f1o de pruebas basadas en especificaciones – Las t\u00e9cnicas de dise\u00f1o de pruebas basadas en especificaciones tambi\u00e9n se denominan pruebas de caja negra. Estas t\u00e9cnicas consisten en probar la especificaci\u00f3n del sistema sometido a prueba sin conocer su arquitectura interna.<\/li>\n\n\n\n
- T\u00e9cnicas de dise\u00f1o de pruebas basadas en estructuras – Tambi\u00e9n denominadas pruebas de caja blanca. En estas t\u00e9cnicas, es necesario conocer el c\u00f3digo o la arquitectura interna del sistema para realizar las pruebas.<\/li>\n\n\n\n
- Basadas en la experiencia – Las t\u00e9cnicas basadas en la experiencia se basan en la experiencia o intuici\u00f3n del probador. Las dos formas m\u00e1s comunes de pruebas basadas en la experiencia son: las pruebas ad hoc y las pruebas exploratorias.<\/li>\n<\/ul>\n\n
Pregunta n\u00ba. 35. \u00bfQu\u00e9 es la prueba est\u00e1tica?<\/strong><\/p>\n\n
R: Las pruebas est\u00e1ticas son un tipo de pruebas para revisar los productos de trabajo o la documentaci\u00f3n que se crean a lo largo de un proyecto. Permite revisar las especificaciones, los requisitos empresariales, la documentaci\u00f3n, los procesos y los requisitos funcionales en la fase de prueba inicial.<\/p>\n\n
Para que los probadores implicados puedan comprender los requisitos con m\u00e1s detalle antes de iniciar el ciclo de vida de las pruebas, cuyo objetivo es ayudar a obtener un producto de calidad.<\/p>\n\n
Pregunta n\u00ba. 36. \u00bfQu\u00e9 es la Prueba Din\u00e1mica?<\/strong><\/p>\n\n
Respuesta: El tipo de prueba que se realiza ejecutando la aplicaci\u00f3n sometida a prueba manualmente o mediante automatizaci\u00f3n se denomina prueba din\u00e1mica.<\/p>\n\n
Pregunta n\u00ba. 37. Explica los distintos tipos de t\u00e9cnicas de dise\u00f1o de pruebas basadas en especificaciones.<\/strong><\/p>\n\n
Respuesta: Las t\u00e9cnicas de dise\u00f1o de pruebas basadas en especificaciones tambi\u00e9n se denominan pruebas de caja negra. Consiste en probar la especificaci\u00f3n del sistema sometido a prueba sin conocer su arquitectura interna. Existen distintos tipos de pruebas basadas en especificaciones o t\u00e9cnicas de pruebas de caja negra:<\/p>\n\n
- \n
- Partici\u00f3n de equivalencia: agrupar los datos de la prueba en grupos l\u00f3gicos o clases de equivalencia con el supuesto de que todos los elementos de datos que se encuentren en las clases tendr\u00e1n el mismo efecto en la aplicaci\u00f3n.<\/li>\n\n\n\n
- An\u00e1lisis de valores l\u00edmite: pruebas que utilizan valores l\u00edmite de clases de equivalencia tomados como entradas de prueba.<\/li>\n\n\n\n
- Tablas de decisi\u00f3n: pruebas mediante tablas de decisi\u00f3n que muestran el comportamiento de la aplicaci\u00f3n en funci\u00f3n de distintas combinaciones de valores de entrada.<\/li>\n\n\n\n
- Gr\u00e1fico causa-efecto – Prueba que utiliza una representaci\u00f3n gr\u00e1fica del resultado y de todos los factores que influyen en \u00e9l.<\/li>\n\n\n\n
- Pruebas de transici\u00f3n de estados – Pruebas basadas en el modelo de m\u00e1quina de estados.<\/li>\n\n\n\n
- Pruebas de casos de uso – Pruebas realizadas utilizando casos de uso.<\/li>\n<\/ul>\n\n
Pregunta n\u00ba. 38. Explica la partici\u00f3n de clases de equivalencia.<\/strong><\/p>\n\n
R: La distribuci\u00f3n de clases de equivalencia es una t\u00e9cnica de prueba de caja negra basada en la especificaci\u00f3n. Al dividir las clases de equivalencia, el conjunto de datos de entrada que definen diferentes condiciones de prueba se dividir\u00e1 en grupos l\u00f3gicamente similares, de modo que el uso de un solo dato de prueba de un grupo de prueba pueda considerarse similar al uso de todos los dem\u00e1s datos de ese grupo.<\/p>\n\n
Por ejemplo, para probar un programa Cuadrado (un programa que da como resultado el cuadrado de un n\u00famero), puede haber clases de equivalencia: el conjunto de los n\u00fameros negativos, los enteros, los decimales, el conjunto de los n\u00fameros grandes, etc.<\/p>\n\n
Pregunta n\u00ba. 39. \u00bfQu\u00e9 es el an\u00e1lisis del valor l\u00edmite?<\/strong><\/p>\n\n
Respuesta: El an\u00e1lisis de valores l\u00edmite es una t\u00e9cnica de prueba de software para dise\u00f1ar casos de prueba que toma los valores l\u00edmite de las distribuciones de clases de equivalencia como entrada para los casos de prueba, por ejemplo. si los datos de la prueba se encuentran en el intervalo 0-100, el an\u00e1lisis del umbral incluir\u00e1 los datos de la prueba – 0,1, 99, 100.<\/p>\n\n
Pregunta 40. \u00bfQu\u00e9 es la prueba de la tabla de decisi\u00f3n?<\/strong><\/p>\n\n
Respuesta: La prueba de tablas de decisi\u00f3n es un tipo de t\u00e9cnica de dise\u00f1o de pruebas basada en especificaciones o t\u00e9cnica de prueba de caja negra en la que las pruebas se realizan utilizando tablas de decisi\u00f3n que representan el comportamiento de una aplicaci\u00f3n en funci\u00f3n de varias combinaciones de valores de entrada.<\/p>\n\n
Las tablas de decisi\u00f3n son especialmente \u00fatiles para dise\u00f1ar casos de prueba para escenarios empresariales complejos que impliquen la validaci\u00f3n de aplicaciones con m\u00faltiples combinaciones de entradas.<\/p>\n\n
Pregunta 41. \u00bfQu\u00e9 es un gr\u00e1fico causa-efecto?<\/strong><\/p>\n\n
Contesta: La prueba gr\u00e1fica de causa y efecto es una t\u00e9cnica de dise\u00f1o de pruebas de caja negra en la que se utiliza una representaci\u00f3n gr\u00e1fica de la entrada para dise\u00f1ar las pruebas, es decir j. causas y resultados, es decir j. de consecuencia. Esta t\u00e9cnica utiliza varias notaciones que representan Y, O, NO, etc. entre las condiciones de entrada que conducen a la salida.<\/p>\n\n
Pregunta n\u00ba. 42. \u00bfQu\u00e9 es la prueba de transici\u00f3n de estado?<\/strong><\/p>\n\n
Respuesta: La prueba de transici\u00f3n de estados es una t\u00e9cnica de dise\u00f1o de pruebas de caja negra basada en un modelo de m\u00e1quina de estados. Probar las transiciones entre estados se basa en el concepto de que un sistema puede definirse como un conjunto de m\u00faltiples estados, y la transici\u00f3n de un estado a otro se producir\u00e1 como resultado de un suceso.<\/p>\n\n
Pregunta n\u00ba. 43. \u00bfQu\u00e9 es la prueba de casos de uso?<\/strong><\/p>\n\n
Respuesta: La prueba de casos de uso es un enfoque de prueba de caja negra en el que la prueba se realiza mediante casos de uso. El escenario del caso de uso se considera una interacci\u00f3n entre la aplicaci\u00f3n y los actores (usuarios). Estos casos de uso se utilizan para ilustrar los requisitos y, por tanto, tambi\u00e9n pueden servir de base para las pruebas de aceptaci\u00f3n.<\/p>\n\n
Pregunta n\u00ba. 44. \u00bfQu\u00e9 es la cobertura de las pruebas?<\/strong><\/p>\n\n
Respuesta: Es una m\u00e9trica que mide la cantidad de pruebas realizadas en el software al ejecutar los casos de prueba. La cobertura de las pruebas de cualquier software puede calcularse como un porcentaje del n\u00famero de \u00e1reas de prueba o elementos de cobertura cubiertos en relaci\u00f3n con el n\u00famero total de \u00e1reas de prueba.<\/p>\n\n
Cuanto mayor sea la cobertura de las pruebas, m\u00e1s partes del software estar\u00e1n cubiertas por casos de prueba y, por tanto, m\u00e1s eficaces ser\u00e1n las pruebas.<\/p>\n\n
Pregunta n\u00ba. 45. \u00bfQu\u00e9 son las pruebas basadas en estructuras?<\/strong><\/p>\n\n
Responde: Las t\u00e9cnicas de dise\u00f1o de pruebas basadas en estructuras tambi\u00e9n se denominan pruebas de caja blanca. En estas t\u00e9cnicas, es necesario conocer el c\u00f3digo o la arquitectura interna del sistema para realizar las pruebas. Los distintos tipos de pruebas basadas en la estructura o t\u00e9cnicas de prueba de caja blanca son:<\/p>\n\n
- \n
- Prueba de sentencias: t\u00e9cnica de prueba de caja blanca en la que se dise\u00f1an scripts de prueba para ejecutar comandos en el c\u00f3digo de la aplicaci\u00f3n. Su cobertura se mide como el n\u00famero de l\u00edneas de c\u00f3digo o sentencias ejecutadas por los scripts de prueba.<\/li>\n\n\n\n
- Prueba de decisi\u00f3n\/prueba de rama: t\u00e9cnica de prueba en la que se dise\u00f1an guiones de prueba para ejecutar diferentes ramas de decisi\u00f3n (por ejemplo, condiciones si-si) en una aplicaci\u00f3n. Su cobertura se mide como porcentaje de puntos de decisi\u00f3n sobre el n\u00famero total de puntos de decisi\u00f3n de la aplicaci\u00f3n.<\/li>\n\n\n\n
- Pruebas de condici\u00f3n – Las pruebas de condici\u00f3n son un enfoque de prueba en el que probamos una aplicaci\u00f3n con resultados Verdadero y Falso para cada condici\u00f3n. Por tanto, para n condiciones, tendremos 2n guiones de prueba.<\/li>\n\n\n\n
- Pruebas de condiciones m\u00faltiples – En las pruebas de condiciones m\u00faltiples, se prueban diferentes combinaciones de resultados de condiciones al menos una vez. Por tanto, para una cobertura del 100%, tendremos 2^n guiones de prueba. Esto es muy agotador y es muy dif\u00edcil conseguir una cobertura del 100%.<\/li>\n\n\n\n
- Pruebas de determinaci\u00f3n de condiciones – Se trata de una forma optimizada de probar m\u00faltiples condiciones, descartando las combinaciones que no afectan a los resultados.<\/li>\n\n\n\n
- Pruebas de rutas – Pruebas de rutas independientes en el sistema (las rutas son declaraciones ejecutables desde los puntos de entrada a los de salida).<\/li>\n<\/ul>\n\n
Pregunta n\u00ba. 46. \u00bfQu\u00e9 es la cobertura del c\u00f3digo?<\/strong><\/p>\n\n
R: La cobertura del c\u00f3digo es una medida de la cantidad de c\u00f3digo cubierto por los guiones de prueba. Da una idea de la parte de la aplicaci\u00f3n cubierta por las pruebas.<\/p>\n\n
Pregunta 47. \u00bfQu\u00e9 es la prueba de enunciados y la cobertura de enunciados en la prueba de caja blanca?<\/strong><\/p>\n\n
Respuesta: La prueba de sentencias es un enfoque de prueba de caja blanca en el que se dise\u00f1an guiones de prueba para ejecutar sentencias de c\u00f3digo.<\/p>\n\n
La cobertura de sentencias es una medida del porcentaje de sentencias de c\u00f3digo ejecutadas por los scripts de prueba sobre el n\u00famero total de sentencias de c\u00f3digo de la aplicaci\u00f3n. La cobertura de comandos es la m\u00e9trica menos preferida para comprobar la cobertura de las pruebas.<\/p>\n\n
Pregunta n\u00ba. 48. \u00bfQu\u00e9 es la prueba de decisi\u00f3n o prueba de rama?<\/strong><\/p>\n\n
R: La prueba de decisi\u00f3n o prueba de rama es un enfoque de prueba de caja blanca en el que la cobertura de la prueba se mide por el porcentaje de puntos de decisi\u00f3n (por ejemplo, condiciones if-else) ejecutados del n\u00famero total de puntos de decisi\u00f3n de la aplicaci\u00f3n.<\/p>\n\n
Pregunta 49. \u00bfCu\u00e1les son los distintos niveles de las pruebas?<\/strong><\/p>\n\n
Responde: Las pruebas pueden realizarse a distintos niveles durante el proceso de desarrollo. Llevar a cabo actividades de comprobaci\u00f3n a varios niveles ayuda a identificar pronto los defectos. Los distintos niveles de prueba son –<\/p>\n\n
1. Pruebas unitarias<\/p>\n\n
2. Pruebas de integraci\u00f3n<\/p>\n\n
3. Pruebas del sistema<\/p>\n\n
4. Pruebas de aceptaci\u00f3n<\/p>\n\n
Pregunta n\u00ba. 50. \u00bfQu\u00e9 son las pruebas unitarias?<\/strong><\/p>\n\n
Respuesta: Las pruebas unitarias son el primer nivel de las pruebas y consisten en probar m\u00f3dulos de software individuales. Suelen llevarla a cabo los promotores.<\/p>\n\n
Pregunta n\u00ba. 51. \u00bfQu\u00e9 son las pruebas de integraci\u00f3n?<\/strong><\/p>\n\n
R: Las pruebas de integraci\u00f3n se realizan despu\u00e9s de las pruebas unitarias. En las pruebas de integraci\u00f3n, probamos un grupo de m\u00f3dulos relacionados. Su objetivo es encontrar problemas de interconexi\u00f3n entre m\u00f3dulos.<\/p>\n\n
Pregunta n\u00ba. 52. \u00bfCu\u00e1les son los distintos tipos de pruebas de integraci\u00f3n?<\/strong><\/p>\n\n
R: Los distintos tipos de pruebas de integraci\u00f3n son –<\/p>\n\n
1. Pruebas de integraci\u00f3n \u00abbig bang\u00bb – En las pruebas de integraci\u00f3n \u00abbig bang\u00bb, las pruebas comienzan una vez integrados todos los m\u00f3dulos.<\/p>\n\n
2. Pruebas de integraci\u00f3n descendente – En la integraci\u00f3n descendente, las pruebas\/integraci\u00f3n comienzan desde los m\u00f3dulos de nivel superior hacia los m\u00f3dulos de nivel inferior.<\/p>\n\n
3. Pruebas de integraci\u00f3n ascendente – En la integraci\u00f3n ascendente, las pruebas comienzan desde los m\u00f3dulos de nivel inferior hacia los m\u00f3dulos de nivel superior de la jerarqu\u00eda.<\/p>\n\n
4. Pruebas de integraci\u00f3n h\u00edbridas – Las pruebas de integraci\u00f3n h\u00edbridas son una combinaci\u00f3n de pruebas de integraci\u00f3n descendentes y ascendentes. En este enfoque, la integraci\u00f3n parte de la capa intermedia y las pruebas se realizan en ambas direcciones<\/p>\n\n
Pregunta n\u00ba. 53. \u00bfQu\u00e9 es un tal\u00f3n?<\/strong><\/p>\n\n
R: En el caso de las pruebas de integraci\u00f3n descendente, muchas veces los m\u00f3dulos de nivel inferior no evolucionan cuando se inician las pruebas\/integraci\u00f3n con los m\u00f3dulos de nivel superior. En estos casos, se utilizan stubs o m\u00f3dulos ficticios para simular el funcionamiento de los m\u00f3dulos proporcionando una salida fija o esperada en funci\u00f3n de los valores de entrada.<\/p>\n\n
Pregunta 54. \u00bfQu\u00e9 es un conductor?<\/strong><\/p>\n\n
R: En el caso de las pruebas de integraci\u00f3n ascendentes, los controladores se utilizan para simular el funcionamiento de los m\u00f3dulos de nivel superior, con el fin de probar los m\u00f3dulos relacionados de nivel inferior en la jerarqu\u00eda.<\/p>\n\n
Pregunta 55. \u00bfQu\u00e9 es la prueba del sistema?<\/strong><\/p>\n\n
R: La prueba del sistema es un nivel de prueba que comprueba el software en su conjunto. Durante las pruebas del sistema, se comprueba que la aplicaci\u00f3n cumple sus requisitos empresariales.<\/p>\n\n
Pregunta n\u00ba. 56. \u00bfQu\u00e9 son las pruebas de aceptaci\u00f3n?<\/strong><\/p>\n\n
Respuesta: Las pruebas de aceptaci\u00f3n son las que realiza un posible usuario final o cliente para comprobar que el software cumple los requisitos de la empresa y puede ser aceptado para su uso.<\/p>\n\n
Pregunta n\u00ba. 57. \u00bfQu\u00e9 es la prueba UAT?<\/strong><\/p>\n\n
Respuesta: Las pruebas UAT son la \u00faltima fase del ciclo de vida de las pruebas. Su objetivo principal es verificar que el software funciona de acuerdo con los requisitos de la empresa. Tambi\u00e9n se asegura de que la aplicaci\u00f3n sea f\u00e1cil de usar y pueda manejar mejor los escenarios complejos antes de lanzar el producto a los usuarios reales.<\/p>\n\n
Pregunta n\u00ba. 58. \u00bfQu\u00e9 es la prueba de extremo a extremo?<\/strong><\/p>\n\n
R: Las pruebas de extremo a extremo son un tipo de prueba en el que se comprueba toda la aplicaci\u00f3n para verificar que cada caracter\u00edstica del software funciona como se espera y que no quedan lagunas. Garantiza que la aplicaci\u00f3n sea f\u00e1cil de usar y cumpla los requisitos de la empresa.<\/p>\n\n
Pregunta n\u00ba. 59. \u00bfQu\u00e9 es la prueba alfa?<\/strong><\/p>\n\n
Respuesta: La prueba alfa es un tipo de prueba de aceptaci\u00f3n que realizan probadores o empleados internos de la organizaci\u00f3n en el lugar de trabajo del desarrollador.<\/p>\n\n
Pregunta 60. \u00bfQu\u00e9 es una prueba beta?<\/strong><\/p>\n\n
Respuesta: Las pruebas beta son las que realizan los usuarios finales en su lugar de trabajo. Permite a los usuarios proporcionar informaci\u00f3n directa sobre el software a la empresa desarrolladora.<\/p>\n\n
Pregunta n\u00ba. 61. \u00bfQu\u00e9 son las pruebas ad hoc?<\/strong><\/p>\n\n
Respuesta: Las pruebas ad hoc son una forma no estructurada de realizar pruebas, sin documentaci\u00f3n formal ni planificaci\u00f3n adecuada.<\/p>\n\n
Pregunta n\u00ba 62. \u00bfQu\u00e9 es la prueba del mono?<\/strong><\/p>\n\n
Respuesta: La prueba del mono es un tipo de prueba que se realiza aleatoriamente, sin casos de prueba ni entradas de prueba predefinidos.<\/p>\n\n
Pregunta n\u00ba. 63. \u00bfEn qu\u00e9 se diferencian las pruebas mono de las pruebas adhoc?<\/strong><\/p>\n\n
R: En el caso de las pruebas Adhoc, aunque no haya casos de prueba predefinidos o documentados, los probadores siguen teniendo una visi\u00f3n general de la aplicaci\u00f3n. Mientras que en el caso de las pruebas de mono, los probadores no entienden la aplicaci\u00f3n.<\/p>\n\n
Pregunta n\u00ba. 64. \u00bfQu\u00e9 es la prueba exploratoria?<\/strong><\/p>\n\n
R: La prueba exploratoria es un tipo de prueba en la que se a\u00f1aden y actualizan nuevos casos de prueba a medida que se explora el sistema o se ejecutan los casos de prueba. A diferencia de las pruebas con gui\u00f3n, en las pruebas exploratorias, el dise\u00f1o y la ejecuci\u00f3n de las pruebas tienen lugar en paralelo.<\/p>\n\n
Pregunta n\u00ba. 65. \u00bfQu\u00e9 es la prueba de carga?<\/strong><\/p>\n\n
R: Las pruebas de carga son un tipo de pruebas de rendimiento cuyo objetivo es determinar el rendimiento de una aplicaci\u00f3n bajo una carga prevista. Durante las pruebas de carga, evaluamos el tiempo de respuesta, el rendimiento, la tasa de errores, etc. par\u00e1metros de aplicaci\u00f3n.<\/p>\n\n
Pregunta n\u00ba. 66. \u00bfQu\u00e9 son las pruebas de estr\u00e9s?<\/strong><\/p>\n\n
R: Las pruebas de estr\u00e9s son un tipo de pruebas de rendimiento en las que se controla el comportamiento de una aplicaci\u00f3n bajo una carga superior a la esperada. Las pruebas de estr\u00e9s se realizan para detectar fugas de memoria y la robustez de la aplicaci\u00f3n.<\/p>\n\n
Pregunta n\u00ba. 67. \u00bfQu\u00e9 es la prueba de volumen?<\/strong><\/p>\n\n
R: Las pruebas de volumen son un tipo de prueba de rendimiento que eval\u00faa el rendimiento de una aplicaci\u00f3n con una gran cantidad de datos. Comprueba la escalabilidad de la aplicaci\u00f3n y ayuda a identificar los cuellos de botella con grandes vol\u00famenes de datos.<\/p>\n\n
Pregunta n\u00ba. 68. \u00bfQu\u00e9 es la prueba de resistencia o Soak test?<\/strong><\/p>\n\n
Respuesta: Las pruebas de resistencia son un tipo de pruebas de rendimiento cuyo objetivo es encontrar problemas, como fugas de memoria, cuando una aplicaci\u00f3n se somete a pruebas de estr\u00e9s durante un largo periodo de tiempo.<\/p>\n\n
Pregunta n\u00ba. 69. \u00bfQu\u00e9 es la prueba del pico?<\/strong><\/p>\n\n
R: La prueba de picos es un tipo de prueba de rendimiento que mide el rendimiento de una aplicaci\u00f3n cuando el n\u00famero de usuarios activos aumenta repentinamente durante una prueba de estr\u00e9s.<\/p>\n\n
Pregunta n\u00ba. 70. \u00bfQu\u00e9 es la prueba de interfaz de usuario?<\/strong><\/p>\n\n
Respuesta: Las pruebas de interfaz de usuario o UI son un tipo de pruebas cuyo objetivo es encontrar fallos en la GUI de una aplicaci\u00f3n y comprobar si la GUI se ajusta a las especificaciones.<\/p>\n\n
Pregunta n\u00ba. 71. \u00bfQu\u00e9 son las pruebas de usabilidad?<\/strong><\/p>\n\n
Respuesta: Las pruebas de usabilidad son un tipo de pruebas cuyo objetivo es determinar la facilidad de uso de una aplicaci\u00f3n. Su finalidad es detectar fallos de usabilidad en la aplicaci\u00f3n.<\/p>\n\n
Pregunta n\u00ba. 72. \u00bfQu\u00e9 son las pruebas de accesibilidad?<\/strong><\/p>\n\n
Respuesta: Las pruebas de accesibilidad son un tipo de pruebas dise\u00f1adas para determinar la facilidad de uso o funcionamiento de una aplicaci\u00f3n espec\u00edficamente para personas con discapacidad.<\/p>\n\n
Pregunta 73. \u00bfQu\u00e9 es la prueba de compatibilidad?<\/strong><\/p>\n\n
Respuesta: La prueba de compatibilidad es la verificaci\u00f3n del software para determinar su compatibilidad con un entorno concreto: sistema operativo, plataforma o hardware.<\/p>\n\n
Pregunta n\u00ba. 74. \u00bfQu\u00e9 es la prueba de configuraci\u00f3n?<\/strong><\/p>\n\n
Respuesta: La prueba de configuraci\u00f3n es un tipo de prueba que se utiliza para evaluar los requisitos de configuraci\u00f3n del software junto con el efecto de cambiar la configuraci\u00f3n requerida.<\/p>\n\n
Pregunta n\u00ba 75. \u00bfQu\u00e9 son las pruebas de localizaci\u00f3n?<\/strong><\/p>\n\n
R: Las pruebas de localizaci\u00f3n son un tipo de pruebas en las que evaluamos la adaptaci\u00f3n de una aplicaci\u00f3n (una versi\u00f3n localizada de la aplicaci\u00f3n) en una cultura, ubicaci\u00f3n o pa\u00eds concretos.<\/p>\n\n
Pregunta n\u00ba. 76. \u00bfQu\u00e9 es la prueba de la globalizaci\u00f3n?<\/strong><\/p>\n\n
R: Las pruebas de globalizaci\u00f3n son un tipo de pruebas que eval\u00faan el rendimiento de una aplicaci\u00f3n en todo el mundo en diferentes culturas, idiomas, lugares y pa\u00edses.<\/p>\n\n
Pregunta n\u00ba. 77. \u00bfQu\u00e9 son las pruebas negativas?<\/strong><\/p>\n\n
Respuesta: Las pruebas negativas son un tipo de prueba que eval\u00faa la resistencia de una aplicaci\u00f3n (graceful exiting o notificaci\u00f3n de errores) cuando se le proporcionan datos de entrada o de prueba no v\u00e1lidos.<\/p>\n\n
Pregunta n\u00ba. 78. \u00bfQu\u00e9 son las pruebas de seguridad?<\/strong><\/p>\n\n
Respuesta: Las pruebas de seguridad son un tipo de pruebas cuyo objetivo es evaluar la integridad, autenticaci\u00f3n, autorizaci\u00f3n, disponibilidad, confidencialidad y no repudio de la aplicaci\u00f3n sometida a prueba.<\/p>\n\n
Pregunta n\u00ba. 79. \u00bfQu\u00e9 son las pruebas de penetraci\u00f3n?<\/strong><\/p>\n\n
R: Las pruebas de penetraci\u00f3n o pen testing son un tipo de pruebas de seguridad en las que se eval\u00faa una aplicaci\u00f3n (explot\u00e1ndola de forma segura) en busca de varios tipos de vulnerabilidades que podr\u00edan ser aprovechadas por cualquier hacker.<\/p>\n\n
Pregunta n\u00ba. 80. \u00bfQu\u00e9 es la prueba de robustez?<\/strong><\/p>\n\n
Respuesta: Las pruebas de robustez son un tipo de pruebas que se realizan para determinar la robustez de una aplicaci\u00f3n, es decir. j. la capacidad del sistema para comportarse con moderaci\u00f3n en caso de pasos de prueba y entradas de prueba defectuosos.<\/p>\n\n
Pregunta n\u00ba. 81. \u00bfQu\u00e9 es la prueba de concurrencia?<\/strong><\/p>\n\n
Respuesta: Las pruebas de concurrencia son pruebas multiusuario en las que se eval\u00faa una aplicaci\u00f3n analizando su comportamiento cuando los usuarios acceden a la misma funci\u00f3n de forma concurrente.<\/p>\n\n
Pregunta n\u00ba. 82. \u00bfQu\u00e9 es la prueba del backend?<\/strong><\/p>\n\n
Respuesta: Las pruebas de backend son un tipo de pruebas que implican probar el backend del sistema, lo que incluye probar las bases de datos y las API de la aplicaci\u00f3n.<\/p>\n\n
Pregunta n\u00ba. 83. \u00bfQu\u00e9 son las pruebas A\/B?<\/strong><\/p>\n\n
Respuesta: Las pruebas A\/B son un tipo de pruebas en las que se expone a los usuarios finales a dos variantes de un producto de software y, bas\u00e1ndose en un an\u00e1lisis del comportamiento del usuario en cada variante, se selecciona la variante mejor y se utiliza.<\/p>\n\n
Pregunta n\u00ba. 84. \u00bfQu\u00e9 es el an\u00e1lisis de riesgos?<\/strong><\/p>\n\n
Respuesta: El an\u00e1lisis de riesgos es el an\u00e1lisis de un riesgo identificado y la asignaci\u00f3n de un nivel de riesgo adecuado a un defecto en funci\u00f3n de su impacto en la aplicaci\u00f3n.<\/p>\n\n
Pregunta n\u00ba. 85. \u00bfQu\u00e9 diferencia hay entre las pruebas de regresi\u00f3n y el retesteo?<\/strong><\/p>\n\n
R: Las pruebas de regresi\u00f3n consisten en probar una aplicaci\u00f3n para verificar que un nuevo cambio de c\u00f3digo no afecta a otras partes de la aplicaci\u00f3n. Al volver a probar, comprobamos si el problema solucionado se ha resuelto o no.<\/p>\n\n
Pregunta n\u00ba. 86. \u00bfCu\u00e1l es la diferencia entre las pruebas de caja negra y de caja blanca?<\/strong><\/p>\n\n
Respuesta: Las pruebas de caja negra son un tipo de pruebas en las que no se requiere la arquitectura interna del c\u00f3digo para realizarlas. Suele aplicarse en las pruebas del sistema y en las pruebas de aceptaci\u00f3n.<\/p>\n\n
Mientras que las pruebas de caja blanca requieren conocer el dise\u00f1o interno y la implementaci\u00f3n de la aplicaci\u00f3n sometida a prueba. Suele utilizarse para pruebas unitarias y pruebas de integraci\u00f3n.<\/p>\n\n
Pregunta n\u00ba. 87. \u00bfCu\u00e1l es la diferencia entre las pruebas de humo y las de cordura?<\/strong><\/p>\n\n
R: La diferencia entre las pruebas de humo y las pruebas de cordura es la siguiente.<\/p>\n\n
- \n
- La prueba de humo es un tipo de prueba en la que se prueban todas las funciones principales de una aplicaci\u00f3n antes de realizar una prueba exhaustiva. Mientras que las pruebas de cordura son un subconjunto de las pruebas de regresi\u00f3n, que se realizan cuando se hace alguna correcci\u00f3n menor en la aplicaci\u00f3n en una nueva compilaci\u00f3n.<\/li>\n\n\n\n
- Las pruebas de humo suelen estar documentadas o automatizadas. Aunque las pruebas de cordura no suelen estar documentadas ni guionizadas.<\/li>\n<\/ul>\n\n
Pregunta n\u00ba. 88. \u00bfCu\u00e1l es la diferencia entre Liberar y Construir?<\/strong><\/p>\n\n
Respuesta: Una compilaci\u00f3n es un archivo ejecutable proporcionado por los desarrolladores al equipo de pruebas para probar la aplicaci\u00f3n. Pasa por varias iteraciones de correcciones y pruebas hasta que la aplicaci\u00f3n funcione como se espera. Cuando la aplicaci\u00f3n es estable y est\u00e1 lista para los usuarios finales, se lanza al mercado.<\/p>\n\n
Mientras que la Versi\u00f3n es el software instalable que se proporciona a los usuarios finales despu\u00e9s de que el equipo de pruebas lo haya certificado. Cuando se libera cualquier software a un cliente, va acompa\u00f1ado de notas de lanzamiento que incluyen el n\u00famero de errores a\u00fan abiertos, las historias de usuario cubiertas, las peticiones de cambio y la versi\u00f3n de lanzamiento.<\/p>\n\n
Preguntas avanzadas de la entrevista sobre pruebas manuales<\/strong><\/h2>\n\n
Preguntas no. 89. \u00bfCu\u00e1l es la diferencia entre filtraci\u00f3n de fallos y liberaci\u00f3n de fallos?<\/strong><\/p>\n\n
Respuesta Una fuga de errores se produce cuando un software en fase de pruebas sale al mercado y el usuario final encuentra errores en \u00e9l. Esto incluye los errores pasados por alto por el equipo de pruebas durante la fase de pruebas.<\/p>\n\n
Mientras que una publicaci\u00f3n de errores es cuando una versi\u00f3n concreta de un software se lanza al mercado con algunos errores conocidos que se corregir\u00e1n en versiones posteriores. Este tipo de problemas son de baja prioridad y se mencionan en las notas de la versi\u00f3n cuando se comparten con los usuarios finales.<\/p>\n\n
Pregunta n\u00ba. 90. \u00bfQu\u00e9 quieres decir con Triaje de defectos?<\/strong><\/p>\n\n
R: El triaje de defectos es un proceso que prioriza los defectos en funci\u00f3n de varios factores, como la gravedad, el riesgo, el tiempo necesario para solucionar el defecto, etc. A la reuni\u00f3n asisten varias partes interesadas: equipo de desarrollo, equipo de pruebas, jefe de proyecto, BA, etc. y decidir la prioridad de la correcci\u00f3n de errores.<\/p>\n\n
Pregunta n\u00ba. 91. \u00bfQu\u00e9 es una prueba de arn\u00e9s? \u00bfPor qu\u00e9 necesitamos una prueba de arn\u00e9s?<\/strong><\/p>\n\n
Respuesta: Un arn\u00e9s de pruebas es una colecci\u00f3n de guiones de pruebas y datos de pruebas que suele asociarse a las pruebas unitarias y de integraci\u00f3n. Incluye stubs y drivers necesarios para probar m\u00f3dulos de software y componentes integrados.<\/p>\n\n
Pregunta n\u00ba. 92. \u00bfQu\u00e9 son las pruebas por parejas?<\/strong><\/p>\n\n
Respuesta: La prueba de todos los pares es un tipo de prueba en el que la aplicaci\u00f3n se prueba con todas las combinaciones posibles de valores de los par\u00e1metros de entrada.<\/p>\n\n
Pregunta n\u00ba. 93. \u00bfQu\u00e9 es la prueba de conmutaci\u00f3n por error?<\/strong><\/p>\n\n
Respuesta: La prueba de conmutaci\u00f3n por error es un tipo de prueba que se utiliza para verificar la capacidad de una aplicaci\u00f3n para asignar varios recursos (varios servidores) en caso de fallo y transferir parte del procesamiento a un sistema de copia de seguridad.<\/p>\n\n
Pregunta n\u00ba. 94. \u00bfQu\u00e9 son las pruebas fuzz?<\/strong><\/p>\n\n
R: Las pruebas Fuzz son un tipo de pruebas en las que se proporciona una gran cantidad de datos aleatorios como entrada a una aplicaci\u00f3n, con el fin de encontrar brechas de seguridad y otros problemas en la aplicaci\u00f3n.<\/p>\n\n
Pregunta n\u00ba. 95. \u00bfQu\u00e9 es una prueba piloto?<\/strong><\/p>\n\n
R: Las pruebas piloto son pruebas realizadas a modo de ensayo con un n\u00famero limitado de usuarios que eval\u00faan el sistema y aportan sus comentarios antes de la implantaci\u00f3n completa.<\/p>\n\n
Pregunta n\u00ba. 96. \u00bfQu\u00e9 es la prueba dev-box?<\/strong><\/p>\n\n
R: En las pruebas dev-box, el probador realiza pruebas en el sistema del desarrollador para verificar que las principales caracter\u00edsticas de la aplicaci\u00f3n son estables y est\u00e1n listas para las pruebas.<\/p>\n\n
Pregunta n\u00ba. 97. \u00bfQu\u00e9 es la prueba de mutaciones?<\/strong><\/p>\n\n
Respuesta: La prueba de mutaci\u00f3n es un tipo de prueba de caja blanca en la que se muta el c\u00f3digo fuente de una aplicaci\u00f3n para provocar determinados errores en su funcionamiento. A continuaci\u00f3n, se ejecutan guiones de prueba para comprobar su correcci\u00f3n verificando los errores causados por el c\u00f3digo mutado.<\/p>\n\n
Pregunta n\u00ba. 98. \u00bfQu\u00e9 es una matriz de trazabilidad de requisitos (RTM)?<\/strong><\/p>\n\n
R: En las pruebas de software, una matriz de trazabilidad de requisitos es una tabla que relaciona los requisitos de alto nivel con los requisitos detallados, los planes de prueba o los casos de prueba. La RTM ayuda a garantizar una cobertura de pruebas del 100%.<\/p>\n\n
Pregunta n\u00ba. 99. \u00bfQu\u00e9 es la complejidad ciclom\u00e1tica?<\/strong><\/p>\n\n
R: La complejidad ciclom\u00e1tica es una medida del n\u00famero de caminos independientes en una aplicaci\u00f3n o programa. Esta m\u00e9trica proporciona una indicaci\u00f3n de la cantidad de esfuerzo necesario para probar la funcionalidad completa. Puede definirse mediante la expresi\u00f3n –<\/p>\n\n
- Ot\u00e1zky na pohovory o manu\u00e1lnom testovan\u00ed pre pokro\u010dil\u00fdch<\/a><\/li><\/ul><\/div>\n