Tema_8

La comprobabilidad fue diseñada por James Back. Verdadero. Falso.

La comprobabilidad fue diseñada en 1998. Verdadero. Falso.

La comprobabilidad fue diseñada en 1994. Verdadero. Falso.

La comprobabilidad del software significa docuementar los fallos. Verdadero. Falso.

La comprobabilidad del software significa saber con cuanta facilidad puede probarse. Verdadero. Falso.

La comprobabilidad del software significa saber con cuanta facilidad puede documentarse. Verdadero. Falso.

En la comprobabilidad una buena tiene baja probabilidad de encontrar errores. Verdadero. Falso.

En la comprobabilidad una buena prueba tiene alta probabilidad de resolver los errores. Verdadero. Falso.

En la comprobabilidad una buena prueba tiene alta probabilidad de encontrar los errores. Verdadero. Falso.

En la comprobabilidad una buena prueba es redundante. Verdadero. Falso.

En la comprobabilidad una buena prueba es totalmente comprobable y fácil de resolver. Verdadero. Falso.

En la comprobabilidad una buena prueba no es redundante. Verdadero. Falso.

En la comprobabilidad una buena prueba debe ser << la mejor de la camada>>. Verdadero. Falso.

En la comprobabilidad una buena prueba debe de ser simple. Verdadero. Falso.

En la comprobabilidad una buena prueba debe de ser compleja. Verdadero. Falso.

En la comprobabilidad una buena prueba no debe de ser simple ni compleja. Verdadero. Falso.

En la comprobabilidad, visión externa. se realizan pruebas que demuestren que cada función del producto es completamente operativa a la vez que se buscan errores asociados. se realizan pruebas asociadas al funcionamiento del producto de manera que se garantice que todas la operaciones y componente funcionan correctamente.

En la comprobabilidad, visión interna. se realizan pruebas que demuestren que cada función del producto es completamente operativa a la vez que se buscan errores asociados. se realizan pruebas asociadas al funcionamiento del producto de manera que se garantice que todas la operaciones y componente funcionan correctamente.

Vision externa e interna. pruebas de caja blanca. pruebas de caja negra.

Las pruebas de la caja blanca esta basado en detalles externos. Verdadero. Falso.

Las pruebas de la caja blanca esta basado en detalles internos. Verdadero. Falso.

Las pruebas de la caja blanca deben garantizar que todas las rutas independientes dentro de un módulo se prueban al menos una vez. Verdadero. Falso.

Las pruebas de la caja blanca realizan pruebas sobre la interfaz del software. Verdadero. Falso.

Las pruebas de la caja blanca se realizan tempranamente en el proceso de prueba. Verdadero. Falso.

Las pruebas de la caja blanca se realizan durante las últimas etapas. Verdadero. Falso.

Las pruebas de la negra se realizan de los detalles internos. Verdadero. Falso.

Las pruebas de la negra se realizan de los detalles externos. Verdadero. Falso.

Las pruebas de la negra realiza pruebas sobre la interfaz del software. Verdadero. Falso.

Las pruebas de la negra garantizan que todas las rutas independientes dentro de un módulo se prueben al menos una vez. Verdadero. Falso.

Las pruebas de la negra se realiza tempranamente en el proceso de prueba. Verdadero. Falso.

Las pruebas de la negra se aplica en las última etapas de la prueba. Verdadero. Falso.

Los diseño de los casos de pruebas de la caja blanca fueron realizados por Jame Bach. Verdadero. Falso.

Los diseño de los casos de pruebas de la caja blanca fueron realizados por Boris Beizer. Verdadero. Falso.

Boris Beizer decía que los errores están al acecho en las esquinas y se concentrar en las fronteras. Verdadero. Falso.

Diseño de caos de pruebas. Objetivo. Criterio. Restricciones.

Diseño de casos de pruebas de la caja blanca -> objetivo. descubrir errores. de una forma completa. con el mínimo esfuerzo y tiempo.

Diseño de casos de pruebas de la caja blanca -> criterio. descubrir errores. de una forma completa. con el mínimo esfuerzo y tiempo.

