PRUEBAS DE SOFTWARE "TESTING" PRUEBAS DE SOFTWARE Las pruebas de software se integran dentro de las diferentes fases del ciclo

del software dentro de la Ingeniera de software. As se ejecuta un programa y mediante tcnicas experimentales se trata de descubrir que errores tiene. Las pruebas de software tambin conocidas como testing son los procesos que permiten verificar y revelar la calidad de un producto software. Son utilizadas para identificar posibles fallos de implementacin, calidad, o usabilidad de un programa de ordenador o videojuego. Bsicamente es una fase en el desarrollo de software consistente en probar las aplicaciones construidas. Para determinar el nivel de calidad se deben efectuar unas medidas o pruebas que permitan comprobar el grado de cumplimiento respecto de las especificaciones iniciales del sistema.

La importancia de la deteccin oportuna 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.

TIPOS DE PRUEBAS PRUEBAS DE VALIDACIN Las pruebas de validacin en la ingeniera de software son el proceso de revisin que el sistema de software producido cumple con las especificaciones y que cumple su cometido. Es normalmente una parte del proceso de pruebas de software de un proyecto, que tambin utiliza tcnicas tales como evaluaciones, inspecciones, y tutoriales. La validacin es el proceso de comprobar lo que se ha especificado es lo que el usuario realmente quera. Las pruebas de validacin empiezan tras la culminacin de las pruebas de integracin, cundo se han ejercitado los componentes individuales.se han terminado de ensamblar el software como paquete y se ha descubierto y corregido los errores de interfaz Se trata de evaluar el sistema o parte de este durante o al final del desarrollo para determinar si satisface los requisitos iniciales. La pregunta a realizarse es: Es esto lo que el cliente quiere? Enfoques a la verificacin Dinmica de verificacin, tambin conocido como ensayos o experimentacin. Esttica de verificacin, tambin conocido como anlisis.

Tipos Pruebas de aceptacin: desarrolladas por el cliente. Pruebas alfa realizadas por el usuario con el desarrollador como observador en un entorno controlado (simulacin de un entorno de produccin). Pruebas beta: realizadas por el usuario en su entorno de trabajo y sin observadores

Caractersticas Comprobar que se satisfacen los requisitos: Se usan la mismas tcnicas, pero con otro objetivo. No hay programas de prueba, sino slo el cdigo final de la aplicacin. Se prueba el programa completo. Uno o varios casos de prueba por cada requisito o caso de uso especificado. Se prueba tambin rendimiento, capacidad, etc. (y no slo resultados correctos). Pruebas alfa (desarrolladores) y beta (usuarios).

PRUEBAS DE INTEGRACIN Pruebas integrales o pruebas de integracin son aquellas que se realizan en el mbito del desarrollo de software una vez que se han aprobado las pruebas unitarias. nicamente se refieren a la prueba o pruebas de todos los elementos unitarios que componen un proceso, hecha en conjunto, de una sola vez.

Consiste en realizar pruebas para verificar que un gran conjunto de partes de software funcionan juntos. Las pruebas de integracin (algunas veces llamadas integracin y testeo I&t) es la fase del testeo de software en la cual mdulos individuales de software son combinados y testeados como un grupo. Son las pruebas posteriores a las pruebas unitarias y preceden el testeo de sistema.

PRUEBAS FUNCIONALES Una prueba funcional es una prueba basada en la ejecucin, revisin y retroalimentacin de las funcionalidades previamente diseadas para el software. Las pruebas funcionales se hacen mediante el diseo de modelos de prueba que buscan evaluar cada una de las opciones con las que cuenta el paquete informtico. Las pruebas funcionales estn desarrolladas bajo la perspectiva del usuario, confirmando que el sistema hace lo que los usuarios esperan que haga. Un error funcional en su aplicacin puede tener consecuencias catastrficas, desde la prdida de credibilidad de sus clientes, hasta grandes prdidas econmicas. Los consultores de pruebas funcionales de Testhouse tienen amplia experiencia en multitud de mercados a nivel global, adaptndose a todo tipo de metodologas de desarrollo y habiendo realizado pruebas funcionales en aplicaciones crticas de empresas lderes en el sector de finanzas, telecomunicaciones y media, entre otros.

