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