Calidad de Software Ing.

Alonso Morales

2011

EJECUCIN DE PRUEBAS

Integrantes:
Alvarado Pachas, Euler Hardy. Orellana Paucar, Rony Eduardo. Quispe Gamboa, Omar Ernesto. Saravia Soto, Jhonathan Vargas Castilla, Kelvin Renzo.

Facultad de Ingeniera de Sistemas

Ejecucin de pruebas 2011

Ejecucin de pruebas 2011

Contenido
INTRODUCCION ............................................................................................................. 5 1. CONCEPTOS INTRODUCTORIOS ............................................................................... 6
1.1. 1.2. 1.3. 1.4. 1.5. DEFINICIONES ............................................................................................................ 6 RELACION ENTRE DEFECTO, FALLA Y ERROR ................................................................ 6 CICLO DE LAS PRUEBAS DE SOFTWARE ........................................................................ 7 QU ES PROBAR? ..................................................................................................... 8 PORQU ES IMPORTANTE HACER PRUEBAS EN NUESTRO SOFTWARE? ....................... 8

2.

EJECUCIN DE PRUEBAS ......................................................................................... 9

2.1. 2.2. 2.3. DEFINICIN................................................................................................................ 9 FASES ...................................................................................................................... 10 HERRAMIENTAS PARA IMPLEMENTAR Y EJECUTAR PRUEBAS .................................... 12
E-TESTER ................................................................................................................................. 12 RATIONAL FUNCTIONAL TESTER............................................................................................. 13 QUICK TEST PRO ..................................................................................................................... 15 RATIONAL ROBOT ................................................................................................................... 15 TESTPARTNER ......................................................................................................................... 16 WINRUNNER........................................................................................................................... 17

2.3.1. 2.3.2. 2.3.3. 2.3.4. 2.3.5. 2.3.6.

3.

CASOS DE PRUEBA ................................................................................................ 18

3.1. 3.2. 3.3. CONCEPTO ............................................................................................................... 18 OBJETIVOS ............................................................................................................... 20 TECNICAS DE 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.................................................................................................... 22 3.3.1.4. PRUEBA DE CAJA BLANCA .................................................................................................. 23 3.3.1.5. ADIVINAR 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 LMITE .............................................................................................. 26

4.

CLASES DE EQUIVALENCIA..................................................................................... 27

Ejecucin de pruebas 2011

4.1. 4.2. 4.3. DEFINICIN.............................................................................................................. 27 DIRECTRICES ............................................................................................................ 27 PARTICIN EQUIVALENTE ........................................................................................ 27

4.3.1. DEFINICIN ............................................................................................................................. 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. SOLUCIN .......................................................................................................................... 29

5.

INFORME Y SEGUIMIENTO DE PRUEBAS ................................................................ 31

5.1. DOCUMENTACIN EN EL PROCESO DE PRUEBAS ....................................................... 31
5.1.1. DOCUMENTACIN EN LA PREPARACION DE LAS PRUEBAS ................................................... 32 5.1.1.1. PLAN DE PRUEBAS ............................................................................................................. 33 5.1.1.2. DOCUMENTO DE ESPECIFICACIN DE DISEO DE PRUEBAS ............................................. 34 5.1.1.3. DOCUMENTO DE ESPECIFICACIN DE CASOS DE PRUEBA ................................................ 34 5.1.1.4. DOCUMENTO DE ESPECIFICACIN DE LOS PROCEDIMIENTOS DE PRUEBA ...................... 35 5.1.1.5. INFORME DE TRANSMISIN DE ELEMENTOS DE PRUEBAS ............................................... 36 5.1.2. DOCUMENTACION DURANTE LA EJECUCION DE LAS PRUEBAS ............................................. 36 5.1.2.1. REGISTRO DE PRUEBAS (HISTRICO DE PRUEBAS O TEST LOG) ........................................ 37 5.1.2.2. INFORME DE INCIDENTES .................................................................................................. 38 5.1.3. DOCUMENTACIN PARA LA FINALIZACION DE LAS PRUEBAS ................................................ 38 5.1.3.1. INFORME DE RESUMEN DE PRUEBAS ................................................................................ 38

5.2.

SEGUIMIENTO DE LAS PRUEBAS ............................................................................... 39

5.2.1. DEPURACIN (DEBUGGING) .................................................................................................. 39 5.2.1.1. DEFINICIN ........................................................................................................................ 39 5.2.1.2. CONSEJOS PARA LA DEPURACIN ..................................................................................... 40 5.2.2. CUNDO PARAR DE PROBAR? .............................................................................................. 41

CONCLUSIN ............................................................................................................... 42 RECOMENDACIONES.................................................................................................... 43 BIBLIOGRAFIA ............................................................................................................. 44

Ejecucin de pruebas 2011

INTRODUCCION
Una de las ltimas fases del ciclo de vida antes de entregar un programa para su explotacin, es la fase de pruebas. Las pruebas de software se aplican como una etapa ms 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 mayora 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 ms crticas del ciclo de vida del desarrollo de software y esto ha causado el origen de diversas metodologas. En la actualidad la prueba de software se hace ms complicada ya que debe hacer frente a una gran cantidad de metodologas de desarrollo, lenguajes de programacin, sistemas operativos, hardware etc. Es por esto que la prueba debe apoyarse en metodologas generales que revisan los aspectos ms fundamentales que debe considerar todo proceso de pruebas. Debido a esta complejidad actualmente se cuentan con una gran cantidad de software diseado exclusivamente para la etapa de pruebas, incluyendo la gestin del proceso de prueba de software, la administracin y seguimiento de errores, la administracin de los casos de prueba, automatizacin de pruebas, etc.

Ejecucin 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 evaluacin de algn aspecto. CASO DE PRUEBA (test case): un conjunto de entradas, condiciones de ejecucin y resultados esperados desarrollados para un objetivo particular. DEFECTO (defect, fault, bug): un defecto en el software como, por ejemplo, un proceso, una definicin 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 tericamente correcto.

1.2.RELACION ENTRE DEFECTO, FALLA Y ERROR

