Téc D.P.- Basadas en la experiencia (K2).

Objetivos:

1. Retener las causas para escribir casos de prueba en base a la intuición, la experiencia y el conocimeinto de los defectos comunes (K1).
2. Comparar técnicas basadas en la experiencia con técnicas de pruebas basadas en la especificación (K2).

Términos usados en este artículo: PRUEBAS EXPLORATORIAS, ATAQUE (falta).

Antecedentes. 

Las pruebas basadas en la experiencia son aquellas en las que las pruebas se derivan de la habilidad e intuición del probador y de su experiencia con aplicaciones y tecnologías similares. Si se utilizan para aumentar las técnicas sistemáticas, estas técnicas pueden ser útiles a la hora de identificar pruebas especiales que no pueden capturarse fácilmente mediante técnicas formales, especialmente si se aplican después de adoptar enfoques más formales. No obstante, esta técnica puede tener distintos grados de efectividad, en función de la experiencia del probador.

• Una técnica basada en la experiencia muy usada es la predicción de error.
• En general los probadores anticipan los defectos en base a su experiencia.
• Un enfoque estructurado de la técnica de predicción de error consiste en enumerar una lista de posibles defectos y diseñar pruebas para atacar dichos defectos.

Este enfoque sistemático se denomina ataque de faltas. Esta lista de defectos y fallos puede elaborarse en base a la experiencia, a los datos disponibles sobre defectos y fallos y a partir del conocimiento común sobre por qué falla el software.

Las pruebas exploratorias coinciden con las fases de diseño de pruebas, ejecución de pruebas , registro de pruebas y aprendizaje , en base a un contrato de pruebas que contempla los objetivos de las pruebas, y se llevan a cabo dentro de los períodos de tiempo establecidos.

Se trata de un enfoque especialmente útil en los casos en los que las especificaciones son escasas o inadecuadas y existe una importante presión temporal, o para aumentar o complementar otras pruebas más formales. Asimismo, puede servir como comprobación del proceso de pruebas, para ayudar a garantizar que los defectos más graves han sido efectivamente detectados.

Definición de técnicas basadas en la experiencia.

• Práctica para la creación de casos de pruebas sin un claro enfoque metodológico basada en la intuición y experiencia del probador.
• Los casos de prueba están basados en la intuición y experiencia.
• ¿Dónde se han acumulado errores en el pasado?
• ¿Dónde falla normalmente el software?

Fundamentos.

• Las pruebas basadas en la experiencia también se denomina pruebas intuitivas ("intuitive testing") e incluyen predicciones de errores ("error guessing")( pruebas orientadas a puntos débiles) y pruebas exploratorias (pruebas iterativas basadas en el conocimiento adquiridos respecto del sistema).
• Principalmente aplicadas con el objeto de completar otros casos de pruebas generados con un mayor formalismo.
• No cumple los criterios de un proceso de prueba sistemático.
• Frecuentemente produce casos de pruebas adicionales que no podrían ser creados con otras prácticas, por ejemplo:

1. Pruebas de un año bisiesto posterior al año 60 (problema conocido en el pasado)
2. Conjuntos vacíos en valores de entrada (una aplicación similar ha tenido valores en estas circunstancias). 

Diseño de caso de prueba.

El probador debe contar con experiencia o conocimiento aplicables / relevantes al caso.

• Intuición: ¿Dónde se pueden esconder los defectos? - La intuición caracteriza a un buen probador.
• Experiencia: ¿Qué defectos han sido detectados y dónde en el pasado?
• Conocimiento / percepción - ¿Dónde se esperan defectos especificados? 
• - Se incluyen detalles específicos del proyecto.
• - ¿Dónde se producirán defectos como consecuencia de la presión por los plazos y la complejidad?
• ¿Están involucrados programadores sin experiencia?

Diseño intuitivo de casos de prueba - posibles fuentes.

• Resultados de pruebas y experiencia práctica con sistemas similares. - Posiblemente un predecesor del software u otro sistema con funcionalidad similar.
• Experiencia de usuario. - Intercambio de experiencia con el sistema como usuario del mismo.
• Enfoque del despliegue.- ¿Qué partes del sistema serán utilizados con mayor frecuencia?
• Problemas de desarrollo.- ¿Hay algún punto débil como resultado de dificultades en el proceso de desarrollo?

Predicción de errores ("error guessig") en la práctica.

• Comprobar lista de defectos.

