Vous êtes sur la page 1sur 14

Diseño, desarrollo e implementación de un sistema de información para la

recolección y unificación de datos de docentes y estudiantes en la Institución


Educativa Simón Bolívar del departamento del Valle del Cauca

AP9-AA1-Ev2-Ejecución de pruebas sobre el proyecto formativo

Aprendiz: Ronald Samuel Pérez Calderón

Servicio Nacional de Aprendizaje SENA

Análisis y Desarrollo de Sistemas de Información

Octubre 2018
PLAN DE PRUEBAS

Departamento/Proyecto/ Subtítulo

Departamento/Proyecto/ Subtítulo 2 Octubre 2018


HISTÓRICO DE CAMBIOS

Fecha Versión Descripción Autor


Octubre 2018 0.9 Ronald Samuel Pérez
Creación del documento
Calderón

Departamento/Proyecto/ Subtítulo 3
Índice
1.1. Objetivos y tareas 4
1.1.1. Objetivos 4
1.1.2. Tareas 4
1.2. Audiencia prevista 4
1.3. Referencias 4
2.1. Ítems a probar (funciones) 5
2.2. Cuestiones de riesgo 5
2.3. Características a probar 5
2.4. Características que no se van a probar 5
2.5. Enfoque (estrategia) 5
3.1. Criterios de entrada 6
3.2. Criterios de salida 6
3.3. Criterios de suspensión 6
3.4. Criterios de reanudación 6
3.5. Criterios de éxito y fallo 6
5.1. Planificación 8
5.2. Recursos 8
5.2.1. Hardware 8
5.2.2. Software 8
5.2.2.1. Herramientas 8
5.2.3. Dotación de personal 8
5.2.3.1. Responsabilidades 8
5.2.3.2. Formación 8

Departamento/Proyecto/ Subtítulo 4
1. INTRODUCCIÓN

El principal propósito de la evaluación es encontrar errores y defectos que puedan existir en


el uso del sistema a fin de corregirlos. Verificar que los validadores de datos funcionen y
limiten el ingreso de información, para que no se puedan ingresar datos que no estén
permitidos (sólo números en campos numéricos, por ejemplo). Se quiere comprobar además
que el sistema cumple con los requerimientos establecidos por el usuario, tiene un
rendimiento adecuado en el ambiente donde se encuentra instalado. Otro aspecto
importante a evaluar son las características de seguridad relacionadas con el ingreso no
autorizado de usuarios, de manera que no puedan realizar modificaciones donde no sean
permitidas

1.1. OBJETIVOS Y TAREAS

1.1.1. Objetivos
El propósito del plan de pruebas es proveer la información necesaria para planear y
controlar los esfuerzos de pruebas de un proyecto o iteración específicos. Describe el
enfoque para probar el software y es el plan general generado y utilizado por
administradores para dirigir el esfuerzo de pruebas.

1.1.2. Tareas
 Set de pruebas documentado incluyendo escenarios claros para el desarrollo de las
pruebas unitarias.
 Toda la documentación requerida debe estar disponible.

 Supervisar si se cumple las especificaciones de diseño establecidas por el cliente.


 Supervisar si se cumple los requisitos del análisis que se hicieron en la planificación
del diseño y desarrollo del software.

 Realizar las pruebas necesarias de rendimiento y capacidad del sistema.


 Encontrar los problemas importantes y determinar los riesgos percibidos en cuanto a
la calidad del producto.

1.2. AUDIENCIA PREVISTA


Por retiros de integrantes del grupo la audiencia se realizará por el Jefe de proyecto el cual
realizará todos los pasos de la prueba del software.

Departamento/Proyecto/ Subtítulo 5
1.3. REFERENCIAS
Lista todos los documentos que se han utilizado para crear este plan, los que se usarán en
el desarrollo de casos de pruebas o durante la ejecución de pruebas. Estos se pueden listar
en una tabla como la siguiente:

