Lectura M4 PDF

Preview

Summary

Lecturas PDF...

Description

WƌƵĞďĂƐĞ ŝŵƉůĞŵĞŶƚĂĐŝſŶ

^ĞŵŝŶĂƌŝŽ ĚĞƉƌĄĐƚŝĐĂ

Proceso de Pruebas En este módulo revisaremos los conceptos principales para evaluar y asegurar la calidad del sistema durante su construcción y las principales actividades de Pruebas propuestas por el Proceso Unificado de Desarrollo. En esta etapa de la materia haremos referencia a conceptos ya vistos en las materias Análisis y Diseño, Pruebas de Sistemas y Bases de Datos I. Sugerimos profundizar cada uno de los temas en la bibliografía sugerida y en el material usado en cada una de esas materias.

Podemos definir a las pruebas de sistema como cualquier actividad realizada para evaluar la calidad del producto identificando defectos y problemas, y mejorar esa calidad considerando los resultados obtenidos, también como el proceso de ejercitar el sistema para detectar errores y verificar que satisface las especificaciones de requerimientos funcionales y no funcionales. Las pruebas tienen que estar enfocadas en provocar que el software falle para detectar el defecto vigente antes que lo detecte el usuario o cliente. Cuando hablemos de fallas, hacemos referencia a un comportamiento no esperado o distinto al esperado que tiene el sistema, y cuando hablemos de defecto, estaremos indicando un desperfecto. El proceso de Verificación y Validación es el proceso que asegura que el sistema implementado: 

Produce el producto correcto (verificación).



Satisface los requerimientos funcionales y otros requerimientos (validación).

1

En materias anteriores como Análisis y Diseño de Software y Pruebas de Sistema se han visto en profundidad el tema de Verificación y Validación de Sistemas. Se recomienda revisar el material bibliográfico de dichas materias para reforzar los temas presentados en este módulo.

Niveles de Pruebas Todo proceso de prueba de software consiste en tres niveles de prueba: pruebas de unidad, de integración y de sistema. En el Proceso de Desarrollo Unificado, las pruebas de unidad se realizan el Flujo de Trabajo de Implementación y las pruebas de integración y de sistema en el Flujo de Trabajo de Prueba. Las pruebas de unidad son el primer tipo de pruebas que se realizan. Consiste en la prueba de los componentes más pequeños apenas son generados. Por referirse principalmente a la prueba de métodos de las clases, se ubican naturalmente en el Flujo de Trabajo de Implementación ya que es normal que quien realiza la codificación de la clase vaya realizando la prueba de sus métodos. Generalmente se realiza una evaluación estructural (o prueba de caja blanca), lo cual significa que se usan los conocimientos de cómo la unidad es diseñada internamente, y una evaluación de especificación (o prueba de caja negra), la cual usa lo opuesto: se aplican los test solamente sobre la especificación de los comportamientos de la unidad visibles externamente. El siguiente nivel de pruebas consiste en las pruebas de integración. Es la que está orientada a asegurar que las unidades individuales operan correctamente cuando se combinan en la aplicación. Esto valida la funcionalidad global de cada etapa de la aplicación parcial. Por último, las pruebas de sistema tienen como objetivo determinar si el sistema en su globalidad opera satisfactoriamente (recuperación de fallas, seguridad y protección, stress, performance, otros). Las funciones del sistema son ejercitadas y el programa es estresado para descubrir las limitaciones y medir los topes de capacidades. La mayoría de las pruebas de sistema se basan en la perspectiva de caja negra, solo consideran las funcionalidades solicitadas. El ambiente para este nivel de pruebas, donde el sistema está funcionando como un todo debe corresponderse lo más que se pueda con el ambiente de producción. Finalmente, se realizan las pruebas de aceptación que validan el producto final. El propósito de estas pruebas es darle al cliente o al usuario final la confianza y la seguridad que el sistema está listo para ser usado, por lo que encontrar defectos no tiene que ser el foco principal. El usuario final o el cliente que son ellos quienes dirigen las pruebas de este nivel

2

La siguiente figura ilustra los niveles de prueba:

Fuente: Libro “Ingeniería de Software – Una perspectiva orientada a objetos” - Eric Braude, Pág. 395.

Otras pruebas Pruebas de regresión: Cuando se precisa verificar que un producto mantiene la totalidad de sus funcionalidades después se le agrega una nueva, se ejecutan un conjunto de pruebas diseñado antes de hacer los cambios, llamadas pruebas de regresión. Las pruebas de aceptación están diseñadas para asegurar al cliente que se construyó la aplicación estipulada. Las pruebas de aceptación tal vez no sean muy diferentes de las pruebas del sistema que diseña el desarrollador, pero la organización del cliente es el testigo y se ejecutan en la plataforma que van a operar.