PRUEBAS DE RECORRIDO Incluye indagacin y observacin del flujo de transacciones dentro de procesos representativos desde el punto en que las transacciones son iniciadas hasta el punto en el que son reportadas en el mayor general. Recorremos los controles que hemos identificado para determinar que han sido diseados e implantados eficazmente. El recorrido incluye el examen de los flujos de la documentacin e informacin desde una perspectiva tanto manual como automatizada. Su objetivo es confirmar nuestra comprensin del flujo de las transacciones representativas, la exactitud de la informacin que hemos obtenido acerca de los controles preventivos y/o de deteccin relevantes sobre el flujo de transacciones, si los controles han sido diseados eficazmente para prevenir o detectar y corregir aseveraciones equvocas materiales en forma oportuna, si lo los controles han sido implantados y la idoneidad de nuestra documentacin.

PRUEBA UNITARIA En programacin, una prueba unitaria es una forma de probar el correcto funcionamiento de un mdulo de cdigo. Esto sirve para asegurar que cada uno de los mdulos funcione correctamente por separado. Luego, con las pruebas de integracin, se podr asegurar el correcto funcionamiento del sistema o subsistema en cuestin. La idea es escribir casos de prueba para cada funcin no trivial o mtodo en el mdulo de forma que cada caso sea independiente del resto. Caracterstica Para que una prueba unitaria sea buena se deben cumplir los siguientes requisitos: Automatizable: no debera requerirse una intervencin manual. Esto es especialmente til para integracin continua Completas: deben cubrir la mayor cantidad de cdigo. Repetibles o Reutilizables: no se deben crear pruebas que slo puedan ser ejecutadas una sola vez. Tambin es til para integracin continua. Independientes: la ejecucin de una prueba no debe afectar a la ejecucin de otra. Profesionales: las pruebas deben ser consideradas igual que el cdigo, con la misma profesionalidad, documentacin, etc. Aunque estos requisitos no tienen que ser cumplidos al pie de la letra, se recomienda seguirlos o de lo contrario las pruebas pierden parte de su funcin.

Ventajas El objetivo de las pruebas unitarias es aislar cada parte del programa y mostrar que las partes individuales son correctas. Proporcionan un contrato escrito que el trozo de cdigo debe satisfacer. Estas pruebas aisladas proporcionan cinco ventajas bsicas: 1. Fomentan el cambio: Las pruebas unitarias facilitan que el programador cambie el cdigo para mejorar su estructura (lo que se ha dado en llamar refactorizacin), puesto que permiten hacer pruebas sobre los cambios y as asegurarse de que los nuevos cambios no han introducido errores. 2. Simplifica la integracin: Puesto que permiten llegar a la fase de integracin con un grado alto de seguridad de que el cdigo est funcionando correctamente. De esta manera se facilitan las pruebas de integracin. 3. Documenta el cdigo: Las propias pruebas son documentacin del cdigo puesto que ah se puede ver cmo utilizarlo. 4. Separacin de la interfaz y la implementacin: Dado que la nica interaccin entre los casos de prueba y las unidades bajo prueba son las interfaces de estas ltimas, se puede cambiar cualquiera de los dos sin afectar al otro, a veces usando objetos mock (mock object) para simular el comportamiento de objetos complejos. 5. Los errores estn ms acotados y son ms fciles de localizar: dado que tenemos pruebas unitarias que pueden desenmascararlos.

Limitaciones Es importante darse cuenta de que las pruebas unitarias no descubrirn todos los errores del cdigo. Por definicin, slo prueban las unidades por s solas. Por lo tanto, no descubrirn errores de integracin, problemas de rendimiento y otros problemas que afectan a todo el sistema en su conjunto. Adems, puede no ser trivial anticipar todos los casos especiales de entradas que puede recibir en realidad la unidad de programa bajo estudio. Las pruebas unitarias slo son efectivas si se usan en conjunto con otras pruebas de software.