Documento Autor Versión Localización

Plantilla stakeholders Samuel Pérez 1.9 Sena2017/actividades

Plantilla caso de Samuel Pérez 1.9 Sena2018/actividades


prueba

Departamento/Proyecto/ Subtítulo 6
2. ALCANCE Y ENFOQUE

2.1. ÍTEMS A PROBAR (FUNCIONES)


La prueba de esfuerzo en un tipo de prueba de performance implementada y ejecutada para
encontrar errores cuando hay pocos recursos o cuando hay competencia por recursos. Poca
memoria o poco espacio de disco pueden revelar fallas en el software que no aparecen bajo
condiciones normales de cantidad de recursos. Otras fallas pueden resultar al competir por
recursos compartidos como bloqueos de bases de datos o ancho de banda de red. La
prueba de esfuerzo también puede usarse para identificar el trabajo máximo que el software
puede manejar.
• Poca memoria o sin disponibilidad de memoria en el servidor
• Cantidad máxima de usuarios conectados
• Múltiples usuarios realizando la misma operación sobre los mismos datos
• Peor caso de volumen de operaciones.

2.2. CUESTIONES DE RIESGO


 Cliente escéptico
 Cliente insatisfecho por mala asesoría
 Altas Competencias
 Falta de Motivación al Cliente

2.3. CARACTERÍSTICAS A PROBAR


Las pruebas se realizarán con la siguiente criticidad en una escala de Alto, Media, bajo (A,
M, B).
 Pruebas de mantenibilidad……………………(A)
 Pruebas de fiabilidad ……………………. (B)
 Pruebas de escalabilidad ……………………(M)
 Pruebas de seguridad ……………………. (A)
 Pruebas de agilidad ……………………(B)

Departamento/Proyecto/ Subtítulo 7
2.4. CARACTERÍSTICAS QUE NO SE VAN A PROBAR

Las vías que pueden dificultar la determinación de los requisitos son:

● Los usuarios no se involucran en la elaboración de requisitos escritos


● Los usuarios insisten en nuevos requisitos después de que el coste y la
programación se hayan fijado.
● La comunicación con los usuarios es lenta
● Los usuarios no participan en revisiones o son incapaces de hacerlo.
● Los usuarios no tienen claro lo que desean los usuarios no comprenden los
problemas técnicos
● Los usuarios no entienden el proceso del desarrollo

Esto puede conducir a la situación donde las exigencias del consumidor cambian,
incluso cuando el desarrollo del producto ya está en marcha.

2.5. ENFOQUE (ESTRATEGIA)


Descripción de la estrategia de pruebas general para este plan de pruebas. Se han de
identificar las reglas y procesos asociados.

Departamento/Proyecto/ Subtítulo 8
3. CRITERIOS DE TRANSICIÓN

A continuación, se describen los criterios requeridos para las pruebas para poder pasar de
un estado a otro.

3.1. CRITERIOS DE ENTRADA


Lista todos los criterios que se han de satisfacer para empezar la ejecución de las pruebas.
Entre los posibles ítems que se pueden incluir están los siguientes:
- Casos de pruebas escritos y aprobados
 tipo de persona
 Entidad responsable
 Usuario
 Impresora Laser
 Hardware

3.2. CRITERIOS DE SALIDA


Lista todos los criterios que se han de satisfacer para que una fase de pruebas se de por
finalizada. Entre los posibles ítems que se pueden incluir están:
 mantenibilidad
 fiabilidad
 escalabilidad
 seguridad
 agilidad

3.3. CRITERIOS DE SUSPENSIÓN


Se aplicará este ítem si en los casos de prueba los elementos o puntos no cuentan con las
condiciones necesarias para llevar a cabo el proyecto tales como algoritmos mal definidos o
no funcionales, recopilación de elementos sin reconocimiento de autor y por incorporación
de elementos que no cuenten con pruebas que den fiabilidad de su uso en el aplicativo.

