Pruebas de software

MAESTRO: ING. OSCAR JESUS DERRAMONA GODINEZ

ALUMNA:
AMAYRANI JIMENEZ NAVA

MATERIA:
INGENIERÍA DE SOFTWARE II

“TECNOLOGIAS DE LA INFORMACIÓN Y
COMUNICACIÓN DEL ÁREA SISTEMAS INFORMATICOS”
5 “A”

OCOTITO, GRO., A 15 DE MARZO DEL 2018

 TIPOS DE PRUEBAS DE SOFTWARE

Objetivos de las pruebas

 Encontrar defectos en el software

 Una prueba tiene éxito si descubre un defecto
 Una prueba fracasa si hay defectos, pero no los descubre

Pruebas de Verificación

 Ver si cumple las especificaciones de diseño

Pruebas de Validación

 Ver si cumple los requisitos del análisis

El proceso de pruebas del software tiene dos objetivos:

1. Demostrar al desarrollador y al cliente que el software satisface sus

requerimientos.

Para el software a medida, significa que debe haber al menos una prueba para cada
requerimiento del sistema y del usuario.

Para software genérico, significa que debe haber pruebas para todas las
características del sistema que se incorporarán en la entrega del producto.

Este objetivo conduce a las pruebas de validación => se espera que el sistema
funcione correctamente usando un conjunto determinado de casos de prueba que
reflejan el uso esperado de aquél.

2. Descubrir defectos en el software: que su comportamiento es incorrecto, no

deseable o no cumple su especificación.

La prueba de defectos está relacionada con la eliminación de todos los

comportamientos no deseables.
Ej: caídas del sistema, interacciones no permitidas con otros sistemas, cálculos
incorrectos y corrupción de datos. Este objetivo conduce a la prueba de defectos,
cuando los casos de prueba se diseñan para exponer los defectos.

Pruebas de “caja blanca”

Concepto y terminología

 Pruebas en que se conoce el código a probar

 Caja blanca (clear box: caja clara o transparente)
 Se procura ejercitar cada elemento del código

Algunas clases de pruebas

 Pruebas de cubrimiento
 Pruebas de condiciones
 Pruebas de bucles

Pruebas de cubrimiento
 Ejecutar al menos una vez cada sentencia
 Se necesitan varios casos de prueba
o Determinar posibles “caminos” independientes
o Cada condición debe cumplirse en un caso y en otro no. En general,
se necesitan tantos casos como condiciones, más uno (número
ciclomático)
 Puede ser imposible cubrir el 100%
o Código que nunca se ejecuta: condiciones imposibles
o Ejemplo: detección y notificación de errores internos en un código sin
errores

Pruebas de condiciones
 Cumplir o no cada parte de cada condición
 Se necesitan varios casos de prueba
o Determinar expresiones simples en las condiciones
o Una por cada operando lógico o comparación
o Cada expresión simple debe cumplirse en un caso y en otro no,
siendo decisiva en el resultado
 Puede ser imposible cubrir el 100%
 Expresiones simples no independientes

Pruebas de bucles
 Conseguir números de repeticiones especiales
 Bucles simples
o Repetir cero, una y dos veces
o Repetir un número medio (típico) de veces
o Repetir el máximo-1, máximo y ¡máximo +1!
 Bucles anidados
o Repetir un número medio (típico) los bucles internos, el mínimo los
externos, y variar las repeticiones del bucle intermedio ensayado.
o Ensayarlo con cada nivel de anidamiento

Pruebas de “caja negra”

 Concepto y terminología
o Pruebas en que se conoce sólo la interfaz
o Caja negra (black box: caja opaca)
o Se procura ejercitar cada elemento de la interfaz
 Algunas clases de pruebas
o Cubrimiento invocar todas las funciones (100%)
o Clases de equivalencia de datos
 o Pruebas de valores límite

Pruebas de valores límite

 Complemento a las particiones de equivalencia
 Varios casos de prueba por cada partición
o Valores típicos, intermedios
o Valores primero y segundo del rango
o Valores penúltimo y último
o Valores vecinos fuera del rango (en otra partición)
 Motivación
o Los programadores se equivocan con más frecuencia al tratar los
valores en la frontera (Ej: > en vez de )

Pruebas sin estrategia

 Motivación
