analisis de cobertura y prueba

7/24/2019 Analisis de cobertura y prueba

1/98

Testing de Software


2/98

Tercera Unidad:TCNICAS DE TESTING


3/98

4.2 Anlisis decobertura y pruebasbasadas en estructura


4/98

DISEO DE CASOS DE PRUEBAPara cualquier producto de ingeniera existen dos enfoques a la hora de probar un p

Pruebas de Caja Blanca: Se centra en el estudio minucioso de la operatividad de una parte del sistema considerando los detalles proce

del sistema).

Pruebas de Caja Negra: Analiza principalmente la compatibilidad entre s, en cuanto a las interfaces, de cada uno de los componentes del software (no t

a del sistema).

Combinando ambas estrategias se obtiene una ms completa validacin del softwar


5/98

TCNICAS DE DISEO DE CASOS DEPRUEBAPropsito:

Reducir el nmero de casos de prueba manteniendo la efectividad de la prueba

Enfoques: Caja negra (que es lo que hace)

Caja blanca (como lo hace)


6/98

PRUEBAS DE CAJA BLANCAUsa la estructura de control del diseo procedimental para obtener los casos de pru

Estos casos deben garantizar: Que se ejercita por lo menos una vez todos los caminos independientes de cada mdulo.

Que se ejerciten todas las decisiones lgicas en sus vertientes verdadera y falsa.

Que se ejecuten todos los bucles en sus lmites operacionales.

Que se ejerciten las estructuras internas de datos para asegurar su validez.

Los errores se esconden en los rincones y se aglomeran en los lmites [Beizer].


7/98

PRUEBA DEL CAMINO BSICOEs una tcnica para obtener casos de prueba de caja blanca.

Este mtodo permite obtener una medida de la complejidad lgica de un diseo pr

Esta medida puede ser usada como gua a la hora de definir un conjunto bsico de cejecucin (diseo de casos de prueba).

Para la obtencin de la complejidad lgica o ciclomtica emplearemos una represenflujo de control en forma de grafo (Grafo del flujo).


8/98

REPRESENTACIN DEL GRAFO DE FLDE LAS ESTRUCTURAS DE CONTROL


9/98

REPRESENTACIN DEL GRAFO DE FLDE LAS ESTRUCTURAS DE CONTROL


10/98

EJEMPLO. DIAGRAMA DE FLUJO


11/98

EJEMPLO. GRAFO DE FLUJO


12/98

GRAFOS ASOCIADOS A CONDICIONELGICAS COMPUESTAS


13/98

COMPLEJIDAD CICLOMTICAEs una medida del software que aporta una valoracin cuantitativa de la complejidaun programa.

Dentro del contexto del mtodo de pruebas del camino bsico define el nmero deindependientes de un programa.

Por camino independiente se entiende aquel que introduce un nuevo conjunto de suna nueva condicin. En trminos del grafo, por una arista que no haya sido recorri

Nos da una cota o lmite superior para el nmero de casos de prueba.


14/98

CLCULO DE LA COMPLEJIDADCICLOMTICAFormas de clculo:

El nmero de regiones del grafo es igual a la complejidad ciclomtica.

V(G)=A-N+2 Donde A es el nmero de aristas y N es el nmero de nodos contenidos en el grafo.

V(G)=P+1 Donde P es el nmero de nodos predicados contenidos en el grafo.


15/98

DERIVACIN DE LOS CASOS DE PRUEPasos a seguir:

Representacin del grafo de flujo asociado al cdigo fuente del programa.

Clculo de la complejidad ciclomtica.

Determinacin de un conjunto de caminos bsicos. Dicho conjunto bsico, para un grafo no ser nico y existir distintas posibilidades.

Se preparan los casos que obligan a la ejecucin de cada camino del conjunto bsico.

Los casos de prueba as derivados garantizan que:

al menos una vez se ejecute cada sentencia cada condicin se haya probado en sus dos vertientes (verdadera y falsa).


16/98

COMPLEJIDAD CICLOMTICA.CAMINBSICOS


17/98

EJEMPLODisear el conjunto de casos de prueba mediante el mtodo de la complejidad ciclo

