Pruebas de software

Objetivos Discutir las distinciones entre pruebas de validación y pruebas de defectos Describir los principios del sistema y las pruebas de componentes Describir las estrategias para generar casos de prueba de sistemas Comprender las características esenciales de las herramientas utilizadas para la automatización de las pruebas.

Contenidos Pruebas de sistema Pruebas de componentes Diseño de casos de prueba Automatización de las pruebas

El proceso de pruebas Pruebas de componentes Pruebas del sistema Prueba de los componentes individuales del programa; Normalmente es responsabilidad del desarrollador de componentes (excepto a veces en sistemas críticos); Las pruebas se derivan de la experiencia del desarrollador. Pruebas del sistema Prueba de grupos de componentes integrados para crear un sistema o un subsistema; La responsabilidad es de un equipo de pruebas independiente; Las pruebas se basan en la especificación de un sistema.

Fases de pruebas Pruebas del Pruebas de componente integración Desarrollador de software Equipo de pruebas independiente

Pruebas de defectos La meta de la prueba de defectos es descubrir defectos en los programas Una prueba de defectos con éxito es aquella que causa que el programa se comporte de una manera anómala Las pruebas muestran la presencia no la ausencia de defectos

Testing process goals Pruebas de validación Pruebas de defectos Demostrar al desarrollador y el cliente del sistema que el software cumple sus requerimientos; Unas pruebas con éxito muestran que el sistema funciona como se pretendía. Pruebas de defectos Descubrir fallos o defectos in el software donde su comportamiento es incorrecto o no se ajusta a su especificación; Una prueba con éxito es aquella que hace que el sistema no rinda de forma correcta y por tanto expone un defecto en el sistema.

Proceso de pruebas del software Casos de pruebas Datos de prueba Resultados de la prueba Informe de prueba Diseñar casos de pruebas Preparar datos de prueba Ejecutar el programa con los datos de prueba Comparar resultados con los datos de prueba

Políticas de pruebas Sólo las pruebas exhaustivas pueden demostrar que un programa está libre de defectos. Sin embargo, las pruebas exhaustivas son imposibles. Las políticas de pruebas definen la aproximación que debe usarse al seleccionar las pruebas del sistema: Deberían ser probadas todas las funciones a las que se ha accedido a través de menú; Deberían comprobarse las combinaciones de funciones a las que se ha accedido a través del mismo menú; Donde se requiere la entrada del usuario, todas las funciones deben ser comprobadas con entradas correctas e incorrectas.

Pruebas del sistema Implica integrar componentes para crear un sistema o subsistema. Puede implicar probar un incremento que va a entregarse al cliente. Dos fases: Pruebas de integración- El equipo de pruebas tiene acceso al código fuente del sistema. El sistema es probado al tiempo que los componentes se integran en éste. Pruebas de entregas - El quipo de pruebas prueba el sistema completo que va a ser entregado como una «caja negra»

Pruebas de integración Implica construir un sistema desde sus componentes y probarlo para encontrar problemas que pueden surgir de las interacciones de los componentes. Integración descendente Desarrollar el esqueleto del sistema y añadir componentes. Integración ascendente Integrar los componentes de infraestructura y después añadir componentes funcionales. Para simplificar la localización de errores, los sistemas deberían ser integrados incrementalmente.

Pruebas de integración incrementales Secuencia de prueba 1 Secuencia de prueba 2 Secuencia de prueba 3

Enfoque pruebas Validación arquitectónica Demostración del sistema Las pruebas de integración descendentes son mejores para descubrir errores en la arquitectura del sistema. Demostración del sistema Las pruebas de integración descendente permiten una demostración limitada en una etapa temprana en el desarrollo. Prueba de implementación Normalmente es más fácil con pruebas de integración ascendentes. Pruebas de observación Tiene problemas con varios enfoques. Puede requerirse código extra para observar las pruebas.

Pruebas de entrega El proceso de probar la entrega de un sistema que será distribuido a los clientes La meta principal es incrementar la confianza del proveedor en que el sistema cumplirá sus requerimientos. La pruebas de entrega normalmente son pruebas de caja negra o funcionales Están basadas sólo en la especificación del sistema; Los probadores no tienen conocimientos de la implementación del sistema;

Pruebas de caja negra Entradas que provocan comportamiento anómalo Entrada de datos de prueba E e Sistema Salidas que revelan la presencia de defectos Resultados de las pruebas Se

Pauta de pruebas Las pautas de pruebas son pistas para ayudar al equipo de pruebas a elegir las pruebas que revelarán defectos en el sistema Escoger entradas que fuercen al sistema a generar todos los mensajes de error; Diseñar entradas que hacen que los búferes de entrada se desborden; Repetir la misma entrada o serie de entradas varias veces; Forzar a que se generen las salidas inválidas; Forzar los resultados de los cálculos para que sean demasiado grandes o demasiado pequeños.

Escenario de pruebas

Pruebas de sistemas

