Pruebas de sistemas

Daniel Esparza

Taller de integración de software

Instituto IACC

28/09/2019
 Desarrollo

Pruebas funcionales y no funcionales

Agenda de pruebas
1. Generalidades de la fase de ejecución de pruebas
2. Definición de iteración
3. Preparación del ambiente de pruebas
4. Ejecución de pruebas por iteración
5. Reporte de hallazgo
6. Retroalimentación
7. Actividad practica
Generalidades de la fase de ejecución de pruebas
Preparación del ambiente
 Definición de ambiente controlado pruebas funcionales fichas técnicas
 Definición de ambiente para pruebas no funcionales fichas técnicas
Iteraciones de pruebas
 Ejecución de requerimientos de prueba
 Ejecución de scripts para pruebas
 Registro de hallazgos NC
 Reproceso de NC
 Análisis de resultados de prueba
Seguimiento/control/retroalimentación
 Calculo de indicadores de producto
 Informe avance proceso pruebas
 Informe cierre pruebas funcionales
 Informe cierre pruebas no funcionales
Propósito
Ejecución de pruebas mediante la definición de las actividades requeridas para la ejecutar los
requerimientos de pruebas identificando en la fase del diseño de pruebas

 La fase de ejecución de pruebas se realiza por iteración de pruebas. (total o un

subconjunto de los requerimientos de pruebas)
Reportar los hallazgos y asegurar su corrección por parte del equipo de desarrollo de software

 En cada iteración de pruebas se registra los hallazgos o no conformidades NC de

software

Alcance
 Nuevos usuarios
 Mantenimiento: Actualización de funcionalidades a usuarios
 Pruebas funcionales Aplica para los diferentes tipos de pruebas dinámicas de
software
 Pruebas No-funcionales:
Pruebas de rendimientos
Pruebas de seguridad
Pruebas de compatibilidad
Pruebas de Usabilidad o Facilidad de uso

Responsabilidades en ejecución
Cliente prueba
 Brindar un ambiente de prueba controlado
 Gestionar las mejoras de proceso identificadas por el equipo de pruebas
 Apoyar el cumplimiento de los acuerdos de nivel de servicio previamente
establecido
 Apoyar la gestión de datos de producción para la ejecución de pruebas
Gerente de pruebas de software

 Comunicar a los gerentes de proyecto los cambios metodológicos vigentes en el

proceso de pruebas

 Gestionar los recursos necesarios para la ejecución de pruebas

 Definir y hacer cumplir los acuerdos de nivel de servicio

 Realizar seguimiento con al plan del proyecto

Líder de prueba de software

 Velar por un ambiente de pruebas controlado

 La gestión de las actividades definidas en los procedimientos de ejecución de

pruebas

 Presentación a la gerencia de pruebas de informes parciales que permiten verificar

el seguimiento del proceso

 Analizar información de causa de no conformidades y realizar informes

Preparación ambiente de pruebas

 Utilizando ficha técnica FT de producto:

 Especificación de la configuración de máquinas (clientes servidor) en que se

ejecutaran las pruebas; el sistema operativo Windows

 Especificación de software de sistema y de apoyo a la prueba motor base de datos

y máquinas virtuales servidor web, simuladores

 Harware necesario para las pruebas: Windows 10, 8 gb de ram, 1 tera disco duro .

Ingreso de información sistema.

Descripción del caso: el sistema enviara una notificación de creación exitosa al
administrador para obtener un control cuando se registre
alguna de las siguientes transacciones: creación local, creación usuaria, eliminación de
usuario
Técnica de pruebas de caja negra: requerimiento funcional / caso de uso

Caso 1.1: datos de entrada: registrar local. Resultado esperado (salida):

el sistema envía un correo electrónico al cliente como constancia de la creación exitosa.
Caso 1.2: datos de entrada: registrar usuario. Resultado
esperado (salida): el sistema envía un correo electrónico al cliente como constancia
de que se ha registrado usuario de forma exitosa

Caso 1.2: datos de entrada: se selecciona usuario y se presiona eliminar. Resultado

esperado (salida): el sistema envía un correo electrónico al cliente como constancia
de que se ha eliminado usuario de forma exitosa

RQF 1 Autenticación al sistema mediante la identificación de usuario y contraseña.

Entrada: nombre de usuario – contraseña

Procesos: Verificación de la existencia del usuario y su correspondiente contraseña en la

base de datos.

Salidas: Acceso al sistema.

RQF 2 Mantención tablas del sistema: Esta funcionalidad les permite a los actores

