Tec Sup Desarrollo Aplicaciones Multiplataforma Desarrollo de Interfaces 08

Desarrollo de
Interfaces
Técnico Superior en
Desarrollo de Aplicaciones
Multiplataforma
© Centro para la Cultura y el Conocimiento, S.A.
ISBN-13: 978-84-7157-397-1
ISBN-10: 84-7157-397-0
E-m06-22
Printed in Spain
Queda rigurosamente prohibida, sin autori-

zación escrita de los titulares del "copyright"
bajo las sanciones establecidas en las leyes, la
reproducción parcial o total de esta obra por
cualquier medio o procedimiento, comprendi-
dos la reprografía y el tratamiento informático
y la distribución de ejemplares de ella median-
te alquiler o préstamos públicos.
8
Realización
de pruebas.
TÉCNICO SUPERIOR EN DESARROLLO DE APLICACIONES MULTIPLATAFORMA 151

Módulo | Desarrollo de Interfaces
Sumario
1. Introducción a la realización de pruebas................................................................. 153
2. Objetivo, importancia y limitaciones del proceso de prueba. Estrategias............. 154
3. Pruebas de integración: ascendentes y descendentes............................................ 157
4. Pruebas de sistema: configuración y recuperación................................................. 158
5. Pruebas de regresión................................................................................................ 160
6. Pruebas funcionales.................................................................................................. 161
7. Pruebas de capacidad y rendimiento....................................................................... 162
8. Pruebas de uso de recursos...................................................................................... 163
9. Pruebas de seguridad............................................................................................... 164
10. Pruebas manuales y automáticas. Herramientas software
para la realización de pruebas.................................................................................. 165
11. Pruebas de usuario.................................................................................................. 166
12. Pruebas de aceptación de usuario......................................................................... 167
13. Versiones alfa y beta................................................................................................ 168
Webgrafía....................................................................................................................... 169
152
TÉCNICO SUPERIOR EN DESARROLLO DE APLICACIONES MULTIPLATAFORMA
Objetivos
▶ Conocer el objetivo de la realización de pruebas y qué estrategias se pueden seguir para
implementarlas.
▶ Estudiar los diferentes tipos de pruebas que existen en el desarrollo de interfaces.
▶ Saber identificar las versiones alfa y beta de una interfaz gráfica y de cualquier aplicación.
1. Introducción
a la realización de pruebas
En el mundo del desarrollo de software un requisito indispensable es la calidad del producto
terminado.
En los siguientes apartados se estudiarán las diferentes etapas y elementos que intervienen
en las pruebas de software para medir y mejorar la calidad de las aplicaciones que desarrolle-
mos.
153
2. Objetivo, importancia y
limitaciones del proceso de
prueba. Estrategias
2.1. Objetivos de las pruebas

El objetivo principal de las pruebas de software es tratar de encontrar la mayor cantidad posi-
ble de errores en el código.
Hay que tener cuenta que todas las aplicaciones que se desarrollan tienen defectos y debemos
ser capaces de detectarlos y eliminarlos.
El objetivo inmediato es evitar que los defectos se propaguen a fases posteriores del desa-
rrollo y que pongan en riesgo el correcto funcionamiento de la aplicación en estado de produc-
ción.
154
Las pruebas de software se deben entender como:
▶ Verificación. El producto es capaz de realizar la tarea para la que ha sido creado.
▶ Validación. El producto final es correcto, y el cliente está conforme con lo que esperaba.
▶ Proceso de
verificación y
validación del
software.
2.2. Importancia de las pruebas
A nivel de desarrollo de software, cuanto más tarde se detecta un defecto, más costosa (tiempo,
recursos y dinero) es su corrección.
Debemos tratar de identificar y solucionar los defectos, tan pronto como son detectados, con
la mejora de los procesos abiertos.
Una correcta estrategia de pruebas contribuye a los siguientes puntos:
▶ Crear aplicaciones y software de calidad.
▶ Mejorar la satisfacción del cliente.
▶ Aumentar la productividad.
▶ Disminuir posibles riesgos del negocio y facilitar su crecimiento.
2.3. Limitaciones en el proceso de

