UT5 - Entornos de trabajo (Presentación IES El Rincón)

El objetivo de las pruebas de software es (MARCA LAS RESPUESTAS CORRECTAS): Conseguir un software libre de errores, mejorando la rentabilidad. Optimizar el tiempo de producción: eficiencia. Exclusivamente probar la funcionalidad básica del software. Aumentar los costos de desarrollo.

A la hora de realizar pruebas de software, es habitual incurrir en errores de varios tipos (MARCA LAS RESPUESTAS CORRECTAS): Incorrecta especificación de los objetivos/requisitos. Errores producidos en el diseño. Errores en la fase de desarrollo. Los errores de prueba son siempre responsabilidad del equipo de desarrollo.

Cuando hablamos de pruebas de software, el programador debe evitar probar sus propios programas. ¿Verdadero o falso?: Verdadero. Falso.

Siguiendo el modelo en espiral, las pruebas de software (MARCA LAS RESPUESTAS CORRECTAS): Empezarán con las pruebas de integración de cada porción de código. Una vez pasadas las pruebas unitarias con éxito, se seguirá con las pruebas de integración, donde se ponen todas las partes del código en común, comprobando que el ensamblado de los bloques de código y sus pruebas atienden a los establecido durante la fase de diseño. Una vez pasadas las pruebas de integración con éxito, se seguirá con las pruebas unitarias, donde se ponen todas las partes del código en común, comprobando que el ensamblado de los bloques de código y sus pruebas atienden a los establecido durante la fase de diseño. Empezarán con las pruebas unitarias de cada porción de código.

(Ámbito de las pruebas de software) Se comprueba cada porción del código (métodos y clases), permitiendo detectar errores de cada parte del programa por separado: Pruebas unitarias. Pruebas de integración. Pruebas de regresión. Pruebas de funcionalidad/validación.

(Ámbito de las pruebas de software) Se comprueban todas las partes del código en común, comprobando que el ensamblado de los bloques de código y sus pruebas atienden a los establecido durante la fase de diseño: Pruebas de funcionalidad/validación. Prueba de sistema/verificación. Pruebas de integración. Pruebas unitarias.

(Ámbito de las pruebas de software) Cada vez que se realizan cambios en un proyecto, es posible que el código existente ya no funcione correctamente o que se presenten errores no descubiertos previamente: Ninguna respuesta es correcta. Pruebas de funcionalidad/validación. Prueba de sistema/verificación. Pruebas de regresión.

(Ámbito de las pruebas de software) Prueban las funcionalidades de la aplicación o módulo construidos desde el punto de vista del análisis preliminar y usuarios finales, con sus diferentes roles, para validar que el software hace lo que debe y, sobre todo, lo que se ha especificado: Pruebas de regresión. Pruebas de funcionalidad/validación. Prueba de sistema/verificación. Pruebas unitarias.

(Ámbito de las pruebas de software) Se realiza sometiendo el sistema a condiciones extremas, como volúmenes de datos máximos o una gran cantidad de usuarios simultáneos; llevando el sistema al colapso o degradación para ver cómo reacciona y posteriormente volverlo a dejar en una situación de no estrés para ver cómo reacciona: Pruebas de estrés. Prueba de rendimiento. Pruebas de seguridad. Todas las respuestas son correctas.

(Ámbito de las pruebas de software) Determinan la capacidad de respuesta, el rendimiento, la confiabilidad y/o la escalabilidad de un sistema bajo una carga de trabajo determinada: Pruebas de estrés. Prueba de rendimiento. Pruebas de seguridad. Ninguna respuesta es correcta.

(Ámbito de las pruebas de software) Validan los servicios de seguridad de una aplicación e identifican posibles fallos y debilidades. Por ejemplo en las aplicaciones web: Pruebas de seguridad. Prueba de sistema/verificación. Pruebas de detección de errores. Pruebas de vulnerabilidades.

Los test manuales son aquellos que son ejecutados por un tester o analista de pruebas: Verdadero. Falso.

Los test automatizados son aquellos que son ejecutados por un tester o analista de pruebas: Verdadero. Falso.