o Las pruebas son incómodas
o La pruebas son aburridas
o “Estoy seguro de que lo he codificado bien”
 Probar todo junto, al final - Big-Bang
o Falla por todas partes
o Muy difícil diagnosticar las causas de los fallos
o Muy costoso de arreglar
o Resultado productos finales defectuosos
 Pruebas de Unidad

Se concentra en el esfuerzo de verificación de la unidad más pequeña del diseño

del software: el componente o módulo del software.

Las pruebas de unidad se concentran en la lógica del procesamiento interno. Este

tipo de prueba se puede aplicar en paralelo a varios componentes.

Pruebas de Integración

“Si todo funciona bien individualmente, ¿por qué dudan que funcione cuando se
une?

La prueba de integración es una técnica sistemática para construir la arquitectura

del software, mientras, al mismo tiempo, se aplican las pruebas para descubrir
errores asociados con la interfaz.

El objetivo es tomar componentes a los que se aplicó una prueba de unidad y

construir una estructura de programa que determine el diseño.

A menudo se tiende a intentar una integración que no sea incremental (enfoque “big
bang”), se combinan todos los componentes por anticipado, se prueba todo el
programa como un todo.
 Pruebas de integración

La principal dificultad que surge en las pruebas de integración es localizar los

errores.

Hay interacciones complejas entre los componentes del sistema, y cuando se

descubre una salida anómala, es difícil identificar dónde ha ocurrido el error. Para
facilitar la localización de errores, debería utilizarse una aproximación incremental
para la integración y pruebas del sistema.

Inicialmente, debería integrarse una configuración del sistema mínima y probar este
sistema.

A continuación, deberían añadirse componentes a esta configuración mínima y

probar después de añadir cada incremento.

Pruebas de regresión

 Repetir las pruebas tras cada modificación

o Repetir sólo pruebas de verificación
 Pruebas de unidades
 Pruebas de integración
 Conservar y actualizar los programas de prueba
 Usar herramientas de ejecución automática de las pruebas

Cuando se integra un nuevo incremento, hay que volver a ejecutar las pruebas
para incrementos previos, así como las nuevas pruebas requeridas para verificar
la nueva funcionalidad del sistema. Volver a ejecutar un conjunto existente de
pruebas se denomina pruebas de regresión.

Si las pruebas de regresión nos muestran problemas, entonces hay que verificar
si éstos son problemas en el incremento previo o si son debidos al incremento
añadido de funcionalidad.

Pruebas de Validación
Las pruebas de validación empiezan tras la culminación de la prueba de integración,
cuando se han ejercitado los componentes individuales. Se ha terminado de
ensamblar el software como paquete y se han descubierto y corregido los errores
de interfaz. La prueba se concentra en las acciones visibles para el usuario y en la
salida del sistema que éste puede reconocer.

La validación se define de una forma simple en que se alcanza cuando el software

