Entornos t3

Los objetivos fundamentales de las revisiones coinciden con lo indicado para las pruebas, es decir, la detección de fallos lo antes posible para su eliminación: verdadero. falso.

Durante la reunión el moderador organiza, el autor explica el código, los revisores identifican los errores y un secretario recoge lo tratado: Revisiones técnicas: Reuniones. Revisiones técnicas: Inspecciones.

Pruebas de caja blanca: Se centran en la especificación del programa para estudiar las entradas de datos y las salidas de resultados. Se centran en la implementación de los programas para elegir los casos de prueba.

Pruebas de caja blanca, cobertura de flujo de control, Camino simple: Diseñar un caso de prueba capaz de recorrer todo el algoritmo de una sola pasada. Diseñar un caso de prueba por cada camino independiente.

Pruebas de integración: Tienen como misión comprobar que cada módulo funciona correctamente. Un objetivo importante es localizar errores en las interfaces entre las distintas unidades.

Componentes de pruebas: Permiten automatizar las pruebas para que sean menos tediosas de realizar. Cada unos de los casos de prueba utilizados para comprobar el funcionamiento de un programa.

Pruebas de integración estrategia ascendente: Es necesario crear módulos ficticios o stub. Es necesario diseñar módulos software como componentes de pruebas, denominados manejadores de pruebas o impulsores o drivers.

En la etapa final de creación del software: El jefe de proyectos realiza la llamada prueba de aceptación del software. Habrá una prueba que no realiza ni la controla el equipo de desarrollo, es la aceptación del software por parte del cliente.

El software desarrollado por terceros: Garantiza que nuestro programa no tendrá errores al estar ya suficientemente probado. Puede ser también una fuente de errores, errores colaterales.

Complejidad ciclomática (CC): Sólo tiene en cuenta una única ejecución de los bucles. La CC se incrementa tantas veces como el número de veces que se ejecuta un bucle.

Pruebas de caja negra, una clase de equivalencia es: El conjunto de pruebas que se realizan a las clases y sus objetos. Conjunto de datos de entrada que al ser introducidos en el sistema generará salidas válidas y no válidas.

Pruebas del sistema, pruebas de seguridad: Se trata de encontrar fallos de seguridad en el sistema. Son las pruebas de integración que aseguran el funcionamiento correcto del sistema.

Si queremos evitar fallos en los programas debemos: Centrarnos en su codificación. Revisar el software en todo su proceso de creación.

En métrica, pruebas de validación e implantación: Comprueban el correcto funcionamiento del sistema dentro del entorno real de producción. Son las pruebas realizadas a cada módulo del programa antes de realizar la integración.

En inglés “computer bug”: Errores que se producen en la traducción al código máquina del programa fuente. Los defectos y errores de programación.

¿Cuál de los siguientes casos sería un “bug”?. Una impresora que deja de imprimir porque se queda sin papel. Un programa que debe actualizarse para usar euros en lugar de pesetas. Un programa que calcula los número primos y responde que 21 es primo. Ninguna respuesta es correcta.

¿Cuándo es mejor realizar las pruebas?. Al principio del ciclo de vida para localizar los fallos pronto y ahorrar esfuerzos. Al final, cuando esté el programa terminado, pues entonces podrán realizarse los casos de prueba y ver si funciona bien el programa. A lo largo de todo el ciclo de vida. Ninguna respuesta es correcta.

Para saber si un programa es correcto y está libre de errores: Basta con seguir el diseño del algoritmo y saber que funciona. Debo aplicarle distintos casos de prueba, y si los supera sin fallos, entonces está libre de errores. Debo entregarlo al cliente para que lo pruebe y si queda satisfecho es suficiente. Puedo seguir una metodología de desarrollo y aplicar un plan de pruebas con lo que me aseguro un cierto nivel de calidad y seguridad ante el fallo, pero nunca podré saber si está 100% libre de fallos.

Si la entrada de un programa debe ser un número de 2 cifras, un caso de prueba que recoja todas las clases de equivalencia (válidas y no válidas) podría ser el siguiente: 5476, juan, 99. 3, 14, 100, A. 02, 27, 99, z. 1, 10, 100.

