Si un programa se ha probado y se logra la cobertura de condiciones 100%, ¿Cuál de los siguientes criterios de cobertura está garantizado luego de ser alcanzado? Cobertura de ramas 100%. 100% cobertura de condición y 100% cobertura de sentencia. Clase equivalencia y la cobertura de valores limite. Ningún otro criterio de cobertura de caja blanca se garantiza que se cumpla 100%.
Es modelo en V: Uno modelo de desarrollo de software que ilustra cómo las actividades de prueba se integran con las fases de desarrollo de software. Un modelo de ciclo de vida del software que no es relevante para la prueba. El desarrollo de software y modelo de ciclo de vida de pruebas perteneciente al ISTQB. Un modelo de ciclo de vida de pruebas incluyendo la unidad, la integración, el sistema y las fases de aceptación.
¿Por qué es necesario definir una estrategia de prueba? Como hay muchas maneras diferentes para probar el software, debe pensarse y decir cual va a ser la forma más eficaz para poner a prueba el presente proyecto. Empezar el proceso de pruebas sin una planificación previa conduce a un proyecto de prueba caótico e ineficiente. Se necesita una estrategia para informar a la gestión de proyectos como el equipo de prueba va a programar los ciclos de prueba. Las fallas de software pueden causar la perdida de dinero, tiempo, reputación empresarial, y en casos extremos, lesiones y muerte. Por tanto, es fundamental contar con una estrategia de pruebas planteada.
¿Cuál de los siguientes es el principal objetivo de la estrategia de integración de las pruebas de integración en el pequeño? Para asegurar que todos los pequeños módulos son probados adecuadamente. Para asegurar que las interfaces del sistema con otros sistemas y redes. Para especificar que módulos para combinar cuándo y cuantas a la vez. Para especificar cómo el software debe ser dividido en módulos.
Los incidentes no se deben plantear en contra de: Requisitos. Documentación. Casos de prueba. Mejoras sugeridas por los usuarios.
Las pruebas betas son: Realizado por los clientes en su propio sitio. Realizado por los clientes en el sitio del desarrollador de software. Realizado por un equipo de pruebas independiente. Realizado lo antes posible en el ciclo de vida.
El estándar que proporciona definiciones de términos de prueba es: ISO / IEC 12207 BS 7925-1 ANSI / IEEE 829 ANSI / IEEE 729.
El costo de arreglar una falla: No es importante. Aumenta cuanto más tarde se encuentra la falla. Disminuye cuanto más tarde se encuentra la falla. Nunca se puede determinar.
Las entradas para el desarrollo de un plan de pruebas se timan de: El plan de proyecto. El plan de negocios. El plan de apoyo. Ninguna de las anteriores.
¿Cuál de las siguientes sentencias podría ser una razón para fracasar?
1. Falla de Pruebas.
2. Falla de software.
3. Falla de diseño.
4. Falla de ambiente.
5. Falla de documentación. 2 es una razón válida; 1, 3, 4 y 5 no lo son. 1, 2, 3, 4 son razones válidas; 5 no lo es. 1, 2, 3 son razones válidas; 4 y 5 no lo son. Todas ellas son razones válidas.
Verificación es: Comprobar que estamos construyendo el sistema correcto. Comprobar que estamos construyendo bien el sistema. Realizada por un equipo de pruebas independiente. Asegurar que es lo que el usuario realmente quiere.
Matriz Función / Prueba es un tipo de Informe de prueba previsional. Informe de prueba final. Informe de estado de proyecto. Informe de gestión.
Las pruebas de software representa a qué porcentaje de los costos de desarrollo de software? 10-20 40-50 70-80 5-10.
¿Cuánto probar? Esta pregunta es imposible de contestar. La respuesta depende de los riesgos para su industria, el contrato y los requisitos especiales. La respuesta depende de la madurez de sus desarrolladores. La respuesta debe ser estandarizada para la industria de desarrollo de software.
Partición de equivalencia es: Una técnica de pruebas de caja negra utilizada sólo por los desarrolladores. Una técnica de prueba de caja negra que sólo se puede utilizar durante las pruebas del sistema. Una técnica de prueba de caja negra adecuado para todos los niveles de prueba. Una técnica de prueba de caja blanca apropiado para pruebas de componentes.
¿Qué es falla? Desviación del resultado esperado al resultado real. Defecto en el software. Error en el código del programa. Avería en el sistema.
Uno de los siguientes no es una parte de las pruebas de caja blanca según las normas BS7925-II. Pruebas al azar. Prueba de flujo de datos. Prueba de declaración. Prueba de sintaxis.
¿Qué herramienta se utiliza para probar los puntos de fuga de memoria y punteros sin asignar? Herramientas de análisis dinámico. Herramientas de análisis estático. Herramientas de mantenimiento. Herramientas de configuración.
La cantidad de pruebas realizadas no dependerán de: Los riesgos involucrados. Los requisitos contractuales. Los requerimientos legales. Los datos de prueba.
¿Cuál de las siguientes ofrece el mayor potencial de ahorro del uso de CAST? Gestión de prueba. Diseño de prueba. La planificación de prueba. Ejecución de la prueba.
Las pruebas no están hechas para Encontrar fallas. Mejorar la calidad. Comprobar si es amigable. Mejorar la precisión del software.
¿Cuál de los siguientes es un tipo de prueba no funcional? Prueba de usabilidad. Cobertura de sentencia. Prueba de flujo de datos. Gráfico de causa-efecto.
¿Cuál de los siguientes es cierto del modelo en V? Incluye la verificación de diseños. Afirma que los módulos se prueban contra los requerimientos del usuario. Se especifican las técnicas de prueba que deberán utilizarse. Solo se modela la fase de pruebas.
¿Cuál de las siguientes afirmaciones es verdadera respecto a análisis estáticos? La compilación de un código no es una forma de análisis estáticos. El análisis estático no tiene por qué llevarse a cabo antes de la ejecución de código imperativo. El análisis estático puede encontrar fallas que son difíciles de encontrar con pruebas dinámicas. No será necesario análisis estadístico amplio si las pruebas white box se van a realizar.
Las pruebas de regresión siempre implican: Probar si se ha arreglado la falla conocida de un software. La ejecución de un gran número de pruebas diferentes. Probar si las modificaciones han introducido efectos secundarios adversos. El uso de herramientas de autorización de pruebas.
¿Cuál de los siguientes no es una característica de las pruebas de aceptación de usuario? Uso de herramientas automáticas para ejecución de pruebas. Pruebas realizadas por los usuarios. Pruebas realizadas contra los clientes de pruebas. integración del sistema con documentación de usuario.
Los resultados esperados son: Sólo es importante en las pruebas del sistema Sólo se utiliza en la prueba de componentes Más útil cuando se especifica por adelantado Derivado del código.
Qué tipo de revisión requiere criterios formales de entrada y salida, incluyendo métricas: Paso a paso Inspección Revisión de la dirección Revisión post proyecto.
¿Cuál de los siguientes utiliza el análisis de impacto más? Prueba de componentes Pruebas no funcionales del sistema Pruebas de aceptación por parte del usuario Pruebas de mantenimiento.
¿Qué NO se incluye en los costos típicos para un proceso de inspección? Creación de formularios y bases de datos Analizar las métricas y mejorar los procesos La redacción de los documentos a inspeccionar Tiempo dedicado al documento fuera de la reunión.
¿Cuál de los siguientes NO es un objetivo de prueba razonable: Para encontrar fallas en el software Probar que el software no tiene fallas Dar confianza en el software Encontrar problemas de rendimiento.
¿Qué expresión mejor coincide con las siguientes características de los procesos de revisión:
1. Dirigido por el autor
2. Indocumentado
3. Ninguna participación de la dirección
4. Dirigido por un moderador o líder
5. Utiliza criterios de entrada y salida
s) Inspección
t) Revisión inter pares
u) Revisión informal
v) Guía práctica
s = y 5, t = 3, u = 2, v = 1 s = 4, t = 3, u = 2 y 5, v = 1 s = 1 y 5, t = 3, u = 2, v = 4 s = 4 y 5, t = 1, u = 2, v = 3.
¿Cuál de las siguientes no forma parte de las pruebas del sistema? Pruebas basadas en procesos empresariales Pruebas de rendimiento, carga y esfuerzo Pruebas de usabilidad Pruebas de integración de arriba hacia abajo.
¿Qué declaración sobre los resultados esperados es FALSO? Los resultados esperados se definen por el comportamiento del software Los resultados esperados se derivan de una especificación, no del código Los resultados esperados deben predecirse antes de que se realice una prueba Los resultados esperados pueden incluir restricciones temporales tales como tiempos de respuesta.
El costo de la fijación de un fallo: No es importante Aumenta el tiempo en que se encuentra una falla Disminuye más tarde se encuentra una falla Nunca se puede determinar Q.
¿Cuál de las siguientes no está incluida en el documento del Plan de Prueba de la Norma de Documentación de Prueba? Lo que no debe probarse Probar las propiedades del entorno Planes de calidad Horarios y plazos.
¿Podrían las revisiones o inspecciones ser consideradas parte de las pruebas? No, porque se aplican a la documentación de desarrollo No, porque normalmente se aplican antes de la prueba Sí, porque ambos ayudan a detectar fallas y mejorar la calidad Sí, porque las pruebas incluyen todas las actividades no constructivas.
¿Cuál de las siguientes no forma parte de las pruebas de rendimiento? Medir los tiempos de respuesta Pruebas de recuperación Simular muchos usuarios Generar muchas transacciones.
La conjetura de errores se utiliza mejor: Después de aplicar técnicas más formales
Como el primer enfoque para derivar casos de prueba Por experimentadores inexpertos Después de que el sistema haya terminado
.
¿Qué no puede encontrar el análisis estático? El uso de una variable antes de que se haya definido
Código inaccesible ("muerto")
Fugas de memoria
Las violaciones del límite del arreglo
.
|
