wayground logo

Free Printable Worksheets

Font size

S
M
L
XL
Worksheets

Testing 2

Total questions: 60

Worksheet time: 30mins

Name
Class
Date
1.

¿Cuál es el objetivo principal de las pruebas de software?

a)
  • Aumentar el rendimiento del hardware

b)
  • Mejorar la calidad del software y garantizar que sea lo más libre de errores posible

c)
  • Reducir el costo del desarrollo

d)
  • Incrementar la complejidad del código

2.

¿En qué etapa del ciclo de vida del desarrollo de software se pueden realizar pruebas?

a)
  • Solo en la fase de implementación

b)
  • Desde la fase de diseño hasta el mantenimiento

c)
  • Exclusivamente durante el mantenimiento

d)
  • Solo en la fase de pruebas finales

3.

¿Qué tipo de pruebas se enfoca en la funcionalidad sin considerar el código subyacente?

a)
  • Pruebas de caja blanca

b)
  • Pruebas exploratorias

c)
  • Pruebas de caja negra

d)
  • Pruebas automatizadas

4.

¿Cuál de las siguientes afirmaciones sobre las pruebas automatizadas es verdadera?

a)
  • Son útiles solo para pruebas de seguridad

b)
  • Se realizan manualmente

c)
  • Son efectivas para pruebas repetitivas y para diferentes entornos

d)
  • No requieren herramientas especializadas

5.

¿Cuál de las siguientes metodologías busca descubrir problemas sin un plan específico?

a)
  • Pruebas de caja blanca

b)
  • Pruebas de caja negra

c)
  • Pruebas exploratorias

d)
  • Pruebas automatizadas

6.

¿Qué tipo de pruebas se centra en detectar vulnerabilidades en el software?

a)
  • Pruebas de caja blanca

b)
  • Pruebas de seguridad

c)
  • Pruebas manuales

d)
  • Pruebas exploratorias

7.

¿Qué se entiende por caso de prueba (test case)?

a)
  • Un error cometido por un programador

b)
  • Un conjunto de entradas y condiciones que arrojan resultados esperados

c)
  • Una norma de calidad del software

d)
  • Una evaluación de fallos en el software

8.

¿Qué es un error en el contexto del software?

a)
  • Un defecto encontrado en el software

b)
  • Una acción humana que produce un resultado incorrecto

c)
  • Una falla en el sistema

d)
  • Un estándar de calidad

9.

¿Cómo se define un defecto en el software?

a)
  • La manifestación visible de un fallo

b)
  • Un resultado correcto de un caso de prueba

c)
  • La manifestación de un error en el software que causa una falla

d)
  • Un conjunto de entradas y condiciones

10.

¿Qué fundamento de las pruebas se enfoca en que el software haga lo que no debe hacer?

a)
  • Comprobar la eficiencia del software

b)
  • Evaluar los efectos secundarios

c)
  • Verificar la compatibilidad

d)
  • Garantizar la usabilidad

11.

¿Qué área no está incluida en la evaluación del marco de referencia ISO IEC 25000?

a)
  • Usabilidad

b)
  • Seguridad

c)
  • Innovación

d)
  • Mantenibilidad

12.

¿Qué es el ciclo de vida del desarrollo de software (SDLC)?

a)
  • Un modelo para evaluar la calidad del software

b)
  • Un proceso para diseñar y crear software de alta calidad

c)
  • Un método de gestión de proyectos no relacionado con el software

d)
  • Una técnica de prueba de software

13.

¿Cuál es el objetivo principal del SDLC?

a)
  • Aumentar el costo del proyecto

b)
  • Minimizar los riesgos del proyecto mediante una planificación anticipada

c)
  • Maximizar la duración del desarrollo

d)
  • Eliminar todas las pruebas del proceso

14.

¿Qué modelo de ciclo de vida del desarrollo de software presenta etapas en un orden secuencial?

a)
  • Modelo ágil

b)
  • Modelo en espira

c)
  • Modelo en cascada

d)
  • Modelo incremental

15.

¿Qué son los requerimientos funcionales?

a)
  • Características que describen cómo un sistema debe comportarse

b)
  • Descripciones detalladas de las funciones y características del sistema

c)
  • Requisitos que no están relacionados con la funcionalidad del sistema

d)
  • Normas de seguridad para el software

16.

¿Cuál es la diferencia principal entre requerimientos funcionales y no funcionales?

a)
  • Los requerimientos funcionales se centran en cómo hace el sistema las cosas, mientras que los no funcionales en qué hace

b)
  • Los requerimientos funcionales son menos importantes que los no funcionales

c)
  • Los requerimientos no funcionales son irrelevantes para el desarrollo

d)
  • Los requerimientos funcionales describen qué hace el sistema, y los no funcionales se centran en cómo lo hace