Diseño de casos de pruebas de la caja blanca -> restricciones. descubrir errores. de una forma completa. con el mínimo esfuerzo y tiempo.

El objetivo de la prueba básica del a caja blanca fue diseñado por. James Bach. Boris Beizer. Tom McCabe.

El objetivo de la prueba básica del a caja blanca fue diseñado en 1976. Verdadero. Falso.

Tom McCabe. Prueba básica de caja blanca. Prueba de bucles caja blanca. Pruebas de casos de prueba caja blanca.

Tom McCabe decia que el objetivo es asegurar que todos los valores han sido ejecutados una vez. Verdadero. Falso.

La complejidad durante la prueba basica blanca se trata de una medición del software que proporciona una evaluación simple de una tarea. Verdadero. Falso.

La complejidad durante la prueba basica blanca se trata de una medición del software que proporciona una evaluación cuantitativa compleja lógica de un programa. Verdadero. Falso.

La complejidad durante la prueba basica blanca se trata de una medición del software que proporciona una evaluación cuantitativa compleja dinamica de un programa. Verdadero. Falso.

En la complejidad durante la prueba básica blanca su valor define el número de valores distintos que hemos puestos. Verdadero. Falso.

En la complejidad durante la prueba básica blanca su valor define el número de rutas independientes del conjunto básico de un programa. Verdadero. Falso.

La complejidad durante la prueba básica blanca constituye un indicador del número de pruebas necesarias para que las sentencias se ejecuten. Verdadero. Falso.

Calcula de la complejidad ciclomática (VG). V(G) 1. V(G) 2. V(G) 3.

Cálcula de la complejidad ciclomática V(G) 1. Número de regiones del grafo de flujo. NumAristas - NumNodos + 2. NumNodosPredicado + 1.

Cálcula de la complejidad ciclomática V(G) 2. Número de regiones del grafo de flujo. NumAristas - NumNodos + 2. NumNodosPredicado + 1.

Cálcula de la complejidad ciclomática V(G) 3. Número de regiones del grafo de flujo. NumAristas - NumNodos + 2. NumNodosPredicado + 1.

Influencia V(G) en las pruebas : deben tener una complejidad ciclomática es una medición útil para predecir aquellos módulos proclives al error. Verdadero. Falso.

Influencia V(G) en las pruebas : cuanto menor sea la complejidad ciclomática de un módulo mayor es la probabilidad de encontrar errores. Verdadero. Falso.

Influencia V(G) en las pruebas : cuanto mayor sea la complejidad ciclomática de un módulo mayor es la probabilidad de encontrar errores. Verdadero. Falso.

Influencia V(G) en las pruebas : debe priorizarse el diseño de pruebas para modelos con V(G) alto. Verdadero. Falso.

Paso 1 en el diseño de caso prueba de ruta básica. Dibujar el grafo de flujo asociado al diseño o código base utilizados. Determinar la complejidad ciclomática del grafo de flujo. Determinar el conjunto básico de rutas linealmente independientes. Preparar casos de prueba que sigan cada ruta del conjunto básico. Si alguna no se puede ejecutar por sí sola, puede entonces probarse como parte de otra ruta.

Paso 2 en el diseño de caso prueba de ruta básica. Dibujar el grafo de flujo asociado al diseño o código base utilizados. Determinar la complejidad ciclomática del grafo de flujo. Determinar el conjunto básico de rutas linealmente independientes. Preparar casos de prueba que sigan cada ruta del conjunto básico. Si alguna no se puede ejecutar por sí sola, puede entonces probarse como parte de otra ruta.

Paso 3 en el diseño de caso prueba de ruta básica. Dibujar el grafo de flujo asociado al diseño o código base utilizados. Determinar la complejidad ciclomática del grafo de flujo. Determinar el conjunto básico de rutas linealmente independientes. Preparar casos de prueba que sigan cada ruta del conjunto básico. Si alguna no se puede ejecutar por sí sola, puede entonces probarse como parte de otra ruta.

