Tema 3 - Entornos - Diseño y realización

Estrategias incluidas en las revisiones técnicas, Inspecciones: Están organizadas por un moderador que reparte roles y tareas entre los participantes. Están organizadas por un desarrollador que reparte roles y tareas entre los participantes.

Pruebas de aceptación, prueba de usuario: La ejecución la realiza un analista simulando ser un usuario típico del sistema. La ejecución la realiza el usuario ayudado por profesionales participantes en el proyecto.

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.

El diseño de alto nivel, la arquitectura del sistema y la interfaz de usuario se comprueban al final de las pruebas: Pruebas de integración estrategia de big bang o gran explosión. Pruebas de integración estrategia ascendente.

Pruebas de Regresión: Una nueva versión de un programa exige nuevas actividades de pruebas. Son las pruebas que permiten volver a un sistema anterior (más antiguo) si se detectaron fallos grandes en el nuevo sistema.

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

Las pruebas: La más eficientes son las que se realizan al azar, sin una planificación previa, de esta forma se ataca al programa por sitios no previstos. No se pueden realizar de cualquier manera, hay que ser meticulosos.

Revisión de código: Son las pruebas que se realizan a cada módulo. Es la inspección directa del código individualmente o en grupo.

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.

En métrica, pruebas de regresión: Comprobar el resultado de las posibles modificaciones o actualizaciones del sistema. Cada nueva prueba que se hace al sistema tras un fallo.

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. Para crear las clases de equivalencia, debemos seguir los siguientes pasos: Identificar las condiciones, restricciones o contenidos (valores) de los datos de entrada, identificar las clases de equivalencia de las entradas y salidas y crear los casos de prueba. Identificar las condiciones, identificar las clases y objetos de la aplicación y por último crear los casos de prueba.

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: Forzamos al software para que falle, buscamos el error. Se comprueban los casos más comunes para los que fue desarrollado el programa.

Pruebas de aceptación, pruebas alfa: Se invita a los clientes a probar los productos en el entorno de desarrollo. Los programadores prueban el sistema en el entorno real.

Pruebas de unidades: Su realización exhaustiva mantendrá nuestra aplicación libre de errores. No descubrirán errores de integración, problemas de rendimiento y otros problemas que afectan a todo el sistema en su conjunto.

A las pruebas de unidades también se las llama: Pruebas unitarias. Pruebas de integración.

Pruebas del sistema y validación: Tienen como objetivo comprobar que el programa es capaz de funcionar en distintos sistemas operativos. El objetivo es asegurar que el sistema completo (software y hardware) cumple con los requisitos especificados inicialmente.

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 unidades: Para que una prueba unitaria sea de calidad debe documentarse adecuadamente. Las pruebas de unidades no necesitan documentarse, al contrario de las pruebas de integración.

Es ventajoso si los errores es más fácil que estén en los niveles inferiores: Pruebas de integración estrategia ascendente. Pruebas de integración estrategia descendente.

La idea de las pruebas de unidades: Es escribir casos de prueba generales para la aplicación en su conjunto. Es escribir casos de prueba para cada función no trivial.

En métrica, pruebas de sistema: Prueba de la aplicación en todo tipo de sistemas operativos. Prueban en un entorno lo más parecido posible a donde se va a instalar.

Pruebas de integración estrategia ascendente: Con los manejadores realizamos las pruebas de las interfaces y los módulos. Con los stub realizamos las pruebas de las interfaces y los módulos.

Localizan de forma sencilla los errores en las interfaces de los módulos al sustituir sistemáticamente manejadores por módulos desarrollados: Pruebas de integración estrategia de big bang o gran explosión. Pruebas de integración estrategia ascendente.

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 caja negra, estudio de errores típicos: El valor cero suele provocar errores: Verdadero. Falso, ningún valor numérico provoca más errores que otro.

Pruebas del sistema, pruebas funcionales: Se utilizan técnicas de caja negra y técnicas de caja blanca. La comprobación del sistema requiere pruebas de caja blanca.

