Validacion & Verificacion de Software

Según Barry Boehm (1979), la pregunta central de la VALIDACIÓN es: ¿Construimos el producto correcto?. ¿Construimos bien el producto?. ¿El sistema está libre de defectos?. ¿El código cumple con los estándares definidos?.

¿Cuál es el objetivo principal del proceso de diseño de casos de prueba según Sommerville?. Garantizar que el sistema no contendrá ningún defecto antes de su entrega al cliente. Ejecutar el mayor número posible de pruebas para maximizar la cobertura del código fuente. Crear un conjunto de casos de prueba que sean efectivos descubriendo defectos en los programas y mostrando que el sistema satisface los requerimientos. Documentar los errores encontrados durante la fase de integración del sistema.

Durante y después del proceso de implementación, el software debe comprobarse para asegurar que satisface su especificación. ¿Cómo se denomina el proceso que agrupa las actividades de análisis y prueba destinadas a ese fin?. Integración continua del software. Aseguramiento de la calidad del proceso. Verificación y validación (V&V). Gestión de configuración del software.

¿Cuál es el principio estratégico que establece que las pruebas exhaustivas son imposibles?. Que las herramientas de automatización no pueden cubrir todos los escenarios posibles del sistema. Que los requerimientos del sistema cambian con frecuencia, haciendo imposible mantener los casos de prueba actualizados. Que no es posible probar todas las combinaciones posibles de entradas, estados y condiciones del sistema, por lo que se deben priorizar los casos más relevantes. Que los equipos de prueba no tienen tiempo suficiente para ejecutar todos los casos posibles antes de la entrega.

¿Qué implica el principio "probar temprano reduce costos" en el enfoque estratégico?. Que las herramientas de prueba deben comprarse antes de que comience el desarrollo del sistema. Que el costo de las pruebas se puede reducir ejecutándolas en paralelo con las actividades de desarrollo del sistema. Que detectar y corregir un defecto en etapas tempranas del desarrollo es significativamente más barato que corregirlo en producción. Que el equipo de pruebas debe ser contratado desde el inicio del proyecto para reducir los gastos de personal.

En el proceso Sala Limpia, ¿cuántos equipos están implicados en el desarrollo de grandes sistemas?. Tres equipos: especificación, desarrollo y certificación. Dos equipos: desarrollo y pruebas. Un único equipo multidisciplinario integrado. Cuatro equipos: especificación, diseño, implementación y certificación.

¿Cuál de los siguientes es un ejemplo de error de interfaz de parámetros?. Un componente pasa a otro un parámetro con un tipo de dato diferente al esperado por el componente receptor. Un componente solicita un servicio de otro componente enviando un mensaje con formato incorrecto. Dos componentes comparten un bloque de memoria que uno de ellos escribe y el otro lee en momentos distintos, generando inconsistencias. Un componente llama a un procedimiento de otro componente que ya no existe en la versión actual del sistema.

¿Qué función cumple el gestor de pruebas dentro de un banco de trabajo de pruebas automatizadas?. Compara los resultados de las pruebas con los resultados previos e informa las diferencias entre ellos. Mantiene un registro de los casos de prueba ejecutados, los resultados obtenidos y las versiones del sistema que han sido probadas. Genera predicciones de los resultados de prueba basándose en la especificación formal del sistema. Añade código al programa para contar el número de veces que cada sentencia del programa se ejecuta.

Las TÉCNICAS ESTÁTICAS de V&V analizan el software sin ejecutarlo. ¿Cuál de las siguientes es una técnica estática?. Prueba de integración entre módulos. Prueba de carga del sistema. Inspección y revisión del código fuente. Prueba de regresión automatizada.

Las técnicas de validación de la protección (Security) incluyen pruebas de penetración, análisis de vulnerabilidades y modelado de amenazas (STRIDE). ¿Qué caracteriza específicamente al ethical hacking como técnica de validación?. Genera automáticamente casos de prueba basándose en la especificación formal del sistema para maximizar la cobertura. Consiste en revisar el código fuente del sistema en busca de patrones conocidos de vulnerabilidades de seguridad. Analiza el tráfico de red del sistema para detectar anomalías en el comportamiento de los protocolos de comunicación. Simula ataques reales controlados realizados por expertos para descubrir fallos de seguridad antes de que lo hagan atacantes reales.