Paso 4 en el diseño de caso prueba de ruta básica. Dibujar el grafo de flujo asociado al diseño o código base utilizados. Determinar la complejidad ciclomática del grafo de flujo. Determinar el conjunto básico de rutas linealmente independientes. Preparar casos de prueba que sigan cada ruta del conjunto básico. Si alguna no se puede ejecutar por sí sola, puede entonces probarse como parte de otra ruta.

Pruebas de bucles se trata de una técnica de prueba de caja blanca. Verdadero. Falso.

Pruebas de bucles se centra en la evaluación de los errores y es un elemento de los casos de pruebas. Verdadero. Falso.

Pruebas de bucles se centra en la validez de los bucles y es un elemento de los casos de la ruta básica. Verdadero. Falso.

Pruebas de bucles simple tiene un conjunto de pruebas donde n es el máximo número de pasadas permitidas. Verdadero. Falso.

Pruebas de bucles simples. Saltar por completo el bucle. Una sola pasada a través del bucle. Dos pasadas a través del bucle. m pasadas a través del bucle, donde m < n. n - 1, n y n + 1 pasadas a través del bucle. Saltar la mitad del bucle. Tres pasadas a trav´´es del bucle. n y n - 1 pasadas a través del bucle.

En los bucles animados debemos de no aplicar en ningún momento las pruebas del bucle simple. Verdadero. Falso.

En los bucles animados debemos de aplicar las pruebas de bucle simple. Verdadero. Falso.

En los bucles animados el número de pruebas debería disminuir con el paso del tiempo. Verdadero. Falso.

En los bucles animados el número de pruebas crecería genéticamente con el bucle de anidación. Verdadero. Falso.

En los bucles animados se sugiere comenzar con el bucle mas externo y establecer el resto de valores máximos. Verdadero. Falso.

En los bucles animados se sugiere comenzar con el bucle mas internos y establecer el resto a valores mínimos de sus parámetros de iteración. Verdadero. Falso.

Aplicar pruebas de bucles anidados para el bucle interno mientras que los externos serán los simples. Verdadero. Falso.

Continuar hasta que se hayan probado todos los bucles. Verdadero. Falso.

Pruebas de bucles concatenados, si los bucles son independiente. aplicar el enfoque de bucles simple. aplicar el enfoque de bucles anidados.

Pruebas de bucles no estructurados. siempre que sea posible se debe queda con el mismo diseño. siempre que sea posible deben rediseñarse como bucles estrucurados.

En las pruebas de la caja negra, deben estar enfocados en los requisitos dinamicos del software. Verdadero. Falso.

En las pruebas de la caja negra, deben estar enfocados en los requisitos funcionales del software. Verdadero. Falso.

En las pruebas de la caja negra, deben estar enfocados en los necesidades del usuario. Verdadero. Falso.

C.N -> funciones totalmente comprobables y correctas. Error detectable. Falso.

C.N -> funciones incorrectas o faltantes. Error detectable. Falso.

C.N -> Errores en el acceso a la estructura de datos y en la base de datos interna. Error detectable. Falso.

C.N -> Errores en las estructuras de datos o en acceso a base de datos externas. Error detectable. Falso.

C.N -> Errores de inicialización o de terminación. Error detectable. Falso.

La partición de equivalencia es una técnica de caja blanca. Verdadero. Falso.

La partición de equivalencia es una técnica de caja negra. Verdadero. Falso.

La partición de equivalencia es una divide el dominio de entrada de un programa en clases de equivalencias. Verdadero. Falso.

La partición de equivalencia es una divide el dominio de entrada de un programa en clases de equivalencias. a partir de las cuales pueden generar casos de particiones simples. a partir de las cuales puede generara casos de uso dinamicos. a partir de las cuales puede generar casos de uso.

Una clase de equivalencia representa un conjuntos de valores para un tipo de entrada. Verdadero. Falso.

Una clase de equivalencia representa un conjuntos de estados validos e invalidos para condiciones de entrada. Verdadero. Falso.