En la figura 1.1 podemos observar graficamente la relacin directa que existe entre las definiciones de defecto, falla y error.

Figura 1.1. Relacin entre Defecto, Falla y Error

Ejecucin de pruebas 2011

As podemos entablar la relacin consecuencial como nos muestra la figura 1.2:

Figura 1.2. Relacin 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

Ejecucin de pruebas 2011 1.4.QU ES PROBAR?

Errneamente, la mayora 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 aade valor al producto que se maneja: todos los programas tienen errores y la fase de pruebas los descubre; ese es el valor que aade. El objetivo especfico de la fase de pruebas es encontrar cuantos ms 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 (quin va a pasar a la seccin 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 fabricacin de programas sea hacer programas que funcionen bien; pero cada fase tiene su objetivo especfico, y el de las pruebas es destapar errores. Probar un programa es ejercitarlo con la peor intencin a fin de encontrarle fallos. DEFINICIN CORRECTA: Probar es el proceso de ejecutar un programa con la intencin de encontr ar errores.

1.5.PORQU ES IMPORTANTE HACER PRUEBAS EN NUESTRO SOFTWARE?

En la cadena de valor del desarrollo de un software especfico, 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 tamao, y por consiguiente tambin en costos. Hoy en da es crucial verificar y evaluar la calidad de lo construido de modo de minimizar el costo de su reparacin. Mientras antes se detecte una falla, ms barata es su correccin. El proceso de prueba es un proceso tcnico especializado de investigacin que requiere de profesionales altamente capacitados en lenguajes de desarrollo, mtodos y tcnicas de pruebas y herramientas especializadas. El conocimiento que debe manejar un ingeniero de prueba es muchas veces superior al del desarrollador de software.

Ejecucin de pruebas 2011

2. EJECUCIN DE PRUEBAS
2.1.DEFINICIN
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 informacin necesaria para la ejecucin de pruebas, el ambiente se preparara y se ejecutan las pruebas. Se ejecutan las pruebas mediante la definicin de las actividades requeridas para ejecutar los requerimientos de pruebas identificados en la fase de diseo de pruebas, reportar los hallazgos y asegurar su correccin por parte del equipo de desarrollo de software.

Figura 2.1. Proceso de Ejecucin de Pruebas

Ejecucin de pruebas 2011

La fase de ejecucin de pruebas se realiza por iteraciones de pruebas. (Total o un subconjunto de los requerimientos de pruebas). En cada iteracin 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 ejecucin, los responsables de pruebas deben ejecutar la mayor cantidad posible de iteraciones y regresiones de prueba hasta poder demostrar grficamente 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 Conformidades

El resultado real de ejecucin debe cumplir con dos caractersticas 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 ejecucin de pruebas segn el estndar IEEE Std. 829, abarca las siguientes fases: Ejecutar las pruebas, cuyos casos y procedimientos han sido ya diseados previamente.

10

Ejecucin de pruebas 2011

Comprobar si se ha concluido el proceso de prueba (segn ciertos criterios de complecin de prueba que suelen especificarse en el plan de pruebas). En el caso que hayan terminado las pruebas, se evalan los resultados; en caso contrario hay que generar las pruebas adicionales para que se satisfagan los criterios de complecin de pruebas. b) El proceso de ejecucin propiamente dicho, consta de las siguientes fases: Se ejecutan las pruebas. Se comprueba si ha habido algn fallo al ejecutar. Si lo ha habido, se puede deber a un defecto del software, lo que nos lleva al proceso de depuracin o correccin del cdigo. Se puede deber tambin a un defecto en el propio diseo de las pruebas. En ambos casos, las nuevas pruebas o las corregidas se debern ejecutar. De no existir fallos, se pasar a la comprobacin de la terminacin de las pruebas. c) Las fases del proceso de comprobacin de la terminacin de las pruebas son: Tras la ejecucin, se comprueba si se cumplen los criterios de complecin de pruebas descritos en el correspondiente plan de pruebas. En caso de terminar las pruebas, se pasa a la evaluacin de los productos probados sobre la base de los resultados obtenidos (terminacin 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 evaluacin; en caso contrario, se pasa a generar y ejecutar pruebas adicionales para satisfacer cualquiera de las dos terminaciones. Los criterios de complecin de pruebas hacen referencia a las reas (caractersticas, funciones, etc.) que deben cubrir las pruebas y el grado de cobertura para cada una de esas reas. Como ejemplos genricos de este tipo de criterios se pueden indicar los siguientes: Se debe cubrir cada caracterstica o requerimiento del software mediante un caso de prueba o una excepcin aprobada en el plan de pruebas. En programas codificados con lenguajes procedurales, se deben cubrir todas las instrucciones ejecutables mediante casos de prueba.

11

Ejecucin de pruebas 2011 2.3.HERRAMIENTAS PARA IMPLEMENTAR Y EJECUTAR PRUEBAS

Sabemos que las pruebas de software es el acto de la ejecucin 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 slo puede resultar montono 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 compaas desarrollaron herramientas automatizadas de prueba. En trminos 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 supervisin necesaria de los seres humanos. Esto permite a los probadores que normalmente ejecutan el script manualmente, automatizar las pruebas para concentrarse en otros aspectos ms interesantes en el desarrollo del software. Ahora estamos a lo largo de varias generaciones en trminos de herramientas de pruebas automatizadas. En su mayor parte, en las primeras generaciones eran difciles de usar, y las secuencias de comandos automatizadas que se utilizan para crear no eran fciles de mantener. Sin embargo, las ltimas herramientas que se han desarrollado son ms fciles de utilizar, de manera que pueda ser utilizado por un mayor nmero de personas que tienen diferentes niveles y tipos de habilidades. En este captulo tratare de explicar cules son las herramientas que se emplean para implementar y ejecutar pruebas funcionales y de regresin, as como ver cules son sus caractersticas. Entre las herramientas ms usadas para realizar pruebas funcionales y de regresin 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 diseado para ser utilizado para probar web, soluciones inalmbricas y aplicaciones multimedia.

12

Ejecucin de pruebas 2011

CMO FUNCIONA? Un usuario inicia la generacin de una secuencia de comandos mediante e-Tester para grabar su interaccin con la aplicacin que se estudia. E-Tester registra todos los objetos en cada pgina 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 ningn tipo de codificacin que sea. Facilidad de uso es una de las principales caractersticas 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 depuracin y la capacidad de crear funciones reutilizables. C + +, J + +, VBScript y JavaScript tambin puede utilizarse para mejorar e-Tester scripts. Scripts de prueba creada con e-Tester tambin se puede utilizar para la realizacin de pruebas de rendimiento en Empirix e-carga. Adems, E-Tester se integra con e-Manager, la herramienta de gestin 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 programacin y la experiencia es esencial. Fue diseado para probar aplicaciones Java, .Net y aplicaciones Web, mas no en aplicaciones Cliente/Servidor. CARACTERSTICAS: 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 ms de una base tecnolgica. Provee el mismo soporte robusto de automatizacin para aplicaciones construidas usando tecnologa Java, HTML/DHTML y Visual Studio .NET en WinForm.

13

Ejecucin de pruebas 2011

Eleccin del lenguaje - java o visual basic .net - para la customizacin de los test script: La customizacin de los test scripts es mandatorio en orden a realizar algn test que no sea el ms bsico. Rational Functional Tester da la opcin 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 tecnologas de interfaz de usuario soportadas. Al trabajar con el Functional Tester, los testeadores aprenden rpidamente a trabajar con construcciones bsicas del lenguaje adquiriendo experiencia de programacin que facilitar una comunicacin ms productiva con los desarrolladores. Editor y debugger nativos para testeadores avanzados java y visual basic .net: Esta herramienta proporciona opciones ms 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 optimizacin de los test, incluyendo una caracterstica til de completamiento del cdigo que sugiere la sentencia para acelerar la edicin. Los desarrolladores GUI encontrarn esta caracterstica particularmente til, ya que podrn accederla desde la misma interfaz a la que acceden para construir la interfaz de usuario. Tecnologa 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 identificarn 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 tecnologa ScriptAssure. Correlacin automatizada de datos y testing orientado al dato eliminando la necesidad de codificacin manual: Las pruebas funcionales generalmente necesitan de variar los datos para simular adecuadamente los usuarios reales. Rational Functional Tester puede detectar automticamente los datos ingresados durante la grabacin del test y preparar el test para orientarlo a los datos. Usando una hoja de clculo 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 codificacin manual. Soporte para ejecucin y edicin de test bajo linux: Para los testeadores interesados en Java, Rational Functional Tester ofrece capacidad de scripting

14

Ejecucin de pruebas 2011

para crear, editar y ejecutar pruebas sobre plataforma Linux - incluyendo todo excepto el grabador de test. Tambin soporta la plataforma Windows para todas las capacidades de grabacin, edicin y ejecucin.

2.3.3. QUICK TEST PRO

Herramienta para realizar pruebas automatizadas, es tan fcil de usar como el WinRunner. Muchas de las cosas que requiere de la escritura de cdigo en WinRunner, como agregar bucles IF a los scripts de pruebas automatizadas se pueden realizar a travs del Quick Test Pro que es una funcionalidad integrada y no existe la necesidad de escribir el cdigo. Funcionalidad que permite a individuos con poca o sin conocimiento de programacin podr hacer uso de esta herramienta.

2.3.4. RATIONAL ROBOT

El objetivo de IBM Rational Robot es facilitar la creacin y ejecucin de scripts automatizados para probar la funcionalidad de una aplicacin mediante la simulacin de un usuario que interacta con la interfaz grfica de la aplicacin. Rational Robot tambin 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 ejecucin del script. CARACTERSTICAS: Brinda soporte a mltiples tecnologas 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 administracin de Pruebas y est integrado al las soluciones propuestas en el Rational Unified Process para el seguimiento de defectos, administracin de cambios y trazabilidad de requerimientos.

15

Ejecucin de pruebas 2011

Simplifica la configuracin de pruebas - Rational Robot puede usarse para distribuir las pruebas funcionales entre varias mquinas, cada una de ellas configurada en forma diferente. Se pueden correr simultneamente los mismas Pruebas funcionales, reduciendo el tiempo necesario para identificar los problemas con configuraciones especficas. Asegura la Profundidad de las pruebas - Prueba ms all de la interfaz de usuario de la aplicacin 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 aplicacin bajo variadas condiciones proveyendo casos de prueba para mens, listas, caracteres alfanumricos, bitmaps y muchos otros objetos. Facilita el rehso - Rational Robot permite que los mismas pruebas de scripts, sin ninguna modificacin, se pueden rehusar para probar una aplicacin que corre sobre Microsoft Windows XP, Windows, ME, Windows 2000, Windows 98 o Windows NT. Ayuda a analizar rpidamente los problemas - Rational Robot registra automticamente los resultados del test en el Rational Repository integrado y colorea el cdigo par un rpido anlisis visual. Haciendo doble clic sobre una entrada, se posiciona directamente sobre la lnea correspondiente de la prueba de script, asegurando en consecuencia un rpido anlisis y correccin 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 aplicacin que se est probando. CARACTERSTICAS: Puede ser utilizado para probar web y las aplicaciones cliente / servidor. TestPartner tambin 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 tambin proporciona algunas de las caractersticas del entorno de Microsoft VBA, incluida la asistencia con la depuracin y la informacin sobre las variables de tiempo de ejecucin. Wizards estn disponibles para ayudar a

16

Ejecucin de pruebas 2011

crear los controles que los artculos validar tales como propiedades de objetos y datos del sistema. TestPartner tambin 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 aplicacin 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 automtica, con el fin de identificar los defectos y determinar si los procesos de negocio trabajan como fue diseado.

ETAPAS DE PRUEBA DEL WINRUNNER: 1. CREACIN DE PRUEBAS: Crear pruebas con la grabacin y la programacin. Mientras se realizan las pruebas de grabacin, se puede aadir puntos de control para comprobar el comportamiento de la aplicacin. 2. PRUEBAS DE FUNCIONAMIENTO: Mientras se ejecuta una prueba, WinRunner emula un usuario humano mediante la utilizacin del mouse y teclado en la aplicacin. 3. ANLISIS DE LOS RESULTADOS DE LA PRUEBA: Cuando una ejecucin de prueba termina, WinRunner realiza una lista de todos los eventos importantes que tuvieron lugar durante la realizacin de la prueba, tales como puntos de control, los errores o mensajes.

17

Ejecucin de pruebas 2011

3. CASOS DE PRUEBA
3.1. CONCEPTO
Segn la IEEE, estndar 610 define un caso de prueba como Conjunto de entrada de prueba, condicin de ejecucin, 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 especfico, y como documentacin que especifique las entradas, los resultados previos, y un conjunto de condiciones de ejecuciones de un elemento de prueba. A partir de esta definicin, se puede deducir acerca de los casos de pruebas: Los casos de prueba se utilizan para la ejecucin de una prueba en un producto de software. Los casos de prueba se compone de entradas de usuario que se proporcionan a la aplicacin y el procedimiento para la ejecucin 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 especficos de un artefacto de cdigo de software o una clase de artefactos de cdigo de software. Los casos de prueba de facilitar y asegurar el cumplimiento de los artefactos de cdigo de software con un requisito especfico. Los casos de prueba estn documentados.

La prctica habitual es el de documentar los casos de prueba en una hoja de clculo 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 prctica general es el de documentar los casos de prueba para un componente de software (artefacto de cdigo de software) en un documento. (Ver figura 3.1)

18

Ejecucin de pruebas 2011

Figura 3.1. Formato de definicin 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 contrasea y haga clic ya sea en el botn Aceptar o el botn Cancelar. Cuando el botn se hace clic en Cancelar, el diario de la accin debe ser cancelada, pero cuando el usuario hace clic en el botn Aceptar, el sistema se comporta como se describe en la Figura 3.2.

Figura 3.2. Tabla de condicin para una pantalla de registro

19

Ejecucin de pruebas 2011

El diseo de casos de prueba es muy importante en las pruebas de software. Diseados adecuadamente los casos de prueba pueden descubrir todos los defectos y mal diseado los casos de prueba, dejando defectos residuales en el producto de software.

3.2.OBJETIVOS
El objetivo del diseo 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 minimizacin de la restriccin quede esfuerzo y tiempo. Los casos de prueba deben derivarse de los artefactos de software de informacin. En la siguiente figura se mostrara la lista de artefactos que ayudan la obtencin de un caso de prueba. (Ver figura 3.3)

Figura 3.3. Informacin de los artefactos del software que asisten en derivados de caso de pruebas

El nmero de casos de prueba para ser diseado y documentado es bastante grande. Considere las siguientes implicaciones en el diseo de casos de prueba: Por cada entrada de datos numrico (incluido los datos de tipo fecha), cinco casos de pruebas, usando el particionamiento y tcnica de anlisis del valor limite. Verificar que el tamao debe ser realizada por todo los datos no numricos, uno por cada elemento. Todos los datos no numricos deben ser evaluados para verificar que han sido introducido y que el rea de entrada no se deja en blanco.

20

Ejecucin de pruebas 2011

Las pruebas de lgica es necesaria para comprobar la presencia de datos no validos, como dos puntos decimales en tipo numrico, numrico 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 tamao, y el esfuerzo requerido para preparar exhaustivamente un conjunto de caso de prueba sea muy amplio. Por esta razn, es comn para preparar los casos de prueba donde se espera que el probador no pueda entender intuitivamente los casos de prueba en si mismo. Segn las guas de pruebas es de uso general para los siguientes tipos de pruebas de software: Prueba GUI. Prueba de navegacin (entorno web). Prueba negativas. Prueba de carga. Prueba de estrs. Prueba paralelo y concurrente.

Las organizaciones utilizan estas directrices para evitar tener que preparar los casos de prueba exhaustiva. Las pruebas de integracin, pruebas del sistema, y las pruebas de aceptacin que normalmente se llevan a cabo contra los casos de prueba.

3.3.TECNICAS DE PRUEBAS
Describimos una serie de tcnicas de pruebas que el Analista de Pruebas puede emplear en el diseo y desarrollo de casos de pruebas efectivas. Las tcnicas de pruebas estn 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 diseado para descubrir defectos en el software.

21

Ejecucin de pruebas 2011

La prueba positiva se realiza principalmente durante los clientes y usuarios finales las pruebas de aceptacin, pruebas funcionales y pruebas de extremo a extremo. Se lleva a cabo sobre la base de casos de prueba diseados para demostrar que el producto de software est trabajando segn 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 nmero de eventos asociados. Por ejemplo, haga clic, doble clic, cambiar, ratn arriba, ratn abajo, tiene el foco, perdido el foco, presione la tecla, tecla, tecla, etc. estn asociados con un cuadro combinado. Se tiene mucho cuidado en el cdigo de control para que la accin del usuario de la activacin de un evento es validado por un segmento de cdigo 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 lgica 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 tcnica, 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

Ejecucin 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 lnea 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 estn diseados. Si los casos de prueba se completan, la prueba es exhaustiva y tiene una mejor oportunidad de detectar anomalas en el software.

3.3.1.4.

PRUEBA DE CAJA BLANCA

La prueba de caja blanca considera las declaraciones de lgica interna y el programa del software. Se trata de pasar a travs de cada lnea de cdigo y de todas las ramas en el cdigo. Para utilizar esta tcnica, el auditor debe tener conocimiento en el lenguaje de programacin 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

Ejecucin de pruebas 2011

Figura 3.5. La prueba de caja blanca

La prueba de caja blanca puede llevarse a cabo desde la lnea de comandos, la interfaz de usuario, o desde el programa. Si la prueba se lleva a cabo desde la lnea de comandos o la interfaz de usuario, la exhaustividad de la prueba depende de los casos de prueba para recorrer a travs de cada ruta en el software. La otra forma es la realizacin de pruebas de caja blanca con el entorno de desarrollo interactivo (IDE) o un depurador de lenguaje especfico. Esta herramienta ha facilitado para realizar lo siguiente: Paso a travs de cada lnea de cdigo. Establecer puntos de interrupcin en el cdigo en la ejecucin espera a que el probador para reanudar la ejecucin. Establecer el valor inicial o cambiar el valor de las variables o constantes, sin la necesidad de cambiar el programa. Recorrer a travs de todos los caminos de las estructuras de control de configurar dinmicamente los valores de la variable de control. Detener la ejecucin en cualquier punto en el programa y continuar con las pruebas desde el principio o en cualquier parte del programa. Mover la ejecucin de cualquier punto a cualquier otro punto en el programa.

3.3.1.5.

ADIVINAR ERRORES

Como es generalmente aceptado que las pruebas exhaustivas de todos los escenarios posibles no son prcticas, las organizaciones tratan de garantizar un producto libre de defectos de diseo de casos de prueba para estos casos, si los defectos son posibles. Por lo general, una gua para adivinar el error se ha desarrollado. En esta tcnica, el diseador de caso de prueba utiliza la experiencia,

24

Ejecucin de pruebas 2011

la intuicin y el sentido comn para disear 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 tcnica sin duda requiere de muchos aos 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 vlida como el 30 de febrero entr en un conjunto de 13 meses o un ao malo como el 9999 entr.

3.3.1.6.

PRUEBA DE SOFTWARE AUTOMATIZADO

Aunque estrictamente hablando no es una tcnica de prueba, las pruebas automatizadas se incluyen en este apartado, ya que puede proporcionar una solucin de pruebas eficaces. Una ventaja importante en esta prueba es su capacidad para operar sin supervisin (por ejemplo, para ejecutar durante la noche o el fin de semana), que proporciona ganancias significativas en productividad para la tarea de comprobacin. Las herramientas automatizadas tambin pueden generar una confianza adicional en la automatizacin, permitiendo ms 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 vlidas y entradas no validas. Un ejemplo ilustrar esta tcnica. (Ver figura 3.6)

Figura 3.6. Equivalencia de particionamiento

En una aplicacin de los recursos humanos, la edad del empleado puede ser de un mnimo de 16 (edad laboral mnima) y un mximo de 65 (la edad de jubilacin). La

25

Ejecucin de pruebas 2011

particin de valores vlidos es de entre 16 y 65 aos. Hay dos particiones de datos invlidos uno por debajo de 16 y otro de 65 aos. Por lo tanto, hay tres particiones en este caso - un vlido y dos invlidos. Un caso de prueba se puede disear para cada particin, lo que resulta en tres casos de prueba.

3.3.2.2.

ANALISIS DEL VALOR LMITE

Mostrando con el ejemplo de las particiones (ver figura 3.7) hay dos lmites: la edad mnima para el empleo y la edad mxima para el empleo (edad de jubilacin)

Figura 3.7. Anlisis del valor limite

Estos dos lmites: 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 estn diseados, que combinan las tcnicas de particin de equivalencia y anlisis del valor lmite. En este ejemplo, hay cinco casos de prueba: Un valor entre 16 y 65 - valor vlido. Un valor en el lmite inferior de 16 - valor vlido.

Un valor justo por debajo del lmite inferior (es decir, menos de 16) - valor no vlido (por lo general este valor se le dara como un da menos de 16). Un valor en el lmite superior de 65 un valor vlido.

Un valor justo por encima del lmite superior (es decir, mayor que 65) - valor no vlido (por lo general este valor se le dara como 65 aos y 1 da).

26

Ejecucin de pruebas 2011

4. CLASES DE EQUIVALENCIA
4.1.DEFINICIN
Una clase de equivalencia representa un conjunto de estados vlidos o no vlidos para condiciones de entrada. Tpicamente, una condicin de entrada es un valor numrico especfico, un rango de valores, un conjunto de valores relacionados o una condicin lgica. Si un conjunto de objetos puede unirse por medio de relaciones simtricas, 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 condicin de entrada especifica un rango, se define una clase de equivalencia vlida y dos no vlidas. 2. Si una condicin de entrada requiere un valor especfico, se define una clase de equivalencia vlida y dos no vlidas. 3. Si una condicin de entrada requiere un valor especfico, se define una clase de equivalencia vlida y dos no vlidas.

4. Si una condicin de entrada es lgica, se define una clase de equivalencia vlida y una no vlida.

4.3.PARTICIN EQUIVALENTE
4.3.1. DEFINICIN
La particin equivalente es un mtodo 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 carcter) que, de otro modo requeriran la ejecucin de muchos casos antes de detectar el error genrico. La particin equivalente se dirige a la definicin de casos de prueba que descubran clases de errores, reduciendo as el nmero total de casos de prueba que hay que desarrollar.