¿Cuál de los siguientes componentes del argumento de seguridad contiene los argumentos estructurados que justifican por qué el diseño es seguro?. Descripción del sistema. Informe de revisiones. Procesos de gestión de cambios. Análisis del diseño.

¿Qué distingue a las pruebas de caja negra de otras técnicas de prueba?. El equipo de pruebas diseña casos de prueba basándose en el análisis detallado del código fuente. Las pruebas solo consideran las entradas y salidas del sistema sin acceso a su implementación interna. Se utilizan exclusivamente para detectar defectos de rendimiento bajo condiciones de alta concurrencia. El equipo de pruebas tiene acceso completo al código fuente y puede modificarlo durante las pruebas.

¿Cuál es la idea central de las pruebas de particiones (también denominadas particiones de equivalencia)?. Dividir el código fuente del programa en módulos iguales para asignar responsabilidades de prueba a distintos equipos. Particionar el tiempo de ejecución del sistema para medir el rendimiento en diferentes intervalos de operación. Identificar particiones de entrada y salida donde todos los elementos de la partición deberían ser procesados de la misma manera por el programa. Separar las pruebas funcionales de las no funcionales para ejecutarlas en etapas distintas del proceso de V&V.

¿Qué son los niveles de integridad de seguridad (SIL) y cuál es su propósito?. Son niveles que clasifican el riesgo requerido en sistemas de seguridad para definir el rigor de las pruebas y evidencias exigidas, desde SIL 1 (menor riesgo) hasta SIL 4 (mayor riesgo). Son indicadores que miden la satisfacción del usuario con el sistema en condiciones normales de operación. Son métricas de rendimiento que miden la velocidad de procesamiento de sistemas en tiempo real. Son estándares de calidad de código fuente que establecen los requisitos mínimos de documentación técnica.

El principio estratégico "las pruebas muestran la presencia de defectos, no su ausencia" implica que: Nunca se puede afirmar con certeza que un software está libre de defectos, por lo que las pruebas deben planificarse para maximizar la detección. Solo las pruebas automatizadas son válidas para demostrar la ausencia de errores en el sistema. Las pruebas únicamente detectan defectos en las partes del código que fueron ejecutadas durante su ejecución. Si el software supera todas las pruebas diseñadas, es absolutamente seguro que no contiene ningún defecto.

En un proceso de desarrollo iterativo, ¿en qué momento se ejecutan las pruebas del sistema?. Solo cuando el cliente lo solicita explícitamente en el plan del proyecto. Únicamente al final del proyecto, cuando todos los módulos están terminados. Se prueban los incrementos a medida que se entregan, probando el sistema completo al finalizar. Exclusivamente durante la fase de mantenimiento del software.

En el contexto de pruebas de integración incremental, ¿qué ventaja principal ofrece este enfoque frente a la integración no incremental?. Elimina completamente la necesidad de desarrollar componentes de prueba especializados. Reduce significativamente el tiempo total de desarrollo al eliminar etapas de prueba individuales. Garantiza que todos los defectos sean detectados antes de integrar cualquier componente adicional. Localizar los errores es más fácil porque cuando aparece una salida anómala, es probable que se deba a las interacciones del nuevo componente añadido.

¿Cuál es el punto de partida de una prueba de caminos en un grafo de flujo?. El punto de entrada de la prueba de caminos es el modelo del esqueleto de todos los caminos del programa, representado por el grafo de flujo. El módulo con mayor complejidad ciclomática, ya que determina el número mínimo de pruebas necesarias. El nodo con mayor número de aristas de salida, ya que representa la decisión más compleja del programa. El nodo final del programa, ya que se analiza el flujo en sentido inverso para identificar las causas de cada salida.

