Java conocimiento 2do edicion
21
-
Upload
cegudo-sistemas -
Category
Documents
-
view
221 -
download
1
description
Â
Transcript of Java conocimiento 2do edicion
EDICION: Renny Centeno
DISEÑO: Ana Fernández
Núcleo De Monagas
Curso especialidad de grado
Universidad De Oriente
Editorial Como siempre desde las oficinas de java conocimiento nos esforzamos por ofrecer a nuestros queridos lectores la mejor y variada información relacionada con el campo de ciencias de la computación, no es fácil mantenerse a la vanguardia en un mundo tan cambiante como el de hoy en día. Esta semana ha sido difícil para los miembros de la revista, pero nos caracterizamos por dejar el todo por el todo y en esta edición no será la excepción, esta semana nos enfocamos en un tema sumamente importante para todo aquel que se esté iniciando en el mundo de los sistemas informáticos o incluso para aquellos que ya están familiarizados pero desean aprender un par de cositas que no están de más, lo que abarcaremos esta semana serán las técnicas para detectar y disminuir los errores que se podrían presentar en un sistema informático, los casos de prueba. Es que resultaría casi imposible diseñar y desarrollar un sistema y que este no presente ningún tipo de inconveniente, QUE ESTE PREFECTO DESDE SUS INICIOS RESULTA DIFICIL DE ALCANZAR, PARA ELLO NACEN LOS CASOS DE PRUEBA, SON VARIOS LOS QUE DISPONEMOS PERO LO MAS SIFNIFICATIVOS SON LOS CASOS DE PRUEBA DE CAJA BLANCA Y CAJA NEGRA, con la caja blanca se busca estudiar cada camino y componente interno del sistema buscando disminuir en gran medida los errores, en cambio con la caja negra se ignora la estructura interna o de control y nos enfocamos más en los requisitos y salidas que necesita el sistema, ambos poseen sus utilidades y son cruciales para mejorar el rendimiento de nuestro sistema informático, esperamos que esta edición sea de tu agrado y logres sacar provecho de este conocimiento.
Contenido
Introduccion…………………………………………………………5 Casos de prueba y su importancia………………………………6 Como crear tu propio caso de prueba manual………………….7 Prueba de caja blanca…………………………………………………….9 Prueba de caja negra………………………………………………………..12 Referencias bibliograficas…………………………………………………..19
Introducción Desde que aparecieron los primeros inventos novedosos aquello que
llamamos tecnología la cual nos facilita enormemente la vida con
su variedad de aplicaciones, surgió la necesidad de corregir
cualquier detalle o defecto que estos podrían tener y que evitaría
que realizaran su labor de manera eficaz y eficiente, sabemos que
no todo es perfecto y mucho menos cuando es algo que no lleva
mucho tiempo de creado, el no
corregir cualquier falla
podría traer consecuencias
que van desde lo más jovial
hasta las más lamentables.
Los sistemas informáticos no
escapan de esta realidad, no
son más que tecnología
aplicada que está presente
para hacer nuestro día a día
mucho menos laborioso, como
entidades creadas por el
hombre no están exceptas de
errores, se puede presentar
desde un molesto bug hasta una falla general del sistema que
frustre su funcionamiento (destacando que se pueden presentar
estas fallas desde la fase de creación hasta la de implementación)
Para prevenir o en su efecto solucionar con la falla existen
diversos métodos y técnicas llamados casos de prueba, mediante
estos métodos se busca analizar el sistema y todas sus facetas
como procedimientos y entradas para detectar y acabar con
cualquier anomalía.
Casos de prueba y su importancia
En un proyecto de desarrollo de software
los errores (bugs en inglés) pueden
presentarse en cualquiera de las etapas del
ciclo de vida del software
Aun cuando se intente detectarlos después
de cada fase utilizando técnicas como la
inspección, algunos errores permanecen
sin ser descubiertos, Por lo tanto es muy
probable que el código final contenga
errores de requerimientos y diseño,
adicionales a los introducidos en la
codificación
Las pruebas de software son una parte
importante pero muy costosa del proceso
de desarrollo de software
Un caso de prueba es una serie de pruebas
de entrada, condiciones de ejecución y
resultados esperados desarrollados para
un objetivo en particular, tal como
ejecutar una ruta particular de un
programa o verificar el cumplimiento con
un requerimiento en específico.
Nada tiene mayor efecto en la satisfacción
del usuario final con respecto al software
que una vista clara de lo que espera, éstas
expectativas deben ser verificadas y
validadas. Los casos de pruebas reflejan
los requerimientos que serán verificados.
Esta verificación deberá ser realizada de
diferentes maneras y por diferentes
probadores.
Si no se tiene la capacidad para verificar
todos los requerimientos, es importante
para el éxito del proyecto seleccionar los
requerimientos más apropiados o críticos
para la prueba. Los requerimientos que se
elijan para verificar deberán estar
balanceados entre el costo, riesgo y la
necesidad de tener los requerimientos
verificados.
6
Como crear un caso de prueba manual
Puede crear casos de prueba manuales
utilizando Microsoft Test Manager que
tienen pasos de prueba de acción y
validación. Asimismo, varios casos de
prueba pueden compartir un conjunto de
pasos de prueba comunes,
denominados pasos compartidos. Esto
simplifica el mantenimiento de los pasos
de prueba en caso de cambiar la
aplicación sometida a prueba
Requisitos:
Visual Studio
Ultimate
Visual Studio
Premium
Visual Studio
Test
Professional
Cualquier caso de
prueba que se cree
está asociado al
proyecto de equipo y
se puede agregar a
varios conjuntos de
pruebas en los
mismos planes de
pruebas u otros
diferentes. Cuando se
ejecutan estos casos
de prueba, se puede marcar qué pasos de
prueba se realizan sin errores y cuáles con
errores. Se puede crear un error a partir de
un caso de prueba con errores. Este error
incluye automáticamente los pasos de
prueba y otro tipo de información
recopilada.
Si desea ejecutar un caso de prueba
manual varias veces con datos diferentes,
no es necesario crear varias copias del
caso de prueba. Puede agregar parámetros
para las acciones o los resultados
esperados en cualquier paso de prueba del
caso de prueba. A continuación, puede
agregar varios conjuntos de valores para
los parámetros que desea usar en la
prueba. Cada conjunto de valores para los
parámetros se ejecuta como una iteración
individual de la prueba.
Se puede crear un caso de prueba manual
desde un plan de pruebas seleccionando
un conjunto, tal y como se muestra en la
siguiente ilustración.
7
Si el conjunto de
pruebas se creó
mediante la adición de
un requisito al plan de
pruebas, los casos de
prueba nuevos o
existentes que se
agreguen a dicho
conjunto se vincularán
automáticamente al
requisito.
A continuación, se pueden agregar los detalles del caso de prueba, tal y como se indica en
la ilustración siguiente.
Puede agregar los pasos de prueba copiando y pegando desde Microsoft Excel y Microsoft
Word. Seleccione los pasos en su documento de Microsoft Excel o Microsoft Word, haga
clic con el botón secundario en un paso existente o Elija aquí para agregar un paso y, a
continuación, elija Pegar.
8
Pruebas de caja blanca
La prueba de caja blanca se basa en el
diseño de casos de prueba que usa la
estructura de control del diseño
procedimental para derivarlos. Mediante
la prueba de la caja blanca el ingeniero
del software puede obtener casos de
prueba que:
1. Garanticen que se ejerciten por lo
menos una vez todos los caminos
independientes de cada módulo,
programa o método.
2. Ejerciten todas las decisiones
lógicas en las vertientes verdadera
y falsa.
3. Ejecuten todos los bucles en sus
límites operacionales.
4. Ejerciten las estructuras internas
de datos para asegurar su validez.
Es por ello que se considera a la prueba
de Caja Blanca como uno de los tipos de
pruebas más importantes que se le aplican
a los software, logrando como resultado
que disminuya en un gran porciento el
número de errores existentes en los
sistemas y por ende una mayor calidad y
confiabilidad.
Prueba camino básico
La prueba del camino básico es una
técnica de prueba de la Caja Blanca
propuesta por Tom McCabe.
Esta técnica permite obtener una medida
de la complejidad lógica de un diseño y
usar esta medida como guía para la
definición de un conjunto básico.
La idea es derivar casos de prueba a partir
de un conjunto dado de caminos
independientes por los cuales puede
circular el flujo de control. Para obtener
dicho conjunto de caminos
independientes se construye el Grafo de
Flujo asociado y se calcula su
complejidad ciclomática.
Los pasos que se siguen para aplicar esta
técnica son:
1. A partir del diseño o del código
fuente, se dibuja el grafo de flujo
asociado.
2. Se calcula la complejidad
ciclomática del grafo.
3. Se determina un conjunto básico
de caminos independientes.
9
4. Se preparan los casos de prueba
que obliguen a la ejecución de
cada camino del conjunto básico.
Los casos de prueba derivados del
conjunto básico garantizan que durante la
prueba se ejecuta por lo menos una vez
cada sentencia del programa.
Notación de Grafo de Flujo
Para aplicar la técnica del camino básico
se debe introducir una sencilla notación
para la representación del flujo de control,
el cual puede representarse por un Grafo
de Flujo. Cada nodo del grafo
corresponde a una o más sentencias de
código fuente. Todo segmento de código
de cualquier programa se puede traducir a
un Grafo de Flujo. Para construir el grafo
se debe tener en cuenta la notación para
las instrucciones. Un Grafo de Flujo está
formado por 3 componentes
fundamentales que ayudan a su
elaboración, comprensión y nos brinda
información para confirmar que el trabajo
se está haciendo adecuadamente.
Los componentes son:
Nodo
Cada círculo representado se denomina
nodo del Grafo de Flujo, el cual
representa una o más secuencias
procedimentales. Un solo nodo puede
corresponder a una secuencia de procesos
o a una sentencia de decisión. Puede ser
también que hallan nodos que no se
asocien, se utilizan principalmente al
inicio y final del grafo.
Aristas
Las flechas del grafo se denominan
aristas y representan el flujo de control,
son análogas a las representadas en un
diagrama de flujo. Una arista debe
terminar en un nodo, incluso aunque el
nodo no represente ninguna sentencia
procedimental.
Regiones
Las regiones son las áreas delimitadas por
las aristas y nodos. También se incluye el
área exterior del grafo, contando como
una región más. Las regiones se
enumeran. La cantidad de regiones es
equivalente a la cantidad de caminos
independientes del conjunto básico de un
programa.
Cualquier representación del diseño
procedimental se puede traducir a un
grafo de flujo. Cuando en un diseño se
encuentran condiciones compuestas (uno
o más operadores AND, NAND, NOR
lógicos en una sentencia condicional), la
generación del grafo de flujo se hace un
poco más complicada.
10
Complejidad Ciclomática
La complejidad ciclomática es una
métrica de software extremadamente útil
pues proporciona una medición
cuantitativa de la complejidad lógica de
un programa. El valor calculado como
complejidad ciclomática define el número
de caminos independientes del conjunto
básico de un programa y nos da un límite
superior para el número de pruebas que se
deben realizar para asegurar que se
ejecute cada sentencia al menos una vez.
Un camino independiente es cualquier
camino del programa que introduce por lo
menos un nuevo conjunto de sentencias
de procesamiento o una nueva condición.
El camino independiente se debe mover
por lo menos por una arista que no haya
sido recorrida anteriormente
Derivación de casos de prueba
Luego de tener elaborados los Grafos de
Flujos y los caminos a recorrer, se
preparan los casos de prueba que forzarán
la ejecución de cada uno de esos caminos.
Se escogen los datos de forma que las
condiciones de los nodos predicados estén
adecuadamente establecidas, con el fin de
comprobar cada camino.
Casos de prueba para cada camino.
Camino 1: 1-2-3-5-6. Escoger algún X y
Y tales que cumpla X >= 0 AND Y >= 0.
X = 10 AND Y = 20. Camino 2: 1-2-4-6.
Escoger algún X tal que se cumpla X < 0.
X = -15.
Luego de confeccionar los casos de
prueba se ejecutan cada uno de estos y se
comparan los resultados con los
esperados. Una vez terminados todos los
casos de prueba, se estará seguro de que
todas las sentencias del programa se han
ejecutado por lo menos una vez. Es
importante considerar que algunos
caminos no se pueden probar de forma
aislada. O sea, la combinación de datos
requeridos para recorrer el camino no se
puede obtener con el flujo normal del
programa. En tales casos, estos caminos
se prueban como parte de otra prueba de
camino.
11
Prueba de caja negra
Estas pruebas permiten obtener un
conjunto de condiciones de entrada que
ejerciten completamente todos los
requisitos funcionales de un programa. En
ellas se ignora la estructura de control,
concentrándose en los requisitos
funcionales del sistema y ejercitándolos.
La prueba de Caja Negra no es una
alternativa a las técnicas de prueba de la
Caja Blanca, sino un enfoque
complementario que intenta descubrir
diferentes tipos de errores a los
encontrados en los métodos de la Caja
Blanca. Muchos autores consideran que
estas pruebas permiten encontrar:
1. Funciones incorrectas o ausentes.
2. Errores de
interfaz.
3. Errores en
estructura
s de datos
o en
accesos a
las Bases
de Datos
externas.
4. Errores de
rendimiento.
5. Errores de inicialización y
terminación.
Para preparar los casos de pruebas hacen
falta un número de datos que ayuden a la
ejecución de los estos casos y que
permitan que el sistema se ejecute en
todas sus variantes, pueden ser datos
válidos o inválidos para el programa
según si lo que se desea es hallar un error
o probar una funcionalidad. Los datos se
escogen atendiendo a las especificaciones
del problema, sin importar los detalles
internos del programa, a fin de verificar
que el programa corra bien.
Para desarrollar la prueba de caja negra
existen varias técnicas, entre ellas están:
1. Técnica de la Partición de
Equivalencia: esta técnica divide
el campo de entrada en clases de
datos que tienden a ejercitar
determinadas
funciones del
software.
2. Técnica del
Análisis de
Valores
Límites: esta
Técnica prueba
la habilidad del
programa para
manejar datos
que se
encuentran en
los límites aceptables.
3. Técnica de Grafos de Causa-
Efecto: es una técnica que
permite al encargado de la
prueba validar complejos
conjuntos de acciones y
condiciones.
12
Dentro del método de Caja Negra la
técnica de la Partición de Equivalencia es
una de las más efectivas pues permite
examinar los valores válidos e inválidos
de las entradas existentes en el software,
descubre de forma inmediata una clase de
errores que, de otro modo, requerirían la
ejecución de muchos casos antes de
detectar el error genérico. La partición
equivalente se dirige a la definición de
casos de pruebas que descubran clases de
errores, reduciendo así en número de
clases de prueba que hay que desarrollar.
Partición equivalente
Una partición equivalente es una técnica
de prueba de Caja Negra que divide el
dominio de entrada de un programa en
clases de datos de los que se pueden
derivar casos de prueba. El diseño de
estos casos de prueba para la partición
equivalente se basa en la evaluación de
las clases de equivalencia.
El diseño de casos de prueba para la
partición equivalente se basa en una
evaluación de las clases de equivalencia
para una condición de entrada. Una clase
de equivalencia representa un conjunto de
estados válidos o inválidos para
condiciones de entrada.
Regularmente, una condición de entrada
es un valor numérico específico, un rango
de valores, un conjunto de valores
relacionados o una condición lógica.
Las clases de equivalencia se pueden
definir de acuerdo con las siguientes
directrices: Si un parámetro de entrada
debe estar comprendido en un cierto
rango, aparecen 3 clases de equivalencia:
por debajo, en y por encima del rango.
Si una entrada requiere un valor concreto,
aparecen 3 clases de equivalencia: por
debajo, en y por encima del rango.
Si una entrada requiere un valor de entre
los de un conjunto, aparecen 2 clases de
equivalencia:
en el
conjunto o
fuera de él.
Si una
entrada es
booleana,
hay 2 clases:
si o no.
Los mismos
criterios se
aplican a las
salidas
esperadas:
hay que intentar generar resultados en
todas y cada una de las clases.
13
Aplicando estas directrices se ejecutan
casos de pruebas para cada elemento de
datos del campo de entrada a desarrollar.
Los casos se seleccionan de forma que
ejerciten el mayor número de atributos de
cada clase de equivalencia a la vez.
Para aplicar esta técnica de prueba se
tienen en cuenta los siguientes pasos:
Primero se deben identificar las
clases de equivalencia lo cual se
hace tomando
Cada condición de entrada y aplicándole
las directrices antes expuestas.
Para definir las clases de equivalencia
hace falta tener en cuenta un conjunto de
reglas: Si una condición de entrada
especifica un rango, entonces se
confeccionan una clase de equivalencia
válida y 2 inválidas. Si una condición de
entrada especifica la cantidad de valores,
identificar una clase de equivalencia
válida y dos inválidas. Si una condición
de entrada especifica un conjunto de
valores de entrada y existen razones para
creer que el programa trata en forma
diferente a cada uno de ellos, identificar
una clase válida para cada uno de ellos y
una clase inválida. Si una condición de
entrada especifica una situación de tipo
“debe ser”, identificar una clase válida y
una inválida. Si existe una razón para
creer que el programa no trata de forma
idéntica ciertos elementos pertenecientes
a una clase, dividirla en clases de
equivalencia menores.
Luego de tener las clases válidas e
inválidas definidas, se procede a
definir los casos de pruebas, pero
para ello antes se debe haber
asignado un identificador único a
cada clase de equivalencia.
Luego entonces se pueden definir
los casos teniendo en cuenta lo
siguiente:
1. Escribir un nuevo caso de cubra
tantas clases de equivalencia
válidas no cubiertas como sea
posible hasta que todas las clases
de equivalencia hayan sido
cubiertas por casos de prueba.
2. Escribir un nuevo caso de prueba
que cubra una y solo una clase de
equivalencia inválida hasta que
todas las clases de equivalencias
inválidas hayan sido cubiertas por
casos de pruebas.
Con la aplicación de esa técnica se
obtiene un conjunto de pruebas que
reduce el número de casos de pruebas y
nos dicen algo sobre la presencia o
ausencia de errores. A menudo se plantea
que las pruebas a los software nunca
terminan, simplemente se transfiere del
desarrollador al cliente. Cada vez que el
cliente usa el programa está llevando a
cabo una prueba.
Aplicando el diseño de casos de pruebas
al software en cuestión se puede
conseguir una prueba más completa y
descubrir y corregir el mayor número de
errores antes de que comiencen las
“pruebas del cliente”.
14
Procedimientos de prueba
Un procedimiento de prueba específica
como realizar uno o varios casos de
prueba o parte de estos. Por ejemplo un
procedimiento de prueba puede ser una
instrucción para un individuo sobre cómo
ha de realizar un caso de prueba
manualmente, o puede ser una
especificaron de cómo interaccionar
manualmente con una herramienta de
automatización de pruebas para crear
componentes ejecutables de pruebas.
El cómo llevar a cabo un caso de prueba
puede ser especificado por un
procedimiento de prueba pero es a
menudo útil reutilizar un procedimiento
de prueba para varios casos de prueba y
reutilizar varios procedimientos de prueba
para varios casos de prueba.
Componentes de prueba
Un componente de prueba automatiza uno
o varios procedimientos de prueba o parte
de ellos.
Los componentes de pruebas pueden ser
desarrollados utilizando lenguaje de
guiones o un lenguaje de programación o
pueden ser grabados con una herramienta
de automatización de pruebas.
Los componentes de pruebas se utilizan
para probar los componentes en el
modelo de implementación
proporcionando entradas de prueba,
controlando y monitorizando la ejecución
de los componentes a probar y,
posiblemente informando de los
resultados de las pruebas.
Plan de Prueba
El propósito del plan de pruebas es dejar
de forma explicita el alcance, el enfoque,
los recursos requeridos, el calendario, los
responsables y el manejo de riesgos de un
proceso de pruebas.
15
Está constituido por un conjunto de
pruebas. Cada prueba debe:
Dejar claro qué tipo de
propiedades se quieren probar
(corrección, robustez, fiabilidad,
amigabilidad,...).
Dejar claro cómo se mide el
resultado.
Especificar en qué consiste la
prueba (hasta el último detalle de
cómo se ejecuta).
Definir cual es el resultado que se
espera (identificación,
tolerancia,...). ¿Cómo se decide
que el resultado es acorde con lo
esperado?
Las pruebas carecen de utilidad, tanto, sí
no se sabe exactamente lo que se quiere
probar, sí no se está claro cómo se
prueba, o si el análisis del resultado se
hace a simple vista. Estas mismas ideas se
suelen agrupar diciendo que un caso de
prueba consta de 3 bloques de
información:
1. El propósito de la prueba.
2. Los pasos de ejecución de la
prueba.
3. El resultado que se espera.
Todos y cada uno de esos puntos deben
quedar perfectamente documentados. El
plan de pruebas señala el enfoque, los
recursos y el esquema de actividades de
prueba, así como los elementos a probar,
las características, las actividades de
prueba, el personal responsable y los
riesgos.
Una estrategia de prueba propone
movernos hacia afuera en una espiral, de
manera que primero se prueban las
unidades más pequeñas del diseño del
software (clases o módulos) y después
como se integran los componentes en los
cuales están contenidas estas unidades.
RUP propone definir casos de prueba de
integración para verificar que los
componentes interaccionan entre sí de
forma apropiada.
A partir de un caso de uso se pueden
realizar pruebas de caja negra,
obteniéndose varios casos de prueba que
permiten:
Verificar el resultado de la
interacción entre los actores y el
sistema.
Comprobar que se satisfagan las
precondiciones y poscondiciones
del caso de uso.
16
Comprobar que se siga la
secuencia de acciones
especificado por el caso de uso.
También se pueden realizar pruebas de
caja blanca a partir de la realización de un
caso de prueba que permiten obtener
casos de prueba en los que se verifica la
integración ante los componentes que
implementan dicho caso de uso.
Defecto
Un defecto es una anomalía del sistema,
como por ejemplo un síntoma de una
fallo software o un problema descubierto
en una revisión. Un defecto puede ser
utilizado para localizar cualquier cosa que
los desarrolladores necesitan registrar
como síntoma de un problema en el
sistema que ellos necesitan controlar y
resolver.
Evaluación de prueba
Una evaluación de prueba es una
evaluación de los resultados de los
esfuerzos de prueba, tales como la
cobertura del caso de prueba, la cobertura
del código y el estado de los defectos
.
17
Bibliografía Contenido:
Microsoft.com, Cómo: Crear un caso de prueba manual, 2015
https://msdn.microsoft.com/es-es/library/vstudio/dd286659%28v=vs.110%29.aspx
[consulta: jueves, 09 de abril del 2015, hora: 14:15]
Ecured, Pruebas de caja blanca, 2015,
http://www.ecured.cu/index.php/Pruebas_de_caja_blanca [consulta: jueves, 09 de
abril del 2015, hora: 14:15]
Ecured, Pruebas de caja negra, 2015,
http://www.ecured.cu/index.php/Pruebas_de_caja_negra [consulta: jueves, 09 de
abril del 2015, hora: 15:15]
TELLO, Rodriguez, Importancia de las pruebas de software, 2011,
http://www.tamps.cinvestav.mx/~ertello/swe/swTestingTecZacatecas.pdf [consulta:
jueves, 09 de abril del 2015, hora: 16:17]
Imágenes:
http://identidadgeek.com, Software, S.F., recuperado de:
http://identidadgeek.com/category/software/
ORE, Alexander, UNIT TESTING - PRUEBAS UNITARIAS - CAP 1, 2011,
recuperado de: http://www.calidadysoftware.com/testing/pruebas_unitarias1.php
ROMAY, Alfonzo, Complejidad innecesaria en las organizaciones,2014,
recuperado de: http://www.scalabble.com/2014/05/complejidad-innecesaria/
18
www.muycanal.com, La complejidad de elegir un software empresarial adecuado,
2011, recuperado de: http://www.muycanal.com/2011/06/15/software-empresarial-
adecuad-empresas
Ecured, Pruebas de caja negra, 2015, recuperado de:
http://www.ecured.cu/index.php/Pruebas_de_caja_negra
LOPEZ, Alex, Periodo de prueba, 2014, recuperado de:
http://alaboralista.com/periodo-de-prueba/
androideity.com, Componentes de una aplicación Android, 2011, recuperado de:
http://androideity.com/2011/07/05/componentes-de-una-aplicacion-android/
www.catlab.com.ar,Validacion de los sistemas informáticos, 2011, recuperado de:
http://www.catlab.com.ar/notas.php?idm=1419&accion1=notas&PHPSESSID=25d
db8ccac6a586bebdaac642ca3a248
rupproceso.blogspot.com, RUP, 2011, recuperado de:
http://rupproceso.blogspot.com/
brightphone-web.sharepoint.com, Lista de precios, S.F. , recuperado de:
https://brightphone-web.sharepoint.com/Pages/Inicio.aspx
19
http://www.catlab.com.ar/notas.php?idm=1419&accion1=notas&PHPSESSID=25ddb8ccac6a586bebdaac642ca3a248
UN POCO DE HUMOR