CAJA BLANCA Al desarrollar un nuevo software o sistema de informacin, la primera etapa de pruebas a considerar es la etapa de pruebas unitarias o tambin llamada pruebas de caja blanca (White Box), ests pruebas tambin son llamadas pruebas modulares ya que nos permiten determinar si un mdulo del programa est listo y correctamente terminado, estas pruebas no se deben confundir con las pruebas informales que realiza el programador mientras est desarrollando el mdulo. El principal factor que se debe considerar al inicio de las pruebas es el tamao del mdulo a probar, se debe considerar si el tamao del mdulo permitir probar adecuadamente toda su funcionalidad de manera sencilla y rpida. Tambin es importante separar los mdulos de acuerdo a su funcionalidad, si los mdulos son muy grandes y contienen muchas funcionalidades, estos se volvern ms complejos de probar y al encontrar algn error ser ms difcil ubicar la funcionalidad defectuosa y corregirla. Al hacer esta labor el analista de pruebas podr recomendar que un mdulo muy complejo sea separado en 2 o 3 mdulos ms sencillos.

Este tipo de pruebas debe ser realizado por personal especializado en Software testing, el cual debe estar familiarizado en el uso de herramientas de depuracin y pruebas, as mismo deben conocer el lenguaje de programacin en el que se est desarrollando la aplicacin, en la actualidad existen una gran cantidad de herramientas que apoyan la labor del analista de pruebas, inclusive se pueden conseguir herramientas para cada tipo de lenguaje, estas herramientas pueden facilitar el desarrollo de pruebas, elaboracin de casos de pruebas, seguimiento de errores, etc. Algunas de las herramientas que se utilizan para pruebas unitarias son: Junit, La Suite de Mercury, CPPUnit etc. El objetivo fundamental de las pruebas unitarias es asegurar el correcto funcionamiento de las interfaces, o flujo de datos entre componentes.

No es un requisito indispensable la culminacin de todos los mdulos del sistema para iniciar las pruebas, generalmente las pruebas modulares y las pruebas integrales se solapan; en la actualidad algunas metodologas consideran oportuno iniciar la etapa de pruebas unitarias poco despus del desarrollo. En esta imagen se muestra lo que se considera una representacin clsica de Software Testing White Box o pruebas de caja blanca, en este tipo de pruebas el cubo representara un sistema en donde se pueden observar los diversos componentes que forman parte del mismo, cada uno de estos componentes debe ser probado en su totalidad (valos), y tambin sus interfaces o comunicaciones con los dems componentes (flechas), este tipo de pruebas tambin son llamadas pruebas de caja de cristal ya que este ltimo trmino representa mejor el tipo de pruebas.

Lo importante en este tipo de pruebas es que se deben tener claros los siguientes aspectos: Los datos de entrada son conocidos por el Tester o Analista de Pruebas y estos deben ser preparados con minuciosidad, ya que el resultado de las pruebas dependen de estos. Se debe conocer que componentes interactan en cada caso de prueba. Se debe conocer de antemano que resultados debe devolver el componente segn los datos de entrada utilizados en la prueba. Finalmente se deben comparar los datos obtenidos en la prueba con los datos esperados, si son idnticos podemos decir que el modulo supero la prueba y empezamos con la siguiente. Luego de tener una buena cantidad de mdulos independientes probados y encontrados Conformes, el siguiente paso es integrarlos, las principales formas de integracin que existen son: Integracin Incremental. Integracin no incremental.

Integracin Incremental

Al realizar una integracin incremental debemos combinar o unir el siguiente modelo que se debe probar con el conjunto de mdulos ya probados. El nmero de mdulos se incrementa progresivamente hasta formar el programa completo. Esto lo podemos realizar en dos formas. Integracin Incremental Ascendente. Integracin Incremental Descendente.