funciona de tal manera que satisface las expectativas razonables del cliente
(especificación de requisitos-criterios de validación.

Comprobar que se satisfacen los requisitos

 Se usan la misma técnica, pero con otro objetivo

 No hay programas de prueba, sino sólo el código final de la aplicación

 Se prueba el programa completo

 Uno o varios casos de prueba por cada requisito o caso de uso

especificado

 Se prueba también rendimiento, capacidad, etc. (y no sólo resultados

correctos)

 Pruebas alfa (desarrolladores) y beta (usuarios)

Pruebas del Sistema

 Al final del desarrollo el software se incorpora a otros elementos del sistema

(hardware, personas, información) y se realiza una serie de pruebas de
integración del sistema y de validación.
 Estas pruebas están más allá del alcance del proceso del software y no las
realizan únicamente los ingenieros de software.
 Sin embargo, los pasos dados durante el diseño y la prueba del software
mejorarán en gran medida la probabilidad de tener éxito en la integración del
software del sistema mayor.
Prueba de seguridad

 La interrupción abarca un ampliorango de actividades: hackers

 La prueba de seguridad comprueba que los mecanismos de protección
integrados en el sistema realmente lo protejan de irrupciones inapropiadas.
 Durante la prueba de seguridad quién la aplica desempeña el papel del
individuo que desea entrar en el sistema.

Prueba de resistencia

 Las pruebas de resistencia están diseñadas para confrontar los programas

con situaciones anormales.
 La prueba de resistencia ejecuta un sistema de tal manera que requiera una
frecuencia o un volumen anormal de recursos
 La persona que aplica la prueba tratará de sobrecargar el programa.
 Una variante de la prueba de resistencia es una técnica denominada prueba
de sensibilidad.
 Las pruebas de sensibilidad tratan de descubrir combinaciones de datos
dentro de las clases de entrada válidas que causen inestabilidad o
procesamiento inapropiado.

Prueba de desempeño

 La prueba de desempeño está diseñada para probar el desempeño del

software en tiempo de ejecución dentro del contexto de un sistema integrado.
 La prueba de desempeño se aplica en todos los pasos del proceso de la
prueba, incluso al nivel de la unidad, el desempeño de un módulo individual
debe evaluarse mientras se realizan las pruebas.
 Sin embargo no es sino hasta que se encuentren totalmente integrados todos
los elementos del sistema que es posible asegurar el verdadero desempeño
del sistema.
 Diseño de casos de prueba

El diseño de casos de prueba es parte de las pruebas de componentes y sistemas.

Consiste en diseñar los casos de prueba (entradas y salidas esperadas) para probar
el sistema.

El objetivo es crear un conjunto de casos de prueba que sean efectivos

descubriendo defectos en los programas y muestren que el sistema satisface sus
requerimientos.

Para diseñar un caso de prueba, se selecciona una característica del sistema o

componente que se está probando.

Casos de pruebas
Un caso de prueba o test case es, en ingeniería del software, un conjunto de
condiciones o variables bajo las cuáles un analista determinará si una aplicación,
un sistema software (software system), o una característica de éstos es parcial o
completamente satisfactoria.

Se pueden realizar muchos casos de prueba para determinar que un requisito es

completamente satisfactorio. Con el propósito de comprobar que todos los
requisitos de una aplicación son revisados, debe haber al menos un caso de prueba
para cada requisito a menos que un requisito tenga requisitos secundarios. En ese
caso, cada requisito secundario deberá tener por lo menos un caso de prueba.
Algunas metodologías como RUP recomiendan el crear por lo menos dos casos de
prueba para cada requisito. Uno de ellos debe realizar la prueba positiva de los
requisitos y el otro debe realizar la prueba negativa.

Si la aplicación es creada sin requisitos formales, entonces los casos de prueba se

escriben basados en la operación normal de programas de una clase similar.

Lo que caracteriza un escrito formal de caso de prueba es que hay una entrada
conocida y una salida esperada, los cuales son formulados antes de que se ejecute
la prueba. La entrada conocida debe probar una precondición y la salida
esperada debe probar una postcondición.

Bajo circunstancias especiales, podría haber la necesidad de ejecutar la prueba,

producir resultados, y luego un equipo de expertos evaluaría si los resultados se
pueden considerar como "correctos". Esto sucede a menudo en la determinación
del número del rendimiento de productos nuevos. La primera prueba se toma como
línea base para los subsecuentes ciclos de pruebas/lanzamiento del producto.

Los casos de prueba escritos, incluyen una descripción de la funcionalidad que se

probará, la cuál es tomada ya sea de los requisitos o de los casos de uso, y la
preparación requerida para asegurarse de que la prueba pueda ser dirigida.

Los casos de prueba escritos se recogen generalmente en una suite de pruebas.

Las variaciones de los casos de prueba son comúnmente utilizados en pruebas de

aceptación. La prueba de aceptación es realizada por un grupo de usuarios finales o
los clientes del sistema, para asegurarse que el sistema desarrollado cumple sus
requisitos. La prueba de aceptación de usuario se distingue generalmente por la
incorporación de un trayecto feliz o casos de prueba positivos.

Estructura de los casos de prueba

Formalmente, los casos de prueba escritos consisten principalmente en tres partes
con subdivisiones:

 Introducción/visión general: Contiene información general acerca de los

Casos de Prueba.
 Identificador: Es un identificador único para futuras referencias, por
ejemplo, mientras se describe un defecto encontrado.
 Caso de prueba dueño/creador: Es el nombre del analista o diseñador de
pruebas, quien ha desarrollado pruebas o es responsable de su desarrollo.
 Versión: La actual definición del caso de prueba.
  Nombre: El caso de prueba debe ser un título entendible por personas, para
la fácil comprensión del propósito del caso de prueba y su campo de
aplicación.
 Identificador de requerimientos: el cuál está incluido por el caso de
prueba. También aquí puede ser un identificador de casos de uso o
de especificación funcional.
 Propósito: Contiene una breve descripción del propósito de la prueba, y la
funcionalidad que chequea.
 Dependencias: Indica qué otros subsistemas están involucrados y en qué
grado.
 Actividades de los casos de prueba
 Ambiente de prueba/configuración: Contiene información acerca de la
configuración del hardware o software en el cuál se ejecutará el caso de
prueba.
 Inicialización: Describe acciones, que deben ser ejecutadas antes de que
los casos de prueba se hayan inicializado. Por ejemplo, debemos abrir algún
archivo.
 Finalización: Describe acciones, que deben ser ejecutadas después de
realizado el caso de prueba. Por ejemplo si el caso de prueba estropea la
base de datos, el analista debe restaurarla antes de que otro caso de prueba
sea ejecutado.
 Acciones: Pasos a realizar para completar la prueba.
 Descripción de los datos de entrada
 Resultados
 Salida esperada: Contiene una descripción de lo que el analista debería ver
tras haber completado todos los pasos de la prueba.
 Salida obtenida: Contiene una breve descripción de lo que el analista
encuentra después de que los pasos de prueba se hayan completado.
 Resultado: Indica el resultado cualitativo de la ejecución del caso de prueba,
a menudo con un Correcto/Fallido.
  Severidad: Indica el impacto del defecto en el sistema: Grave, Mayor,
Normal, Menor.
 Evidencia: En los casos que aplica, contiene información, bien un link al
print de pantalla (screenshot), bien una consulta a una base de datos, bien
el contenido de un fichero de trazas, donde se evidencia la salida obtenida.
 Seguimiento: Si un caso de prueba falla, frecuentemente la referencia al
defecto implicado se debe enumerar en esta columna. Contiene el código
correlativo del defecto, a menudo corresponde al código del sistema de
tracking de bugs que se esté usando.
 Estado: Indica si el caso de prueba está: No iniciado, En curso, o terminado.

Herramientas para pruebas de software

1) Herramientas de gestión de pruebas

