Pruebas Del Software

Descargar como pdf o txt
Descargar como pdf o txt
Está en la página 1de 18

Objetivo de la Unidad:

Estudiar los diferentes tipos de pruebas de software, el


momento de su diseño y posterior aplicación dentro del
ciclo de vida de desarrollo de software.
Fase que le permite al analista detectar errores de
codificación, estructura lógica y funcionabilidad con la
ayuda del usuario y personal técnico externo al grupo que
participa en el desarrollo.

Las pruebas se deben realizar con malicia, es decir,


buscar que el sistema falle con el propósito de que el
sistema sea implantado cumpliendo el 100% de
operatividad.
Este autor establece que el analista debe utilizar
estrategias, tipos, métodos y clases de pruebas que le
faciliten su trabajo.

Estrategias: Existen dos estrategias que le permiten


detectar errores de codificación y funcionabilidad.

1. Estrategia Caja Negra: Con ayuda del usuario el analista


detecta errores de funcionabilidad sin importarle la
codificación del mismo.
2. Estrategia Caja de Cristal: El analista con el personal
técnico interno o externo al desarrollo detecta errores
de codificación sin importarle la funcionabilidad del
sistema.
Prueba Estática: Este tipo de prueba permite al analista
correr en frio el programa con la ayuda de herramientas
lógicas tales como: Diagramas de flujo, diagramas Hipo,
Hipo funcional.

Prueba Dinámica: Se utiliza ejecutándose el sistema,


normalmente una prueba dinámica conlleva a una prueba
estática siempre y cuando se detecten errores.
• De arriba a hacia abajo (descendente), se prueba el
sistema comenzando con el módulo principal hasta
llegar al módulo más sencillo, es decir, que de él no
depende nadie; por ejemplo:

Sistema de ventas - x

Agregar - x
Productos - x
Agregar Código: xxx
Consultar
Modificar
Nombre:
Eliminar Cantidad:
Facturar
Cerrar Precio:

Aplicaciones
• De abajo hacia arriba (ascendente), se prueba el sistema
comenzando por la aplicación mas sencilla hasta llegar al
módulo principal.

• Método Total: Se aplica utilizando los dos métodos


descritos anteriormente, es decir, se comienza por el
método descendente y luego el ascendente y viceversa.
• Prueba unitaria: Es aquella que le permite al analista
detectar errores de codificación y funcionabilidad de
forma independiente, es decir, módulos o cada una de las
aplicaciones que conforman el sistema sin importar la
relación que existe entre esos módulos o aplicaciones.

• Pruebas de integración: Le permite al analista detectar


errores de codificación y estructura lógica, así como
también de funcionabilidad. Con el propósito de
visualizar si los módulos se están relacionando entre si
con sus diferentes aplicaciones entre si o con otros
módulos. Por ejemplo: (El mcedula producto), cuando
agregamos un producto la relación sería la consulta.
Módulo a módulo, cuando agregamos un producto y
luego se va a reporte para generar el mismo.
• Prueba de sistema: Se detectan solamente errores de
codificación y compatibilidad entre los componentes. Por
ejemplo: Entre los componentes y el sistema (pantallas).
Control de asistencia por huellas dactilares.

• Pruebas funcionales: Le permiten al analista detectar


errores de operativilidad y seguridad. Por ejemplo:
Ingreso de claves de seguridad.

• Aceptación técnica: Le permite al analista detectar


errores de codificación, estructura lógica y funcionales
con la ayuda de personal técnico externo al grupo de
desarrollo.
• Aceptación funcional: Permite detectar errores
funcionales, con la ayuda de los usuarios finales.

• Pruebas de instalación: Permite detectar errores de


compatibilidad entre hardware y software y sobre todo
en el acontecimiento del espacio físico (puntos de redes).
1. Pruebas de programa con datos ficticios: Son las misma
clases de pruebas unitarias de Fábregas pero se utilizan
datos ficticios.

2. Prueba de enlace con datos de pruebas: Es la misma clase de


prueba de integración de Fábregas pero se utilizan datos
ficticios. A su vez se usan errores de enlace de
comunicaciones. Por ejemplo: Servidor a servidor.

3. Prueba completa de sistema con datos: Prueba también


conocida como pruebas ALFA, donde se escoge un grupo
pequeño de usuarios para que prueben el sistema con datos
ficticios.
4. Pruebas completas de sistema con datos reales: También
conocidas como pruebas BETA, se toma la totalidad de
usuarios para que utilicen el sistema bajo periodo de prueba
con datos reales con el propósito de detectar errores de
seguridad y de ejecución del sistema. Po ejemplo: La versión
de Windows en estado BETA.
I parte:

1. Niveles de seguridad: Le permite al analista validar, verificar


y certificar todas las aplicaciones y módulos del sistema con
la ayuda del usuario y grupo de desarrollo.
2. Verificación: Este tipo de prueba se detectan errores de
estructura lógicas y aritméticas. Por ejemplo: El ingreso de
la clave, solicitud de cantidades, ingreso de códigos de
productos, entre otros.
3. Validación: Valida las entradas y salidas de los datos del
sistema. Por ejemplo: Bloqueo de la tarjeta luego de 3
intentos.
4. Certificación: Es realizado por el usuario quien establece si
cumple o no con sus necesidades.
II parte:

1. Estrategias de pruebas: Se dividen en dos tipos:


• De codificación: Es la misma estrategia de la caja de cristal.
• De especificación: Es la misma estrategia de la caja negra.

III Parte: Niveles de pruebas

1. Pruebas parciales: Son los métodos ascendentes y


descendentes.
2. Pruebas de sistema: Este tipo de prueba se realiza con la ayuda
de simuladores, ya que el sistema se prueba de la siguiente
manera y a través de las siguientes pruebas al sistema:
a. Pruebas de carga máxima: Consiste en que el sistema funcione
al 100%, es decir, se ejecuten diferentes procesos al mismo
tiempo con el fin de determinar si el sistema es capaz de
soportar situaciones extremas. Por ejemplo: De varios
terminales al mismo tiempo.
b. Pruebas de ejecución: Permiten detectar los tiempos de cada
una de las ejecuciones con el propósito de establecer si el
sistema es eficaz.
c. Pruebas de almacenamiento: Con ayuda de un simulador se
determina si la capacidad de almacenamiento fue la
establecida.
d. Prueba de factores humanos: Con este tipo de pruebas se
detecta los posibles errores que pueden cometer los usuarios al
momento de ingresar o ejecutar alguna aplicación.
e. Pruebas de documentación: Con este tipo de pruebas se
determina si el nivel de ayuda ofrecida por los manuales de
usuario y el módulo de ayuda ubicado en la pagina principal
satisface o no a los usuarios.
f. Pruebas de recuperación: Estos tipos de pruebas permiten
determinar si el sistema es capaz de recuperar información por
fallos eléctricos o fallas humanas.
Pruebas de entorno especializados, arquitectura y aplicación.

• Interfaz gráfica: Este tipo de pruebas detecta errores


relacionado con el diseño de pantallas que utiliza el usuario
para interactuar con el sistema, razón por la cual dentro del
grupo de desarrollo se encuentra el diseñador grafico quien se
encarga de esta tarea.
• Cliente-Servidor: Detecta errores de conexión entre cliente y
diferentes servidores con el propósito de establecer si la
conexión es correcta.
• Prueba de documentación y ayuda: Se utiliza para detectar
errores con la ayuda de los usuarios quienes sin los manuales y
el módulo de ayuda cumplen con las necesidades y sobre todo
orientan al manejo del sistema.
• Prueba de sistema de tiempo real: Se utiliza para detectar
errores de ejecución y sobre todo del tiempo de respuesta de
cada una de las actividades o aplicaciones ejecutada en el
mismo. Se divide en:

 Tarea: También conocida como prueba de aplicación la cual se


realiza para detectar errores en cada una de las tarea que
efectuara el usuario. Por ejemplo: Módulo producto  agregar,
consultar, eliminar, entre otros.
 Prueba de comportamiento: Aquella que permite determinar si
la aplicación o módulo se ejecuta según la analizada y diseñada.
Por ejemplo: Generar reportes diarios o semanales.
 Pruebas de intertarea: Se utiliza para detectar errores dentro de
aplicaciones, como por ejemplo: Consultas- se puede realizar
por código o por nombre.
. CONTROL DE CALIDAD DE SOFTWARE. (SQA)

Objetivo de la Unidad: Identificar las diferentes características que pueden


ser evaluadas en un producto de software

• ¿Qué es calidad?
• Algunos conceptos sobre calidad.
• ¿Cómo se controla la calidad del software?
• Aseguramiento de la calidad del software.
• Algunas operaciones SQA.
• Confiabilidad del software.
• Seguridad del software.
• El plan de SQA.
• El modelo de capacidad de Madurez (CMM)

También podría gustarte