Tipos de Pruebas Existen definidas muchas tipificaciones de prueba, pero nos ocuparemos de las que consideramos más importantes: Las pruebas funcionales con el objetivo de probar la función del sistema. Se hacen para verificar los requisitos funcionales que fueron establecidos en las especificaciones, casos o escenarios de negocio o cualquier documento que establezca lo que el sistema debe hacer. Se pueden llevar a cabo en todos los niveles de prueba: componentes, de sistema, de integración y de aceptación.

3

Las pruebas no funcionales con el objetivo de probar las características del producto. Tienen que ver con las características del sistema en cuanto a la manera en que lleva a cabo sus funciones. A continuación se detallan las más típicas 

Volumen: Somete al producto a la entrada de grandes cantidades de datos.



De Carga: Somete al sistema a fuertes cargas de trabajo como tráfico excesivo o cargas elevadas de transacciones simultáneas y múltiples usuarios simultáneos.



De performance: Permiten medir los tiempos de respuesta y el comportamiento en la concurrencia



Utilidad: Valida la aceptación de la aplicación por los usuarios midiendo la reacción de estos. Algunos criterios esenciales son: accesibilidad, rapidez en las respuestas, eficiencia, comprensión.



Desempeño: Mide la velocidad para varias circunstancias.



Configurabilidad: Configura los distintos elementos de hardware/software. Por ejemplo, mide el tiempo de preparación.



Compatibilidad: Con otras aplicaciones designadas. Por ejemplo, mide el tiempo de adaptación.



Seguridad: Sujeta a intentos comprometedores. Por ejemplo, mide el tiempo promedio para entrar (romper) al sistema.



Uso de recursos: Mide el uso de RAM, espacio en disco, entre otros.



Aptitud de instalación: Mide el tiempo de instalación.



Recuperabilidad: Fuerza actividades que desactivan la aplicación y mide el tiempo de recuperación.



Funcionalidad: Da servicio a las aplicaciones en diferentes circunstancias, mide el tiempo de servicio. El término funcionalidad se refiere a la facilidad o dificultad con que la aplicación se mantiene operativa. Por ejemplo, una aplicación de sistema experto se apoya en su base de conocimientos, que debe ser capaz de modificarse con facilidad.

4

Las pruebas estructurales que tiene el objetivo de probar la estructura/arquitectura software. Las pruebas de asociadas al cambio, es decir aquellas que prueban el sistema después de los cambios, las más conocidas con re-testing, o sea la pruebas tras la corrección de errores, y las pruebas de regresión.

Flujo de trabajo de Pruebas Durante este flujo de trabajo se procederá a verificar el resultado de la implementación probando cada construcción, tanto las intermedias como las versiones finales del sistema. Los objetivos de la prueba son: 

Planificar las pruebas necesarias en cada iteración (pruebas de integración y de sistema).



Diseñar e implementar las pruebas creando casos de prueba que especifican qué probar, procedimientos de prueba que indican cómo realizar las pruebas y de ser posible crear componentes automatizados que realicen las pruebas.



Realizar las pruebas y manejar los resultados de las mismas sistemáticamente. Las construcciones en las que se detectan defectos son probadas es nuevo y posiblemente devueltas al flujo de diseño o implementación para que sean arregladas.

Durante la fase de inicio puede hacerse algo de la planificación de las pruebas. Sin embargo, las pruebas se llevan a cabo cuando una construcción es sometida a las pruebas de integración y de sistema. Esto quiere decir que las actividades de pruebas se centran en las fases de elaboración cuando se prueba la línea base ejecutable del sistema, y en la fase de construcción cuando el grueso del sistema está implementado. Durante la fase de transición el centro de atención se desplaza hacia la corrección de defectos durante los primeros usos del sistema y a las pruebas de regresión. A continuación se muestra un gráfico que indica el flujo de trabajo para la actividad de Prueba, que relaciona los trabajadores participantes con sus actividades, poniendo de manifiesto la secuencia de estas:

5

Fuente: Libro “El Proceso Unificado de Desarrollo de Software” - Ivar Jacobson y otros, Pág. 290

El siguiente gráfico muestra la relación entre los artefactos de la prueba y los trabajadores responsables de cada uno:

