analisis de cobertura y prueba
TRANSCRIPT
-
7/24/2019 Analisis de cobertura y prueba
1/98
Testing de Software
-
7/24/2019 Analisis de cobertura y prueba
2/98
Tercera Unidad:TCNICAS DE TESTING
-
7/24/2019 Analisis de cobertura y prueba
3/98
4.2 Anlisis decobertura y pruebasbasadas en estructura
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
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)
-
7/24/2019 Analisis de cobertura y prueba
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/24/2019 Analisis de cobertura y prueba
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).
-
7/24/2019 Analisis de cobertura y prueba
8/98
REPRESENTACIN DEL GRAFO DE FLDE LAS ESTRUCTURAS DE CONTROL
-
7/24/2019 Analisis de cobertura y prueba
9/98
REPRESENTACIN DEL GRAFO DE FLDE LAS ESTRUCTURAS DE CONTROL
-
7/24/2019 Analisis de cobertura y prueba
10/98
EJEMPLO. DIAGRAMA DE FLUJO
-
7/24/2019 Analisis de cobertura y prueba
11/98
EJEMPLO. GRAFO DE FLUJO
-
7/24/2019 Analisis de cobertura y prueba
12/98
GRAFOS ASOCIADOS A CONDICIONELGICAS COMPUESTAS
-
7/24/2019 Analisis de cobertura y prueba
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.
-
7/24/2019 Analisis de cobertura y 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.
-
7/24/2019 Analisis de cobertura y prueba
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).
-
7/24/2019 Analisis de cobertura y prueba
16/98
COMPLEJIDAD CICLOMTICA.CAMINBSICOS
-
7/24/2019 Analisis de cobertura y prueba
17/98
EJEMPLODisear el conjunto de casos de prueba mediante el mtodo de la complejidad ciclo
el siguiente cdigo:
-
7/24/2019 Analisis de cobertura y prueba
18/98
Ejemplo
-
7/24/2019 Analisis de cobertura y prueba
19/98
EJEMPLO. CONVERSIN AL GRAFO DFLUJO
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
21/98
PRUEBAS DE CAJA BLANCA: COBERTLGICACobertura de Sentencia.
Cobertura de Decisiones.
Cobertura de Condiciones.
Cobertura de Condicin Mltiple.
-
7/24/2019 Analisis de cobertura y prueba
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.
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
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.
-
7/24/2019 Analisis de cobertura y prueba
26/98
EJEMPLO. POSIBLES COMBINACIONE 1: x0 e y0
2: x0 e y
-
7/24/2019 Analisis de cobertura y prueba
27/98
EJEMPLO. POSIBLES COMBINACIONE
-
7/24/2019 Analisis de cobertura y prueba
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.
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
30/98
TCNICAS DE PRUEBA DE CAJA NEGParticin Equivalente
Anlisis de Valores Lmites
-
7/24/2019 Analisis de cobertura y prueba
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.
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
33/98
CONDICIONES DE ENTRADALas condiciones de entrada vienen representadas por sentencias en la especificaci
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
36/98
CRITERIOS DE IDENTIFICACIN DE LACLASES DE EQUIVALENCIA
TABLA DE CONSIGNACIN DE LAS
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y 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
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
40/98
Consignacin de las condiciones de entrada
-
7/24/2019 Analisis de cobertura y prueba
41/98
Consignacin de las clases de equivalencia
-
7/24/2019 Analisis de cobertura y prueba
42/98
Derivacin de los casos de prueba
EL MTODO DEL ANLISIS DE LOS
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
45/98
-
7/24/2019 Analisis de cobertura y prueba
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}
-
7/24/2019 Analisis de cobertura y prueba
47/98
AVL aplicado al ejemplo 1
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
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)
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
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.
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura 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
-
7/24/2019 Analisis de cobertura y 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.
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
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.
-
7/24/2019 Analisis de cobertura y prueba
58/98
DEPURACIN POR INDUCCININDUCCIN: Proceso que pasa de lo particular a lo general.
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
60/98
4.3 Pruebas de integracin
-
7/24/2019 Analisis de cobertura y prueba
61/98
Pruebas de Integracin: Motivacin
-
7/24/2019 Analisis de cobertura y prueba
62/98
Tipos de errores: Errores de
-
7/24/2019 Analisis de cobertura y prueba
63/98
programacin entre componentes
-
7/24/2019 Analisis de cobertura y prueba
64/98
Ejemplo:
-
7/24/2019 Analisis de cobertura y prueba
65/98
Bloqueo mutuo o abrazo mortal (deadlock)
-
7/24/2019 Analisis de cobertura y prueba
66/98
Bloqueo activo (livelock)
Tipos de errores: Errores deb l d d
-
7/24/2019 Analisis de cobertura y prueba
67/98
interoperabilidadErrores de interoperabilidad a nivel de sistema
-
7/24/2019 Analisis de cobertura y prueba
68/98
Errores de interoperabilidad a nivel de lenguaje de programacin
-
7/24/2019 Analisis de cobertura y prueba
69/98
Errores de interoperabilidad a nivel de especificacin
E i
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
72/98
EstrategiasIntegracin descendente. La integracin se realiza partiendo del programa principalmovindonos hacia abajo por la jerarqua de control
-
7/24/2019 Analisis de cobertura y prueba
73/98
Integracin descendente - En profundidad. La integracin se realiza por ramas. Cadimplementar una funcionalidad especfica.
-
7/24/2019 Analisis de cobertura y prueba
74/98
Qu ocurre si algn mdulo/componente an no ha sido implementado pero es neprobar la integracin de otros componentes?
-
7/24/2019 Analisis de cobertura y prueba
75/98
Stubs: Componentes de mentira que imitan el comportamiento de componentes implementados (implementan su interfaz).
-
7/24/2019 Analisis de cobertura y prueba
76/98
Integracin descendente - En anchura. La integracin se realiza por niveles movindhorizontal por la estructura de control.
-
7/24/2019 Analisis de cobertura y prueba
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.
-
7/24/2019 Analisis de cobertura y prueba
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.
-
7/24/2019 Analisis de cobertura y prueba
79/98
Integracin de sandwich (Sandwich testing)
-
7/24/2019 Analisis de cobertura y prueba
80/98
-
7/24/2019 Analisis de cobertura y prueba
81/98
4.4 Pruebas derendimiento
Pruebas de rendimiento
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
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)
-
7/24/2019 Analisis de cobertura y prueba
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)
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
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).
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
92/98
-
7/24/2019 Analisis de cobertura y prueba
93/98
4.5 Pruebas deregresin
Pruebas de regresin
-
7/24/2019 Analisis de cobertura y prueba
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 -
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y prueba
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
-
7/24/2019 Analisis de cobertura y 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
-
7/24/2019 Analisis de cobertura y 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.