17.

¿En qué consiste el proceso de pruebas?

a)
  • Una verificación estática del código fuente

b)
  • Un conjunto infinito de pruebas para encontrar todos los errores posibles

c)
  • Una verificación dinámica del comportamiento del software mediante casos de prueba

d)
  • Un procedimiento para documentar los errores encontrados

18.

¿Cuáles son los elementos fundamentales de una prueba?

a)
  • Código, diseño y evaluación

b)
  • Acciones, valores de prueba y resultado

c)
  • Funcionalidad, rendimiento y seguridad

d)
  • Planificación, desarrollo y despliegue

19.
  • Según Pressman, ¿qué implica la verificación en el desarrollo de software?

a)
  • Garantizar que el software cumpla con los requerimientos del cliente

b)
  • Asegurar que el software implementa correctamente una función específica

c)
  • Comprobar que el software es fácil de usar

d)
  • Evaluar la eficiencia del software

20.

¿Cómo define Boehm la verificación?

a)
  • ¿Estamos construyendo el producto correcto?

b)
  • ¿Es el software seguro?

c)
  • ¿Cumple el software con las expectativas del usuario?

d)
  • ¿Estamos construyendo el producto correctamente?

21.

Según Sommerville, ¿qué busca la validación?

a)
  • Asegurar que el software hace lo que el usuario espera

b)
  • Comprobar que el sistema cumple con los requerimientos especificados

c)
  • Verificar la eficiencia del sistema

d)
  • Evaluar la calidad del código

22.

¿Qué son los bugs en el contexto del software?

a)
  • Errores en el diseño

b)
  • Defectos del programa que se encuentran operando

c)
  • Documentación inexacta

d)
  • Cualquier tipo de falla en el hardware

23.

¿Qué caracteriza a un caso de prueba (test case)?

a)
  • Un documento que describe errores potenciales

b)
  • Un conjunto de condiciones bajo las cuales se determinará la aceptabilidad de un sistema

c)
  • Un plan para la implementación del software

d)
  • Un protocolo de revisión de código

24.

¿Cuál es una diferencia clave entre pruebas estáticas y dinámicas?

a)
  • Las pruebas estáticas se realizan sin ejecutar el código, mientras que las dinámicas requieren ejecución

b)
  • Las pruebas dinámicas son más baratas que las estáticas

c)
  • Las pruebas estáticas se centran en la detección de defectos, mientras que las dinámicas en la prevención

d)
  • Las pruebas estáticas se realizan al final del desarrollo, y las dinámicas al inicio

25.

¿Qué tipo de técnicas se utilizan en pruebas estáticas?

a)
  • Pruebas funcionales

b)
  • Ejecución de casos de prueba

c)
  • Revisión técnica, inspección y revisión de código

d)
  • Análisis de rendimiento

26.
  • ¿Qué se prueba en las pruebas unitarias?

a)
  • Todo el sistema en su conjunto

b)
  • Unidades o conjuntos de unidades aisladas del software

c)
  • Solo la interfaz de usuario

d)
  • La integración entre módulos

27.

¿Cuál es el enfoque principal de las pruebas unitarias?

  • A)

  • B)

  • C) D)

a)
  • Verificar el rendimiento del sistema

b)
  • Evaluar la usabilidad del software

c)
  • Validar la documentación del proyecto

d)
  • Detectar discrepancias entre los requerimientos y el comportamiento real de la unidad

28.

¿Qué son las pruebas de caja blanca?

a)
  • Pruebas que se realizan sin conocer el código

b)
  • Pruebas que se basan en el conocimiento interno del código de un programa

c)
  • Pruebas exclusivamente enfocadas en la interfaz de usuario

d)
  • Pruebas que se realizan solo en el entorno de producción

29.

¿Cuál es el objetivo de las pruebas de caja blanca?

a)
  • Asegurar que el software cumpla con los requerimientos del cliente

b)
  • Realizar pruebas que cubran la estructura interna de un sistema

c)
  • Evaluar la experiencia del usuario

d)
  • Identificar errores en el diseño del software

30.

¿Qué técnica de pruebas de caja blanca se enfoca en medir cuántas líneas de código se han ejecutado?

a)
  • Prueba de cobertura de decisión

b)
  • Prueba de cobertura de condición

c)
  • Prueba de cobertura de sentencia

d)
  • Prueba de flujo de trabajo

31.

¿Qué mide la prueba de cobertura de condición?

a)
  • La cantidad de código ejecutado

b)
  • Todos los caminos posibles en el código

c)
  • Todas las condiciones de las estructuras de control

d)
  • El rendimiento del sistema

32.

¿Cuál es el enfoque de la prueba de cobertura de decisión?

a)
  • Asegurarse de que todos los errores sean encontrados

