AP9-AA1-EV2-INFORME DE INCIDENTES Y PROPUESTAS DE MEJORA.

Por:

JOSE EDWIN GAMBOA GALINDO

DUVÁN DE JESÚS BENAVIDES ARCHILA

CONSTANZA MILENA JAIMES SUÁREZ

EBED ADÁN MARTÍNEZ FÁBREGAS

SENA

Análisis Y Desarrollo De Sistemas De Información

01 de abril de 2019
 Tabla de Contenido

Tabla de Contenido ..................................................................................................................... 2

INTRODUCCIÓN....................................................................................................................... 3
OBJETIVOS ................................................................................................................................ 4
1 EVALUACION DE LA PRUEBA ..................................................................................... 5
2 MEJORA (PRUEBAS SOFTWARE PENDIENTE PARA REALIZAR). .................... 5
BIBLIOGRAFIA ................................................................................................................. 9
 INTRODUCCIÓN

Se han desarrollado las Pruebas Software Funcionales para verificar que funcione como
el sistema al que sustituye”). Es decir, con las funciones establecemos “lo que el sistema
hace”. A través de estas se ha comprobado que se cumple con el objetivo que es cumplir
con las especificaciones de funcionamiento de sus requerimientos.

Sin embargo, hay que desarrollar otras pruebas que son necesarias para el correcto
funcionamiento del software las cuales se expondrán a continuación.
 OBJETIVOS

El plan de prueba describe el ámbito del esfuerzo de prueba general y proporciona un registro
del proceso de planificación de prueba. Puede configurarse el plan de pruebas para que se
ajuste a las necesidades del equipo. Normalmente, un plan de pruebas identifica los requisitos,
riesgos, casos de prueba y entornos de prueba que hay que probar, los objetivos de negocio y
calidad, las planificaciones de prueba y otros elementos.

Crear un plan de pruebas duplicando otro plan de pruebas.

Crear una instantánea del plan de prueba y utilizarla como la base para un nuevo plan de
prueba.
 AP9-AA1-EV2-INFORME DE INCIDENTES Y PROPUESTAS DE MEJORA.

1 EVALUACION DE LA PRUEBA

Al verificar el resultado de las acciones se evidencia éxito, y al realizar las pruebas

específicas, concretas y exhaustivas para probar y validar que el software hace lo que
debe y sobre todo, lo que se ha especificado.
El objetivo fue diseñar las pruebas para que tengan la mayor probabilidad de encontrar
defectos con la mínima cantidad de esfuerzo y tiempo. Fueron pruebas que se llevo a
cabo a través de la interfaz gráfica del software (GUI). Es decir, se demostro que las
funciones del software son operativas, que la entrada se acepta de forma adecuada y que
se produce una salida correcta, así como que la integridad de la información externa se
mantiene. Se creo casos de prueba divididos en pasos (steps) para cada acción a realizar
con un resultado esperado asociado, que podrá ser verificado. Durante la fase de diseño
también se especifican los datos de entrada necesarios para que los casos de pruebas
definidos puedan ser ejecutados (ya sea buscando el éxito de la prueba, o bien el fallo),
en este caso fueron exitosos.
Dado lo anterior se establece realizar pruebas como acción de mejora, para evaluar la
forma en que el sistema funciona, y poder corregir futuros problemas.

2 MEJORA (PRUEBAS SOFTWARE PENDIENTE PARA REALIZAR).

Las pruebas no funcionales se enfocan en validar un sistema o aplicación por medio de

sus requerimientos no funcionales, es decir, la forma en que el sistema funciona y no por
medio de comportamientos específicos al cual se someterá el software SIUGET.

Entre estas pruebas están:

Pruebas de carga

Las pruebas de carga consisten en simular demanda sobre una aplicación de software y
medir el resultado. Estas pruebas se realizan bajo demanda esperada y también en
condiciones de sobrecarga (picos en la demanda).

Las pruebas de carga ayudan a identificar la máxima capacidad operativa de una

aplicación, así como en el identificar cuellos de botella y las causas de posible
degradación del desempeño.

Cuando la carga de prueba se eleva por encima de los parámetros esperados, a estas
pruebas se les conoce como pruebas de estrés.

Pruebas de estrés
Son pruebas de carga que se realizan con demandas mayores a la capacidad operativa,
con frecuencia hasta llegar al punto de ruptura.

Este tipo de prueba de software se utiliza para determinar la estabilidad de un sistema o

aplicación, con especial atención en la disponibilidad y manejo de errores cuando se
enfrenta a la sobrecarga.

Pruebas de volumen

Las pruebas de volumen consisten en validar el funcionamiento de la aplicación con