4.3.2. QU PASOS SEGUIR?

En el diseo de casos de prueba para particin equivalente se procede en dos pasos:

27

Ejecucin de pruebas 2011

1. Se identifican las clases de equivalencia. Las clases de equivalencia son identificadas tomando cada condicin de entrada (generalmente una oracin o una frase en la especificacin) y repartindola en dos o ms grupos. Es de notar que dos tipos de clases de equivalencia estn identificados: las clases de equivalencia vlidas representan entradas vlidas al programa, y las clases de equivalencia no vlidas que representan el resto de los estados posibles de la condicin (es decir, valores errneos 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 nmero nico a cada clase de equivalencia. Hasta que todas las clases de equivalencia vlidas han sido cubiertas por los casos de prueba, se escribe un nuevo caso de prueba que cubra la clase de equivalencia vlida. Y por ltimo hasta que los casos de prueba hayan cubierto todas las clases de equivalencia invlidas, se escribe un caso de la prueba que cubra una, y solamente una, de las clases de equivalencia invlidas descubiertas.

4.3.3. EJERCICIO DE PRUEBA DE CAJA NEGRA CLASES DE EQUIVALENCIA

4.3.3.1. ENUNCIADO

Considere una aplicacin 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 dems), la informacin de entrada del procedimiento que gestiona las operaciones concretas a realizar por el usuario requiere las siguientes entradas: Cdigo del banco: En blanco o nmero de tres dgitos. En este caso, el primero de los dgitos tiene que ser mayor que 1. Cdigo de sucursal: Un nmero de cuatro dgitos. El primero de ellos mayor de 0. Nmero de cuenta: Nmero de cinco dgitos. Clave personal: Valor alfanumrico de cinco posiciones. Orden: En este valor se introducir segn la orden que se desee realizar. Puede estar en blanco o se una de las dos cadenas siguientes: o o Talonario Movimientos