1. - Enumerar posibles errores.
2. - Factores ponderados dependientes del riesgo y probabilidad de ocurrencia.

• Diseño de caso de prueba.

1. - Creación de casos de prueba dirigidos a producir los defectos de la lista.
2. - Aumentar la prioridad a aquellos casos de prueba considerando el valor de su riesgo.

• Actualizar la lista de defectos durante las pruebas.

1. - Procedimiento iterativo.
2. Es útil una colección estructurada de experiencia cuando se repite el procedimiento en futuros proyectos. 

Pruebas exploratorias ("exploratory testing").

• Es un procedimiento de diseño de casos de prueba especialemnte apropiado cunado la información base se encuentra poco estructurada.
• También es útil cuando el tiempo disponible para pruebas es escaso.
• Procedimiento:

1. - Revisar las partes constituyentes (individuales/identificables) del objeto de prueba.
2. - Ejecutar un número reducido de casos de prueba exclusivamente sobre aquellas partes que deben ser probadas, aplicando predicción de errores ("errores guessing").
3. - Analizar los resultados, desarrollar un modelo preliminar ("rough model") de cómo funciona el objeto de prueba.
4. - Iteración. Diseñar nuevos objetos de prueba aplicando el conocimiento adquirido recientemente.
5. - Por lo tanto concentrándose en las áreas relevantes y explorando características adicionales del objeto de prueba.
6. Herramientas de captura pueden ser útiles para registrar las actividades de pruebas.
7. Seleccionar objetos pequeños y/o concentrándose en aspectos particulares del objeto de pruebas. - Una iteración unitaria no debería llevar más de 2 horas.
8. Los resultados de una iteración constituyen la base de información para la siguiente iteración.- Se obtienen casos de prueba adicionales a partir de la situación particular de la prueba.
9. El modelado tiene lugar durante el proceso de pruebas.- El diseño , ejecución , registro y aprendizaje basados en una carta de prueba ("test charter") que contiene los objetivos de prueba son concurrentes y ejecutado en ventanas temporales ("time boxes").
10. Preparación de pruebas adicionales.- Con esto, el conocimiento puede ser adquirido para apoyar la elección apropiada de métodos de diseño de casos de prueba.   

Pruebas basadas en la experiencia versus pruebas basadas en la especificación.

• El diseño intuitivo de casos de prueba es un buen complemento a los enfoques sistemáticos.

1. -  debería ser tratados como una actividad complementaria.
2. - No puede dar constancia de completitud - el número de casos de prueba puede variar de forma considerable.

• Las pruebas son ejecutadas de la misma manera que los son los casos de pruebas definidos en forma sistemática.
• La diferencia es la forma en la cual los casos de prueba han sido diseñados I identificados.
• A través de pruebas intuitivas se puede detectar defectos que no podrían ser detectados a través de métodos sistemáticos de prueba.

Concluyendo:

• Las técnicas basadas en la experiencia complementan las técnicas sistemáticas para determinar casos de pruebas.
• Las técnicas basadas en la experiencia dependen en gran medida de la habilidad individual del probador.
• La predicción de errores y las pruebas exploratorias son dos de las técnicas más ampliamente utilizadas de pruebas basadas en la experiencia.

Pregunta de examen:

40 Error guessing is best used

a) As the first approach to deriving test cases

b) After more formal techniques have been applied-->OK

c) By inexperienced testers

d) After the system has gone live

e) Only by end users

40 Adivinando error es el más utilizado cuando..

a) Como primera aproximación derivar casos de prueba

b) Una vez se han aplicado las técnicas más formales-->OK

c) Por probadores inexperto

d ) Después de que el sistema ha ido en directo

e) Sólo los usuarios finales

Téc de Diseño de Pruebas - Caja Blanca - Resumen (K4).

Objetivos:

1. Describir el concepto y el valor de la cobertura de código (K2).
2. Explicar los conceptos de sentencia y cobertura de decisión y explicar por qué estos conceptos pueden utilizarse también en niveles de prueba que no sean pruebas de componente (por ejemplo, en procedimientos de negocio a nivel de sistema)(K2).
3. Escribir casos de prueba a partir de flujos de control de datos utilizando técnicas de diseño de pruebas de decisión y sentencia (K3).
4. Evaluar la cobertura de sentencia y decisión para la integridad por lo que respecta a los criterios de salida definidos (K4).