Integracin incremental ascendente En este tipo de integracin se combinan los mdulos de ms bajo nivel en grupos que realizan alguna sub funcin especfica. Atreves de un driver (mdulo impulsor) se simulan llamadas a los mdulos, se introducen los datos de prueba y se recogen los resultados. Cada grupo se prueba usando un driver (test integrador), y este luego es sustituido por los mdulos de nivel superior en la jerarqua. En el ltimo paso se prueba el programa completo con sus entradas y salidas reales. Ejemplo: Para probar un sistema bancario, se debe empezar por los mdulos que aplican lgica de negocio y que hacen cambios en la base de datos, una vez que cada uno de estos mdulos funciona correctamente, se inicia las pruebas de niveles superiores, los cuales bsicamente hacen llamadas a estos mdulos de bajo nivel, esta segunda etapa normalmente es mucho ms rpida. Tal como se muestra en la siguiente figura, luego de probar los mdulos de ms bajo nivel, continuamos con los mdulos del siguiente nivel, para esto debemos construir nuevos drivers o impulsores (B y C), que se aplicaran directamente a los mdulos superiores (B y C) y estos a su vez se integrarn a los de ms bajo nivel.

VENTAJAS DE LA INTEGRACIN INCREMENTAL ASCENDENTE:

Las entradas para las pruebas son ms fciles de crear ya que los mdulos inferiores suelen tener funciones ms especficas. Es ms fcil la observacin de los resultados de las pruebas, puesto que es en los mdulos inferiores donde se elaboran. Resuelve primero los errores de los mdulos inferiores que son los que acostumbran tener el procesamiento ms complejo, para luego nutrir de datos al resto del sistema.

DESVENTAJA DE LA INTEGRACIN INCREMENTAL ASCENDENTE:

Se requieren mdulos impulsores, que deben escribirse especialmente y que no son necesariamente sencillos de codificar. El sistema como entidad no existe hasta que se agregue el ultimo modulo.

La integracin descendente: Los mdulos se incorporan iniciando del mdulo de control principal (de mayor nivel) para luego ir incorporando los mdulos subordinados progresivamente. No hay un procedimiento considerado ptimo para seleccionar el siguiente mdulo a incorporar. La nica regla es que el mdulo incorporado tenga todos los mdulos que lo invocan previamente probados.

En general no hay una secuencia ptima de integracin. Debe estudiarse el problema concreto y de acuerdo a este, buscar el orden de integracin ms adecuado para la organizacin de las pruebas. No obstante, pueden considerarse las siguientes pautas: Si hay secciones crticas como ser un mdulo complicado, se debe proyectar la secuencia de integracin para incorporarlas lo antes posible. El orden de integracin debe incorporar cuanto antes los mdulos de entrada y salida. Existen principalmente dos mtodos para la incorporacin de mdulos: 1. Primero en profundidad: Primero se mueve verticalmente en la estructura del mdulo. 2. Primero en anchura: primero se mueve horizontalmente en la estructura del mdulo.

Etapas de la integracin descendente: - El mdulo de mayor nivel hace de impulso y se escriben mdulos ficticios simulando a los subordinados, que sern llamados por el mdulo de control superior. - Probar cada vez que se incorpora un mdulo nuevo al conjunto ya engarzado. - Al terminar cada prueba, sustituir un mdulo ficticio subordinado por el real que remplazaba. - Escribir los mdulos ficticios subordinados que se necesiten para la prueba del nuevo mdulo incorporado.

Ventajas de este mtodo de integracin: Las fallas que puedan existir en los mdulos inferiores se detecten en una etapa temprana. Permite ver la estructura del sistema desde un principio, facilitando la elaboracin de demostraciones de su funcionamiento.

Concuerda con definir primero las interfaces de los distintos subsistemas para despus seguir con las funciones especficas de cada uno por separado. Desventajas: Requiere de mucho trabajo de desarrollo adicional, ya que se debe escribir un gran nmero de mdulos ficticios subordinados. Antes de incorporar los mdulos de entrada y salida resulta difcil introducir los casos de prueba y obtener los resultados. Los juegos de datos de prueba pueden resultar difciles o imposibles de generar, puesto que generalmente los mdulos de nivel inferior son los que proporcionan los detalles. Induce a diferir la terminacin de la prueba en ciertos casos.