Clases de equivalencia -> rango de valores. una clase válida y dos invalidas. una clase válida y una invalidas.

Clases de equivalencia -> miembro de un conjunto. una clase válida y dos invalidas. una clase válida y una invalidas.

Las clases de equivalencia depende del tipo de estado si valido o invalido. Verdadero. Falso.

Las clases de equivalencia depende del tipo de condiciones de entrada. Verdadero. Falso.

Diseño de prueba P1. identificación de las clases de equivalencia. identificación de los casos de prueba.

Diseño de prueba P2. identificación de las clases de equivalencia. identificación de los casos de prueba.

Diseño de casos de prueba. Identificación de las clases de equivalencia. Identificación de los casos de pruebas.

En el primero paso de el diseño de casos de prueba debemos de identificar el rango de valores y los miembros de un conjunto. Verdadero. Falso.

En el primero paso de el diseño de casos de prueba debemos de identificar las clases de equivalencias invalidas y validad. Verdadero. Falso.

En el primero paso de el diseño es Identificar las clases de equivalencia. Verdadero. Falso.

En el primero paso de el diseño es Identificar lo casos de prueba. Verdadero. Falso.

En el segundo paso de el diseño es Identificar lo casos de prueba. Verdadero. Falso.

En el segundo paso de el diseño es Identificar las clases de equivalencia. Verdadero. Falso.

En el segundo paso del diseño de casos de prueba escribirmos el mayor número de casos de pruebas. Verdadero. Falso.

En el segundo paso del diseño de casos de prueba escribirmos el menor número de casos de pruebas. Verdadero. Falso.

En el segundo paso del diseño de casos de prueba escribirmos el menor número de casos de pruebas. para cubrir el total de clases de equivalencias invalidas. para cubrir el total de clases de equivalencias validas.

En el segundo paso del diseño de casos de prueba escribimos un caso de prueba para cada clase invalidad. para corregir errores más facilmente. para facilitar el control de los posibles errores.

El análisis de fronteras es una técnica de caja blanca. Verdadero. Falso.

El análisis de fronteras es una técnica de caja negra. Verdadero. Falso.

El análisis de fronteras se centra en las fronteras internas mas que las externas. Verdadero. Falso.

El análisis de fronteras se centra en las fronteras del dominio de salida mas que en lso valores centrales. Verdadero. Falso.

El análisis de fronteras se centra en las fronteras del dominio de entrada mas que en los valores centrales. Verdadero. Falso.

El análisis de fronteras el primero criterio de aplicación en función de la entrada es que hay que especificar unn rango ilimitado. Verdadero. Falso.

El análisis de fronteras el primero criterio de aplicación en función de la entrada es que hay que especificar un rango limitado. Verdadero. Falso.

El análisis de fronteras el primero criterio de aplicación en función de la entrada es que hay que especificar un rango limitado. deben incluir los valores justamente anteriores y posteriores. deben incluir los valores justamente posteriores. deben incluir los valores justamente anteriores.

El análisis de fronteras el primero segundo de aplicación, aplican el punto uno a las comprobaciones entreda. Verdadero. Falso.

El análisis de fronteras el primero segundo de aplicación, aplican el punto uno a las comprobaciones salida. Verdadero. Falso.

El análisis de fronteras el tercero de aplicación, las estructuras si tienen fronteras deben probarlas. Verdadero. Falso.

OATS -> Estrategia de prueba del array octogonal. Verdadero. Falso.

OATS -> se trata de un método científico de resolución de pares. Verdadero. Falso.

OATS -> se trata de un método estadístico sistemático de prueba de interacciones por pares. Verdadero. Falso.

OATS -> dificulta una cobertura representativa de todas las combinaciones de variables a analizar. Verdadero. Falso.

OATS -> facilita una cobertura representativa de todas las combinaciones de equivalencia. Verdadero. Falso.

OATS -> facilita una cobertura representativa de todas las combinaciones de variables a analizar. Verdadero. Falso.

OATS -> el tango de valores para una variable debe ser ilimitado. Verdadero. Falso.

