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