En una interfaz gráfica debo diseñar casos de prueba para los siguientes elementos: Iconos y menús. Cuadros de texto y listas desplegables. Tamaño y movimiento de la ventana. Todos los elementos anteriores y otros que compongan la interfaz gráfica.

El orden de las revisiones de menos a más formal es: Inspecciones, Walkthroughs, Reuniones. Reuniones, Walkthroughs, Inspecciones, Auditorías. Reuniones, Walkthroughs, Inspecciones. Reuniones, Inspecciones, Walkthroughs.

La mejor estrategia para la integración de módulos en las pruebas es: La descendente. La ascendente. La combinada. Cualquiera de las anteriores, depende del tipo de sistema a desarrollar y la metodología de desarrollo utilizada.

¿Qué actividades se incluyen dentro de las pruebas del sistema?: Pruebas funcionales. Pruebas de instalación y configuración. Pruebas de rendimiento y recuperación. Todas las anteriores forman parte de las pruebas del sistema.

Las características de una prueba alfa son: Se utilizan en las pruebas de sistema por parte de los desarrolladores y el equipo de pruebas. Se realizan en el entorno del cliente. El producto probado es una versión completa. Ninguna de las anteriores características corresponde a las pruebas alfa.

Los stubs deben describirse en el documento de pruebas siguiente: Plan de pruebas. Especificación de los casos de prueba. Informes de desarrollo de las pruebas. Informe de resumen de las pruebas.

Pruebas de software: Error: Ocurre cuando un software da como resultado unos datos que no se pueden considerar correctos dentro del campo de aplicación. Ocurre cuando en un programa hay algo que no funciona tan bien como se podría esperar.

Pruebas de aceptación, pruebas beta: Se realizan en el entorno del cliente. Se realizan en un entorno controlado (laboratorio).

Recomendaciones de los expertos sobre pruebas. Los casos de prueba deben diseñarse de manera que provoquen situaciones con mayor probabilidad de encontrar fallos: Verdadero. Falso, mejor no forzar el producto.

Documentación de las pruebas: Plan de pruebas, informe de pruebas de integración y del sistema. Plan de pruebas, especificación de los casos de pruebas, plan de revisiones, reuniones e inspecciones, Informes del desarrollo de las pruebas, Informe de resumen de las pruebas.

Pruebas de caja negra, análisis de los valores límite: En los rangos de valores vamos a elegir los extremos del rango y el valor medio. En los rangos de valores vamos a elegir los valores superiores al rango.

Complejidad ciclomática (CC): Número de ramas Número de nodos. Número de ramas Número de nodos + 2.

La visión funcional global del sistema no llega hasta el final: Pruebas de integración estrategia de big bang o gran explosión. Pruebas de integración estrategia ascendente.

En métrica, pruebas de validación e implantación: Son las pruebas realizadas a cada módulo del programa antes de realizar la integración. Comprueban el correcto funcionamiento del sistema dentro del entorno real de producción.

Pruebas de caja negra, análisis de los valores límite: Si el resultado se mueve en un determinado rango, debemos elegir datos a la entrada para provocar las salidas mínima, máxima y un valor intermedio. Las salidas no se tienen en cuenta para los valores límite.

Pruebas de caja negra, análisis de los valores límite: En los rangos de valores vamos a elegir los extremos del rango y el valor medio. En los rangos de valores vamos a elegir los valores superiores al rango.

Recomendaciones de los expertos sobre pruebas: Evitar el uso de una metodología de desarrollo del software. Usar una metodología de desarrollo del software.

Modificar los programas una vez que están terminados y usándose es mucho más costoso. Verdadero. Un programa una vez creado es más fácil de modificar e incluso es más fácil añadirle funciones que hacerlo desde su diseño inicial.

Si un programa, escrito por ejemplo en lenguaje C, compila sin errores: Significa que el programa está libre de errores y que realizará el cometido para el que fue creado en la fase de diseño. Esto realmente no significa nada sobre su posterior funcionamiento.

Pruebas de caja negra, estudio de errores típicos: En las listas de valores se debe intentar introducir el valor más usado o común. Cuando hay que introducir una lista de valores debemos centrarnos en la posibilidad de no introducir ningún valor, o introducir uno sólo.