OATS -> el tango de valores para una variable debe ser limitado. Verdadero. Falso.

OATS -> puede combinarse con el uso de particiones de valores de fronteras. Verdadero. Falso.

OATS -> puede combinarse con el uso de particiones de valores de equivalencia. Verdadero. Falso.

OATS -> puede combinarse con el uso de particiones de valores de equivalencia. para limitar los valores posibles de una variable. para encontrar todas las posibles variables.

OATS -> nos aporta una selección estática de los casos de prueba. Verdadero. Falso.

OATS -> nos aporta una selección inteligente de los casos de prueba. Verdadero. Falso.

OATS -> diferenciación en lo que nos aporta los casos de prueba : pruebas sin fin. que probablemente encuentren pocos errores sin aumentar la confianza en el sistema. que detectará muchos más errores y nos dará una mayor confianza en la calidad de nuestro sistema.

OATS -> diferenciación en lo que nos aporta los casos de prueba : pruebas bien definidas y consisas. que probablemente encuentren pocos errores sin aumentar la confianza en el sistema. que detectará muchos más errores y nos dará una mayor confianza en la calidad de nuestro sistema.

OATS una técnica se usa cuando la prueba resulta particularmente útil para las combianciones de componente. Verdadero. Falso.

OATS una técnica se usa cuando el resutlado es intereante para las pruebas basadas en combinaciones de opciones configurables. Verdadero. Falso.

OATS las interacciones y las integraciones son una importante fuente de defectos. Ventaja. Falso.

OATS la menor parte de los defectos vienen araigamos por las interacciones entre las integraciones. Ventaja. Falso.

OATS la mayor parte de los defectos son consecuencia de la interacción entre pares de variables. Ventaja. Falso.

OATS garantiza la pruebas individuales de todas las varibales. Ventaja. Falso.

OATS garantiza la pruebas por parejas de todas las variables. Ventaja. Falso.

OATS puede añadir manualmente algunas combinaciones críticas de las variables. Ventaja. Falso.

OATS las pruebas se tienen que general complicada así nos aseguramos de que la cobertura sea lo más estable posible. Ventaja. Falso.

OATS las pruebas se tienen que generar de forma sencilla y con mayor cobertura que las pruebas generadas a mano. Ventaja. Falso.

OATS Runs. número de filas del array. Coincide con el número de casos de prueba generados. número de columnas del array. Coincide con el máximo número de variables que puede gestionar el array. número máximo de valores que puede tomar un factor. número de columnas a tener en cuenta para que las Levels posibilidades se repitan un mismo número de veces. debe ser siempre múltiplo de Levels^Strength.

OATS Factors: número de filas del array. Coincide con el número de casos de prueba generados. número de columnas del array. Coincide con el máximo número de variables que puede gestionar el array. número máximo de valores que puede tomar un factor. número de columnas a tener en cuenta para que las Levels posibilidades se repitan un mismo número de veces. debe ser siempre múltiplo de Levels^Strength.

OATS Levels. número de filas del array. Coincide con el número de casos de prueba generados. número de columnas del array. Coincide con el máximo número de variables que puede gestionar el array. número máximo de valores que puede tomar un factor. número de columnas a tener en cuenta para que las Levels posibilidades se repitan un mismo número de veces. debe ser siempre múltiplo de Levels^Strength.

OATS Strength. número de filas del array. Coincide con el número de casos de prueba generados. número de columnas del array. Coincide con el máximo número de variables que puede gestionar el array. número máximo de valores que puede tomar un factor. número de columnas a tener en cuenta para que las Levels posibilidades se repitan un mismo número de veces. debe ser siempre múltiplo de Levels^Strength.

OATS El valor de Runs. número de filas del array. Coincide con el número de casos de prueba generados. número de columnas del array. Coincide con el máximo número de variables que puede gestionar el array. número máximo de valores que puede tomar un factor. número de columnas a tener en cuenta para que las Levels posibilidades se repitan un mismo número de veces. debe ser siempre múltiplo de Levels^Strength.