internos del sistema, realizar acciones de creación y modificación de datos paramétricos

del sistema.

Entrada: -Acción a realizar “Creación o modificación” -Información del parámetro a

crear o modificar

Proceso: Si es creación, se debe validar que el parámetro exista. Si no existe, crear el

parámetro; si existe, informar esta situación al usuario

Si es modificación, validar que el parámetro exista. Si existe, realizar la modificación; si

no existe informar esta situación al usuario.

 Salidas: El parámetro modificado.

RQF 3 Creación lista locales

Entrada: número de local -jefe de local -números de empleados -dirección -telefono-

observaciones

Proceso: Validación de tipos de carácter, dimensiones y datos requeridos

Salidas: Se agrego un local correctamente

Pruebas de comunicaciones.

Después de que los sistemas han sido verificados, probados e implantados, se les debe seguir dando
mantenimiento. Las rutinas de mantenimiento variarán de acuerdo con el tipo y complejidad de la
tecnología en este caso el mantenimiento es básico ya que el aplicativo lo es.

A los sistemas se les debe dar mantenimiento para asegurar que cont inúen operando en el nivel
mostrado durante la etapa de prueba El monitoreo permanente de los sistemas necesita ser
sistematizado para asegurar que las necesidades de mantenimiento sean identificadas y satisfechas
cuando resulte necesario. Cuando los sistemas son de uso prolongado, se puede establecer un
mecanismo para recibir retroalimentación de los usuarios como otra forma de determinar las
necesidades de mantenimiento y modificación.
Cuando se realicen modificaciones a las comunicaciones como resultado de programas de
mantenimiento o actualización, puede ser necesario promover rondas adicionales de verificación y
prueba del sistema para asegurarse que sigue cumpliendo las normas exigidas.

Pruebas de sobrecarga.

Probaremos como funciona el webservice que tiene la aplicación con una prueba de estrés básica.

Prueba de carga webservice

SoapUI te permite crear fácilmente las pruebas de carga (o pruebas de Estrés), para ello, se
utilizan los mismos parámetros de las pruebas funcionales, simplemente seleccionándola y
presionando para generar a partir de ella la prueba de carga.

De esta forma se pueden crear rápidamente las pruebas de carga, las cuales te permiten evaluar el
desempeño de la aplicación rápidamente al comienzo del proceso de desarrollo.

1.- Ve al TestSuite Sample expanded TestSuite y a los casos de prueba de Search y Buy.

Puedes ver 4 tipos de pruebas de carga en ese caso de prueba, uno para acada estrategia de
LoadTest.

Por ahora, seleccionamos el LoadTest: Simple Strategy LoadTest. Este LoadTest está basado en
una estrategia de carga que llamaremos Simple Strategy, la cual es una estrategia básica para un
simple retraso aleatorio (random delay).

Procedemos a configurar la prueba.

Primero se configura el limite de la estrategia de pruebas (Limit). Esto es, el número de segundos
que la prueba estará en ejecución.
Luego se configuran el número de hilos (Threads) de la estrategia. Por ahora, se configura uno
solo.
Tercero, se configura el retraso (Test Delay), que establece el número de milisegundos para el
retraso base.
Cuarto, se configura una variable aleatoria (Random), que establece un intervalo de probabilidad
para el retraso entre pruebas. 0,5 indica que el tiempo entre pruebas estará entre 100 y 300
milisegundos. Un random de 0 indica variación 0 entre pruebas, es decir el retraso será siempre
de 200 milisegundos.

3.- Procedemos a ejecutar la prueba.

4.- Como puedes ver, los números de la prueba se actualizan constantemente. Puedes ver números
para los tiempos de respuesta, aserciones, errores, porcentaje de las pruebas ejecutadas y más.

Puedes presionar el botón de gráfico.

 El MockService en el proyecto de ejemplo tiene un error que fue colocado
intencionalmente.

 Revisa TestSuite Sample TestSuite fails if we don't get faults y TestCase TestCase:
Searching después de Logging out LoadTests. Allí encontraras una prueba de carga
llamada LoadTest with Multiple Tests, la cual fallará si es ejecutada.
 Abrela y ejecutala, transcurrido un tiempo, esta prueba presentará un fallo.
Pruebas de seguridad

Se realizan para disminuir el riesgo de sufrir un ataque de usuario malintencionados.

Generalmente este tipo de pruebas son ejecutadas por compañías especializadas que
cuentan con herramientas y listas de vulnerabilidades.
El sistema cuenta con seguridad de acceso una página login,
Ingresamos un usuario existente, pero con una password errónea podemos apreciar el
error que lanza la aplicación en color rojo.

