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.

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 línea base para futuras pruebas de regresión2.

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 caídas o las pruebas de estrés3.

Las pruebas de rendimiento sólo deben hacerse después de las pruebas de integración del sistema

Aunque esta es la norma común en la industria, las pruebas de rendimiento también pueden realizarse mientras se realiza el desarrollo inicial de la

2  Pruebas de regresión 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 aplicación. 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. 

aplicación. Este tipo de enfoque se conoce como pruebas de rendimiento tempranas. Este enfoque garantizaría un desarrollo holístico de la aplicación manteniendo los parámetros de rendimiento en mente. Por lo tanto, 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, se reduce en gran medida.

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. En sí mismos, los scripts, aunque importantes, son sólo uno de los componentes de las pruebas de rendimiento. 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.

2.4. LAS ESPECIFICACIONES DE RENDIMIENTO (4)

Es fundamental detallar las especificaciones de rendimiento (requisitos) y documentarlas en algún 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 diseño. Sin embargo, con frecuencia las pruebas de rendimiento no se realizan teniendo en cuenta alguna especificación, es decir, nadie ha expresado cual es el tiempo máximo de respuesta aceptable para un número determinado de usuarios. Las pruebas de rendimiento se utilizan con frecuencia como parte del proceso de ajuste de la ejecución. La idea es identificar el "eslabón más débil", pues hay inevitablemente una parte del sistema que, si responde con mayor rapidez, eso se traducirá en un funcionamiento del sistema global más rápido. 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, número 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 estadísticas de rendimiento. La especificación de rendimiento, como mínimo, debería responder a las siguientes preguntas:

¿Cuál es el alcance, en detalle, de la prueba de rendimiento? ¿Qué subsistemas, interfaces, componentes, etc, están dentro y fuera del ámbito de ejecución de esta prueba?

Para las interfaces de usuario involucradas, ¿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, 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, 40% buscando, 30% seleccionando elemento, 10% comprando).

¿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, 20% del volumen de trabajo para B, 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.5. MEDICION DE RENDIMIENTO (5)

¿Cómo 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 aplicación proporciona un servicio a los usuarios finales.

2.5.2. INDICADORES DE EFICIENCIA

Son el rendimiento y la utilización, medir qué tan bien (o no) una aplicación hace uso del entorno de la aplicación. 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. La falta de disponibilidad es importante porque muchas aplicaciones tendrán un costo de negocios importante, incluso para un corte pequeño. 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.

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

Tiempo de respuesta

Es la cantidad de tiempo que le toma a la aplicación responder a una petición 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 aplicación y llegada completa de la respuesta al usuario en la estación de trabajo.

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.

Utilización

El porcentaje de la capacidad teórica de un recurso que se está utilizando. 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.

En conjunto, estos indicadores pueden darnos una idea exacta de cómo una aplicación se está realizando y su impacto, en términos de capacidad y en el entorno de la aplicación.

2.6. PRE-REQUISITOS PARA PRUEBA DE RENDIMIENTO

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

A. CONDICION DE PRUEBA

De acuerdo con ISTQB (6), 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. 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 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.

Nota: Una prueba de condición 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 ejecución 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 extenderán a través de la implementación. Cuanto más tarde se detecte un defecto de rendimiento, mayor será el costo de la rehabilitación. Esto es cierto en el caso de las pruebas funcionales, pero más aún con pruebas de rendimiento, debido a la naturaleza de extremo a extremo de su ámbito de aplicación.

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 cómo solucionar estos. 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. 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. Utiliza los principios y técnicas 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 desempeño y otros los objetivos de calidad. Si se encuentra un problema, también PASA identifica las estrategias para reducir o eliminar los riesgos.

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.

2.7.2. INGENIERIA DE RENDIMINETO

Es la etapa final donde se realizan los cambios necesarios (tunning)7 para alcanzar lo esperado por la aplicación, esto puede incluir cambios de código, 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.8. TIPOS DE PRUEBAS DE RENDIMIENTO (8)