el siguiente cdigo:


18/98

Ejemplo


19/98

EJEMPLO. CONVERSIN AL GRAFO DFLUJO


20/98

EJEMPLO. CONJUNTO DE CAMINOSBSICOSHabr tantos caminos bsicos como grados de complejidad posee e cdigo.

En este caso tenemos tres caminos bsicos: C1: 1-2-4-6

C2: 1-2-3-4-5

C3: 1-2-3-5-6

La derivacin de los casos a partir de los caminos bsicos es inmediato: C1: x


21/98

PRUEBAS DE CAJA BLANCA: COBERTLGICACobertura de Sentencia.

Cobertura de Decisiones.

Cobertura de Condiciones.

Cobertura de Condicin Mltiple.


22/98

COBERTURA DE SENTENCIAEsta cobertura requiere que se ejecute por lo menos una vez cada sentencia del pro

Este criterio es necesario pero no suficiente

Es un criterio dbil No se comprueban ambas vertientes de las condiciones.


23/98

COBERTURA DE DECISINEste criterio establece que es necesario escribir un nmero suficiente de casos de p

para que cada decisin tenga por lo menos un resultado verdadero o falso.

Este criterio es ms fuerte que el de sentencia pero an presenta debilidades.

En sentencias condicionales compuestas puede quedar enmascarada una de las con


24/98

COBERTURA DE CONDICINEn este criterio es necesario presentar un nmero suficiente de casos de prueba de

cada condicin en una decisin tenga, al menos una vez, todos los resultados posib

Este criterio es ms fuerte que el anterior.

Hay que ser cuidadoso con la eleccin de los casos de prueba por que aunque se gaejecucin de las condiciones puede ocurrir que alguna clusula de la decisin no se


25/98

COBERTURA MLTIPLELa solucin lgica a lo anterior es utilizar un criterio que requiera un nmero suficie

de prueba tal que todas las combinaciones posibles de resultados de condicin en cy todos los puntos de entrada se invoquen al menos una vez.

Satisface los criterios de cobertura anteriormente citados.


26/98

EJEMPLO. POSIBLES COMBINACIONE 1: x0 e y0

2: x0 e y


27/98

EJEMPLO. POSIBLES COMBINACIONE


28/98

DISEO DE CASOS DE PRUEBAMEDIANTE CAJA NEGRAEnfoque de caja negra:

Tambin denominadas pruebas de comportamiento. Consideran la funcin especfica para la cul fue creado el producto (lo que hace).

Las pruebas se llevan a cabo sobre la interfaz del sistema.

Reduce el nmero de casos de prueba mediante la eleccin de condiciones de entrada y no vlidas que ejercitan toda la funcionalidad del sistema.


29/98

TIPOS DE ERRORES QUE DETECTAFunciones incorrectas o ausentes

Errores de la interfaz

Errores en estructuras de datos o accesos a

bases de datos

Errores de rendimiento

Errores de inicializacin y terminacin


30/98

TCNICAS DE PRUEBA DE CAJA NEGParticin Equivalente

Anlisis de Valores Lmites


31/98

EL MTODO DE PARTICIN EQUIVAL(PE)Se basa en la divisin del campo de entrada en un conjunto de clases de datos deno

clases de equivalencia.


32/98

CONCEPTO DE CLASE EQUIVALENTEClase de equivalencia: un conjunto de datos de entrada que definen estados vlido

del sistema. Clase vlida: genera un valor esperado

Clase no vlida: genera un valor inesperado

Se obtienen a partir de las condiciones de entrada descritas en las especificaciones


33/98

CONDICIONES DE ENTRADALas condiciones de entrada vienen representadas por sentencias en la especificaci


34/98

EL PROCEDIMIENTOIdentificacin de las clases de equivalencia

Obtencin de los casos de prueba: Se parte de la premisa de que cualquier elemento de una clase dada es representativo de

conjunto.

IDENTIFICACIN DE LAS CLASES DE


35/98

IDENTIFICACIN DE LAS CLASES DEEQUIVALENCIAPor cada condicin de entrada se identifican clases de equivalencia vlidas y no vl

