1. Las pruebas sirven para convencer a los desarrolladores del sistema y a los clientes que es lo suficientemente bueno para su uso operacional.
1.1. Pruebas basadas en requerimientos
1.1.1. Aproximación sistemática al diseño de los casos de uso
1.1.2. Son pruebas de validación y no de defectos
1.1.3. El usuario define cada requerimiento
1.1.3.1. Objetivo
1.1.3.1.1. El usuario intenta demostrar que el sistema ha implementado sus requerimientos de forma adecuada.
1.2. Pruebas de sistema
1.2.1. Se utiliza para probar la integración de dos o mas componentes
1.2.2. Se utiliza para sistemas complejos y se divide en:
1.2.2.1. Pruebas de Integración
1.2.2.1.1. El equipo de pruebas tienen acceso al código fuente
1.2.2.1.2. Se ocupan principalmente para encontrar defectos en el sistema
1.2.2.2. Pruebas de entregas
1.2.2.2.1. Se prueba la versión del sistema que podrá ser entregado a los usuarios
1.2.2.2.2. Valida satisfacción de requerimientos y confiabilidad
1.2.2.2.3. Tambien conocidas como pruebas de caja negra
1.2.3. Se obtiene información de los usuarios para tener una idea mas precisa de las funciones
1.3. Pruebas de rendimiento
1.3.1. Se diseñan para medir el soporte del sistema a la carga esperada.
1.3.2. Se incrementan una seria de pruebas de forma regular hasta lograr que el rendimiento del sistema se hace inaceptable
1.3.3. Mide el rendimeinto del sistema
1.3.3.1. Objetivo
1.3.3.1.1. Demostrar que el sistema satisface sus requerimientos, como descubrir problemas y defectos.
1.3.4. Para este tipo de pruebas se requiere un perfil operacional
1.3.4.1. Conjunto de pruebas real de trabajo que debería ser operacional en el sistema
1.3.5. Implica estresar el sistema realizando peticiones fuera de los límites establecidos
1.3.5.1. Pruebas de comportamiento de ejecución
1.3.5.2. Sobrecarga del sistema para manifestar defectos difíciles de detectar
1.4. Pruebas de usuario
1.4.1. Se enfoca en la funcionalidad, ya que al usuario lo único que le importa es que el sistema cumpla con su función
1.4.2. El comportamiento se determina por
1.4.2.1. Datos de Entrada
1.4.2.1.1. Ingresar Datos válidos para ver comportamiento del sistema
1.4.2.1.2. Ingresar datos inválidos para provocar fallas en el sistema
1.4.2.2. Datos de Salida
1.4.2.2.1. Evaluar los datos presentados y comparar contra los esperados
1.4.2.2.2. Provocar salidas incorrectas para detectar fallas
1.4.3. La mejor forma de probarlo en con casos de uso
1.5. Pruebas de aceptación
1.5.1. También conocidas como pruebas de entrega
1.5.2. El objetivo es incrementar la confianza del suministrador basado en los requerimientos
1.5.3. Conocidas como pruebas de caja negra, ya que se enfoca en las entradas y salidas relaciondas
1.5.4. Mejora de funciones y eficientar