Ingeniera de Software Orientada a Objetos

Unidad 6: Verificacin y validacin de software

Tema 12: Pruebas de Software (PARTE A)

<<Atrs Objetivos: 1. 2.
Analizar los diferentes mtodos, tcnicas y estrategias empleadas en la verificacin y validacin de software. Adquirir habilidades en la planificacin, diseo y ejecucin de pruebas de programas

Contenidos:
Fallas y faltas de software Verificacin y validacin de software Tcnicas estticas Tcnicas dinmicas: pruebas de programas Planificacin de pruebas Pruebas de unidades: estrategias caja blanca y caja negra Pruebas de integracin: mtodos ascendentes, descendentes y combinados Pruebas del sistema Pruebas de aceptacin Depuracin de programas

Principales referencias bibliogrficas:

(Pfleeger, 1998, Caps. 7 y 8) (Conger, 1994, Cap. 17) (Ince, et al., 1993, Caps. 13-15) (Sommerville, 1992, Cap. 19, 22-24)

Fallas y faltas de software

"Una falta [fault] ocurre cuando un humano comete un error al ejecutar alguna actividad de software. Por ejemplo, un diseador puede interpretar equivocadamente un requerimiento y crear un diseo que no sastiface las necesidades reales del usuario... Una falla puede residir en cualquier producto del desarrollo o mantenimiento de software". Una falla [failure] ocurre cuando el sistema se separa de su comportamiento esperado, es decir, no ejecuta de acuerdo a lo requerido. Puede ser descubierto durante la entrega, las pruebas, la operacin o el mantenimiento del sistema. La falta es vista por los diseadores del sistema desde un punto de vista interno del sistema, mientras que las fallas son vistas desde el punto de vista del usuario. Tipos de faltas:

Faltas algortmicas: Ocurren cuando un componente de la lgica o algoritmo de un programa no produce la salida esperada para una entrada dada.

Faltas de computacin y precisin: Ocurren cuando la implementacin de una frmula o procedimeinto es errneo o no produce un resultado preciso.

Faltas de documentacin: La documentacin no se corresponde con el programa. Faltas de sobrecarga o estrs: Ocurre cuando las estructuras de datos exceden sus capacidades especificadas. Faltas de capacidad o lmites: Ocurren cuando el rendimiento del sistema se vuelve inaceptable o excede sus lmites establecidos. Faltas temporales o de coordinacin: Ocurren cuando el programa que controla la coordinacin de varios procesos o su secuenciacin no opera adecuadamente.

Faltas de rendimiento: El sistema no ejecuta a la velocidad especificada. Faltas de recuperacin: Ocurren cuando se detecta una falla y el sistema no se comporta del modo esperado.

Faltas de hardware/software: Cuando el sistema H/S no opera de acuerdo a las condiciones o procedimientos de operacin documentados.

Faltas de estndares y procedimientos: El programa no satisface los estndares y procedimientos de software establecidos en la organizacin.

Clasificacin de defectos de HP:

Verificacin y Validacin de Software (V&V):

V&V es un proceso de Ingeniera de Software que asegura que el sistema producido satisface sus requerimientos y que estos requerimientos, a su vez, satisfacen las necesidades de los usuarios del producto. V&V es un proceso que cubre todo el ciclo de desarrollo de software: o o

se inicia con la revisin de los requerimientos producidos en la fase A&ER y culmina con las pruebas del producto.

Tiene dos objetivos principales [Sommerville, 1992]: Descubrir errores o defectos en el sistema. Evaluar si el sistema producido es utilizable en su ambiente operacional. La Verificacin es el proceso de determinar si el producto de una fase dada satisface los requerimientos o especificaciones de la(s) fase(s) anteriores. Implica establecer una relacin entre el producto y sus especificaciones. Estamos construyendo correctamente el producto ? La Validacin es el proceso de evaluar el producto al final de su desarrollo para determinar si cumple o no con los requerimientos establecidos. Implica establecer la calidad y adecuacin del producto con respecto a su uso. Hemos construido el producto correcto ? Taxonoma de las tcnicas de V&V:

TECNICAS ESTATICAS
Estn relacionadas con el anlisis de los modelos del sistema: requerimientos, diseos y listados de programas. Involucra la revisin o anlisis formal o informal de requerimientos, diseos o programas.