Términos usados en este artículo: COBERTURA DE CÓDIGO, COBERTURA DE DECISIÓN, COBERTURA DE SENTENCIA, PRUEBAS BASADAS EN LA ESTRUCTURA.

Concluyendo:

1. Los métodos de caja blanca y caja negra son métodos dinámicos, el objeto de prueba es ejecutado durante las pruebas.
2. El método de caja blanca (white box) comprende:                                                                           - Cobertura de sentencia.                                                                                                                      - Cobertura de decisión.                                                                                                                     - Cobertura de camino.                                                                                                                                            - Cobertura de condición (simple y múltiple). 
3. Sólo se puede probar código existente. Habiendo funciones faltantes , este hecho no puede ser detectado. Sin embargo el código muerto o superfluo puede ser detectado con las pruebas de caja blanca.
4. Principalmente, los métodos de caja blanca son utilizados en pruebas de bajo nivel como pruebas de componentes o pruebas de integración.
5. Los métodos difieren en la intensidad de las pruebas (profundidad de la prueba).                     - Dependiendo del método , el número de casos de prueba es distinto.

Téc D P - Caja Blanca - Prueba de Camino y Cobertura (K4).

Objetivos:

1. Describir el concepto y el valor de la cobertura de código (K2).
2. Explicar los conceptos de sentencia y cobertura de decisión y explicar por qué estos conceptos pueden utilizarse también en niveles de prueba que no sean pruebas de componente (por ejemplo, en procedimientos de negocio a nivel de sistema)(K2).
3. Escribir casos de prueba a partir de flujos de control de datos utilizando técnicas de diseño de pruebas de decisión y sentencia (K3).
4. Evaluar la cobertura de sentencia y decisión para la integridad por lo que respecta a los criterios de salida definidos (K4).

Términos usados en este artículo: COBERTURA DE CÓDIGO, COBERTURA DE DECISIÓN, COBERTURA DE SENTENCIA, PRUEBAS BASADAS EN LA ESTRUCTURA.

Prueba de camino y cobertura ("path testing and coverage").

La cobertura de camino se centra en la ejecución de todos los posibles caminos a través de un programa.

• Un camino es una combinación de segmentos de programa (en un gráfico "diagrama" de flujo de control : una secuencia de nodos y aristas alternados).
• Para cobertura de decisión, un solo camino a través de un bucle es suficiente. Para la cobertura de camino hay casos de prueba adicionales.

         a).- Un caso de prueba no entrante al bucle.
         b).- Un caso de prueba adicional para cada ejecución del bucle.

• Esto puede conducir a un número muy alto de casos de prueba
• El foco del análisis de cobertura es el gráfico ("diagrama") de flujo de control.

          a).- Las sentencias son nodos.
          b).- El flujo de control es una vía única desde el inicio al fin del diagrama de flujo de control.

• El objetivo de esta prueba (criterio de salida) es alcanzar un porcentaje definido de cobertura de camino.

Ejemplo 1:

• El gráfico ("diagrama") de flujo de control de la imagen, representa el segmento de programa a ser evaluado.

• Contiene 3 sentencias "if".
• 3 caminos diferentes conducen a través del diagrama de este segmento de programa logran una cobertura de decisión completa.
• Sin embargo, pueden ser ejecutadas 5 posibles caminos distintos.
• Son necesarios 5 casos de prueba para lograr un 100% de cobertura de camino.
• Sólo 2 son necesarios para un 100% de cobertura de sentencia (C0).
• Sólo 3 son necesarios para un 100% de cobertura de rama o decisión (C1).  

Ejemplo 2:

• El diagrama de flujo  de control de la imagen , representa el segmento de programa a ser evaluado.

• Contiene 2 sentencia "if" y un bucle en el interior de la segunda sentencia if.
• 3 caminos diferentes que conducen a través del diagrama de este segmento de programa logran una cobertura de decisión completa.
• Si el bucle se ejecuta 2 veces, son posibles 4 caminos diferentes.
• Cada incremento en el contador del bucle añade un nuevo caso de prueba.

Conclusiones Generales.

• El 100% de cobertura de camino sólo se puede lograr en programas muy simples.
• Un sólo bucle puede conducir a una explosión de casos de prueba dado que, toda posible jecución de un bucle constituye un nuevo caso de prueba.
• teóricamente es posible un número indefinido de caminos.
• La Cobertura de camino a través del programa es ejecutado.
• 100% de cobertura de camino incluye 100% de cobertura de decisión, que asu vez incluye 100% de cobertura de sentencia.