Diferencias entre los test manuales y lo test automatizados (MARCA LAS RESPUESTAS CORRECTAS): Cobertura de pruebas: Los test automatizados pueden realizar pruebas más exhaustivas y repetitivas que los test manuales: pueden cubrir más casos de prueba y detectar más errores en menos tiempo. Tiempo y costo: Los test automatizados pueden ahorrar tiempo y reducir costos a largo plazo, ya que no requieren de la intervención humana en cada ejecución de prueba. Los test manuales requieren más tiempo y esfuerzo humano y pueden ser costosos en términos de tiempo y recursos. Cobertura de pruebas: Los test manuales pueden realizar pruebas más exhaustivas y repetitivas que los test automatizados: pueden cubrir más casos de prueba y detectar más errores en menos tiempo. Tiempo y costo: Los test manuales pueden ahorrar tiempo y reducir costos a largo plazo, ya que no requieren el desarrollo de software para realizar pruebas. Los test automatizados requieren más tiempo y esfuerzo humano y pueden ser costosos en términos de tiempo y recursos.

Diferencias entre los test manuales y lo test automatizados (MARCA LAS RESPUESTAS CORRECTAS): Flexibilidad: Los test manuales pueden ser más flexibles para probar escenarios complejos o imprevistos que los test automatizados, ya que los seres humanos pueden adaptarse mejor a situaciones no previstas. Sin embargo, los test automatizados pueden ser configurados para ser más flexibles con la introducción de variables dinámicas y configuraciones personalizadas. Los test automatizados pueden ser más precisos y consistentes que los test manuales, ya que eliminan la posibilidad de errores humanos. Los test manuales pueden ser más propensos a errores y variaciones en la calidad de las pruebas, dependiendo del analista que realiza la prueba. Flexibilidad: Los test automatizados pueden ser más flexibles para probar escenarios complejos o imprevistos que los test manuales, ya que los seres humanos pueden adaptarse mejor a situaciones no previstas. Sin embargo, los test manuales pueden ser configurados para ser más flexibles con la introducción de variables dinámicas y configuraciones personalizadas. Los test automatizados pueden ser más precisos y consistentes que los test manuales, ya que eliminan la posibilidad de errores humanos. Los test automatizados pueden ser más propensos a errores y variaciones en la calidad de las pruebas, dependiendo del analista que realiza la prueba.

Los test automatizados son más eficientes en términos de tiempo y costo que los test manuales, y pueden proporcionar una cobertura de prueba más exhaustiva y precisa: Verdadero. Falso.

Los test automatizados pueden ser más flexibles y adaptarse mejor a situaciones imprevistas o complejas. Por lo tanto, dependiendo de los requerimientos de la empresa o proyecto, es posible que se requieran ambos tipos de pruebas: Verdadero. Falso.

Las metodologías ágiles (SCRUM) ven al software testing como una fase separada, no como una parte integral del Desarrollo de software al igual que la programación: Verdadero. Falso.

Principios del Agile Testing (MARCA LAS RESPUESTAS CORRECTAS): El Testing no es una fase. El Testing hace avanzar el proyecto. Una parte del equipo realiza pruebas. Código limpio: Los defectos en el código se corrigen durante las prueba.

Principios del Agile Testing (MARCA LAS RESPUESTAS CORRECTAS): Se utilizan listas de chequeos para reducir la documentación. Las pruebas se hacen “durante” el desarrollo y no después: TDD. Las pruebas se hacen “después” del desarrollo y no durante: TDD. No se utilizan listas de chequeos para reducir la documentación.

Cuando hablamos de pruebas de 'Caja Negra', hablamos de pruebas: Pruebas funcionales. Pruebas estructurales. Pruebas funcionales y estructurales. Ninguna respuesta es correcta.

Comprobar que los resultados de la ejecución de la aplicación, son los esperados, en función de las entradas que recibe. Sin atender a como se ha construido: Pruebas de caja negra. Pruebas de caja blanca. Pruebas estructurales. Pruebas de caja negra (estructurales).

Tipos de prueba de 'Caja Negra' (MARCA LAS RESPUESTAS CORRECTAS): Particiones equivalentes. Análisis de valores límite. Pruebas aleatorias. Cobertura de sentencias.

(Tipos de prueba de Caja Negra ) La idea es considerar el menor número posible de casos de pruebas donde se prueban valores representativos. Lo que se pretende, es crear un conjunto de clases de equivalencia: Particiones equivalentes. Análisis de valores límite. Pruebas aleatorias. Cobertura del camino de prueba.