Integracin no incremental Es muy sencilla y se recomienda para proyectos de poca envergadura, consiste en probar cada mdulo por separado de manera similar a la integracin incremental, pero una vez de terminar con los mdulos independientes, se contina probndolos todos juntos como un todo. La nica ventaja es que no se necesita ningn tipo de trabajo adicional, ni planificar al orden de integracin, ni crear mdulos impulsores, ni mdulos ficticios subordinados. Las desventajas son que no tiene nocin de la comunicacin hasta el final, en ningn momento se dispone de un producto (ni siquiera parcial) para mostrar o presentar, el hecho de presentar las pruebas de una vez hace que las sesiones de prueba sean ms largas y tediosas, la cantidad de errores que arroja puede ser atemorizante, encontrar la causa de los errores puede resultar mucho ms compleja y se corre el riesgo que a poco tiempo de la entrega, haya que volver sobre el diseo y la codificacin de sistema.

 Automatizacin De Pruebas Unitarias Contexto Un proceso de desarrollo de software que necesita mejorar la calidad y reducir el nmero de defectos. El proyecto ya debe poseer Automatizacin de build y Control de versiones. Problema La calidad del software es una tarea de todo el equipo. Dejar la cuestin de la calidad del cdigo apenas a cargo de un grupo de analistas de pruebas y de calidad es un riesgo. Aumentar la confianza de los programadores en relacin a eventuales modificaciones en el cdigo es esencial en Cdigo Legado. Facilitar las pruebas de los programadores es fundamental, para que ellos puedan probar su cdigo slidamente y de esa forma no encuentren dificultades en probar siempre todo lo que producen. Fuerzas El costo de deteccin y correccin de un defecto es mayor cuando ocurre en la etapa de homologacin. Las partes complejas de un software acostumbran tener ms defectos y tienden a ser recurrentes. La flexibilidad de modificar aumenta la complejidad. Siempre que un desarrollador trabaja con un cdigo complejo, le lleva un tiempo para que l pueda entender nuevamente la solucin. Corregir un defecto ocasionalmente causa problemas en otra parte del software. Solucin Utilice una herramienta para la creacin de la Prueba Unitaria automatizada, bien como herramientas que permitan la creacin de "Mock Object" (Objeto Falso) que imiten la funcionalidad de objetos reales.

Siempre ejecute todas las pruebas unitarias automatizadas antes de hacer check-in de nuevos cdigo en el repositorio de control de versiones. Cuando un nuevo defecto es descubierto, lo primero que se hace es una prueba unitaria automatizada para probar el defecto. Luego el mismo es corregido. De este modo es ms difcil que el defecto vuelva, ya que en el caso que un desarrollador cometa el mismo error nuevamente, la batera de pruebas unitarias automatizadas lo detectar.

Raciocinio Las pruebas unitarias reducen el tiempo que gasta el equipo para identificar y corregir defectos (HUNT e THOMAS, 2004). Un conjunto de pruebas unitarias automatizadas tambin aumenta la confianza del equipo cuando necesita realizar cambios para inclusin de nuevas funcionalidades o la alteracin de funcionalidades existentes. La automatizacin de pruebas unitarias aumenta la calidad al facilitar la deteccin de defectos ms rpido en el ciclo de desarrollo. El tiempo de vida de un software tiende a aumentar debido a la "red de seguridad" que da la batera de pruebas unitarias. Contexto Resultante El proyecto posee un conjunto de pruebas unitarias automatizadas que es ejecutada siempre que un desarrollador le desee. El cdigo de las pruebas unitarias generados por la Automatizacin De Pruebas Unitarias se deben almacenar como parte del proyecto junto con el cdigo fuente del software en la herramienta de control de versiones. La automatizacin de bild debe tener tareas especficas para ejecutar todas las pruebas unitarias del proyecto. De este modo es posible ejecutar el conjunto de pruebas unitarias siempre que la integracin continua sea ejercida.

