Test
EliasExamen
Este test tiene tipos de pregunta que se abren en el reproductor de siempre.
Preguntas del test (37)
1son importantes porque aseguran el correcto cuumplimineto de la funcionalidad del producto,
ayudan a ganar confianza, confirman la fiabilidad del uso y previenen defectos en produccion.- APlaneacion
- BPruebas de software
- CAnalisis y diseño de prueba
2Donde se hace un esquema de ¿que se va a probar? ¿como se va a probar? ¿quien lo va a probar? y ¿cuando? A la
salida de esta fase podemos mencionar que se obtiene un plan de pruebas maestro que incluye estrategia y enfoque
de pruebas.- APlaneacion
- BPruebas de software
- CAnalisis y diseño de pruebas
- DEjecucion de pruebas
3en esta fase se analizan los requerimientos y se diseñan los casos de prueba, incluyendo
en esta actividad casos de prueba positivos y casos de prueba negativos- APlanecion
- BAnalisis y diseño de prueba
- CEjecucion de pruebas
- DEvalucion de resultados
4En esta fase es donde determinamos si se han alcanzado los objetivos de las pruebas, es decir, si la implementación de los requerimientos fue la óptima, lo ideal es que el usuario realice también otras pruebas para dar el visto bueno a la aplicación y ésta pueda ser puesta en producción.
- AEvaluacion de resultados
- BPlaneacion
- CAnalisis de prueba
- DEjecucion de pruebas
5Esta fase es la más importante ya que, es donde los casos de prueba son ejecutados en un ambiente de prueba o calidad para validar que los requerimientos especificados se hayan implementado de la manera correcta, es en este punto donde se aplica la estrategia de pruebas.
- APlaneacion
- BEjecucion de pruebas
- CAnalisis y diseño de pruebas
- DEJecucion de resultados
6 Una condición o necesidad de un usuario para resolver un problema o alcanzar un objetivo. Una condición o capacidad que debe estar presente en un sistema o componentes de sistema para satisfacer un contrato, estándar, especificación u otro documento formal.
- APlaneacion
- BDeficion de requerimiento
- CAnalisis y diseño de pruebas
- DCierre de pruebas
7Son los requerimientos que el usuario define y exige de manera clara y precisa
- ARequerimientos explicitos
- BRequerimientos implicitos
- CRequerimientos
- DPlaneacion
8Son los requerimientos que aunque el usuario no los especifique espera que el sistema sea entregado con estos
- ARequerimientos implicitos
- BRequerimientos explicitos
- CRequerimientos funcionales
- DRequerimientos no funcionales
9Documentacion que espefica las acciones a seguir para llegar a un objetivo especifico (resultado esperado)
que contiene datos o deberia contener datos de entrada, resultados esperados y un conjunto de condiciones de ejecucion de un elemento de prueba.- ACasos de prueba
- BPruebas de software
- CDocumentacion de pruebas
- DPlaneacion
10Son diseñados con la intención de romper el requerimiento, módulo o sistema a probar, es decir, comprueban situaciones en las que hay tratamientos con errores, por ejemplo: datos de entrada inválidos.
- ACasos de prueba negativos (Test To Fail)
- BCasos de prueba positivos (Test To Pass)
- CHappy path
- Dcasos de prueba
11Escenario default de un requerimiento. No se consideran caminos alternos, excepcionales o condiciones de error.
- AHappy path
- BCasos de prueba Negativos
- Ccasos de pruebas Positivos
- DCasos de pruebas
12 Son aquéllos que se diseñan para probar el requerimiento tal cual se diseñó y construyó. Estos casos de prueba aseguran que las funciones descritas en los casos de uso o requerimientos funcionales realmente estén implementadas en el sistema o módulo que se esté probando y que funcionen como se definieron. Muestran funcionalidad.
- ACasos de prueba Positivos
- BCasos de prueba Negativos
- CHappy path
13En el proceso de pruebas se registran los problemas encontrados o las incidencias detectadas. Dicho de manera técnica un desperfecto en un componente o sistema que puede causar que el sistema falle en desempeñar las funciones requeridas, por ejemplo: una sentencia o una definición de datos incorrecta.
- ABug
- BError
- CFalla
- DDefectos
14Es el medio de trabajo para la aplicacion de pruebas de software, como documentacion, scripts , resultados esperados, configuracion, procedimientos, archivos, base de datos, y cualquier software adicional o servicios utilizados en pruebas.
- ACasos de pruebas
- BTestware
- CRequerimientos
- DRequerimientos positivos
15Persona que asegura que el equipo de desarrollo ofrece la calidad necesaria a sus clientes. Centrandose en la entrega de un producto que proporcione mas valor que el negocio.
- Atester
- BPlaneador
- CIngeniero de pruebas
- DIngeniero de Requerimientos
16Se hace referencia a los componentes como módulos, clases o unidades, debido a que los desarrolladores pueden estar involucrados en la ejecución de pruebas, pueden llamarse también pruebas de desarrollador.
Es importante mencionar que estas pruebas las ejecuta el desarrollador verificando que su código cumple con lo solicitado y no ha violado ningún estándar que ponga en riesgo la estabilidad del sistema.- APruebas integrales
- BPruebas unitarias
- CPruebas de casos
- DPruebas requeridas
17 también son conocidas como pruebas de interfaz, ya que comprueban la interacción entre componentes.
Las pruebas de integración asumen que los módulos ya han sido probados de manera individual (pruebas unitarias).- APruebas Unitarias
- BPruebas requeridas
- CPruebas integrales
- DPruebas de fallos
18Cuando el desarrollo del sistema comienza con piezas unitarias y crece hasta formar modulos
- AAscendente
- BDescendente
- Cbig bang
19cuando se muestra el front de la aplicacion pero esta hueca por dentro y se comienza a trabajar desde los modulos mas grandes hasta llegar al detalle o en las partes unitarias
- ABig bang
- BDescendente
- CAscendente
20. Que va de la mano con xtreme programing porque el desarrollo no tiene un orden específico y puede ser al azar.
- AAscendente
- BDescendente
- CBig bang
21Se llevan a cabo cuando todo el desarrolo ha sido culminado y tenemos una version preliminar del sistema que saldra a produccion. consiste en probar un sistema integrado con el objeto de comprobar el cumplimiento de requisitos especificados.
- APruebas de software
- BPruebas de sistemas
- CPruebas de casos
- Dcasos de pruebas
22El objetivo de este nivel de prueba es obtener el visto bueno del cliente, no se deberian encontrar defectos funcionales graves en el sistema.
- APruebas Unitarias
- BPruebas de sistemas
- CPruebas de aceptacion
23El cliente utiliza el software para hacer el tratamiento de sus procesos de negocio en las dependencias del proveedor
- APruebas alfas
- BPruebas betas
24Estas se ejecutan en las dependencias del cliente
- APruebas Alfa
- BPruebas Beta
25 se enfocan en validar la correcta implementación de las necesidades del cliente. La funcionalidad puede ser vinculada a los datos de entrada y de salida. Los datos de entrada serán ejecutados y mostrarán un resultado y dicho resultado será comparado con el resultado esperado (comportamiento)
- ANo funcionales
- BFuncionales
- CPruebas Unitarias
26Se enfocan a las características de un software
- AFuncionales
- BNo funcionales
- CRequerimientos
27[blank_start]carga[blank_end] Pruebas a un sistema cubriendo la demanda esperada.
- Acarga
28[blank_start]rendimiento[blank_end] Rapidez con la cual un sistema ejecuta una determinada función.
- Arendimiento
29[blank_start]Estres[blank_end] Someter a la aplicación a una carga mucho mayor a la esperada y evaluar la capacidad del sistema de seguir su operación después de este tipo de demanda.
- AEstres
30se enfocan a revisar el código y su estructura. No es más que asegurarnos que todo el código es ejecutado con los casos de prueba diseñados, de esa manera se evita que existan ramas muertas o código inaccesible.
- APruebas Estructurales
- BPruebas Funcionales
- CPruebas de Planeacion
31El objetivo de estas pruebas es validar que la funcionalidad que ya se ha validado siga igual después de una modificación al código, hablamos de re-test, y pruebas de regresión, es decir, probar después de algún cambio.
- AAsociadas al cambio
- BPruebas Funcionales
- CPruebas Unitarias
- DPruebas de Aceptacion
32[blank_start]prueba de regresión[blank_end] :Repetir una prueba de funcionalidad que ha sido verificada previamente.
- Aprueba de regresión
33 comprenden métodos donde no se ejecutan los componentes u objetos de prueba (sistema).
- ADinamicas
- BEstaticas
- CFuncionales
34Este análisis se lleva a cabo sobre el código fuente, consiste en analizar un objeto de prueba sin llevar a cabo la ejecución del mismo.
- AAnalisis estatico
- BAnalisis dinamico
- CAnalisis de pruebas
35 examinan la parte interna del programa, siempre se está observando el código, y los casos de prueba están basados en la estructura interna del programa (figura 6.2). Por ello, la implementación de estas pruebas depende de la disponibilidad del código fuente. Este tipo de pruebas permiten generar casos para ejercitar y validar los caminos de cada módulo, las condiciones lógicas, los bucles, etcétera.
- ACaja negra
- BCaja blanca
- Ccaja amarrilla :v
- Dcaja magica xdxd
36se enfoca en probar el sistema sin tomar en cuenta la estructura interna del mismo, su objetivo es validar que las salidas sean las esperadas. Se centra en encontrar las circunstancias en las que el sistema no se comporta conforme a las especificaciones establecidas.
- ACaja Blanca
- BCaja Negra
37En esta etapa se llevan a cabo las primeras actividades correspondientes al proceso de pruebas, tiene como resultado un entregable denominado plan de pruebas
- ADiseño de pruebas
- BPlaneacion de pruebas
- CImplementacion de pruebas
Información
- Descripción
- Examen para Desarrollo de software
- Autor
- Elias Moguel
- Idioma
- Español
- Visitas
- 33
- Valoración
- Aún sin valoraciones Valora este test