09pruebassoftware

12/07/2011

CALIDAD DE PRODUCTO

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERÚ

Facultad de Ingeniería de Sistemas

INGENIERÍA DE SOFTWARE Proceso

Influye Calidad de proceso

Influye Calidad interna

Depende de

Efecto del producto

Producto

Influye Calidad externa

Depende de

Calidad en uso

Contextos de uso

Depende de

proveedor

usuario

PRUEBAS DE SOFTWARE MG. RICHARD Y. MERCADO RIVAS

ISO 14598

CALIDAD DE PRODUCTO Requisitos

mundo real

Operación

Necesidades

Calidad en uso

métricas externas

Identificar los tipos de producto(s) a ser evaluados

uso y respuesta determina

Especificación indica

comporta miento del sistema real

Requisitos calidad externos

Calidad externa

Integración del Sistema y Pruebas métricas externas

PRUEBAS DE SW Pruebas de software son los procesos que permiten verificar y revelar la calidad de un producto software.

Las pruebas de software se integran dentro de las diferentes fases del Ciclo del software dentro de la Ingeniería de software.

Así se ejecuta un programa y mediante técnicas experimentales se trata de descubrir que errores tiene Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto de las especificaciones iniciales del sistema.

Las pruebas de software, testing o beta testing es un proceso usado para identificar posibles fallos de implementación, calidad, o usabilidad de un programa.

Básicamente es una fase en el desarrollo de software consistente en probar las aplicaciones construidas.

determina

"El testing puede probar la presencia de errores pero no la ausencia de ellos", E. W. Dijkstra.

Diseño y Desarrollo indica

atributos software

Requisitos calidad internos

Calidad interna

métricas internas

PRUEBAS DE SW Una definición de "testing" es: proceso de evaluación de un producto desde un punto de vista crítico, donde el "tester" (persona que realiza las pruebas) somete el producto a una serie de acciones inquisitivas, y el producto responde con su comportamiento como reacción.

Por supuesto, nunca se debe testear el software en un entorno de producción

Conceptos  Error: acción humana que produce una falta  Falta: algo que está mal en un producto (modelo, código, documento, etc.)  Fallo: manifestación de una falta  Defecto: error, falta o fallo Verificación y Validación  Verificación: ¿estamos construyendo el producto correctamente?  Validación: ¿estamos construyendo el producto correcto?

1

12/07/2011

RELACIÓN ENTRE ERROR, DEFECTO Y FALLO

PRUEBAS DE PROGRAMAS Pruebas de programas es el proceso de ejecutar programas con el propósito de encontrar errores Se puede mostrar la presencia de un error pero no la ausencia [Dijkstra] Debería ser visto como el último recurso para encontrar errores

PROCESO DE PRUEBAS DE PROGRAMAS Preparar Casos de Prueba

Congelar versión del Sw para Pruebas

Ejecutar Casos de Prueba

NO Errors Detectados?

Version Acceptada

PROCESO DE PRUEBAS DE PROGRAMAS: DEPURACIÓN Diagnosticar Error

Planificar Cambios ?

Seleccionar casos de prueba para probar los cambios

Actualizar Requerimientos

SI Hacer Pruebas Totales o parciales de Regresión

Seleccionar y Priorizar los errores para corrección

Selecionar casos de Prueba para Pruebas de Regresión

Actualizar Diseño Arquitec.

Actualizar Diseño Detallado

Verificar Correcciones

Congelar versión corregida del Sw

Actualizar código

Corregir

Probar los Cambios Pruebas de Regresión

CICLO EN V

CICLO COMPLETO DE LAS PRUEBAS

Definición de Requerimientos

Análisis Requirementos

Preparación Pruebas Aceptación

Diseño Arquitectura

Preparación Pruebas Sistema

Diseño Detallado

Programación

Preparación Integración Preparacion Pruebas Unit.

Pruebas Unitarias

Pruebas Integración

Pruebas SIstema

Pruebas Aceptación

2

12/07/2011

TÉCNICAS DE PRUEBA Caja blanca o pruebas estructurales  El conocimiento del diseño interno del software se usa para desarrollar los casos de pruebas Caja negra o pruebas funcionales  Los casos de prueba son diseñados basados sólo en la especificación externa del software Pruebas basadas en escenarios o casos de uso  Actuar como un usuario final y crear escenarios reales para detectar errores

PRUEBAS DE CAJA BLANCA PRUEBA DEL CAMINO BÁSICO - GRAFO DE FLUJO Secuencia

end if

no opción1

no opción2

no opciónN