Este proceso es heurstico.

Sin embargo existen un conjunto de criterios que ayudan a su identificacin.

CRITERIOS DE IDENTIFICACIN DE LA


36/98

CRITERIOS DE IDENTIFICACIN DE LACLASES DE EQUIVALENCIA

TABLA DE CONSIGNACIN DE LAS


37/98

TABLA DE CONSIGNACIN DE LASCLASES DE EQUIVALENCIALas clases as identificadas se consignan en esta tabla enumerndose de cara a la de

los casos de prueba


38/98

DERIVACIN DE LOS CASOS DE PRUEClases de equivalencia :

Cada caso debe contemplar el mximo nmero de clases de equivalencia vlidas. Generar suficientes casos para cubrir todas las clases.

Generar un caso de prueba por cada clase de equivalencia no vlida que haya sido i


39/98

Ejemplo 1:Construccin de una batera de pruebas para detectar posibles errores en la constr

identificadores de un hipottico lenguaje de programacin. Las reglas que determinconstruccin sintctica son: No debe tener mas de 15 ni menos de 5 caracteres

El juego de caracteres utilizables es: Letras (Maysculas y minsculas)

Dgitos (0,9)

Guin (-)

Se distinguen las maysculas de las minsculas

El guin no puede estar ni al principio ni al final, pero puede haber varios consecutivos.

Debe contener al menos un carcter alfabtico

No puede ser una de las palabras reservadas del lenguaje


40/98

Consignacin de las condiciones de entrada


41/98

Consignacin de las clases de equivalencia


42/98

Derivacin de los casos de prueba

EL MTODO DEL ANLISIS DE LOS


43/98

EL MTODO DEL ANLISIS DE LOSVALORES LMITES (AVL)Se basa en la evidencia experimental de que los errores suelen aparecer con mayor

en los extremos de los campos de entrada.Un anlisis de las condiciones lmites de las clases de equivalencia aumenta la eficieprueba.

Condiciones lmites : valores justo por encima y por debajo de los mrgenes de la cequivalencia.

DERIVACIN DE LOS CASOS DE PRUE


44/98

DERIVACIN DE LOS CASOS DE PRUE

Generar tantos casos de prueba como sean necesarios para ejercitar las condicione

las clases de equivalencia.Proceso heurstico

Como en el caso anterior se pueden seguir unos criterios que faciliten su obtencin


45/98


46/98

Ejemplo 2 (PE vs AVL):Programa que establece a partir de tres valores de entrada de que tipo de tringulo

Condicin: A+B>C and A+C>B and B+C>A