− Bugzilla Testopia: es un administrador de casos de prueba, que maneja

extensiones para interactuar con Bugzilla. Testopia es una herramienta genérica
para el seguimiento de casos de prueba de software e integrar reportes de defectos
encontrados, así como el resultado de los casos de prueba. Testopia está diseñado
desde el punto de vista de la actividad de pruebas, así como el seguimiento virtual
de cualquier proceso de ingeniería.

− FitNesse: es un servidor wiki web, que tiene una entrada y curva de aprendizaje
muy baja, lo que lo convierte en una excelente herramienta para colaborar con, el
análisis de una aplicación.

− qaManager: es una aplicación independiente diseñada para la gestión y control

de calidad de proyectos, con una instalación muy sencilla. qaManager tiene
seguimiento de proyectos, Administración de Recursos, Gestión de TC, Biblioteca
en línea, alertas y más.
− qaBook: es un producto de gestión de pruebas que permite crear, gestionar y
editar requerimientos, Casos de prueba (con o sin pasos de prueba), pruebas de
funcionamiento, Defectos, Entornos, Presentación de informes y más. Posee una
elección de escritorio a través de la web o en Microsoft SharePoint, como interfaz
de usuario.

− RTH (open source): es un Sistema relativamente nuevo, la documentación que

existe no es mucha, y la que hay es poco clara. Requiere de pruebas y registros
para su calificación.

− Test Environment Toolkit: Es ampliamente utilizado en muchas aplicaciones de

prueba, incluyendo el programa de certificación UNIX del Open Group y LSB
programa de Certificación de la Free Standards Group.

− Testitool: utiliza diversos casos de prueba, por lo que es muy versátil. Cada plan
de prueba contiene la lista maestra de todos los casos de prueba para un producto
determinado. Sin embargo, para cualquier versión dada puede que no se desee
ejecutar todos y cada caso de prueba. Testitool permite seleccionar y elegir qué
prueba caso tendrá que ejecutar para cualquier instancia dada del plan de pruebas.

− XQual Studio: Es más que una plataforma estándar de gestión de pruebas, es