PRUEBAS DE REGRESIN Se denominan Pruebas de regresin a cualquier tipo de pruebas de software que intentan descubrir las causas de nuevos errores (Bugs), carencias de funcionalidad, o divergencias funcionales con respecto al comportamiento esperado del software, inducidos por cambios recientemente realizados en partes de la aplicacin que anteriormente al citado cambio no eran propensas a este tipo de error. Esto implica que el error tratado se reproduce como consecuencia inesperada del citado cambio en el programa. Este tipo de cambio puede ser debido a prcticas no adecuadas de control de versiones, falta de consideracin acerca del mbito o contexto de produccin final y extensibilidad del error que fue corregido (fragilidad de la correccin), o simplemente una consecuencia del rediseo de la aplicacin. Por lo tanto, en la mayora de las situaciones del desarrollo de software se considera una buena prctica que cuando se localiza y corrige un bug, se grabe una prueba que exponga el bug y se vuelvan a probar regularmente despus de los cambios subsiguientes que experimente el programa. Existen herramientas de software que permiten detectar este tipo de errores de manera parcial o totalmente automatizada, la prctica habitual en programacin extrema es que este tipo de pruebas se ejecuten en cada uno de los pasos del ciclo de vida del desarrollo del software. Tipos de regresin Clasificacin de mbito Local - los cambios introducen nuevos errores. Desenmascarada - los cambios revelan errores previos. Remota - Los cambios vinculan algunas partes del programa (mdulo) e introducen errores en ella.

Clasificacin temporal Nueva caracterstica - los cambios realizados con respecto a nuevas funcionalidades en la versin introducen errores en otras novedades en la misma versin del software. Caracterstica preexistente - los cambios realizados con respecto a nuevas funcionalidades introducen errores en funcionalidad existente de previas versiones. Como mitigar los riesgos Repeticin completa y habitual de la batera de pruebas, manual o mediante automatizacin. Repeticin parcial basada en trazabilidad y anlisis de riesgos. Pruebas de cliente o usuario: o Beta - distribucin a clientes potenciales y actuales de versiones beta. o Pilot - distribucin a un subconjunto bien definido y localizado. o Paralela - simultaneando uso de ambos sistemas.* Usar relase mayores. Probar nuevas funciones a menudo cubre las funciones existentes. Cuantas ms nuevas caractersticas haya en un relase, habr mayor nivel de pruebas de regresin "accidental". Parches de emergencia - estos parches se publican inmediatamente, y sern incluidos en relase de mantenimiento futuras. Usos Las Pruebas de Regresin pueden usarse no solo para probar la correccin de un programa, sino a menudo usarse para rastrear la calidad de su salida. Por ejemplo en el diseo de un compilador, las pruebas de regresin deben rastrear el tamao del cdigo, tiempo de simulacin, y el tiempo de compilacin de las suites de prueba. Cuando quiera que aparezca un nuevo build, el proceso de regresin aparece.

Citas "Tambin como consecuencia de la introduccin de nuevos bugs, el mantenimiento del programa necesita ms pruebas del sistema por sentencia escrita que cualquier otra programacin. En teora, despus de cada correccin uno debe ejecutar el batch completo de casos de prueba antes de ejecutar contra el sistema, para asegurarse de que no ha sido daado de forma oscura. En la prctica, tales pruebas de regresin deben aproximarse a esta idea terica, y es muy costoso." -- Fred Brooks, The Mythical Man Month (p 122). PRUEBAS DE PRESTACIONES A veces es importante el tiempo de respuesta, u otros parmetros de gasto. Tpicamente nos puede preocupar cunto tiempo le lleva al sistema procesar tantos datos, o cunta memoria consume, o cunto espacio en disco utiliza, o cuntos datos transfiere por un canal de comunicaciones, o ... Para todos estos parmetros suele ser importante conocer cmo evolucionan al variar la dimensin del problema (por ejemplo, al duplicarse el volumen de datos de entrada). Las Pruebas de Prestaciones tienen como objetivo fundamental: "Demostrar que el sistema funciona de acuerdo a las especificaciones con tiempos de respuesta aceptables para el usuario mientras se estn procesando los volmenes de transacciones requeridos sobre una base de datos proporcional a la de produccin." Las Pruebas de Escalabilidad tienen como objetivo fundamental: "Demostrar la capacidad de un sistema para proporcionar un servicio aceptable cuando la carga se incrementa o decrementa. Ejemplo: manejar cargas del sistema, bases de datos y redes tanto grandes como pequeas." El principal requisito para las pruebas de prestaciones y escalabilidad, es disponer de una infraestructura para poder ejecutar pruebas automticas durante largos periodos de tiempo. Esta infraestructura es un activo, aunque costoso, para cualquier organizacin por lo que hay que hacer el mayor uso posible del mismo.

