Tema 3. Diseño y realización de las pruebas.pdf

Diseño y realización de las pruebas Tema 3 Diseño y realización de las pruebas 0  Diseño y realización de las pruebas...

Diseño y realización de las pruebas Tema 3 Diseño y realización de las pruebas 0  Diseño y realización de las pruebas Las características del software convierten la tarea de su comprobación en algo mucho más difícil que, por ejemplo, probar un producto industrial de tipo mecánico, entre otras razones por la elevada posibilidad de que se den fallos humanos. De este modo, la producción de software ha de ir unida a una actividad que garantice la calidad, debido a que desde el comienzo del proceso pueden aparecer los errores en forma de objetivos especificados de forma errónea o La fase de pruebas es, en los modelos en cascada, la penúltima imperfecta, a lo que se unen los errores en la fase de diseño fase de desarrollo de software. y posteriormente de desarrollo. La calidad del software es un parámetro fundamental que permite obtener una idea sobre su adecuación a los fines para los que ha sido construido. Para ello, es imprescindible implementar un proceso de pruebas cuyo coste es elevado pero muy inferior al de un único fallo no detectado. La prueba del software es un elemento crítico para la garantía de la calidad del software, que permite revisar las especificaciones del mismo, el diseño y la implementación. Puede llegar a consumir más de la mitad del tiempo total de desarrollo. Por ello se investiga en métodos que reduzcan el esfuerzo necesario para realizar unas buenas pruebas. En cuanto a métodos de pruebas de software, hay tres tipos fundamentales: Las técnicas de desarrollo de Métodos estáticos: Analizan el código fuente de la software como Agile o SCRUM aplicación para localizar errores insertan el proceso de pruebas en todas las fases de desarrollo para Métodos dinámicos: Requieren que se ejecute el código agilizar la puesta en producción del objeto programa. Métodos formales: Prueban la corrección de algoritmos 21  Diseño y realización de las pruebas Las pruebas permiten llevar a cabo las siguientes tareas que verifican el nivel de calidad del mismo: Verificación: proceso de evaluación de un sistema o de uno de sus componentes para determinar si los productos de una fase dada satisfacen las condiciones impuestas al comienzo de dicha fase. Mediante la verificación es posible comprobar si el producto software se está construyendo correctamente Validación: es el proceso de evaluación de un sistema o de uno de sus componentes durante o al final del proceso de desarrollo para determinar si satisface los requisitos especificados. Permite contrastar si el producto software que se está construyendo corresponde a las necesidades que en su momento se detectaron, es decir, si es el producto adecuado El aseguramiento de la calidad del software (SQA) va más allá del diseño y ejecución de un conjunto de pruebas y comienza ya cuando se inician los trabajos de planificación estratégica El estandar ISO /IEC 9126 establecía de los sistemas de información. los criterios para garantizar la calidad del software. Fue sustituido Durante el análisis y desarrollo, los métodos de ingeniería del en 2011 por ISO / IEC 25010 software para análisis y diseño, codificación e implantación, proporcionan la base a partir de la cual se construye la calidad al proporcionar técnicas uniformes y resultados predecibles. Otro elemento importante son las revisiones técnicas formales que ayudan a asegurar la calidad de los productos de cada etapa de la ingeniería del software. También, a lo largo de todo el desarrollo se suceden las actividades de medición y control. La prueba constituye el último elemento que se ha de aplicar en el proceso de aseguramiento de la calidad que se Características y subcaracteristicas incorpora en las diferentes etapas de desarrollo del software, de calidad proporcionadas en el estándar ISO / IEC 25010 y permite confirmar la ausencia o presencia de la misma. 22  Diseño y realización de las pruebas Métrica 3 La métrica 3 ha sido desarrollada por Informatica El Corte Ingles a requerimiento del Consejo Superior de Informática del Ministerio de Administraciones Públicas Las estrategias de pruebas que se emplean están relacionadas con el modelo de desarrollo de software Esta basado en la métrica 2.1 y contempla los ultimos metodos y estandares como son: basado en prototipado. Metodologías de ingenieria del software Merise, SSADM V.4 y los metodos USA de Hoy en día se emplean para el desarrollo de aplicaciones las Ingenieria de la información. herramientas RAD, mediante un proceso denominado Los principales estandares de ingenieria y modelo en espiral que consiste en refinar el código en cada calidad del software tales como IEEE (Standares 610.12-1990 y 1074), ISO (normas una de las fases de las que consta la técnica, realizando un 12207 y 9000-3) y ISO/IEC TR 15504 (SPICE). análisis crítico para ver si se sigue con el desarrollo pasando a Métrica 3 cubre tanto desarrollos estructurados niveles de mayor detalle o bien se abandona por motivos como desarrollos orientados a objetos. Sus creadores afirman haber integrado las técnicos o económicos. actividades exclusivas de la orientación a objetos dentro de la estructura de Métrica V3, definiendo asi una metodología mixta. Cada vuelta de la espiral es una fase del ciclo estructurado u orientado a objetos, siendo el producto de cada fase un prototipo realizado con herramientas de cuarta generación, con un nivel de abstracción menor que el de la fase Estándares para la documentación inmediatamente anterior y de cuyo análisis surgen los de pruebas esquemas que permiten el desarrollo de la siguiente fase. La documentación de las pruebas es un requisito indispensable para su correcta La estrategia para la prueba de software también se puede realización. ubicar sobre esta espiral pero con un sentido de giro inverso Unas pruebas bien documentadas podran al de la ingeniería. tambien servir como base de conocimiento para futuras tareas de comprobación. Las metodologías como Métrica 3, proponen un desarrollo documental de las fases de pruebas basado en los estandares ANSI/IEEE sobre verificación y validación del software. De estas normas cabe destacar las siguientes: IEEE/ANSI 1012-1998: Estandar para verificación y validación de software Comienza con la definición de un plan de pruebas de IEEE/ANSI 730-1998: Estandar para planes de sistemas de información y no termina hasta que se realizan las aseguramiento de la calidad en el software. últimas pruebas en la fase de implantación y aceptación del IEEE/ANSI 1028/1997: Estandar para revisiones y auditorias del software sistema. IEEE/ANSI 829-1998: Estandar para documentación de pruebas de software De acuerdo con Métrica 3, “el plan de pruebas es un IEEE/ANSI 1008-1987(R1993): Estandar para producto formal que define los objetivos de la prueba de un pruebas de unidades de software sistema , establece y coordina una estrategia de trabajo, y IEEE/ANSI 610.12-1990: Glosario estandar para provee del marco adecuado para establecer una terminos de ingenieria del software. planificación paso a paso de las actividades de prueba. La mas centrada en definir los estandares aplicables a la documentación de pruebas de software es el 829. El plan se inicia en el proceso Análisis del Sistema de Información, definiendo el marco general y estableciendo los requisitos de prueba de aceptación, relacionados directamente con la especificación de requisitos. Dicho plan 23  Diseño y realización de las pruebas se ira completando y detallando a medida que se avanza en los restantes procesos del ciclo de vida del software. Diseño del Sistema de Información, Construcción del Sistema de Información e Implantación y Aceptación del Sistema. Se plantean los siguientes niveles de prueba: pruebas unitarias, pruebas de integración, pruebas del sistema, pruebas de implantación y pruebas de aceptación.” Ciclo de pruebas del software Se considera que el ciclo de prueba comienza con la generación de un plan de pruebas, tarea para la cual es preciso contar con información en detalle sobre el proyecto y sobre el software que se está desarrollando. Esta información ha de componerse en: Descripción del entorno tecnológico al que va destinado el sistema Catálogo de normas y requisitos Especificación del interfaz de usuario Modelo de procesos o de casos de uso Modelo lógico de datos o de clases. Plan de pruebas de software Con la información disponible y el plan de pruebas se entra en detalle diseñando las pruebas específicas, lo que significa determinar el diseño, los casos y procedimientos de prueba así como la versión del software sobre la que se han de aplicar. Se ejecutan las pruebas sobre la versión del software adecuada. En caso de que se trate de nuevas pruebas sobre 24  Diseño y realización de las pruebas software ya probado se tendrá en cuenta el resultado de las pruebas anteriores. Se evalúan los resultados, para lo cual se comparan con las salidas previstas. En caso de que así se determine se procede a la depuración de errores y corrección de defectos. Otra opción puede ser efectuar nuevas pruebas para obtener más información sobre errores que se han detectado pero cuyo origen no se ha podido determinar. Tras el proceso de corrección será preciso probar de nuevo el software. Si se encuentran muchos errores graves que requieren modificaciones en el diseño, calidad y fiabilidad del software quedaran en entredicho y solo podrá rubricarse tras un nuevo ciclo de pruebas posterior a la corrección de los defectos. Si la prueba no detecta errores significativos se pueden Niveles de pruebas plantear las siguientes hipótesis: Las pruebas son inadecuadas para descubrir errores serios La calidad y la fiabilidad del software son aceptables Cualquier error que no haya sido descubierto en la fase de pruebas será eventualmente descubierto por los usuarios y corregido. Comienzan en el vórtice de la espiral y se ocupan por separado de cada unidad del software, tal como está implementada en el código fuente. Las pruebas progresan hacia fuera de la espiral, hasta llegar a la prueba de NUnit es una herramienta para integración. implementar pruebas unitarias sobre módulos de proyectos en.NET Las pruebas de unidad verifican la funcionalidad y estructura -usa C#- de cada componente individual del software una vez que ya ha sido codificado y se emplearán en el diseño técnicas de caja blanca -aunque a veces se combinara con técnicas de caja negra- debido a que el tamaño del componente sea suficientemente pequeño como para ser examinado según esta técnica y porque el tipo de defectos buscado en una 25  Diseño y realización de las pruebas prueba de caja blanca coincide exactamente con el nivel de especificación propio de la lógica detallada en los componentes. Los pasos necesarios para llevar a cabo las pruebas de unidad son los siguientes: Ejecutar todos los casos de prueba asociados a cada verificación establecida en el plan de pruebas, registrando JUnit es una herramienta para el resultado. generar pruebas unitarias sobre los diferentes módulos de un proyecto Corregir los errores o defectos encontrados y repetir las Java. pruebas que los detectaron, u otras distintas, si se considera necesario, debido a su importancia. En las pruebas de unidad se verifican el interfaz las estructuras de datos locales, las condiciones límite, todos los caminos independientes de la estructura de control y todos los caminos que llevan a errores. En las pruebas de integración se presta especial atención al diseño y construcción de la arquitectura del software. Su finalidad es verificar el correcto ensamblaje entre los distintos componentes del software que ya han sido probados unitariamente. Con este objetivo se comprobará que la interactuación entre los componentes a través de sus interfaces, tanto internas como externas, es adecuada, que cubren la funcionalidad establecida y que se ajustan a los requisitos no funcionales especificados en las verificaciones correspondientes. Para probar unitariamente componentes reutilizables, es preciso crear módulos auxiliares que simulen las acciones de los componentes que se desea probar, así como Integración ascendente. Se componentes conductores del flujo de control, encargados prueban los componentes inferiores de establecer las precondiciones necesarias, llamar al y una vez probados se prueban los superiores que están compuestos componente objeto de la prueba y examinar los resultados por ellos. de dicha prueba. Estos módulos auxiliares funcionan como nexo integrador de los componentes individuales que han de ser probados. De este modo, es evidente que si en lugar de probar directamente los componentes individuales, se aguarda a que el nivel inmediatamente superior esté terminado, se podrán utilizar los componentes de este nivel tanto para las 26  Diseño y realización de las pruebas pruebas individuales como las de integración del nivel inferior. Es por esto por lo que se combinan las pruebas unitarias y las de integración. Tenemos cinco tipos de pruebas de integración: Integración súbita: Consiste en esperar demasiados niveles para empezar las pruebas individuales o de integración de los niveles inferiores. El riesgo en este caso es que no sirva Integración descendente. Primero nada de lo hecho y haya que volver a empezar. se prueba el main() de la clase Principal, empleando objetos de Integración gradual: Los componentes objeto de la ejemplo, sin contenido, y prueba van siendo paulatinamente añadidos al conjunto posteriormente se crean los objetos restantes y se van añadiendo a la de componentes que ya están probados. De este modo prueba. se va incrementando progresivamente el número de componentes que se prueba conjuntamente. Integración ascendente (bottom-up): Es aquella en la que se crean primero los componentes de más bajo nivel del árbol de estructura elaborándose componentes auxiliares y conductores para simular a los componentes que los llaman. Una vez probado el nivel inferior se elabora - o se refina en caso de que se tengan ya los prototipos- el nivel Pruebas de regresión superior, se integra con el inferior o ya probado y se elaboran los componentes invocantes del nivel superior y Son complementarias a las de integración. Se emplean cada vez que se produce un los conductores necesarios probándose el conjunto. cambio en el sistema, tanto para corregir un error como para realizar una mejora. Integración descendente (top-down): El primer Se prueban no solo los componentes modificados o añadidos sino que hay que componente que se desarrolla y prueba es el primero de comprobar que las modificaciones no la jerarquía. Los componentes de nivel más bajo se produzcan efectos colaterales negativos sobre el mismo u otros componentes. sustituyen por componentes auxiliares para simular a los Una técnica utilizada en el proceso de componentes invocados. En este caso no son necesarios integración es la revisión del producto componentes conductores. Es conveniente para detectar intermedio. Hay dos técnicas de revisión errores del tipo de estructuras de control inadecuadas, Revisión formal: Detecta y registra los defectos de un producto intermedio aunque a veces para llevar a cabo la prueba de unidad verificando, a través de un procedimiento de un módulo de nivel superior es estrictamente necesaria de auditoría, que el producto satisface sus especificaciones y se ajusta a los la existencia de uno de nivel inferior. estándares establecidos. Revisión técnica: Tiene como objetivo Estrategias combinadas: Se combina la integración evaluar un producto intermedio del ascendente con la descendente. Tanto los S.O., que desarrollo para comprobar que se ajusta a sus especificaciones y que se está incorporan muchas funciones de alto nivel, como por otro elaborando de acuerdo a las normas, estándares y guías aplicables al proyecto lado los desarrolladores independientes que crean continuamente componentes listos para usar, que incorporan funciones de bajo y medio nivel, permiten que estos elementos no necesiten ser probados y puedan utilizarse como módulos de nivel inferior sea cual sea el método de integración elegido, 27  Diseño y realización de las pruebas Por otro lado los componentes más críticos en el nivel más bajo se seguirán desarrollando siguiendo un enfoque ascendente. En las pruebas de validación se comprueba que el sistema construido cumple con lo establecido en el análisis de requisitos del software. La validación del sistema se consigue mediante la realización de pruebas de caja negra que demuestran la conformidad con los requisitos y que se recogen en el plan de pruebas, el cual define las verificaciones que se han de realizar y los casos de prueba asociados. Las pruebas serán más o menos formales en función de cada organización y dependerá principalmente de la importancia del sistema. Hay dos tipos de pruebas a aplicar: Pruebas alfa: Prueba de aceptación que realiza el usuario Las pruebas alfa y beta se siguen de final del sistema. Es efectuada por el cliente en el lugar de manera continuada hasta llegar a la fase de producción. desarrollo. Se trata de un entorno controlado, en el que los componentes del equipo estarán vigilando continuamente la actividad del usuario y registrando errores y problemas de uso Pruebas beta: También se lleva a cabo por los usuarios finales de los productos, en gran número y en el lugar de trabajo habitual y sin la presencia del equipo de desarrollo. Se registrarán todos los problemas que hayan surgido y se informa al equipo de desarrollo que lleva a cabo las modificaciones necesarias y prepara una prueba del producto del software para toda la base de clientes. Por otro lado A continuación se llevan a cabo las pruebas del sistema en las que se verifica el funcionamiento total del software y otros elementos del sistema, comprobando su integración como un todo y verificando el funcionamiento correcto de las interfaces entre los distintos subsistemas que lo componen y con el resto de sistemas de información con los que se comunica. Entre los principales tipos de pruebas del sistema se encuentran las siguientes: 28  Diseño y realización de las pruebas Pruebas de interfaz Pruebas de recuperación Pruebas de ergonomía Pruebas de funcionalidad Pruebas de rendimiento Pruebas de seguridad Pruebas de volumen y sobrecarga Verificaciones que se llevan a cabo para asegurar que el sistema funcionara correctamente en el entorno de operación final, respondiendo satisfactoriamente a los mismos requisitos cuyo cumplimiento se ha constatado en las pruebas del sistema y asegurando su coexistencia con el resto de los sistemas de la instalación. Según el IEEE, un caso de prueba es un conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular cómo por ejemplo, ejercitar un camino concreto de un programa o verificar el cumplimiento de un determinado requisito. Sin embargo, hoy día es imposible a un coste razonable realizar todos los tipos posibles de pruebas, sobre todo en los entornos interactivos tipo GUI dirigidos por eventos. De ahí que las pruebas busquen un compromiso razonable entre la cantidad de recursos que se consumirán en el proceso de prueba y la probabilidad obtenida de que se detecten los defectos existentes. Existen varios enfoques para el diseño de casos de prueba Esquema de un modelo de pruebas para aplicaciones de software. de caja blanca Conociendo la implementación interna del producto se pueden desarrollar pruebas que comprueben que la operación interna se ajusta a las especificaciones. 29  Diseño y realización de las pruebas En este caso la prueba ideal será aquella que compruebe todos los posibles caminos de ejecución del código. Este es el tipo de prueba al que antes se ha calificado de inviable, sin embargo, la prueba de caja blanca, aplicada en un número razonablemente reducido de lugares importantes, no se debe desechar como impracticable pues permitirá comprobar la validez de las estructuras fundamentales. Dentro de las pruebas de caja blanca podemos distinguir: Pruebas de cobertura lógica: Las pruebas de cobertura lógica se basan en unos criterios de prueba que son los siguientes: o Cobertura de sentencias: Se han de generar los casos de prueba suficientes para que cada instrucción del programa sea ejecutada al menos una vez. o Cobertura de decisiones: Se trata de crear los suficientes casos de prueba para que cada opción resultado de una prueba lógica del programa se evalúe al menos una vez a cierto y una vez a falso. o Cobertura de condiciones: Se trata de crear los suficientes casos de prueba para que cada elemento de condición de cada prueba lógica del programa se evalúe al menos una vez a cierto y a falso. Grafo de flujo de instrucciones secuenciales o Cobertura de condiciones y de decisiones: Consiste en cumplir simultáneamente los dos anteriores. o Cobertura de caminos: Es el criterio más elevado, que establece que se debe ejecutar al menos una vez cada secuencia de sentencias encadenadas desde la sentencia inicial del programa hasta su sentencia final, secuencias a las que se conoce como camino. Dado que el número de caminos puede hacer esta opción impracticable, incluso para programas pequeños, se puede optar por reducir este número en lo que se conoce como camino de prueba. Grafo de flujo de REPETIR….HASTA o Cobertura del camino de prueba: existen al menos dos variantes del concepto del camino de prueba 30  Diseño y realización de las pruebas ▪ Opción clásica: Cada bucle solo se debe ejecutar una vez ya que hacerlo más veces no incrementa la significatividad de la prueba. ▪ Otros autores recomiendan que se pruebe cada bucle tres veces, la primera sin entrar en su interior, otra ejecutándolo una vez y otra mas ejecutándolo dos veces. o Prueba del camino básico de Tom McCabe: Es una Grafo de flujo de SI…ENTONCES…SINO…FIN técnica de prueba de la caja blanca que permite obtener una medida de la complejidad lógica de un diseño predeterminado y usar esa medida como guía para la definición de un conjunto básico de caminos de ejecución. Los casos de prueba derivados del conjunto básico garantizan que durante la prueba se ejecutan por lo menos una vez cada sentencia de programa. Esta técnica utiliza los siguientes conceptos: ▪ Grafo de flujo: Representa de flujo de control lógico mediante una notación basada en flechas o aristas y círculos o nodos, que delimitan áreas Grafo de flujo de llamadas regiones. HACER…MIENTRAS ▪ Complejidad ciclomática: Es una métrica del software que proporciona una medición cuantitativa de la complejidad lógica de un programa. Para el método del camino básico define el número de caminos independientes del conjunto básico de un programa y da un límite superior para el numero de pruebas que se deben realizar para asegurar que se ejecuta cada sentencia al menos una vez. Se puede calcular de tres formas: V(G)=a-n+2 donde a es el número de aristas del grafo y n el de nodos; V(G)=r donde r es el número de regiones del grafo; V(G)=c+1 siendo c el número de nodos de condición. Grafo de flujo de una estructura ▪ Matriz de grafo: Representación en una matriz condicional múltiple cuadrada de los nodos y las conexiones del grafo. Sirve como técnica de apoyo que permite automatizar los cálculos que se han de realizar en la prueba del camino básico. 31  Diseño y realización de las pruebas No es más que una matriz de adyacencia del grafo dirigido de flujo de programa, a partir de la cual es posible calcular la complejidad ciclomática. Es factible representar las aristas con o sin pesos. En el caso de que estos se utilicen pueden hacer referencia a características tales como la probabilidad de ejecución de una arista al consumo de recursos que se deriva de su ejecución. En esta matriz, cada fila con dos o más entradas representa un nodo de condición, y si tiene dos o Flujograma y grafo de flujo más salidas nodo predicado. Por tanto, si se resta a asociado. cada suma de conexiones la unidad el resultado será el número de nodos de condición. La complejidad ciclomática de este ejemplo calculada con los tres Para calcular V(G) solo hace falta sumar 1. Una vez métodos vistos es: que se conocen los caminos independientes, el V(G)=2; diseñador de las pruebas analizara el código con el propósito de obtener que datos de entrada van a V(G)=2; ser necesarios para obligar a que se ejecuten todos V(G)=2; los caminos. Las conclusiones a sacar de este método son: V(G) es un límite mínimo para el número de casos de prueba necesarios para comprobar un programa. Se ha constatado empíricamente que cuando V(G) supera el valor 10 y no hay sentencias CASE en el código la probabilidad de error va a crecer muy rápidamente. Se recomienda pues, que, cuando esto ocurra se replantee el diseño modular de manera que V(G) disminuya. Ordinograma y grafo de flujo de un o Otras pruebas de la estructura de control: Otras pruebas programa que determina cuantos pares e impares hay entre los del mismo tipo que la prueba del camino básico son: números introducidos por teclado. ▪ Prueba de condiciones: Es un método de diseño de La complejidad ciclomática es casos de prueba que somete a comprobación las V(G)=3 condiciones lógicas contenidas en el modelo de un programa. V(G)=3 V(G)=3 32  Diseño y realización de las pruebas Se centra en la prueba de cada una de las Camino Caso de prueba Resultado condiciones del programa con el propósito de esperado detectar no solo los errores en estas condiciones, sino 1 Escoger un valor de Visualizar el también otros errores del programa. NUM_ELEMENTOS número de que haga que no se valores cumpla la pares e condición impares ▪ Prueba del flujo de datos: Este método selecciona 2 NUM_ELEMENTOS