b)
  • Probar todos los caminos posibles que puede tomar el código

c)
  • Medir el tiempo de ejecución del código

d)
  • Evaluar la satisfacción del usuario

33.

¿Qué es una prueba de caja negra?

a)
  • Una prueba que evalúa la lógica interna del sistema

b)
  • Una prueba que analiza la compatibilidad entre las interfaces de componentes del software

c)
  • Una prueba enfocada en el rendimiento del sistema

d)
  • Una prueba que solo verifica la usabilidad del software

34.

¿Cuál de las siguientes afirmaciones es correcta sobre las pruebas de caja negra?

a)
  • Considera la lógica interna del sistema

b)
  • Se basa únicamente en la revisión de código

c)
  • Permite la revisión final de especificaciones y codificación de un programa

d)
  • Se realiza solo en la etapa final del desarrollo

35.

¿Qué técnica de prueba de caja negra se basa en los requisitos del sistema y los casos de uso?

a)
  • Prueba de límites

b)
  • Prueba de errores comunes

c)
  • Prueba de casos de uso

d)
  • Prueba aleatoria

36.

¿Cuál es el objetivo de las pruebas de integración?

a)
  • Probar cada módulo de forma individual

b)
  • Verificar que los diferentes módulos funcionen en armonía al integrarse

c)
  • Asegurar que el sistema cumpla con los requisitos del usuario

d)
  • Medir el rendimiento del sistema

37.

¿Qué tipo de prueba de caja negra se centra en probar las entradas que suelen generar errores?

a)
  • Prueba de interoperabilidad

b)
  • Prueba de límites

c)
  • Prueba de errores comunes

d)
  • Prueba de casos de uso

38.

¿Qué evalúan las pruebas de interoperabilidad?

a)
  • La capacidad del sistema para realizar operaciones internas

b)
  • La capacidad del sistema para comunicarse e interactuar con otros sistemas

c)
  • La eficiencia del código

d)
  • La satisfacción del usuario final

39.

Las pruebas de integración ayudan a:

a)
  • Detectar errores en la codificación

b)
  • Prevenir contratiempos posteriores tras la integración de componentes

c)
  • Mejorar la experiencia del usuario

d)
  • Validar los requisitos del sistema

40.

¿Qué son las pruebas de integración de componentes?

a)
  • Pruebas que se centran en la interacción entre distintos sistemas

b)
  • Pruebas enfocadas en la interacción de interfaces entre componentes integrados

c)
  • Pruebas realizadas únicamente en la fase de desarrollo

d)
  • Pruebas que no requieren automatización

41.

¿Cuál es una ventaja de automatizar las pruebas de integración de componentes?

a)
  • Aumenta la calidad del código

b)
  • Reduce el tiempo y costo de las pruebas

c)
  • Facilita la documentación del proceso

d)
  • Permite la prueba de todos los sistemas externos

42.

¿Cuál es el propósito de un STUB en las pruebas de integración?

a)
  • Realizar pruebas de seguridad

b)
  • Facilitar la documentación de pruebas

c)
  • Probar la lógica interna del sistema

d)
  • Actuar como sustituto de componentes no desarrollados

43.

En qué consiste la estrategia Big Bang de integración?

a)
  • Integrar componentes de manera incremental

b)
  • Realizar pruebas sin planificación

c)
  • Integrar todos los componentes al mismo tiempo antes de iniciar las pruebas

d)
  • Combinar enfoques top-down y bottom-up

44.

¿Cuál es el enfoque de la estrategia Hybrid en las pruebas de integración?

a)
  • Combina pruebas manuales y automatizadas

b)
  • Utiliza solo la estrategia Top-Down

c)
  • Aplica estrategias top-down y down-top de forma conjunta

d)
  • Se basa únicamente en pruebas de sistema

45.

¿Cuál es el objetivo principal de las pruebas de sistemas?

a)
  • Verificar la documentación del software.

b)
  • Asegurar la capacitación del personal.

c)
  • Evaluar el costo del desarrollo.

d)
  • Comprobar la integración del sistema de información con otros sistemas.

46.

¿Cuáles son las etapas del proceso de prueba de un sistema?

a)
  • Preparación de pruebas y aplicación de pruebas.

b)
  • Análisis de requerimientos y diseño.

c)
  • Codificación y depuración.

d)
  • Planificación y despliegue.

47.

Las pruebas funcionales se dirigen a:

a)
  • Asegurar que el sistema realiza correctamente las funciones especificadas.

b)
  • Comprobar la adaptabilidad del sistema.

c)
  • Evaluar el rendimiento bajo carga.

d)
  • Verificar la seguridad de los datos.

48.

¿Cuál de las siguientes es una actividad de la etapa de preparación de pruebas?