Fuente: Libro “El Proceso Unificado de Desarrollo de Software” - Ivar Jacobson y otros, Pág. 282.

El Modelo de Prueba es un modelo que describe principalmente cómo se prueban los componentes ejecutables (construcciones) en el modelo de implementación con pruebas de integración y de sistema. También puede especificar cómo se probarán ciertos aspectos específicos como la interfaz de usuario y la ayuda en línea. El modelo de pruebas está compuesto por un conjunto de casos de prueba, procedimientos de prueba y componentes de prueba. Un procedimiento de prueba especifica cómo realizar uno o más casos de prueba. Es similar a la descripción del flujo de eventos de un caso de uso pero incluye información adicional, como los valores de entrada del caso

6

de uso a utilizar, la forma en la que estos valores han de ser introducidos en la interfaz de usuario y lo que hay que verificar. Un componente de prueba automatiza uno o varios procedimientos de prueba o partes de ellos. El Plan de Pruebas describe las estrategias, recursos y planificación de la prueba. La estrategia incluye la definición del tipo de pruebas a realizar para cada iteración y sus objetivos, el nivel de cobertura de prueba y el porcentaje de pruebas que deberían ejecutarse con un resultado específico. Un defecto es una anomalía del sistema. Puede ser utilizado para localizar cualquier cosa que los desarrolladores deben registrar como un síntoma de problema en el software, que ellos necesitan controlar y resolver. La evaluación de la prueba es un análisis y valoración del resultado de la prueba, tales como cobertura del caso de prueba, cobertura de código y el estado de los defectos.

Casos de Prueba La IEEE en su estándar 829 (2008) define a un caso de prueba como la documentación que especifica las entradas, los resultados previstos o esperados, y un conjunto de condiciones de ejecución de un elemento de prueba. También la IEEE en el estándar 610 (1990), nos indica que la descripción de un caso de prueba debe incluir. En resumen, caso de prueba debe contener entradas, proceso y salidas: 

La entrada comprende tanto el conjunto de datos a ingresar para ejecutar el caso de prueba, como las pre-condiciones necesarias para poder ejecutar correctamente el caso de prueba.



El proceso es el conjunto de acciones a realizar para ejecutar el caso de prueba, que partiendo de los datos de entrada, deberán producir los datos esperados como resultado.



La salida es el conjunto de resultados que deben estar preestablecidas, es decir, ser conocidas y previstas antes de la primera ejecución del caso de prueba o lo que es lo mismo, se deben especificar en el momento de definir el caso de prueba.

Típicamente un caso de prueba en el Flujo de Trabajo de Prueba del PUD puede especificar:

7



Cómo probar un caso de uso o un escenario específico de un caso de uso. Este tipo de caso de prueba incluye la verificación del resultado de la interacción entre los actores y el sistema, que se satisfacen las pre-condiciones y las post-condiciones. Un caso de prueba de este tipo es una prueba de “caja negra”, es decir, una prueba del comportamiento exteriormente observable.



Cómo probar una realización de caso de uso-diseño, que incluye la verificación de la interacción de los componentes que implementan dicho caso de uso. Este tipo de prueba es una prueba de “caja blanca”, es decir, una prueba de la interacción interna de los componentes.

Para las pruebas de sistema, en el Flujo de Trabajo de Prueba se plantean las siguientes: 

Pruebas de instalación: Verifican que el sistema pueda ser instalado en la plataforma del cliente y que funcionará correctamente.



Pruebas de configuración: Verifican que el sistema funciona correctamente en diferentes configuraciones, como por ejemplo distintas configuraciones de red.



Pruebas negativas: Intentan provocar que el sistema falle para revelar sus debilidades. Consisten en casos de prueba en los que se utilizará el sistema deliberadamente “mal” o realizando cosas que no son las esperadas, o sobrecargándolo.



Pruebas de tensión o de estrés: Identifican problemas con el sistema cuando hay recursos insuficientes o cuando hay competencia por los recursos.



Pruebas de aceptación: Se realizan en el ambiente de operación, también se las conoce como testing del cliente. En la confección del plan de pruebas de aceptación debería participar el cliente.

8

Implementación Durante la implementación tomamos como entrada el resultado del diseño e implementamos el sistema en términos de componentes (archivos de código fuente, ejecutables, librerías y otros). La mayor parte de la arquitectura del sistema ya fue capturada durante el diseño, siendo el propósito principal de la Implementación desarrollar la arquitectura y el sistema como un todo.