Téc D P - Caja Blanca - Cobertura de Condición - Conclusiones Generales (K4).

Objetivos:

1. Describir el concepto y el valor de la cobertura de código (K2).
2. Explicar los conceptos de sentencia y cobertura de decisión y explicar por qué estos conceptos pueden utilizarse también en niveles de prueba que no sean pruebas de componente (por ejemplo, en procedimientos de negocio a nivel de sistema)(K2).
3. Escribir casos de prueba a partir de flujos de control de datos utilizando técnicas de diseño de pruebas de decisión y sentencia (K3).
4. Evaluar la cobertura de sentencia y decisión para la integridad por lo que respecta a los criterios de salida definidos (K4).

Términos usados en este artículo: COBERTURA DE CÓDIGO, COBERTURA DE DECISIÓN, COBERTURA DE SENTENCIA, PRUEBAS BASADAS EN LA ESTRUCTURA.

Cobertura de condición ("condition coverage") Conclusiones Generales.

• La cobertura  de condición simple es un instrumento débil para probar condiciones múltiples.
• La cobertura de condición múltiple es un método mucho mejor.

          a).- Asegura cobertura de sentencia y decisión.
          b).- Sin embargo , tiene como resultado un alto número de casos de prueba: 2^n.
          c).- La ejecución de algunas combinaciones no es posible. Por ejemplo "x>5 and x< 10"  ambas condiciones no pueden ser falsas al mismo tiempo.

• La mínima cobertura de condición múltiple es incluso mejor, debido a :

          a).- Reduce el número de casos de prueba [de (n+1) a (2n))].
          b).- Las coberturas de sentencia y decisión también son cubiertas.
          c).- Tiene en cuenta la complejidad de las sentencias de decisión.

• Todas las decisiones complejas deben ser probadas - la mínima cobertura de condición múltiple es adecuada para lograr este objetivo.

Téc D P - Caja Blanca - Mínima Cobertura de Condición Múltiple (K4).

Objetivos:

1. Describir el concepto y el valor de la cobertura de código (K2).
2. Explicar los conceptos de sentencia y cobertura de decisión y explicar por qué estos conceptos pueden utilizarse también en niveles de prueba que no sean pruebas de componente (por ejemplo, en procedimientos de negocio a nivel de sistema)(K2).
3. Escribir casos de prueba a partir de flujos de control de datos utilizando técnicas de diseño de pruebas de decisión y sentencia (K3).
4. Evaluar la cobertura de sentencia y decisión para la integridad por lo que respecta a los criterios de salida definidos (K4).

Términos usados en este artículo: COBERTURA DE CÓDIGO, COBERTURA DE DECISIÓN, COBERTURA DE SENTENCIA, PRUEBAS BASADAS EN LA ESTRUCTURA.

Mínima Cobertura de condición múltiple (" Minimum multiple condition coverage").

• Toda  las combinaciones que puedan ser creadas utilizando los resultados lógicos de cada sub-condición deben ser parte de las pruebas, sólo si el cambio del resultado de una sub-condición cambia el resultado de la condición combinada.

• Este ejemplo se utiliza para  explicar la cobertura de condición utilizando una expresión con una condición múltiple.
• Los cambios de una sub-condición cambian el resultado global para 3 de 4 casos de prueba. Sólo para el caso 2 (true or true ) el cambio en la sub-condición no resultará en un cambio en la condición global. Este caso de prueba puede ser omitido.
• El número de casos de prueba se puede deducir a un valor entre:

                                                                      n+1    y   2n 

Téc D P - Caja Blanca - Cobertura de Condición Múltiple (K4).

Objetivos:

1. Describir el concepto y el valor de la cobertura de código (K2).
2. Explicar los conceptos de sentencia y cobertura de decisión y explicar por qué estos conceptos pueden utilizarse también en niveles de prueba que no sean pruebas de componente (por ejemplo, en procedimientos de negocio a nivel de sistema)(K2).
3. Escribir casos de prueba a partir de flujos de control de datos utilizando técnicas de diseño de pruebas de decisión y sentencia (K3).
4. Evaluar la cobertura de sentencia y decisión para la integridad por lo que respecta a los criterios de salida definidos (K4).

Términos usados en este artículo: COBERTURA DE CÓDIGO, COBERTURA DE DECISIÓN, COBERTURA DE SENTENCIA, PRUEBAS BASADAS EN LA ESTRUCTURA.