28

Ejecucin 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 cdigo est en blanco, el usuario recibir los dos documentos.

4.3.3.2.

SOLUCIN

Siguiendo los pasos de la particin 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 despus la realizacin de los casos de prueba. Condicin de Entrada Cdigo banco Cdigo sucursal N cuenta

Tipo Lgica (puede estar o no) Si est es Rango Rango

Clase Equivalencia Vlida 1. En blanco 2. 100<=Cdigo banco<=999 6. 1000<=Cdigo sucursal<=9999

Clase Equivalencia no Vlida 3. 4. 5. 7. 8. Un valor no numrico Cdigo banco<100 Cdigo banco>999 Cdigo sucursal<1000 Cdigo sucursal>=9999

Valor

9. Cualquier nmero de 5 dgitos

10. Nmero de menos de cinco dgitos 11. Nmero de menos de cuatro dgitos 13. Cadena de menos de cinco posiciones 14. Cadena de ms de cinco posiciones 18. Cadena distinta de blanco y de las vlidas 19. Talonarios 20. Movimiento

Clave

Valor

12. Cualquier cadena de caracteres alfanumricos de 5 posiciones

Orden

Conjunto, con comportamiento distinto

15. 16. Talonario 17. Movimientos

Tabla1. Clases de Equivalencia