Se válida la password con la base de datos y los registros.

También se menciona cuando se registra un usuario se ingresa la información encriptada

lo cual es una forma muy segura de evitar intrusos a la base de datos es una buena
práctica y una forma segura de almacenar la información.
Pruebas de facilidad de uso.

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

Se comprobó que el usuario tiende a realizar muchos errores en el registro del sistema

anterior por lo cual se llevó a crear un formulario con errores en el caso que el usuario

ingrese un local proceda a leer el error y ingresar nuevamente los datos, lo dial al realizar

un sistema es siempre pensar que el usuario no entiende nada y hacer un sistema bien

intuitivo y con muchas alertas en lo personal te soluciona muchos problemas de usuario.

Pruebas de disponibilidad de datos.

Las pruebas de disponibilidad de datos fueron exitosas

Realizaremos pruebas de respaldo en la base de datos creada en mysql.

Backup Lógico

 Se utiliza la herramienta mysqldump para realizar el backup

 Se puede realizar el backup con el servidor online
 Permite "transportar" bases de datos entre servidores
 Permite hacer restauraciones parciales (p.ej.: recuperar una tabla)
 Más costoso (en tiempo y espacio) que backup físico
 Puede configurarse restauración "en tiempo" utilizando logs

Backup Físico

 No se necesitan herramientas para el backup ya que se copian los ficheros

del filesystem
 Es preferible detener el servidor de Bases de Datos
 Mas fácil para recuperar Bases de Datos complejas
 Menos costoso que backup lógico
 No se permite restaurar "en tiempo"

Realizar backup logico

Para realizar un backup lógico usaremos la herramienta mysqldump de la

siguiente forma:
  @localhost:~$ mysqldump -u[root] -p[qwerty21] [db-bgc] > [fichero_fackup].
sql

Para restaurar el backup lógico y obtener el tiempo para las pruebas de

importación, se han realizado los siguientes pasos: Reiniciar servidor MySQL y

luego importar el backup sql de la siguiente forma:

localhost:~$ time mysql -uroot -proot workbench [fichero_backup].sql

mysql: [Warning] Using a password on the command line interface can be insecur
e.

real 1m2.907s
user 0m4.004s
sys 0m0.216s

Realizar backup físico

Para el backup físico de la base de datos, se ha copiado el directorio correspondiente a

dicha base de datos usando el siguiente comando y se ha obtenido su tiempo:

localhost:~$ time cp -R /var/lib/mysql/benchmark/ /tmp/backup1

Para restaurar el backup físico, se hace el paso inverso al apartado 5 (debemos tener en

cuenta que la base de datos debe existir para que funcionen las consultas correctamente).

El propietario y grupo de los ficheros los cambiamos a propietario=mysql y grupo=mysql

localhost:~$ time cp -R /tmp/backup1/* /var/lib/mysql/benchmark/ && chmod -R mysql.

mysql /var/lib/mysql/benchmark/

Respaldo diagrama de modelo.

Ejemplo de métodos de respaldo y configuraciones adicionales

Espejo (Mirroring): este método implica realizar una copia completa, en un momento

específico, de todos los archivos y bases de datos seleccionados hacia una nueva

ubicación. Es la forma más rápida y sencilla de respaldar la información, ya que no se

requiere de ningún proceso o algoritmo de comprensión de los datos. No obstante, la gran

velocidad de ejecución del espejo o mirror conlleva a la necesidad de utilizar un gran

espacio de almacenamiento. Además, la seguridad del respaldo se ve comprometida ya

que no es posible implementar claves o passwords para limitar el acceso a los datos

respaldados.

Comandos para respaldo: el uso de comandos o instrucciones específicas para el respaldo

de los datos está ligado directamente con el sistema operativo bajo el cual el DBMS fue

instalado. Sin embargo, dada la importancia de los respaldos, la complejidad de los

 comandos y la posibilidad de error humano, en la actualidad se han desarrollado

múltiples programas utilitarios para llevar a cabo este proceso

Pruebas de operación.

Una vez realizada la prueba de operación se pudo contemplar que los procedimientos de operación,

Incluyendo el control arranque y rearranque del sistema se cumplieron de forma exitosa.

Pruebas de entorno.

Realizando las pruebas de interno se puede validar que el sistema no contempla conectividad con
otras aplicativos, solamente se comunica por medio de internet con enlaces directos para otros
sistemas

Bibliografía
Elaboración propia