Calidad de Software Ing. Alonso Morales
2011
EJECUCIÓN DE PRUEBAS
Integrantes: Alvarado Pachas, Euler Hardy. Orellana Paucar, Rony Eduardo. Quispe Gamboa, Omar Ernesto. Saravia Soto, Jhonathan Vargas Castilla, Kelvin Renzo.
Facultad de Ingeniería de Sistemas
Ejecución de pruebas
2011
2
Ejecución de pruebas
2011
2
Ejecución de pruebas
2011
Contenido INTRODUCCION ............................................................................................................. ............................................................................................................. 5 1.
2.
CONCEPTOS INTRODUCTORIOS ............................................................................... ............................................................................... 6 1.1.
DEFINICIONES ............................................................................................................ 6
1.2.
RELACION ENTRE DEFECTO, FALLA Y ERROR ................................................................ 6
1.3.
CICLO DE LAS PRUEBAS DE SOFTWARE ........................................................................ ........................................................................ 7
1.4.
¿QUÉ ES PROBAR? ..................................................................................................... PROBAR? ..................................................................................................... 8
1.5.
¿PORQUÉ ES IMPORTANTE HACER PRUEBAS EN NUESTRO SOFTWARE? ....................... ....................... 8
EJECUCIÓN DE PRUEBAS ......................................................................................... ......................................................................................... 9 2.1.
DEFINICIÓN ................................................................................................................. ............................................................................................................... 9
2.2.
FASES ...................................................................................................................... 10
2.3.
HERRAMIENTAS PARA IMPLEMENTAR Y EJECUTAR PRUEBAS .................................... 12
2.3.1. 2.3.2. 2.3.3. 2.3.4. 2.3.5. 2.3.6.
3.
E-TESTER.............. E-TESTER ............................ ............................. ............................. ............................ ............................ ............................ ............................ ............................ ................ .. 12 RATIONAL FUNCTIONAL TESTER.............. TESTER ............................ ............................ ............................ ............................ ............................ ....................... ......... 13 QUICK TEST PRO .......................... ........................................ ............................ ............................ ............................ ............................. ............................. .................... ...... 15 RATIONAL ROBOT .......................... ........................................ ............................ ............................. ............................. ............................ ............................ .................. .... 15 TESTPARTNER.............. TESTPARTNER ............................ ............................ ............................ ............................ ............................ ............................. ............................. ...................... ........ 16 WINRUNNER.............. WINRUNNER........................... ........................... ............................ ............................. ............................. ............................ ............................ ......................... ........... 17
CASOS DE PRUEBA ................................................................................................ ................................................................................................ 18 3.1.
CONCEPTO............................................................................................................... CONCEPTO ............................................................................................................... 18
3.2.
OBJETIVOS............................................................................................................... OBJETIVOS ............................................................................................................... 20
3.3.
TECNICAS DE PRUEBAS............................................................................................. PRUEBAS ............................................................................................. 21
3.3.1. TECNICAS DE PRUEBAS GENERALES: ............................ .......................................... ............................ ............................. ............................ ............... .. 21 3.3.1.1. PRUEBA POSITIVA .......................... ........................................ ............................ ............................ ............................ ............................. ............................ ............. 21 3.3.1.2. PRUEBA NEGATIVA .......................... ......................................... ............................. ............................ ............................ ............................ ......................... ........... 22 3.3.1.3. PRUEBA DE CAJA NEGRA............................ NEGRA.......................................... ............................ ............................ ............................ ............................ ................ .. 22 3.3.1.4. PRUEBA DE CAJA BLANCA .............................. ............................................. ............................. ............................ ............................ ......................... ........... 23 3.3.1.5. ADIVINAR ERRORES............................. ERRORES........................................... ............................ ............................ ............................ ............................. ....................... ........ 24 3.3.1.6. PRUEBA DE SOFTWARE AUTOMATIZADO............................ .......................................... ............................ ............................ .................. .... 25 3.3.2. TECNICAS DE PRUEBAS FUNCIONALES: ............................ ........................................... ............................. ............................ ......................... ........... 25 3.3.2.1. EQUIVALENCIA DE PARTICIONAMIENTO ...................................... .................................................... ............................. ....................... ........ 25 3.3.2.2. ANALISIS DEL VALOR LÍMITE .................................... .................................................. ............................ ............................ ............................ ................ .. 26
4.
CLASES DE EQUIVALENCIA............................................. ..................................................................................... ........................................ 27
3
Ejecución de pruebas 4.1.
DEFINICIÓN ............................................................................................................... ............................................................................................................. 27
4.2.
DIRECTRICES ............................................................................................................ 27
4.3.
PARTICIÓN EQUIVALENTE ........................................................................................ EQUIVALENTE ........................................................................................ 27
2011
4.3.1. DEFINICIÓN............. DEFINICIÓN........................... ............................ ............................ ............................ ............................ ............................ ............................ ............................ .............. 27 4.3.2. ¿QUÉ PASOS SEGUIR? ........................... .......................................... ............................. ............................ ............................ ............................ ......................... ........... 27 4.3.3. EJERCICIO DE PRUEBA DE CAJA NEGRA – CLASES DE EQUIVALENCIA ........................... .................................... ......... 28 4.3.3.1. ENUNCIADO ............................ .......................................... ............................ ............................ ............................ ............................. ............................. .................... ...... 28 4.3.3.2. SOLUCIÓN .......................... ........................................ ............................ ............................. ............................. ............................ ............................ ......................... ........... 29
5.
INFORME Y SEGUIMIENTO DE PRUEBAS ................................................ ................................................................ ................ 31 5.1.
DOCUMENTACIÓN EN EL PROCESO DE PRUEBAS ....................................................... 31
5.1.1. DOCUMENTACIÓN EN LA PREPARACION DE LAS PRUEBAS ............................ ........................................... ....................... ........ 32 5.1.1.1. PLAN DE PRUEBAS ........................... .......................................... ............................. ............................ ............................ ............................ ......................... ........... 33 5.1.1.2. DOCUMENTO DE ESPECIFICACIÓN DE DISEÑO DE PRUEBAS ........................... ......................................... .................. .... 34 5.1.1.3. DOCUMENTO DE ESPECIFICACIÓN DE CASOS DE PRUEBA ................................... ................................................ ............. 34 5.1.1.4. DOCUMENTO DE ESPECIFICACIÓN DE LOS PROCEDIMIENTOS DE PRUEBA ...................... 35 5.1.1.5. INFORME DE TRANSMISIÓN DE ELEMENTOS DE PRUEBAS .......................... ......................................... ..................... ...... 36 5.1.2. DOCUMENTACION DURANTE LA EJECUCION DE LAS PRUEB AS ........................... ......................................... .................. .... 36 5.1.2.1. REGISTRO DE PRUEBAS (HISTÓRICO DE PRUEBAS O TEST LOG) L OG) ............... ............................. ......................... ........... 37 5.1.2.2. INFORME DE INCIDENTES ............................ .......................................... ............................ ............................ ............................ ............................ .............. 38 5.1.3. DOCUMENTACIÓN PARA LA FINALIZACION DE LAS PRUEBAS ........................... .......................................... ..................... ...... 38 5.1.3.1. INFORME DE RESUMEN DE PRUEBAS ............................... ............................................. ............................ ............................. ..................... ...... 38 38
5.2.
SEGUIMIENTO DE LAS PRUEBAS ............................................................................... 39
5.2.1. DEPURACIÓN (DEBUGGING) ............................ .......................................... ............................ ............................ ............................ ............................ .............. 39 5.2.1.1. DEFINICIÓN ........................... ......................................... ............................ ............................ ............................ ............................. ............................. ...................... ........ 39 5.2.1.2. CONSEJOS PARA LA DEPURACIÓN ........................... ......................................... ............................ ............................. ............................ ............... .. 40 5.2.2. ¿CUÁNDO PARAR DE PROBAR? ............ PROBAR? .......................... ............................. ............................. ............................ ............................ ......................... ........... 41
CONCLUSIÓN ............................................................................................................... ............................................................................................................... 42 42 RECOMENDACIONES................................................... RECOMENDACIONES.................................................................................................... ................................................. 43 43 BIBLIOGRAFIA ............................................ ............................................................................................. ................................................................. ................ 44
4
Ejecución de pruebas
2011
INTRODUCCION Una de las últimas fases del ciclo de vida antes de entregar un programa para su explotación, es la fase de pruebas. Las pruebas de software se aplican como una etapa más del proceso de desarrollo de software, su objetivo es asegurar que el software cumpla con las especificaciones requeridas y eliminar los posibles defectos que este pudiera tener. En un principio la mayoría de empresas de desarrollo contaban con una etapa de pruebas demasiado informal, en la actualidad las pruebas de software se han convertido en una de las etapas más críticas del ciclo de vida del desarrollo de software y esto ha causado el origen de diversas metodologías. En la actualidad la prueba de software se hace más complicada ya que debe hacer frente a una gran cantidad de metodologías de desarrollo, lenguajes de programación, sistemas operativos, hardware etc. Es por esto que la prueba debe apoyarse en metodologías generales que revisan los aspectos más fundamentales que debe considerar todo proceso de pruebas. Debido a esta complejidad actualmente se cuentan con una gran cantidad de software diseñado exclusivamente para la etapa de pruebas, incluyendo la gestión del proceso de prueba de software, la administración y seguimiento de errores, la administración de los casos de prueba, automatización de pruebas, etc.
5
Ejecución de pruebas
2011
1. CONCEPTOS INTRODUCTORIOS 1.1.DEFINICIONES
PRUEBAS (test): una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias previamente especificadas, los resultados se observan y registran y se realiza una evaluación de algún aspecto.
CASO DE PRUEBA (test case): un conjunto de entradas, condiciones de ejecución y resultados esperados desarrollados para un objetivo particular.
DEFECTO (defect, fault, «bug»): un defecto en el software como, por ejemplo, un proceso, una definición de datos o un paso de procesamiento incorrectos en un programa.
FALLO (failure): La incapacidad de un sistema o de alguno de sus componentes para realizar las funciones requeridas dentro de los requisitos de rendimiento especificados.
ERROR (error): La diferencia entre un valor calculado, observado o medio y el valor verdadero, especificado o teóricamente correcto.
1.2.RELACION ENTRE DEFECTO, FALLA Y ERROR En la figura 1.1 podemos observar graficamente la relación directa que existe entre las definiciones de defecto, falla y error.
Figura 1.1. Relación entre Defecto, Falla y Error
6
Ejecución de pruebas
2011
Así podemos entablar la relación consecuencial como nos muestra la figura 1.2:
Figura 1.2. Relación Consecuencial entre Defecto, Falla y Error
1.3.CICLO DE LAS PRUEBAS DE SOFTWARE
Figura 1.3. Ciclo de Vida de las Pruebas de Software
7
Ejecución de pruebas
2011
1.4.¿QUÉ ES PROBAR? Erróneamente, la mayoría de la gente piensa que: Probar es el proceso de demostrar que no hay errores. Probar nos permite demostrar que el programa realiza lo que se supone que debe hacer.
Como parte que es de un proceso industrial, la fase de pruebas añade valor al producto que se maneja: todos los programas tienen errores y la fase de pruebas los descubre; ese es el valor que añade. El objetivo específico de la fase de pruebas es encontrar cuantos más errores, mejor. Es frecuente encontrarse con el error de afirmar que el objetivo de esta fase es convencerse de que el programa funciona bien. En realidad ese es el objetivo propio de las fases anteriores (¿quién va a pasar a la sección de pruebas un producto que sospecha que está mal?). Cumplido ese objetivo, lo mejor posible, se pasa a pruebas. Esto no obsta para reconocer que el objetivo último de todo el proceso de fabricación de programas sea hacer programas que funcionen bien; pero cada fase tiene su objetivo específico, y el de las pruebas es destapar errores. Probar un programa es ejercitarlo con la peor intención a fin de encontrarle fallos.
DEFINICIÓN CORRECTA: “Probar es el proceso de ejecutar un programa con la intención de
encontr ar errores”.
1.5.¿PORQUÉ ES IMPORTANTE HACER PRUEBAS EN NUESTRO SOFTWARE? En la cadena de valor del desarrollo de un software específico, el proceso de prueba es clave a la hora de detectar errores o fallas. Conceptos como estabilidad, escalabilidad, eficiencia y seguridad se relacionan a la calidad de un producto bien desarrollado. Las aplicaciones de software han crecido en complejidad y tamaño, y por consiguiente también en costos. Hoy en día es crucial verificar y evaluar la calidad de lo construido de modo de minimizar el costo de su reparación. Mientras antes se detecte una falla, más barata es su corrección. El proceso de prueba es un proceso técnico especializado de investigación que requiere de profesionales altamente capacitados en lenguajes de desarrollo, métodos y técnicas de pruebas y herramientas especializadas. El conocimiento que debe manejar un ingeniero de prueba es muchas veces superior al del desarrollador de software.
8
Ejecución de pruebas
2011
2. EJECUCIÓN DE PRUEBAS 2.1.DEFINICIÓN Es la actividad donde los procedimientos de pruebas o scripts son especificados combinando los casos de prueba en un orden particular e incluyendo cualquier otra información necesaria para la ejecución de pruebas, el ambiente se preparara y se ejecutan las pruebas. Se ejecutan las pruebas mediante la definición de las actividades requeridas para ejecutar los requerimientos de pruebas identificados en la fase de diseño de pruebas, reportar los hallazgos y asegurar su corrección por parte del equipo de desarrollo de software.
Figura 2.1. Proceso de Ejecución de Pruebas
9
Ejecución de pruebas
2011
La fase de ejecución de pruebas se realiza por iteraciones de pruebas. (Total o un subconjunto de los requerimientos de pruebas). En cada iteración de pruebas se registran los hallazgos o No Conformidades de software tal como se muestra en la figura 2.2. El objetivo de esta etapa es contrastar el comportamiento esperado del software con su comportamiento real, analizar las diferencias y reportar los resultados. Durante la etapa de ejecución, los responsables de pruebas deben ejecutar la mayor cantidad posible de iteraciones y regresiones de prueba hasta poder demostrar gráficamente que existe una tendencia sostenida a la baja en la cantidad de no conformidades encontradas.
Figura 2.2. Curva de Registro de Hallazgos o No C onformidades
El resultado real de ejecución debe cumplir con dos características fundamentales que permiten evidenciar su cumplimiento:
La correctitud: exactitud de los resultados reales versus los esperados. La completitud: cobertura de los resultados reales versus los esperados.
2.2.FASES a) El proceso de ejecución de pruebas según el estándar IEEE Std. 829, abarca las siguientes fases: Ejecutar las pruebas, cuyos casos y procedimientos han sido ya diseñados previamente.
10
Ejecución de pruebas
Comprobar si se ha concluido el proceso de prueba (según ciertos criterios de compleción de prueba que suelen especificarse en el plan de pruebas).
En el caso que hayan terminado las pruebas, se evalúan los resultados; en caso contrario hay que generar las pruebas adicionales para que se satisfagan los criterios de compleción de pruebas.
2011
b) El proceso de ejecución propiamente dicho, consta de las siguientes fases: Se ejecutan las pruebas.
Se comprueba si ha habido algún fallo al ejecutar.
Si lo ha habido, se puede deber a un defecto del software, lo que nos lleva al proceso de depuración o corrección del código. Se puede deber también a un defecto en el propio diseño de las pruebas. En ambos casos, las nuevas pruebas o las corregidas se deberán ejecutar.
De no existir fallos, se pasará a la comprobación de la terminación de las pruebas.
c) Las fases del proceso de comprobación de la terminación de las pruebas son: Tras la ejecución, se comprueba si se cumplen los criterios de compleción de pruebas descritos en el correspondiente plan de pruebas.
En caso de terminar las pruebas, se pasa a la evaluación de los productos probados sobre la base de los resultados obtenidos (terminación normal).
En caso de no terminar las pruebas se debe comprobar la presencia de condiciones anormales en la prueba.
Si hubiesen existido condiciones anormales, se pasa de nuevo a la evaluación; en caso contrario, se pasa a generar y ejecutar pruebas adicionales para satisfacer cualquiera de las dos terminaciones.
Los criterios de compleción de pruebas hacen referencia a las áreas (características, funciones, etc.) que deben cubrir las pruebas y el grado de cobertura para cada una de esas áreas. Como ejemplos genéricos de este tipo de criterios se pueden indicar los siguientes:
Se debe cubrir cada característica o requerimiento del software mediante un caso de prueba o una excepción aprobada en el plan de pruebas. En programas codificados con lenguajes procedurales, se deben cubrir todas las instrucciones ejecutables mediante casos de prueba.
11
Ejecución de pruebas
2011
2.3.HERRAMIENTAS PARA IMPLEMENTAR Y EJECUTAR PRUEBAS Sabemos que las pruebas de software es el acto de la ejecución de software para satisfacer una, algunas o todas de las siguientes metas:
Para asegurar que el software cumple con los requisitos especificados. Identificar los defectos en el software (estos defectos se refieren a menudo como "bugs"). Para entender el nivel de calidad del software.
En la actualidad, para cumplir estos objetivos, muchas organizaciones utilizan las pruebas de software manual, es decir, la gente se sienta delante de un ordenador y usa los scripts para realizar sus pruebas. A menudo, muchos de estos scripts de prueba deben ser ejecutados en varias ocasiones, como emisiones sucesivas del software. Esto no sólo puede resultar monótono y aburrido para los individuos que han de ejecutar las pruebas, pero desde una perspectiva organizacional puede ser muy intensivo en el uso de recursos. Con el fin de ayudar a aliviar este problema, algunas compañías desarrollaron herramientas automatizadas de prueba. En términos simples, una vez la gente utiliza estas herramientas para crear scripts automatizados de prueba. Estas herramientas pueden ejecutar los scripts cada vez que lo indique, con poca supervisión necesaria de los seres humanos. Esto permite a los probadores que normalmente ejecutan el script manualmente, automatizar las pruebas para concentrarse en otros aspectos más interesantes en el desarrollo del software. Ahora estamos a lo largo de varias generaciones en términos de herramientas de pruebas automatizadas. En su mayor parte, en las primeras generaciones eran difíciles de usar, y las secuencias de comandos automatizadas que se utilizan para crear no eran fáciles de mantener. Sin embargo, las últimas herramientas que se han desarrollado son más fáciles de utilizar, de manera que pueda ser utilizado por un mayor número de personas que tienen diferentes niveles y tipos de habilidades. En este capítulo tratare de explicar cuáles son las herramientas que se emplean para implementar y ejecutar pruebas funcionales y de regresión, así como ver cuáles son sus características. Entre las herramientas más usadas para realizar pruebas funcionales y de regresión tenemos las siguientes:
2.3.1. E-TESTER Empirix e-Tester es una herramienta de prueba automatizada que forma parte de la suite de e-test de aplicaciones. E-Tester proporciona a los usuarios la capacidad de crear scripts automatizados de prueba de funcionamiento. Está diseñado para ser utilizado para probar web, soluciones inalámbricas y aplicaciones multimedia.
12
Ejecución de pruebas
2011
¿CÓMO FUNCIONA? Un usuario inicia la generación de una secuencia de comandos mediante e-Tester para grabar su interacción con la aplicación que se estudia. E-Tester registra todos los objetos en cada página web que se ve, y valida estos objetos cuando el script se ejecuta. El script se puede personalizar para utilizar los valores de los archivos de datos como entradas de prueba. Empirix afirma que las secuencias de comandos utilizables prueba puede ser creado sin ningún tipo de codificación que sea. Facilidad de uso es una de las principales características de este producto. Sin embargo, para extender la funcionalidad de scripts registrados, los usuarios pueden utilizar Visual Basic para Aplicaciones (VBA). E-Tester utiliza el entorno de desarrollo de VBA para proporcionar a los usuarios avanzados con script de prueba las funciones de depuración y la capacidad de crear funciones reutilizables. C + +, J + +, VBScript y JavaScript también puede utilizarse para mejorar e-Tester scripts. Scripts de prueba creada con e-Tester también se puede utilizar para la realización de pruebas de rendimiento en Empirix e-carga. Además, E-Tester se integra con e-Manager, la herramienta de gestión de pruebas de Empirix.
2.3.2. RATIONAL FUNCTIONAL TESTER Rational Functional Tester antes conocida como XDE Tester, es una herramienta de prueba que permite a los usuarios grabar, editar y ejecutar scripts de prueba funcional automatizada. Un usuario puede crear y modificar los scripts de prueba utilizando Java o Visual Basic .Net, por lo que algunos conocimientos de programación y la experiencia es esencial. Fue diseñado para probar aplicaciones Java, .Net y aplicaciones Web, mas no en aplicaciones Cliente/Servidor. CARACTERÍSTICAS:
Soporte para pruebas de aplicaciones java, web y visual studio .net basadas en winform: A menudo se le requiere a los equipos de pruebas el evaluar aplicaciones construidas sobre más de una base tecnológica. Provee el mismo soporte robusto de automatización para aplicaciones construidas usando tecnología Java, HTML/DHTML y Visual Studio .NET en WinForm.
13
Ejecución de pruebas
2011
Elección del lenguaje - java o visual basic .net - para la customización de los test script: La customización de los test scripts es mandatorio en orden a realizar algún test que no sea el más básico. Rational Functional Tester da la opción de seleccionar entre lenguajes poderosos de scripting para hacerlo posible, siendo las posibilidades tanto Java como Visual Basic .NET - ambas opciones pueden ser usadas con todas las tecnologías de interfaz de usuario soportadas. Al trabajar con el Functional Tester, los testeadores aprenden rápidamente a trabajar con construcciones básicas del lenguaje adquiriendo experiencia de programación que facilitará una comunicación más productiva con los desarrolladores. Editor y debugger nativos para testeadores avanzados java y visual basic .net: Esta herramienta proporciona opciones más fuertes de la industria para estos fines, los testeadores que usan Java pueden trabajar con el Eclipse Java Development Toolkit (JDT), y los que usan Visual Basic .NET pueden hacerlo en Visual Studio .NET . Ambos ambientes integrados de desarrollo ofrecen una gran cantidad de opciones para simplificar la optimización de los test, incluyendo una característica útil de completamiento del código que sugiere la sentencia para acelerar la edición. Los desarrolladores GUI encontrarán esta característica particularmente útil, ya que podrán accederla desde la misma interfaz a la que acceden para construir la interfaz de usuario. Tecnología scriptassure para adecuar los cambios frecuentes a las interfaces de usuario: Los cambios frecuentes a la interfaz de usuario de las aplicaciones pueden desbaratar las pruebas que involucran asunciones respecto a la forma en que se identificarán los objetos de la interfaz durante el playback. Permite a los probadores automatizar las pruebas de forma flexible cuando se realizan cambios frecuentes en la interfaz de usuario de las aplicaciones con la tecnología ScriptAssure. Correlación automatizada de datos y testing orientado al dato eliminando la necesidad de codificación manual: Las pruebas funcionales generalmente necesitan de variar los datos para simular adecuadamente los usuarios reales. Rational Functional Tester puede detectar automáticamente los datos ingresados durante la grabación del test y preparar el test para orientarlo a los datos. Usando una hoja de cálculo como editor de datos, de esta manera se pueden crear juegos de datos customizados para ser insertados dentro del script durante el playback. De esta manera, se pueden producir pruebas altamente personalizados sin codificación manual. Soporte para ejecución y edición de test bajo linux: Para los testeadores interesados en Java, Rational Functional Tester ofrece capacidad de scripting
14
Ejecución de pruebas
2011
para crear, editar y ejecutar pruebas sobre plataforma Linux - incluyendo todo excepto el grabador de test. También soporta la plataforma Windows para todas las capacidades de grabación, edición y ejecución.
2.3.3. QUICK TEST PRO Herramienta para realizar pruebas automatizadas, es tan fácil de usar como el WinRunner. Muchas de las cosas que requiere de la escritura de código en WinRunner, como agregar bucles IF a los scripts de pruebas automatizadas se pueden realizar a través del Quick Test Pro que es una funcionalidad integrada y no existe la necesidad de escribir el código. Funcionalidad que permite a individuos con poca o sin conocimiento de programación podrá hacer uso de esta herramienta.
2.3.4. RATIONAL ROBOT El objetivo de IBM Rational Robot es facilitar la creación y ejecución de scripts automatizados para probar la funcionalidad de una aplicación mediante la simulación de un usuario que interactúa con la interfaz gráfica de la aplicación. Rational Robot también permite a los usuarios crear datapools, que vienen a ser un conjunto de datos de prueba que pueden ser utilizados por los scripts automatizados para variar los valores de entrada durante la ejecución del script. CARACTERÍSTICAS:
Brinda soporte a múltiples tecnologías de interfaz de usuario (ui) para cualquier entorno, desde Java y la web hasta todos los controles de VS.NET, incluidos VB.NET, J#, C# y C++ gestionado. Incluye herramientas para administración de Pruebas y está integrado al las soluciones propuestas en el Rational Unified Process para el seguimiento de defectos, administración de cambios y trazabilidad de requerimientos.
15
Ejecución de pruebas
2011
Simplifica la configuración de pruebas - Rational Robot puede usarse para distribuir las pruebas funcionales entre varias máquinas, cada una de ellas configurada en forma diferente. Se pueden correr simultáneamente los mismas Pruebas funcionales, reduciendo el tiempo necesario para identificar los problemas con configuraciones específicas. Asegura la Profundidad de las pruebas - Prueba más allá de la interfaz de usuario de la aplicación los cientos de propiedades de los objetos componentes de la misma - tales como Controles ActiveX , OCXs, applets Java y muchos otros - con solo un click. Prueba los controles y objetos usuales - Rational Robot permite hacer pruebas a cada componente de la aplicación bajo variadas condiciones proveyendo casos de prueba para menús, listas, caracteres alfanuméricos, bitmaps y muchos otros objetos. Facilita el rehúso - Rational Robot permite que los mismas pruebas de scripts, sin ninguna modificación, se pueden rehusar para probar una aplicación que corre sobre Microsoft Windows XP, Windows, ME, Windows 2000, Windows 98 o Windows NT. Ayuda a analizar rápidamente los problemas - Rational Robot registra automáticamente los resultados del test en el Rational Repository integrado y colorea el código par un rápido análisis visual. Haciendo doble clic sobre una entrada, se posiciona directamente sobre la línea correspondiente de la prueba de script, asegurando en consecuencia un rápido análisis y corrección de los errores del test script.
2.3.5. TESTPARTNER TestPartner de Compuware es una herramienta que permite a los usuarios para crear scripts automatizados de prueba que valide funcionalidad de la aplicación que se está probando. CARACTERÍSTICAS:
Puede ser utilizado para probar web y las aplicaciones cliente / servidor. TestPartner también tiene una funcionalidad integrada que permite a los usuarios probar los sistemas SAP. TestPartner scripts se crean utilizando Microsoft Visual Basic para Aplicaciones (VBA), que es un lenguaje no propietario que tiene una base de usuarios bastante grande fuera del campo de pruebas de software automatizadas. TestPartner también proporciona algunas de las características del entorno de Microsoft VBA, incluida la asistencia con la depuración y la información sobre las variables de tiempo de ejecución. Wizards están disponibles para ayudar a
16
Ejecución de pruebas
2011
crear los controles que los artículos validar tales como propiedades de objetos y datos del sistema. TestPartner también tiene la capacidad para probar el lado del cliente y los objetos del lado del servidor COM, que permite las pruebas para comenzar antes de interfaz de la aplicación se está probando se ha creado.
2.3.6. WINRUNNER WinRunner es una herramienta empresarial para pruebas funcionales que asegura que los procesos de negocio funcionen perfectamente la primera vez y mantiene la fiabilidad. Consiste en capturar, reproducir y verificar las interacciones entre usuarios de forma automática, con el fin de identificar los defectos y determinar si los procesos de negocio trabajan como fue diseñado.
ETAPAS DE PRUEBA DEL WINRUNNER: 1. CREACIÓN DE PRUEBAS: Crear pruebas con la grabación y la programación. Mientras se realizan las pruebas de grabación, se puede añadir puntos de control para comprobar el comportamiento de la aplicación. 2. PRUEBAS DE FUNCIONAMIENTO: Mientras se ejecuta una prueba, WinRunner emula un usuario humano mediante la utilización del mouse y teclado en la aplicación. 3. ANÁLISIS DE LOS RESULTADOS DE LA PRUEBA: Cuando una ejecución de prueba termina, WinRunner realiza una lista de todos los eventos importantes que tuvieron lugar durante la realización de la prueba, tales como puntos de control, los errores o mensajes.
17
Ejecución de pruebas
2011
3. CASOS DE PRUEBA 3.1. CONCEPTO Según la IEEE, estándar 610 define un caso de prueba como “Conjunto de entrada de prueba, condición de ejecución, y resultado esperado desarrollados para un objetivo en particular, como el ejercicio de una ruta de programa en particular o para verificar el cumplimiento de un requisito específico, y como documentación que especifique las entradas, los resultados previos, y un conjunto de condiciones de ejecuciones de un elemento de prueba” . A partir de esta definición, se puede deducir acerca de los casos de pruebas:
Los casos de prueba se utilizan para la ejecución de una prueba en un producto de software. Los casos de prueba se compone de entradas de usuario que se proporcionan a la aplicación y el procedimiento para la ejecución del caso de prueba durante la prueba. Prueba de detalle de los casos los resultados esperados desde el software cuando la prueba se ejecuta con los insumos especificados por el usuario. Los casos de prueba son específicos de un artefacto de código de software o una clase de artefactos de código de software. Los casos de prueba de facilitar y asegurar el cumplimiento de los artefactos de código de software con un requisito específico. Los casos de prueba están documentados.
La práctica habitual es el de documentar los casos de prueba en una hoja de cálculo como Microsoft Excel o en una herramienta como TestPal. (Esta herramienta está disponible como descarga gratuita desde la Web de descarga de Valor Agregado en el Centro de Recursos www.jrosspub.com). La práctica general es el de documentar los casos de prueba para un componente de software (artefacto de código de software) en un documento. (Ver figura 3.1)
18
Ejecución de pruebas
2011
Figura 3.1. Formato de definición casos de prueba
Una tabla de condiciones es otra manera de describir los casos de prueba. Una tabla de condiciones describe el comportamiento del sistema para diferentes combinaciones de insumos. Por ejemplo, en una pantalla de registro, el usuario introduce un nombre de usuario y una contraseña y haga clic ya sea en el botón Aceptar o el botón Cancelar. Cuando el botón se hace clic en Cancelar, el diario de la acción debe ser cancelada, pero cuando el usuario hace clic en el botón Aceptar, el sistema se comporta como se describe en la Figura 3.2.
Figura 3.2. Tabla de condición para una pantalla de registro
19
Ejecución de pruebas
2011
El diseño de casos de prueba es muy importante en las pruebas de software. Diseñados adecuadamente los casos de prueba pueden descubrir todos los defectos y mal diseñado los casos de prueba, dejando defectos residuales en el producto de software.
3.2.OBJETIVOS El objetivo del diseño de casos de prueba es descubrir todos los defectos que acechan en el software y para poner a prueba todo el software completo, con la minimización de la restricción quede esfuerzo y tiempo. Los casos de prueba deben derivarse de los artefactos de software de información. En la siguiente figura se mostrara la lista de artefactos que ayudan la obtención de un caso de prueba. (Ver figura 3.3)
Figura 3.3. Información de los artefactos del software que asisten en derivados de caso de pruebas
El número de casos de prueba para ser diseñado y documentado es bastante grande. Considere las siguientes implicaciones en el diseño de casos de prueba:
Por cada entrada de datos numérico (incluido los datos de tipo fecha), cinco casos de pruebas, usando el particionamiento y técnica de análisis del valor limite. Verificar que el tamaño debe ser realizada por todo los datos no numéricos, uno por cada elemento. Todos los datos no numéricos deben ser evaluados para verificar que han sido introducido y que el área de entrada no se deja en blanco.
20
Ejecución de pruebas
2011
Las pruebas de lógica es necesaria para comprobar la presencia de datos no validos, como dos puntos decimales en tipo numérico, numérico y caracteres especiales en el campo de nombre, etc.
Por lo tanto, el caso de prueba para establecer incluso una unidad de complejidad moderada es enorme. Los proyectos modernos son de gran tamaño, y el esfuerzo requerido para preparar exhaustivamente un conjunto de caso de prueba sea muy amplio. Por esta razón, es común para preparar los casos de prueba donde se espera que el probador no pueda entender intuitivamente los casos de prueba en si mismo. Según las guías de pruebas es de uso general para los siguientes tipos de pruebas de software:
Prueba GUI.
Prueba de navegación (entorno web).
Prueba negativas.
Prueba de carga.
Prueba de estrés.
Prueba paralelo y concurrente.
Las organizaciones utilizan estas directrices para evitar tener que preparar los casos de prueba exhaustiva. Las pruebas de integración, pruebas del sistema, y las pruebas de aceptación que normalmente se llevan a cabo contra los casos de prueba.
3.3.TECNICAS DE PRUEBAS Describimos una serie de técnicas de pruebas que el Analista de Pruebas puede emplear en el diseño y desarrollo de casos de pruebas efectivas. Las técnicas de pruebas están organizadas en:
3.3.1. TECNICAS DE PRUEBAS GENERALES: 3.3.1.1.
PRUEBA POSITIVA
Prueba de positivo en las pruebas del software tal como se especifica y no trata de acciones que no se espera de un usuario sincera, para asegurarse de que todas las funciones definidas es el esperado. No está diseñado para descubrir defectos en el software.
21
Ejecución de pruebas
2011
La prueba positiva se realiza principalmente durante los clientes y usuarios finales las pruebas de aceptación, pruebas funcionales y pruebas de extremo a extremo. Se lleva a cabo sobre la base de casos de prueba diseñados para demostrar que el producto de software está trabajando según lo previsto. Este tipo de pruebas se utiliza justo antes de la entrega de un producto a los clientes, para asegurar que el producto está funcionando.
3.3.1.2.
PRUEBA NEGATIVA
La prueba negativo implica el uso del software de una manera en la que no se espera que sea utilizado, lo que revela todos los otros defectos ocultos no relacionados directamente con la funcionalidad definida en el software. Esto es para asegurar que incluso el uso malicioso no afectará el software o la integridad de los datos. Con el advenimiento de sistemas de eventos activados por software, las pruebas negativas se han convertido en muy importante. Cada control en la pantalla, como un cuadro de texto, cuadro combinado, cuadro de lista, etc., tiene un gran número de eventos asociados. Por ejemplo, haga clic, doble clic, cambiar, ratón arriba, ratón abajo, tiene el foco, perdido el foco, presione la tecla, tecla, tecla, etc. están asociados con un cuadro combinado. Se tiene mucho cuidado en el código de control para que la acción del usuario de la activación de un evento es validado por un segmento de código y los fracasos se previenen. Las pruebas negativas desentierran prueba deficiencias en el software centrado en el manejo de errores y facilita la mejora del software para que las fallas inesperadas no se produzcan en las instalaciones del cliente. Recomiendo llevar a cabo esta prueba en todos los productos de software, ya sea en el escenario del proyecto o producto escenario.
3.3.1.3.
PRUEBA DE CAJA NEGRA
En las pruebas de caja negra, el software es tratado como un "caja negra", y su lógica interna para el procesamiento de los datos no se considera. Un conjunto de entradas se introduce en el software y los productos entregados por el software se comparan con los resultados esperados. Para utilizar esta técnica, el auditor considera que la funcionalidad del software y administra la prueba. La prueba de caja negra es representada de la siguiente manera. (Ver figura 3.4)
22
Ejecución de pruebas
2011
Figura 3.4. La prueba de caja negra
La prueba de caja negra normalmente se lleva a cabo desde la interfaz de usuario o la línea de comandos. El programa se invoca, y los insumos necesarios se dan en el software para que los procesos de los datos de prueba y las entradas del usuario para generar resultados que se pueden comparar con los resultados esperados. Esto determina si el software funcionaba correctamente. La eficacia de las pruebas de caja negra depende del cuidado con que los casos de prueba y datos de prueba están diseñados. Si los casos de prueba se completan, la prueba es exhaustiva y tiene una mejor oportunidad de detectar anomalías en el software.
3.3.1.4.
PRUEBA DE CAJA BLANCA
La prueba de caja blanca considera las declaraciones de lógica interna y el programa del software. Se trata de pasar a través de cada línea de código y de todas las ramas en el código. Para utilizar esta técnica, el auditor debe tener conocimiento en el lenguaje de programación de software y debe entender la estructura del programa. La prueba de caja blanca se asegura de que todas las declaraciones de los programas y todas las estructuras de control se ponen a prueba al menos una vez. La prueba de caja blanca es representada de la siguiente manera. (Ver figura 3.5)
23
Ejecución de pruebas
2011
Figura 3.5. La prueba de caja blanca
La prueba de caja blanca puede llevarse a cabo desde la línea de comandos, la interfaz de usuario, o desde el programa. Si la prueba se lleva a cabo desde la línea de comandos o la interfaz de usuario, la exhaustividad de la prueba depende de los casos de prueba para recorrer a través de cada ruta en el software. La otra forma es la realización de pruebas de caja blanca con el entorno de desarrollo interactivo (IDE) o un depurador de lenguaje específico. Esta herramienta ha facilitado para realizar lo siguiente:
3.3.1.5.
Paso a través de cada línea de código. Establecer puntos de interrupción en el código en la ejecución espera a que el probador para reanudar la ejecución. Establecer el valor inicial o cambiar el valor de las variables o constantes, sin la necesidad de cambiar el programa. Recorrer a través de todos los caminos de las estructuras de control de configurar dinámicamente los valores de la variable de control. Detener la ejecución en cualquier punto en el programa y continuar con las pruebas desde el principio o en cualquier parte del programa. Mover la ejecución de cualquier punto a cualquier otro punto en el programa.
ADIVINAR ERRORES
Como es generalmente aceptado que las pruebas exhaustivas de todos los escenarios posibles no son prácticas, las organizaciones tratan de garantizar un producto libre de defectos de diseño de casos de prueba para estos casos, si los defectos son posibles. Por lo general, una guía para adivinar el error se ha desarrollado. En esta técnica, el diseñador de caso de prueba utiliza la experiencia,
24
Ejecución de pruebas
2011
la intuición y el sentido común para diseñar casos de prueba que puedan detectar errores. Como su propio nombre indica, hay una cierta cantidad de errores por adivinar involucrados, lo que significa que los ingenieros de software son propensos a cometer errores. Usando esta técnica sin duda requiere de muchos años de experiencia en el desarrollo y pruebas de software. Algunos ejemplos de áreas en un campo de fecha en que los errores pueden ocurrir incluyen una fecha no válida como el 30 de febrero entró en un conjunto de 13 meses o un año malo como el 9999 entró.
3.3.1.6.
PRUEBA DE SOFTWARE AUTOMATIZADO
Aunque estrictamente hablando no es una técnica de prueba, las pruebas automatizadas se incluyen en este apartado, ya que puede proporcionar una solución de pruebas eficaces. Una ventaja importante en esta prueba es su capacidad para operar sin supervisión (por ejemplo, para ejecutar durante la noche o el fin de semana), que proporciona ganancias significativas en productividad para la tarea de comprobación. Las herramientas automatizadas también pueden generar una confianza adicional en la automatización, permitiendo más pruebas para ser ejecutado en el momento mismo que el dado por una prueba manual equivalente.
3.3.2. TECNICAS DE PRUEBAS FUNCIONALES: 3.3.2.1.
EQUIVALENCIA DE PARTICIONAMIENTO
El espacio de entrada se divide en entradas válidas y entradas no validas. Un ejemplo ilustrará esta técnica. (Ver figura 3.6)
Figura 3.6. Equivalencia de particionamiento
En una aplicación de los recursos humanos, la edad del empleado puede ser de un mínimo de 16 (edad laboral mínima) y un máximo de 65 (la edad de jubilación). La
25
Ejecución de pruebas
2011
partición de valores válidos es de entre 16 y 65 años. Hay dos particiones de datos inválidos uno por debajo de 16 y otro de 65 años. Por lo tanto, hay tres particiones en este caso - un válido y dos inválidos. Un caso de prueba se puede diseñar para cada partición, lo que resulta en tres casos de prueba.
3.3.2.2.
ANALISIS DEL VALOR LÍMITE
Mostrando con el ejemplo de las particiones (ver figura 3.7) hay dos límites: la edad mínima para el empleo y la edad máxima para el empleo (edad de jubilación)
Figura 3.7. Análisis del valor limite
Estos dos límites: 16 y 65 deben ser aceptadas, y todos los valores por debajo de 16 y mayores de 65 debe ser rechazada. Por lo tanto, los casos de prueba están diseñados, que combinan las técnicas de partición de equivalencia y análisis del valor límite. En este ejemplo, hay cinco casos de prueba:
Un valor entre 16 y 65 - valor válido.
Un valor en el límite inferior de 16 - valor válido.
Un valor justo por debajo del límite inferior (es decir, menos de 16) - valor no válido (por lo general este valor se le daría como un día menos de 16).
Un valor en el límite superior de 65 un valor válido.
Un valor justo por encima del límite superior (es decir, mayor que 65) - valor no válido (por lo general este valor se le daría como 65 años y 1 día).
26
Ejecución de pruebas
2011
4. CLASES DE EQUIVALENCIA 4.1.DEFINICIÓN Una clase de equivalencia representa un conjunto de estados válidos o no válidos para condiciones de entrada. Típicamente, una condición de entrada es un valor numérico específico, un rango de valores, un conjunto de valores relacionados o una condición lógica. Si un conjunto de objetos puede unirse por medio de relaciones simétricas, transitivas y reflexivas, entonces existe una clase de equivalencia.
4.2.DIRECTRICES Las clases de equivalencia se pueden definir de acuerdo con las siguientes directrices: 1. Si una condición de entrada especifica un rango, se define una clase de equivalencia válida y dos no válidas. 2. Si una condición de entrada requiere un valor específico, se define una clase de equivalencia válida y dos no válidas. 3.
Si una condición de entrada requiere un valor específico, se define una clase de equivalencia válida y dos no válidas.
4. Si una condición de entrada es lógica, se define una clase de equivalencia válida y una no válida.
4.3.PARTICIÓN EQUIVALENTE 4.3.1. DEFINICIÓN La partición equivalente es un método de prueba de caja negra que divide el campo de entra de un programa en clases de datos de los que se pueden derivar casos de prueba. Un caso de prueba ideal descubre de forma inmediata una clase de errores (por ejemplo proceso incorrecto de todos los datos de carácter) que, de otro modo requerirían la ejecución de muchos casos antes de detectar el error genérico. La partición equivalente se dirige a la definición de casos de prueba que descubran clases de errores, reduciendo así el número total de casos de prueba que hay que desarrollar.
4.3.2. ¿QUÉ PASOS SEGUIR? En el diseño de casos de prueba para partición equivalente se procede en dos pasos:
27
Ejecución de pruebas
2011
1. Se identifican las clases de equivalencia. Las clases de equivalencia son identificadas tomando cada condición de entrada (generalmente una oración o una frase en la especificación) y repartiéndola en dos o más grupos. Es de notar que dos tipos de clases de equivalencia están identificados: las clases de equivalencia válidas representan entradas válidas al programa, y las clases de equivalencia no válidas que representan el resto de los estados posibles de la condición (es decir, valores erróneos de la entrada). 2. Se define los casos de prueba. El segundo paso es el uso de las clases de equivalencia para identificar los casos de prueba. El proceso es como sigue: se asigna un número único a cada clase de equivalencia. Hasta que todas las clases de equivalencia válidas han sido cubiertas por los casos de prueba, se escribe un nuevo caso de prueba que cubra la clase de equivalencia válida. Y por último hasta que los casos de prueba hayan cubierto todas las clases de equivalencia inválidas, se escribe un caso de la prueba que cubra una, y solamente una, de las clases de equivalencia inválidas descubiertas.
4.3.3. EJERCICIO DE PRUEBA DE CAJA NEGRA – CLASES DE EQUIVALENCIA 4.3.3.1.
ENUNCIADO
Considere una aplicación bancaria, donde el usuario puede conectarse al banco por internet y realizar una serie de operaciones bancarias. Una vez accedido al banco con las consiguientes medidas de seguridad (clave de acceso y demás), la información de entrada del procedimiento que gestiona las operaciones concretas a realizar por el usuario requiere las siguientes entradas:
Código del banco: En blanco o número de tres dígitos. En este caso, el primero de los dígitos tiene que ser mayor que 1.
Código de sucursal: Un número de cuatro dígitos. El primero de ellos mayor de 0.
Número de cuenta: Número de cinco dígitos.
Clave personal: Valor alfanumérico de cinco posiciones.
Orden: En este valor se introducirá según la orden que se desee realizar. Puede estar en blanco o se una de las dos cadenas siguientes: o
“Talonario”
o
“Movimientos”
28
Ejecución de pruebas
2011
En el primer caso el usuario recibirá un talonario de cheques, mientras que en el segundo recibirá los movimientos del mes en curso. Si este código está en blanco, el usuario recibirá los dos documentos.
4.3.3.2.
SOLUCIÓN
Siguiendo los pasos de la partición equivalente, como primer paso identificaremos las clases de equivalencia para este ejercicio, tal como se muestra en la tabla. Cada una de las clases ha sido numerada para facilitar después la realización de los casos de prueba. Condición de Entrada Código banco
Tipo
Clase Equivalencia Válida
Clase Equivalencia no Válida
Lógica (puede estar o no) Si está es Rango Rango
1. En blanco 2. 100<=Código banco<=999
Nº cuenta
Valor
9. Cualquier número de 5 dígitos
10. Número de menos de cinco dígitos 11. Número de menos de cuatro dígitos
Clave
Valor
12. Cualquier cadena de caracteres alfanuméricos de 5 posiciones
Orden
Conjunto, con comportamiento distinto
15. “” 16. “Talonario” 17. “Movimientos”
13. Cadena de menos de cinco posiciones 14. Cadena de más de cinco posiciones 18. Cadena distinta de blanco y de las válidas 19. “Talonarios” 20. “Movimiento”
Código sucursal
6. 1000<=Código sucursal<=9999
3. 4. 5. 7. 8.
Un valor no numérico Código banco<100 Código banco>999 Código sucursal<1000 Código sucursal>=9999
Tabla1. Clases de Equivalencia
Para generar los casos de prueba, consideremos la técnica de Análisis de Valores Límite. Esta técnica conduce a que determinadas clases de equivalencia se genere más de un caso de prueba. Este es el caso por ejemplo, de la clase de equivalencia 2 y 6 que representan un rango de valores y para los que la técnica de Análisis de Valores Límite indica que se generen dos casos de prueba con el límite inferior y el superior del rango respectivamente (para identificar estos casos de prueba se ha añadido el sufijo a y b a las clases de equivalencia correspondiente). Los casos de prueba resultantes se muestran en la tabla.
29
Ejecución de pruebas
Nº Caso 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15
Clase de Banco Equivalencia 1, 6a, 9a, 12a, 15 2a, 6b, 9b, 12b, 16 2b, 6, 9, 12, 17 3, 6, 9, 12, 15 4, 6, 9, 12, 15 5, 6, 9, 12, 15 1, 7, 9, 12, 15 1, 8, 9, 12, 16 1, 6, 10, 12, 16 1, 6, 11, 12, 16 1, 6, 9, 13, 16 1, 6, 9, 14, 16 1, 6, 9, 12, 18 1, 6, 9, 12, 19 1, 6, 9, 12, 20
2011
Sucursal
Cuenta
Clave
Orden
Resultado
-
1000
00000
00000
“”
Todos los movimientos y talonario
100
9999
99999
zzzzz
“Talonario”
Envío de talonario
999
1001
12345
Hyu56
“Movimientos”
Envío de movimientos
30A 99 1000 -
1989 1989 1989 999 10000
12347 12347 12347 12347 12345
Kuh98 Kuf98 Abc80 Def85 Hyu56
“” “” “” “” “Talonario”
Código banco erróneo Código banco erróneo Código banco erróneo Código sucursal erróneo Código sucursal erróneo
-
2345
9999
Jkgy5
“Talonario”
Número cuenta erróneo
-
7863
100000
Jkgy5
“Talonario”
Número cuenta erróneo
-
6754 9998 8765 7654 8769
89765 89765 89765 89765 89765
Jut8 Jut890 Gar78 Gar78 Gar78
“Talonario”
Clave errónea Clave errónea Orden errónea Orden errónea Orden errónea
“Talonario”
988 “Talonarios” “Movimiento”
Tabla2. Casos de Pruebas
30
Ejecución de pruebas
2011
5. INFORME Y SEGUIMIENTO DE PRUEBAS 5.1.DOCUMENTACIÓN EN EL PROCESO DE PRUEBAS En un proyecto de desarrollo de software existe un conjunto de documentos asociados a cada una de las fases del ciclo de vida: planificación, análisis, diseño, construcción, pruebas, etc. Podemos considerar el proceso de pruebas como un proyecto que se ejecuta en paralelo con el desarrollo y en el que se pueden distinguir tres grandes etapas: Preparación de las pruebas. Ejecución de las pruebas. Finalización de las pruebas.
En cada una de estas fases hay que generar la documentación apropiada, lo cual puede ser complicado si no se tiene una referencia adecuada. Para proporcionar una base estándar para la documentación del proceso de pruebas se creó la norma IEEE 829. IEEE 829 propone una serie de documentos que encajan en las etapas de prueba de la siguiente forma:
Preparación de las pruebas. Plan de pruebas. o Especificación de diseño de pruebas. o Especificación de casos de prueba. o o Especificación de procedimientos de prueba. o Informe de transferencia de elementos de prueba. Ejecución de las pruebas. o Registro de pruebas. o Informe de incidentes. Finalización de las pruebas. Informe de resumen de pruebas. o
Aunque el estándar hace referencia a documentos distintos, en la práctica no tienen porqué ser documentos físicos separados. Incluso en muchas ocasiones, gran parte de la información no residirá en documentos, sino en herramientas orientadas a soportar el proceso de pruebas. Por otro lado, no todos los proyectos requieren el mismo grado de formalidad en la documentación del proceso de pruebas: seguramente no tendrá el mismo rigor documental un proyecto de un software médico que uno sobre la construcción de un sencillo sitio web. Otros factores como la cultura y política de la empresa pueden influir en la formalidad de la documentación. Podemos mencionar que los elementos imprescindibles en el proceso de pruebas y los cuales serán usados durante todo el proceso son los siguientes: o
El plan de prueba:
31
Ejecución de pruebas
o
o
o
o
2011
Describe todos los métodos que se utilizarán para verificar que el software satisface la especificación del producto y las necesidades del cliente. Incluye los objetivos de calidad, necesidades de recursos, cronograma, asignaciones, métodos, etc. Casos de prueba: Lista los ítems específicos que serán probados y describe los pasos detallados que serán seguidos para verificar el software. Reporte de bugs: Describen los problemas encontrados al ejecutar los casos de prueba. Herramientas de pruebas y automatización: Documentación de las herramientas empleadas en el proceso de pruebas. Métricas, estadísticas y resúmenes: Indican como ha sido el progreso del proceso de prueba. Toman la forma de gráficos, tablas e informes escritos.
5.1.1. DOCUMENTACIÓN EN LA PREPARACION DE LAS PRUEBAS La fase de preparación de las pruebas es la que más documentación requiere ya que implica definir aspectos como el calendario de pruebas, qué se quiere probar, cómo se va a probar, sobre qué entorno de pruebas, etc. El primer paso en la documentación del proceso de pruebas es la creación del plan de pruebas como se ve en la figura 5.1.
Figura5.1. Documentación relacionada en la Preparación de las pruebas según IEEE
32
Ejecución de pruebas 5.1.1.1.
2011
PLAN DE PRUEBAS
El plan de pruebas constituye el plan maestro que va a dirigir los esfuerzos de pruebas de un proyecto determinado. Un plan de pruebas debe contemplar los siguientes aspectos:
Qué elementos y funcionalidades del producto software van a ser probados (y cuáles no), es decir el alcance de las pruebas. Quién va a realizar las pruebas (asignar responsabilidades) y qué recursos se necesitan en cuanto a personas, software, hardware y formación. La planificación de las tareas de pruebas, con sus dependencias, calendario, duración, etc. Los tipos de pruebas a realizar (de componentes, de integración, etc.) y las técnicas elegidas para diseñar las pruebas, así como el nivel de cobertura y los criterios de salida. Es decir los aspectos relativos a la calidad de las pruebas. Los principales riesgos a tener en cuenta, en especial las circunstancias bajo las cuales se parará o se reiniciará el proceso de pruebas.
ESTRUCTURA FIJADA EN EL ESTÁNDAR Según el estándar IEEE 829 la estructura que debería contener nuestro plan de pruebas debería ser la siguiente: A. Identificador único del documento (para la gestión de configuración). B. Introducción y resumen de elementos y características a probar. C. Elementos software que se van a probar (por ejemplo, programas o módulos). D. Características que se van a probar. E. Características que no se prueban. F. Enfoque general de la prueba (actividades, técnicas, herramientas, etc.). G. Criterios de paso/fallo para cada elemento. H. Criterios de suspensión y requisitos de reanudación. I. Documentos a entregar (como mínimo, los descritos en el estándar). J. Actividades de preparación y ejecución de pruebas. K. Necesidades de entorno. L. Responsabilidades en la organización y realización de las pruebas. M. Necesidades de personal y de formación. N. Esquema de tiempos (con tiempos estimados, hitos, etc.). O. Riesgos asumidos por el plan y planes de contingencias para cada riesgo. P. Aprobaciones y firmas con nombre y puesto desempeñado. Q. Glosario
33
Ejecución de pruebas 5.1.1.2.
2011
DOCUMENTO DE ESPECIFICACIÓN DE DISEÑO DE PRUEBAS
La especificación del diseño de pruebas es el primer paso en el desarrollo real de las pruebas. Este documento especifica las características y funcionalidades que se quieren probar del producto software (condiciones de la prueba o requisitos de la prueba) y su priorización, así como los criterios de éxito/fallo de las pruebas. Por ejemplo, en un módulo de gestión de usuarios, las siguientes podrían ser condiciones de prueba: “Un usuario puede darse de alta en el sistema”, “Un usuario puede darse de baja en el sistema”. El documento de especificación de
diseño de pruebas ayuda a determinar en una fase temprana dónde se quieren centrar los esfuerzos de la prueba, de tal forma que después no se malgasten energías en crear casos de prueba para elementos que no merecen la pena. ESTRUCTURA FIJADA POR EL ESTÁNDAR Según el estándar IEEE 829 la estructura que debería contener nuestra especificación de diseño de pruebas debería ser la siguiente: A. Identificador (único) para la especificación. Proporcionar también una referencia del plan asociado (si existe). B. Características a probar de los elementos software (y combinaciones de características). C. Detalles sobre el plan de pruebas del que surge este diseño, incluyendo las técnicas de prueba específica y los métodos de análisis de resultados. D. Identificación de cada prueba: Identificador. Casos que se van a utilizar. Procedimientos que se van a seguir. E. Criterios de paso/fallo de la prueba (criterios para determinar si una característica o combinación de características ha pasado con éxito la prueba o no).
5.1.1.3.
DOCUMENTO DE ESPECIFICACIÓN DE CASOS DE PRUEBA
Las condiciones o requisitos de la prueba suelen estar especificadas de forma muy vaga. Un caso de prueba realiza una especificación más detallada indicando:
Los datos de entrada concretos que hay que utilizar (por ejemplo, “ejecutar
proceso de alta con nombre de usuario “Juan” y contraseña “123”). Cuál es el resultado esperado tras la ejecución de la prueba. Otros elementos relevantes que deben indicar el documento de casos de prueba son:
34
Ejecución de pruebas
2011
Las precondiciones que se han de dar antes de la ejecución del caso de prueba. Por ejemplo, “El usuario con nombre “Juan” no debe existir en el
sistema”.
Interdependencias entre los casos de test. Por ejemplo, si hay un caso de test que crea con éxito un usuario con nombre “Juan”, tendría que ser ejecutado después del caso anterior para que las precondiciones del primero se puedan cumplir.
ESTRUCTURA FIJADA POR EL ESTÁNDAR Según el estándar IEEE 829 la estructura que debería contener nuestra especificación de casos de prueba debería ser la siguiente: A. Identificador único de la especificación. B. Elementos software (p. ej., módulos) que se van a probar: definir dichos elementos y las características que ejercitará este caso. C. Especificaciones de cada entrada requerida para ejecutar el caso (incluyendo las relaciones entre las diversas entradas; p. ej., la sincronización de las mismas). D. Especificaciones de todas las salidas y las características requeridas (p. ej., el tiempo de respuesta) para los elementos que se van a probar. E. Necesidades de entorno (hardware, software y otras como, por ejemplo, el personal). F. Requisitos especiales de procedimiento (o restricciones especiales en los procedimientos para ejecutar este caso). G. Dependencias entre casos (p. ej., listar los identificadores de los casos que se van a ejecutar antes de este caso de prueba).
5.1.1.4. DOCUMENTO DE ESPECIFICACIÓN DE LOS PROCEDIMIENTOS DE PRUEBA Este documento especifica aspectos como:
Los pasos detallados de cómo ejecutar cada test y el orden de ejecución. La configuración exacta del entorno de pruebas.
Por ejemplo, un procedimiento de pruebas podría contener instrucciones como las siguientes:
Paso 1: Recrear la base de datos ejecutando el script “bbdd.sql”.
Paso 2: Cargar usuarios en base de datos con el script “usuarios.sql”.
Paso 3: Acceder a la URL http://pruebas/login Etc.
35
Ejecución de pruebas
2011
ESTRUCTURA FIJADA POR EL ESTÁNDAR Según el estándar IEEE 829 la estructura que debería contener nuestra especificación de los procedimientos de prueba debería ser la siguiente: A. Identificador único de la especificación y referencia a la correspondiente especificación de diseño de prueba. B. Objetivo del procedimiento y lista de casos que se ejecutan con él. C. Requisitos especiales para la ejecución (p. ej., entorno especial o personal especial). D. Pasos en el procedimiento. Además de la manera de registrar los resultados y los incidentes de la ejecución, se debe especificar: La secuencia necesaria de acciones para preparar la ejecución. Acciones necesarias para empezar la ejecución. Acciones necesarias durante la ejecución. Cómo se realizarán las medidas (p. ej., el tiempo de respuesta). Acciones necesarias para suspender la prueba (cuando los acontecimientos no previstos lo obliguen). Puntos para reinicio de la ejecución y acciones necesarias para el reinicio en estos puntos. Acciones necesarias para detener ordenadamente la ejecución. Acciones necesarias para restaurar el entorno y dejarlo en la situación existente antes de las pruebas. Acciones necesarias para tratar los acontecimientos anómalos.
5.1.1.5.
INFORME DE TRANSMISIÓN DE ELEMENTOS DE PRUEBAS
Detrás de este nombre tan complicado se esconde un documento cuyo propósito es describir los elementos que van a entrar en una fase de pruebas. De esta forma los técnicos de pruebas pueden tener la garantía de que los elementos que van a probar están preparados y saben dónde localizarlos.
5.1.2. DOCUMENTACION DURANTE LA EJECUCION DE LAS PRUEBAS Durante la ejecución de las pruebas es fundamental conocer el estado del proceso de prueba, saber qué pruebas se han ejecutado y cuáles quedan pendientes, qué defectos se han encontrado, etc. Para ello, se crean los registros de pruebas (o los también llamados Históricos de pruebas o test log) y los informes de incidentes tal como se muestra en la figura 5.2.
36
Ejecución de pruebas
2011
Figura 5.2. Documentación relacionada durante la Ejecución de las pruebas según IEEE
5.1.2.1.
REGISTRO DE PRUEBAS (HISTÓRICO DE PRUEBAS O TEST LOG)
Un objetivo fundamental del proceso de prueba es proporcionar información acerca del sistema que se está probando. El registro de pruebas documenta los aspectos relativos a la ejecución de las pruebas: qué prueba se han ejecutado, quién y cuándo los ha ejecutado, en qué orden, en qué entorno, si la prueba ha pasado o ha fallado. En este documento es importante también, asociar la información de ejecución de cada prueba con versiones específicas del software en prueba para garantizar la trazabilidad. La información recogida en el registro de pruebas permite conocer el progreso de la fase de ejecución de pruebas y tomar decisiones acerca de si el software está listo para pasar a la siguiente fase. ESTRUCTURA FIJADA EN EL ESTÁNDAR Según el estándar IEEE 829 la estructura que debería contener nuestro registro de pruebas debería ser la siguiente: A. Identificador B. Descripción de la prueba: elementos probados y entorno de la prueba C. Anotación de datos sobre cada hecho ocurrido (incluido el comienzo y el final de la prueba)
37
Ejecución de pruebas
2011
Fecha y hora Identificador de informe de incidente D. Otras informaciones
5.1.2.2.
INFORME DE INCIDENTES
Hay que resaltar la referencia al término “incidente”; un incidente no tiene porqué deberse necesariamente a un defecto en el sistema. Un incidente representa una discrepancia entre los resultados esperados y los resultados obtenidos. Esta discrepancia puede deberse a varios motivos, como un defecto, un error en la especificación de los casos de prueba, una mala interpretación de los requisitos, etc. El informe de incidentes debe contener toda la información necesaria para la identificación y resolución del incidente: entradas utilizadas, resultados esperados, resultados obtenidos, paso del procedimiento en el que se ha producido el incidente, configuración del entorno, valoración del impacto, etc. ESTRUCTURA FIJADA EN EL ESTÁNDAR Según el estándar IEEE 829 la estructura que debería contener nuestro informe de incidentes debería ser la siguiente: A. Identificador B. Resumen del incidente C. Descripción de datos objetivos (fecha/hora, entradas, resultados esperados, etc.) D. Impacto que tendrá sobre las pruebas
5.1.3. DOCUMENTACIÓN PARA LA FINALIZACION DE LAS PRUEBAS Una vez finalizado el proceso de pruebas, se tiene que proporcionar suficiente información para que los involucrados en el proyecto puedan conocer los resultados y tomar decisiones.
5.1.3.1.
INFORME DE RESUMEN DE PRUEBAS
El informe final de pruebas se crea en hitos determinados del proyecto o al finalizar un nivel de pruebas determinado. Permite comunicar a todos los stakeholders los resultados obtenidos para así decidir si el software está listo para pasar a la siguiente fase. Este informe proporciona información sobre las pruebas realizadas y el tiempo consumido, así como valoraciones acerca de la calidad del proceso de prueba realizado, del nivel de calidad alcanzado en el producto. Este informe final puede servir como base para planificar mejoras futuras en el proceso de prueba.
38
Ejecución de pruebas
2011
ESTRUCTURA FIJADA EN EL ESTÁNDAR Según el estándar IEEE 829 la estructura que debería contener nuestro informe de resumen de pruebas debería ser la siguiente: A. Identificador B. Resumen de la evaluación de los elementos probados C. Variaciones del software respecto a su especificación de diseño, así como las variaciones en las pruebas D. Valoración de la extensión de la prueba (cobertura lógica, funcional, de requisitos, etc.) E. Resumen de los resultados obtenidos en las pruebas F. Evaluación de cada elemento software sometido a prueba (evaluación general del software incluyendo las limitaciones del mismo) G. Firmas y aprobaciones de quienes deban supervisar el informe
5.2.SEGUIMIENTO DE LAS PRUEBAS 5.2.1. DEPURACIÓN (DEBUGGING) 5.2.1.1.
DEFINICIÓN
Casi todos los compiladores suelen llevar asociada la posibilidad de ejecutar un programa paso a paso, permitiéndole al operador conocer dónde está en cada momento, y cuánto valen las variables. Los depuradores pueden usarse para realizar inspecciones rigurosas sobre el comportamiento dinámico de los programas. La práctica demuestra, no obstante, que su uso es tedioso y que sólo son eficaces si se persigue un objetivo muy claro. El objetivo habitual es utilizarlo como consecuencia de la detección de un error. Si el programa se comporta mal en un cierto punto, hay que averiguar la causa precisa para poder repararlo. La causa a veces es inmediata (por ejemplo, un operador booleano equivocado); pero a veces depende del valor concreto de los datos en un cierto punto y hay que buscar la causa en otra zona del programa. El depurador es el último paso para convencernos de nuestro análisis y afrontar la reparación con conocimiento de causa.
39
Ejecución de pruebas
2011
Figura 5.3. Proceso de Depuración
5.2.1.2.
CONSEJOS PARA LA DEPURACIÓN
LOCALIZACIÓN DEL ERROR
Analizar la información y pensar. Al llegar a un punto muerto, pasar a otra cosa. Al llegar a un punto muerto, describir el problema a otra persona. Usar herramientas de depuración sólo como recurso secundario. No experimentar cambiando el programa. Se deben atacar los errores individualmente. Se debe fijar la atención también en los datos.
CORRECCIÓN DEL ERROR
Donde hay un defecto, suele haber más. Debe fijarse el defecto, no sus síntomas. La probabilidad de corregir perfectamente un defecto no es del 100%. Cuidado con crear nuevos defectos. La corrección debe situarnos temporalmente en la fase de diseño. Cambiar el código fuente, no el código objeto.
40
Ejecución de pruebas
2011
5.2.2. ¿CUÁNDO PARAR DE PROBAR? ¿Cuándo dejar de probar para una actividad de prueba específica? ¿Cuándo dejar de probar todas las actividades principales? ¿Cuándo dejar de probar y liberar el producto?”
CRITERIOS INFORMALES
Basándonos en criterios de recursos Basándonos en criterios de actividad
CRITERIOS FORMALES
Establecer una meta de confiabilidad durante la planificación de productos y análisis de necesidades
41
Ejecución de pruebas
2011
CONCLUSIÓN Actualmente podemos afirmar que probar es buscarle los fallos a un programa. La fase de pruebas absorbe una buena porción de los costes de desarrollo de software. Además, se muestra renuente a un tratamiento matemático o, simplemente, automatizado. Su ejecución se basa en metodología (reglas que se les dan a los encargados de probar) que se va desarrollando con la experiencia. Es tediosa, es un arte, es un trabajo que requiere una buena dosis de mala intención, y provoca difíciles reacciones humanas. Aunque se han desarrollado miles de herramientas de soporte de esta fase, todas han limitado su éxito a entornos muy concretos, frecuentemente sólo sirviendo para el producto para el que se desarrollaron. Sólo herramientas muy generales como analizadores de complejidad, sistemas de ejecución simbólica y medidores de cobertura han mostrado su utilidad en un marco más amplio. Pero al final sigue siendo imprescindible un artista humano que sepa manejarlas. Así podemos afirmar que las herramientas son importantes pero una herramienta de prueba no es una estrategia ni un proceso ni un plan de prueba. Una herramienta de pruebas sin saber técnicas, prácticas y tener experiencia en pruebas es tan útil como un entorno de programación sin saber el lenguaje.
42
Ejecución de pruebas
2011
RECOMENDACIONES Con lo leído anteriormente se puede recomendar para la ejecución de una prueba exitosa los siguientes puntos:
Cada caso de prueba debe definir el resultado de salida esperado que se comparará con el realmente obtenido. El programador debe evitar probar sus propios programas, ya que desea (consciente o inconscientemente) demostrar que funcionan sin problemas. Además, es normal que las situaciones que olvidó considerar al crear el programa queden de nuevo olvidadas al crear los casos de prueba. Se debe inspeccionar a conciencia el resultado de cada prueba, así, poder descubrir posibles síntomas de defectos. Al generar casos de prueba, se deben incluir tanto datos de entrada válidos y esperados como no válidos e inesperados. Las pruebas deben centrarse en dos objetivos (es habitual olvidar el segundo): Probar si el software no hace lo que debe hacer. Probar si el software hace lo que debe hacer, es decir, si provoca efectos secundarios adversos. Se deben evitar los casos desechables, es decir, los no documentados ni diseñados con cuidado. Ya que suele ser necesario probar muchas veces el software y por tanto hay que tener claro qué funciona y qué no. No deben hacerse planes de prueba suponiendo que, prácticamente, no hay defectos en los programas y, por lo tanto, dedicando pocos recursos a las pruebas siempre hay defectos. La experiencia parece indicar que donde hay un defecto hay otros, es decir, la probabilidad de descubrir nuevos defectos en una parte del software es proporcional al número de defectos ya descubierto. Las pruebas son una tarea tanto o más creativa que el desarrollo de software. Siempre se han considerado las pruebas como una tarea destructiva y rutinaria.
Es interesante planificar y diseñar las pruebas para poder detectar el máximo número y variedad de defectos con el mínimo consumo de tiempo y esfuerzo.
43