Para generar los casos de prueba, consideremos la tcnica de Anlisis de Valores Lmite. Esta tcnica conduce a que determinadas clases de equivalencia se genere ms 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 tcnica de Anlisis de Valores Lmite indica que se generen dos casos de prueba con el lmite inferior y el superior del rango respectivamente (para identificar estos casos de prueba se ha aadido el sufijo a y b a las clases de equivalencia correspondiente). Los casos de prueba resultantes se muestran en la tabla.

29

Ejecucin de pruebas 2011

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 100 999 30A 99 1000 -

N Caso 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15

Sucursal 1000 9999 1001 1989 1989 1989 999 10000 2345 7863 6754 9998 8765 7654 8769

Cuenta 00000 99999 12345 12347 12347 12347 12347 12345 9999 100000 89765 89765 89765 89765 89765

Clave 00000 zzzzz Hyu56 Kuh98 Kuf98 Abc80 Def85 Hyu56 Jkgy5 Jkgy5 Jut8 Jut890 Gar78 Gar78 Gar78

Orden Talonario Movimientos Talonario Talonario Talonario Talonario Talonario 988 Talonarios Movimiento

Resultado Todos los movimientos y talonario Envo de talonario Envo de movimientos Cdigo banco errneo Cdigo banco errneo Cdigo banco errneo Cdigo sucursal errneo Cdigo sucursal errneo Nmero cuenta errneo Nmero cuenta errneo Clave errnea Clave errnea Orden errnea Orden errnea Orden errnea

