Font size
WorksheetsParcial N°1 - Mantenimiento y Pruebas de Software
Total questions: 47
Worksheet time: 24mins
Es el proceso de evaluación y verificación de un producto o aplicación de software para saber si hace lo que se supone que debe hacer.
Prueba de Software.
Prueba de Hardware.
Pruebas de escritorio.
Pruebas virtuales.
Ninguna de las anteriores.
En un proyecto de desarrollo de software los errores pueden presentarse en cualquiera de las etapas del ciclo de vida del software.
Cierto
Falso
¿Qué NO es una prueba de software?
Encontrar cada defecto específico.
Permanecer esperando que algo falle.
Presionar botones de manera aleatoria esperando que algo falle.
Todas las anteriores.
Ninguna de las anteriores.
¿Qué beneficios nos da hacer las pruebas de software?
Prevención de errores.
Reducción de costos del desarrollo.
Mejoras del rendimiento.
Todas las anteriores.
Organización dedicada a la calificación y certificación de profesionales y empresas en el área de Pruebas de Software.
ITIL
ISTQB
EXIN
CMMI Associate
Son objetivos de las pruebas de Software (respuesta múltiple)
Descubrir errores no descubiertos antes.
Identificar cuáles son los elementos para que el cliente interactúe.
Detectar un error específico.
Ninguna de las anteriores.
¿Cuál es el objetivo principal que aportan las pruebas?
Mejoras
Calidad
Correcciones
Testear
¿Cuál/es de los siguientes conceptos son correctos?
El Testing es una disciplina para evaluar las características acordadas como relevantes.
El Testing sirve para dar indicadores que permiten medir instancias y diferencias con las expectativas de un producto.
El Testing de Software es fuente de la Mejora Continua.
Todos pueden realizar pruebas, pero solo un buen Tester puede hacer buenas pruebas.
Todas las anteriores.
Errores, Defectos y Fallas
Un error es producto de un mal funcionamiento del sistema.
Los defectos reportados a Tiempo, determinan la calidad del software.
Un Error no identificado genera defectos, entonces un defecto causa fallas en el sistema.
Una falla necesita ser arreglada por el desarrollador del equipo.
¿Cuándo son más necesarias las pruebas?
Cuando el costo de los errores es mayor a la inversión en el trabajo de pruebas.
Cuando queremos eliminar por completo todos los problemas de un producto o servicio.
Cuando necesitamos analizar, detectar y evidenciar el trabajo mal realizado.
Todas las anteriores.
Ninguna de las anteriores.
¿Para qué sirve un Caso de Prueba?
Para documentar y guiar las pruebas de un escenario específico.
Para comunicar el objetivo y secuencias de una prueba específica.
Para organizar y dar seguimiento al plan de ejecuciones.
Todas las anteriores.
Ninguna de las anteriores.
Garantizar que está creando el software correctamente.
Verificación
Validación
Proceso
Ninguna de las anteriores
Garantizar que está construyendo el software correcto.
Verificación
Validación
Proceso
Ninguna de las anteriores
Se desarrollan para definir las cosas que son necesarias verificar y validar a fin de asegurar que el sistema funciona correctamente y está construido con un alto nivel de calidad.
Casos de Prueba
Cobertura de Pruebas
Suite de Pruebas
Ninguna de las anteriores
Colección de casos de prueba que se han agrupado para la ejecución de pruebas.
Planes de Prueba
Escenarios de Prueba
Suite de Pruebas
Ninguna de las anteriores
Identifican requisitos, riesgos, casos de prueba, los entornos de prueba a probar, una lista de la infraestructura a utilizar, objetivos empresariales y de calidad, planificaciones de prueba, los tipos y niveles de las pruebas que se van a realizar, los recursos para las pruebas y los entregables que se producirán al final.
Planes de Prueba
Escenarios de Prueba
Suite de Pruebas
Ninguna de las anteriores
Medida de qué tanto examinamos un sistema con nuestras pruebas con base en un determinado criterio.
Planes de Prueba
Escenarios de Prueba
Cobertura de Pruebas
Ninguna de las anteriores
Caso de Prueba que verifica que un sistema o software no hace lo que se supone que no debe hacer.
Negativo
Exitoso
Dinámico
Automatizado
Caja Negra
Caso de Prueba en donde el resultado esperado para el caso de prueba se obtuvo y el resultado obtenido coincide con el resultado esperado.
Positivo
Exitoso
Estático
Manual
Caja Blanca
Prueba en donde se ejecuta el código de un software en un ambiente controlado.
Positiva
Exitosa
Dinámica
Manual
Caja Negra
Prueba basada en la estructura interna del sistema o en su implementación.
Negativa
Fallida
Estática
Automatizada
Caja Blanca
Tipos de Pruebas
Funcionales
No Funcionales
Caja Blanca
Caja Negra
Todas las anteriores
Niveles de Pruebas
Unitarias
De Integración
De Sistema
De Aceptación
Relacionadas con el cambio
¿Qué nivel de prueba es la base de la pirámide de automatización en proyectos ágiles?
Pruebas de aceptación.
Pruebas de regresión.
Pruebas unitarias.
Pruebas de servicios
Pruebas que se centran en comprobar que los sistemas desarrollados funcionan acorde a las especificaciones funcionales y requisitos del cliente.
Funcionales
No Funcionales
Caja Blanca
Caja Negra
Pruebas que se centran en probar los requerimientos no funcionales, incluyendo pruebas de: rendimiento, usabilidad, seguridad, entre otros.
Funcionales
No Funcionales
Caja Blanca
Caja Negra
Pruebas que determinan como se comporta un sistema en términos de respuesta y estabilidad sobre una carga de trabajo concreta.
Rendimiento
Usabilidad
Seguridad
Recuperación
Pruebas que permiten validar si el equipo de desarrollo ha empleado buenas prácticas de seguridad en la codificación del software.
Rendimiento
Usabilidad
Seguridad
Recuperación
Pruebas que verifican el tiempo que le toma a un sistema recuperarse tras haber experimentado un fallo de hardware o software.
Rendimiento
Usabilidad
Seguridad
Recuperación
Técnicas para el Diseño de Casos de Pruebas:
Basadas en la especificación.
Basadas en la estructura.
Basadas en la experiencia.
Todas las anteriores.
¿Qué debe tener un caso de prueba?
Identificador, Nombre de caso, Descripción, pasos, resultados esperados
Id, Fecha, Nombre del tester, Problema visto
Resultados obtenidos, Resultados esperados, interface funcional
Compila o no, errores obtenidos, tipo de prueba que se realizo
Las pruebas de cobertura que se le hacen a un software con base en el funcionamiento, están estipuladas en las técnicas de:
Caja Negra
Caja Blanca
Caja Gris
Pruebas dinámicas
Las pruebas de caja negra, cuando se basan en el funcionamiento, evalúan:
Requisitos, entradas y salidas.
Rutinas de procesos, módulos y líneas de código.
Solo las respuestas.
Los mensajes o alertas.
Para las técnicas de caja negra es necesario conocer la lógica del programa, únicamente la funcionalidad que debe realizar
Verdadero
Falso
Su objetivo es definir el menor número de casos de prueba que descubran clases de errores.
Clases de Equivalencia.
Tabla de Decisiones.
Combinación por Pares.
Valor Límite.
Se enfoca en la identificación de los casos de prueba asociados con los valores límites del dominio de la función tanto de entrada como de salida.
Clases de Equivalencia.
Tabla de Decisiones.
Combinación por Pares.
Valor Límite.
Enfoque sistemático en el que varias combinaciones de entrada y su respectivo comportamiento del sistema se capturan en forma de tabla.
Clases de Equivalencia.
Tabla de Decisiones.
Combinación por Pares.
Valor Límite.
Ayuda a optimizar tus planes de prueba para cubrir un gran número de casuísticas con una selección mínima de pruebas.
Clases de Equivalencia.
Tabla de Decisiones.
Combinación por Pares.
Valor Límite.
Cobertura de Clases de Equivalencia.
Es medida como el número de particiones de equivalencia probadas con al menos un valor, dividido por el número total de particiones de equivalencia identificadas.
Se determina tomando el número de valores límite que han sido probados y dividiéndolo entre el número total de valores límite identificados.
Garantiza una cobertura del 100% para cada par parámetro-valor.
Se calcula cubriendo: todos los resultados de la condición, todas las acciones, todas las reglas de decisión factibles y no redundantes.
Cobertura de Valor Límite.
Es medida como el número de particiones de equivalencia probadas con al menos un valor, dividido por el número total de particiones de equivalencia identificadas.
Se determina tomando el número de valores límite que han sido probados y dividiéndolo entre el número total de valores límite identificados.
Garantiza una cobertura del 100% para cada par parámetro-valor.
Se calcula cubriendo: todos los resultados de la condición, todas las acciones, todas las reglas de decisión factibles y no redundantes.
Para esta técnica deben considerarse una entrada válida y dos más entradas no válidas, dependiendo de sus excepciones.
Clases de Equivalencia.
Tabla de Decisiones.
Combinación por Pares.
Valor Límite.
La desventaja de esta técnica es que no se puede identificar qué porcentaje del sistema ha sido probado.
Clases de Equivalencia.
Tabla de Decisiones.
Combinación por Pares.
Valor Límite.
Seleccione las dos técnicas que mejor trabajan en conjunto, siendo una la evolución de la otra en donde trabaja con rangos.
Clases de Equivalencia.
Tabla de Decisiones.
Combinación por Pares.
Valor Límite.
En la técnica de partición de equivalencias, solo para estos casos se define una clase válida y dos o más inválidas (según mensajes de error diferentes).
Si un parámetro de entrada especifica un rango de valores.
Si un parámetro de entrada especifica un valor numérico o número de valores.
Si un parámetro de entrada se especifica con un conjunto de valores de entrada que serán tratados igual.
Si hay razones para creer que cada uno de los miembros del conjunto serán tratado de modo distinto por el programa.
Si un parámetro de entrada es una condición lógica.
Casos de Prueba en sistemas no determinísticos.
Funcional
No Funcional
Equivalente
Límite
Método en donde se ejecuta una prueba sin intervención humana.
Positiva
Exitosa
Dinámica
Automatizada
Caja Negra
Pruebas en donde se desarrollan y corren los casos de prueba nosotros mismos.
Estática
Manual
Negativa
Automatizada
Caja Blanca