¿Cuál es la respuesta a la pregunta clásica "¿cuándo terminar las pruebas?" según el criterio basado en defectos?. Las pruebas terminan cuando se ha alcanzado una cobertura mínima del 90% de las líneas de código del sistema. Las pruebas terminan cuando se agota el presupuesto asignado al proceso de pruebas del proyecto. Las pruebas terminan cuando el cliente aprueba formalmente el sistema mediante una firma de aceptación. Las pruebas finalizan cuando la tasa de descubrimiento de defectos disminuye significativamente y el sistema se estabiliza dentro de niveles aceptables.

El MODELO V de desarrollo de software establece una relación entre las etapas del proceso y las actividades de prueba. ¿En qué tipo de proyectos se aplica principalmente?. Proyectos de software libre con equipos distribuidos globalmente. Procesos de desarrollo estrictamente controlados, como los usados en sistemas críticos para la seguridad. Proyectos con metodología Scrum y entregas iterativas cortas. Proyectos de desarrollo web con ciclos de despliegue continuo.

¿Cuál de los siguientes elementos forma parte de la estructura de un PLAN DE PRUEBAS del sistema?. El presupuesto total del proyecto de desarrollo. El calendario de reuniones del equipo de gestión. El organigrama del departamento de desarrollo. Los procedimientos de registro sistemático de resultados de prueba.

El ANÁLISIS ESTÁTICO AUTOMATIZADO tiene como objetivo principal: Medir el rendimiento del sistema mediante perfiles de ejecución automatizados. Compilar el código fuente y verificar su compatibilidad con el sistema operativo. Ejecutar el programa con datos de prueba generados automáticamente. Llamar la atención del inspector sobre anomalías del programa sin ejecutarlo.

Según los estudios citados por Sommerville, Fagan (1986) reportó que mediante inspecciones informales de programa se detecta más del: 60% de los errores. 45% de los errores. 80% de los errores. 30% de los errores.

¿Qué es un argumento de seguridad del software según Bishop y Bloomfield (1998)?. Un conjunto de evidencias documentadas que proporcionan un argumento válido y convincente de que un sistema es adecuadamente seguro para una aplicación determinada en un entorno concreto. Un plan de contingencia que describe los pasos a seguir cuando el sistema falla en producción. Un conjunto de pruebas de regresión automatizadas que demuestran que el sistema no tiene defectos conocidos. Un informe de auditoría generado por el equipo de calidad al finalizar el proceso de desarrollo del sistema.

Las pruebas basadas en requerimientos son, por lo tanto, una aproximación sistemática al diseño de casos de prueba. ¿Qué principio general las orienta?. Que los requerimientos definen únicamente los requisitos funcionales, dejando los no funcionales para otras técnicas. Que los requerimientos deberían ser escritos de forma que cada requerimiento pueda derivar un conjunto de casos de prueba para cada uno de ellos. Que los requerimientos deben ser escritos como afirmaciones positivas del comportamiento del sistema que los diseñadores puedan ignorar. Que los requerimientos son documentos estáticos que no necesitan validación mediante pruebas específicas.

Las pruebas de rendimiento deben ejecutarse hasta que: El cliente apruebe formalmente los resultados de la primera sesión de pruebas de carga. El rendimiento del sistema se vuelve inaceptable, revelando los límites operativos del sistema bajo carga creciente. Se hayan ejecutado exactamente el mismo número de casos de prueba que en las pruebas funcionales. Se detecte el primer defecto funcional del sistema, momento en que se detienen las pruebas.

¿Qué objetivo tienen las pruebas de caminos en el diseño de casos de prueba estructurales?. Medir el tiempo de ejecución de cada módulo del sistema bajo condiciones de carga máxima. Asegurar que cada camino de ejecución independiente del programa sea ejecutado al menos una vez durante las pruebas. Verificar que el sistema genera los mensajes de error correctos cuando se reciben entradas inválidas. Garantizar que todos los casos de uso del sistema sean cubiertos por al menos un caso de prueba.

¿Cómo se define la fiabilidad del software según la métrica matemática presentada por Sommerville?. La fiabilidad es la capacidad del sistema para recuperarse automáticamente ante cualquier fallo de hardware o software. La fiabilidad es el número total de fallos detectados durante la fase de pruebas del sistema antes de su entrega. La fiabilidad es el porcentaje de casos de prueba que el sistema supera satisfactoriamente durante la validación final. La fiabilidad es la probabilidad de que un sistema opere sin fallos durante un tiempo determinado bajo condiciones específicas.