Tabla2. Casos de Pruebas

30

Ejecucin de pruebas 2011

5. INFORME Y SEGUIMIENTO DE PRUEBAS

5.1.DOCUMENTACIN 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: planificacin, anlisis, diseo, construccin, 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: Preparacin de las pruebas. Ejecucin de las pruebas. Finalizacin de las pruebas.

En cada una de estas fases hay que generar la documentacin apropiada, lo cual puede ser complicado si no se tiene una referencia adecuada. Para proporcionar una base estndar para la documentacin 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: Preparacin de las pruebas. o Plan de pruebas. o Especificacin de diseo de pruebas. o Especificacin de casos de prueba. o Especificacin de procedimientos de prueba. o Informe de transferencia de elementos de prueba. Ejecucin de las pruebas. o Registro de pruebas. o Informe de incidentes. Finalizacin de las pruebas. o Informe de resumen de pruebas. Aunque el estndar hace referencia a documentos distintos, en la prctica no tienen porqu ser documentos fsicos separados. Incluso en muchas ocasiones, gran parte de la informacin 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 documentacin del proceso de pruebas: seguramente no tendr el mismo rigor documental un proyecto de un software mdico que uno sobre la construccin de un sencillo sitio web. Otros factores como la cultura y poltica de la empresa pueden influir en la formalidad de la documentacin. Podemos mencionar que los elementos imprescindibles en el proceso de pruebas y los cuales sern usados durante todo el proceso son los siguientes: o El plan de prueba:

31

Ejecucin de pruebas 2011

Describe todos los mtodos que se utilizarn para verificar que el software satisface la especificacin del producto y las necesidades del cliente. Incluye los objetivos de calidad, necesidades de recursos, cronograma, asignaciones, mtodos, etc. Casos de prueba: Lista los tems especficos que sern probados y describe los pasos detallados que sern seguidos para verificar el software. Reporte de bugs: Describen los problemas encontrados al ejecutar los casos de prueba. Herramientas de pruebas y automatizacin: Documentacin de las herramientas empleadas en el proceso de pruebas. Mtricas, estadsticas y resmenes: Indican como ha sido el progreso del proceso de prueba. Toman la forma de grficos, tablas e informes escritos.

o o o

5.1.1. DOCUMENTACIN EN LA PREPARACION DE LAS PRUEBAS

La fase de preparacin de las pruebas es la que ms documentacin requiere ya que implica definir aspectos como el calendario de pruebas, qu se quiere probar, cmo se va a probar, sobre qu entorno de pruebas, etc. El primer paso en la documentacin del proceso de pruebas es la creacin del plan de pruebas como se ve en la figura 5.1.

Figura5.1. Documentacin relacionada en la Preparacin de las pruebas segn IEEE 829

32

Ejecucin de pruebas 2011

