TEST BORRADO, QUIZÁS LE INTERESE: Tema 6
COMENTARIOS | ESTADÍSTICAS | RÉCORDS |
---|
REALIZAR TEST
Título del Test:
Tema 6 Descripción: Unidad 4. MF0494_3. UF2181 Autor: Adeplos OTROS TESTS DEL AUTOR Fecha de Creación: 13/01/2025 Categoría: Informática Número Preguntas: 69 |
COMPARTE EL TEST
Comentar
No hay ningún comentario sobre este test.
Temario:
¿Cuál es el principal objetivo de las pruebas de software? Detectar la mayor cantidad posible de errores. Garantizar que el software se vea bien. Acelerar el proceso de desarrollo. Reducir el costo del proyecto. Según el texto, ¿qué se entiende por "bugs" en el contexto de las pruebas de software? Errores de programación en el código. Defectos en la apariencia visual. Problemas de comunicación entre equipos. Cambios inesperados en los requerimientos. ¿Cuál de las siguientes NO es mencionada como una razón común para los errores en el desarrollo de software? Rica documentación del código Poca o falta de comunicación Complejidad del software Cambios continuos en los requerimientos. ¿Qué tipo de errores se intentan detectar además de los errores de programación o bugs? Defectos de forma. Problemas de hardware. Errores de documentación. Conflictos de personal. ¿Qué se menciona sobre la documentación del código como un factor que contribuye a los errores? Pobre documentación que dificulta la modificación. Exceso de documentación innecesaria. Documentación que se crea muy tarde en el ciclo de vida. Documentación que sólo entienden los programadores. ¿Qué actitud debe tener un tester durante las pruebas? Probar para romper. Probar para corregir. Probar para satisfacer al cliente. Probar para evitar conflictos. Según el texto, ¿en qué entorno NO se deben realizar las pruebas? En el entorno de explotación o producción. En el entorno de desarrollo. En un entorno simulado. En un entorno local. ¿Quién es responsable de llevar a cabo el proceso de pruebas en grandes organizaciones? Un equipo independiente de probadores diferente al de desarrollo. El equipo de desarrollo del software. Los usuarios finales del software. El cliente que solicitó el software. Según el texto, ¿qué enunciado famoso resume la naturaleza de las pruebas? El testing puede probar la presencia de errores, pero no la ausencia de ellos. El testing es una forma de demostrar que el software es perfecto. Cuanto más se prueba un software, menos errores tendrá. El testing debe realizarse al final del ciclo de desarrollo. ¿Qué se dice sobre la relación entre la complejidad del software y la necesidad de personal experto en su desarrollo? La complejidad del software requiere a personas muy expertas. La complejidad reduce la necesidad de personal. La complejidad facilita el desarrollo. La complejidad hace innecesario el testing. ¿Cuál es la principal diferencia entre las pruebas de caja negra y las de caja blanca? Las pruebas de caja negra se centran en la funcionalidad, y las de caja blanca en el código. Las pruebas de caja negra se centran en el código, y las de caja blanca en la funcionalidad. Las pruebas de caja negra son manuales, y las de caja blanca son automatizadas. Las pruebas de caja negra son más completas que las de caja blanca. ¿Qué tipo de prueba se enfoca en verificar la robustez del software ante una gran cantidad de datos o usuarios simultáneos? Prueba de estrés. Prueba de integración. Prueba de interfaces. Prueba de caja negra. ¿Cuál es el objetivo principal de las pruebas de integración? Verificar la compatibilidad y el funcionamiento correcto de las distintas partes del software. Probar el software en condiciones extremas. Validar que el software cumple con los requisitos. Evaluar el rendimiento de la aplicación. ¿Qué se verifica en las pruebas de interfaces? La comunicación eficiente entre diferentes módulos o aplicaciones. La funcionalidad principal de la aplicación. La apariencia visual de la aplicación. El uso de recursos del sistema. ¿Cómo se denomina a la versión de un producto que se distribuye gratuitamente para pruebas a los usuarios? Versión beta. Versión alpha. Versión RTM. Versión master. ¿Cuál es la diferencia principal entre la versión alpha y la versión beta de un software? La versión alpha es para pruebas internas, y la beta para pruebas externas. La versión alpha es la versión final, y la beta una versión de prueba. La versión alpha es una versión estable, y la beta una versión inestable. La versión alpha es para pocos usuarios, y la beta para muchos. ¿Qué significa RTM testing? Release To Market, pruebas en entornos de producción antes del lanzamiento. Requisitos de tiempo y materiales, pruebas de estimación de costes. Return to manufacturer, pruebas de devolución al fabricante. Rapid testing method, pruebas rápidas de funcionalidad básica. Según el texto, ¿qué tipo de pruebas se realizan generalmente después de las pruebas de caja negra y caja blanca? Pruebas de estrés. Pruebas de unidad. Pruebas de aceptación. Pruebas de compatibilidad. ¿Qué tipo de pruebas se basan en el análisis del código interno para comprobar el funcionamiento de la aplicación? Pruebas de caja blanca Pruebas de caja negra Pruebas de integración Pruebas de estrés. ¿Qué tipo de prueba se utiliza para asegurar que los módulos de una aplicación que se desarrollaron por separado se comuniquen correctamente? Pruebas de interfaces Pruebas de estrés Pruebas de carga Pruebas de regresión. ¿Cuál es el principal propósito de la planificación de las pruebas en el ciclo de vida del software? Definir los objetivos de la prueba y la estrategia a seguir. Ejecutar las pruebas lo más rápido posible. Corregir errores de código inmediatamente. Reducir el costo total del proyecto. ¿Qué se menciona en el texto sobre la frecuencia con la que se deben realizar las pruebas en relación al ciclo de vida del software? Las pruebas deben comenzar al inicio del desarrollo y continuar hasta su finalización. Las pruebas deben realizarse solo al final del desarrollo. Las pruebas deben ser opcionales si los plazos son ajustados. Las pruebas solo deben realizarse en la fase de explotación. Según el texto, ¿por qué es importante evitar descuidar la fase de planificación de las pruebas? Para evitar una mala documentación y carencia en la planificación. Para acelerar el proceso de pruebas. Para reducir los costos del proyecto. Para garantizar que el software sea visualmente atractivo. ¿Qué tipo de información debería incluirse en un Plan de Pruebas? Objetivos, módulos a probar, estrategia, criterios de validez e invalidez, requerimientos del entorno. Solo los módulos a probar y las personas responsables. Solo el tiempo que se va a dedicar a las pruebas y los recursos asignados. Solo los criterios de validez del software. ¿Qué sucede a menudo con la fase de pruebas debido a las presiones sobre plazos y costes, según el texto? Es descuidada y sacrificada. Es la fase más importante del proyecto. Es la fase más sencilla del proyecto. Es la fase que siempre se respeta a pesar de las presiones. ¿Cuál es el primer paso en el proceso de pruebas, según el texto? Planificación de las pruebas (elaboración del plan de pruebas). Preparación de los datos de prueba. Codificación de las pruebas. Ejecución de las pruebas. ¿Qué se debe definir en el paso de planificación de las pruebas? Los objetivos de la prueba, quién la realiza y bajo qué condiciones. Los datos de prueba que se utilizarán. El código de las pruebas. El informe final de las pruebas. Según el texto, ¿quiénes NO son los más adecuados para realizar las pruebas? Los propios programadores. Los analistas de sistemas. Los usuarios finales del software. Los jefes de proyecto. ¿Por qué es importante diseñar casos de prueba que tengan una alta probabilidad de encontrar un fallo? Para aumentar la eficiencia del proceso de pruebas. Para que las pruebas sean más rápidas. Para que las pruebas sean más sencillas. Para reducir el costo de las pruebas. ¿Qué tipo de datos se deben incluir al preparar los datos de prueba? Datos válidos, inválidos y fuera de rango. Solo datos válidos. Solo datos inválidos. Solo datos dentro de un rango específico. ¿Qué acción se debe llevar a cabo al detectar un error durante la ejecución de las pruebas? Aislar el error y documentarlo detalladamente. Ignorar el error y continuar con las pruebas. Corregir el error inmediatamente sin documentarlo. Reiniciar las pruebas desde el principio. ¿Qué se incluye en el informe final de las pruebas? Clasificación de los errores encontrados por naturaleza e importancia. Los datos de prueba utilizados. El código de las pruebas. Las opiniones de los testers. ¿Qué se debe especificar en el apartado "Criterios de validez o invalidez del software" del plan de pruebas? Cuando el software se puede dar como válido o inválido según criterios específicos. La duración estimada de las pruebas. Los nombres de los responsables de las pruebas. Los requerimientos de hardware y software. Según el texto, ¿qué es importante recordar acerca de la exhaustividad de las pruebas? Es imposible probar todo, la prueba exhaustiva no existe. Siempre es posible realizar pruebas exhaustivas. Las pruebas exhaustivas deben realizarse siempre. La exhaustividad de las pruebas es irrelevante. ¿Qué debe incluir el apartado "Proceso de pruebas" en el plan de pruebas? La especificación del proceso y los procedimientos de las pruebas a ejecutar. Los resultados de las pruebas anteriores. Las correcciones de los errores encontrados. Los objetivos de negocio de las pruebas. ¿Cuál es el principal objetivo de la fase de "Preparación de los Datos de Prueba"? Diseñar casos de prueba que tengan alta probabilidad de encontrar fallos. Corregir errores de código antes de ejecutar las pruebas. Documentar los resultados de las pruebas ejecutadas. Generar el informe final de las pruebas. Según el texto, ¿qué se debe evitar al diseñar los casos de prueba? Ser redundante. Ser demasiado sencillos. Ser demasiado complejos. Usar siempre datos válidos. En la fase de "Codificación de las Pruebas", ¿qué se necesita generar además de los datos de prueba? Las condiciones necesarias para poder ejecutar los casos de prueba. El informe final de las pruebas. Los objetivos de la prueba. El plan de pruebas. ¿Qué tipo de datos se deben incluir en los "set o conjuntos de datos" durante la "Codificación de las Pruebas"? Datos válidos, inválidos y fuera de rango. Solo datos válidos. Solo datos inválidos. Solo datos dentro del rango especificado. ¿Qué se debe preparar en las máquinas de prueba durante la "Codificación de las Pruebas"? Instalar el software necesario, usuarios y realizar carga del sistema. Realizar las pruebas manualmente. Ejecutar las pruebas en diferentes sistemas operativos. Hacer una copia de seguridad del sistema. ¿Qué acción se debe realizar inmediatamente después de detectar un error durante la "Ejecución de las Pruebas"? Aislar el error y documentarlo detalladamente. Corregir el error e intentar volver a ejecutar la prueba. Ignorar el error y continuar con las pruebas. Rechazar el error por ser aleatorio. Según el texto, ¿qué se debe registrar al documentar un error durante la "Ejecución de las Pruebas"? La acción que se estaba probando, el caso, módulo, fecha, hora y datos utilizados. Solo la acción que se estaba probando y la fecha. Solo el módulo y los datos utilizados. Solo la fecha y la hora del error. Según el texto, ¿qué ocurre generalmente si se encuentra un error en un módulo de software y se insiste en probarlo? Se encontrarán más errores. Se corregirán los errores automáticamente. Los errores se volverán más difíciles de encontrar. No se encontrarán más errores. ¿Cuál es el objetivo principal de la fase de "Generación del Informe Final de las Pruebas"? Detallar formalmente las anotaciones realizadas durante las pruebas y clasificar los errores. Corregir los errores encontrados durante las pruebas. Planificar las próximas pruebas. Validar los datos de prueba utilizados. ¿Quiénes suelen firmar los informes finales de las pruebas, según el texto? Las personas responsables de haber realizado el testing. Los desarrolladores del software. Los usuarios finales del software. Los clientes que solicitaron el software. ¿Cuál es el objetivo principal de las pruebas de rendimiento? Evaluar la rapidez con la que el software realiza una tarea y otros atributos de calidad. Encontrar errores de programación en el código. Verificar que el software cumpla con las especificaciones del cliente. Asegurar que el software sea compatible con diferentes sistemas operativos. ¿Qué tipo de mediciones de rendimiento se pueden realizar? Orientadas al usuario (ej., tiempos de respuesta) y al sistema (ej., uso de la CPU). Solo orientadas al usuario. Solo orientadas al sistema. Solo mediciones de errores. ¿Cuáles son algunos ejemplos de variables que se miden en las pruebas de rendimiento? Tiempo de retorno, tiempo de respuesta, tiempo de reacción, capacidad de ejecución, etc. Número de errores encontrados, complejidad del código, tamaño del software, etc. Número de usuarios que usan el software, cantidad de funcionalidades, etc. Número de líneas de código, número de ciclos del procesador, etc. Según el texto, ¿qué se busca al evaluar la calidad del software? Su adecuación a los fines para los que ha sido construido y que esté libre de errores. Que cumpla con los plazos de entrega. Que se vea bien visualmente y sea fácil de usar. Que sea lo más económico posible. ¿Cuál fue una de las principales características de la crisis del software en los años 90? Calidad insuficiente del producto final. Exceso de personal cualificado. Estimaciones de duración de proyectos muy precisas. Productos simples y poco complejos. ¿Qué aspecto de la calidad del software se menciona además del funcionamiento? El soporte, que incluye formación, asistencia a problemas y mantenimiento. La documentación técnica. El precio de venta del software. La facilidad de instalación. ¿Qué evalúan las pruebas de carga? El comportamiento de una aplicación bajo una cantidad de peticiones esperada. Los límites del sistema bajo condiciones extremas. La capacidad de recuperación del sistema ante fallos. La compatibilidad del software con distintos sistemas operativos. ¿Cuál es el propósito principal de las pruebas de estrés? Determinar la solidez de la aplicación en momentos de carga extrema. Simular el uso normal de la aplicación. Evaluar la rapidez con la que el software realiza una tarea específica. Verificar la compatibilidad con distintas versiones de Java. ¿Qué tipo de pruebas someten la aplicación a una carga continuada? Pruebas de estabilidad. Pruebas de picos. Pruebas de carga. Pruebas de estrés. ¿Qué es un benchmark en el contexto de las pruebas de rendimiento? Una aplicación o conjunto de aplicaciones para evaluar el rendimiento de un ordenador. Un tipo de prueba de seguridad para detectar vulnerabilidades. Una herramienta para crear informes de errores. Un tipo de prueba de caja blanca para evaluar el código. ¿Cuáles son las cuatro categorías generales de pruebas de comparación (benchmarks)? Pruebas de aplicaciones-base, playback, sintéticas e inspección. Pruebas de carga, estrés, estabilidad y picos. Pruebas de caja negra, caja blanca, integración e interfaz. Pruebas unitarias, funcionales, de sistema y de aceptación. ¿Qué hacen las pruebas de aplicaciones-base dentro de las pruebas de comparación? Ejecutan y cronometran los tiempos de las aplicaciones. Usan llamadas al sistema durante actividades específicas. Enlazan actividades de la aplicación en subsistemas específicos. Ejecutan directamente actividades en su entorno productivo. ¿Qué hacen las pruebas playback dentro de las pruebas de comparación? Usan llamadas al sistema durante actividades específicas de una aplicación. Ejecutan y cronometran los tiempos de las aplicaciones. Enlazan actividades de la aplicación en subsistemas específicos. Ejecutan directamente actividades en su entorno productivo. ¿Qué hacen las pruebas sintéticas dentro de las pruebas de comparación? Enlazan actividades de la aplicación en subsistemas específicos. Usan llamadas al sistema durante actividades específicas de una aplicación. Ejecutan y cronometran los tiempos de las aplicaciones. Ejecutan directamente actividades en su entorno productivo. ¿Qué hacen las pruebas de inspección dentro de las pruebas de comparación? Ejecutan directamente actividades en su entorno productivo. Enlazan actividades de la aplicación en subsistemas específicos. Usan llamadas al sistema durante actividades específicas de una aplicación. Ejecutan y cronometran los tiempos de las aplicaciones. Según las normas de estilo de programación en Java, ¿cómo deben comenzar los nombres de las variables? Con minúsculas. Con mayúsculas. Con un guión bajo (_). Con un número. ¿Cómo se deben escribir las variables compuestas en Java según las normas de estilo? Combinando mayúsculas y minúsculas (camelCase). Todo en minúsculas. Todo en mayúsculas. Usando guiones bajos entre palabras. ¿Cómo deben escribirse las constantes en Java, de acuerdo a las normas de estilo? En mayúsculas. En minúsculas. Combinando mayúsculas y minúsculas. Con la primera letra en mayúscula. ¿Cómo se deben escribir los nombres de procedimientos y métodos en Java, según las normas de estilo? Combinando mayúsculas y minúsculas (camelCase). Todo en minúsculas. Todo en mayúsculas. Usando guiones bajos entre palabras. ¿Qué nombres se sugiere usar para los iteradores o variables que recorren una serie de valores en Java? i, j, k, l, etc. a, b, c, d, etc. iter1, iter2, iter3, etc. x, y, z, w, etc. ¿Cuál es la recomendación para dividir líneas de código muy largas? Dividirlas en partes para hacerlas más legibles. Evitar líneas largas a toda costa. Dividirlas con saltos de línea. No dividirlas nunca. Según las normas de estilo, ¿cómo se deben colocar los brackets al declarar un array en Java? Al lado del tipo de dato (ej., double[] lista;). Al lado del nombre de la variable (ej., double lista[];). Indistintamente al lado del tipo o de la variable. No hay una regla definida. Según el texto, ¿cuál es la recomendación sobre el uso de while y do-while en bucles? Utilizar while en vez de do-while. Utilizar do-while en vez de while. Utilizar ambos indistintamente. Evitar ambos tipos de bucles. En el contexto de Java, ¿qué significan las siglas "JAR"? Java Archive Java Application Runner Java Resource File Just Another Release. |
Denunciar Test