En el contexto de sistemas críticos, ¿cuál es la razón principal por la que los costes de V&V son significativamente más elevados que para otros tipos de sistemas?. Porque los lenguajes de programación usados en sistemas críticos requieren compiladores más costosos. Porque los sistemas críticos siempre son más grandes y complejos que los sistemas convencionales. Porque los sistemas críticos deben cumplir con normativas de diseño que exigen equipos de desarrollo más grandes. Porque los sistemas críticos consumen más del 50% de los costes de desarrollo, ya que un fallo puede tener consecuencias catastróficas que justifican una inversión elevada en pruebas y validación.

¿Qué se debe hacer con los valores en los límites entre particiones durante el diseño de pruebas?. Probar los valores en los límites de cada partición, incluyendo el valor justo en el límite, uno por encima y uno por debajo. Probar únicamente los valores centrales de cada partición para simplificar el proceso de prueba. Ignorarlos, ya que los límites no son representativos del comportamiento general del programa. Aplicarlos exclusivamente en pruebas de rendimiento para determinar los umbrales de carga del sistema.

El número de caminos en un programa puede ser muy grande. ¿Qué hace impráctica la prueba exhaustiva de todos los caminos?. Que cuando los módulos se integran en sistemas, puede haber un número infinito de posibles combinaciones de caminos entre componentes, lo que hace imposible probarlos todos. Que los equipos de prueba no tienen acceso al código fuente del sistema que están probando. Que las particiones de equivalencia cubren completamente todos los caminos, haciendo redundante su prueba individual. Que las herramientas de automatización no son capaces de generar casos de prueba para programas complejos.

¿Cuál es la diferencia clave entre verificación y validación en términos de enfoque?. La verificación es realizada por el cliente; la validación es realizada por el equipo de desarrollo. La verificación tiene enfoque interno y previene defectos; la validación tiene enfoque externo y detecta fallos funcionales. La verificación evalúa el cumplimiento del negocio; la validación evalúa el cumplimiento técnico. La verificación se aplica únicamente al código; la validación se aplica únicamente a los requerimientos.

Los tres objetivos de seguridad (Security) que deben garantizarse en sistemas críticos son: Usabilidad, accesibilidad y trazabilidad de las acciones realizadas por los usuarios del sistema. Disponibilidad, mantenibilidad y portabilidad del sistema en distintos entornos de operación. Rendimiento, escalabilidad y tolerancia a fallos del sistema bajo condiciones de alta carga. Confidencialidad, integridad y disponibilidad de la información y los servicios del sistema.

¿Qué describe el componente "Procesos de gestión de cambios" dentro de un argumento de seguridad?. El calendario de mantenimiento preventivo y actualizaciones periódicas del sistema en producción. La descripción de las herramientas de prueba utilizadas durante el proceso de validación del sistema. Los procedimientos de capacitación del personal técnico encargado de operar el sistema. Los informes de todos los cambios propuestos al sistema, las acciones tomadas y, cuando sea apropiado, la justificación de la seguridad de los cambios realizados.

¿En qué tipo de sistemas se aplica principalmente el enfoque basado en riesgos para la planificación de pruebas?. En sistemas críticos donde el fallo puede tener consecuencias graves para personas, el entorno o la economía. En sistemas de entretenimiento y aplicaciones móviles donde la experiencia del usuario es prioritaria. En sistemas de información empresarial donde los datos son procesados en grandes volúmenes. En sistemas con equipos de desarrollo pequeños donde los recursos de prueba son limitados.

En el contexto de pruebas de caminos, ¿qué es un grafo de flujo?. Un diagrama de barras que representa el número de defectos detectados en cada módulo del sistema. Un diagrama de secuencia que muestra el orden de llamadas entre los métodos de una clase. Una representación visual de la arquitectura del sistema y sus componentes principales. Un modelo del esqueleto de todos los caminos del programa, compuesto por nodos que representan decisiones y aristas que representan el flujo de control.