5.1.1.1. 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 cules no), es decir el alcance de las pruebas. Quin va a realizar las pruebas (asignar responsabilidades) y qu recursos se necesitan en cuanto a personas, software, hardware y formacin. La planificacin de las tareas de pruebas, con sus dependencias, calendario, duracin, etc. Los tipos de pruebas a realizar (de componentes, de integracin, etc.) y las tcnicas elegidas para disear 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 ESTNDAR Segn el estndar IEEE 829 la estructura que debera contener nuestro plan de pruebas debera ser la siguiente: A. Identificador nico del documento (para la gestin de configuracin). B. Introduccin y resumen de elementos y caractersticas a probar. C. Elementos software que se van a probar (por ejemplo, programas o mdulos). D. Caractersticas que se van a probar. E. Caractersticas que no se prueban. F. Enfoque general de la prueba (actividades, tcnicas, herramientas, etc.). G. Criterios de paso/fallo para cada elemento. H. Criterios de suspensin y requisitos de reanudacin. I. Documentos a entregar (como mnimo, los descritos en el estndar). J. Actividades de preparacin y ejecucin de pruebas. K. Necesidades de entorno. L. Responsabilidades en la organizacin y realizacin de las pruebas. M. Necesidades de personal y de formacin. 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 desempeado. Q. Glosario

33

Ejecucin de pruebas 2011

5.1.1.2. DOCUMENTO DE ESPECIFICACIN DE DISEO DE PRUEBAS

La especificacin del diseo de pruebas es el primer paso en el desarrollo real de las pruebas. Este documento especifica las caractersticas y funcionalidades que se quieren probar del producto software (condiciones de la prueba o requisitos de la prueba) y su priorizacin, as como los criterios de xito/fallo de las pruebas. Por ejemplo, en un mdulo de gestin de usuarios, las siguientes podran 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 especificacin de diseo de pruebas ayuda a determinar en una fase temprana dnde se quieren centrar los esfuerzos de la prueba, de tal forma que despus no se malgasten energas en crear casos de prueba para elementos que no merecen la pena. ESTRUCTURA FIJADA POR EL ESTNDAR Segn el estndar IEEE 829 la estructura que debera contener nuestra especificacin de diseo de pruebas debera ser la siguiente: A. Identificador (nico) para la especificacin. Proporcionar tambin una referencia del plan asociado (si existe). B. Caractersticas a probar de los elementos software (y combinaciones de caractersticas). C. Detalles sobre el plan de pruebas del que surge este diseo, incluyendo las tcnicas de prueba especfica y los mtodos de anlisis de resultados. D. Identificacin 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 caracterstica o combinacin de caractersticas ha pasado con xito la prueba o no).

5.1.1.3.

DOCUMENTO DE ESPECIFICACIN DE CASOS DE PRUEBA

Las condiciones o requisitos de la prueba suelen estar especificadas de forma muy vaga. Un caso de prueba realiza una especificacin ms detallada indicando: Los datos de entrada concretos que hay que utilizar (por ejemplo, ejecutar proceso de alta con nombre de usuario Juan y contrasea 123). Cul es el resultado esperado tras la ejecucin de la prueba. Otros elementos relevantes que deben indicar el documento de casos de prueba son:

34

Ejecucin de pruebas 2011

Las precondiciones que se han de dar antes de la ejecucin 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, tendra que ser ejecutado despus del caso anterior para que las precondiciones del primero se puedan cumplir.

ESTRUCTURA FIJADA POR EL ESTNDAR Segn el estndar IEEE 829 la estructura que debera contener nuestra especificacin de casos de prueba debera ser la siguiente: A. Identificador nico de la especificacin. B. Elementos software (p. ej., mdulos) que se van a probar: definir dichos elementos y las caractersticas que ejercitar este caso. C. Especificaciones de cada entrada requerida para ejecutar el caso (incluyendo las relaciones entre las diversas entradas; p. ej., la sincronizacin de las mismas). D. Especificaciones de todas las salidas y las caractersticas 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 ESPECIFICACIN DE LOS PROCEDIMIENTOS DE PRUEBA

Este documento especifica aspectos como: Los pasos detallados de cmo ejecutar cada test y el orden de ejecucin. La configuracin exacta del entorno de pruebas.

Por ejemplo, un procedimiento de pruebas podra 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

Ejecucin de pruebas 2011

ESTRUCTURA FIJADA POR EL ESTNDAR Segn el estndar IEEE 829 la estructura que debera contener nuestra especificacin de los procedimientos de prueba debera ser la siguiente: A. Identificador nico de la especificacin y referencia a la correspondiente especificacin de diseo de prueba. B. Objetivo del procedimiento y lista de casos que se ejecutan con l. C. Requisitos especiales para la ejecucin (p. ej., entorno especial o personal especial). D. Pasos en el procedimiento. Adems de la manera de registrar los resultados y los incidentes de la ejecucin, se debe especificar: La secuencia necesaria de acciones para preparar la ejecucin. Acciones necesarias para empezar la ejecucin. Acciones necesarias durante la ejecucin. Cmo se realizarn 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 ejecucin y acciones necesarias para el reinicio en estos puntos. Acciones necesarias para detener ordenadamente la ejecucin. Acciones necesarias para restaurar el entorno y dejarlo en la situacin existente antes de las pruebas. Acciones necesarias para tratar los acontecimientos anmalos.

5.1.1.5.

INFORME DE TRANSMISIN DE ELEMENTOS DE PRUEBAS

Detrs de este nombre tan complicado se esconde un documento cuyo propsito es describir los elementos que van a entrar en una fase de pruebas. De esta forma los tcnicos de pruebas pueden tener la garanta de que los elementos que van a probar estn preparados y saben dnde localizarlos.

5.1.2. DOCUMENTACION DURANTE LA EJECUCION DE LAS PRUEBAS

Durante la ejecucin de las pruebas es fundamental conocer el estado del proceso de prueba, saber qu pruebas se han ejecutado y cules quedan pendientes, qu defectos se han encontrado, etc. Para ello, se crean los registros de pruebas (o los tambin llamados Histricos de pruebas o test log) y los informes de incidentes tal como se muestra en la figura 5.2.

36

Ejecucin de pruebas 2011

Figura 5.2. Documentacin relacionada durante la Ejecucin de las pruebas segn IEEE 829

5.1.2.1.