TECNICAS DINAMICAS
Estn relacionados con sistema o su prototipo. los programas del

Involucran las PRUEBAS DE PROGRAMAS, es decir la ejecucin de los programas con el propsito de encontrar errores.

Verifican la correspondencia entre los programas y sus especificaciones. No implican la ejecucin de un programa. Se basan en el examen del programa y la deteccin de fallas antes de su ejecucin. Tipos:

Demustran que el sistema producido prototipo) es operacionalmente til.

(o

Estn orientadas a detectar y corregir las fallas de los programas

Tipos: Pruebas de software: Recorridos estructurados Inspecciones de cdigo Anlisis esttico Verificacin formal

Pruebas de Componentes:

Pruebas de Unidad Pruebas de Integracin Pruebas de Aceptacin

Pruebas Especficas:

Pruebas Funcionales Pruebas de Desempeo Pruebas de Tensin Pruebas Estructurales

Depuracin

Tcnicas Estticas de V&V

1) Recorridos Estructurados (Walkthrough): o Tcnica grupal orientada a la deteccin de errores mediante la revisin metdica de un producto generado durante el proceso de desarrollo de software. o Un equipo, de al menos tres personas, someten el producto (especificacin de requerimientos, diseo, listado o prueba) a una revisin metdica en busca de errores, inconsistencias, desviaciones con respecto a las normas establecidas, etc. (ver Figura 1).

Figura 1. Participantes del proceso de Revisin Estructurada

Pasos de la Revisin Estructurada: Revisin preliminar: Convocatoria a la reunin y entrega del producto Identificacin individual de errores y elaboracin de las Listas de Errores y Sugerencias Reunin de recorrido: Introduccin: Seleccin del moderador y del secretario, definicin de objetivos y alcances. Explicacin del producto: Exposicin del producto, revisin y discusin de las Lstas de Errores y Sugerencias. Conclusin: Discusin final y redaccin de la Lista de Acciones a seguir. Seguimiento de los puntos de accin acordados: Elaboracin, revisin y ejecucin de un Plan de Accin basado en la Lista de Acciones.

2) Inspeccin de Diseo y Cdigo: o Proceso similar al recorrido, pero emplea una lista de inspeccin de elementos de diseo o de cdigo previamente elaborada.

la Lista de Inspeccin es utilizada durante la sesin para detectar errores en el producto.

Figura 2. Participantes del proceso de Inspeccin de Diseo y Cdigo

Pasos de la Inspeccin de Diseo Cdigo: Etapa de Planificacin: Seleccin del grupo, organizacin de la sesin y distribucin del material del producto a inspeccionar. Etapa Preliminar: Descripcin general del producto a inspeccionar e inspeccin individual del producto. Etapa de Inspeccin: Identificacin y registro de errores siguiendo la Lista de Inspeccin. Etapa de Correcciones: Localizacin de errores, definicin de cambios y correcciones la producto inspeccionado (realizada por el Autor). Etapa de Re-inspeccin: el producto corregido se somete de nuevo a una segunda inspeccin para asegurar que los cambios no introducen nuevos errores. Elementos de Inspeccin del Diseo: Cumplimiento de requerimientos Especificaciones de: estructura, componentes e interfaces

Consistencia con respecto a estndares Elementos de Inspeccin de Cdigo:

 Declaracin de datos Referencia a datos Expresiones aritmticas Expresiones de comparacin Flujo de control Interfaces entre mdulos Proposiciones de entrada y salida Estilo de programacin
Ejemplo de una lista parcial de errores frecuentes en la "Interface entre mdulos": Coinciden en nmero, orden, tipo y tamao los parmetros reales y formales de cada interconexin por llamada entre mdulos? Se corresponden los atributos (magnitud y dimensin) de cada parmetro formal con el correspondiente parmetro real? Se pasan constantes como parmetros modificables o variables? Se altera, en el mdulo, o se intenta devolver el valor de un parmetro declarado como parmetro por valor? Si existen variables globales, tienen estas la misma definicin y los mismos atributos de magnitud y dimensin en todos los mdulos en que son utilizadas? Los nombres de los parmetros reales y formales son semnticamente representativos?

Tcnicas Dinmicas de V&V: Pruebas de Programas

Son tcnicas dinmicas que ejecutan un programa con el fin expreso de encontrar errores.

Parten del supuesto de que todo programa contiene errores.