prueba
155
Como ya hemos comentado, un proyecto de software desarrollado siempre tendrá defectos y
la principal finalidad del proceso de prueba es minimizarlos.
Para ello podemos seguir una serie de principios:

▶ Siempre va a existir falta de conocimiento del estado real de la aplicación durante el
desarrollo.
▶ Tener buenos conocimientos técnicos no es garantía de éxito de un proyecto.
▶ Es muy conveniente seguir procedimientos y actividades estandarizadas que nos pue-

dan servir de guía durante el desarrollo del proyecto.
Recuerda:
Aunque se realicen las pruebas más importantes, será prácticamente imposible examinar to-
dos los casos que se puedan presentar. Nunca será posible realizar todas las comprobaciones
de la aplicación.
2.4. Estrategias de las pruebas

A la hora de buscar estrategias para abordar las fases de pruebas, es conveniente buscar la
respuesta a las siguientes preguntas:
▶ ¿Cuántos niveles de pruebas habría que planificar?
▶ ¿Cuándo será conveniente poner fin a las pruebas?
▶ ¿Es conveniente automatizar las tareas?
El objetivo de la estrategia es concretar los tipos de pruebas a realizar, el calendario de ejecu-

ción, los responsables, los recursos asignados y el alcance de las pruebas.
Para ello, también deberemos conocer los siguientes aspectos:
▶ La complejidad de la aplicación y los módulos que la componen.
▶ Plataforma en la que va a poder funcionar la aplicación.
▶ Normativa legal correspondiente.
▶ Conocimientos y experiencia de los responsables quienes realizan las pruebas.

156
3. Pruebas de integración:
ascendentes y descendentes
Las pruebas de integración son aquellas que se realizan una vez han terminado las pruebas
unitarias.
Las pruebas unitarias permiten probar ciertas partes del código de forma independiente. De
esta manera, se puede probar el funcionamiento de las partes o módulos que componen la
aplicación por separado.
Las pruebas de integración consisten en verificar que el software cumple su objetivo y se rea-
liza sobre el conjunto de todos los elementos que lo componen al mismo tiempo.
Estas pruebas pueden ser ascendentes o descendentes.
Pruebas de integración ascendentes
Las pruebas de integración ascendentes consisten en comenzar por módulos de bajo nivel
hasta llegar a la aplicación final.
157
Para realizar estas pruebas se pueden seguir los siguientes pasos:
1. Se agrupan los módulos de bajo nivel por grupos con funciones similares.

2. Se controlan las entradas en esos módulos.
3. Se prueba todo el conjunto de módulos.
4. Se reemplazan los controladores y se combinan con grupos que están en niveles supe-
riores de la estructura hasta el programa principal.
Pruebas de integración descendentes
Las pruebas de integración descendentes comienzan por la aplicación general y va bajando

por los módulos inferiores.
Para realizar estas pruebas se pueden seguir los siguientes pasos:
1. Se utiliza el módulo principal como control de la prueba, guardando respaldos de los

módulos inferiores en jerarquía.
2. Se van cambiando los respaldos de módulos inferiores por los módulos reales.
3. Cuando se integra un módulo es cuando se realizan las pruebas.
4. Tras terminar con éxito las pruebas, se reemplaza el respaldo por otro real.
4. Pruebas de sistema:
configuración y
recuperación
Las pruebas de sistema buscan verificar el correcto comportamiento del sistema en su con-
junto.
En concreto, se comprueban los requisitos no funcionales del programa, como los siguien-
tes:
▶ Seguridad.
▶ Velocidad.
▶ Exactitud.
▶ Fiabilidad.
En este tipo de pruebas también se comprueban los interfaces externos con otros entornos
operativos, herramientas y unidades físicas.
158
Las pruebas de configuración y las pruebas de recuperación son, entre otras, pruebas de siste-
ma.
Pruebas de configuración
Las pruebas de configuración verifican la instalación de la aplicación en el entorno destino

y comprueban la respuesta del sistema frente a los requisitos de configuración, así como para
diferentes usuarios.
El objetivo es forzar el fallo de la aplicación a la hora de cumplir con los requerimientos de