ciertos volúmenes de datos. El sujeto de pruebas no está limitado a bases de datos,
también se puede usar por ejemplo para medir el desempeño de una interfaz cuando el
archivo de interfaz (un archivo de texto, XML, etc.) supera cierto tamaño.

El objetivo es ver si dado ciertos volúmenes de datos la aplicación funciona con

normalidad, cuáles son los límites máximos de volúmenes de datos para la operación e
identificar condiciones de falla.

Pruebas de configuración

En lugar de probar el desempeño de una aplicación desde la perspectiva de la carga, las

pruebas de configuración se usan para validar que efectos en el desempeño tienen ciertos
cambios en la configuración.

Un ejemplo típico de esta situación es experimentar con diferentes métodos de balanceo

de cargas y ver la respuesta de la aplicación a niveles similares de sobrecarga.

Otro ejemplo es verificar si el sistema es capaz de funcionar adecuadamente en diferentes

versiones o configuraciones de entornos de hardware y software, como pueden ser
diversos navegadores de internet, versiones de navegadores, entre otros.

Pruebas de usabilidad

En las pruebas de usabilidad, los testers de software se enfocan en validar que tan fácil de
usar es una determinada aplicación.

Las características evaluadas en la usabilidad incluyen:

Facilidad de aprendizaje: Que tan fácil es para los usuarios realizar funciones básicas
la primera vez que utilizan la aplicación.

Eficiencia: Que tan rápido los usuarios experimentados pueden realizar sus tareas.

Memorización: Que tan fácil de memorizar es el uso de la aplicación, esto es, cuando
un usuario pasa mucho tiempo sin usar la aplicación, puede recordar lo suficiente para
usarla con efectividad la próxima vez, o tiene que empezar a aprender de nuevo.

Errores: Cuantos errores atribuibles al diseño comete el usuario, que tan severos son y
que tan fácil es recuperarse de los mismos.
 Satisfacción: Que tanto le gusta (o desagrada) al usuario utilizar el sistema.

Pruebas de seguridad

Consiste en probar los atributos o características de seguridad del sistema, si es un sistema

seguro o no, si puede ser vulnerado, si existe control de acceso por medio de cuentas de
usuario, si pueden ser vulnerados estos accesos.

Las pruebas de seguridad también sirven para validar si el equipo de desarrollo de

software ha seguido prácticas de seguridad recomendadas en su programación.

Entre las características de seguridad de un sistema, están la confidencialidad, integridad,

autenticación, autorización y la disponibilidad.

Pruebas de resistencia

Las pruebas de resistencia implican someter a un Sistema o aplicación a una carga

determinada durante un período de tiempo, para determinar cómo se comporta luego de
un uso prolongado.

Un sistema informático puede comportarse de forma normal durante las primeras horas,
sin embargo, luego de cierto tiempo, problemas como fugas de memoria suelen ocasionar
fallas.

Pruebas de escalabilidad

Las pruebas de escalabilidad consisten en verificar la capacidad de una aplicación de

escalar cualquiera de sus características no funcionales, como por ejemplo la carga que
soporta, número de transacciones, volúmenes de datos, entre otros. Probar en bloques
incrementales significa por ejemplo primero probar con niveles de demanda bajos, luego
incrementar a niveles de demanda medios y finalmente probar con altos niveles de carga.
De esta manera se puede determinar que también escala la aplicación y los problemas que
comienzan a surgir en distintos niveles.

Para que los resultados sean confiables, los ambientes de prueba y su configuración deben
mantenerse constantes.

Pruebas de recuperación

Las pruebas de recuperación se realizan para verificar que tan rápido y que tan bien se
recupera una aplicación luego de experimentar un falló de hardware o software.

Por lo tanto, para realizar pruebas de recuperación se requiere forzar la falla y luego
verificar si la recuperación ocurre adecuadamente.
Por ejemplo, cuando una aplicación esté funcionando desconectar el cable de red, o en
una aplicación móvil interrumpir la conexión con la red Wi-Fi o con la operadora, para
luego restablecer la conexión.

Pruebas de mantenibilidad

Básicamente consisten en evaluar que tan fácil es realizar el mantenimiento de un sistema

o aplicación. Esto significa que tan fácil es analizar, cambiar y probar estos cambios.

Para realizar esta prueba deben evaluarse la forma en que está implementada la
aplicación, siguiendo buenas prácticas de ingeniería de software. Es decir, que se estén
siguiendo los patrones recomendados de ingeniería de software y que no se estén
introduciendo inadvertidamente anti-patrones, esto es, que no se estén cometiendo errores
comunes de programación.
 BIBLIOGRAFIA

Pmoinformatica.Tipos de pruebas no funcionales Tomado de internet el 01/04/2019 de:

http://www.pmoinformatica.com/2016/07/tipos-pruebas-no-funcionales.html