Una prueba se considera exitosas si es capz de detectar errores (Las pruebas son procesos destructivos) No se puede probar exhaustivamente un programa

=> No se puede garantizar que un programa est libre de errores;

Un error de software ocurre cuando algn aspecto del programa es incompleto, inconsistente o incorrecto. Error Tipo 1 (error de omisin): el programa no hace lo que se supone debe hacer. o Error Tipo 2 (error de cometido): el programa hace lo que se supone no debe hacer. Algunos principios de pruebas [Meyer, 1983]: o La definicin del resultado esperado a la salida de un programa es una parte fundamental de todo caso de prueba (i.e. del conjunto de datos de prueba). o Un programador debe evitar probar sus propios programas. o Los resultados de cada prueba deben ser analizados cuidadosamente. o Los casos de prueba se deben escribir tanto para condiciones de entrada invlidas e inesperadas como para condiciones vlidas y esperadas. o La probabilidad de encontrar errores adicionales en una seccin del programa es proporcional al nmero de errores ya encontrados. o Evite los casos de prueba desechables (casos diseados "al vuelo"). El proceso de prueba de programas segn [Conger, 1994]:

El proceso de pruebas segn [Pfleeger, 1998]:

Planificacin de Pruebas
El Plan de Pruebas especifica para cada tipo de pruebas (pruebas de unidades, mdulos, subsistemas, sistema y aceptacin) los siguientes aspectos [Ince & Sharp, 1993]: 1) Los objetivos de las pruebas

Qu se espera alcanzar con este tipo de prueba?

2) Los criterios que determinan cuando el tipo de prueba es completo, es decir, cuando se debe dar por terminada un tipo de prueba.

CRITERIO 1: La prueba se da por terminada cuando se han ejecutado todos los casos de pruebas y estos se han basado en un conjunto de mtodos de pruebas pre-establecido (P.ej. para la prueba de mdulos los casos incluyen el criterio de cobertura de multicondicin y el anlisis de los valores lmites).

CRITERIO 2: La prueba se termina cuando se han detectado un nmero determinado de errores. Esto implica estimar el nmero total de errores del programa y el porcentaje de errores que pueden ser encontrados con las pruebas. CRITERIO 3: La prueba finaliza cuando el nmero de errores encontrados por unidad de tiempo (p.ej. semanal) decrece. Se emplea una grfica Numero de Errores Encontrados vs. Unidad de tiempo para determinar cuando finalizar.

3) Programacin de actividades de pruebas (Calendario de Pruebas) 4) Recursos requeridos (personal, H/S requerido para realizar las pruebas) 5) Responsabilidades de los miembros de los grupos de prueba y desarrollo. 6) Determinacin de las estrategias de prueba (i.e., pruebas de funcin, desempeo, tensin, estructurales, etc.) y los procedimientos de identificacin, generacin y documentacin de los casos de prueba que sern utilizados. Procedimientos de prueba: Descripcin de cada prueba incluyendo casos de prueba, herramientas H/S de prueba que se emplearn, instrucciones para ejecutar la prueba y resultados esperados.

Pruebas de Unidades
Estn dirigidas a probar individualmente las unidades ms pequeas que componen un programa, i.e., funciones, procedimientos, subrutinas o mtodos. 1) ESTRATEGIA DE PRUEBA CAJA NEGRA: Se ignora la estructura y comportamiento de la unidad a probar. Los casos de prueba se disean en base a los requerimientos especificados para los datos de entrada y salida a la unidad. Mtodos conocidos para especificar casos de prueba: - Particiones de equivalencias - Anlisis de los valores lmites PARTICIONES DE EQUIVALENCIA: v El dominio de entrada de una unidad se divide en un nmero finito de clases de

