2. Pruebas de rendimiento 2.1.Definición Se realizan, desde una perspectiva, para determinar lo rápido que realiza una tarea un sistema en condiciones particulares de trabajo. También puede servir para validar y verificar otros atributos de la calidad del sistema, tales como la escalabilidad, fiabilidad y uso de los recursos. (1) Según la IEEE “Es el grado en que un sistema o componente realiza sus funciones designadas dentro de las limitaciones dadas, tales como la velocidad, precisión, o el uso de la memoria.” (2) Con estas prueba no se busca encontrar errores, pero si busca enfocarse en procesos individuales de la aplicación (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 aplicación. Es vital tener objetivos claros para poder definir correctamente las métricas 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 producción 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 degradación de recursos del sistema antes de su paso a producción y así facilitar su corrección. Medir el rendimiento de las aplicaciones entregadas en su ubicación establecida. Garantizar el cumplimiento de los requisitos mínimos de servicio demandados por el cliente y, al mismo tiempo, facilitar el paso de los productos obtenidos al entorno de producción con las máximas garantías posibles de éxito. 1 Un cuello de botella es un fenómeno en donde el rendimiento o capacidad de un sistema completo es severamente limitado por un único componente. la carga continuada por un periodo prolongado de tiempo mientras la demanda aumenta. De lo contrario las pruebas de carga normal se hacen generalmente para entender el comportamiento de la solicitud en la carga de usuarios previstos.Fig. Se va doblando el número de usuarios que se agregan a la aplicación y se ejecuta una prueba de carga hasta que se rompe. 2. Dependiendo de otros requisitos. Las pruebas de Stress se hacen para entender el punto de ruptura del sistema.3. 1 Ciclo de vida prueba de sistemas (Yongkui and Guofeng. tales como el aumento de carga esperado. la resistencia a las caídas o las pruebas de estrés3. 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. . 3 Esta prueba se utiliza normalmente para romper la aplicación. Las pruebas de rendimiento sólo deben hacerse después de las pruebas de integración del sistema 2 Pruebas de regresión son cualquier tipo de pruebas de software que intentan descubrir las causas de nuevos errores (bugs). sino eliminar los cuellos de botella y establecer una línea base para futuras pruebas de regresión2. 2009) Nota: El objetivo NO es encontrar errores. 2. son sólo uno de los componentes de las pruebas de rendimiento. El probar el rendimiento sólo implica la creación de scripts y cualquier cambio en la aplicación solo puede causar una simple refactorización dichos scripts Las pruebas de rendimiento son en sí mismas una ciencia evolucionada de la industria del software. número de accesos a bases de datos. eso se traducirá en un funcionamiento del sistema global más rápido. Las pruebas de rendimiento se utilizan con frecuencia como parte del proceso de ajuste de la ejecución. sobrecarga de la red. debería responder a las siguientes preguntas: ¿Cuál es el alcance. es decir. etc. antes de cualquier esfuerzo de diseño. esto se hace durante la fase de requisitos del desarrollo de cualquier proyecto de desarrollo de sistemas. Idealmente. en detalle. La especificación de rendimiento.4. LAS ESPECIFICACIONES DE RENDIMIENTO (4) Es fundamental detallar las especificaciones de rendimiento (requisitos) y documentarlas en algún plan de pruebas de rendimiento. las pruebas de rendimiento también pueden realizarse mientras se realiza el desarrollo inicial de la aplicación. se reduce en gran medida. Sin embargo. los scripts. de la prueba de rendimiento? ¿Qué subsistemas. nadie ha expresado cual es el tiempo máximo de respuesta aceptable para un número determinado de usuarios. la búsqueda de un problema en el rendimiento justo antes de la terminación de la aplicación y el coste de corregir el error. El principal desafío 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. pues hay inevitablemente una parte del sistema que. como mínimo. A veces es una difícil tarea determinar qué parte del sistema representa esta ruta crítica. y algunas herramientas de prueba incluyen (o puede tener añadidos que lo proporcionan) instrumentos que se ejecuta en el servidor (agentes) y que informan de tiempos de transacción.Aunque esta es la norma común en la industria. aunque importantes. Por lo tanto. con frecuencia las pruebas de rendimiento no se realizan teniendo en cuenta alguna especificación. que pueden ser analizados junto con los datos principales de las estadísticas de rendimiento. La idea es identificar el "eslabón más débil". Este tipo de enfoque se conoce como pruebas de rendimiento tempranas. están dentro y fuera del ámbito de ejecución de esta prueba? . Este enfoque garantizaría un desarrollo holístico de la aplicación manteniendo los parámetros de rendimiento en mente. En sí mismos. si responde con mayor rapidez. componentes. y otros monitores del servidor. interfaces. MEDICION DE RENDIMIENTO (5) ¿Cómo hacemos para medir el rendimiento? Hay una serie de indicadores clave que se deben tener en cuenta. especificando todos los servidores de red y configuraciones de dispositivo)? ¿Cuál es la distribución del volumen de trabajo de la aplicación para cada componente? (por ejemplo: 20% login. 20% del volumen de trabajo para B. INDICADORES DE EFICIENCIA Son el rendimiento y la utilización.5.5. incluso para un corte pequeño. Podemos definir brevemente estos términos de la siguiente manera: Disponibilidad La cantidad de tiempo que una aplicación está disponible para el usuario final.2. Estos indicadores son parte de los requisitos de rendimiento. La falta de disponibilidad es importante porque muchas aplicaciones tendrán un costo de negocios importante.5. 30% seleccionando elemento. ¿Cuál es el número de usuarios concurrentes que se esperan para cada uno (especificando picos y medias? ¿Cuál es la estructura objetivo del sistema (hardware. generalmente se plasma en indicadores o formatos preestablecidos para su análisis. ¿Cuál es la distribución del trabajo del sistema? [Las cargas de trabajo múltiples pueden ser simuladas en una sola prueba de eficacia] (por ejemplo: 30% del volumen de trabajo para A. podemos dividir en dos tipos: 2. 2. ORIENTADO A INDICADORES DE SERVICIO Son la disponibilidad y tiempo de respuesta. medir qué tan bien (o no) una aplicación hace uso del entorno de la aplicación.1. . 40% buscando. Para las interfaces de usuario involucradas. 4 Son las respuestas luego de avaluar el rendimiento del software. 50% del volumen de trabajo para C) ¿Cuáles son los requisitos de tiempo para cada uno y para todos los procesos por lotes (especificando picos y medias4)? 2. que miden qué tan bien (o no) una aplicación proporciona un servicio a los usuarios finales. 10% comprando). En conjunto.6. Utilización El porcentaje de la capacidad teórica de un recurso que se está utilizando. estos indicadores pueden darnos una idea exacta de cómo una aplicación se está realizando y su impacto. a nivel de cantidad de usuario. una de las medidas normalmente usadas es el tiempo entre la solicitud de respuesta del usuario a la aplicación y llegada completa de la respuesta al usuario en la estación de trabajo. Los ejemplos incluyen la cantidad de ancho de banda de red está siendo consumido por el tráfico de aplicaciones y la cantidad de memoria utilizada en un servidor cuando un millar de visitantes son activos5. PRE-REQUISITOS PARA PRUEBA DE RENDIMIENTO 5 No solo a nivel de software se analiza la capacidad de un sistema si no también. de capacidad harware(compatibilidad y rendimiento). en términos de capacidad y en el entorno de la aplicación. Para las pruebas de rendimiento.En cuanto a las pruebas de rendimiento. esto significaría la completa incapacidad de un usuario final para hacer un uso eficaz de la solicitud. Rendimiento Rendimiento de la velocidad orientado a los eventos que se producen en la aplicación. Un buen ejemplo sería el número de accesos a una web página en un plazo determinado de tiempo. . Tiempo de respuesta Es la cantidad de tiempo que le toma a la aplicación responder a una petición de usuario. 2. y los criterios de entrada que puedan ser necesarias para iniciar la ejecución de casos de prueba. Esto es cierto en el caso de las pruebas funcionales. una condición de prueba puede ser una característica. una función o un atributo que puede ser verificado por un caso de prueba. tales como requisitos previos. 6 La condición de prueba es la función importante para evaluar mediante escenarios cada uno de los módulos de prueba dependiendo del contexto. Un escenario de prueba puede significar lo mismo que un caso de una prueba. las dependencias. . pero más aún con pruebas de rendimiento.A.7. una condición de prueba6 puede ser la función objetivo de la aplicación de software que se evalúa mediante la ejecución de un escenario de prueba. ETAPA DE PRUEBAS DE RENDIMINETO (7) 2. debido a la naturaleza de extremo a extremo de su ámbito de aplicación. Para prevenir estos casos existe PASA PASA (Performance Assessment of Software Architectures) Es un método para la evaluación del desempeño de arquitecturas de software. los esfuerzos de pruebas de rendimiento comienzan al inicio del desarrollo del proyecto y se extenderán a través de la implementación. Se estima que en el 80 % de los casos los problemas de performance se deben a una incorrecta elección de la arquitectura de la aplicación. o de un procedimiento de prueba. Nota: Una prueba de condición no debe confundirse con las necesidades ambientales. Cuanto más tarde se detecte un defecto de rendimiento. un grupo de casos de prueba. mayor será el costo de la rehabilitación.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 cómo solucionar estos. 2. TIEMPO Es fundamental para el coste de un nuevo sistema. B. CONDICION DE PRUEBA De acuerdo con ISTQB (6).7. Por lo tanto. Si se encuentra un problema.8.Utiliza los principios y técnicas de [Williams y Smith. 2. por lo general para medir el tiempo de respuesta de las transacciones. La prueba de carga es la aproximación más cercana del uso de aplicaciones reales. 2002] para identificar áreas potenciales de riesgo dentro de la arquitectura con respecto al desempeño y otros los objetivos de calidad. El objetivo es alcanzar los objetivos de rendimiento para la disponibilidad.2. 1998] de la SPE. INGENIERIA DE RENDIMINETO Es la etapa final donde se realizan los cambios necesarios (tunning) 7 para alcanzar lo esperado por la aplicación. también PASA identifica las estrategias para reducir o eliminar los riesgos. PRUEBA DE LINEA BASE Esto establece un punto de comparación para los funcionamientos de ensayo. 2. 2. y normalmente incluye una simulación de los efectos de interacción del usuario con el cliente.8. . la concurrencia o del caudal y tiempo de respuesta.8.2. PRUEBA DE STRESS 7 Etapa final en el que se efectúan cambios necesarios al software. PRUEBA DE CARGA (9) Esta es la prueba de rendimiento clásico. Esta ejecución debe llevarse a cabo sin ninguna otra actividad en el sistema para proporcionar " un mejor caso" de medida.8. TIPOS DE PRUEBAS DE RENDIMIENTO (8) 2. pero por lo general no más. donde se carga la aplicación hasta la concurrencia de destino. hardware o red entre los principales para luego ser testeado nuevamente. Tunning: Afinar la configuración de hardware y software para optimizar su rendimiento.2. 2.7. La prueba se ejecuta normalmente para una sola transacción con un único usuario virtual para un período de tiempo determinado o para un número determinado de iteraciones transacción. Smith [y Williams. esto puede incluir cambios de código. El valor obtenido se puede utilizar para determinar la cantidad de degradación del rendimiento que se produce en respuesta al creciente número de usuarios o el rendimiento.1. tiempo de respuesta superior al valor que se define como aceptable. . PRUEBA DE HUMO (10) La definición de las pruebas de humo es centrarse únicamente en lo que ha cambiado.Esto tiene un objetivo muy diferente de una prueba de carga. consta de ejecuciones repetidas de determinadas transacciones que se han 8 Es una prueba muy rápida para ver que cambios ocasiono al modificar una línea de código o una transacción. Un clásico ejemplo de ello sería una pérdida de memoria de desarrollo lento o alguna limitación de imprevistos en el número de veces que una transacción se puede ejecutar. Es importante que conozca sus límites máximos. Por lo general. PRUEBA DE ESTABILIDAD O INMERSION La prueba de inmersión tiene el objetivo de identificar los problemas que pueden aparecer sólo después de un período prolongado de tiempo.8. El componente superado la prueba.3. La correlación de los datos de los usuarios y servidores en el punto de falla o desaceleración que se percibe es vital para asegurar un diagnóstico preciso. o la aplicación no está disponible. Los resultados de la capacidad de medir la tensión de prueba tanto como el rendimiento. 2. el equipo fue accionado simplemente para arriba. Por lo tanto.5. Una prueba de Stress hace que la aplicación o alguna parte de la infraestructura fallen. Este tipo de prueba no puede llevarse a cabo de manera efectiva a menos que se realice una supervisión de servidores en el lugar. 2. El fundamento de las pruebas de estrés es que si nuestro objetivo es la simultaneidad.4.8. Por lo tanto. Problemas de este tipo normalmente se manifiestan ya sea como una desaceleración gradual en el tiempo de respuesta o como pérdida repentina de la disponibilidad de la aplicación. en una prueba de humo el rendimiento puede involucrar sólo las transacciones que se han visto afectados por un cambio de código8.8. El objetivo es determinar los límites superior o el tamaño de la infraestructura. Nota: Las pruebas de humo término se originó en la industria del hardware. Si no hay humo (O llamas!). 2. particularmente si el crecimiento futuro del tráfico de aplicaciones es difícil de predecir. El término deriva de esta práctica: después de un pedazo de hardware o un componente de hardware ha sido cambiado o reparado. una prueba de Stress continúa hasta que se rompe algo: no hay más usuarios que pueden acceder. PRUEBA DE AISLAMIENTO Esta variedad de prueba se utiliza en el dominio de un problema identificado. cada cierto cambio. información del entorno. probablemente en repetidas ocasiones (iterativamente 9). Elegir la/s herramienta/s de prueba. Instalar y configurar los simuladores de peticiones y controladores. pera llegar a un buen producto final. Desarrollar un plan de prueba de rendimiento detallado. 2. en función de la experiencia de la casa (o falta de ella). configurar los router. como es el requisito para las pruebas de aislamiento. o investigación el camino crítico y recomendando medidas correctivas. La prueba de inmersión y la prueba de humo son más dependientes sobre la aplicación y la cantidad de tiempo disponible para las pruebas. Desarrollar scripts de prueba de concepto para cada aplicación/componente sometido a la prueba. y prueba de Stress. Configurar el entorno de prueba (lo ideal es que sea idéntico hardware a la plataforma de producción). plazos e hitos. Elaborar un plan de pruebas de rendimiento detallado (incluyendo los escenarios detallados y casos de prueba.9. incluyendo los requisitos. etc). cargas de trabajo. Reunir u obtener requisitos de rendimiento (especificaciones) de los usuarios y/o analistas. 2. utilizando la herramienta de prueba elegida y estrategias. incluyendo todas las dependencias y los plazos. la carga. Ejecutar las pruebas. etc.ya sea de aceptando/rechazando. que en gran medida determinará cuáles son los problemas que se descubran. desplegar la aplicación en el servidor. recursos. A menudo se utiliza para aislar y confirmar el fallo de dominio. aislar la red (no queremos alterar los resultados por parte de otros usuarios). METODOLOGIA DE PRUEBAS DE RENDIMIENTO (11) 9 Iterativamente especifica realizar pruebas cada cierto periodo. Analizar los resultados . desarrollar la base de datos de prueba. a fin de ver si el desconocimiento de cualquier factor podría afectar a los resultados. Especificar los datos de prueba necesarios y la distribución de ellos (a menudo pasado por alto. . Es recomendable primero ejecutar una prueba de línea de base. TAREAS A REALIZAR Las tareas para realizar una prueba de este tipo serían las siguientes: Decidir usar recursos internos o externos para ejecutar las pruebas. Desarrollar un plan de alto nivel. y a menudo el fracaso de una prueba de rendimiento válida).10.identificado como el resultado de un problema de rendimiento. Planificación: Tiene como objetivo la correcta caracterización de la carga de trabajo. o Elección de las métricas adecuadas. o Caracterización de la carga de trabajo. Es una investigación detallada de los componentes de la organización.Etapas Relevamiento: El objeto de esta fase es "Determinar la situación existente en el sistema actual". o Definición de Escenarios o Distribución de tareas o Coordinación con encargados de Servidor de Pruebas . Construcción: Tiene como Objetivo la Construcción de los Test Scripts y la: o configuración del ambiente de pruebas. o Obtención de requisitos. o Elección del tipo de pruebas. o Descripción del sistema a probar. Determinar el tiempo de respuesta. En general. este proceso debe ser revisado periódicamente durante todo el ciclo de vida del proyecto. la utilización de los recursos y los objetivos y limitaciones. sacar conclusiones y proponer recomendaciones de cambio. Identificar el entorno de pruebas. Tener un profundo conocimiento de todo el entorno de prueba desde el principio permite diseños más eficientes de pruebas y la planificación y ayuda a identificar problemas en las pruebas en fases tempranas del proyecto. El entorno físico incluye hardware. el rendimiento. procesarla de manera que se pueda interpretar. . Ejecución: Tiene como objetivo correr los Test Scripts desarrollados en la etapa de construcción. o Dependiendo del tamaño del proyecto puede ocurrir 1 o varias veces. Además. Identificar los criterios de aceptación de rendimiento. Actividad 2. así como las herramientas y recursos de que dispone el equipo de prueba. mediante pruebas de rendimiento para evaluar qué combinación de la configuración da lugar a un funcionamiento óptimo. por ejemplo. el rendimiento al negocio. software y configuraciones de red. o Recopilación de Resultados o Foco en métricas más significativas o Definición de gráficos más adecuados para mostrar la información o Proponer recomendaciones en función de los resultados obtenidos Actividades Actividad 1. o Se registran las fecha y hora de ejecución Análisis: Tiene como Objetivo recabar toda la información generada por las pruebas. y la utilización de los recursos al sistema. el tiempo de respuesta concierne al usuario. Identificar el entorno físico de pruebas y el entorno de producción. identificar criterios de éxito del proyecto que no hayan sido recogidos por los objetivos y limitaciones. En algunas situaciones. determinar la variabilidad de los usuarios y la forma de simular esa variabilidad. los datos de las pruebas. así como las características y componentes disponibles para la prueba. Analizar los datos. Ejecutar y monitorizar las pruebas. y recoger los resultados. Desarrollar las pruebas de rendimiento de acuerdo con el diseño del plan. Actividad 6. ejecutarlo y analizarlo. Actividad 7. . Identificar los principales escenarios. Configurar el entorno de prueba. y establecer las métricas a recoger. y toda la información deseada se ha reunido. Consolidar y compartir los resultados de la prueba. Analizar los resultados. Aplicar el diseño de la prueba. Planificar y diseñar las pruebas. Consolidar esta información en uno o más modelos de uso del sistema a implantar. Actividad 4. Ejecutar pruebas válidas para analizar. como con un equipo multidisciplinario. mientras se monitoriza la prueba y su entorno. las pruebas han acabado para el escenario definido por la configuración. Preparar el entorno de prueba. Ejecutar la prueba. Actividad 5. tanto individualmente. ninguno de los umbrales establecidos han sido rebasados. Volver a priorizar el resto de las pruebas y volver a ejecutarlas de ser necesario. definir los datos de las pruebas. realizar un informe y repetirlo. Validar las pruebas. Cuando todas las métricas estén dentro de los límites aceptados. herramientas y recursos necesarios para ejecutar cada una de las estrategias. Asegurarse de que el entorno de prueba se ha preparado para la monitorización de los recursos según sea necesario. Actividad 3. incluyendo Vista extendida del log donde se ven los valores de los parámetros y los mensajes del servidor. Gran cantidad de facilidades para data entry. Java. JDBC WebLoad LoadRunner Soporta muchos. El facilidades de donde se Entonces cual debug en los ven los hay muchos muestra los scripts calores GUI pedidos y de los Listeners. Es posible grabar scripts con multi protocolo Ejecución de Vista Es una Vista los extendida herramienta extendida scripts y del log GUI. del log. Playback funciones HTTP/S. en el control „Users Gran cantidad de facilidades para data entry. HERRAMIENTAS OpenSTA HTTP 1. AJAX. Tiene una opción para hacer debug en el generador de scripts. Web services. La parametrizaci ón se puede hacer por interfaz. También permite ver y comparar la versión grabada de la pagina y los mensajes del servidor.0 / 1. ActiveX. los usados para mensajes capturar la del grabación y servidor. WAP.1 / HTTPS (SSL). Parametrizaci ón Cambio dinámico de valores para variables pasadas desde el cliente Gran cantidad de facilidades para data entry. Tiene una opción de grabación por multiprotocolo CRITERIO DE DESCRIPCION EVALUACION Protocolos Los protocolos de comunicación que pueden ser capturados.11. Los protocolos son cargados por ítem. incluyendo interfaces .FTP.2. SOAP/XM L JMeter HTTP. los parámetro los cuales datos de sy son respuesta. manipulados y simulados por la aplicación. replicar los mensajes. SOAP/XMLR PC. Genera repotes automáticos en Word. permite. interfaces Wizard para generar automática mente datos de prueba. incluyendo Parameters‟. El usuario puede crear sus propias vistas de las estadísticas que estos reportes muestran. Se puede ir cambiando de reportes gráficos o textuales (Tablas) . Posee una gran cantidad de gráficos sofisticados con muchísimas facilidades. OpenSTA JMeter No lo No lo permite. Gráficos Puede crear simples y gráficos pero suficientes no reportes como para analizar los resultados de carga y uso de recursos. Se pueden obtener reportes por cada usuario simulado. WebLOAD Console muestra reportes online de las sesiones que están corriendo. WebLoad No lo permite en la version Open Source Wizard para generar automáticame nte datos de prueba LoadRunner Puede emular diferentes velocidades de la red durante la ejecución. Pero puede programarse en JAVA interfaces Wizard para generar automática mente datos de prueba.al servidor durante el POST para asegurar una simulación mas real del comportamient o CRITERIO DE DESCRIPCION EVALUACION Simulación Habilidad de de la emular las velocidad de diferentes conexión de velocidades de los usuarios la red que pueden ser utilizadas por los usuarios Reportes y Facilidades análisis para examinar e investigar los resultados de las pruebas incluyendo contadores y recursos monitoreados. Los gráficos pueden ser exportados a Excel. El framework de WebLoad es flexible Librerías adicionales en TSL o C . EJEMPLO Caso: Fórmula para calcular el rendimiento de una página web 𝑠𝑢𝑚𝑎 𝑑𝑒 𝑙𝑎 𝑣𝑒𝑙𝑜𝑐𝑖𝑑𝑎𝑑 𝑑𝑒𝑙 𝑝𝑟𝑜𝑐𝑒𝑠𝑎𝑑𝑜𝑟 𝑥 𝑝𝑟𝑜𝑐𝑒𝑠𝑎𝑑𝑜𝑟 𝑑𝑒 𝑢𝑠𝑜𝑛ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑠𝑜𝑙𝑖𝑐𝑖𝑡𝑢𝑑𝑒𝑠 𝑝𝑜𝑟 𝑠𝑒𝑔𝑢𝑛𝑑𝑜 Las pruebas de carga en una página ASP pueden llegar al máximo de su capacidad cuando alcanzan las 800 solicitudes por segundo y un 85 por ciento del uso del procesador en el servidor Web.000 ciclos por segundo).000. Además al ser OpenSour ce Funciones Beanshell/JA VA pueden ser definidas y ser usadas como plug-in Permite agregar objetos Java. 2. limitado por las capacidades funcionales de la herramienta.12. Pueden escribirse módulos en SCL. el coste por página puede calcularse de la siguiente forma: . ActiveX o COM en los test Scripts. Si el servidor Web dispone de cuatro procesadores a 700 MHz (700.Extensibilidad La habilidad de incrementar la funcionalidad de la herramienta. Available from: www. Performance Testing. 5 . 2009. Available from: http://www. Pruebas de rendimiento del software. Software de pruebas de rendimiento. 2012 [cited 2012 11 11. 1st ed. WIKIPEDIA. I. 2009.sqaforums. NEW YORK: AMAZON. SARCO JP. 1st ed.pdf%3Farnumber%3D5463653&authDecision=-203.COM .org/wiki/Software_performance_testing. [Online]. Bibliografía 3 . 6 . 2012 [cited 2012 10 23. [Online]. 2012 [cited 2012 11 09. NEW YORK: AMAZON. Molyneaux.. 2O12 [cited 2012 11 11. Testing en Español. 2012 [cited 2012 10 27. 4 . [Online]. Available from: http://wapedia. [Online]. [Online].ieee. The Art of Application Performance Testing.. WIKIPEDIA. NEWYORK. wikipedia.com/attachments/524220-TestingdePerformancePorJosePabloSarco.wordpress.. The Art of Application Performance Testin. 2012 [cited 2012 11 11.3.. Molyneaux I. Molyneaux I. 2012 [cited 2012 11 11. International Software Testing Qualification Board (Comité Internacional de Calificación de Pruebas de Software). 9 . NEW YORK..istqb.ieee. 1st ed. 2009.org/iel5/5463512/54 63636/05463653. 7 .n. Molyneaux. The Art of Application Performance Testing. IEEE. I. AMAZON . The Art of Application Performance Testing.com/performance-testing/.mobi/es/Pruebas_de_rendimiento_del_software.pdf. TESTING DE PERFONCE. . 1 1 .. ISTQB. editor. Available from: http://ieeexplore.org/Xplore/login. editor. 1st ed.mobi/es/Pruebas_de_rendimiento_del_software. 1 0 .jsp?url=http://ieeexplore. Available from: http://en. 2 .org. 8 . IEEE . [Online]. 2009. Available from: http://josepablosarco. AMAZON. Available from: http://wapedia. [Online].wikipedia.. 1 .Instituto de Ingeniería Eléctrica y Electrónica. Pruebas de rendimiento del software.