Niveles de Pruebas de sistemas
Enviado por kessmeza • 25 de Noviembre de 2015 • Trabajos • 1.506 Palabras (7 Páginas) • 89 Visitas
NIVELES DE PRUEBA
Los sistemas no se diseñan como sistemas completos ni tampoco como sistemas únicos. El analista debe llevar a cabo tanto pruebas parciales como pruebas del sistema.
Los niveles de prueba son:
- Pruebas Parciales
- Pruebas de Sistemas
- Pruebas Especiales de Sistemas
1. Pruebas Parciales
- Se les conoce también como Pruebas Unitarias o de Unidad o Prueba de Programas.
- Las unidades de software en un sistema son los módulos y rutinas que se ensamblan e integran para llevar a cabo una función específica.
- Las pruebas parciales se centran primero en los módulos independientes entre sí, para localizar los errores. Esto permite al que realice las pruebas, detectar errores en el código y lógica contenidos dentro de ese único módulo.
- Aquellos errores que resultan de la interacción entre los módulos se evitan inicialmente.
- Los casos de prueba necesarios para las pruebas parciales deben probar cada condición u opción.
- Si el módulo recibe una entrada o genera una salida, también se necesitan casos de prueba para examinar el rango de valores esperado, incluyendo los datos válidos e inválidos.
2. Pruebas de Sistemas
- También son llamadas pruebas de Integración.
Martes 27/octubre/2015
- Estas pruebas no prueban el sw en sí, sino la integración de cada módulo en el sistema.
- También busca las discrepancias entre el sistema y su objetivo original, especificaciones y documentación del sistema.
- La preocupación principal es la compatibilidad de los módulos individuales.
- En las Pruebas de Sistemas también debe verificar que los tamaños de los archivos son adecuados.
- Se deben probar a niveles de sistema los procedimientos de ordenamiento que se supone, están presentes en los módulos de nivel interior, para ver que realmente existen y que logran los resultados que esperan los módulos.
3. Pruebas Especiales de Sistemas
Hay otras pruebas en una categoría especial ya que no se centra en el funcionamiento normal del sistema. Los tipos de Pruebas Especiales de Sistemas son:
- Prueba de Carga Máxima
- Prueba de Almacenamiento
- Prueba de Tiempo de Ejecución
- Prueba de Recuperación
- Prueba de Procedimientos
- Prueba de Factores Humanos
Prueba de Carga Máxima: Determina si el sistema manejará el volumen de actividades que ocurran cuando el sistema esté en el punto más alto de su demanda de procesamiento.
Por ejemplo: Todas las terminales se activan al mismo tiempo.
Prueba de Almacenamiento: Determina la capacidad del sistema para almacenar datos de transacciones en un disco u otros archivos. La capacidad se mide en términos de número de registros que un disco puede manejar o que un archivo puede mantener.
Por ejemplo: Verificar la documentación en el sentido de que el sistema almacenará 10,000 registros de 383 bytes de longitud en un único dispositivo de almacenamiento.
Prueba de Tiempo de Ejecución: Determina el tiempo de máquina que el sistema necesita para procesar los datos de una transacción Un error común que se comete en las pruebas parciales y de sistemas es que solo se prueba con un conjunto relativamente pequeño de datos para encontrar errores. Un sistema que corre bien con solo unas pocas transacciones puede ser inaceptablemente lento cuando esté cargado por completo.
Por ejemplo: Tiempo de respuesta a las consultas cuando el sistema está cargado en su totalidad con datos operativos.
Prueba de Recuperación: Determina la capacidad del usuario para recuperar los datos o restablecer el sistema después de una falla. Los analistas deben suponer siempre que el sistema fallará y que los datos se dañarán o perderán.
Por ejemplo: Cargar copias de respaldo de datos y reiniciar el procesamiento sin perder datos o integridad.
Prueba de Procedimientos: Determina la claridad de la documentación en los aspectos de operación y uso de un sistema, haciendo que los usuarios lleven a cabo exactamente lo que el manual pide. Este tipo de prueba no solo muestra los huecos que la documentación tiene en cuando a detalles sobre cómo funciona el sistema, sino en qué lugar la documentación está equivocada, es decir, donde las acciones realmente hay que llevar a cabo para hacer que el sistema funcione.
Por ejemplo: Apagar el sistema al final de la semana o responder al indicador luminoso de la impresora que señala la falta de papel.
Prueba de Factores Humanos: Determina como utilizarán los usuarios el sistema al procesar datos o prepara informes. ¿Qué hacen los usuarios si después de mandar una transacción por medio de una terminal, la pantalla se pone en blanco mientras los datos se procesan?
El analista debe observar cuidadosamente las transacciones del usuario cuando no hay respuesta inmediata a una consulta. Además debe asegurarse de observar como introducen los datos las personas.
¿Usan teclas diferentes a las anticipadas?
¿Hay combinaciones difíciles de teclear que puedan provocar errores?
¿Cómo se sentirá el usuario de un sistema después de trabajar con él durante mucho tiempo?
Pág. 1/N
EJEMPLO DE CASO DE PRUEBA:
“ckMarket”
Kessley Meza, Carlos Soto
Prueba de Caja Negra
Nombre del Módulo: Clientes
NUM.: | TIPO: prueba de caja negra | ||
DESCRIPCION: EL campo de nombre completo en su código permite un gran número de ingresos de caracteres | EVALUACION DE: código fuente | ||
IMAGEN: | |||
[pic 1] If DirectCast(sender, TextBox).Text.Length > 0 Then Me.erroricono.SetError(sender, "") Else Me.erroricono.SetError(sender, "Ingrese nombre cliente por favor, este campo es obligatorio") End If End Sub[pic 2] | |||
RUTA: | Login/Menu principal/clientes | ||
FECHA: | 12/11/2015 | SOLUCIONADO: | No |
SOLUCION: |
...