(Tipos de prueba de caja negra) Se van a elegir como valores de entrada, aquellos que se encuentra en el límite de las clases de equivalencia. En la imagen, un ejemplo de una función que determina si una persona es o no mayor de edad: Pruebas aleatorias. Particiones equivalentes. Cobertura de decisiones. Ninguna respuesta es verdadera.

(Tipos de prueba de caja negra) Consiste en generar entradas aleatorias para la aplicación que hay que probar. Se suelen utilizar generadores de prueba, que son capaces de crear un volumen de casos de prueba al azar, con los que será alimentada la aplicación: Cobertura de sentencias. Cobertura de decisiones. Cobertura del camino de prueba. Todas las respuestas son falsas.

Cuando hablamos de pruebas de 'Caja Blanca', hablamos de pruebas: Funcionales. Estructurales. Que comprueban que los resultados de la ejecución de la aplicación, son los esperados, en función de las entradas que recibe. Sin atender a como se ha construido. De particiones equivalentes.

Se prueba la aplicación desde dentro, usando su lógica de aplicación. El objetivo es analizar y probar directamente el código, intentando localizar estructuras incorrectas o ineficientes en el código. (Revisar todos los caminos): Pruebas de caja negra. Pruebas de caja blanca. Pruebas funcionales. Ninguna respuesta es correcta.

Las pruebas de caja blanca se basan en unos criterios de cobertura lógica que son (MARCA LAS RESPUESTAS CORRECTAS): Cobertura de sentencias. Cobertura de decisiones. Cobertura de condiciones. Cobertura del camino de prueba.

Uno de los criterios de cobertura lógica en los que se basan las pruebas de caja blanca, establece que se debe ejecutar al menos una vez cada secuencia de sentencias encadenadas, desde la sentencia inicial del programa, hasta su sentencia final: Objetivo recorrer todos los posibles caminos dentro de la aplicación: Cobertura del camino de prueba. Cobertura de decisiones. Cobertura de sentencias. Cobertura de condiciones.

(Criterios de las pruebas de caja blanca) Cobertura de condiciones: para que cada elemento de una condición, se evalúe al menos una vez a falso y otra a verdadero. Verdadero. Falso.

(Criterios de las pruebas de caja blanca) Cobertura de sentencias: para que cada instrucción del programa sea ejecutada, al menos, una vez. Verdadero. Falso.

(Criterios de las pruebas de caja blanca) Cobertura de decisiones: para que cada opción/sentencia cuyo resultado es una prueba lógica del programa, se evalúe al menos una vez a cierto y otra a falso. Verdadero. Falso.

(Pruebas de caja blanca) Es una puntuación que se obtiene del código de cada método/funciones o clase y que nos indica lo complejo que es un código: Complejidad ciclomática. Tiempo de ejecución. Complejidad estática. Número de líneas de código.

¿Cuál de las siguientes afirmaciones relacionadas con la complejidad ciclomática es verdadera?: Una puntuación de 0 a 10 es un código estable de complejidad aceptable; de 11 a 15 riesgo medio, más complejidad; de 16 a 20 código de alto riesgo, demasiadas decisiones para una unidad de código; por encima de 50 código no testeable. Una puntuación de 0 a 20 es un código estable de complejidad aceptable; de 20 a 25 riesgo medio, más complejidad; de 25 a 49 código de alto riesgo, demasiadas decisiones para una unidad de código; por encima de 50 código no testeable. Una puntuación de 0 a 10 es un código estable de complejidad aceptable; de 11 a 25 riesgo medio, más complejidad; de 25 a 40 código de alto riesgo, demasiadas decisiones para una unidad de código; por encima de 50 código no testeable. Una puntuación de 0 a 20 es un código estable de complejidad aceptable; de 20 a 35 riesgo medio, más complejidad; de 35 a 50 código de alto riesgo, demasiadas decisiones para una unidad de código; por encima de 50 código no testeable.

Para evitar que el número de pruebas de regresión crezca demasiado (MARCA LAS RESPUESTAS CORRECTAS): Se deben de diseñar para incluir sólo aquellas pruebas que traten una o más clases de errores en cada una de las funciones principales del programa. No es práctico ni eficiente volver a ejecutar cada prueba de cada función del programa después de un cambio. No se deben de diseñar para incluir sólo aquellas pruebas que traten una o más clases de errores en cada una de las funciones principales del programa. Es práctico y eficiente volver a ejecutar cada prueba de cada función del programa después de un cambio.