una solución líder que maneja el ciclo de vida completo de sus proyectos de
GC/prueba de principio a fin: productos / comunicados, requisitos, especificaciones,
proyectos ágiles, pruebas, campañas de prueba, prueba de informes y defectos.
− Radi-testdir: es una herramienta de gestión de pruebas que soporta
características testdirectory como configurar el plan de pruebas, la actualización
(crear/editar) los resultados de las pruebas para la imagen/construcción, copia de
seguridad, gestión de usuarios.

− Data Generator: Realiza un estudio de diferentes aplicaciones tal como se ilustra

en la imagen.

2) Herramientas para pruebas funcionales

− Selenium: Está compuesto por una lista de versiones anteriores y código fuente,
así como información adicional para los usuarios de Maven (Maven es una
herramienta popular de construcción Java).
Es un entorno de pruebas de software para aplicaciones basadas en la web. Permite
grabar/reproducir pruebas en una amplia gama de lenguajes de programación tales
como: Java, C#, Ruby, Groovy, Perl, Php y Python.

Las pruebas pueden ejecutarse en la mayoría de los navegadores web actuales

sobre diferentes sistemas operativos como Windows, Linux y OSX.

Los componentes de la suite Selenium son:

Selenium IDE: Es un plugin de Firefox que permite grabar y reproducir test en

Firefox. Permite generar código para ejecutar posteriormente las pruebas con
Selenium Remote Control.

Selenium Remote Control: Es un servidor escrito en Java que acepta comandos al

navegador vía HTTP. RC hace posible escribir pruebas automatizadas para
aplicaciones web, en cualquier lenguaje de programación lo que permite una mejor
integración de Selenium a entornos de prueba existentes.

Selenium WebDriver: Es el sucesor de Selenium RC. Selenium WebDriver acepta

comandos (enviados en Selenese o vía el API del cliente) y los envía a un
navegador.

Selenium Grid: Es un servidor que permite usar instancias del

navegador ejecutándose en máquinas remotas.

− Soapui: Es una solución multiplataforma de código abierto. Dispone de una fácil
interfaz gráfica. Permite crear y ejecutar pruebas funcionales, de regresión, de
cumplimiento y de carga automatizadas con facilidad y rapidez. En un solo entorno
de prueba, SoapUI ofrece cobertura de prueba completa y apoya todos los
protocolos y tecnologías estándar.

Watir (Pruebas de aplicaciones web en Ruby): Es una aplicación de código abierto

(BSD) con una familia de bibliotecas de Ruby para la automatización de los
navegadores web. Se le permite escribir pruebas que son fáciles de leer y mantener.
Es simple y flexible.

Watir sólo es compatible con Internet Explorer en Windows, WatirWebDriver apoya

Chrome, Firefox, Internet Explorer, Opera y también se ejecuta en modo HtmlUnit.
Al igual que otros lenguajes de programación, Ruby permite conectarse a bases de
datos, leer archivos y hojas de cálculo, exportación en formato XML, al igual que
código como bibliotecas reutilizables.

− WatiN (Pruebas de aplicaciones web en .Net): Inspirado por el desarrollo Watir,

WatiN comenzó en diciembre de 2005 para hacer el mismo tipo de pruebas de
aplicaciones Web en lenguajes .Net. Desde entonces WatiN se ha convertido en
una herramienta fácil de usar en diversas necesidades corporativas. WatiN está
desarrollado en C # y su objetivo es lograr automatizar sus pruebas con Internet
Explorer y FireFox utilizando .Net.

− Capedit: LabShark es una suite de productos de pruebas de protocolo en redes.

La familia de productos de LabShark permite modificar y editar los paquetes a
medida que fluyen entre los dispositivos y probar cualquier protocolo que se desee.

− Canoo WebTest. Es una herramienta de código abierto para pruebas

automatizadas de aplicaciones web de manera muy eficaz.
− Solex: Es una herramienta de prueba gratuita de código abierto para aplicación
Web construida como un plug-in para Eclipse IDE. Proporciona funciones para
grabar una sesión de cliente, ajustarlo de acuerdo a diversos parámetros y
reproducir posteriormente con el fin de garantizar la no regresión del
comportamiento de la aplicación (con capacidades de pruebas de estrés que se
añade en una etapa posterior).