Pruebas de caja negra, análisis de los valores límite: Si se especifican una serie de valores, elegiremos el mayor y el menor. Si se especifican una serie de valores, elegiremos el mayor, el menor, el anterior del menor, y el posterior al mayor.

Estrategias incluidas en las revisiones técnicas, Reuniones: En ellas varios …………….. revisan un documento o producto para mejorar su calidad y detectar errores antes de la prueba: Usuarios del sistema. Desarrolladores.

Pruebas de caja negra: Las pruebas se ajustarán a las características del lenguaje de programación. Son independientes del lenguaje o paradigma de programación utilizado.

Pruebas de caja negra, análisis de los valores límite: En el caso de listas o tablas se elige un valor aleatorio. Si el programa maneja una lista o tabla, debemos elegir el elemento primero, el último y el intermedio.

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

Las pruebas de software: Se centran en la fase de codificación y mantenimiento por ser donde se escribe el código. Deben contemplar todo el ciclo de vida del software, desde la fase de análisis hasta la de explotación y mantenimiento.

Caso de prueba: Conjunto de datos de entrada, las condiciones de ejecución y los resultados esperados. Algoritmo que debe ser inspeccionado para comprobar su correcto funcionamiento.

Es ventajoso si los errores es más fácil que estén en los niveles superiores: Pruebas de integración estrategia descendente. Pruebas de integración estrategia ascendente.

Pruebas de caja blanca, cobertura de flujo de control, Condiciones: Debemos diseñar suficientes casos de prueba para que todas las condiciones del programa se evalúen a cierto y a falso. Cada condición encontrada en un algoritmo precisa realizar un caso de prueba.

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.

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

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

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

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.

¿Cuál de los siguientes casos sería un “bug”?. 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.

¿Cuándo es mejor realizar las pruebas?. 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.

Para saber si un programa es correcto y 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: 02, 27, 99, z. 3, 14, 100, A.

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

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

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

¿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.

Los stubs deben describirse en el documento de pruebas siguiente: Plan de pruebas. Especificación de los casos de prueba.

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.

Pruebas del sistema, pruebas de configuración: Hay que prever los posibles cambios en la configuración del sistema software y hardware. Se comprueba que todos los módulos se integran de forma correcta.

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

Las revisiones: Cuando se utilizan en la comprobación del código se denominan revisiones técnicas. Cuando se utilizan en la comprobación del código se denominan pruebas de integración.

Recomendaciones de los expertos sobre pruebas: Deben centrarse e insistir más en las partes o módulos que más se utilicen o sean más críticos para el sistema: Verdadero. Falso.

Las pruebas de software: Permiten elaborar programas que funcionan más rápido y ocupan menos espacio en memoria. Buscan comprobar que la aplicación funciona correctamente, o dicho de otra forma, buscan la detección de errores.

Esta estrategia parece simple de aplicar, pero tiene el importante inconveniente de que cuando se descubre un fallo es muy dificil localizarlo para poder corregirlo: Pruebas de integración estrategia de big bang o gran explosión. Pruebas de integración estrategia ascendente.

Pruebas de integracion estrategia combinada: Combinan la integración ascendente y descendente. Combinan la integración unitaria, ascendente y descendente.

Herramientas especificamente diseñadas para la realización de pruebas: CASE. CAST.

Pruebas de caja blanca, cobertura de flujo de control: Consiste en buscar valores que presumiblemente puedan fallar. Consiste en estudiar la estructura de control del programa para obtener los casos de prueba.

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.

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

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.

Los manejadores son sencillos de construir: Pruebas de integración estrategia descendente. Pruebas de integración estrategia ascendente.

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

Las revisiones se utilizan tanto en las pruebas como en el control de la calidad: Verdadero. Falso.

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

Estrategias incluidas en las revisiones técnicas, Inspecciones: Son las menos formales de las distintas revisiones por lo que son muy flexibles. Son las más formales y requieren de preparación previa. Se utilizan para la verificación de todo el proceso de desarrollo.

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.

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.

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.

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.