configuración. De esta manera, se pueden detectar defectos ocultos, analizarlos, solucionarlos
y prevenirlos.
Pruebas de recuperación
Las pruebas de recuperación son pruebas de sistema que fuerzan el fallo del software de mu-
chas formas y verifican que la recuperación se lleva a cabo de forma satisfactoria.
La recuperación de la aplicación puede llevarse a cabo de manera automática o manual.
Si la recuperación es automática, se deben evaluar los siguientes elementos:
▶ La inicialización del sistema.
▶ Los mecanismos de recuperación.
▶ Los datos.
▶ El proceso de arranque.
159
5. Pruebas de regresión
Una prueba de regresión se realiza cuando se añaden nuevos componentes y módulos a una
aplicación.
Al agregar un nuevo componente o módulo se introducen nuevos cambios: nuevas rutas de

flujo de datos y una nueva ruta de control en el software. Y estos cambios pueden introducir
errores en los módulos que ya funcionaban correctamente.
Se hace necesario, por tanto, volver a ejecutar un subconjunto de pruebas para confirmar
que los nuevos cambios no han propagado errores nuevos.
La pruebas de regresión son la repetición selectiva de pruebas que detectan posibles fallos
introducidos durante la modificación de una aplicación o alguno de sus componentes.
Se pueden hacer de manera manual o mediante herramientas automáticas.
En las pruebas de regresión existen tres clases de pruebas diferentes:
▶ Planificar una muestra de pruebas sobre todos los componentes de la aplicación.
▶ Añadir pruebas adicionales centradas en las funciones que se vean afectadas por los
cambios.
160
▶ Planificar pruebas centradas solo en los componentes que se han modificado.
Las pruebas de regresión forman parte integral del método de desarrollo de software Progra-
mación Extrema (Extreme Programming).
La Programación Extrema es una metodología de desarrollo de software que se centra en reali-

zar el proceso de programación de software de manera adaptable, es decir, teniendo en cuenta
posibles cambios en los requisitos durante el desarrollo del proyecto y en el mismo momento
de estar generando el código.
Los principales valores de la Programación Extrema tienen mucha relación con las pruebas
de regresión, ya que se centran en hacer las cosas simples, en una amplia comunicación en el
desarrollo y retroalimentación continua.
Nota:
Puedes consultar más detalles sobre las pruebas realizadas

en Extreme Programming en este enlace:
http://www.extremeprogramming.org/
6. Pruebas funcionales
Las pruebas funcionales, también conocidas como pruebas de conformidad, validan si el
comportamiento de la aplicación desarrollada cumple las especificaciones (requisitos funcio-
nales) para la que fue diseñada.
Normalmente, los que realizan este tipo de pruebas son los analistas de la aplicación con la
ayuda de los usuarios finales.
Las pruebas funcionales tratan de dar respuesta a preguntas del tipo: “¿funciona esta utilidad
de la aplicación?”, “¿el usuario podría llevar a cabo tal función?”.
En este tipo de pruebas interesa verificar que las salidas que devuelve la aplicación son las
esperadas, en función de las entradas que tenga.
Dentro de las pruebas funcionales, encontramos tres tipos:
▶ Análisis de valores límite. Se seleccionan como entradas los valores que se encuentran
en el límite de validez de la aplicación.
▶ Particiones equivalentes. Se selecciona como entradas un conjunto representativo de

todas las posibles.
161
▶ Pruebas aleatorias. Se selecciona como entradas una muestra al azar. Son pruebas es-
pecíficas para aplicaciones interactivas.
En las pruebas funcionales intervienen principalmente cuatro fases:

▶ Análisis de requisitos. A partir de los procesos que podrá ejecutar el software, se realiza
la planificación de los diferentes requisitos que la aplicación deberá cumplir.
▶ Diseñar el plan de pruebas. Una vez se conocen los requisitos y características del soft-
ware, se procede a preparar las tareas de prueba específicas.
▶ Ejecutar las pruebas. En esta fase se llevan a cabo las diferentes pruebas diseñadas y
acordadas anteriormente.
▶ Gestionar las posibles incidencias. Una vez se tienen los resultados de las pruebas, es
importante recopilar los posibles errores detectados para proceder a su corrección por
parte del equipo de desarrollo.
Las pruebas funcionales se pueden ejecutar tanto de manera manual como automática.
En las pruebas funcionales manuales interviene un usuario experimentado como testeador o