Cobertura de condición múltiple ("multiple condition coverage").

• Todas las combinaciones que puedan ser creadas utilizando permutaciones de las sub condiciones atómicas deben formar parte de las pruebas.

• Este ejemplo se utiliza para explicar la cobertura de condición utilizando una expresión con una condición múltiple.
• Con 4 casos de pruebas se puede lograr una cobertura de condición múltiple. Se han creado todas las combinaciones de los valores verdaderos ("true") y falso ("false"). Se han logrado todos los posibles resultados de la condición múltiple.
• El número de caso de prueba se incrementa de forma potencial:

                      n = número de condiciones atómicas.

                      2^n = número de casos de pruebas.

Téc D P - Caja Blanca - Cobertura de Condición Simple (K4).

Objetivos:

1. Describir el concepto y el valor de la cobertura de código (K2).
2. Explicar los conceptos de sentencia y cobertura de decisión y explicar por qué estos conceptos pueden utilizarse también en niveles de prueba que no sean pruebas de componente (por ejemplo, en procedimientos de negocio a nivel de sistema)(K2).
3. Escribir casos de prueba a partir de flujos de control de datos utilizando técnicas de diseño de pruebas de decisión y sentencia (K3).
4. Evaluar la cobertura de sentencia y decisión para la integridad por lo que respecta a los criterios de salida definidos (K4).

Términos usados en este artículo: COBERTURA DE CÓDIGO, COBERTURA DE DECISIÓN, COBERTURA DE SENTENCIA, PRUEBAS BASADAS EN LA ESTRUCTURA.

Cobertura de condición simple ("simple condition coverage").

• Cada sub-condición atómica de una sentencia condicional combinada tiene que tomar, al menos una vez, los valores lógicos verdadero ("true") así como falso ("false").

Ejemplo:

1. Este ejemplo se utiliza para explicar la cobertura de condición utilizando una expresión con una condición múltiple.
2. Con sólo dos casos de prueba se puede lograr una cobertura de condición simple.- Cada sub-condición ha tomado los valores verdadero ("true") y falso ("falso").
3. Sin embargo, el resultado combinado es verdadero ("true") en ambos casos: 

     - true OR false = true

     - false OR true = true

Téc D P - Caja Blanca - Pruebas de Condición y Cobertura (K4).

Objetivos:

1. Describir el concepto y el valor de la cobertura de código (K2).
2. Explicar los conceptos de sentencia y cobertura de decisión y explicar por qué estos conceptos pueden utilizarse también en niveles de prueba que no sean pruebas de componente (por ejemplo, en procedimientos de negocio a nivel de sistema)(K2).
3. Escribir casos de prueba a partir de flujos de control de datos utilizando técnicas de diseño de pruebas de decisión y sentencia (K3).
4. Evaluar la cobertura de sentencia y decisión para la integridad por lo que respecta a los criterios de salida definidos (K4).

Términos usados en este artículo: COBERTURA DE CÓDIGO, COBERTURA DE DECISIÓN, COBERTURA DE SENTENCIA, PRUEBAS BASADAS EN LA ESTRUCTURA.

Pruebas de condición y cobertura.

• Se tiene en cuenta la complejidad de una condición que esté constituida por múltiples condiciones atómicas.- Una condición atómica o puede ser dividida en sentencias condicionales más pequeñas.
• Éste método tiene por objetivo detectar defectos que resulten de la implementación de condiciones múltiples (condiciones combinadas).

1.   Las condiciones múltiples están constituidas por condiciones atómicas, que se combinan con el uso de operadores lógicos como : OR, AND, NOR, etc.
2.   Las condiciones atómicas no contienen operadores lógicos sólo contienen operadores relacionales y el operador NOT (= >. <=, etc)-

• Hay tres tipos de cobertura de condición:

1.    Cobertura de condición simple ("simple condition coverage").
2.    Cobertura de condición múltiple (multiple condition coverage).
3.    Mínimo cobertura  de condición múltiple ("minimun multiple condition coverage").

Téc D P - Caja Blanca - Sentencias y Cobertura - Decisión y Cobertura (K4).

Objetivos:

