Académique Documents
Professionnel Documents
Culture Documents
.-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
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 escalabilidad
Pruebas de mantenibilidad
Pruebas de instalabilidad
Pruebas de portabilidad
Pruebas manuales
Pruebas automticas
1.
2.
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
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