Solex actúa como un proxy HTTP y registra todas las peticiones y respuestas HTTP
que pasan por el cable entre un cliente Web (por ejemplo. Un navegador web) y un
servidor Web. La tarea de reproducir un escenario consiste en enviar las peticiones
HTTP previamente grabadas hacia el servidor y afirmando cada respuesta.
− SAMIE: Es un módulo automatizado para Internet Explorer. Permite escribir
scripts de Perl con el fin de analizar Internet Explorer en toda la web, en particular
como se muestra la información de la empresa al mundo. El sistema puede registrar
todos los resultados en una base de datos o en un archivo de texto plano. Se puede
publicar esos resultados a una página web de la empresa.

− WET: Es una herramienta de prueba de automatización opensource web.

Funciona sobre un navegador directamente comprobando de forma automática las
páginas web. Permite realizar diversos controles como parte del proceso de prueba
mediante el uso de puntos de control.

− WebInject: Es una herramienta gratuita para pruebas automatizadas de

aplicaciones web y servicios web. Se utiliza para probar los componentes
individuales del sistema que tienen interfaces HTTP (JSP, ASP, CGI, PHP, AJAX,
Servlets, formularios HTML, XML/Servicios web SOAP, REST, etc.), también como
un instrumento de pruebas funcionales, de aceptación y de regresión. Permite
ejecutar muchos casos y recoger/reportar sus resultados en tiempo real.

3) Herramientas para pruebas de carga y rendimiento

− FunkLoad: Esta herramienta permite hacer pruebas funcionales y de carga de

aplicaciones web.

− FWPTT load testing: Es un programa que permite hacer pruebas funcionales y

de carga de aplicaciones web. Se puede grabar peticiones normales o en ajax. Se
he comprobado en aplicaciones ASP.NET, pero funciona con JSP, PHP u otros.

− loadUI: Ejecuta pruebas de carga rápida de la API, ya sea contra un solo punto
final del servicio web o contra varios, en minutos, no en días.
− jmeter: Es un software desarrollado en Java de código abierto, diseñado para
efectuar pruebas funcionales y medir el rendimiento de una aplicación. Fue
diseñado originalmente para pruebas de aplicaciones web, pero desde entonces se
ha expandido a otras funciones de prueba. jmeter incluye:

Capacidad de carga y pruebas de rendimiento para diferentes tipos de servidor /

protocolo:

 Web - HTTP, HTTPS

 SOAP / REST
 FTP
 Base de datos a través de JDBC
 LDAP
 Middleware orientado a mensajes (MOM) a través de JMS
 Correo - SMTP (S), POP3 (S) e IMAP (S)
 MongoDB (NoSQL)
 Comandos o scripts de shell Nativo
 TCP

JMeter presenta un marco completo multithreading, permite el muestreo simultáneo

por muchos hilos y muestreo simultáneo de funciones diferentes por grupos de hilos
separados. Tiene un diseño GUI cuidadoso, que permite pruebas más rápidas y
depuración, con almacenamiento en caché y análisis online y offline.

Núcleo altamente extendible: Tiene capacidades de pruebas ilimitadas. Muestra

estadísticas de carga que pueden ser elegidos con temporizadores. También,
permite el análisis de datos y visualización de plugins.
Las funciones pueden ser utilizadas para proporcionar la entrada dinámica a
una prueba o proporcionar manipulación de datos.

Conclusión

Las pruebas de software se basan en la investigación empírica y técnica que permite

proporcionar información objetiva e independiente sobre la calidad de la aplicación
a la parte interesada o stakeholder. Forma parte crítica del proceso de control de
calidad. Es por ello que no se puede subestimar las pruebas de software, si se desea
garantizar un producto de calidad a los usuarios.

Las pruebas son básicamente un conjunto de actividades dentro del desarrollo de

software. Dependiendo del tipo de pruebas, estas actividades podrán ser
implementadas en cualquier momento de dicho proceso de desarrollo. Existen
distintos modelos de desarrollo de software, así como modelos de pruebas. A cada
uno corresponde un nivel distinto de involucramiento en las actividades de
desarrollo.

Bibliografía

https://es.scribd.com/doc/311003407/Las-Mejores-Herramientas-Para-Realizar-Pruebas-de-
Software

https://es.wikipedia.org/wiki/Caso_de_prueba

file:///G:/tiposdepruebasdesoftware-120427121354-phpapp01.pdf