1. Describir el concepto y el valor de la cobertura de código (K2).
2. Explicar los conceptos de sentencia y cobertura de decisión y explicar por qué estos conceptos pueden utilizarse también en niveles de prueba que no sean pruebas de componente (por ejemplo, en procedimientos de negocio a nivel de sistema)(K2).
3. Escribir casos de prueba a partir de flujos de control de datos utilizando técnicas de diseño de pruebas de decisión y sentencia (K3).
4. Evaluar la cobertura de sentenca y decisión para la integridad por lo que respecta a los criterios de salida definidos (K4).

Términos usados en este artículo: COBERTURA DE CÓDIGO, COBERTURA DE DECISIÓN, COBERTURA DE SENTENCIA, PRUEBAS BASADAS EN LA ESTRUCTURA.

Pruebas de sentencias y coberturas y Pruebas de decisión y cobertura.

• Ambos métodos se refieren a caminos a través del diagrama de flujo de control. - Difieren en la cantidad de casos de pruebas necesarios para lograr el 100% de cobertura.
• Sólo se considera el resultado final de una condición a pesar de que la condición resultante puede estar constituida por múltiples condiciones atómicas.

1.   La condición if ((a>2) o (b>6)) sólo puede ser verdadera o falsa.
2.   El camino (del programa) a ejecutar depende solamente del resultado final de la condición combinada.
3.   Aquellos fallos debidos a una implementación erróneo de las partes de una decisión combinada pueden no ser detectados.

Téc D P - Caja Blanca - Conclusiones Generales (K4).

Objetivos:

1. Describir el concepto y el valor de la cobertura de código (K2).
2. Explicar los conceptos de sentencia y cobertura de decisión y explicar por qué estos conceptos pueden utilizarse también en niveles de prueba que no sean pruebas de componente (por ejemplo, en procedimientos de negocio a nivel de sistema)(K2).
3. Escribir casos de prueba a partir de flujos de control de datos utilizando técnicas de diseño de pruebas de decisión y sentencia (K3).
4. Evaluar la cobertura de sentenca y decisión para la integridad por lo que respecta a los criterios de salida definidos (K4).

Términos usados en este artículo: COBERTURA DE CÓDIGO, COBERTURA DE DECISIÓN, COBERTURA DE SENTENCIA, PRUEBAS BASADAS EN LA ESTRUCTURA.

Conclusiones Generales:

1. Lograr una cobertura de decisión del 100% requiere, al menos , los mismos casos de prueba que requiere la cobertura de sentencia - mayor cantidad en la mayoría de los casos. - Una cobertura de decisión del 100% siempre incluye una cobertura de sentencia del 100%.
2. La mayoría de las aristas son cubiertas en múltiples ocasiones.
3. Desventajas:

•   No se pueden detectar sentencias faltantes.
•   No es suficiente para probar condiciones complejas.
•   No es suficiente para probar bucles de formas extensivas.
•   No se consideran las dependencias entre bucles.

Téc D P - Caja Blanca - Cobertura de Decisión (K4).

Objetivos:

1. Describir el concepto y el valor de la cobertura de código (K2).
2. Explicar los conceptos de sentencia y cobertura de decisión y explicar por qué estos conceptos pueden utilizarse también en niveles de prueba que no sean pruebas de componente (por ejemplo, en procedimientos de negocio a nivel de sistema)(K2).
3. Escribir casos de prueba a partir de flujos de control de datos utilizando técnicas de diseño de pruebas de decisión y sentencia (K3).
4. Evaluar la cobertura de sentenca y decisión para la integridad por lo que respecta a los criterios de salida definidos (K4).

Términos usados en este artículo: COBERTURA DE CÓDIGO, COBERTURA DE DECISIÓN, COBERTURA DE SENTENCIA, PRUEBAS BASADAS EN LA ESTRUCTURA.

Explicando la cobertura de decisión ("decision coverage").

• En lugar de las sentencias , la cobertura de decisión de centra en el flujo de control en un segmento de programa (no los nodos sino las aristas del diagrama de flujo de control).

1. - Todas las aristas del diagrama de flujo de control tiene que ser cubiertas al menos una vez.
2. - ¿Qué casos de pruebas son necesarias para cubrir cada arista del diagrama de flujo de control al menos una vez?.

• El propósito de esta prueba (criterio de salida) es lograr la cobertura de un porcentaje específico de todas las decisiones, denominado cobertura de decisión (C1 cobertura de decisión - "decision coverage" ; cobertura de rama - "branch coverage").

Cobertura de decisión C1 = Número de decisiones ejecutadas * 100%

                                                                      ------------------------------------------------

                                     Número total de decisiones