equivalencia y los casos de prueba se disean seleccionando datos representativos de cada clase. v Para cada condicin de entrada (argumento o variable) se definen dos tipos de clases de equivalencia: - ClasesVlidas: conjuntos de valores de entrada vlidas ( Ej. 0 = NOTA = 20). - Clases Invlidas: conjuntos de valores de entrada invlidos (Ej. NOTA < 0 y NOTA > 20). v El diseo de los casos de prueba consiste en: - Asignar un nmero nico a cada clase de equivalencia. - Escribir casos de pruebas que cubran tantas clases vlidas como sea posible hasta cubrir todas las clases vlidas especificadas. - Cubrir todos las clases de equivalencias invlidas incorporando a cada caso una y sla una clase invlida. ANALISIS DE LOS VALORES LIMITES: v Es una forma de particionamiento de equivalencia que considera los valores limites de cada clase en lugar de cualquier valor de la clase. v Los casos de prueba se disean tomando los valores mnimos y mximos de cada clase de equivalencia vlida, as como los valores lmites de cada clase invlida. v Ejemplo: para la clase vlida (0 = NOTA = 20) se seleccionan como caso de pruebas los valores 0 y 20. para las clases invlidas (NOTA < 0) y (NOTA > 20), se selecionan los valores -1 y 21, respectivamente. 2) ESTRATEGIA DE PRUEBA CAJA BLANCA: Toma en consideracin la estructura o lgica interna de la unidad

 Los casos de prueba ejercitan la estructura recorriendo rutas del flujo de control pre-determinadas en base a los siguientes criterios: CRITERIO DE COBERTURA DE INSTRUCCIONES Cada instruccin de la unidad debe ejecutarse al menos una vez. CRITERIO DE COBERTURA DE DECISIONES: Los casos de prueba deben asegurar que cada una de las ramas de cada estructura de decisin que tenga la unidad se ejercite al menos una vez. CRITERIO DE COBERTURA DE CONDICION: Cada condicin individual en una decisin debe ser ejecutada con todos los resultados posibles al menos una vez. Ejemplo: En la instruccin "IF (SUELDO > 300000 OR POSICION = "gerente") THEN .... ELSE ... " se deben probar ambas condiciones lgicas.

Un mtodo que incorpora los tres tipos de coberturas se describe en [Sommerville,92]: Se deriva primero el GRAFO DE FLUJO de la unidad a probar. v En un Grafo de Flujo los nodos representan decisiones y los ejes el flujo de control. v Las instrucciones secuenciales (asignaciones, llamadas y E/S) se ignoran, excepto la inicial y final de la unidad. v Los subgrafos de flujo correspondientes a las estructuras de seleccin y decisin son los siguientes:

 Se determina el nmero de CAMINOS INDEPENDIENTES

Un cmino independiente en un Grafo de Flujo es un cmino que contiene al menos un eje que no est incluido en ningn otro cmino. El nmero de cminos independientes se determina mediante la COMPLEJIDAD CICLOMATICA del Grafo de Flujo.

CC(G) = Nmero de Ejes - Nmero de Nodos + 1 El nmero de casos de prueba requerido para ejercitar todas las condiciones de una unidad es igual a la complejidad ciclomtica de su grafo de flujo. Forma general de una tabla de Casos de Prueba: Nmero del Caso de Prueba Datos de Entrada Salida Esperada

Pruebas de Integracin
La prueba de integracin validan las conexiones entre unidades o mdulos empleando una o ms de las estrategias siguientes: 1) ESTRATEGIA DE INTEGRACION ASCENDENTE: o Se parte de las unidades de ms bajo nivel en la jerarqua modular del sistema y se procede a probar la integracin de unidades en subsistemas de abajo hacia arriba hasta llegar al programa principal.

 Pasos: Probar las unidades de ms bajo nivel separadamente [Ej. Probar E, F y G]. Probar la integracin de unidades en subsistemas [Ej. Probar S1(B,E,F); S2(C) y S3(D,G)] Probar el programa completo (Ej. Probar A integrando sus subsistemas S1, S2 y S3) Las pruebas de unidades e integracin requieren el uso de CONDUCTORES DE PRUEBA: programas que llaman a la unidad o subsistema en prueba, le suministran los datos de prueba y presentan los resultados obtenidos.

2) ESTRATEGIA DE INTEGRACION DESCENDENTE:

o Parte de la raz de la jerarqua modular del programa y procede a probar la integracin de unidades en subsistemas hasta llegar a las unidades de ms bajo nivel.

Pasos: Se prueba primero la raz usando TRONCOS o ESQUELETOS de las unidades llamadas por la raz. (Ej. probar A con troncos de B,C y D). Se reemplazan los troncos dependientes de la raz por sus unidades respectivas Se prueba cada una de estas unidades utilizando troncos para sus unidades dependientes. (Ej. probar B con troncos E y F) Se repite el proceso para cada nivel de la jerarqua hasta llegar a las unidades de ms nivel. Los troncos o esqueletos son unidades vacias que sirven para resolver la transferencia del flujo de control durante la llamada y la devolucin de valores a la unidad que lo llama. Ventajas:

Las unidades se pueden integrar a medida que se van desarrollando. Los troncos son reutilizables. No requiere conductores de prueba.

3) ESTRATEGIA DE INTEGRACION COMBINADA ( Sandwich):

o Utiliza una combinacin de la integracin descendente y la ascendente.

4) ESTRATEGIA DE INTEGRACION BIB-BANG:

Pruebas de rendimiento del software

Este artculo o seccin necesita referencias que aparezcan en una publicacin acreditada, como revistas especializadas, monografas, prensa diaria o pginas de Internet fidedignas.
Puedes aadirlas as o avisar al autor principal del artculo en su pgina de discusin pegando: {{subst:Aviso referencias|Pruebas de rendimiento

del software}} ~~~~

En la ingeniera del software, las pruebas de rendimiento son las pruebas que 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. Las pruebas de rendimiento son un subconjunto de la ingeniera de pruebas, una prctica informtica que se esfuerza por mejorar el rendimiento,

englobndose en el diseo y la arquitectura de un sistema, antes incluso del esfuerzo inicial de la codificacin.
ndice
[ocultar]

1 Introduccin

o o o o o

1.1 Pruebas de carga 1.2 Prueba de estrs 1.3 Prueba de estabilidad (soak testing) 1.4 Pruebas de picos (spike testing) 1.5 Pre-requisitos para las pruebas de carga

2 Mitos de las pruebas de rendimiento 3 Tecnologa 4 Especificaciones del rendimiento 5 Tareas a realizar 6 Metodologa

6.1 Metodologa de pruebas de rendimiento de aplicaciones Web

7 Vase tambin 8 Enlaces externos

Introduccin[editar editar cdigo]

Las pruebas de rendimiento pueden servir para diferentes propsitos. Pueden demostrar que el sistema cumple los criterios de rendimiento. Pueden comparar dos sistemas para encontrar cual de ellos funciona mejor. O pueden medir que partes del sistema o de carga de trabajo provocan que el conjunto rinda mal. Para su diagnstico, los ingenieros de software utilizan herramientas como pueden ser monitorizaciones que midan qu partes de un dispositivo o software contribuyen ms al mal rendimiento o para establecer niveles (y umbrales) del mismo que mantenga un tiempo de respuesta aceptable. Es fundamental para alcanzar un buen nivel de rendimiento de un nuevo sistema, que los esfuerzos en estas pruebas comiencen en el inicio del proyecto de desarrollo y se amplie durante su construccin. Cuanto ms se tarde en detectar un defecto de rendimiento, mayor es el coste de la solucin. Esto es cierto en el caso de las pruebas funcionales, pero mucho ms en las pruebas de rendimiento, debido a que su mbito de aplicacin es de principio a fin. En las pruebas de rendimiento, a menudo es crucial (y con frecuencia difcil de conseguir) que las condiciones de prueba sean similares a las esperadas en el uso real. Esto es, sin embargo, casi

imposible en la prctica. La razn es que los sistemas en produccin tienen un carcter aleatorio de la carga de trabajo y aunque en las pruebas se intente dar lo mejor de s para imitar el volumen de trabajo que pueda tener el entorno de produccin, es imposible reproducir exactamente la variabilidad de ese trabajo, salvo en el sistema ms simple. Los nuevos conceptos en la implementacin de la arquitectura (por ejemplo: SOA) han aadido complejidad adicional a las pruebas de rendimiento. Los servicios o recursos de la empresa (que comparten infraestructura o plataforma) requieren pruebas de rendimiento coordinadas (con la creacin del volumen y carga de todos los sistemas que comparten la infraestructura o plataformas) para reproducir realmente el estado del entorno de produccin. Debido a la complejidad, coste y tiempo necesario en torno a esta actividad, algunas organizaciones emplean herramientas que pueden mostrar y crear condiciones (tambin conocido como "ruido") en los entornos de pruebas de rendimiento para comprender la capacidad y las necesidades de recursos y verificar/validar los niveles de calidad.

Pruebas de carga[editar editar cdigo]