Casos de uso Los casos de uso pueden ser la base de derivar las pruebas para un sistema. Ayudan a identificar las operaciones que van a probarse y ayuda a diseñar los casos de pruebas requeridos. Desde un diagrama de secuencia asociado, pueden identificarse las entradas y salidas que deben crearse para las pruebas.

Diagrama de secuencia de recopilación de datos sobre el tiempo

Pruebas de rendimiento Parte de las pruebas de entrega puede implicar probar las propiedades emergentes de un sistema, como el rendimiento y la fiabilidad. Las pruebas de rendimiento normalmente implican planificar una serie de pruebas donde la carga se incrementa a un ritmo constante hasta que el rendimiento del sistema llega a ser inaceptable.

Pruebas de estrés Ejercita el sistema por encima de su carga máxima de diseño. Estresar el sistema a veces provoca que los defectos salgan a la luz. Estresar el sistema prueba el comportamiento de fallos. Los sistemas no deberían fallar catastróficamente. Las pruebas de estrés comprueban las pérdidas inaceptables de servicio o datos. Estresar el sistema es particularmente importante para sistemas distribuidos que pueden exhibir una degradación severa cuando una red de trabajo se sobrecarga.

Pruebas de componentes Las pruebas de componentes o pruebas de unidad son los procesos de prueba de componentes individuales aislados. Es un proceso de prueba de defectos. Los componentes pueden ser: funciones individuales o métodos dentro de un objeto; clases de objetos con varios atributos y métodos; Componentes compuestos con interfaces definidas utilizadas para acceder a su funcionalidad.

Pruebas de clases de objetos Completar la cobertura de pruebas de una clase implica Probar todas las operaciones asociadas con un objeto; establecer e interrogar todos los atributos de los objetos; Ejercitar el objeto en todos los estados posibles. La herencia hace que sea más difícil diseñar pruebas de clases de objetos ya que no se localiza la información que se va a probar.

Interfaz del objeto de la estación meteorológica W eatherStation identifier repor tW eather () calibrate (instruments) test () star tup (instruments) shutdown (instruments)

Pruebas de una estación meteorológica Necesita definir los casos de pruebas para reportWeather, calibrate, test, startup and shutdown. Utilizando un modelo de estado, identifica secuencias de transiciones de estado que se van a probar y las secuencias de estado que causan estas transiciones Por ejemplo: Waiting -> Calibrating -> Testing -> Transmitting -> Waiting

Pruebas de interfaces El objetivo es detectar fallos debidos a errores de la interfaz o suposiciones inválidas sobre las interfaces. Es particularmente importante para el desarrollo orientado a objetos ya que los objetos se definen por sus interfaces.

Pruebas de interfaces Casos de pruebas A B C

Tipos de interfaz Interfaces de parámetro Datos que pasan de un procedimiento a otro. Interfaces de memoria compartidas Se comparte un bloque de memoria entre procesos o funciones Interfaces procedurales Un subsistema encapsula un conjunto de procedimientos que pueden ser llamados por otros componentes. Interfaces de paso de mensajes Los subsistemas piden servicios de otros subsistemas.

Errores de interfaz Mal uso de la interfaz Un componente llama a otro componente y comete un error en la utilización de su interfaz. P.Ej.: parámetros en el orden incorrecto. No comprensión de la interfaz El componente que realiza la llamada hace suposiciones incorrectas sobre el comportamiento del componente llamado que. Errores temporales El objeto que llama y el llamado operan a diferentes velocidades y se accede a información no actualizada.

Pautas para la prueba de interfaces Diseñar los parámetros de forma que los parámetros para un procedimiento al que se ha llamado estén en los extremos de sus rangos Probar siempre los parámetros punteros con punteros nulos. Diseñar pruebas que provoquen el fallo del componente. Utilizar pruebas de estrés en los sistemas de paso de mensajes En sistemas de memoria compartida, variar el orden en que se activan los componentes.

Diseño de casos de pruebas Implica diseñar casos de pruebas (entradas y salidas) utilizadas para probar el sistema. La meta del diseño de casos de pruebas es crear un conjunto de pruebas que sean efectivas en las pruebas de validación y defectos. Diseñar aproximaciones: Pruebas basadas en requerimientos; Pruebas de particiones; Pruebas estructurales.

Requerimientos basados en pruebas Un principio general de la ingeniería de requerimientos es que los requerimientos deberían ser estables. Las pruebas basadas en requerimientos son técnicas de pruebas de validación donde se considera cada requerimiento y se deriva un conjunto de pruebas para ese requerimiento.

Requerimientos LIBSYS

Pruebas LIBSYS

Pruebas de particiones Los datos de entrada y los resultados de salida con frecuencia se dividen en diferentes clases en las que todos los miembros de una clase están relacionados. Cada una de estas clases es una partición de equivalencia o dominio en la que el programa se comporta de forma equivalente para cada miembro de la clase. Deberían escogerse casos de pruebas de cada partición.

Particiones de equivalencia Entradas inválidas Salidas válidas Sistema S ystem salidas