Es sinónimo de:

Cobertura de decisión C1 = Número de decisiones ejecutadas - 100%

                                                                      ------------------------------------------------

                                     Número total de decisiones

Ejemplo 1: 

El gráfico ("diagrama") de flujo de control (imagen de arriba) representa el segmento de un programa de objeto de la evaluación.

Tres caminos diferentes conducen a través del diagrama de este segmento de programa.

1. La primera sentencia "if" conduce a dos direcciones diferentes.
2. Un camino de la priemra sentencia "if" se divide nuevamente en dos caminos diferentes, uno de los cuales contiene un bucle.
3. Solamente se puede alcanzar todas las aristas a través de una combinación de los tres caminos posibles.
4. Son necesarios tres casos de prueba para alcanzar una cobertura de decisión del 100%.
5. Utilizando solamente las dos direcciones de la derecha, pueden ser cubiertas nueve de diez aristas (C1 = 90%).

Ejemplo 2:

En este ejemplo el gráfico ("diagrama") es ligeramente más complejo.

Cuatro "caminos" diferentes conducen a través del segmento de programa.

1. La primera sentencia "if" permite dos direcciones.
2. En ambas ramas de la sentencia "if" otra sentencia "if" permite nuevamente dos direcciones diferentes.
3. En este ejemplo, el bucle no se cuenta como una decisión adicional.
4. Utilizando sólo un caso de pruebas, pueden ser cubiertas; de 15 aristas. Esto resulta en un valor de C1 = 46, 67%.
5. Son necesarios cuatro casos de pruebas para lograr una cobertura de decisión de 100%.
6. En este ejemplo , son necesarias el mismo conjunto de casos de prueba para lograr una cobertura de sentencia del 100%.

Téc D P - Caja Blanca - Cobertura de Sentencia (K4).

Objetivos:

1. Describir el concepto y el valor de la cobertura de código (K2).
2. Explicar los conceptos de sentencia y cobertura de decisión y explicar por qué estos conceptos pueden utilizarse también en niveles de prueba que no sean pruebas de componente (por ejemplo, en procedimientos de negocio a nivel de sistema)(K2).
3. Escribir casos de prueba a partir de flujos de control de datos utilizando técnicas de diseño de pruebas de decisión y sentencia (K3).
4. Evaluar la cobertura de sentenca y decisión para la integridad por lo que respecta a los criterios de salida definidos (K4).

Términos usados en este artículo: COBERTURA DE CÓDIGO, COBERTURA DE DECISIÓN, COBERTURA DE SENTENCIA, PRUEBAS BASADAS EN LA ESTRUCTURA.

Explicando la Cobertura de sentencia ("Statement coverage").

• El foco de la atención es la sentencia del código de un programa.- ¿Qué casos de prueba son necesarias con el objeto de ejecutar todas (o un porcentaje determinado) las sentencias del código existentes?
• La base de este análisis es el gráfico (o diagrama) de flujo de control ("control flow graph").

1. - Todas las instrucciones están representadas por nodos y el flujo de control entre instrucciones está está representado por aristas (flecha).
2. - Las instrucciones múltiples se combinan en un nodo independiente si solamente pueden ser ejecutados en una secuencia particular. 

• El objetivo de la prueba (criterio de salida) es lograr la cobertura de un porcentaje específico de todas las sentencias, denominado cobertura de sentencia. (Co Cobertura de código - "code coverage").

Ejemplo 1: Se evalúa el siguiente segmento de código de un programa, que está representado por el diagrama del flujo de control:

j = f(i);

if (j>10){

   for (k=i; k >10 ; k --){

     .......

   }

}

  









Considerar el programa representado por el gráfico (o diagrama) de flujo de control (imagen de arriba).

1. Contiene dos  sentencia "if" y un bucle "do - while" dentro de la segunda sentencia "if".
• Hay tres "caminos" diferentes a través del segmento de programa.
1. La primera sentencia "if" permite dos direcciones.
2. La dirección de la derecha de la primera sentencia "if" se divide nuevamente a partir de una segunda sentencia "if".
• Todas las sentencias de este programa pueden ser alcanzadas haciendo uso de este camino.
1. Un solo caso de prueba será suficiente para alcanzar el 100% de cobertura de sentencia.

Ejemplo 2: En este ejemplo el gráfico ("diagrama") es ligeramente más complejo:

 