Flujo de trabajo de Implementación Los creadores de Proceso Unificado de Desarrollo, Jacobson, Booch, y Rumbaugh (2006), plantearon en su libro de forma más específica los propósitos de la implementación del siguiente modo: 

Planear las integraciones de sistemas requeridas en cada iteración.



Repartir el sistema determinando componentes ejecutables a nodos en el diagrama de despliegue. De este modo se realiza la distribución de la funcionalidad del sistema.



Aplicar las clases y subsistemas identificados durante el diseño.



Testear los componentes de modo individual, para luego integrarlos en una compilación y enlazándolos en uno o más ejecutables.

El proceso de implementación lo inicia el arquitecto delineando los componentes más importantes en el modelo de implementación. Luego es el integrador de sistemas quien define las integraciones de sistema necesarias como secuencias de construcciones. En cada una de estas iteraciones el integrado describe qué funcionalidad se implementará y que subsistemas y componentes se afectarán. Los ingenieros de componentes implementan los requisitos en las partes del modelo de implementación correspondientes y realizan las pruebas sobre los componentes resultantes antes de pasarlos para su integración. El integrador los integra y los pasa para que se realicen las pruebas e integración previstas.

9

El siguiente gráfico muestra la relación entre los artefactos involucrados en la implementación y los trabajadores responsables de cada uno:

Fuente: Libro “El Proceso Unificado de Desarrollo de Software” - Ivar Jacobson y otros, Pág. 256.

A continuación describiremos brevemente cada uno de los artefactos obtenidos durante la implementación: El modelo de implementación describe cómo los elementos del diseño se implementan en términos de componentes. También detalla cómo se organizan los componentes de acuerdo con los mecanismos de estructuración y modularización disponibles en el entorno de implementación y en los lenguajes de programación utilizados. Un componente es un empaquetamiento físico de los elementos de un modelo, como las clases de diseño. Los componentes tienen las siguientes características: 

Los componentes tienen relaciones de traza con los elementos de modelo que implementan.



Es normal que un componente implemente varios elementos, por ejemplo varias clases, sin embargo la forma exacta en que se crea esta traza depende de cómo van a ser estructurados y modularizados los archivos de código fuente según el lenguaje de programación que se esté utilizando.

Los subsistemas de implementación constituyen una forma de organizar los elementos del modelo de implementación en partes más manejables y pueden estar compuestos por interfaces, componentes y otros subsistemas. Las mismas interfaces que se utilizaron en el modelo de diseño, pueden utilizarse en el modelo de implementación para especificar operaciones implementadas por componentes y subsistemas de implementación.

10

La descripción de la arquitectura, como vista del modelo de implementación, contiene la descomposición del modelo de implementación en subsistemas, sus interfaces y dependencias entre ellos, como también componentes claves, que siguen la traza de las clases de diseño arquitectónicamente significativas. El modelo de despliegue es un modelo de objetos que describe la distribución física del sistema en cuanto a la distribución de la funcionalidad entre los nodos de cómputo. Puede detallar diferentes configuraciones de red, incluidas las configuraciones para pruebas y simulación. En el gráfico continuación se muestra el flujo de trabajo para la actividad de implementación, que relaciona los trabajadores participantes con sus actividades, poniendo de manifiesto la secuencia de estas:

Fuente: Libro “El Proceso Unificado de Desarrollo de Software” - Ivar Jacobson y otros, Pág. 267

Es importante desarrollar el software en forma incremental, en pasos manejables. El resultado de cada paso es una versión ejecutable del sistema al que se denomina “construcción”. Cada construcción es sometida a pruebas de integración. El plan de integración de construcciones describe la secuencia de construcciones necesarias en una iteración, definiendo para cada una de ellas. Para consultar con mayor detalle los temas antes expuestos se recomienda revisar la bibliografía y el material visto en las materias del cuarto semestre “Bases de Datos I” y del quinto semestre “Análisis y Diseño de Software” y “Pruebas de Sistemas”.

11

Referencias ANSI/IEEE Std P730 (2002). Standard for Software Quality Assurance Plans. ANSI/IEEE Std P829 (2008). Standard for Software and System Test Documentation. Booch, G., Rumbaugh, J. y Jacobson, I. (2006). El Lenguaje Unificado de Modelado. Segunda Edición. España: Pearson-Addison Wesley. Braude, E., (2003). Ingeniería de Software, una perspectiva orientada a objetos. México: Alfaomega Grupo Editor SA. Jacobson I., Booch G., Rumbaugh J. (2000). El Proceso Unificado de Desarrollo de Software. España: Addison Wesley.

12...