2. Pruebas de rendimiento 2.1.

Definicin

Se realizan, desde una perspectiva, para determinar lo rpido que realiza una tarea un sistema en condiciones particulares de trabajo. Tambin puede servir para validar y verificar otros atributos de la calidad del sistema, tales como la escalabilidad, fiabilidad y uso de los recursos. (1) Segn la IEEE Es el grado en que un sistema o componente realiza sus funciones designadas dentro de las limitaciones dadas, tales como la velocidad, precisin, o el uso de la memoria. (2) Con estas prueba no se busca encontrar errores, pero si busca enfocarse en procesos individuales de la aplicacin (Base de Datos, Algoritmos, Red, etc) en busca de probables cuellos de botella1 y poder determinar una base a considerar en futuros cambios de la aplicacin. Es vital tener objetivos claros para poder definir correctamente las mtricas que vamos a utilizar y como las vamos a utilizar. Estas pruebas de rendimiento se pueden realizar tanto en las plataformas de prueba del desarrollo como, opcionalmente, en la plataforma de produccin del cliente. En cualquier caso, el resultado obtenido consiste en una serie de informes que reflejan el rendimiento del sistema en distintos escenarios.

2.2.

Objetivos

Predecir anticipadamente problemas de rendimiento y degradacin de recursos del sistema antes de su paso a produccin y as facilitar su correccin. Medir el rendimiento de las aplicaciones entregadas en su ubicacin establecida. Garantizar el cumplimiento de los requisitos mnimos de servicio demandados por el cliente y, al mismo tiempo, facilitar el paso de los productos obtenidos al entorno de produccin con las mximas garantas posibles de xito.
1

Un cuello de botella es un fenmeno en donde el rendimiento o capacidad de un sistema completo es severamente limitado por un nico componente.

Fig. 1 Ciclo de vida prueba de sistemas (Yongkui and Guofeng, 2009) Nota: El objetivo NO es encontrar errores, sino eliminar los cuellos de botella y establecer una lnea base para futuras pruebas de regresin2. 2.3. Mitos en las pruebas de rendimiento (3)

Algunos de los mitos muy comunes son los siguientes:

Las Pruebas de rendimiento se hacen para romper el sistema. Las pruebas de Stress se hacen para entender el punto de ruptura del sistema. De lo contrario las pruebas de carga normal se hacen generalmente para entender el comportamiento de la solicitud en la carga de usuarios previstos. Dependiendo de otros requisitos, tales como el aumento de carga esperado, la carga continuada por un periodo prolongado de tiempo mientras la demanda aumenta, la resistencia a las cadas o las pruebas de estrs3. Las pruebas de rendimiento slo deben hacerse despus de las pruebas de integracin del sistema

Pruebas de regresin son cualquier tipo de pruebas de software que intentan descubrir las causas de nuevos errores (bugs). 3 Esta prueba se utiliza normalmente para romper la aplicacin. Se va doblando el nmero de usuarios que se agregan a la aplicacin y se ejecuta una prueba de carga hasta que se rompe.

Aunque esta es la norma comn en la industria, las pruebas de rendimiento tambin pueden realizarse mientras se realiza el desarrollo inicial de la aplicacin. Este tipo de enfoque se conoce como pruebas de rendimiento tempranas. Este enfoque garantizara un desarrollo holstico de la aplicacin manteniendo los parmetros de rendimiento en mente. Por lo tanto, la bsqueda de un problema en el rendimiento justo antes de la terminacin de la aplicacin y el coste de corregir el error, se reduce en gran medida. El probar el rendimiento slo implica la creacin de scripts y cualquier cambio en la aplicacin solo puede causar una simple refactorizacin dichos scripts Las pruebas de rendimiento son en s mismas una ciencia evolucionada de la industria del software. En s mismos, los scripts, aunque importantes, son slo uno de los componentes de las pruebas de rendimiento. El principal desafo para cualquier persona que pruebe el rendimiento es determinar el tipo de pruebas necesarias y analizar los distintos medidores de rendimiento para determinar el cuello de botella de rendimiento.