...

CASE then

if

opción2

else

While

...

opciónN

opción1

END CASE

PRUEBAS DE CAJA BLANCA PRUEBA DEL CAMINO BÁSICO - ... GRAFO DE FLUJO

TÉCNICAS DE PRUEBA (2) Pruebas Selectivas  Generar más casos de prueba para las funciones o componentes que son más usados  Probar más rigurosamente las funciones o componentes más críticos  Generar mas casos de prueba para las funciones o componentes más complejos

PRUEBAS UNITARIAS (1)

PRUEBAS UNITARIAS (2)

Descripción  Su propósito es encontrar errores en la lógica, datos o algoritmos en componentes o subsistemas individuales  Realizado por los desarrolladores del componente  Técnica de prueba: Caja blanca

Guías para generar casos de prueba  Tratar de detectar errores en los algoritmos y la lógica  Tratar de detectar errores en la manipulación de las estructuras de datos  Tratar de detectar errores en el llamado a otros módulos  Identificar todos los caminos posibles del módulo y tratar de hacer casos de prueba que los cubran  Tratar de detectar errores usando datos límites

3

12/07/2011

PRUEBAS DE INTEGRACIÓN

PRUEBAS DE INTEGRACIÓN (2)

Descripción  Su propósito es encontrar errores en las interfaces entre los módulos  Realizado por los desarrolladores de los módulos que serán integrados  Técnica de Prueba: Caja negra basado en las especificaciones de las interfaces

Guías para generar casos de prueba  Tratar de detectar errores en los formatos de intercambio de datos  Tratar de detectar errores en el el orden en que interactúan los módulos, la sincronización y los tiempos de respuesta

PRUEBAS DE SISTEMA Descripción  Su propósito es encontrar errores en el comportamiento del sistema de acuerdo con la especificación de requerimientos  Realizado por un grupo diferente al de desarrollo  Técnica de Prueba: Caja negra basado en los requerimientos y en escenarios reales Guías para generar casos de prueba  Verificar que la funcionalidad del sistema es correcta y completa  Verificar que el sistema tiene la capacidad volumétrica, de robustez y que se comporta bien ante fallas

PRUEBAS DE SISTEMAS 1. Probar el mecanismo de login usando logins correctos e incorrectos para comprobar que los usuarios válidos son aceptados y que los inválidos son rechazados.

2. Probar la facilidad de búsqueda utilizando consultas con fuentes conocidas para comprobar que el mecanismo de búsqueda realmente encuentra los documentos.

3. Probar la facilidad de presentación del sistema para comprobar que la información sobre los documentos se visualiza adecuadamente.

4. Probar el mecanismo descargas.

para solicitar permisos para

PRUEBAS DE INTEGRACIÓN INCREMENTABLES

ESCENARIO DE PRUEBAS Una estudiante que estudia Historia Americana tiene que escribir un trabajo sobre «la mentalidad sobre las fronteras en el Este Americano desde 1840 a 1880». Para hacer esto, necesita encontrar documentación de varias bibliotecas. Se registra en el sistema y utiliza la facilidad de búsqueda para ver si puede acceder a los documentos originales de esa época. Descubre trabajos en varias bibliotecas universitarias de Estados Unidos y descarga copias de algunos de ellos. Sin embargo, para uno de los documentos, necesita tener confirmación de su Universidad de que ella en verdad es estudiante y de que el uso del documento es para fines no comerciales. La estudiante entonces utiliza la facilidad del Sistema que le permite solicitar dicho permiso y registrar su petición. Si ésta es aceptada, el documento podrá descargarse en el servidor de la biblioteca registrada y ser impreso. La estudiante recibe un mensaje del Sistema informándole de que recibirá un mensaje de correo electrónico cuando el documento impreso esté disponible para ser recogido.

PRUEBAS DE ACEPTACIÓN Descripción  Su propósito es verificar que el sistema satisface los requerimientos del cliente (en el sitio del cliente)  Realizado por un grupo de usuarios finales  Técnicas de Prueba: Caja negra basado en los requerimientos y en escenarios reales Guías para generar casos de prueba  Similar a pruebas del sistema

5. Probar la respuesta de correo electrónico indicando que el documento descargado está disponible.

4

12/07/2011

PRUEBAS DE REGRESIÓN Descripción  Su propósito es verificar que, después de un cambio, las partes no cambiadas del sistema se siguen comportando igual (no hay efectos de borde)  Están asociadas al mantenimiento de Software

