Responda a más de 100 MCQ de aseguramiento de la calidad del software y evalúe su conocimiento sobre el aseguramiento de la calidad del software.
¡Desplácese hacia abajo y comience!
A. Prueba de intento del usuario
B. Pruebas de aceptación del usuario
A. Prueba de validación
B. Examen de la unidad
C. Prueba del sistema
D. Pruebas de integración
A. caja negra
B. caja blanca
C. caja de vidrio
D. buzón
A. Un método antiguo para calcular la distancia entre dos objetos
B. un principio o mecanismo por el cual podemos saber si el software funciona de acuerdo con los criterios de alguien;
C. ¡No hay tal cosa!
D. Un método por el cual el aprendizaje tiene lugar como resultado de los descubrimientos informados por la exploración.
A. Para evaluar si el software está listo para su lanzamiento.
B. Para encontrar fallas en el software.
C. Para demostrar que el software es correcto.
D. Para demostrar que el software no funciona.
A. Declaraciones en el programa
B. Rutas lógicas independientes en el programa
C. Errores en el programa
D. Ciclos en el programa
A. Se descubre que el requisito que sugiere implementar ya existe.
B. Su prioridad es muy alta y debe manejarse de inmediato.
C. El equipo de pruebas se encarga de verlo.
D. Es tecnológicamente complejo.
A. FALSO
B. Verdadero
A. FALSO
B. Verdadero
A. Ejercer las condiciones lógicas en un módulo de programa
B. Concéntrese en probar la validez de las construcciones de bucle
C. Confiar en las pruebas de la ruta de base
D. Seleccione rutas de prueba basadas en las ubicaciones y usos de las variables
A. La satisfacción del cliente
B. Seguimiento de defectos
C. Trabajo en equipo
D. Control de configuración
A. Errores de rendimiento
B. Errores tipográficos y errores lógicos
C. Errores tipográficos
D. Errores lógicos
E. Errores de comportamiento
A. Inicial, administrado, definido, cuantitativamente administrado, optimizando
B. Ninguno de éstos
C. Funcionalidad, confiabilidad, usabilidad, eficiencia, mantenibilidad, portabilidad
A. Herramienta utilizada para pruebas no funcionales
B. Herramienta de código abierto de Ware gratis
C. Herramienta de prueba basada en la web
D. sobre todo
E. Herramienta de automatización
A. Caja blanca
B. Caja gris
C. Prueba de Junit
D. Pruebas de integración
E. Caja negra
A. Las pruebas basadas en sesiones son un método de prueba de software que tiene como objetivo combinar la responsabilidad y las pruebas exploratorias para proporcionar un descubrimiento de defectos rápidos, un diseño creativo de prueba sobre la marcha.
B. Las pruebas basadas en la sesión son un método de prueba de software que involucra al probador que registra sus comportamientos para ser revisados en una etapa posterior.
C. Las pruebas basadas en sesiones son un método de prueba de software que tiene como objetivo aumentar los probadores de Junior Skill que podrían no estar tan cómodos con el sistema bajo prueba.
D. Las pruebas basadas en sesiones son un método de prueba de software que tiene como objetivo combinar resultados rápidos con las expectativas de un equipo ágil.
A. Concéntrese en probar la validez de las construcciones de bucle
B. Seleccione rutas de prueba basadas en las ubicaciones y usos de las variables
C. ejercer las condiciones lógicas en un módulo de programa
D. Diar las pruebas de ruta de base
A. Diseño y código de programa interno
B. Requisitos y funcionalidad
C. Cómo funciona una aplicación bajo cargas pesadas
D. Declaraciones de código, ramas, rutas y condiciones
A. Compatibilidad: la mayoría de los emuladores son incompatibles con versiones populares de MS Windows.
B. Problemas de instalación: Instalar y manejar emuladores es más engorroso que manejar hardware real.
C. Falta de confiabilidad: los emuladores pueden no representar las limitaciones de hardware adecuadamente.
D. Falta de confiabilidad: los emuladores pueden no representar la interfaz de usuario adecuadamente.
A. Verdadero
B. FALSO
A. Seleccione rutas de prueba basadas en las ubicaciones y usos de las variables
B. Ejercar las condiciones lógicas en un módulo de programa
C. Confiar en las pruebas de la ruta de base
D. Concéntrese en probar la validez de las construcciones de bucle
A. Excepción
B. Alfa
C. Beta
D. Caja negra
A. Programación extrema
B. Método de cascada
C. Desarrollo ágil
D. Desarrollo impulsado por pruebas
A. Exploración de uso
B. Experiencia de usuario
C. Bajo existencia
D. Experiencia de usabilidad
A. Funciones incorrectas o faltantes
B. Funciones incorrectas o faltantes, y errores de interfaz y errores de rendimiento
C. Errores de interfaz
D. Errores de rendimiento
E. Ninguno de esos
A. El usuario realiza pruebas alfa, mientras que el equipo de pruebas realiza pruebas beta.
B. El usuario realiza pruebas alfa bajo la supervisión del equipo de prueba en el laboratorio de prueba, mientras que las pruebas son realizadas por el usuario en instalaciones del usuario sin supervisión cercana.
C. Las pruebas beta son realizadas por el usuario, mientras que el equipo de pruebas realiza las pruebas alfa.
D. El usuario realiza pruebas beta bajo la supervisión del equipo de prueba en el laboratorio de prueba, mientras que las pruebas alfa son realizadas por el usuario en instalaciones del usuario sin supervisión cercana.
A. Una prueba formal del software
B. Una reunión informal para evaluación o fines informativos
C. Una mirada en profundidad en cómo funciona el software
D. Ninguno de esos
A. La gravedad está determinada principalmente por los factores técnicos, mientras que la prioridad está determinada por los factores relacionados con el negocio.
B. La gravedad está determinada por los desarrolladores y el análisis de negocios, mientras que la prioridad, por el equipo de pruebas.
C. La prioridad está determinada principalmente por los factores técnicos, mientras que la gravedad está determinada por los factores relacionados con el negocio.
D. La gravedad está determinada por las expectativas del usuario, mientras que la prioridad, por el impacto en la funcionalidad.
A. Modelo de seguridad de prueba holística
B. Modelo de estrategia de prueba humana
C. Modelo de estrategia de prueba heurística
D. Gestión de la estrategia de alta tecnología
E. Modelo de estrategia de equipo hueco
A. Probándolos en lugar de tratar de probar un gran conjunto de entradas.
B. Un tipo especial de identificador de recursos universales (URI).
C. Cifrado que puede proteger el canal sobre el cual ocurre su conversación.
D. Un valor de valor clave se combina con un signo igual (=) entre la clave y el valor.
A. Plan - ACT - CHECK - DO
B. Plan - Do - Check - Act
C. Plan - Compruebe - ACT - DO
D. Plan - Compruebe - Do - ACT
A. Usabilidad
B. Actuación
C. Caja negra
D. Funcionalidad
A. Usuarios
B. Desarrolladores
C. Atención al cliente
D. Ingenieros de prueba
A. Seguro de calidad
B. Control de detectives
C. Control de calidad
D. Control correctivo
A. Un proceso en el que las pruebas solo toman valores de límite para las pruebas
B. Un proceso en el que el probador toma valores de límite y valores medios para probar
A. Un lector
B. Una grabadora
C. El desarrollador
D. Un moderador
A. Sugiriendo un horario de lanzamiento.
B. Presentar el estado de calidad de la prueba bajo prueba a los tomadores de decisiones.
C. Tomar la decisión de liberar la prueba del sistema en producción.
D. Invocar al defensor del usuario cuestionando las decisiones de diseño.
A. Las principales funciones de control se pueden probar temprano.
B. Se elimina la necesidad de programas Stub.
C. Las condiciones de prueba son más fáciles de crear.
D. La observación de los resultados de la prueba es más fácil.
A. Incapacidad para leer datos fuera de los campos de aplicaciones.
B. Incapacidad para automatizar las pruebas de localización que requieren cambios de configuración a nivel de dispositivo.
C. Incapacidad para comparar imágenes.
D. Incapacidad para automatizar el clic de los objetos de la aplicación y hacer selecciones desplegables.
A. El procedimiento es lo que debe suceder y el proceso es el paso a paso de cómo sucederá
B. El procedimiento es quién ejecuta las pruebas necesarias y el proceso es cuándo se ejecutará
C. El proceso es quién ejecuta las pruebas necesarias y el procedimiento es cuándo se ejecutará
D. El proceso es lo que debe suceder y el procedimiento es el paso a paso de cómo sucederá
A. Tablero de control de configuración
B. Equipo de desarrollo de software
C. Tablero de control de cambios
D. Enlace del cliente
A. Los defectos son desviaciones de los requisitos, mientras que las solicitudes de cambio son sugerencias sobre cómo alterar los requisitos.
B. Los defectos son registrados por los ingenieros de pruebas, mientras que las solicitudes de cambio, por los analistas de negocios.
C. Son manejados por diferentes sistemas de registro.
D. Los defectos siempre tienen un riesgo asociado con su resolución, mientras que las solicitudes de cambio no.
A. Prueba beta
B. Prueba alfa
C. Prueba de mantenimiento
D. Prueba del sistema
E. Pruebas de integración
A. Verdadero
B. FALSO
A. Entregado a tiempo
B. Cumple con los requisitos y expectativas
C. Entregado dentro del presupuesto
D. Completamente libre de errores
A. Técnica de caja negra
B. Técnica de caja de vidrio
C. Técnica de caja blanca
A. Prueba de usabilidad
B. Prueba de seguridad
C. Prueba funcional
D. Pruebas de rendimiento
A. Subversión
B. Git
C. CVS
D. Estudio visual
A. Prueba del mismo módulo después de que se corrige el error
B. Prueba de los módulos efectivos después de que el error se solucione
C. Sin arreglar si probamos el defecto nuevamente
A. Tratar solo con interfaces.
B. Concéntrese en el comportamiento del sistema bajo estrés.
C. No voy a repetirse.
D. Están bien documentados y fáciles de ejecutar manualmente.
A. Prueba de usabilidad
B. Prueba alfa
C. Prueba beta
D. Pruebas de aceptación del usuario
A. Tomando solo con los valores de rango
B. Solo tome valores de límite para las pruebas
C. En el que tomamos los valores de límite y el valor medio para las pruebas
A. Defectos por el número de reapensiones (reelaboración).
B. Defectos por estado y gravedad.
C. Defectos por asignación del desarrollador.
D. Defectos por prioridad.
A. Diagrama de diseño
B. Lista de características a probar y no probarse
C. Supuestos/condiciones previas
D. Introducción
A. Establecer la responsabilidad personal del ingeniero de pruebas
B. Proporcionar datos de prueba
C. Asegurar la cobertura
D. Resultados de la prueba de documento
A. Imite ráfagas cortas de usuarios concurrentes mientras mide el uso de la memoria.
B. Ejercar la funcionalidad de la prueba de bajo sistema con el tiempo con el tiempo mientras mide el uso de la memoria.
C. Concéntrese en el relleno de la base de datos y específicamente en las tablas de registro.
D. Mida el tiempo de respuesta en el cliente y en el servidor.
A. Diseño
B. Mantenimiento
C. Actuación
D. Requisitos
E. Codificación
A. de comportamiento
B. buzón
C. caja negra
D. caja blanca
A. Iniciar inspecciones de código para identificar defectos en el código
B. Anime a los programadores a esforzarse más para hacer menos defectos
C. Aumentar el tipo y el alcance de la prueba para eliminar los defectos antes de la producción
D. Clasifique y cuente los defectos para que pueda identificar el defecto de la mayor frecuencia y eliminar la causa raíz del defecto
A. V-Modelo
B. Modelo lineal
C. Modelo espiral
D. Modelo de cascada
A. Este es un proceso de desarrollo de software iterativo e incremental y esto puede apuntar depende de las características.
B. Ninguna de las anteriores
C. Este es un enfoque iterativo e incremental que enfatiza la participación continua del usuario.
D. Esta es una técnica que tiene iteraciones cortas en las que primero se escriben nuevas casos de prueba que cubren la mejora deseada o la nueva funcionalidad.
A. Verdadero
B. FALSO
A. Plan de prueba
B. Especificación
C. Documento de requisitos
D. Caso de prueba
A. Módulo
B. Nodo traza
C. Cama de prueba
D. Lote
A. Robotium
B. QTP
C. Selenio
D. Jmeter
A. Diseño, requisitos, implementación, verificación, mantenimiento
B. Requisitos, diseño, verificación, implementación, mantenimiento
C. Requisitos, diseño, implementación, verificación, mantenimiento
D. Mantenimiento, requisitos, diseño, implementación, verificación
A. Gerente de proyecto
B. Cliente
C. Desarrolladores
D. Ingeniero de software
A. Documentación de scripts de prueba, seguimiento métrico, prueba de carga
B. Comprobación de límites, pruebas ad-hoc, combinación de instalación
C. Prueba de nuevas características y funciones, comprobaciones de integridad de datos, pruebas de regresión
A. QA es parte del proceso de prueba de software
B. La prueba de software es parte del proceso de control de calidad
C. Las pruebas de software y el control de calidad son lo mismo
D. Las pruebas de software y el control de calidad son dos procesos diferentes
A. Verdadero
B. FALSO
A. control de configuración
B. Solicitud de cambio
C. especificación
D. módulo de software
A. Garantía de calidad del software
B. Planificación
C. Pruebas
D. Desarrollo de software
A. FALSO
B. Verdadero
A. ISO 9002
B. ISO 9000
C. ISO 9003
D. ISO 9001
A. No puede comparar números en tal conjunto
B. & gt;
C. =
D. & lt;
A. Verdadero
B. FALSO
A. Fiabilidad
B. Usabilidad
C. Costo
D. Exactitud
A. Documentación de prueba
B. Prueba de procedimiento
C. Prueba estructural
D. Prueba funcional
A. Aceptacion de usuario
B. Estrés
C. Usabilidad
D. Supervivencia y recuperación
A. Todos estos son modelos de calidad
B. ISO 9000
C. ISO/IEC 15504
D. Cmmi
A. Pruebas de integración
B. Prueba de caja blanca (vidrio)
C. Prueba de caja negra
D. Prueba de caja gris
A. Verdadero
B. FALSO
A. Verdadero
B. FALSO
A. Aceptación del cliente
B. Condiciones de borde
C. Prueba negativa
D. Manejo de errores
A. Estabilidad y observabilidad
B. Observabilidad, simplicidad y estabilidad
C. Observabilidad
D. Sencillez
E. Estabilidad
A. Prueba de caja negra
B. Examen de la unidad
C. Ninguno de esos
D. Prueba de caja blanca
A. Documentación
B. Prueba
C. Reseñas y auditorías
D. Presupuesto
A. Ninguno de esos
B. Integración del modelo de madurez de la capacidad
C. Iniciación de gestión de madurez de conexión
D. Instituto modular de maduración de capacidad
A. Para hacer recomendaciones
B. Para encontrar problemas y ver qué falta
C. Para arreglar el software
D. Para recopilar información preliminar
A. No
B. Sí
A. Inyección SQL
B. Partición de equivalencia
C. Pruebas alfa
D. Registro visual
A. alfa y beta
B. Poseer y negativo
A. Ambos errores en diseño y errores en la implementación
B. Errores en el diseño
C. Errores en precisión
D. Errores en la implementación
E. Errores en operación
A. FALSO
B. Verdadero
A. Apoyar la gestión del cambio
B. Administrador de cambios de software
C. Gestión de la cadena de suministro
D. Gestión de configuración de software
A. Enfoque de abajo hacia arriba
B. Todas las de arriba
C. Enfoque de Big Bang
D. Enfoque de arriba hacia abajo
A. Prueba funcional
B. Prueba del sistema
C. Pruebas de regresión
D. Test de aceptación
A. Analistas de negocios
B. Usuarios
C. Ingenieros de prueba
D. Desarrolladores
A. Cronograma
B. (todos estos)
C. Acercarse
D. Alcance
E. Recursos
A. Número de errores de software desconocidos.
B. Número de palabras en el plan de prueba.
C. Número de líneas de código ejecutadas en el software que se está probando.
D. Número de casos de prueba que pasaron vs fracasaron.