3.4. CRITERIOS DE REANUDACIÓN


La reanudación de las pruebas se hace después de que el código haya sido revisado y
mejorado, después de ello se puede pasar nuevamente al plan de prueba

Departamento/Proyecto/ Subtítulo 9
3.5. CRITERIOS DE ÉXITO Y FALLO
Especificación de los criterios que se han de usar para determinar si cada una de las
pruebas ha tenido éxito o ha fallado.
Si las pruebas cumplen con los siguientes puntos se dará por entendido que ha tenido éxito
la ejecución de procedimiento
 Que tenga mantenibilidad
 Que sea fiable
 Que tenga escalabilidad
 Que sea seguro
 Que sea ágil en su ejecución

Departamento/Proyecto/ Subtítulo 10
4. ESTRATEGIA DE PRUEBAS

- En este punto nos enfocaremos en realizar tres diferentes tipos de pruebas las
cuales son:

 Prueba Unitaria: Verificar la funcionalidad y estructura de cada


componente.
 Prueba de Implantación: Verificar el funcionamiento del programa y su
rendimiento con hardware, software y aceptación de usuario.
 prueba del sistema: Verificar el sistema completamente incluyendo todos
los subsistemas con sus respectivas interfaces y el correcto acople al
resto de los componentes.

Departamento/Proyecto/ Subtítulo 11
5. PLANIFICACIÓN Y RECURSOS

5.1. PLANIFICACIÓN
Esta sección debería incluir una lista de hitos clave en las pruebas. Puede incluir:
- Aprobación del plan de pruebas
- Desarrollos de la lisara de casos de pruebas
- Desarrollo de los casos de pruebas
- Desarrollo de scripts de pruebas
- Preparación del entorno de pruebas
- Fechas de ejecución de pruebas

5.2. RECURSOS

5.2.1. Hardware
Requisito mínimo de hardware:
 Espacio disponible en disco duro de 500GB
 Memoria RAM de 1T
 Procesador de 1,60 GHz en adelante

5.2.2. Software
 Sistema operativo de 32 o 64 bits.

5.2.3. Dotación de personal


 Impresoras
 Laptops
 Dispositivos móviles

5.2.3.1. Responsabilidades
Miembros del equipo de aseguramiento de la calidad y sus responsabilidades:
 Ronald Samuel Pérez Calderón - Análisis y soporte

Departamento/Proyecto/ Subtítulo 12
5.2.3.2. Formación
 Ronald Samuel Pérez Calderón - Desarrollador de software y Analista de
Calidad

Departamento/Proyecto/ Subtítulo 13
6. REVISIÓN DEL PLAN DE PRUEBAS

El Plan de Pruebas, contiene la definición de las metas y objetivos a probar dentro del
alcance de cada iteración del proyecto. Proporciona el marco de trabajo en el que el equipo
llevará a cabo la prueba dentro del horario coordinado.
 El Resumen de Resultados de Pruebas, organiza y presenta un análisis resumen de
los resultados de las pruebas y las medidas clave para revisar y definir estas,
típicamente por los Stakeholders claves. Además, puede contener una declaración
general de calidad relativa, puede mantener las recomendaciones de las pruebas
que se realizarán a futuro.
 La Lista de los Problemas, proporciona una manera de registrar para el
Administrador del Proyecto los: problemas, excepciones, anomalías, u otras tareas
incompletas que requieren atención que relaciona a la dirección del proyecto.
 Cambios de Requerimientos. Se proponen cambios a los artefactos de desarrollo a
través de Cambios de requerimientos (CR). Se usan los Cambios de Requerimientos
para documentar los problemas, las mejoras solicitadas y cualquier otro tipo de
solicitud para un
cambio en el producto. El beneficio de CR es que proporcionan un registro de
decisiones, debido a su proceso de valoración, asegura los impactos del cambio que
puedan
darse en el proyecto.

Departamento/Proyecto/ Subtítulo 14