CONCEPTOS Espacio de Prueba  Conjunto de todos los posibles casos de Prueba Pruebas de subdominios  Subconjuntos del espacio de Prueba Línea de Prueba (Test Suite)  Conjunto de casos de prueba que serán ejecutados en una fase Testbed/Test Harness  Software adicional desarrollado para soportar la ejecución de los casos de prueba Prueba de Cubrimiento  Grado en el cual los casos de prueba “pasan” por el código siendo probado

ESTRUCTURA DEL ESPACIO DE PRUEBAS

DISEÑO DE LOS CASOS DE PRUEBA

Taxonomia de los Casos de Prueba  Pruebas Funcionales: considerar solamente entradas válidas al sistema y condiciones normales de operación.  Pruebas de Robustez: considerar datos de entrada inválidos, secuencias invalidas de comandos/acciones, etc.  Pruebas de Frontera: considerar valores/tamaños mínimos y máximos para datos de entrada, carga del sistema mínima y máxima, etc.  Pruebas de tolerancia a fallas: considerar condiciones anormales de operación, fallas hardware y software de la plataforma computacional sobre la que funciona el software en prueba.

Hacer una lista de los propósitos de Prueba  Usar la taxonomía de los casos de prueba como guía

DISEÑO DE LOS CASOS DE PRUEBA (2)

DISEÑO DE LOS CASOS DE PRUEBA (3)

 Cuales son los errores típicos encontrados en productos similares probados en el pasado, y que casos de prueba se usaron para revelarlos?  En pruebas del sistema y pruebas de aceptación, qué casos es probable que los desarrolladores hubieran pasado por alto (desde el punto de vista del experto del negocio o dominio de aplicación)?  En pruebas de unidad y pruebas de integración, qué características complejas del diseño pudieron haber sido implementadas de forma incorrecta?

 En pruebas del sistema y pruebas de aceptación, qué aspectos complejos acerca de los requerimientos pudieron haber sido mal interpretados por los desarrolladores?  Qué casos triviales pudieran haber sido no tenidos en cuenta en la implementación?

Por cada propósito de Prueba, hacer una lista de casos de prueba  Construir una versión preliminar de la lista de casos de prueba a partir de los escenarios típicos relacionados con el propósito de prueba  Enriquecer la lista de casos de prueba, analizando las posibles variaciones o casos especiales de los escenarios considerados  Complementar la lista de casos de prueba, analizando posibles casos que puedan revelar errores, usando como guía la siguiente lista de chequeo:

5

12/07/2011

DISEÑO DE LOS CASOS DE PRUEBA (4)

CASOS DE USO

Para cada caso de prueba, especificar los pasos para realizar la prueba y los criterios de aceptación de la prueba, tal como se indica en el formato: Caso de uso Procedimiento Criterios de aceptación Procedimiento Criterios de aceptación ...

Caso 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.

DIAGRAMA DE SECUENCIA DE RECOPILACIÓN DE DATOS SOBRE EL TIEMPO

Desde un diagrama de secuencia asociado, pueden identificarse las entradas y salidas que deben crearse para las pruebas.

DISEÑO DE LOS CASOS DE PRUEBA (7) Para cada caso de prueba se debe especificar  Instrucciones de prueba: lista de pasos a seguir por los usuarios encargados de ejecutar la prueba.  Criterios de aceptación: lista de condiciones (predicados) que deben satisfacerse para determinar el éxito de la prueba, incluyendo restricciones sobre los datos de salida esperados, y condiciones que deben cumplirse en el estado interno del sistema (ej. valores de algunas tablas) después de ejecutar el caso de prueba.

ESTRUCTURA DE LOS CASOS DE PRUEBA Formalmente, los casos de prueba escritos consisten principalmente en tres partes con subdivisiones: Introducción/visión general contiene información general acerca de los Casos de Prueba.  Identificador es un identificador único para futuras referencias, por ejemplo, mientras se describe un defecto encontrado.  Caso de prueba dueño/creador es el nombre del analista o diseñador de pruebas, quien ha desarrollado pruebas o es responsable de su desarrollo.  Versión la actual definición del caso de prueba.  Nombre el caso de prueba debe ser un título entendible por personas, para la fácil comprensión del propósito del caso de prueba y su campo de aplicación.

ESTRUCTURA DE LOS CASOS DE PRUEBA  Identificador de requerimientos el cuál está incluido por el caso de prueba. También aquí puede ser identificador de casos de uso o especificación funcional.  Propósito contiene una breve descripción del propósito de la prueba, y la funcionalidad que chequea.  Dependencias Actividad de los casos de prueba  Ambiente de prueba/configuración contiene información acerca de la configuración del hardware o software en el cuál se ejecutará el caso de prueba.  Inicialización describe acciones, que deben ser ejecutadas antes de que los casos de prueba se hayan inicializado. Por ejemplo, debemos abrir algún archivo.