2.8.1. PRUEBA DE LINEA BASE

Esto establece un punto de comparación 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 transacción con un único usuario virtual para un período de tiempo determinado o para un número determinado de iteraciones transacción. Esta ejecución 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 degradación del rendimiento que se produce en respuesta al creciente número de usuarios o el rendimiento.

2.8.2. PRUEBA DE CARGA (9)

Esta es la prueba de rendimiento clásico, donde se carga la aplicación hasta la concurrencia de destino, pero por lo general no más. 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 aproximación más cercana del uso de aplicaciones reales, y normalmente incluye una simulación de los efectos de interacción del usuario con el cliente.

2.8.2. PRUEBA DE STRESS

Esto tiene un objetivo muy diferente de una prueba de carga. Una prueba de Stress hace que la aplicación o alguna parte de la infraestructura fallen.El objetivo es determinar los límites superior o el tamaño de la infraestructura.

7 Etapa final en el que se efectúan cambios necesarios al software.

Por lo tanto, una prueba de Stress continúa hasta que se rompe algo: no hay más usuarios que pueden acceder, tiempo de respuesta superior al valor que se define como aceptable, o la aplicación no está disponible. El fundamento de las pruebas de estrés es que si nuestro objetivo es la simultaneidad. Los resultados de la capacidad de medir la tensión de prueba tanto como el rendimiento. Es importante que conozca sus límites máximos, particularmente si el crecimiento futuro del tráfico de aplicaciones es difícil de predecir.

2.8.3. 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. 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. 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. 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. 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.

2.8.4. PRUEBA DE HUMO (10)

La definición 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 sólo las transacciones que se han visto afectados por un cambio de código8.

Nota: Las pruebas de humo término se originó en la industria del hardware. 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, 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 identificado como el resultado de un problema de rendimiento. A menudo se utiliza para aislar y confirmar el fallo de dominio.

8 Es una prueba muy rápida para ver que cambios ocasiono al modificar una línea de código o una transacción.

Es recomendable primero ejecutar una prueba de línea de base, la carga, y prueba de Stress. 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, como es el requisito para las pruebas de aislamiento, que en gran medida determinará cuáles son los problemas que se descubran.

2.9. 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, en función

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, información del entorno, etc).

Elegir la/s herramienta/s de prueba. Especificar los datos de prueba necesarios y la distribución de ellos (a menudo

pasado por alto, y a menudo el fracaso de una prueba de rendimiento válida). Desarrollar scripts de prueba de concepto para cada aplicación/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 idéntico hardware a la

plataforma de producción), configurar los router, aislar la red (no queremos alterar los resultados por parte de otros usuarios), desplegar la aplicación en el servidor, desarrollar la base de datos de prueba, etc.

Ejecutar las pruebas, probablemente en repetidas ocasiones (iterativamente9), a fin de ver si el desconocimiento de cualquier factor podría afectar a los resultados.

Analizar los resultados - ya sea de aceptando/rechazando, o investigación el camino crítico y recomendando medidas correctivas.

2.10. METODOLOGIA DE PRUEBAS DE RENDIMIENTO (11)

9 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 situación existente en el sistema actual". Es una investigación detallada de los componentes de la organización.

Planificación:

Tiene como objetivo la correcta caracterización de la carga de trabajo. o Obtención de requisitos. o Elección de las métricas adecuadas. o Elección del tipo de pruebas. o Descripción del sistema a probar. o Caracterización de la carga de trabajo.

Construcción:

Tiene como Objetivo la Construcción de los Test Scripts y la:o configuración del ambiente de pruebas.o Definición de Escenarioso Distribución de tareas

o Coordinación con encargados de Servidor de Pruebas

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.o Se registran las fecha y hora de ejecución

Análisis:

Tiene como Objetivo recabar toda la información generada por las pruebas, procesarla de manera que se pueda interpretar, sacar conclusiones y proponer recomendaciones de cambio.

o Recopilación de Resultadoso Foco en métricas más significativaso Definición de gráficos más adecuados para mostrar la informacióno Proponer recomendaciones en función de los resultados obtenidos