REGISTRO DE PRUEBAS (HISTRICO DE PRUEBAS O TEST LOG)

Un objetivo fundamental del proceso de prueba es proporcionar informacin acerca del sistema que se est probando. El registro de pruebas documenta los aspectos relativos a la ejecucin de las pruebas: qu prueba se han ejecutado, quin y cundo los ha ejecutado, en qu orden, en qu entorno, si la prueba ha pasado o ha fallado. En este documento es importante tambin, asociar la informacin de ejecucin de cada prueba con versiones especficas del software en prueba para garantizar la trazabilidad. La informacin recogida en el registro de pruebas permite conocer el progreso de la fase de ejecucin de pruebas y tomar decisiones acerca de si el software est listo para pasar a la siguiente fase. ESTRUCTURA FIJADA EN EL ESTNDAR Segn el estndar IEEE 829 la estructura que debera contener nuestro registro de pruebas debera ser la siguiente: A. Identificador B. Descripcin de la prueba: elementos probados y entorno de la prueba C. Anotacin de datos sobre cada hecho ocurrido (incluido el comienzo y el final de la prueba)

37

Ejecucin 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 trmino 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 especificacin de los casos de prueba, una mala interpretacin de los requisitos, etc. El informe de incidentes debe contener toda la informacin necesaria para la identificacin y resolucin del incidente: entradas utilizadas, resultados esperados, resultados obtenidos, paso del procedimiento en el que se ha producido el incidente, configuracin del entorno, valoracin del impacto, etc. ESTRUCTURA FIJADA EN EL ESTNDAR Segn el estndar IEEE 829 la estructura que debera contener nuestro informe de incidentes debera ser la siguiente: A. Identificador B. Resumen del incidente C. Descripcin de datos objetivos (fecha/hora, entradas, resultados esperados, etc.) D. Impacto que tendr sobre las pruebas

5.1.3. DOCUMENTACIN PARA LA FINALIZACION DE LAS PRUEBAS

Una vez finalizado el proceso de pruebas, se tiene que proporcionar suficiente informacin 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 informacin 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

Ejecucin de pruebas 2011

ESTRUCTURA FIJADA EN EL ESTNDAR Segn el estndar IEEE 829 la estructura que debera contener nuestro informe de resumen de pruebas debera ser la siguiente: A. Identificador B. Resumen de la evaluacin de los elementos probados C. Variaciones del software respecto a su especificacin de diseo, as como las variaciones en las pruebas D. Valoracin de la extensin de la prueba (cobertura lgica, funcional, de requisitos, etc.) E. Resumen de los resultados obtenidos en las pruebas F. Evaluacin de cada elemento software sometido a prueba (evaluacin 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. DEPURACIN (DEBUGGING)
5.2.1.1. DEFINICIN

Casi todos los compiladores suelen llevar asociada la posibilidad de ejecutar un programa paso a paso, permitindole al operador conocer dnde est en cada momento, y cunto valen las variables. Los depuradores pueden usarse para realizar inspecciones rigurosas sobre el comportamiento dinmico de los programas. La prctica demuestra, no obstante, que su uso es tedioso y que slo son eficaces si se persigue un objetivo muy claro. El objetivo habitual es utilizarlo como consecuencia de la deteccin 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 anlisis y afrontar la reparacin con conocimiento de causa.

39

Ejecucin de pruebas 2011

Figura 5.3. Proceso de Depuracin

5.2.1.2.

CONSEJOS PARA LA DEPURACIN

LOCALIZACIN DEL ERROR Analizar la informacin 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 depuracin slo como recurso secundario. No experimentar cambiando el programa. Se deben atacar los errores individualmente. Se debe fijar la atencin tambin en los datos.

CORRECCIN DEL ERROR Donde hay un defecto, suele haber ms. Debe fijarse el defecto, no sus sntomas. La probabilidad de corregir perfectamente un defecto no es del 100%. Cuidado con crear nuevos defectos. La correccin debe situarnos temporalmente en la fase de diseo. Cambiar el cdigo fuente, no el cdigo objeto.

40

Ejecucin de pruebas 2011

5.2.2. CUNDO PARAR DE PROBAR?
Cundo dejar de probar para una actividad de prueba especfica? Cundo dejar de probar todas las actividades principales? Cundo dejar de probar y liberar el producto? CRITERIOS INFORMALES Basndonos en criterios de recursos Basndonos en criterios de actividad

CRITERIOS FORMALES Establecer una meta de confiabilidad durante la planificacin de productos y anlisis de necesidades

41

Ejecucin de pruebas 2011

CONCLUSIN
Actualmente podemos afirmar que probar es buscarle los fallos a un programa. La fase de pruebas absorbe una buena porcin de los costes de desarrollo de software. Adems, se muestra renuente a un tratamiento matemtico o, simplemente, automatizado. Su ejecucin se basa en metodologa (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 intencin, y provoca difciles reacciones humanas. Aunque se han desarrollado miles de herramientas de soporte de esta fase, todas han limitado su xito a entornos muy concretos, frecuentemente slo sirviendo para el producto para el que se desarrollaron. Slo herramientas muy generales como analizadores de complejidad, sistemas de ejecucin simblica y medidores de cobertura han mostrado su utilidad en un marco ms 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 tcnicas, prcticas y tener experiencia en pruebas es tan til como un entorno de programacin sin saber el lenguaje.

42

Ejecucin de pruebas 2011

RECOMENDACIONES
Con lo ledo anteriormente se puede recomendar para la ejecucin 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. Adems, 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 sntomas de defectos. Al generar casos de prueba, se deben incluir tanto datos de entrada vlidos y esperados como no vlidos 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 diseados 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, prcticamente, 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 nmero de defectos ya descubierto. Las pruebas son una tarea tanto o ms creativa que el desarrollo de software. Siempre se han considerado las pruebas como una tarea destructiva y rutinaria.

Es interesante planificar y disear las pruebas para poder detectar el mximo nmero y variedad de defectos con el mnimo consumo de tiempo y esfuerzo.

43

Ejecucin de pruebas 2011

BIBLIOGRAFIA
[Libros de Consulta]

[Sitios y Anexos Web]

44