unidad iii verificacion y validacion
DESCRIPTION
hoaTRANSCRIPT
2da. Parte
• Conocer los estándares asociados a la calidad del proceso de desarrollo de software y de productos de software.
• Conocer los componentes de un plan de aseguramiento de la calidad.
• Aplicar los elementos de un proceso de prueba (“testing”).
• Diseñar un plan de prueba unitario y de integración.
1) Calidad del software. Sistema de calidad. Certificación de la calidad.
2) Aseguramiento, Gestión y control de la calidad del software.
3) Factores y Métricas de la calidad del software.
4) El testing y su relación con el ciclo de vida de un sistema. Terminología y definiciones básicas.
5) Tipos de Pruebas: Funciones de negocios, Interfaces de usuarios, Performance, Carga, Estrés, Volumen, Configuración, Instalación, etc.
6) Técnicas de Prueba: Testing de Caja Negra vs Testing de Caja Blanca.
Verificación:“¿Estamos construyendo bien el producto?".
El software debe ser conforme a su especificación.
Validación:“¿Lo que estamos construyendo es realmente lo que el cliente quiere?".
El software debe hacer lo que el usuario realmente necesita.
Todo el ciclo de vida - V & V debe ser aplicado en cada etapa del proceso del software.
Tiene dos objetivos principales◦ El descubrimiento de los defectos en un sistema;
◦ La evaluación de si el sistema es útil y utilizable en una situación operacional.
Verificación y validación debe establecer la confianza de que el software es apto para el propósito.
Esto NO quiere decir completamente libre de defectos.
Por el contrario, debe ser lo suficientemente bueno para su uso y el tipo de uso para determinar el grado de confianza que se necesita.
Depende de la finalidad del sistema, las expectativas de los usuarios y el entorno de mercado◦ Función del software El nivel de confianza depende de la forma en que el
software es crítico para una organización.
◦ Las expectativas de los usuarios Los usuarios pueden tener bajas expectativas de
ciertos tipos de software.
◦ Entorno de Mercado Ser el primero en entregar un producto en el mercado
puede ser más importante que encontrar defectos en el programa.
Inspecciones de software. Analizan y comprueban las representaciones del sistema (verificación estática)◦ Puede ser complemento de la herramienta basada en el
documento y análisis de código
Pruebas de software. Implica ejecutar una implementación del software con datos de prueba. Observar el comportamiento del producto (dinámica de verificación)◦ El sistema se ejecuta con los datos de las pruebas de
funcionamiento y se observa su comportamiento
Puede revelar la presencia de errores pero no la Ausencia.
El software tiene que ser ejecutado para ver cómo se comporta.
Debería utilizarse junto con Verificación Estática para prestar toda la cobertura de V & V.
Pruebas de Defecto◦ Pruebas diseñadas para descubrir los defectos del sistema.
◦ El éxito de una prueba es un defecto que revela la presencia de defectos en un sistema.
Pruebas de validación◦ Para poner de manifiesto que el software cumple con sus
requisitos.
◦ El éxito es una prueba que demuestra que los requisitos han sido debidamente aplicados.
Pruebas de defecto y depuración son distintosProcesos.
Verificación y validación se refiere a establecer la existencia de defectos en un programa.
Depuración se refiere a la localización y laReparación de estos errores.
Depuración implica la formulación de una hipótesissobre el comportamiento del programa entonces estas pruebas aplican las hipótesis para encontrar el error del sistema.
Se necesita una planificación cuidadosa para obtener el máximo rendimiento de pruebas y de control de procesos.
La planificación debe empezar temprano en el proceso de desarrollo.
El plan debe determinar el equilibrio entre la verificación y las pruebas estáticas.
La planificación de las pruebas está relacionada con la definición de normas para el proceso de prueba, no solo con describir las pruebas de productos.
El proceso de pruebas◦ Una descripción de las principales fases del proceso de
prueba.
Trazabilidad de requerimientos◦ Los usuarios son los más interesados en que el sistema
satisfaga sus requerimientos y las pruebas deberían planificarse para que todos los requerimientos se prueben individualmente.
Elementos probados◦ Deberían especificarse los elementos del proceso del
software que tienen que ser aprobados.
Calendario de pruebas◦ Un calendario de todas las pruebas y la asignación de
recursos para este calendario se enlaza, obviamente, la agenda general del desarrollo del proyecto
Procedimientos de registro de las Pruebas◦ No es suficiente ejecutar simplemente las pruebas; los
resultados de las pruebas deben ser registrados sistemáticamente. Debe ser posible auditar el proceso de pruebas para comprobar que se ha llevado a cabo correctamente.
Requerimientos de hardware y software◦ Esta sección debería determinar las herramientas software
requeridas y la utilización estimada del hardware.
Restricciones o Limitaciones◦ En esta sección deberían anticiparse las restricciones que
afectan al proceso de pruebas como la escasez de personal.
Se trata del examen de un sistema software con el objetivo de descubrir las omisiones, anomalías y defectos.
Las inspecciones no requieren la ejecución del sistema, puede ser examinado antes de su ejecución.
Que pueden aplicarse a cualquier representación del sistema (requisitos, diseño, configuración de datos, los datos de pruebas, etc.)
Han demostrado ser una técnica eficaz para descubrir los errores del programa.
Muchos defectos pueden ser descubiertos en una sola inspección. En las pruebas, un defecto, puede enmascarar (ocultar) otros errores.
La reutilización de dominio y conocimiento de formas de programación hace probable que se detecten errores que comúnmente surgen.
También pueden considerar atributos de calidad como los estándares, portabilidad y mantenibilidad.
Inspecciones y pruebas son complementarias y no técnicas de verificación opuestas.
Ambos deben ser utilizados durante el proceso de V & V.
Las inspecciones pueden comprobar la conformidad con una especificación, pero no de conformidad con la necesidades reales del cliente.
Las inspecciones no pueden comprobar las características no funcionales, tales como rendimiento, facilidad de uso, etc
Es un proceso formal realizado por un equipo de personas
Destinado expresamente para detección de defectos (no de corrección).
Defectos pueden ser errores lógicos, anomalías en el código que podría indicar un error (por ejemplo una variable sin inicializar) o el incumplimiento de las normas.
Una especificación precisa del código a inspeccionar.
Los miembros del equipo deben estar familiarizados con las Normas de organización.
Se haya distribuido una versión compilable y actualizada del código a todos los miembros del equipo.
Preparar una lista de comprobación de errores comunes.
Debemos aceptar que la gestión de la inspección ocasiona un aumento de los costes en una fase temprana del proceso del software.
Gestionar el proceso cuidadosamente y desarrollar una cultura que proporcione apoyo cuando se detectan errores.
Vista general del sistema presentado al equipo de inspección.
Los código y los documentos asociados sondistribuido al equipo de inspección con antelación.
Se lleva a cabo la inspección y se descubren errores
Se realizan las modificaciones a los errores descubiertos.
Una nueva inspección puede ser o no ser necesaria.
Autor o propietario◦ El programador o diseñador responsable de generar el programa o
documento. Responsable de reparar los defectos descubiertos durante el proceso de inspección.
Inspector◦ Encuentra errores, omisiones e inconsistencias en los programas y
documentos. También puede identificar cuestiones más generales que están fuera del ámbito del equipo de inspección.
Lector◦ Presenta el código o documento en una reunión de inspección.
Secretario◦ Registra los resultados de la reunión de inspección.
Presidente o moderador◦ Gestiona el proceso y facilita la inspección. Realiza un informe de
los resultados del proceso para el moderador jefe.
Moderador jefe◦ Responsable de las mejoras del proceso de inspección,
actualización de las listas de comprobación, estándares de desarrollo, etc.
Lista de comprobación de errores comunes que deben utilizarse para conducir la inspección.
Listas de comprobación de error del lenguaje de programación. Varía de acuerdo con el lenguaje de programación debido a los diferentes niveles de comprobación proporcionados por el compilador del lenguaje.
Deberían ser actualizadas regularmente a medida que se encuentran nuevos tipos de defectos.
Ejemplos: Inicialización, constante de nombres, finalización de bucle, serie de límites, etc
Defectos de datos¿Se inicializan todas las variables antes de que se utilicen sus valores?
¿Tienen nombre todas las constantes?
¿El límite superior de los vectores es igual al tamaño del vector o al tamaño
21?
Si se utilizan cadenas de caracteres, ¿tienen un delimitador explícitamente
asignado?
¿Existe alguna posibilidad de que el búfer se desborde?
Defectos de controlPara cada sentencia condicional, ¿es correcta la condición?
¿Se garantiza que termina cada bucle?
¿Estan puestas correctamente entre llaves las sentencias compuestas?
En las sentencias case, ¿se tienen en cuenta todos los posibles casos?
Si se requiere una sentencia break después de cada caso en las sentencias
case, ¿se ha incluido?
Defectos de
entrada/salida¿Se utilizan todas las variables de entrada?
¿Se les asigna un valor a todas las variables de salida?
¿Pueden provocar corrupciones de datos las entradas no esperadas?
Defectos de interfaz¿Las llamadas a funciones y a métodos tienen el número correcto de
parámetros?
¿Concuerdan los tipos de parámetros reales y formales?
¿Están en el orden correcto los parámetros?
Si los componentes acceden a memoria compartida, ¿tienen el mismo
modelo de estructura de la memoria comparida?
Defectos de gestión
de almacenamientoSi una estructura enlazada se modifica, ¿se reasignan correctamente todos
los enlaces?
Si se utiliza almacenamiento dinámico, ¿se asigna correctamente el espacio
de memoria?
¿Se desasigna explícitamente el espacio de memoria cuando ya no se
necesita?
Defectos de manejo
de excepciones¿Se tienen en cuenta todas las condiciones de error posibles?
Es un proceso muy caro. Por ejemplo:
◦ 500 sentencias de código fuente por hora pueden presentarse durante la etapa de revisión general.
◦ Durante la preparación individual, pueden examinarse alrededor de 125 sentencias de código fuente por hora.
◦ Pueden inspeccionarse por hora de 90 a 125 sentencias durante la reunión de inspección.
Los analizadores son herramientas de software para procesamiento de textos fuente.
Que analizar el texto del programa y tratar de descubrir posibles errores y llevar estas condiciones a la atención del equipo de V & V.
Ellos son muy eficaces como ayuda a las inspecciones - son un complemento pero no un sustituto de las inspecciones.
Análisis de flujo de control. Identifica y resalta bucles con múltiples salidas o punto s de entrada y código no alcanzable.
Análisis de uso de los datos. Revela cómo se utilizan las variables del programa. Detecta variables que se utilizan sin inicialización previa, variables que se asignan dos veces y no se utilizan entre asignaciones, y variables que se declaran pero nunca se utilizan. Descubre pruebas inútiles cuando la condición de prueba es redundante. Las condiciones redundantes son condiciones que son siempre ciertas o siempre falsas.
Análisis de Interfaces. Comprueba la consistencia de las declaraciones de funciones y procedimientos y su utilización. En lenguajes débilmente tipados, este análisis puede detectar errores de tipos, funciones y procedimientos que se declaran y nunca son llamados o resultados de funciones que nunca se utilizan.
Análisis del flujo de información. Identifica lasDependencias entre las variables de entradas y salida.
Análisis de caminos. Identifica todos los posibles caminos en el programa y muestra las sentencias ejecutadas en dicho camino.
Estas dos últimas etapas generan grandes cantidades de información. Deben utilizarse con cuidado.
Especialmente valioso cuando el lenguaje que se ha utilizado para escribir el programa no tiene un compilador fuerte y, por tanto, no son muchos los errores detectados por el compilador,
Menos rentable para lenguajes que tienen un tipo fuerte de control y por lo tanto pueden detectar muchos errores durante la compilación.
Los métodos formales de desarrollo de software se basan en representaciones matemáticas del software, normalmente como una especificación formal.
Se trata de la última verificación técnica estática.
Se trata de un análisis matemático detallado de la especificación formal y pueden desarrollar los argumentos de que un programa se ajusta a sus especificaciones matemáticas.
Requieren notaciones especializadas que no puede ser entendido por los expertos de dominio.
Muy caro para elaborar un pliego de condiciones y aún más costoso para demostrar que un programa que cumple con la especificación.
Puede ser posible alcanzar el mismo nivel de confianza en un programa más barato utilizar otras técnicas de V & V.
El nombre se deriva del proceso de fabricación de semiconductores. La Filosofía es Evitar defectos en lugar de Eliminar defectos.
Este proceso de desarrollo de software se basa en:◦ Desarrollo incremental;
◦ Especificación formal;
◦ Programación Estructurada;
◦ Pruebas Estadística del sistema para determinar la fiabilidad del programa.
Los resultados de utilizar el proceso de sala limpia han sido muy impresionante, con algunos fallos descubiertos en los sistemas de entrega.
El proceso no es más caro que otros enfoques.
Hubo menos errores que en un proceso de desarrollo "tradicional".
Sin embargo, el proceso no es muy utilizado. No está claro cómo este enfoque se puede transferira un ambiente con ingenieros de software menos calificados o menos motivados.
Pruebas de los componentes◦ Pruebas de cada uno de los componentes del programa;
◦ Por lo general, la responsabilidad del desarrollador de componentes (excepto a veces para los sistemas críticos);
◦ Las pruebas se derivan de la experiencia del desarrollador.
Pruebas de Sistema ◦ Pruebas de grupos de componentes integrados para crear
un sistema o subsistema;
◦ La responsabilidad es de un equipo de pruebas independientes;
◦ Las pruebas se basan en un sistema de especificación.
El objetivo de las pruebas defecto es descubrir defectos en los programas
El éxito de una prueba defecto es una prueba que causa que un programa se comporte de una manera anómala
Las pruebas no muestran la ausencia de defectos
Pruebas de validación◦ Para demostrar al desarrollador y al cliente que el software
cumple con sus requisitos;
◦ Muestra que el sistema funciona según lo previsto.
Descubrir Defectos◦ Para descubrir los vicios o defectos en el software
◦ Para descubrir que su comportamiento es correcto o no en conformidad con las especificaciones del mismo;
◦ Muestra que el sistema realiza correctamente o expone un defecto en el sistema.
Pruebas exhaustivas sólo pueden mostrar que un programa está libre de defectos. Sin embargo, la prueba exhaustiva es imposible.
Políticas de pruebas definen el enfoque que se utilizará en la selección de pruebas de sistema:◦ Todas las funciones a través de los menús de acceso deben
someterse a prueba;
◦ Combinaciones de las funciones accesibles a través del mismo menú que se han de analizar;
◦ Cuando la entrada del usuario es necesario, todas las funciones deben ser probado con la entrada correcta e incorrecta.
Prueba de Sistema
Prueba de Integración
Prueba de Entrega
Pruebas de Rendimiento
Pruebas de Estrés
Prueba de Componente
Prueba de Interface
Implica la integración de componentes para crear un sistema o subsistema.
Puede implicar un incremento de las pruebas que se entrega al cliente.
Dos fases:◦ Pruebas de Integración - la prueba de equipo tiene
acceso al código fuente del sistema. El sistema está probado como componentes integrados. Se ocupan principalmente de encontrar defectos en el sistema.
◦ Pruebas de Entregas - la prueba del sistema completo a ser entregado al cliente. Normalmente pruebas de cajas negras.
Involucra la construcción de un sistema a partir de sus componentes y las pruebas para los problemas que surgen de las interacciones de componentes.
Integración Descendente (De arriba abajo)◦ Desarrollar el esqueleto del sistema y poblar estos
con los componentes.
Integración Ascendente (de abajo hacia arriba)◦ Integrar los componentes de la infraestructura a
continuación, agregue los componentes funcionales.
Para simplificar la localización de errores, los sistemas deben ser cada vez más integrado.
Validación de arquitectura◦ De arriba abajo la prueba de integración es mejor en
descubrir los errores en la arquitectura del sistema.
Sistema de demostración◦ De arriba hacia abajo la integración permite un número
limitado de pruebas de demostración en una fase temprana en el desarrollo.
Prueba de ejecución◦ Suelen ser más fáciles las pruebas con la integración de
abajo hacia arriba
Prueba de regresión◦ Cuando se integra un nuevo incremento, es importante
volver a ejecutar las pruebas para incrementos probados.◦ Proceso caro .
El proceso de pruebas de la liberación de un sistema que se distribuirá a los clientes.
Objetivo principal es aumentar la confianza del proveedor de que el sistema cumple con sus requisitos.
Suele ser caja negra o pruebas funcionales◦ Basado en la especificación del sistema único;◦ Los testers no tienen conocimiento de la aplicación
del sistema.
Implica la prueba de propiedades emergentes de un sistema, tales como el rendimiento y la fiabilidad.
la planificación de una serie de pruebas donde se aumentó la carga constantemente hasta que el rendimiento del sistema se convierte en inaceptable.
Ejerce el sistema más allá de su máxima carga.
Destacando la falta de prueba de comportamiento del sistema.
El Sistemas no debe fallar catastróficamente. Es inaceptable la pérdida de datos o servicio.
Es de especial interés para los sistemas distribuidos
Componente o unidad de pruebas es el proceso de pruebas de componentes individuales de forma aislada.
Se trata de un defecto del proceso de pruebas.
Componentes pueden ser:
◦ Individuales dentro de las funciones o métodos de un objeto;
◦ Clases de objetos con varios atributos y métodos;
◦ Compuesto de componentes con interfaces definidas utiliza para acceder a su funcionalidad.
Los objetivos son detectar fallas debido a la interfaz de errores o no válidos los supuestos sobre las interfaces.
Particularmente importante para el desarrollo orientado a objetos como los objetos se definen por sus interfaces.
Parámetro interfaces◦ Los datos transmitidos de un procedimiento a otro.
Interfaces de memoria compartida◦ Bloque de memoria se comparte entre los procedimientos o
funciones.
Interfaces de procedimiento◦ Sub-sistema engloba una serie de procedimientos para ser
llamado por otros subsistemas.
Mensaje pasando interfaces◦ Sub-sistemas de solicitud de servicios de otros sub-
system.s
Uso indebido de la interfaz◦ Un componente de las llamadas pidiendo otro componente
realiza un error en el uso de su interfaz por ejemplo, parámetros en el orden equivocado.
Interfaz malentendida◦ Una llamada a componente incluye supuestos sobre el
comportamiento de los llamados componentes que son incorrectos.
Errores de calendario◦ El llamado y la convocatoria de componentes funcionan a
distintas velocidades y fuera de la fecha la información se accede.
Diseño de pruebas a fin de que los parámetros de llamada a un procedimiento en el extremo final de sus gamas.
Siempre pruebe los parámetros de puntero nulo con punteros.
Diseño de pruebas que causan el componente falle.
Usar pruebas de tensión en sistemas de paso de mensajes.
En los sistemas de memoria compartida, variar el orden en que los componentes son activados.
Métodos de caja Negra
Métodos de caja Blanca
Caja Negra:◦ Basada en la definición de requerimientos o una
descripción funcional de la aplicación bajo prueba.
◦ Las pruebas se conducen a nivel de la interfaz, sin mayor interés por los detalles internos de estructura lógica.
◦ Interesa “el qué” realiza el programa, no “el cómo”. El énfasis está en el control de las salidas teniendo en cuenta las entradas.
Pruebas indirectas son las directrices que ayudan a elegir las pruebas que ponen de manifiesto defectos en el sistema◦ Elegir entradas que fuercen al sistema a generar
todos los mensajes de error;◦ Diseño de las entradas que causan
desbordamiento de buffers;◦ Repetir la misma serie de entrada o series de
entrada en varias ocasiones;◦ Forzar que se generen salidas invalidas◦ Forzar los resultados de los cálculos para que
sean demasiados grandes o demasiados pequeños.
Caja Blanca:◦ También llamadas herramientas estructurales
◦ Basadas en un conocimiento del código, especificaciones u otras fuentes de material.
◦ Pretende un examen en detalle de los procedimientos internos ejecutando cambios lógicos con condiciones o loops específicos.
Los atributos del testing de caja blanca y del testing de caja negra se deben combinar para proveer un enfoque que valide la interfaz y selectivamente asegure que los aspectos internos son los correctos.
Cada técnica es ciega con respecto a algunos tipos de errores.
Es necesario usar una combinación de técnicas para prevenir y encontrar errores.
Casos de uso puede ser una base para obtener las pruebas de un sistema. Ayudan a identificar las operaciones de la prueba y ayudar a diseñar los casos de prueba.
Secuencia de diagrama, las entradas y salidas que se creará para realizar las pruebas que pueden ser identificados.
Cobertura completa de los ensayos de una clase implica◦ Pruebas de todas las operaciones relacionadas con
un objeto;
◦ Ajuste y el interrogatorio de todos los atributos de los objetos;
◦ El objeto en el ejercicio de todos los posibles estados.
Herencia hace más difícil el diseño de pruebas de clase de objeto ya que la información de la prueba no es localizado.
Implica el diseño de los casos de prueba (entradas y salidas) que se utiliza para probar el sistema.
El objetivo de la prueba de diseño es crear un conjunto de pruebas que son eficaces en la validación y el defecto de la prueba.
Enfoques de diseño:◦ Requisitos basados en pruebas;◦ Partición de pruebas;◦ Pruebas estructurales.
Un principio general de ingeniería de requisitos es que los requisitos deben ser comprobables.
Requisitos basados en las pruebas de validación de pruebas es una técnica en la que considera que cada requisito y obtener un conjunto de pruebas de ese requisito.
Los siguientes métodos son comúnmente utilizados en testing de caja negra:
◦ Particionamiento de equivalencias
◦ Análisis de valores frontera
◦ Adivinanza de defectos
Datos de entrada y salida de los resultados a menudo se dividen en diferentes clases, donde todos los miembros de una clase están relacionados.
Cada una de estas clases de equivalencia es una partición de dominio o cuando el programa se comporta de forma equivalente para cada miembro de la clase.
Casos de prueba deben ser elegidos en cada partición.
Es una variante del particionamiento de equivalencias que, en vez de seleccionar cualquier elemento como representativo de una clase de equivalencia, se seleccionan los bordes de una clase
Además, se definen clases de equivalencias de salida, no sólo de entrada como en el caso anterior.
Ejemplo: número entre 3 y 8, probar para 2, 3, 8 y 9.
Enfoque ad hoc, basado en intuición y experiencia, para identificar pruebas que probablemente expondrán defectos.
Idea básica: lista de defectos posibles o situaciones propensas a error, desarrollo de pruebas basadas en una lista.
Historias de los defectos pueden ser muy útiles
Por ejemplo: caracteres blancos o nulos en strings; número negativos
Llamadas tambien pruebas de caja blanca.
Derivación de casos de prueba de acuerdo con la estructura de programas.
Conocimiento de que el programa se utiliza para identificar casos de prueba adicionales.
Objetivo es ejercer la totalidad de las declaraciones del programa (no todas las combinaciones de camino).
El objetivo de la prueba de caminos es garantizar que el conjunto de casos de prueba es tal que cada camino a través del programa se ejecuta al menos una vez.
El punto de partida para la prueba de camino es un programa de pruebas de flujo gráfico que muestra los nodos que representan a las decisiones del programa y arcos que representan el flujo de control.
Estados con condiciones, por lo tanto, son los nodos en el gráfico de flujo.
1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 14
1, 2, 3, 4, 5, 14
1, 2, 3, 4, 5, 6, 7, 11, 12, 5,
1, 2, 3, 4, 6, 7, 2, 11, 13, 5
Casos de prueba deben ser derivados a fin de que todos estos caminos se ejecutan
Un programa dinámico analizador se puede utilizar para comprobar que los caminos han sido ejecutados
Código Grafo (flow graph)
◦ Posibilidad de caminos/rutas de ejecución
Caminos básicos (CB) basis path
◦ Pasan por todo el código
◦ Son caminos independientes
◦ Ayudan a definir el número de pruebas
# CB = cantidad mínima de pruebas
1. Dibujar grafo
2. Calcular cantidad de caminos básicos
3. Encontrar caminos básicos
4. Diseñar como mínimo un caso de prueba para
cada camino básico
Ciclo (while, for)
Ciclo (until)
Decisión Sencilla (if)
Decisión Múltiple (case)
Secuencia
= Nodo Predicado Arcos =
1
2,3
6 4,5
7 8
9
1011
Grafo
1
2
3
6
5
4
7 8
9
10
11
R1
R2
R3
R = Regiones
R4
Complejidad Ciclomática (CC)◦ Basada en teoría de gráficas
◦ En el proceso de pruebas, ayuda a calcular el número de caminos independientes
◦ Métrica de la complejidad lógica de una rutina
V (G) marca el límite mínimo de casos de prueba para un programa.
Cuando V (G) >10 la probabilidad de defectos en el módulo o programa crece mucho entonces quizás sea interesante dividir el módulo.
Complejidad Ciclomática (CC)
CC = #Regiones
CC = #Arcos – #Nodos + 2
CC = #NodosPredicado + 1◦ Sólo si el código es:
Estructurado y
Sin decisiones múltiples
Thomas McCabe, establece en sus trabajos los siguientes valores de referencia:
◦ <= 10, métodos sencillos, sin mucho riesgo.
◦ > 10, <= 20, métodos medianamente complejos, con riesgo moderado.
◦ > 20, <= 50, métodos complejos, con alto riesgo.
◦ > 50, métodos inestables, de altísimo riesgo
La complejidad ciclomática puede ser aplicada en varias áreas incluyendo:
Análisis de riesgo en desarrollo de código: Mientras el código está en desarrollo, su complejidad puede ser medida para estimar el riesgo inherente.
Análisis de riesgo de cambio durante la fase de mantenimiento: La complejidad del código tiende a incrementarse a medida que es mantenido durante el tiempo. Midiendo la complejidad antes y después de un cambio propuesto, puede ayudar a decidir cómo minimizar el riesgo del cambio.
Planificación de Pruebas: El análisis matemático ha demostrado que la complejidad ciclomática indica el número exacto de casos de prueba necesarios para probar cada punto de decisión en un programa.
Reingeniería: Provee conocimiento de la estructura del código operacional de un sistema. El riesgo involucrado en la reingeniería de una pieza de código está relacionado con su complejidad.
Import java.io.*;
Public class Maximo
{
public static void main (String args[]) throws IOException
{
BufferedReader entrada = new BufferedReader (new InputStreamReader(System.in));
Int x,y,z,max;
System.out.println(“Introduce x,y,z: ”);
x = Integer.parseInt (entrada.readLine());
y = Integer.parseInt (entrada.readLine());
z = Integer.parseInt (entrada.readLine());
if (x>y && x>z)
max = x;
else
if (z>y)
max = z;
else
max = y;
System.out.println (“El máximo es ”+ max);
}
}
1. Señalamos en el código los pasos para dibujar el grafo de flujo
Import java.io.*;
Public class Maximo
{
public static void main (String args[]) throws IOException
{
BufferedReader entrada = new BufferedReader (new
InputStreamReader(System.in));
Int x,y,z,max;
System.out.println(“Introduce x,y,z: ”);
x = Integer.parseInt (entrada.readLine());
y = Integer.parseInt (entrada.readLine());
z = Integer.parseInt (entrada.readLine());
if (x>y && x>z)
max = x;
else
if (z>y)
max = z;
else
max = y;
System.out.println (“El máximo es ”+ max);
}
}
1
2 3
4
5 6
7
8
Complejidad
Ciclomática
◦ V(G) = a – n + 2 = 10 – 8 + 2 = 4
◦ V(G) = r = 4
◦ V(G) = c + 1 = 3 + 1 = 4
Por lo tanto tendremos cuatro caminos independientes, que mirando el grafo de flujo deducimos serán los siguientes:
Camino 1 1 - 2 – 3 – 4 – 8
Camino 2 1 – 2 – 3 – 5 – 6 –8
Camino 3 1 – 2 – 5 – 6 – 8
Camino 4 1 – 2 – 5 – 7 - 8
Definir conjuntos de pruebas mínimo para alcanzar
los siguientes criterios de cobertura
Cobertura de sentencias
Se trata de ejecutar con los casos de prueba cada sentencia e instrucción al menos una vez.
En este caso con ejecutar los caminos 1, 2 y 4 nos vale:
Camino Características Caso de Prueba
x y z
Camino 1 x > y , x > z 10 3 3
Camino 2 y < x < z 5 2 10
Camino 4 x < y , z < y 5 10 5
- Caso de prueba 1 (Camino 1 ). Ejecutaremos un caso en el que x>y y x>z, como
por ejemplo x = 10, y = 3 y z = 3.
- Caso de prueba 2(Camino 2).Ejecutamos un caso en el que y<x<z, como por
ejemplo (x,y,z)=(5,2,10)
- Caso de prueba 3 (Camino 4). Ejecutamos un caso en el que x<y y z<y, como por
ejemplo (x,y,z)=(5,10,5)
Cobertura de decisiones
Escribimos los casos suficientes para que cada condición tenga al menos una
resultado verdadero y otro falso. Utilizando los mismos caminos y casos de prueba que
en la cobertura de sentencias cubriremos también en este caso la cobertura de decisiones:
Camino Características Caso de Prueba
x y z
Camino 1 x > y , x > z 10 3 3
Camino 2 y < x < z 5 2 10
Camino 4 x < y , z < y 5 10 5
Cobertura de condiciones
Se trata de escribir los casos suficientes para que
cada condición de cada decisión adopte el valor
verdadero y el falso al menos una vez. Los casos de
prueba en este caso serán los mismos que en la
cobertura de decisiones.
Cobertura de decisión /condición
Es el cumplimiento de la cobertura de condiciones y
de decisiones. Elegiremos los caminos 1,2 y 4, con
los casos de prueba vistos anteriormente.
Si tenemos decisiones multicondicionales las descompondremos en decisiones unicondicionales, ejecutando todas las combinaciones posibles de resultados.
Tenemos la decisión multicondicional x>y && x>z y la decisión unicondicional z>y. Combinándolas nos damos cuenta que para que se cumpla el criterio de condición múltiple debemos ejecutar los cuatro caminos independientes:
Camino Características Caso de Prueba
x y z
Camino 1 x > y , x > z 10 3 3
Camino 2 y < x < z 5 2 10
Camino 3 x < y < z 2 5 8
Camino 4 x < y , z < y 5 10 5
Las Pruebas es un proceso caro. Las Pruebas de laboratorio ofrecen una gama de herramientas para reducir el tiempo requerido y el total de los costes de ensayo.
Sistemas como JUnit apoyar la ejecución automática de pruebas.
La mayoría de pruebas de laboratorio son sistemas abiertos porque las pruebas son las necesidades específicas de la organización.
A veces son difíciles de integrar en el diseño y análisis cerrado laboratorio.
Dado el siguiente fragmento de programa en java:
If (a>1) and (b>5) and (c<2) then
x=x+1;
else
x= x-1;