Segn el mtodo de particin equivalente deberamos considerar una clase equivalente vlida y otra no vlida {A{A=1, B=2, C= 5}

No detectara un error en A+BC

AVL incluira el caso {A=1, B=2, C=3}


47/98

AVL aplicado al ejemplo 1


48/98

CONJETURA DE ERRORESConsiste en la elaboracin previa de una lista de errores no contemplados anteriorm

sirva para generar nuevos casos de prueba.Ejemplo: subrutina que ejecuta la bsqueda binaria

Un caso que compruebe La presencia de un solo dato en la lista.

Que las posiciones de la lista sea una potencia de dos

Que las posiciones de la lista sea uno ms de una potencia de dos

Que las posiciones de la lista sea uno menos de una potencia de dos

ESTRATEGIAS PARA EL DISEO DE CA


49/98

ESTRATEGIAS PARA EL DISEO DE CADE PRUEBASCada tcnica:

Evala una fuente diferente de errores. El diseo debe involucrar una combinacin de estas tcnicas.

Procedimiento: En todos los casos utilizar anlisis de valores lmites

Complementar con casos de prueba derivados del mtodo de particin equivalente

Aadir nuevos casos mediante la conjetura de errores


50/98

SNTESIS FINALEl proceso de prueba consiste en ejecutar el programa con el fin de localizar errore

La prueba es una actividad incompleta.

Propsito de las tcnicas: reducir el nmero de casos de prueba sin mermar la efecprueba.

Existen dos enfoques a la hora de abordar el diseo de los casos de prueba: Caja Negra: evala la funcionalidad del sistema (lo que hace)

Caja Blanca: evala la lgica interna (como lo hace)


51/98

SSTESIS FINALTcnicas de diseo:

Particin equivalente: divisin del campo de entrada en clases de equivalencia vlidas y ntravs de las condiciones que aparecen en la especificacin.

Anlisis de valores lmites: Evaluar las condiciones lmites de las clases de equivalencia.

La prueba de programas bajo caja negra involucra una combinacin de todas estas t

EJECUCIN DE LAS PRUEBAS: PRUEB


52/98

EJECUCIN DE LAS PRUEBAS: PRUEBPOR MDULOS O DE INTEGRACINConsiste en la comparacin de la funcin del mdulo con respecto de alguna espec

funcional o interfaz que lo defina.Motivacin:

Es una forma de poder manejar las posibilidades combinatorias de las pruebas.

La prueba por mdulos facilita la tarea de localizacin y correccin de errores.

Introduce un cierto paralelismo en el proceso de prueba ya que se tiene la oportunidad dsimultneamente.


53/98

PROCESO DE PRUEBA POR MDULOSe disean los casos de prueba:

Se analiza la lgica del programa (caja blanca) Se complementa con casos obtenidos aplicando mtodos de caja negra.

Se determina el orden en que deben probarse los mdulos, siguiendo unas determrecomendaciones prcticas.

PRUEBAS INCREMENTALES y PRUEBA


54/98

PRUEBAS INCREMENTALES y PRUEBANO INCREMENTALESDebe probarse de forma independiente cada mdulo de un programa, para luego y obtener el programa final?.

Se debe probar cada mdulo integrandolo sucesivamente con el resto de los mduconformar el programa final?.

La primera consideracin se denomina integracin no incremental frente a la segunconoce como incremental.

PRUEBAS INCREMENTALES, PRUEBA


55/98

U S C S, UINCREMENTALES. PROCEDIMIENTOPrueba no incremental:

Primero se efecta la prueba de mdulos. Finalmente los mdulos se combinan o integrael programa completo.

La prueba de cada mdulo requiere un mdulo impulsor y uno o ms auxiliares.

Prueba incremental: El siguiente mdulo en ser probado se combina con los mdulos que ya han sido probad

La prueba puedes ser ascendente o descendente.


56/98

DEPURACINLa actividad que se desarrolla despus de ejecutar una caso de prueba exitoso.

Comprende los siguientes pasos: Determinar la naturaleza exacta y la ubicacin del presunto error dentro del programa.

Corregir el error encontrado.

Mtodos de depuracin: Por medio de la fuerza bruta

Por induccin

Por deduccin Por rastreo hacia atrs

Por medio de pruebas

DEPURACIN POR MEDIO DE LA


57/98

FUERZA BRUTA

Mtodos que utilizan la fuerza bruta:

La estrategia de espacir sentencias dentro del programa de cara a producir mensajes o mde ciertas variables. (es un mtodo de prueba y error).

Uso de herramientas que analizan la dinmica del programa empleando las caractersticadepurador del lenguaje de programacin empleado.

Estos mtodos son de prueba y error.

Generan una cantidad excesiva de datos irrelevantes.

No alientan a pensar en el problema que se trata resolver.


58/98

DEPURACIN POR INDUCCININDUCCIN: Proceso que pasa de lo particular a lo general.


59/98

DEPURACIN POR DEDUCCINDEDUCCIN: Se parte de ciertas premisas o leyes generales para llegar a una concluempleando para ello procesos de eliminacin y clasificacin


60/98

4.3 Pruebas de integracin


61/98

Pruebas de Integracin: Motivacin


62/98

Tipos de errores: Errores de


63/98

programacin entre componentes


64/98

Ejemplo:


65/98

Bloqueo mutuo o abrazo mortal (deadlock)


66/98

Bloqueo activo (livelock)

Tipos de errores: Errores deb l d d


67/98

interoperabilidadErrores de interoperabilidad a nivel de sistema


68/98

Errores de interoperabilidad a nivel de lenguaje de programacin


69/98

Errores de interoperabilidad a nivel de especificacin

E i


70/98

EstrategiasPruebas no incrementales (Big bang approach). Se integran todos los componentese prueba el sistema como un todo. No es una tcnica recomendada pues dificulta

aislamiento de errores.

E t t i


71/98

EstrategiasPruebas incrementales. El programa es construido y probado en pequeos incremeel aislamiento de errores y la pruebas sistemticas.

Estrategias para pruebas incrementales:

Integracin descendente (Top-down)

En profundidad (Depth-first)

En anchura (Breadth-first)

Integracin ascendente (Bottom-up)

E t t i


72/98

EstrategiasIntegracin descendente. La integracin se realiza partiendo del programa principalmovindonos hacia abajo por la jerarqua de control


73/98

Integracin descendente - En profundidad. La integracin se realiza por ramas. Cadimplementar una funcionalidad especfica.


74/98

Qu ocurre si algn mdulo/componente an no ha sido implementado pero es neprobar la integracin de otros componentes?


75/98

Stubs: Componentes de mentira que imitan el comportamiento de componentes implementados (implementan su interfaz).


76/98

Integracin descendente - En anchura. La integracin se realiza por niveles movindhorizontal por la estructura de control.


77/98

Integracin ascendente. La integracin se realiza partiendo de mdulos atmicos sitnodos finales de la jerarqua de control. No suele necesitar el uso de stubs.


78/98

Integracin descendente: Permite verificar los puntos de control o decisin al principio del proceso de prueba.

La integracin en profundidad permite probar funcionalidades completas lo cual aument

Puede requerir el uso de muchos stubs.

Integracin ascendente: Se elimina la necesidad de usar stubs.

Es necesario el uso de controladores de prueba (drivers) a fin de coordinar la entrada y de prueba.


79/98

Integracin de sandwich (Sandwich testing)


80/98


81/98

4.4 Pruebas derendimiento

Pruebas de rendimiento


82/98

Pruebas de rendimientoSon las pruebas que se realizan, desde una perspectiva, para determinar lo rpido quna tarea un sistema en condiciones particulares de trabajo.

Tambin puede servir para validar y verificar otros atributos de la calidad del sistemcomo la escalabilidad, fiabilidad y uso de los recursos.

Las pruebas de rendimiento son un subconjunto de la ingeniera de pruebas, una prinformtica que se esfuerza por mejorar el rendimiento, englobndose en el diseoarquitectura de un sistema, antes incluso del esfuerzo inicial de la codificacin.

Introduccin


83/98

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

Pueden medir que partes del sistema o de carga de trabajo provocan que el conjunt

Para su diagnstico, los ingenieros de software utilizan herramientas como pueden monitorizaciones que midan qu partes de un dispositivo o software contribuyen mrendimiento o para establecer niveles (y umbrales) del mismo que mantenga un tie

respuesta aceptable.

Pruebas de carga


84/98

Pruebas de cargaEste es el tipo ms sencillo de pruebas de rendimiento.

Una prueba de carga se realiza generalmente para observar el comportamiento de aplicacin bajo una cantidad de peticiones esperada.

Esta carga puede ser el nmero esperado de usuarios concurrentes utilizando la aprealizan un nmero especfico de transacciones durante el tiempo que dura la carga

Esta prueba puede mostrar los tiempos de respuesta de todas las transacciones impla aplicacin.

Si la base de datos, el servidor de aplicaciones, etc.. tambin se monitorizan, entonprueba puede mostrar el cuello de botella en la aplicacin.

Prueba de estrs


85/98

Prueba de estrsEsta prueba se utiliza normalmente para romper la aplicacin.

Se va doblando el nmero de usuarios que se agregan a la aplicacin y se ejecuta ucarga hasta que se rompe.

Este tipo de prueba se realiza para determinar la solidez de la aplicacin en los momcarga extrema y ayuda a los administradores para determinar si la aplicacin rendirsuficiente en caso de que la carga real supere a la carga esperada.

Prueba de estabilidad (soak testing)


86/98

Prueba de estabilidad (soak testing)Esta prueba normalmente se hace para determinar si la aplicacin puede aguantar esperada continuada.

Generalmente esta prueba se realiza para determinar si hay alguna fuga de memoriaplicacin.

Pruebas de picos (spike testing)


87/98

Pruebas de picos (spike testing)La prueba de picos, como el nombre sugiere, trata de observar el comportamiento variando el nmero de usuarios, tanto cuando bajan, como cuando tiene cambios d

su carga. Esta prueba se recomienda que sea realizada con un software automatizapermita realizar cambios en el nmero de usuarios mientras que los administradoreregistro de los valores a ser monitorizados.

Pre-requisitos para las pruebas de ca


88/98

Pre requisitos para las pruebas de caUn desarrollo estable de la aplicacin instalado en un entorno lo ms parecido al de

El entorno de pruebas de rendimiento no debe cruzarse con pruebas de aceptacinni con el entorno de desarrollo.

Esto es tan peligroso que si las pruebas de aceptacin de usuarios, o las pruebas deo cualquier otra prueba se ejecutan en el mismo entorno, entonces los resultados n

Como buena prctica, siempre es aconsejable disponer de un entorno de pruebas drendimiento lo ms parecido como se pueda al entorno de produccin.

Mitos de las pruebas de rendimiento


89/98

Mitos de las pruebas de rendimientoAlgunos de los mitos ms comunes son los siguientes.

Las pruebas de rendimiento se hacen para romper el sistema: Las pruebas de estrs se hacen para observar el punto desistema. Por el contrario, las pruebas normales de carga se hacen generalmente para ver el comportamiento de la aplic

carga de usuarios esperada, y dependen de otros requisitos, tales como el aumento de carga esperado, la carga continperiodo prolongado de tiempo mientras la demanda aumenta, la resistencia a las cadas o las pruebas de estrs.

Las pruebas de rendimiento slo deben hacerse despus de las pruebas de integracin del sistema: Aunque esta es la nindustria, las pruebas de rendimiento tambin pueden realizarse mientras se realiza el desarrollo inicial de la aplicacinenfoque se conoce como pruebas de rendimiento tempranas. Este enfoque garantizara un desarrollo holstico de la apmanteniendo los parmetros de rendimiento en mente. Por lo tanto, la bsqueda de un problema en el rendimiento juterminacin 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 srefactorizacin de dichos scripts: Las pruebas de rendimiento son en s mismas una ciencia evolucionada de la industriamismos, los scripts, aunque importantes, son slo uno de los componentes de las pruebas de rendimiento. El principal cualquier persona que pruebe el rendimiento es determinar el tipo de pruebas necesarias y analizar los distintos medidrendimiento 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, especialmentWeb, supone un completo desarrollo de los scripts desde cero. Este problema se vuelve mayor si los protocolos involucWeb Services, Siebel, scripts de acciones, Citrix o SAP.

Especificaciones del rendimiento


90/98

Especificaciones del rendimientoEs fundamental detallar las especificaciones de rendimiento (requisitos) y documentarlaplan de pruebas de rendimiento. Idealmente, esto se hace durante la fase de requisitos 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 cueespecificacin, es decir, nadie ha expresado cul es el tiempo mximo de respuesta acepnmero determinado de usuarios. Las pruebas de rendimiento se utiliza con frecuencia 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 tradfuncionamiento del sistema global ms rpido.

A veces es una difcil tarea determinar qu parte del sistema representa esta ruta crticaherramientas de prueba incluyen (o puede tener aadidos que lo proporcionan) instrumejecuta en el servidor (agentes) y que informan de tiempos de transaccin, nmero de a

bases de datos, sobrecarga de la red, y otros monitores del servidor, que pueden ser ancon los datos principales de las estadsticas de rendimiento. Sin estos instrumentos se palguien encargado de observar el administrador de tareas de Microsoft Windows del sever como se carga la CPU en las pruebas de rendimiento (suponiendo que se prueba un Windows).


91/98

Hay una supuesta historia de una empresa que gast una gran cantidad para optimizar su softwarerealizado un anlisis adecuado del problema. La empresa termin reescribiendo el proceso de sistque es donde haban encontrado que el pasaba la mayor parte de su tiempo, pero incluso con el m

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 ya que es sabido que los tiempos de respuesta de Internet varan regionalmente. Tambin se puedlocal, aunque el hardware de enrutamiento debe estar configurado para introducir el desfase de loocurrir en las redes pblicas. Las cargas deben ser realizadas en puntos realistas del sistema. Por e50% de usuarios de un sistema accede a travs de una conexin de mdem de 56K y la otra mitadT1, entonces la carga simulada (ordenadores que simulan los usuarios reales) se debe realizar, ya smismas conexiones (caso ideal) o simular la latencia de la red de conexiones de este tipo, siguiendperfil de usuario.

Siempre es til disponer de una estimacin del pico de nmero de usuarios que se espera que utilen las horas punta. Si puede ser tambin una estimacin del mximo tiempo de respuesta permitipercentil 95, para que la configuracin de la ejecucin de las pruebas se ajuste a estas especificaci


92/98


93/98

4.5 Pruebas deregresin

Pruebas de regresin


94/98

Se denominan Pruebas de regresin a cualquier tipo de pruebas de software que indescubrir las causas de nuevos errores (bugs), carencias de funcionalidad, o diverge

funcionales con respecto al comportamiento esperado del software, inducidos por recientemente realizados en partes de la aplicacin que anteriormente al citado campropensas a este tipo de error.

Esto implica que el error tratado se reproduce como consecuencia inesperada del cen el programa.

Este tipo de cambio puede ser debido a prcticas no adecuadas de control de versioconsideracin acerca del mbito o contexto de produccin final y extensibilidad del

fue corregido (fragilidad de la correccin), o simplemente una consecuencia del redaplicacin.

Pruebas de regresin
http://es.wikipedia.org/wiki/Bugshttp://es.wikipedia.org/wiki/Bugs


95/98

Por lo tanto, en la mayora de las situaciones del desarrollo de software se considerprctica que cuando se localiza y corrige un bug, se grabe una prueba que exponga

vuelvan a probar regularmente despus de los cambios subsiguientes que experimeprograma.

Existen herramientas de software que permiten detectar este tipo de errores de mao totalmente automatizada, la prctica habitual en programacin extrema es que epruebas se ejecuten en cada uno de los pasos del ciclo de vida del desarrollo del sof

Tipos de regresin


96/98

Clasificacin de mbito

Local - los cambios introducen nuevos errores.

Desenmascarada - los cambios revelan errores previos. Remota - Los cambios vinculan algunas partes del programa (mdulo) e introducen error

Clasificacin temporal

Nueva caracterstica - los cambios realizados con respecto a nuevas funcionalidades en laintroducen errores en otras novedades en la misma versin del software.

Caracterstica preexistente - los cambios realizados con respecto a nuevas funcionalidadeerrores en funcionalidad existente de previas versiones.

aso de prueba


97/98

En Ingeniera del software, los casos de prueba o Test Case son un conjunto devariables bajo las cules el analista determinar si el requisito de una aplicacin

completamente satisfactorio.Se pueden realizar muchos casos de prueba para determinar que uncompletamente satisfactorio. Con el propsito de comprobar que todos los requaplicacin son revisados, debe haber al menos un caso de prueba para cada requque un requisito tenga requisitos secundarios. En ese caso, cada requisito secuntener por lo menos un caso de prueba.

Algunas metodologas como RUP recomiendan el crear por lo menos dos casos de

cada requisito. Uno de ellos debe realizar la prueba positiva de los requisitos yrealizar la prueba negativa.

aso de prueba


98/98

Si la aplicacin es creada sin requisitos formales, entonces los casos dse escriben basados en la operacin normal de programas de una clas

Lo que caracteriza un escrito formal de caso de prueba es que hay unaconocida y una salida esperada, los cuales son formulados antes de qejecute la prueba. La entrada conocida debe probar una precondicinesperada debe probar una postcondicin.

analisis de cobertura y prueba

Documents