tester siguiendo un plan preestablecido, mientras que en las pruebas funcionales automáticas
no interviene ningún usuario, lo que permite reducir costes en el proceso de pruebas.
7. Pruebas de capacidad y
rendimiento
Las pruebas de capacidad, también conocidas como pruebas de resistencia o estrés, bus-
can conocer hasta dónde un sistema es capaz de soportar determinadas condiciones extremas.
También tiene como finalidad determinar la capacidad de una aplicación de soportar entradas
con errores o incorrectas.
Para realizar una prueba de capacidad se pueden usar los siguientes métodos:
▶ Aumentar la cantidad de entradas para ver la respuesta de la aplicación.
▶ Ejecutar casos que requieran una memoria muy elevada.
▶ Buscar la máxima cantidad de datos residentes en disco.
▶ Hacer pruebas de sensibilidad para descubrir posibles combinaciones de datos que

puedan producir inestabilidad en el entorno.
Las pruebas de rendimiento buscan conocer el rendimiento del software en tiempo de eje-
162
cución.
Estas pruebas se usan para conocer:

▶ Los tiempos de respuesta.
▶ El espacio ocupado por los módulos en disco y en memoria.
▶ El flujo de datos que genera a través de un canal de comunicaciones, etc.
Las pruebas de rendimiento se realizan durante todas las etapas del proceso de prueba. De-
bemos tener en cuenta que, si se tarda en detectar un defecto de rendimiento, el coste de
solucionarlo será mayor.
▶ Las pruebas de rendimiento

se realizan durante todo el
proceso de prueba.
8. Pruebas de uso de recursos
Las pruebas de uso de recursos, también conocidas como pruebas de eficiencia, utilizan un
conjunto de técnicas que puedan garantizar el uso eficiente de los recursos.
También existe la necesidad de disponer de técnicas que aseguren la adaptación a otros sis-
temas, para los que la aplicación no fue específicamente diseñada pero su ejecución pueda
llevarse a cabo.
La optimización que propone este tipo de pruebas es necesaria realizarla tanto en el código
como en el uso del código.
Todo ello con el objetivo de lograr la adaptación del software a la arquitectura de destino y de
esta manera reducir los tiempos de ejecución de forma automática.
Los elementos más críticos en los sistemas informáticos y que con más frecuencia pueden alte-
rar las pruebas de uso de recursos son la memoria RAM, las unidades de procesamiento o CPUs
y el espacio de almacenamiento.
Conviene resaltar que, aunque en la actualidad los sistemas son cada vez más potentes, toda-
vía existen muchos entornos en los que se utilizan recursos que pueden estar obsoletos o faltos
de mantenimiento.
163
Por eso, las pruebas de uso de recursos son fundamentales para garantizar que nuestras apli-
caciones puedan funcionar en la mayoría de entornos, consiguiendo con ello la mejor acep-
tación por el mayor número de clientes.
▶ Las pruebas de
eficiencia del
software tienen
como objetivo
garantizar su
funcionamiento en
varios entornos.
9. Pruebas de seguridad
Las pruebas de seguridad o de integridad intentan verificar que los elementos de protección
añadidos en el sistema pueden protegerlo de accesos no autorizados.
Se trata de medir la capacidad de un sistema de soportar ataques, que pueden ser intenciona-
dos o accidentales.
Con estas pruebas se intenta verificar que el sistema es robusto frente a problemas relacio-
nados con la seguridad, como podrían ser los siguientes:
▶ Tratar de conseguir las claves de acceso de cualquier forma.
▶ Atacar con software hechos a medida.
▶ Bloquear el sistema.
▶ Provocar errores del sistema y entrar durante el intento de recuperación.
Recuerda:
Debemos tener especial cuidado con posibles entradas no autorizadas cuando se maneja
164
información de carácter privado o personal que puede ser sensible.