De las siguientes afirmaciones sobre las pruebas de regresión, MARCA LAS QUE SEAN VERDADERAS: La detección de errores supone la modificación del componente (clase) donde se ha detectado. Esta modificación, puede generar errores colaterales, que no existían antes. Como consecuencia, la modificación realizada nos obliga a repetir pruebas que hemos realizado con anterioridad. El objetivo es comprobar que los cambios sobre un componente de una aplicación, no introduce un comportamiento no deseado o errores adicionales en otros componentes no modificados. Implica la repetición de las pruebas que ya se hayan realizado previamente y confirmar que el sistema funciona correctamente una vez realizados los cambios. El objetivo no es comprobar que los cambios sobre un componente de una aplicación, introduce un comportamiento no deseado o errores adicionales en otros componentes no modificados.

Las pruebas de integración tienen por objetivo probar que cada módulo (clase. método) funciona correctamente por separado, es decir, que cada caso de prueba sea independiente del resto: Verdadero. Falso.

En las pruebas unitarias hay que tener en cuenta los siguientes requisitos (MARCA LAS RESPUESTAS VERDADERAS): Automatizable: no debería requerirse una intervención manual. Completas: deben cubrir la mayor cantidad de código. Manuales: no debería requerirse una intervención automatizada. Parciales: deben cubrir la menor cantidad de código.

En las pruebas unitarias hay que tener en cuenta los siguientes requisitos (MARCA LAS RESPUESTAS VERDADERAS): Repetibles o Reutilizables: no se deben crear pruebas que sólo puedan ser ejecutadas una sola vez. Independientes: la ejecución de una prueba no debe afectar a la ejecución de otra. Profesionales: las pruebas deben ser consideradas igual que el código, con la misma profesionalidad, documentación, etc. Dependientes: la ejecución de una prueba debe afectar a la ejecución de otra.

Es una práctica de programación en la que se comienzan escribiendo las pruebas en primer lugar, escribiendo el código fuente a continuación, pasando correctamente la prueba y terminando con la refactorización del código escrito: El TDD o Test Driven Development (desarrollo dirigido por pruebas). BDD (Behavior-Driven Development). Pruebas unitarias. Pruebas de aceptación.

El ciclo TDD y sus etapas (MARCA LAS RESPUESTAS VERDADERAS): Desarrollo de la prueba: creación (Lenguaje humano) de una prueba de validación, el equipo de desarrollo ha de conocer los requisitos que nos han dado los usuarios. Escritura del código: programamos el código. Validación de las pruebas: se validan las pruebas mientras se refina el código. Refactorización: se realizan los ajustes que han surgido durante el desarrollo.

Jbehave, Serenity, TestNG, Selenide, Gauge, Geb, Spock, HttpUnit, JWebUnit, son herramientas para hacer test. ¿Verdadero o falso?: Verdadero. Falso.

JUnit (MARCA LAS RESPUESTAS VERDADERAS): Es una herramienta de código abierto. Multitud de documentación y ejemplos en la web. Se ha convertido en el estándar de hecho para las pruebas unitarias en Java. Posee una comunidad mucho mayor que el resto de los frameworks de pruebas en Java.

JUnit (MARCA LAS RESPUESTAS VERDADERAS): Soporta múltiples tipos de aserciones (una sentencia verdadero-falso) y etiquetas. Es la herramienta de pruebas más extendida para el lenguaje Java. Soporta pocos tipos de aserciones (una sentencia verdadero-falso) y etiquetas. No es la herramienta de pruebas más extendida para el lenguaje Java.

(JUnit) @BeforeClass se ejecuta antes de cada test: Verdadero. Falso.

(JUnit) @AfterClass: Se invoca al finalizar todos los test. Verdadero. Falso.

(JUnit) @Test: Identifica los métodos test que deben ser probados. Verdadero. Falso.

(JUnit) @Before: Es invocado una vez al principio de todas los test. Se suele usar para inicializar atributos / objetos. Verdadero. Falso.

(JUnit) @After: Se ejecuta después de cada test. Verdadero. Falso.

(JUnit) @Ignore: Los métodos marcados con esta anotación no serán ejecutados. Verdadero. Falso.

(JUnit) Aserciones (afirmación)_ la clase Assertions una vez llamados ejecutan los métodos a probar y analizan su comportamiento comparándolos con los resultados que se espera de ellos. Verdadero. Falso.