Particiones de equivalencia 3 1 1 4 7 1 Menor que 4 Entre 4 y 10 Más de 10 Número de valores de entrada 9999 1 00000 1 0000 5 0000 99999 Menor que 10.000 Entre 10000 y 99999 Más de99999 Valores de entrada

Especificación de rutina de búsqueda procedure Search (Key : ELEM ; T: SEQ of ELEM; Found : in out BOOLEAN; L: in out ELEM_INDEX) ; Pre-condition -- la secuencia tiene al menos un elemento T’FIRST <= T’LAST Post-condition -- el elemento se encuentra y es referenciado por L ( Found and T (L) = Key) or -- el elemento no está en la secuencia ( not Found and not (exists i, T’FIRST >= i <= T’LAST, T (i) = Key ))

Rutina de búsqueda– particiones de entradas Entradas que se ajustan a las precondiciones. Entradas donde una precondición no encaja. Entradas en las que el elemento clave es un miembro del vector. Entradas en las que el elemento clave no es un miembro del vector.

Pautas de pruebas (secuencias) Probar el software con secuencias que tienen un único valor. Utilizar secuencias de diferentes tamaños en diferentes pruebas. Derivar pruebas para que se acceda a los elementos primero, intermedio y último de la secuencia. Probar con secuencias de longitud cero.

Rutina de búsqueda– particiones de entrada

Pruebas estructurales A veces también llamadas pruebas de caja blanca Derivación de casos de pruebas de acuerdo a la estructura del programa. El conocimiento del programa se utiliza para identificar casos de pruebas adicionales. El objetivo es ejercitar todas las sentencias del programa (no todas las combinaciones de caminos)

Pruebas estructurales Datos de prueba Pruebas Deriva en Código del componente Salidas de prueba

Búsqueda binaria– particiones equivalentes Precondiciones satisfechas, elemento clave en vector Precondiciones satisfechas, elemento clave no está en vector Precondiciones insatisfechas, elemento clave en vector. Precondiciones insatisfechas, elemento clave no está en vector. Vector de entrada tiene un único valor. Vector de entrada tiene un número par de valores. Vector que tiene un número impar de valores.

Particiones equivalentes de búsqueda binaria Límites de la clase de equivalencia v Elementos < Mid Elementos > Mid Punto medio

Búsqueda binaria– casos de pruebas

Prueba de caminos El objetivo de las pruebas de caminos es asegurar que el conjunto de casos de pruebas es tal que cada camino es ejecutado a través del programa al menos una vez. El punto de comienzo para la prueba de caminos es un gráfico de flujo del programa que muestra los nódulos que representan las decisiones del programa y arcos que representan el flujo de control. Las sentencias con condiciones son, por lo tanto, nódulos en el gráfico de flujo.

Gráfico de flujo para búsqueda binaria

Caminos independientes 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, … Los casos de pruebas deberían derivarse para que todos estos caminos se ejecuten Puede usarse un analizador dinámico del programa para comprobar los caminos que han sido ejecutados

Automatización de las pruebas Probar es una fase del proceso cara. Probar bancos de trabajo proporciona cierta variedad de herramientas para reducir el tiempo necesario y los costes totales de las pruebas. Sistemas como Junit soportan la ejecución automática de pruebas. La mayoría de los bancos de trabajo son sistemas abiertos porque las necesidades de pruebas son específicas de la organización. A veces es difícil integrar con un diseño cerrado y bancos de trabajo.

Un banco de trabajos de pruebas Generador De datos de prueba Especificación Código fuente Administrador de pruebas Datos de prueba Oráculo Analizador dinámico Programa en prueba Resultado de la prueba Predicciones de pruebas Informe de ejecución Comparador de archivos Simulador Informe de los resultados de la prueba Generador de informes

Adaptación de bancos de trabajo de pruebas Se pueden desarrollar scripts para los simuladores de interfaz del usuario y patrones para los generadores de datos de pruebas. Las salidas de pruebas pueden tener que estar preparadas manualmente para su comparación. Podrían desarrollarse comparadores de archivos para un propósito especial.

Puntos clave Las pruebas pueden demostrar la presencia de fallos en un sistema; no puede probar que no quedan fallos. Los desarrolladores de un componente son responsables de las pruebas del componente; Las pruebas del sistema son responsabilidad de un equipo aparte. La integración de pruebas es comprobar los incrementos del sistema; las pruebas a entregar implican probar que un sistema que va a ser entregado a un cliente. Utilizar la experiencia y las pautas para diseñar casos de pruebas en pruebas de defectos.

Puntos clave Las pruebas de interfaz están diseñadas para descubrir defectos en las interfaces de componentes compuestos. La partición de equivalencia es una forma de descubrir casos de pruebas : todos los casos en una partición deberían comportarse del mismo modo. El análisis estructural depende del análisis de un programa y las pruebas de derivación del análisis. La automatización de pruebas reduce los costes de pruebas apoyando los procesos de pruebas con varias herramientas de software