a)
  • Realizar pruebas de rendimiento.

b)
  • Desarrollar el software.

c)
  • Preparar un plan de pruebas.

d)
  • Integrar los componentes del sistema.

49.

Las pruebas de comunicación se enfocan en:

a)
  • Asegurar que las interfaces entre los componentes funcionan adecuadamente.

b)
  • Verificar la adaptabilidad del sistema a los usuarios.

c)
  • Comprobar la recuperación ante fallos.

d)
  • Evaluar la carga máxima del sistema.

50.

¿Cuál es el objetivo principal de las pruebas funcionales?

a)
  • Verificar que el software funcione de acuerdo con los requisitos especificados.

b)
  • Evaluar atributos de calidad del software.

c)
  • Comprobar la seguridad del sistema.

d)
  • Analizar el rendimiento bajo carga.

51.

¿Qué pasos generales se deben seguir para realizar pruebas funcionales?

a)
  • Desarrollar nuevos requisitos, realizar pruebas de carga, verificar la seguridad, documentar resultados.

b)
  • Preparar un entorno de pruebas, entrenar al personal, implementar el sistema, revisar la documentación.

c)
  • Identificar datos de entrada, determinar resultados esperados, ejecutar casos de prueba, comparar resultados.

d)
  • Hacer una prueba de humo, realizar pruebas de regresión, llevar a cabo una auditoría, finalizar el desarrollo.

52.

¿Qué son las pruebas de humo?

a)
  • Pruebas exhaustivas de todas las funcionalidades del software.

b)
  • Pruebas rápidas para verificar las funcionalidades más significativas de la aplicación.

c)
  • Pruebas de seguridad para evaluar vulnerabilidades.

d)
  • Pruebas que se realizan solo en entornos de producción.

53.

¿Cuál es el propósito de las pruebas de cordura o sanidad?

a)
  • Comprobar la estabilidad de una nueva compilación después de modificaciones menores.

b)
  • Realizar pruebas exhaustivas en todas las funcionalidades.

c)
  • Evaluar la seguridad del sistema ante ataques externos.

d)
  • Validar la integración con otros sistemas.

54.

¿Cómo se relacionan las pruebas de cordura con las pruebas de regresión?

a)
  • Son independientes y se realizan en diferentes momentos.

b)
  • Las pruebas de cordura son subpruebas de las de regresión, relacionadas con cambios específicos.

c)
  • Ambas pruebas se realizan al mismo tiempo y con los mismos objetivos.

d)
  • Las pruebas de regresión se realizan solo si las de cordura fallan.

55.

¿Cuál de las siguientes afirmaciones es verdadera sobre las pruebas no funcionales?

a)
  • Son irrelevantes para la calidad del software.

b)
  • Se centran en la funcionalidad específica del software.

c)
  • Solo se realizan al final del ciclo de desarrollo.

d)
  • Evalúan aspectos como rendimiento y usabilidad, no directamente funciones del software.

56.

¿Cuáles son las similitudes entre las pruebas de humo y las pruebas de sanidad? elegir mas de una

a)
  • Ambas son pruebas rápidas y enfocadas.

b)
  • Ambas cubren un amplio rango de funcionalidades.

c)
  • Ambas se utilizan después de cambios en el código.

d)
  • Ambas se enfocan en un conjunto limitado de funcionalidades clave.

57.

¿Cuál es la principal diferencia entre las pruebas de humo y las pruebas de sanidad?

a)
  • Las pruebas de humo tienen un alcance más profundo.

b)
  • Las pruebas de sanidad se realizan tras cada nueva compilación.

c)
  • Las pruebas de humo confirman la estabilidad inicial, mientras que las de sanidad se enfocan en áreas específicas.

d)
  • Las pruebas de sanidad se ejecutan antes de los cambios en el código.

58.

¿Qué es el objetivo de las pruebas de integración?

a)
  • Verificar la funcionalidad mínima del software.

b)
  • Probar cómo los módulos funcionan al integrarse.

c)
  • Asegurar que no haya errores en la compilación.

d)
  • Realizar pruebas en un ambiente real

59.

¿Qué se busca con las pruebas de regresión?

a)
  • Verificar la estabilidad del sistema después de cambios menores.

b)
  • Asegurarse de que cambios recientes no introduzcan errores en funcionalidades existentes.

c)
  • Comprobar la interfaz de usuario.

d)
  • Realizar pruebas en el ambiente real del usuario.

60.

¿Cuál es el propósito de las pruebas de aceptación?

a)
  • Validar cambios menores en el código.

b)
  • Comprobar la funcionalidad del software en un ambiente de prueba.

c)
  • Verificar que el software cumpla con los requisitos del cliente en un ambiente real.

d)
  • Identificar problemas en la interfaz de usuario.