▶ Las pruebas de
seguridad miden
la capacidad
del sistema de
soportar ataques
intencionados y
accidentales.
10. Pruebas manuales y
automáticas. Herramientas
software para la realización
de pruebas
Los tipos de pruebas vistos hasta ahora se suelen ejecutar de manera regular con el objetivo de
probar que el software desarrollado funciona correctamente.
Estas pruebas se pueden llevar a cabo de dos formas:
▶ De forma manual, si el usuario interviene en el proceso de prueba.
▶ De forma automática, si el usuario no interviene en el proceso de prueba y este proceso

es repetible y portable.
Una de las claves es que estas pruebas puedan realizarse de manera automática ya que el
coste de ejecutarlas manualmente de manera constante sería inasumible.
165
Motivos para realizar la automatización de pruebas son los siguientes:
▶ Mejorar la calidad del producto.
▶ Detectar errores en las primeras etapas del desarrollo del proyecto.

▶ Disminuir el tiempo de pruebas y su salida al mercado.
▶ Reducir costes.
▶ Ejecutar pruebas de forma continua.
Es interesante utilizar una herramienta que automatice el proceso de pruebas. Estas herra-
mientas de pruebas de software persiguen automatizar tres tareas fundamentales:
▶ Tareas administrativas y generación de documentación.
▶ Tareas mecánicas.
▶ Tareas de generación de casos de prueba.
La elección de la herramienta de automatización es muy importante y va a depender en gran

medida del tipo de pruebas a automatizar, del entorno de desarrollo que se utilice y del lengua-
je de programación con el que la aplicación se haya creado.
Algunos ejemplos de herramientas para realizar pruebas son los siguientes:
▶ Selenium. Herramienta de código abierto utilizada en pruebas automatizadas y mecáni-

cas. Admite muchos lenguajes de programación y es multiplataforma.
▶ JMeter. Herramienta de Apache para pruebas de carga enfocada en aplicaciones y sitios

Web.
▶ Xray. Herramienta muy popular para la generación de casos de prueba completos, ges-
tionando así todo el ciclo de pruebas del producto.
11. Pruebas de usuario

Debemos tener en cuenta que los usuarios finales serán los que usen la aplicación y, por tanto,
ésta debe cubrir sus necesidades, objetivos y expectativas.
La prueba de usuario o de usabilidad consiste en verificar que la interfaz de usuario de la

aplicación sea amigable, intuitiva y que funcione de manera correcta.
Se puede evaluar la usabilidad con métricas sobre:
▶ La manera en que el usuario realiza una tarea concreta.
▶ El tiempo y número de “clics” que tarda en terminar.
▶ Los errores que comete durante el proceso.
Para comprobar la facilidad de uso de una aplicación se pueden incluir en los ensayos de
pruebas estos elementos relacionados con los usuarios:
▶ Encuestas y entrevistas.
▶ Grupos de enfoque.
▶ Pruebas con herramientas de software avanzado.

166
▶ Evaluaciones hechas por expertos en la materia.

▶ Las pruebas
de usuario
comprueban la
facilidad de uso
de una aplicación.
12. Pruebas de aceptación
de usuario
Las pruebas de aceptación de usuario o UAT (del inglés User Acceptance Testing), también lla-
madas pruebas de validación, se utilizan para comprobar que un software cumple con los re-
querimientos iniciales y que funciona satisfaciendo las expectativas del cliente.
Para que la prueba sea lo más objetiva posible, es el mismo cliente quien la debe realizar.
La validación general del sistema se realiza mediante pruebas de caja negra para comprobar
que los requisitos iniciales se cumplen.
Las pruebas de caja negra se centran en verificar el código fuente de una aplicación sin tener
en cuenta la estructura completa del código de la aplicación, así como posibles detalles en la
implementación o posibles ambientes internos de ejecución en los programas.
Las pruebas de aceptación evalúan principalmente estos tres elementos:
▶ Se cumplen los requisitos funcionales.
▶ Se cumplen los requisitos de rendimiento.
167
▶ Se comprueba que la documentación es correcta y entendible.
▶ Las pruebas de