• El programa contiene las sentencias "if" y un bucle (dentro de una sentencia "if").
• Cuatro caminos diferentes conducen a través de este segmento de programa. 
1. La primera sentencia "if" permite dos direcciones.
2. En cada rama de la sentencia "if" otra sentencia "if" permite nuevamente dos direcciones diferentes.
3. Para cada una cobertura de sentencia del 100% hacen falta cuatrocasos de prueba.

Conclusiones generales de la cobertura de sentencias.

• La medición de la cobertura se realiza con el uso de herramientas diseñadas de forma específica. - 

1. - Estas herramientas se denominan Herramientas de análisis de Cobertura ("Coverage Analysis Tools") o Analizadores de Cobertura ("Coverage Analyzers").

• Beneficios /desventajas de este método.

1. - Será detectado el código muerto, es decir, código constituido por sentencias que nunca se ejecutan.
2. - Si hay código muerto en el programa , no se podrá lograr una cobertura del 100%.

• No podrán ser detectados instrucciones faltantes, es decir, código que es necesario con el objeto de cumplir con la especificación.

1. - Las pruebas se desarrollan solamente respecto de sentencias ejecutadas, ¿Tódo el código puede ser alcanzado / ejecutado?.
2.  - El código faltante no puede ser detectado utilizando técnica de caja blanca (análisis de cobertura). 

Pregunta de examen:

13 Given the following:

Switch PC on

Start “outlook”

IF outlook appears THEN

Send an email

Close outlook

a) 1 test for statement coverage, 1 for branch coverage

b) 1 test for statement coverage, 2 for branch coverage-->OK

c) 1 test for statement coverage. 3 for branch coverage

d) 2 tests for statement coverage, 2 for branch coverage

e) 2 tests for statement coverage, 3 for branch coverage

13 Teniendo en cuenta lo siguiente:

Switch PC on

Start “outlook”

IF outlook appears THEN

Send an email

Close outlook

a) Prueba 1 para la cobertura de declaración, 1 para la cobertura de rama

b ) 1 prueba para la cobertura de sentencias , 2 para la cobertura de ramas-->OK

c ) 1 prueba para la cobertura de declaración. 3 para la cobertura de ramas

d ) 2 pruebas para la cobertura de declaración , 2 para la cobertura de ramas

e) 2 pruebas para la cobertura de declaración, 3 para la cobertura de la rama

14 Given the following code, which is true:

IF A > B THEN

C = A – B

ELSE

C = A + B

ENDIF

Read D

IF C = D Then

Print “Error”

ENDIF

a) 1 test for statement coverage, 3 for branch coverage

b) 2 tests for statement coverage, 2 for branch coverage-->OK

c) 2 tests for statement coverage. 3 for branch coverage

d) 3 tests for statement coverage, 3 for branch coverage

e) 3 tests for statement coverage, 2 for branch coverage

14 Dado el siguiente código, lo cual es cierto :

IF A > B THEN

C = A – B

ELSE

C = A + B

ENDIF

Read D

IF C = D Then

Print “Error”

ENDIF

a) Prueba 1 para la cobertura de declaración, 3 para la cobertura de la rama

b) 2 pruebas para la cobertura de sentencia, 2 para la cobertura de ramas-->OK

c ) 2 pruebas para la cobertura de declaración. 3 para la cobertura de ramas

d ) 3 pruebas para la cobertura de declaración , 3 para la cobertura de la rama

e) 3 pruebas para la cobertura de declaración, 2 para la cobertura de rama

15 Consider the following:
Pick up and read the newspaper
Look at what is on television
If there is a program that you are interested in watching then switch the the television on and watch
the program
Otherwise
Continue reading the newspaper
If there is a crossword in the newspaper then try and complete the crossword
a) SC = 1 and DC = 1
b) SC = 1 and DC = 2
c) SC = 1 and DC = 3
d) SC = 2 and DC = 2
e) SC = 2 and DC = 3-->OK

15 Considere lo siguiente 

Recogida y leer el periódico
Mira lo que está en la televisión
Si hay un programa que usted está interesado en ver a continuación, encienda el televisor encendido y 

reloj el programa
De otra manera
Seguir leyendo el periódico
Si hay un crucigrama en el periódico y luego tratar de completar el crucigrama
a) SC = 1 and DC = 1
b) SC = 1 and DC = 2
c) SC = 1 and DC = 3
d) SC = 2 and DC = 2
e) SC = 2 and DC = 3-->OK