HI Iberia Ingeniera y Proyectos ayuda a nuestros clientes a desarrollar una infraestructura que pueda ser utilizada para la realizacin de otras pruebas de prestaciones y escalabilidad con objetivos ms amplios: Evaluar la capacidad de crecimiento del sistema. Evaluar la escalabilidad del sistema. Identificar puntos dbiles en la infraestructura. Ajustar el sistema para optimizar el rendimiento. Verificar y Garantizar la robustez y fiabilidad del sistema. Detectar aspectos en el sistema que pueden ser irrelevantes para operaciones a pequea escala pero que pueden llegar a ser vitales para el uso del sistema cuando este crece. Identificar cuellos de botella y puntos dbiles en la arquitectura del sistema que podran reducir la capacidad y prestaciones del sistema. Ajustar los parmetros de rendimiento del sistema mediante la repeticin de pruebas de prestaciones. Una infraestructura adecuadamente diseada puede ser utilizada para asegurar estos objetivos como parte de la estrategia global de pruebas.

La metodologa utilizada por HI Iberia Ingeniera y Proyectos para implementar la infraestructura de pruebas de prestaciones sigue las siguientes fases: Anlisis del Sistema Especificacin de los casos de Prueba Preparacin Ejecucin Tuning

PRUEBAS DE SISTEMA Al final del desarrollo del software se incorpora otros elementos (hardware, personas, informacin) y se realiza una serie de pruebas de integracin del sistema y de validacin. Estas pruebas estn ms all del proceso del software y no las realizan nicamente los ingenieros del software. Sin embargo los pasos dados durante el diseo y la prueba mejoraran en gran medida la probabilidad de tener xito y la integracin del software del sistema mayor. El software ya validado se integra con el resto del sistema donde algunos Tipos de pruebas a considerar son: Rendimiento: determinan los tiempos de respuesta, el espacio que ocupa el mdulo en disco o en memoria, el flujo de datos que genera a travs de un canal de comunicaciones, etc. Resistencia: determinan hasta donde puede soportar el programa determinadas condiciones extremas. Robustez: determinan la capacidad del programa para soportar entradas incorrectas. Seguridad: se determinan los niveles de permiso de usuarios, las operaciones de acceso al sistema y acceso a datos la prueba comprueba que los mecanismos de proteccin integrados en el sistema realmente lo protejan de irrupciones inapropiadas Usabilidad: se determina la calidad de la experiencia de un usuario en la forma en la que ste interacta con el sistema, se considera la facilidad de uso y el grado de satisfaccin del usuario. Instalacin: se determinan las operaciones de arranque y actualizacin del software.

Desempeo: est diseada para probar el desempeo del software en tiempo de ejecucin en tiempo de contexto de un sistema integrado. La prueba de desempeo se aplica en todos los pasos del proceso de la prueba, incluso a nivel de la unidad, el desempeo de un mdulo individual debe evaluarse mientras se realizan las pruebas

CAJA NEGRA (SISTEMAS) En teora de sistemas y fsica, se denomina caja negra a aquel elemento que es estudiado desde el punto de vista de las entradas que recibe y las salidas o respuestas que produce, sin tener en cuenta su funcionamiento interno. En otras palabras, de una caja negra nos interesar su forma de interactuar con el medio que le rodea (en ocasiones, otros elementos que tambin podran ser cajas negras) entendiendo qu es lo que hace, pero sin dar importancia a cmo lo hace. Por tanto, de una caja negra deben estar muy bien definidas sus entradas y salidas, es decir, su interfaz; en cambio, no se precisa definir ni conocer los detalles internos de su funcionamiento. PRUEBAS DE ACEPTACIN Cuando se construye software a la medida para un cliente, se llevan a cabo una serie de pruebas de aceptacin para permitir que el cliente valide y verifique todos 1os requisitos. Estas pruebas las realiza el usuario final en lugar del responsable del desarrollo del sistema.