Actividades

Actividad 1.

Identificar el entorno de pruebas. Identificar el entorno físico de pruebas y el entorno de producción, así como las herramientas y recursos de que dispone el equipo de prueba. El entorno físico incluye hardware, software y configuraciones de red. 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. En algunas situaciones, este proceso debe ser revisado periódicamente durante todo el ciclo de vida del proyecto.

Actividad 2.

Identificar los criterios de aceptación de rendimiento. Determinar el tiempo de respuesta, el rendimiento, la utilización de los recursos y los objetivos y limitaciones.

En general, el tiempo de respuesta concierne al usuario, el rendimiento al negocio, y la utilización de los recursos al sistema. Además, 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é combinación de la configuración da lugar a un funcionamiento óptimo.

Actividad 3.

Planificar y diseñar 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 métricas a recoger. Consolidar esta información en uno o más 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 características y componentes disponibles para la prueba. Asegurarse de que el entorno de prueba se ha preparado para la monitorización de los recursos según sea necesario.

Actividad 5.

Aplicar el diseño de la prueba. Desarrollar las pruebas de rendimiento de acuerdo con el diseño 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 válidas 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 métricas estén dentro de los límites aceptados, ninguno de los umbrales establecidos han sido rebasados, y toda la información deseada se ha reunido, las pruebas han acabado para el escenario definido por la configuración.

2.11. HERRAMIENTAS

CRITERIO DE EVALUACION

DESCRIPCION OpenSTA JMeter WebLoad LoadRunner

Protocolos Los protocolos decomunicación quepueden sercapturados,manipulados ysimulados por laaplicación.

HTTP 1.0 / 1.1 / HTTPS (SSL),SOAP/XML

HTTP,FTP,SOAP/XMLRPC,JDBC

HTTP/S, WAP,AJAX, ActiveX,Java, Webservices. Esposible grabarscripts con multiprotocolo

Soporta muchos. Losprotocolos son cargados porítem. Tiene una opción degrabación por multi-protocolo

Playbackfunciones

Ejecución de losscripts yfacilidades dedebug en los scripts

Vista extendidadel log donde seven los caloresde losparámetros ylos mensajesdel servidor.

Es unaherramientaGUI. Entonceshay muchosGUI Listeners,los cuales sonusados paracapturar lagrabación yreplicar losmensajes.

Vista extendidadel log. El cualmuestra lospedidos y losdatos derespuesta.

Vista extendida del logdonde se ven los valores delos parámetros y losmensajes del servidor.También permite ver ycomparar la versión grabadade la pagina y los mensajesdel servidor. Tiene unaopción para hacer debug enel generador de scripts.

Parametrización

Cambio dinámicode valores para

Gran cantidadde

Laparametrización se puede

Gran cantidad defacilidades

Gran cantidad de facilidadespara data

variables pasadasdesde el cliente alservidor duranteel POST paraasegurar unasimulación masreal delcomportamiento

facilidadespara data entry,incluyendointerfacesWizard para generarautomáticamente datos deprueba.

hacer por interfaz, en elcontrol ‘Users Parameters’.

paradata entry,incluyendointerfaces Wizardpara generarautomáticamentedatos de prueba.

entry, incluyendointerfaces Wizard paragenerar automáticamentedatos de prueba

CRITERIO DE EVALUACION

DESCRIPCION OpenSTA JMeter WebLoad LoadRunner

Simulaciónde lavelocidad deconexión delos usuarios

Habilidad de emular las diferentes velocidades de la red que pueden ser utilizadas por los usuarios

No lo permite.

No lo permite.Pero puedeprogramarseen JAVA

No lo permite enla version OpenSource

Puede emular diferentesvelocidades de la red durantela ejecución.

Reportes yanálisis

Facilidades para examinar e investigar los resultados de las pruebas incluyendo contadores y recursos monitoreados.

Gráficos simples y suficientes como para analizar los resultados de carga y uso de recursos. Los gráficos pueden ser exportados a Excel.