aceptación de
usuario se realizan
en la etapa final
del proceso de
desarrollo del
software.
13. Versiones alfa y beta

En las pruebas de aceptación se pueden ejecutar dos técnicas: pruebas alfa y pruebas beta.
Pruebas alfa
Las pruebas alfa las lleva a cabo el cliente estando presente el desarrollador y en el sitio don-
de se ha desarrollado la aplicación.
Se intenta conseguir que el cliente use la aplicación como lo haría en su lugar de trabajo.
Se hace uso de un entorno controlado, buscando las mismas condiciones que hay en el lugar
de trabajo del cliente.
Cuando finalizan, se documenta el resultado.
Los beneficios de las pruebas alfa son los siguientes:
▶ Ofrecen una buena perspectiva del software inicial.
▶ Facilitan la simulación del comportamiento del usuario en tiempo real.

168
▶ Permiten detectar muchos errores graves y visuales.
Pruebas beta
Las pruebas beta las lleva a cabo el cliente, pero esta vez en su lugar de trabajo directamente y
sin la presencia del desarrollador.
Todos los problemas detectados serán registrados por el propio cliente, comunicando regular-
mente al desarrollador las posibles correcciones.
Gracias a esta prueba se puede evaluar el grado de calidad del software a través de su uso “en
vivo”.
Los beneficios de las pruebas beta son los siguientes:
▶ Permiten que el cliente valide el producto.
▶ Se mejora la calidad del software al incluir al cliente en las pruebas.
▶ Mejoran las relaciones con el cliente ya que se siente integrado en el proyecto.
Recuerda:
Las pruebas alfa permiten la simulación de un entorno en tiempo real antes de pasar el soft-
ware a las pruebas beta. Se modela así una versión de software estable,
para que en las pruebas beta se pueda involucrar el cliente y se sienta integrado
en el desarrollo y mejora del producto.
Webgrafía
https://netbeans.apache.org/kb/docs/java/quickstart-gui.html
https://docs.oracle.com/javase/tutorial/uiswing/components/toplevel.html
https://docs.oracle.com/javase/tutorial/uiswing/index.html
https://docs.microsoft.com/en-us/dotnet/desktop/winforms/interfaces-related-to-data-
binding?view=netframeworkdesktop-4.8
https://docs.oracle.com/javase/tutorial/uiswing/events/index.html
https://www.oracle.com/java/technologies/foundation-classes-faq.html
https://docs.oracle.com/javase/tutorial/uiswing/events/intro.html
http://msdn.microsoft.com/es-es/library/ms752059.aspx
https://apache.github.io/royale-docs/features/mxml
https://www.xul.fr/en-xml-svg.php
https://doc.qt.io/qtdesignstudio/index.html
https://docs.oracle.com/javase/tutorial/uiswing/events/intro.html
169
https://docs.oracle.com/javase/8/docs/api/java/io/Serializable.html
https://www.interaction-design.org/literature/topics/human-computer-interaction

http://uxpanol.com/experiencia-de-usuario/definicion-de-experiencia-de-usuario-ux-or-user-
experience/
https://docs.oracle.com/javase/tutorial/deployment/jar/signindex.html
https://help.ubuntu.com/community/AptURL
https://www.netinbag.com/es/internet/what-is-context-sensitive-help.html
https://docs.microsoft.com/en-us/previous-versions/windows/desktop/htmlhelp/microsoft-ht-
ml-help-downloads
https://getgreenshot.org/
https://www.uaeh.edu.mx/scige/boletin/prepa4/n1/e8.html
www.cursosccc.com

Tec Sup Desarrollo Aplicaciones Multiplataforma Desarrollo de Interfaces 08

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tec Sup Desarrollo Aplicaciones Multiplataforma Desarrollo de Interfaces 08

Cargado por

Copyright:

Formatos disponibles

Desarrollo de

Queda rigurosamente prohibida, sin autori-

TÉCNICO SUPERIOR EN DESARROLLO DE APLICACIONES MULTIPLATAFORMA 151