Este es el tipo ms sencillo de pruebas de rendimiento. Una prueba de carga se realiza generalmente para observar el comportamiento de una aplicacin bajo una cantidad de peticiones esperada. Esta carga puede ser el nmero esperado de usuarios concurrentes utilizando la aplicacin y que realizan un nmero especfico de transacciones durante el tiempo que dura la carga. Esta prueba puede mostrar los tiempos de respuesta de todas las transacciones importantes de la aplicacin. Si la base de datos, el servidor de aplicaciones, etc.. tambin se monitorizan, entonces esta prueba puede mostrar el cuello de botella en la aplicacin.

Prueba de estrs[editar editar cdigo]

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. Este tipo de prueba se realiza para determinar la solidez de la aplicacin en los momentos de carga extrema y ayuda a los administradores para determinar si la aplicacin rendir lo suficiente en caso de que la carga real supere a la carga esperada.

Prueba de estabilidad (soak testing)[editar editar cdigo]

Esta prueba normalmente se hace para determinar si la aplicacin puede aguantar una carga esperada continuada. Generalmente esta prueba se realiza para determinar si hay alguna fuga de memoria en la aplicacin.

Pruebas de picos (spike testing)[editar editar cdigo]

La prueba de picos, como el nombre sugiere, trata de observar el comportamiento del sistema variando el nmero de usuarios, tanto cuando bajan, como cuando tiene cambios drsticos en su carga. Esta

prueba se recomienda que sea realizada con un software automatizado que permita realizar cambios en el nmero de usuarios mientras que los administradores llevan un registro de los valores a ser monitorizados.

Pre-requisitos para las pruebas de carga[editar editar cdigo]

Un desarrollo estable de la aplicacin instalado en un entorno lo ms parecido al de produccin. El entorno de pruebas de rendimiento no debe cruzarse con pruebas de aceptacin de usuarios ni con el entorno de desarrollo. Esto es tan peligroso que si las pruebas de aceptacin de usuarios, o las pruebas de integracin o cualquier otra prueba se ejecutan en el mismo entorno, entonces los resultados no son fiables. Como buena prctica, siempre es aconsejable disponer de un entorno de pruebas de rendimiento lo ms parecido como se pueda al entorno de produccin.

Mitos de las pruebas de rendimiento[editar editar cdigo]

Algunos de los mitos ms comunes son los siguientes. 1. Las pruebas de rendimiento se hacen para romper el sistema: Las pruebas de estrs se hacen para observar el punto de ruptura del sistema. Por el contrario, las pruebas normales de carga se hacen generalmente para ver el comportamiento de la aplicacin bajo una carga de usuarios esperada, y dependen 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 estrs. 2. Las pruebas de rendimiento slo deben hacerse despus de las pruebas de integracin del sistema: 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. 3. El probar el rendimiento slo implica la creacin de scripts y cualquier cambio en la aplicacin solo puede causar una simple refactorizacin de 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.

Por otro lado, en relacin con este mito, tambin es falso que cualquier cambio en la interfaz de usuario, especialmente en el mbito Web, supone un completo desarrollo de los scripts desde cero. Este problema se vuelve mayor si los protocolos involucrados incluyen Web Services, Siebel, scripts de acciones, Citrix o SAP.

Tecnologa[editar editar cdigo]