Puede crear gráficos pero no reportes

WebLOADConsole muestrareportes online delas sesiones queestán corriendo.El usuario puedecrear sus propiasvistas de lasestadísticas queestos reportesmuestran. Sepuede ircambiando dereportes

Posee una gran cantidad degráficos sofisticados conmuchísimas facilidades.Genera repotes automáticosen Word. Se pueden obtenerreportes por cada usuariosimulado.

gráficoso textuales(Tablas)

Extensibilidad La habilidad deincrementar lafuncionalidad de laherramienta.

Puedenescribirsemódulos enSCL. Ademásal serOpenSource

FuncionesBeanshell/JAVA puedenser definidasy ser usadascomo plug-in

Permite agregarobjetos Java,ActiveX o COM enlos test Scripts. Elframework deWebLoad esflexible

Librerías adicionales en TSL oC , limitado por lascapacidades funcionales de laherramienta.

2.12. EJEMPLO

Caso: Fórmula para calcular el rendimiento de una página web 𝑠𝑢𝑚𝑎 𝑑𝑒 𝑙𝑎 𝑣𝑒𝑙𝑜𝑐𝑖𝑑𝑎𝑑 𝑑𝑒𝑙 𝑝𝑟𝑜𝑐𝑒𝑠𝑎𝑑𝑜𝑟 𝑥 𝑝𝑟𝑜𝑐𝑒𝑠𝑎𝑑𝑜𝑟 𝑑𝑒 𝑢𝑠𝑜𝑛ú𝑚𝑒𝑟𝑜 𝑑𝑒 𝑠𝑜𝑙𝑖𝑐𝑖𝑡𝑢𝑑𝑒𝑠 𝑝𝑜𝑟 𝑠𝑒𝑔𝑢𝑛𝑑𝑜

¿ costo , enciclossolicitud (o Hz/RPS)

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. Si el servidor Web dispone de cuatro procesadores a 700 MHz (700.000.000 ciclos por segundo), el coste por página puede calcularse de la siguiente forma:

(4 x700000000cycless

x 0.85)

800requests

=2975000cyclesrequest

3. Bibliografía

x1. wikipedia. Software de pruebas de rendimiento. [Online].; 2012 [cited 2012 11 11.

Available from: http://en.wikipedia.org/wiki/Software_performance_testing.2. IEEE. IEEE - Instituto de Ingeniería Eléctrica y Electrónica. [Online].; 2012 [cited

2012 11 11. Available from: http://ieeexplore.ieee.org/Xplore/login.jsp?url=http://ieeexplore.ieee.org/iel5/5463512/5463636/05463653.pdf%3Farnumber%3D5463653&authDecision=-203.

3. WIKIPEDIA. Pruebas de rendimiento del software. [Online].; 2012 [cited 2012 10 23. Available from: http://wapedia.mobi/es/Pruebas_de_rendimiento_del_software.

4. WIKIPEDIA. Pruebas de rendimiento del software. [Online].; 2012 [cited 2012 10 27. Available from: http://wapedia.mobi/es/Pruebas_de_rendimiento_del_software.

5. Molyneaux I. The Art of Application Performance Testin. 1st ed. AMAZON.COM , editor. NEW YORK: AMAZON; 2009.

6. ISTQB. International Software Testing Qualification Board (Comité Internacional de Calificación de Pruebas de Software). [Online].; 2012 [cited 2012 11 09. Available from: www.istqb.org.

7. Testing en Español. Performance Testing. [Online].; 2O12 [cited 2012 11 11. Available from: http://josepablosarco.wordpress.com/performance-testing/.

8. Molyneaux. I. The Art of Application Performance Testing,n. 1st ed. AMAZON , editor. NEW YORK: AMAZON; 2009.

9. Molyneaux I. The Art of Application Performance Testing. 1st ed. NEW YORK; 2009.10.

Molyneaux. I. The Art of Application Performance Testing. 1st ed. NEWYORK; 2009.

11.

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