▶ Estudiar los diferentes tipos de pruebas que existen en el desarrollo de interfaces.

2.1. Objetivos de las pruebas

Las pruebas de software se deben entender como:

▶ Verificación. El producto es capaz de realizar la tarea para la que ha sido creado.

Una correcta estrategia de pruebas contribuye a los siguientes puntos:

▶ Crear aplicaciones y software de calidad.

▶ Mejorar la satisfacción del cliente.

▶ Disminuir posibles riesgos del negocio y facilitar su crecimiento.

2.3. Limitaciones en el proceso de

Para ello podemos seguir una serie de principios:

TÉCNICO SUPERIOR EN DESARROLLO DE APLICACIONES MULTIPLATAFORMA

▶ Tener buenos conocimientos técnicos no es garantía de éxito de un proyecto.

▶ Es muy conveniente seguir procedimientos y actividades estandarizadas que nos pue-

2.4. Estrategias de las pruebas

▶ ¿Cuántos niveles de pruebas habría que planificar?

▶ ¿Cuándo será conveniente poner fin a las pruebas?

▶ ¿Es conveniente automatizar las tareas?

El objetivo de la estrategia es concretar los tipos de pruebas a realizar, el calendario de ejecu-

Para ello, también deberemos conocer los siguientes aspectos:

▶ La complejidad de la aplicación y los módulos que la componen.

▶ Plataforma en la que va a poder funcionar la aplicación.

▶ Normativa legal correspondiente.

▶ Conocimientos y experiencia de los responsables quienes realizan las pruebas.

Estas pruebas pueden ser ascendentes o descendentes.

Pruebas de integración ascendentes

TÉCNICO SUPERIOR EN DESARROLLO DE APLICACIONES MULTIPLATAFORMA

3. Se prueba todo el conjunto de módulos.

Pruebas de integración descendentes

Las pruebas de integración descendentes comienzan por la aplicación general y va bajando

Para realizar estas pruebas se pueden seguir los siguientes pasos:

1. Se utiliza el módulo principal como control de la prueba, guardando respaldos de los

3. Cuando se integra un módulo es cuando se realizan las pruebas.

Las pruebas de configuración verifican la instalación de la aplicación en el entorno destino

El objetivo es forzar el fallo de la aplicación a la hora de cumplir con los requerimientos de

Si la recuperación es automática, se deben evaluar los siguientes elementos:

▶ La inicialización del sistema.

▶ Los mecanismos de recuperación.

Al agregar un nuevo componente o módulo se introducen nuevos cambios: nuevas rutas de

Se pueden hacer de manera manual o mediante herramientas automáticas.

En las pruebas de regresión existen tres clases de pruebas diferentes:

▶ Planificar una muestra de pruebas sobre todos los componentes de la aplicación.

▶ Planificar pruebas centradas solo en los componentes que se han modificado.

La Programación Extrema es una metodología de desarrollo de software que se centra en reali-

Puedes consultar más detalles sobre las pruebas realizadas

Dentro de las pruebas funcionales, encontramos tres tipos:

▶ Particiones equivalentes. Se selecciona como entradas un conjunto representativo de

En las pruebas funcionales intervienen principalmente cuatro fases:

TÉCNICO SUPERIOR EN DESARROLLO DE APLICACIONES MULTIPLATAFORMA

En las pruebas funcionales manuales interviene un usuario experimentado como testeador o

▶ Aumentar la cantidad de entradas para ver la respuesta de la aplicación.

▶ Ejecutar casos que requieran una memoria muy elevada.

▶ Buscar la máxima cantidad de datos residentes en disco.

▶ Hacer pruebas de sensibilidad para descubrir posibles combinaciones de datos que

Estas pruebas se usan para conocer:

▶ Los tiempos de respuesta.

▶ El espacio ocupado por los módulos en disco y en memoria.

▶ El flujo de datos que genera a través de un canal de comunicaciones, etc.

▶ Las pruebas de rendimiento

TÉCNICO SUPERIOR EN DESARROLLO DE APLICACIONES MULTIPLATAFORMA

▶ Tratar de conseguir las claves de acceso de cualquier forma.