La tecnologa de las pruebas de rendimiento utiliza uno o ms PCs o servidores para actuar como peticionarios. Cada uno emula la presencia de un nmero de usuarios y cada uno ejecuta una secuencia automtica de las interacciones (registrada como una secuencia de comandos, o como una serie de scripts para simular los distintos tipos de uso por parte de los usuarios) con la aplicacin cuyo rendimiento se pone a prueba. Por lo general, un PC acta como gestor de prueba, coordinando, recopilando las mtricas de cada uno de los ejecutores y acumulando los datos de rendimiento para la realizacin de los informes. La secuencia habitual es incrementar la carga, comenzando con un pequeo nmero de usuarios virtuales y aumentando el nmero durante un periodo hasta alcanzar el mximo. El resultado de la prueba muestra la forma en que el rendimiento vara con la carga, mostrando como el nmero de usuarios modifica el tiempo de respuesta. Existen diversas herramientas disponibles para la realizacin de tales pruebas. Estas herramientas suelen ejecutar un conjunto de pruebas que simulan usuarios reales utilizando el sistema. A veces los resultados pueden revelar curiosidades, por ejemplo, si el promedio de tiempo de respuesta puede ser aceptable, si existen valores anmalos en las peticiones que necesitan tiempos considerablemente ms largo para ejecutarse - algo que puede ser causado por peticiones poco eficientes a la base de datos, fotos, etc. Las pruebas de rendimiento se pueden combinar con pruebas de estrs, con el fin de ver qu pasa cuando una carga aceptable se supera Se cae el sistema? Cunto tiempo tarda en recuperarse si se reduce una gran carga? Un fallo produce daos colaterales? El modelo de anlisis de rendimiento es un mtodo para modelar el comportamiento de una aplicacin en una hoja de clculo. El modelo se alimenta con las mediciones de los recursos solicictados por las peticiones (CPU, IO, LAN, WAN), ponderado por el nivel de transaccin (las peticiones realizadas por unidad de tiempo, habitualmente una hora). La demanda de recursos de las peticiones son acumuladas para obtener la demanda de recursos por unidad de tiempo y divididas por la capacidad total de recursos por la misma unidad, obteniendo as la carga de recursos. Usando la formula de tiempo de respuesta (R=S/(1-U), R=tiempo de respuesta, S=tiempo del servicio, U=carga), los tiempos de respuesta pueden ser calculados y calibrados con los resultados de las pruebas de rendimiento. El modelo de anlisis del rendimiento permite la evaluacin

de diferentes opciones de diseo y dimensionamiento del sistema sobre la base actual o la prevista del uso de la aplicacin. Por lo tanto, es mucho ms rpido y ms barato que las pruebas de rendimiento, aunque requiere una alta comprensin de las plataformas de hardware.

Especificaciones del rendimiento[editar editar cdigo]

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 cul es el tiempo mximo de respuesta aceptable para un nmero determinado de usuarios. Las pruebas de rendimiento se utiliza con frecuencia como parte del proceso de ajuste de la ejecucin. La idea es identificar el "eslabn ms dbil" - 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. Sin estos instrumentos se podra tener a alguien encargado de observar el administrador de tareas de Microsoft Windows del servidor para ver como se carga la CPU en las pruebas de rendimiento (suponiendo que se prueba un sistema de Windows). Hay una supuesta historia de una empresa que gast una gran cantidad para optimizar su software sin haber realizado un anlisis adecuado del problema. La empresa termin reescribiendo el proceso de sistema idle loop, que es donde haban encontrado que el pasaba la mayor parte de su tiempo, pero incluso con el ms eficiente proceso de espera en el mundo, obviamente, no mejoraron el rendimiento general ni un pice. Las pruebas de rendimiento se pueden realizar a travs de la web, e incluso hacerse en diferentes partes del pas, ya que es sabido que los tiempos de respuesta de Internetvaran regionalmente. Tambin se puede hacer en local, aunque el hardware de enrutamiento debe estar configurado para introducir el desfase de lo que suele ocurrir en las redespblicas. Las cargas deben ser realizadas en puntos realistas del sistema. Por ejemplo, si el 50% de usuarios de un sistema accede a travs de una conexin de mdem de 56K y la otra mitad a travs de una T1, entonces la carga simulada (ordenadores que simulan los usuarios reales) se debe realizar, ya sea con las mismas conexiones

(caso ideal) o simular la latencia de la red de conexiones de este tipo, siguiendo el mismo perfil de usuario. Siempre es til disponer de una estimacin del pico de nmero de usuarios que se espera que utilicen el sistema en las horas punta. Si puede ser tambin una estimacin del mximo tiempo de respuesta permitido en el percentil 95, para que la configuracin de la ejecucin de las pruebas se ajuste a estas especificaciones. 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, Cual es el nmero de usuarios concurrentes que se esperan para cada uno (especificando picos y medias?

Cul es la estructura objetivo del sistema (hardware, especificandor 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).

Cual 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 medias)?

Tareas a realizar[editar editar cdigo]

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), a fin de ver si el desconocimiento de cualquier factor podra afectar a los resultados.

Analizar los resultados - ya sea de aceptando/rechazando, o investigando el camino crtico y recomendando medidas correctivas .

Metodologa[editar editar cdigo]

Metodologa de pruebas de rendimiento de aplicaciones Web[editar editar cdigo]
Segn Microsoft Developer Network, la Metodologa de las Pruebas de Rendimiento consiste en las siguientes 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. Asegrarse 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 validas 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.