6

12/07/2011

ESTRUCTURA DE LOS CASOS DE PRUEBA

DESARROLLO GUIADO POR PRUEBAS

 Finalización describe acciones, que deben ser ejecutadas después de realizado el caso de prueba. Por ejemplo si el caso de prueba estropea la base de datos, el analista debe restaurarla antes de que otro caso de prueba sea ejecutado.  Acciones pasos a realizar para completar la prueba.  Descripción de los datos de entrada

Desarrollo guiado por pruebas, o Test-driven development (TDD) es una práctica de programación que involucra otras dos prácticas: Escribir las pruebas primero (Test First Development) y Refactorización (Refactoring).

Resultados  Resultados esperados contiene una descripción de lo que el analista debería ver tras haber completado todos los pasos de la prueba  Resultados reales contienen una breve descripción de lo que el analista encuentra después de que los pasos de prueba se hayan completado. Esto se sustituye a menudo con un Correcto/Fallido.

Si un caso de prueba falla, frecuentemente la referencia al defecto implicado se debe enumerar en esta columna.

El propósito del desarrollo guiado por pruebas es lograr un código limpio que funcione (Del inglés: Clean code that works).

CICLO DE DESARROLLO CONDUCIDO POR PRUEBAS

CICLO DE DESARROLLO CONDUCIDO POR PRUEBAS

Antes de comenzar el ciclo se debe definir una lista de requerimientos. Luego se comienza el siguiente ciclo:

Ejecutar las pruebas automatizadas: Verificar si todo el conjunto de pruebas funciona correctamente.

Elegir un requerimiento: Se elige de una lista el requrimiento que se cree que nos dará mayor conocimiento del problema y que a la vez sea fácilmente implementable.

Escribir una prueba: Se comienza escribiendo una prueba para el requerimiento.

Para ello el programador debe entender claramente las especificaciones y los requisitos de la funcionalidad que está por implementar. Este paso fuerza al programador a tomar la perspectiva de un cliente considerando el código a través de sus interfaces.

Verificar que la prueba falla: Si la prueba no falla es porque el requerimiento ya estaba implementado o porque la prueba es errónea.

Escribir la implementación: Escribir el código más sencillo que haga que la prueba funcione. Se usa la metáfora "Déjelo simple" ("Keep It Simple, Stupid" (KISS)).

CARACTERÍSTICAS

Para escribir las pruebas generalmente se utilizan las pruebas unitarias (unit test en inglés).

Primeros e escribe una prueba y se verifica que las pruebas fallen, luego se implementa el código que haga que la prueba pase satisfactoriamente y seguidamente se refactoriza el código escrito.

La idea es que los requerimientos sean traducidos a pruebas, de este modo, cuando las pruebas pasen se garantizará que los requerimientos se hayan implementado correctamente.

Eliminación de duplicación: El paso final es la refactorización, que se utilizará principalemente para eliminar código duplicado. Se hacen de a una vez un pequeño cambio y luego se corren las pruebas hasta que funcionen.

Actualización de la lista de requerimientos: Se actualiza la lista de requerimientos tachando el requerimiento implementado.

Asimismo se agregan requerimientos que se hayan visto como necesarios durante este ciclo y se se agregan requerimientos de diseño (P. ej que una funcionalidad esté desacoplada de otra).

UNIVERSIDAD NACIONAL DEL CENTRO DEL PERÚ

Facultad de Ingeniería de Sistemas Una ventaja de esta forma de programación es el evitar escribir código innecesario ("You Ain't Gonna Need It" (YAGNI)). Se intenta escribir el mínimo código posible, y si el código pasa una prueba aunque sepamos que es incorrecto nos da una idea de que tenemos que modificar nuestra lista de requerimientos agregando uno nuevo.

La generación de pruebas para cada funcionalidad hace que el programador confíe en el código escrito. Esto permite hacer modificaciónes profundas del código (posiblemente en una etapa de mantenimiento del programa) pues sabemos que si luego logramos hacer pasar todas las pruebas tendremos un código que funcione correctamente.

Otra cracterística del Test Driven Development requiere que el programador primero haga fallar los casos de prueba. La idea es asegurarse de que los casos de prueba realmente funcionen y puedan recoger un error.

MG. RICHARD Y. MERCADO RIVAS

7