NIVELES DE PRUEBA.

.-Prueba Unitaria
La prueba de unidad es la primera fase de las pruebas dinmicas y se realizan
sobre cada mdulo del software de manera independiente

.-Prueba de Integracin
An cuando los mdulos de un programa funcionen bien por separado es
necesario probarlos conjuntamente: un mdulo puede tener un efecto adverso
o inadvertido sobre otro mdulo; las subfunciones, cuando se combinan,
pueden no producir la funcin principal deseada; la imprecisin aceptada
individuamente puede crecer hasta niveles inaceptables al combinar los
mdulos; los datos pueden perderse o malinterpretarse entre interfaces, etc

-.Prueba de sistema (modulares)

Este tipo de pruebas tiene como propsito ejercitar profundamente el sistema
para verificar que se han integrado adecuadamente todos los elementos del
sistema (hardware, otro software, etc.) y que realizan las funciones adecuadas.
Concretamente se debe comprobar que: - Se cumplen los requisitos funcionales
establecidos. - El funcionamiento y rendimiento de las interfaces hardware,
software y de usuario. - La adecuacin de la documentacin de usuario. Rendimiento y respuesta en condiciones lmite y de sobrecarga. Para la
generacin de casos de prueba de sistema se utilizan tcnicas de caja negra.
Este tipo de pruebas se suelen hacer inicialmente en el entorno del
desarrollador, denominadas Pruebas Alfa, y seguidamente en el entorno del
cliente denominadas Pruebas Beta.

-.Prueba de validacin o aceptacin (prueba UAT)

Pruebas de Aceptacin A la hora de realizar estas pruebas, el producto est
listo para implantarse en el entorno del cliente. El usuario debe ser el que
realice las pruebas, ayudado por personas del equipo de pruebas, siendo
deseable, que sea el mismo usuario quien aporte los casos de prueba. Estas
pruebas se caracterizan por: - Participacin activa del usuario, que debe
ejecutar los casos de prueba ayudado por miembros del equipo de pruebas. Estn enfocadas a probar los requisitos de usuario, o mejor dicho a demostrar
que no se cumplen los requisitos, los criterios de aceptacin o el contrato. Si no
se consigue demostrar esto el cliente deber aceptar el producto Corresponden a la fase final del proceso de desarrollo de software. Es muy
recomendable que las pruebas de aceptacin se realicen en el entorno en que
se va a explotar el sistema (incluido el personal que lo maneje). En caso de un
producto de inters general, se realizan pruebas con varios usuarios que
reportarn sus valoraciones sobre el producto. Para la generacin de casos de
prueba de aceptacin se utilizan tcnicas de caja negra.

TIPOS DE PRUEBA
Pruebas funcionales

Pruebas funcionales

Alpha testing

Beta testing

Pruebas de humo

Pruebas de regresin

Pruebas de aceptacin

Pruebas no funcionales

Pruebas no funcionales

Pruebas de seguridad

Pruebas de usabilidad

Pruebas de rendimiento

Pruebas de internacionalizacin y localizacin

Pruebas de escalabilidad

Pruebas de mantenibilidad

Pruebas de instalabilidad

Pruebas de portabilidad

POR AHORA CAPACITACION!

Tipos de pruebas por su ejecucin

Pruebas manuales

Pruebas automticas

Cualquier producto software puede aprobarse de una las siguientes formas:

1.

Conociendo la funcin para la que fue diseado el producto.

Se pueden utilizar pruebas para: comprobar su funcin operativa y
buscar errores de cada funcin.

2.

Conociendo el funcionamiento del producto.

Se pueden utilizar pruebas para: comprobar que las operaciones esta

de acuerdo con las especificaciones y para comprobar que los
componentes internos funcionan de forma adecuada.

ENFOQUES DE PRUEBA

Los casos de prueba o Test Case son un conjunto de condiciones o variables bajo las cules el analista
determinar si el requisito de una aplicacin es parcial o completamente satisfactorio

Tcnicas de Prueba Como se ha indicado anteriormente, las tcnicas de

evaluacin dinmica o prueba proporcionan distintos criterios para generar
casos de prueba que provoquen fallos en los programas.
Estas tcnicas se agrupan en:
Tcnicas de caja blanca o estructural, que se basan en un minucioso
examen de los detalles procedimentales del cdigo a evaluar, por lo que es
necesario conocer la lgica del programa.
Tcnicas de caja negra o funcionales, que realizan pruebas sobre la interfaz
del programa a probar, entendiendo por interfaz las entradas y salidas de dicho
programa. No es necesario conocer la lgica del programa, nicamente la
funcionalidad que debe realizar.

Modelo V de desarrollos de software

En la ingeniera del software

los casos de prueba o Test Case son un conjunto de condiciones o variables bajo las cules el
analista determinar si el requisito de una aplicacin es parcial o completamente satisfactorio
Estructura de los casos de prueba
Formalmente, los casos de prueba escritos consisten principalmente en tres partes con
subdivisiones:
* Introduccin/visin general: Contiene informacin general acerca de los Casos de Prueba.
* Identificador: Es un identificador nico para futuras referencias, por ejemplo, mientras se describe
un defecto encontrado.
* Caso de prueba dueo/creador: Es el nombre del analista o diseador de pruebas, quien ha
desarrollado pruebas o es responsable de su desarrollo.
* Versin: La actual definicin del caso de prueba.
* Nombre: El caso de prueba debe ser un ttulo entendible por personas, para la fcil comprensin
del propsito del caso de prueba y su campo de aplicacin.
* Identificador de requerimientos el cul est incluido por el caso de prueba. Tambin aqu puede
ser un identificador de casos de uso o de especificacin funcional.
* Propsito: Contiene una breve descripcin del propsito de la prueba, y la funcionalidad que
chequea.
* Dependencias: Indica qu otros subsistemas estn involucrados y en qu grado.
* Actividades de los casos de prueba
* Ambiente de prueba/configuracin: Contiene informacin acerca de la configuracin del hardware
o software en el cul se ejecutar el caso de prueba.
* Inicializacin: Describe acciones, que deben ser ejecutadas antes de que los casos de prueba se
hayan inicializado. Por ejemplo, debemos abrir algn archivo.
* Finalizacin: Describe acciones, que deben ser ejecutadas despus de realizado el caso de
prueba. Por ejemplo si el caso de prueba estropea la base de datos, el analista debe restaurarla
antes de que otro caso de prueba sea ejecutado.
* Acciones: Pasos a realizar para completar la prueba.
* Descripcin de los datos de entrada
* Resultados
* Salida esperada: Contiene una descripcin de lo que el analista debera ver tras haber
completado todos los pasos de la prueba.
* Salida obtenida: Contiene una breve descripcin de lo que el analista encuentra despus de que
los pasos de prueba se hayan completado.
* Resultado: Indica el resultado cualitativo de la ejecucin del caso de prueba, a menudo con
un Correcto/Fallido.
* Severidad: Indica el impacto del defecto en el sistema: Grave, Mayor, Normal, Menor.
* Evidencia: En los casos que aplica, contiene un link al print de pantalla (screenshot) donde se
evidencia la salida obtenida.
* Seguimiento: Si un caso de prueba falla, frecuentemente la referencia al defecto implicado se
debe enumerar en esta columna. Contiene el cdigo correlativo del defecto, a menudo corresponde
al cdigo del sistema de tracking de bugs que se est usando.
* Estado: Indica si el caso de prueba est: No iniciado, En curso, o terminado