El modelo de pruebas Construcción y Prueba Diarias: Consiste en realizar pruebas diarias del software en el entorno real del usuario. Consiste en desarrollar cada día una versión ejecutable del programa a la que se le aplica un plan de pruebas diario.

Pruebas de aceptación, pruebas beta: Se realizan en el entorno del cliente. Se realizan en un entorno controlado (laboratorio).

Se denomina “prueba”: Al proceso de ejecutar un programa con el fin de encontrar errores. Al método utilizado por los programadores para quitar errores de compilación.

En la etapa final de creación del software: El jefe de proyectos realiza la llamada prueba de aceptación del software. Habrá una prueba que no realiza ni la controla el equipo de desarrollo, es la aceptación del software por parte del cliente.

Las pruebas realizadas a lo largo de todo el ciclo de vida permiten: Al equipo de desarrollo validar y verificar el software. Al cliente validar, verificar y aceptar el software.

Pruebas de aceptación, prueba de comparación: El nuevo sistema sustituye a otro antiguo, se ejecutan ambos sistemas en paralelo. El nuevo sistema sustituye al antiguo directamente.

Pruebas de integración estrategia de big bang o gran explosión. Primero se prueban todos los métodos individualmente y después todos los componentes del sistema se integran a la vez y se realizan pruebas. Se integran todos los componentes en un solo paso realizando las pruebas sobre el conjunto.

Pruebas de caja blanca, cobertura de flujo de control, Bucles: Los bucles no necesitan ser probados ya que se conocen las sentencias a ejecutar y el número de veces que se repiten. Debemos diseñar casos de prueba de manera que se intente ejecutar cada bucle en diferentes situaciones límite.

Pruebas de unidades: Es recomendable automatizar algunos procesos de manera que los procedimientos de prueba puedan hacerse con la ayuda de software auxiliar. Las pruebas de las unidades deben ser realizadas por los programadores implicados en la mismas de forma manual.

La visión funcional global del sistema no llega hasta el final: Pruebas de integración estrategia ascendente. Pruebas de integración estrategia de big bang o gran explosión.

Pruebas de caja negra, análisis de los valores límite: En los rangos de valores vamos a elegir los valores superiores al rango. En los rangos de valores vamos a elegir los extremos del rango y el valor medio.

Pruebas de unidades: Antes de realizar las pruebas diseñadas es imprescindible usar un depurador (debugger). Antes de utilizar un depurador debemos haber hecho las pruebas oportunas según los casos de prueba diseñados.

Complejidad ciclomática (CC): Número de caminos independientes de un diagrama de flujo de control. El número de bucles o ciclos de un algoritmo.

Se necesitan stubs que a veces son difíciles de construir: Pruebas de integración estrategia de ascendente. Pruebas de integración estrategia descendente.

Estrategias de desarrollo de las pruebas de integración: Pruebas de integración ascendente, descendente, combinadas y big-bang. Pruebas de integración unitarias, ascendente, descendente, combinadas y big-bang.

Pruebas de caja negra, una clase de equivalencia es: Conjunto de datos de entrada que al ser introducidos en el sistema generará salidas válidas y no válidas. El conjunto de pruebas que se realizan a las clases y sus objetos.

Pruebas de caja blanca, cobertura de flujo de control: Nos da el número mínimo de casos de pruebas a realizar garantizando que se pasa por todas las alternativas que tiene un programa. Permite comprobar la solidez de un programa mediante la realización de todos los casos de prueba posibles.

Pruebas: Acciones encaminadas a encontrar errores. Las pistas que emite el compilador para reparar un programa con errores.

Un plan de pruebas contendrá: Casos de pruebas, procedimientos para llevar a cabo esas pruebas, y componentes software que automatizarán las pruebas. Los procedimientos para llevar a cabo las pruebas sobre cada módulo de la aplicación.

Pruebas de aceptación, prueba de comparación: El nuevo sistema sustituye al antiguo directamente. El nuevo sistema sustituye a otro antiguo, se ejecutan ambos sistemas en paralelo.

Pruebas del sistema, pruebas de seguridad: Se trata de encontrar fallos de seguridad en el sistema. Son las pruebas de integración que aseguran el funcionamiento correcto del sistema.