2.4.

LAS ESPECIFICACIONES DE RENDIMIENTO (4)

Es fundamental detallar las especificaciones de rendimiento (requisitos) y documentarlas en algn plan de pruebas de rendimiento. Idealmente, esto se hace durante la fase de requisitos del desarrollo de cualquier proyecto de desarrollo de sistemas, antes de cualquier esfuerzo de diseo. Sin embargo, con frecuencia las pruebas de rendimiento no se realizan teniendo en cuenta alguna especificacin, es decir, nadie ha expresado cual es el tiempo mximo de respuesta aceptable para un nmero determinado de usuarios. Las pruebas de rendimiento se utilizan con frecuencia como parte del proceso de ajuste de la ejecucin. La idea es identificar el "eslabn ms dbil", pues hay inevitablemente una parte del sistema que, si responde con mayor rapidez, eso se traducir en un funcionamiento del sistema global ms rpido. A veces es una difcil tarea determinar qu parte del sistema representa esta ruta crtica, y algunas herramientas de prueba incluyen (o puede tener aadidos que lo proporcionan) instrumentos que se ejecuta en el servidor (agentes) y que informan de tiempos de transaccin, nmero de accesos a bases de datos, sobrecarga de la red, y otros monitores del servidor, que pueden ser analizados junto con los datos principales de las estadsticas de rendimiento. La especificacin de rendimiento, como mnimo, debera responder a las siguientes preguntas: Cul es el alcance, en detalle, de la prueba de rendimiento? Qu subsistemas, interfaces, componentes, etc, estn dentro y fuera del mbito de ejecucin de esta prueba?

 Para las interfaces de usuario involucradas, Cul es el nmero de usuarios concurrentes que se esperan para cada uno (especificando picos y medias? Cul es la estructura objetivo del sistema (hardware, especificando todos los servidores de red y configuraciones de dispositivo)? Cul es la distribucin del volumen de trabajo de la aplicacin para cada componente? (por ejemplo: 20% login, 40% buscando, 30% seleccionando elemento, 10% comprando). Cul es la distribucin del trabajo del sistema? [Las cargas de trabajo mltiples pueden ser simuladas en una sola prueba de eficacia] (por ejemplo: 30% del volumen de trabajo para A, 20% del volumen de trabajo para B, 50% del volumen de trabajo para C) Cules son los requisitos de tiempo para cada uno y para todos los procesos por lotes (especificando picos y medias4)? 2.5. MEDICION DE RENDIMIENTO (5)

Cmo hacemos para medir el rendimiento? Hay una serie de indicadores clave que se deben tener en cuenta. Estos indicadores son parte de los requisitos de rendimiento, podemos dividir en dos tipos:

2.5.1.

ORIENTADO A INDICADORES DE SERVICIO

Son la disponibilidad y tiempo de respuesta, que miden qu tan bien (o no) una aplicacin proporciona un servicio a los usuarios finales.

2.5.2. INDICADORES DE EFICIENCIA Son el rendimiento y la utilizacin, medir qu tan bien (o no) una aplicacin hace uso del entorno de la aplicacin. Podemos definir brevemente estos trminos de la siguiente manera: Disponibilidad La cantidad de tiempo que una aplicacin est disponible para el usuario final. La falta de disponibilidad es importante porque muchas aplicaciones tendrn un costo de negocios importante, incluso para un corte pequeo.

Son las respuestas luego de avaluar el rendimiento del software, generalmente se plasma en indicadores o formatos preestablecidos para su anlisis.

En cuanto a las pruebas de rendimiento, esto significara la completa incapacidad de un usuario final para hacer un uso eficaz de la solicitud.

Tiempo de respuesta Es la cantidad de tiempo que le toma a la aplicacin responder a una peticin de usuario. Para las pruebas de rendimiento, una de las medidas normalmente usadas es el tiempo entre la solicitud de respuesta del usuario a la aplicacin y llegada completa de la respuesta al usuario en la estacin de trabajo. Rendimiento Rendimiento de la velocidad orientado a los eventos que se producen en la aplicacin. Un buen ejemplo sera el nmero de accesos a una web pgina en un plazo determinado de tiempo. Utilizacin El porcentaje de la capacidad terica de un recurso que se est utilizando. Los ejemplos incluyen la cantidad de ancho de banda de red est siendo consumido por el trfico de aplicaciones y la cantidad de memoria utilizada en un servidor cuando un millar de visitantes son activos5.

En conjunto, estos indicadores pueden darnos una idea exacta de cmo una aplicacin se est realizando y su impacto, en trminos de capacidad y en el entorno de la aplicacin.

2.6.

PRE-REQUISITOS PARA PRUEBA DE RENDIMIENTO

No solo a nivel de software se analiza la capacidad de un sistema si no tambin, a nivel de cantidad de usuario, de capacidad harware(compatibilidad y rendimiento).

A. CONDICION DE PRUEBA De acuerdo con ISTQB (6), una condicin de prueba puede ser una caracterstica, una funcin o un atributo que puede ser verificado por un caso de prueba. Un escenario de prueba puede significar lo mismo que un caso de una prueba, un grupo de casos de prueba, o de un procedimiento de prueba. Por lo tanto, una condicin de prueba6 puede ser la funcin objetivo de la aplicacin de software que se evala mediante la ejecucin de un escenario de prueba. Nota: Una prueba de condicin no debe confundirse con las necesidades ambientales, tales como requisitos previos, las dependencias, y los criterios de entrada que puedan ser necesarias para iniciar la ejecucin de casos de prueba.

B. TIEMPO Es fundamental para el coste de un nuevo sistema, los esfuerzos de pruebas de rendimiento comienzan al inicio del desarrollo del proyecto y se extendern a travs de la implementacin. Cuanto ms tarde se detecte un defecto de rendimiento, mayor ser el costo de la rehabilitacin. Esto es cierto en el caso de las pruebas funcionales, pero ms an con pruebas de rendimiento, debido a la naturaleza de extremo a extremo de su mbito de aplicacin. 2.7. ETAPA DE PRUEBAS DE RENDIMINETO (7)

2.7.1.

VALIDACION DEL RENDIMINETO

Es la etapa donde se apunta a medir si se cumplen con los requerimientos establecidos por el cliente, donde se juzga los resultados medidos y analizados para poder determinar por qu y cmo solucionar estos. Se estima que en el 80 % de los casos los problemas de performance se deben a una incorrecta eleccin de la arquitectura de la aplicacin. Para prevenir estos casos existe PASA PASA (Performance Assessment of Software Architectures) Es un mtodo para la evaluacin del desempeo de arquitecturas de software.
6

La condicin de prueba es la funcin importante para evaluar mediante escenarios cada uno de los mdulos de prueba dependiendo del contexto.

Utiliza los principios y tcnicas de [Williams y Smith, 1998] de la SPE, Smith [y Williams, 2002] para identificar reas potenciales de riesgo dentro de la arquitectura con respecto al desempeo y otros los objetivos de calidad. Si se encuentra un problema, tambin PASA identifica las estrategias para reducir o eliminar los riesgos. 2.7.2. INGENIERIA DE RENDIMINETO Es la etapa final donde se realizan los cambios necesarios (tunning) 7 para alcanzar lo esperado por la aplicacin, esto puede incluir cambios de cdigo, hardware o red entre los principales para luego ser testeado nuevamente. Tunning: Afinar la configuracin de hardware y software para optimizar su rendimiento. 2.8. TIPOS DE PRUEBAS DE RENDIMIENTO (8)

2.8.1.

PRUEBA DE LINEA BASE

Esto establece un punto de comparacin para los funcionamientos de ensayo, por lo general para medir el tiempo de respuesta de las transacciones. La prueba se ejecuta normalmente para una sola transaccin con un nico usuario virtual para un perodo de tiempo determinado o para un nmero determinado de iteraciones transaccin. Esta ejecucin debe llevarse a cabo sin ninguna otra actividad en el sistema para proporcionar " un mejor caso" de medida. El valor obtenido se puede utilizar para determinar la cantidad de degradacin del rendimiento que se produce en respuesta al creciente nmero de usuarios o el rendimiento. 2.8.2. PRUEBA DE CARGA (9)

Esta es la prueba de rendimiento clsico, donde se carga la aplicacin hasta la concurrencia de destino, pero por lo general no ms. El objetivo es alcanzar los objetivos de rendimiento para la disponibilidad, la concurrencia o del caudal y tiempo de respuesta. La prueba de carga es la aproximacin ms cercana del uso de aplicaciones reales, y normalmente incluye una simulacin de los efectos de interaccin del usuario con el cliente. 2.8.2. PRUEBA DE STRESS

Etapa final en el que se efectan cambios necesarios al software.

Esto tiene un objetivo muy diferente de una prueba de carga. Una prueba de Stress hace que la aplicacin o alguna parte de la infraestructura fallen. El objetivo es determinar los lmites superior o el tamao de la infraestructura. Por lo tanto, una prueba de Stress contina hasta que se rompe algo: no hay ms usuarios que pueden acceder, tiempo de respuesta superior al valor que se define como aceptable, o la aplicacin no est disponible. El fundamento de las pruebas de estrs es que si nuestro objetivo es la simultaneidad. Los resultados de la capacidad de medir la tensin de prueba tanto como el rendimiento. Es importante que conozca sus lmites mximos, particularmente si el crecimiento futuro del trfico de aplicaciones es difcil de predecir.

2.8.3. PRUEBA DE ESTABILIDAD O INMERSION La prueba de inmersin tiene el objetivo de identificar los problemas que pueden aparecer slo despus de un perodo prolongado de tiempo. Un clsico ejemplo de ello sera una prdida de memoria de desarrollo lento o alguna limitacin de imprevistos en el nmero de veces que una transaccin se puede ejecutar. Este tipo de prueba no puede llevarse a cabo de manera efectiva a menos que se realice una supervisin de servidores en el lugar. Problemas de este tipo normalmente se manifiestan ya sea como una desaceleracin gradual en el tiempo de respuesta o como prdida repentina de la disponibilidad de la aplicacin. La correlacin de los datos de los usuarios y servidores en el punto de falla o desaceleracin que se percibe es vital para asegurar un diagnstico preciso. 2.8.4. PRUEBA DE HUMO (10) La definicin de las pruebas de humo es centrarse nicamente en lo que ha cambiado. Por lo tanto, en una prueba de humo el rendimiento puede involucrar slo las transacciones que se han visto afectados por un cambio de cdigo8.

Nota: Las pruebas de humo trmino se origin en la industria del hardware. El trmino deriva de esta prctica: despus de un pedazo de hardware o un componente de hardware ha sido cambiado o reparado, el equipo fue accionado simplemente para arriba. Si no hay humo (O llamas!). El componente superado la prueba. 2.8.5. PRUEBA DE AISLAMIENTO Esta variedad de prueba se utiliza en el dominio de un problema identificado. Por lo general, consta de ejecuciones repetidas de determinadas transacciones que se han
8

Es una prueba muy rpida para ver que cambios ocasiono al modificar una lnea de cdigo o una transaccin.

identificado como el resultado de un problema de rendimiento. A menudo se utiliza para aislar y confirmar el fallo de dominio. Es recomendable primero ejecutar una prueba de lnea de base, la carga, y prueba de Stress. La prueba de inmersin y la prueba de humo son ms dependientes sobre la aplicacin y la cantidad de tiempo disponible para las pruebas, como es el requisito para las pruebas de aislamiento, que en gran medida determinar cules son los problemas que se descubran. 2.9. TAREAS A REALIZAR

Las tareas para realizar una prueba de este tipo seran las siguientes: Decidir usar recursos internos o externos para ejecutar las pruebas, en funcin de la experiencia de la casa (o falta de ella). Reunir u obtener requisitos de rendimiento (especificaciones) de los usuarios y/o analistas. Desarrollar un plan de alto nivel, incluyendo los requisitos, recursos, plazos e hitos. Elaborar un plan de pruebas de rendimiento detallado (incluyendo los escenarios detallados y casos de prueba, cargas de trabajo, informacin del entorno, etc). Elegir la/s herramienta/s de prueba. Especificar los datos de prueba necesarios y la distribucin de ellos (a menudo pasado por alto, y a menudo el fracaso de una prueba de rendimiento vlida). Desarrollar scripts de prueba de concepto para cada aplicacin/componente sometido a la prueba, utilizando la herramienta de prueba elegida y estrategias. Desarrollar un plan de prueba de rendimiento detallado, incluyendo todas las dependencias y los plazos. Instalar y configurar los simuladores de peticiones y controladores. Configurar el entorno de prueba (lo ideal es que sea idntico hardware a la plataforma de produccin), configurar los router, aislar la red (no queremos alterar los resultados por parte de otros usuarios), desplegar la aplicacin en el servidor, desarrollar la base de datos de prueba, etc. Ejecutar las pruebas, probablemente en repetidas ocasiones (iterativamente 9), a fin de ver si el desconocimiento de cualquier factor podra afectar a los resultados. Analizar los resultados - ya sea de aceptando/rechazando, o investigacin el camino crtico y recomendando medidas correctivas.

2.10. METODOLOGIA DE PRUEBAS DE RENDIMIENTO (11)

Iterativamente especifica realizar pruebas cada cierto periodo, cada cierto cambio, pera llegar a un buen producto final.

Etapas Relevamiento: El objeto de esta fase es "Determinar la situacin existente en el sistema actual". Es una investigacin detallada de los componentes de la organizacin. Planificacin: Tiene como objetivo la correcta caracterizacin de la carga de trabajo. o Obtencin de requisitos. o Eleccin de las mtricas adecuadas. o Eleccin del tipo de pruebas. o Descripcin del sistema a probar. o Caracterizacin de la carga de trabajo. Construccin: Tiene como Objetivo la Construccin de los Test Scripts y la: o configuracin del ambiente de pruebas. o Definicin de Escenarios o Distribucin de tareas o Coordinacin con encargados de Servidor de Pruebas

 Ejecucin: Tiene como objetivo correr los Test Scripts desarrollados en la etapa de construccin. o Dependiendo del tamao del proyecto puede ocurrir 1 o varias veces. o Se registran las fecha y hora de ejecucin Anlisis: Tiene como Objetivo recabar toda la informacin generada por las pruebas, procesarla de manera que se pueda interpretar, sacar conclusiones y proponer recomendaciones de cambio. o Recopilacin de Resultados o Foco en mtricas ms significativas o Definicin de grficos ms adecuados para mostrar la informacin o Proponer recomendaciones en funcin de los resultados obtenidos

Actividades Actividad 1. Identificar el entorno de pruebas. Identificar el entorno fsico de pruebas y el entorno de produccin, as como las herramientas y recursos de que dispone el equipo de prueba. El entorno fsico incluye hardware, software y configuraciones de red. Tener un profundo conocimiento de todo el entorno de prueba desde el principio permite diseos ms eficientes de pruebas y la planificacin y ayuda a identificar problemas en las pruebas en fases tempranas del proyecto. En algunas situaciones, este proceso debe ser revisado peridicamente durante todo el ciclo de vida del proyecto. Actividad 2. Identificar los criterios de aceptacin de rendimiento. Determinar el tiempo de respuesta, el rendimiento, la utilizacin de los recursos y los objetivos y limitaciones.

En general, el tiempo de respuesta concierne al usuario, el rendimiento al negocio, y la utilizacin de los recursos al sistema. Adems, identificar criterios de xito del proyecto que no hayan sido recogidos por los objetivos y limitaciones, por ejemplo, mediante pruebas de rendimiento para evaluar qu combinacin de la configuracin da lugar a un funcionamiento ptimo.

 Actividad 3. Planificar y disear las pruebas. Identificar los principales escenarios, determinar la variabilidad de los usuarios y la forma de simular esa variabilidad, definir los datos de las pruebas, y establecer las mtricas a recoger. Consolidar esta informacin en uno o ms modelos de uso del sistema a implantar, ejecutarlo y analizarlo. Actividad 4. Configurar el entorno de prueba. Preparar el entorno de prueba, herramientas y recursos necesarios para ejecutar cada una de las estrategias, as como las caractersticas y componentes disponibles para la prueba. Asegurarse de que el entorno de prueba se ha preparado para la monitorizacin de los recursos segn sea necesario. Actividad 5. Aplicar el diseo de la prueba. Desarrollar las pruebas de rendimiento de acuerdo con el diseo del plan. Actividad 6. Ejecutar la prueba. Ejecutar y monitorizar las pruebas. Validar las pruebas, los datos de las pruebas, y recoger los resultados. Ejecutar pruebas vlidas para analizar, mientras se monitoriza la prueba y su entorno. Actividad 7. Analizar los resultados, realizar un informe y repetirlo. Consolidar y compartir los resultados de la prueba. Analizar los datos, tanto individualmente, como con un equipo multidisciplinario. Volver a priorizar el resto de las pruebas y volver a ejecutarlas de ser necesario. Cuando todas las mtricas estn dentro de los lmites aceptados, ninguno de los umbrales establecidos han sido rebasados, y toda la informacin deseada se ha reunido, las pruebas han acabado para el escenario definido por la configuracin.

2.11.

HERRAMIENTAS OpenSTA HTTP 1.0 / 1.1 / HTTPS (SSL), SOAP/XM L JMeter HTTP,FTP, SOAP/XMLR PC, JDBC WebLoad LoadRunner Soporta muchos. Los protocolos son cargados por tem. Tiene una opcin de grabacin por multiprotocolo

CRITERIO DE DESCRIPCION EVALUACION Protocolos Los protocolos de comunicacin que pueden ser capturados, manipulados y simulados por la aplicacin.

Playback funciones

HTTP/S, WAP, AJAX, ActiveX, Java, Web services. Es posible grabar scripts con multi protocolo Ejecucin de Vista Es una Vista los extendida herramienta extendida scripts y del log GUI. del log. El facilidades de donde se Entonces cual debug en los ven los hay muchos muestra los scripts calores GUI pedidos y de los Listeners, los parmetro los cuales datos de sy son respuesta. los usados para mensajes capturar la del grabacin y servidor. replicar los mensajes.

Parametrizaci n

Cambio dinmico de valores para variables pasadas desde el cliente

Gran cantidad de facilidades para data entry,

La parametrizaci n se puede hacer por interfaz, en el control Users

Gran cantidad de facilidades para data entry, incluyendo

Vista extendida del log donde se ven los valores de los parmetros y los mensajes del servidor. Tambin permite ver y comparar la versin grabada de la pagina y los mensajes del servidor. Tiene una opcin para hacer debug en el generador de scripts. Gran cantidad de facilidades para data entry, incluyendo interfaces

al servidor durante el POST para asegurar una simulacin mas real del comportamient o CRITERIO DE DESCRIPCION EVALUACION Simulacin Habilidad de de la emular las velocidad de diferentes conexin de velocidades de los usuarios la red que pueden ser utilizadas por los usuarios Reportes y Facilidades anlisis para examinar e investigar los resultados de las pruebas incluyendo contadores y recursos monitoreados.

incluyendo Parameters. interfaces Wizard para generar automtica mente datos de prueba. OpenSTA JMeter No lo No lo permite. permite. Pero puede programarse en JAVA

interfaces Wizard para generar automtica mente datos de prueba. WebLoad No lo permite en la version Open Source

Wizard para generar automticame nte datos de prueba

LoadRunner Puede emular diferentes velocidades de la red durante la ejecucin. Posee una gran cantidad de grficos sofisticados con muchsimas facilidades. Genera repotes automticos en Word. Se pueden obtener reportes por cada usuario simulado.

Grficos Puede crear simples y grficos pero suficientes no reportes como para analizar los resultados de carga y uso de recursos. Los grficos pueden ser exportados a Excel.

WebLOAD Console muestra reportes online de las sesiones que estn corriendo. El usuario puede crear sus propias vistas de las estadsticas que estos reportes muestran. Se puede ir cambiando de reportes grficos o textuales (Tablas)

Extensibilidad

La habilidad de incrementar la funcionalidad de la herramienta.

Pueden escribirse mdulos en SCL. Adems al ser OpenSour ce

Funciones Beanshell/JA VA pueden ser definidas y ser usadas como plug-in

Permite agregar objetos Java, ActiveX o COM en los test Scripts. El framework de WebLoad es flexible

Libreras adicionales en TSL o C , limitado por las capacidades funcionales de la herramienta.

2.12.

EJEMPLO

Caso: Frmula para calcular el rendimiento de una pgina web

Las pruebas de carga en una pgina ASP pueden llegar al mximo de su capacidad cuando alcanzan las 800 solicitudes por segundo y un 85 por ciento del uso del procesador en el servidor Web. Si el servidor Web dispone de cuatro procesadores a 700 MHz (700.000.000 ciclos por segundo), el coste por pgina puede calcularse de la siguiente forma:

3. 1 . 2 .

Bibliografa

3 . 4 . 5 . 6 . 7 . 8 . 9 . 1 0 . 1 1 .

wikipedia. Software de pruebas de rendimiento. [Online].; 2012 [cited 2012 11 11. Available from: http://en.wikipedia.org/wiki/Software_performance_testing. IEEE. IEEE - Instituto de Ingeniera Elctrica y Electrnica. [Online].; 2012 [cited 2012 11 11. Available from: http://ieeexplore.ieee.org/Xplore/login.jsp?url=http://ieeexplore.ieee.org/iel5/5463512/54 63636/05463653.pdf%3Farnumber%3D5463653&authDecision=-203. WIKIPEDIA. Pruebas de rendimiento del software. [Online].; 2012 [cited 2012 10 23. Available from: http://wapedia.mobi/es/Pruebas_de_rendimiento_del_software. WIKIPEDIA. Pruebas de rendimiento del software. [Online].; 2012 [cited 2012 10 27. Available from: http://wapedia.mobi/es/Pruebas_de_rendimiento_del_software. Molyneaux I. The Art of Application Performance Testin. 1st ed. AMAZON.COM , editor. NEW YORK: AMAZON; 2009. ISTQB. International Software Testing Qualification Board (Comit Internacional de Calificacin de Pruebas de Software). [Online].; 2012 [cited 2012 11 09. Available from: www.istqb.org. Testing en Espaol. Performance Testing. [Online].; 2O12 [cited 2012 11 11. Available from: http://josepablosarco.wordpress.com/performance-testing/. Molyneaux. I. The Art of Application Performance Testing,n. 1st ed. AMAZON , editor. NEW YORK: AMAZON; 2009. Molyneaux I. The Art of Application Performance Testing. 1st ed. NEW YORK; 2009. Molyneaux. I. The Art of Application Performance Testing. 1st ed. NEWYORK; 2009.

SARCO JP. TESTING DE PERFONCE. [Online].; 2012 [cited 2012 11 11. Available from: http://www.sqaforums.com/attachments/524220-TestingdePerformancePorJosePabloSarco.pdf.