C. S. 1
![]() |
![]() |
![]() |
Título del Test:![]() C. S. 1 Descripción: C. S. 1 |




Comentarios |
---|
NO HAY REGISTROS |
(1.3) Algunos de los atributos de la Calidad del Software según la ISO 9126 son: (3 correctas). Eficiencia. Portabilidad. Usabilidad. Obsolencia. El atributo de calidad denominado “Mantenibilidad” definido en la ISO 9126 hace referencia a: Estabilidad. Atractivo visual. Costo. Con concepto de VERIFICACIÓN hace referencia a las necesidades reales del usuario. Falso. Verdadero. Complete la palabra que falta “… tiene como fin encontrar un ______ para analizarlo …”. Defecto. Requisito. Diseño. (2.1) “La presencia de que nos indica el mensaje?”. Falla. Error. Defecto. (2.2) El tipo de Testing que suele llamarse también “Retesting” es. Basado en cambios. Ad hoc. Exploratorio. (2.2) El tipo de testing que tiene como objetivo probar “qué” hace el sistema es. Funcional. Estructural. De carga. (2.2) Asignar dos valores a una misma variable al desarrollar hace referencia a. Error. Defecto. Falla. (2.2) ¿Cuál de los siguientes ejemplos es una prueba NO FUNCIONAL?. El sistema debe mostrar un reporte de usuarios registrados en menos de 3 segundos. El sistema debe registrar un nuevo usuario con todos los campos obligatorios. Al eliminar un usuario se debe actualizar la lista inmediatamente. (2.2) Complete la palabra que falta: “… enfocarse en comprobar que el software haga lo que el cliente solicitó es la _______.”. Validación. Verificación. Depuración. (2.2) Nivel de Testing: “Prueba orientada a verificar las interfaces entre los componentes”. Integración. Unidad. Sistema. (2.2) Para verificar la navegación y la información de listas desplegables se necesita Testing: Funcional. Estrés. Seguridad. (2.3) Objetivos principales del testing de software: (dos correctas). Asegurar que el software cumpla con las especificaciones definidas. Encontrar errores en el código lo más rápido posible. Aumentar los costos del desarrollo. (2.3) El atributo de calidad denominado “Confiabilidad” definido en la ISO 9126 hace referencia a. Robustez. Portabilidad. Usabilidad. (3.1) Reejecución de un caso de prueba que falló previamente pertenece a la etapa de. Implementar y Ejecutar. Planificar. Diseñar. (3.2) Elemento del caso de prueba que indica el estado tras la ejecución. Postcondiciones. Precondiciones. Pasos de prueba. (3.4) Técnica dinámica que diseña casos para la parte con mayor probabilidad de errores. Adivinanza de errores. Partición de equivalencia. Prueba de mutación. (4.2) Casos de prueba que buscan que el software haga algo diferente al esperado. Negativos. Positivos. Exploratorios. (4.2) Complete la palabra que falta: “Un caso de prueba no puede ser ________, debe ser completamente detallado.”. Ambiguo. Exhaustivo. Automatizado. (4.3) ¿En base a qué se arman las denominadas Test Suites?. Condiciones de Test. Resultados esperados. Plan de proyecto. ¿Cuál de los siguientes ejemplos corresponde a un atributo de calidad interna del software (es decir, solo visible para desarrolladores y no directamente observable por el usuario final)?. Legibilidad. Usabilidad. Eficiencia. Portabilidad. Completa la frase: “La corrección de un programa se define en relación con las _________ asociadas al software construido; si el software no hace lo que se supone debe hacer, es inútil.”. Necesidades del usuario. Documentaciones. Herramientas de desarrollo. Métricas de desempeño. Considera las dos perspectivas de la ingeniería de software: proceso y producto. ¿Cuál enunciado es verdadero?. El producto se evalúa a lo largo del tiempo mediante métricas como la densidad de defectos (bugs). La ingeniería de software no diferencia entre proceso y producto para medir calidad. El proceso se refiere a las actividades que ayudan a entender las necesidades del usuario. La calidad de producto únicamente se mide en términos de densidad de líneas de código. “Durante la captura de requisitos, nos enfocamos en cómo resolver el problema técnico, sin involucrar al usuario final para definir las funcionalidades.”. Falso. Verdadero. Cuando surgen defectos por una pobre comprensión de las necesidades de usuario y se corrigen tardíamente, su costo puede ser hasta: 100 veces más costoso que corregirlo en el momento adecuado. 10 veces más costoso que corregirlo en el momento adecuado. Igual de costoso que corregirlo temprano, pues el esfuerzo de corrección es constante. 1000 veces más costoso que corregirlo en el momento adecuado. Se refiere a contrastar la especificación con el software bajo prueba. Verificación. Validación. Involucra contrastar las necesidades reales del usuario con la especificación o el resultado del software. Validación. Verificación. Completa el espacio en blanco: “En un test de software, la fase de Arrange corresponde a la construcción de los datos o escenarios; Act a la ejecución del software; y Assert a la _______ del resultado obtenido con el resultado esperado.”. Contrastación. Salida. “Una suite de tests (test suite) falla únicamente cuando todos sus casos de prueba (tests) fallan.”. Falso. Verdadero. Un criterio de testing se define como: Un conjunto de reglas que impone requisitos de testing a una suite de tests, definiendo qué escenarios deben cubrirse. Una herramienta automática para ejecutar tests sobre el SUT. Solo la métrica de cálculo de cobertura de código. Un documento que describe las funcionalidades del sistema sin relacionarlas con las entradas y salidas. La cobertura de sentencias se cumple cuando: Cada sentencia del código del SUT es ejecutada al menos una vez por algún test de la suite. Cada condición if se evalúa al menos una vez en verdadero y una vez en falso. Al menos una ejecución del software termina sin errores. Cada clase del sistema está referenciada por al menos un caso de prueba. “Si una suite cumple con cobertura de ramas (también llamada cobertura de decisión), entonces necesariamente cumple con cobertura de sentencias.”. Verdadero. Falso. ¿Cuál es la característica fundamental de una partición de dominio en testing de caja negra?. Que cada entrada del dominio pertenezca a exactamente una parte (no solapamiento) y cada parte sea no vacía. Que las clases de equivalencia se definan sin considerar las funcionalidades del software. Que cada clase de equivalencia contenga exactamente dos entradas del dominio. Que el dominio se divida en conjuntos que puedan solaparse libremente. “El criterio de todas las combinaciones genera un número de requerimientos de test que crece (1)_______ con la cantidad de características consideradas, mientras que el criterio de cada elección exige al menos un test por cada (2)_______ de cada característica.”. (1)Exponencialmente. (2)Bloque. (1)Logarítmicamente. (2)Paquete. Señala las fuentes posibles de un oráculo de testing: (dos correctas). Necesidades de usuario (requisitos reales del software). Especificación del software. Estructura interna del compilador. Registros de tráfico de red del servidor. “En el testing basado en propiedades (property-based testing), definimos propiedades del software y dejamos que una herramienta genere automáticamente valores para probar esas propiedades (por ejemplo, QuickCheck).”. Verdadero. Falso. |