Prueba de Sofware 1

UNIVERSIDAD NACIONAL DE TRUJILLO
ESCUELA ACADMICO PROFESIONAL DE

INGENERA DE SISTEMAS
PRUEBAS DE SOFWARE
2017
TECNOLOGA DE LA PROMAGACIN II
"AO DE LA CONSOLIDACIN DEL MAR DE GRAU"
TEMA:
Pruebas de Software
DOCENTE:
Mg. Vidal Melgarejo, Zoraida Yanet
CURSO:
Tecnologa de La Programacin II
ALUMNO:
Aranda Carranza Jean Piero
Garca Hiplito, Irvin Luis Alonso
Ruiz Obando, Ronald Alexander
Sucre Gamboa, Carlos Andrs
Vargas Ros, Junior Edward
CICLO:
PRUEBAS DE SOFWARE - 2017-0 Pgina 2 de 48

PRUEBAS DE SOFWARE
Contenido
1. INTRODUCCIN:.............................................................................................................. 5
2. DEFINICIONES ASOCIADAS:......................................................................................... 6
2.1. VERIFICACIN: Es el proceso de evaluacin de un sistema (o de uno de sus
componentes) para determinar si los productos de una fase dada satisfacen las condiciones
impuestas al comienzo de dicha fase. .......................................................................................... 6
2.2. VALIDACIN: ............................................................................................................ 6
2.3. PRUEBAS (TEST): ..................................................................................................... 6
2.4. CASO DE PRUEBA (TEST CASE) ........................................................................... 7
2.5. DEFECTO ( DEFECT FAULF BUG):.................................................................... 7
2.6. FALLO (FAILURE): .................................................................................................... 7
2.7. ERROR (ERROR): ..................................................................................................... 7
2.8. IDEAS PARADOJICAS DE LAS PRUEBAS: ........................................................... 8
2.9. RECOMENDACIONES PARA UNAS PRUEBAS EXITOSAS: ............................... 8
2.10. PROCESO DE PRUEBAS SOFWARE: ................................................................. 9
3. PRUEBAS DE SISTEMA .................................................................................................12

3.1. PRUEBAS UNITARIAS: ...........................................................................................12
3.3. PRUEBAS DE REGRESIN: ...................................................................................14
3.4. PRUEBA DE HUMO ( SMOKE TESTING O AD HOC ) ........................................15
3.5. PRUEBAS DE SISTEMA: .........................................................................................16
3.6. PRUEBAS DE DESEMPEO: ..................................................................................18
3.7. PRUEBA DE CARGA: ...................................................................................................19
3.8. PRUEBA DE STRESS....................................................................................................19
3.9. PRUEBAS DE VOLUMEN .............................................................................................21

3.10 PRUEBAS DE RECUPERACION Y TOLERANCIA A FALLAS ...................................23
3.11. PRUEBA DE MULTIPLES SITIOS: .............................................................................25
3.12. PRUEBA DE COMPATIBILIDAD Y CONVERSION: ..................................................26
3.13. PRUEBAS DE INTEGRIDAD DE DATOS Y BASE DE DATOS ...............................27
3.14. PRUEBAS DE SEGURIDAD Y CONTROL DE ACCESO ..........................................27
4. PRUEBAS DE VALIDACION A SISTEMAS A LA MEDIDA: .......................................30

4.1. PRUEBA DEL CICLO DEL NEGOCIO ....................................................................30
4.2. PRUEBA DE GUIA: ...................................................................................................31
4.3. PRUEBAS DE ESTILO .............................................................................................31
4.4. PRUEBAS DE ACEPTACION ..................................................................................32
4.5. PRUEBAS DE INSTALACION .................................................................................33
4.7. PRUEBAS DE DOCUMENTACION Y PROCEDIMIENTO ....................................35
4.8. PRUEBA DE USABILIDAD ......................................................................................36
4.9. PRUEBA DE CAMPO................................................................................................37
5. PRUEBAS DE VALIDACIONES A APLICACIONES GENRICAS .............................37

5.2. PRUEBAS BETA .......................................................................................................38
6. DISEO DE CAOSOS DE PREBA ( VALORES INTERESANTES).............................38

7. OBTENCIN DE VALORES INTERESANTES: ............................................................39
9. DOCUMENTO DISEO DE PRUEBAS:.........................................................................41
9.1. ESCENARIOS DE PRUEBAS: .................................................................................41
9.2. EVENTOS DE PRUEBAS: ........................................................................................41
9.3. CASOS DE PRUEBAS ..............................................................................................42
9.4. MATRIZ DE TRAZABILIDAD DE PRUEBAS: .......................................................44
9.5. EJECUCION DE PRUEBAS DE SOFTWARE: .......................................................44
9.6. PROCESO DE UNA EJECUCION FORMAL: .........................................................45
10. EJEMPLOS DE EJECUCION DE PRUEBAS: ...........................................................48

11. BIBLIOGRAFA: ...........................................................................................................48

1. INTRODUCCIN:
En la actualidad, las empresas , por lo general, no acostumbran a llevar procesos de

prueba formales en el desarrollo de productos de software, a pesar de la existencia de
un sinnmero de modelos especializados, como el Modelo de Madurez de Pruebas
Integrado (TMMI), el Proceso de Mejoramiento de Pruebas (TPI) y el Enfoque de Gestin
de Pruebas (TMAP); la razn principal de esta falencia radica en que estos modelos
plantean cmo mejorar el proceso de pruebas a travs del cumplimiento de objetivos y
prcticas especficas, sin embargo, no plantean cmo llegar a realizarlas.
La prueba de Software es un proceso que se realiza por diversos motivos,

conscientemente o de manera casual, pero que se reduce a unos cuantos pasos: se
ejecuta el programa (o parte del mismo) en ciertas condiciones, aplicando un conjunto
de valores a sus entradas y se observa su respuesta; si esta resulta la esperada o al
menos resulta aceptable, entonces se repite con otros valores o otras condiciones. En
cierto momento se da por concluido el proceso y se toma una decisin: aceptar el
producto como razonablemente bueno o rechazarlo, regresndolo a revisin.
Este proceso puede realizarse de manera sencilla e informal o de modo muy

riguroso y elaborado, pero siempre bajo el mismo principio, que es de tipo experimental.
En su sencillez, el proceso descrito deja una serie de interrogantes:
Por qu lo hacemos?
Para qu sirve?
Cmo determinar las condiciones y entradas adecuadas?
Cmo saber que la respuesta obtenida es correcta?
Cuntas veces debe repetirse o cmo saber cundo parar? Y
Debe aceptarse un producto despus de cierto nmero de intentos?
En este captulo se detallar y definir el proceso descrito y se buscar respuesta a los

interrogantes.

2. DEFINICIONES ASOCIADAS:
2.1. VERIFICACIN:
Es el proceso de evaluacin de un sistema (o de uno de sus componentes) para
determinar si los productos de una fase dada satisfacen las condiciones
impuestas al comienzo de dicha fase.
2.2. VALIDACIN:
El proceso de evaluacin de un sistema o de uno de sus componentes durante
o al final del proceso de desarrollo para determinar si satisface los requisitos
marcados por el usuario.
2.3. PRUEBAS (TEST):

Una actividad en la cual un sistema o uno de sus componentes se ejecuta en
circunstancias previamente especificadas, los resultados se observan y
registran y se realizan una evaluacin de algn aspecto.

2.4. CASO DE PRUEBA (TEST CASE)
Un conjunto de entradas, condiciones de ejecucin y resultados esperados

desarrollados para un objetivo particular.
2.5. DEFECTO ( DEFECT FAULF BUG):

Un defecto en el software como, por ejemplo, un proceso, una definicin de
datos o un paso de procesamiento incorrectos en un programa.
2.6. FALLO (FAILURE):

La incapacidad de un sistema o de alguno de sus componentes para realizar
las funciones requeridas dentro de los requisitos de rendimiento especificados.
2.7. ERROR (ERROR):
Tiene varias excepciones:
La diferencia entre un valor calculado, observado o medido y el valor verdadero,

especificado o tericamente correcto (Fallo).
Un defecto (Defecto).
Un resultado Incorrecto (Fallo).
Una accin humaba que conduce a un resultado incorrecto (Error).

2.8. IDEAS PARADOJICAS DE LAS PRUEBAS:

La prueba exhaustiva del software es impracticable (no se pueden probar
todas las posibilidades de su funcionamiento ni siquiera en programas
sencillos).
El objetivo de las pruebas es la deteccin de defectos en el software
(descubrir un error es el xito de una prueba).
Mito: Un defecto implica que somos malos profesionales y que
debemos sentirnos culpables todo el mundo comete errores.
El descubrimiento de un defecto significa un xito para la mejora de la
calidad.
2.9. RECOMENDACIONES PARA UNAS PRUEBAS EXITOSAS:
Cada casi de prueba debe definir el resultado de salida esperado que se comparar
con el realmente obtenido.
El programador debe evitar probar sus propios programas, ya que desea
(consciente o inconscientemente) demostrar que funcionan sin problema.
Adems, es normal que las situaciones que olvido considerar al crear el programa
queden de nuevo olvidados al crear los casos de prueba.
Se debe inspeccionar a conciencia el resultado de cada prueba, as, poder descubrir
posibles sntomas de defectos.
Al generar casos de prueba, se deben incluir tanto datos de entrada vlidos y
esperados como no vlidos e inesperados.

Las pruebas deben centrar en dos objetivos (es habitual olvidar el segundo):
Probar si el software no hace lo que debe hacer.
Probar si el software hace lo que debe hacer, es decir, si provoca efectos
secundarios adversos.
Se deben evitar los casos desechables, es decir, los no documentados ni diseados
con cuidado.
Ya que suele ser necesario probar muchas veces el software y por tanto hay que
tener claro que funciona y que no.
No deben hacerse planes de prueba suponiendo que, prcticamente, no hay
defectos en los programas y, por lo tanto, dedicando pocos recursos a las pruebas
Siempre hay defectos.
2.10. PROCESO DE PRUEBAS SOFWARE:

El proceso de pruebas del software se puede realizar en diversos momentos y
por diferentes causas. Sin embargo, el uso principal se da dentro del proceso
de desarrollo de software, que puede realizarse de diversas maneras: en una
forma secuencial tradicional o de alguna manera iterativa. En cualquiera de
ellas existe la actividad de prueba. Se puede descomponer como se muestra
en la Figura 2.
El esquema de la Figura 2 es muy general. Si se sigue el proceso secuencial

tradicional, las pruebas se realizan en las etapas finales del desarrollo, con
poca labor de preparacin inicial.
La comprobacin de que el software cumple lo que se espera de l tiene dos
variantes, donde ambas son necesarias:
La comprobacin de que el software se realiz correctamente, cumpliendo las
especificaciones que se fijaron al inicio, llamada verificacin.
Por otra parte, el asegurarse que el software satisface las necesidades del
cliente, es decir, le resuelve su problema, a lo que se denomina validacin.
Hasta aqu hemos hablado de pruebas como de algo normal, pero, por qu
haces pruebas? La principal justificacin est en la naturaleza humana,
siempre propensa a cometer equivocaciones. Las pruebas deben asegurarse

que cada parte funciones bien que las partes se combinen en subsistemas de
manera eficaz y que el conjunto total opere correctamente. Se identifican tres
niveles de prueba:
a) Nivel de Unidad: Orientada a las partes aisladas.

b) Nivel de Integracin: Analizan la interaccin de las partes.
c) Nivel de Sistemas: Analizan al sistema Completo.
Prueba de los valores limite

Los errores suelen situarse en los lmites.
Si la entrada se encuentra en el rango a..b entonces hay que probar con los
valores a -1, a, a + 1, b - 1, b y b + 1.
Si la entrada es un conjunto de valores entonces hay que probar con los
valores max-1, max, max+1, min-1, min y min+1.

Prueba de la particin equivalente

Mtodo de prueba de caja negra que divide el dominio de entrada de un
programa en un conjunto de clases de datos de los que se pueden derivar
casos de prueba
Si la entrada es un cdigo formado por 2 partes, la primera un prefijo
opcional de 3 dgitos, que empiece por 9 y la contrasea que sea una cadena
de hasta 6 caracteres que empiece necesariamente por una letra y que
puede contener letras, dgitos y el smbolo $
PREFIJO CONTRASEA
Se pueden disear casos de prueba, cada uno de los cuales representa a

un conjunto de casos de prueba.

Pruebas en entornos y aplicaciones especializadas
Pruebas sobre ventanas.

Pruebas sobre mens y uso del ratn.
Pruebas de entrada de datos.
Pruebas de documentacin y de ayuda.
Ejemplo
Al cerrar(minimizar) la ventana se cierra ( minimiza)
Al pulsar el botn, aparece en el campo de texto el resultado
Buscar ayuda de como utilizar la interfaz
3. PRUEBAS DE SISTEMA
3.1. PRUEBAS UNITARIAS:
A) OBJETOS DE LA PRUEBA:
Se focaliza en ejecutar cada mdulo (o unidad minima a ser probada, ej =
una clase) lo que provee un mejor modo de manejar la integracin de las
unidades en componentes mayores.
Busca asegurar que el cdigo funciona de acuerdo con las especificaciones
y que el mdulo lgico es vlido.

B) DESCRIPCION DE LA PRUEBA:
Particionar los mdulos en pruebas en unidades lgicas fciles de probar.

Por cada unidad hay que definir los casos de prueba (pruebas de caja
blanca).
Para esto los casos de prueba deben disearse de forma tal que se recorran
todos los caminos de ejecucin posibles dentro del cdigo bajo prueba; por
lo tanto, el diseador debe construirlos con acceso al cdigo fuente de la
unidad a probar.
Los aspectos a considerar son los siguientes: Rutinas de excepcin, Rutinas
de error, Manejo de parmetros, Validaciones, Valores vlidos, Valores
lmites, Rangos, Mensajes posibles.
C) TCNICA:
Comparar el resultado esperado con el resultado obtenido.
Si existen errores, reportarlos
D) CRITERIOS DE COMPLETITUD:
Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identificaron han sido tenidos en cuenta.
E) CONSIDERACIONES ESPERCIALES:
Para la elaboracin de pruebas unitarias en java se puede utilizar el JUNIT
y CACTUS.
3.2. PRUEBAS DE INTEGRACIN:
A) OBJETOS DE LA PRUEBA:
Identificar errores introducidos por la combinacin de programas

probados unitariamente.
Determina cmo la base de datos de prueba ser cargada.
Verificar que las interfaces entre las entidades externas (usuarios)
y las aplicaciones funcionan correctamente.
Verificar que las especificaciones de diseo sean alcanzadas.

Describe cmo verificar que las interfaces entre las componentes
de software funcionan correctamente.
Determina cmo la base de datos de prueba ser cargada.
Determina el enfoque para avanzar desde un nivel de integracin
de las componentes al siguiente.
Decide qu acciones tomar cuando se descubren problemas
C) TECNICAS:
Utilizar la tcnica top-down. Se empieza con los mdulos de nivel
superior, y se verifica que los mdulos de nivel superior llaman a
los de nivel inferior de manera correcta, con los parmetros
correctos.
Utilizar la tcnica down-top. Se empieza con los mdulos de nivel
inferior, y se verifica que los mdulos de nivel inferior llaman a los
de nivel superior de manera correcta, con los parmetros correctos.
D) CRITERIOS DE COMPLEJIDAD:
Todos los defectos que se identificaron han sido tenidos en
cuenta.
E) CONSIDERAIONES ESPECIALES: Ninguna
3.3. PRUEBAS DE REGRESIN:

A) OBJETIVO DE PRUEBA:
Determinar si los cambios recientes en una parte de la aplicacin tienen
efecto adverso en otras partes.
En esta prueba se vuelve a probar el sistema a la luz de los cambios
realizados durante el debugging, mantenimiento o desarrollo de la nueva
versin del sistema buscando efectos adversos en otras partes.

C) TCNICA:
La prueba de regresin es una nueva corrida de casos de prueba previos.
Se requiere de polticas para ser creada la prueba de regresin y decidir
qu casos de prueba incluir, para probar eficientemente.
La prueba de regresin es un buen candidato para automatizacin.
Desde que estas pruebas se repiten una y otra vez, las herramientas
para minimizar el esfuerzo del trabajo son tiles.
La prueba de viejas funcionalidades es ms importante que la de nuevas
funcionalidades.
Aquellos casos de uso (y los casos de prueba asociados) que descubren
defectos tempranamente deben ser incluidos en la prueba de regresin.
D) CRITERIO DE COMPLEJIDAD:
E) CONSIDERACIONES ESPERCIALES: NINGUNA
3.4. PRUEBA DE HUMO ( SMOKE TESTING O AD HOC )

A) OBJETIVOS DE LA PRUEBA:
Los objetivos son los siguientes:
Detectar los errores en realeases tempranos y de manera fcil
Probar el sistema constantemente
Garantizar poco esfuerzo en la integracin final del sistema
Asegurar los resultados de las pruebas unitarias
Se reducen los riesgos y a baja calidad.
B) DESCRIPCIN DE LA PRUEBA:
Toma ste nombre debido a que su objetivo es probar el sistema
constantemente buscando que saque humo o falle. En algunos proyectos
este tipo de prueba va junto con las pruebas funcionales. Permite detectar
problemas que por lo regular no son detectados en las pruebas normales.
Algunas veces, si las Pruebas ocurren tarde en el ciclo de desarrollo est
ser una forma de garantizar el buen desarrollo.
Las pruebas de humo NO SON exhaustivas, pero van de extremo a extremo
de la aplicacin

C) TCNICA:
Realizar una integracin de todo el sistema cada cierto periodo (se
recomienda un da, mximo una semana)
Realizar los casos de prueba asignados a los casos de uso finalizados ese
da ms los realizados en das anteriores
Buscar eficientemente errores
Todos los defectos que se identifcaron han sido tenidos en cuenta.
E) CONSIDERACIONES ESPECIALES:
Cuando se encuentre un error en el release correspondiente al periodo
elegido para hacer las integraciones del sistema, se detiente el desarrollo
hasta que el error es corregido.
Este tipo de pruebas es til en la programacin extrema (extremme
programming) y de sistemas complejos.
Es til el uso de programas de prueba automticas que se encarguen de
probar os casos de prueba ya ejecutados en realeases anteriores.
3.5. PRUEBAS DE SISTEMA:

A) OBJETIVO DE PRUEBA:
Asegurar la apropiada navegacin dentro del sistema, ingreso de datos,
procesamiento y recuperacin.
Las pruebas del sistema deben enfocarse en requisitos que puedan ser
tomados directamente de casos de uso y reglas y funciones de negocios. El
objetivo de estas pruebas es verificar el ingreso, procesamiento y
recuperacin apropiado de datos, y la implementacin apropiada de las
reglas de negocios. Este tipo de pruebas se basan en tcnicas de caja negra,
sto es, verificar el sistema (y sus procesos internos), la interaccin con las
aplicaciones que lo usan via GUI y analizar las salidas o resultados.
En esta prueba se determina qu pruebas de Sistema (usabilidad, volumen,
desempeo, etc.) asegurarn que la aplicacin alcanzar sus objetivos de
negocio.
La prueba de Sistema incluye:

Prueba funcionalidad
Prueba de Usabilidad
Prueba de Performance
Prueba de Documentacin y Procedimientos
Prueba de Seguridad y Controles
Prueba de Volumen
Prueba de Esfuerzo (Stress)
Prueba de recuperacin
Prueba de mltiples sitios
Para sistemas web se recomienda especialmente realizar mnimo el
siguiente grupo de pruebas de sistema:
Humo.
Usabilidad
Performance
Funcionalidad
Para capitalizar el trabajo hasta ahora completado, los casos de prueba de
las pruebas previas realizadas pueden frecuentemente ser reorganizados y
rehusados durante la prueba de sistema. No obstante, deben ser
desarrollados casos de prueba adicionales para aquellos aspectos del
sistema, tales como documentacin, procedimientos y desempeo que no
han sido probados durante la prueba unitaria y de integracin.
La prueba de sistema es compleja porque intenta validar un nmero de
caractersticas al mismo tiempo, a diferencia de otras pruebas que slo se
centran en uno o dos aspectos del sistema al mismo tiempo.
C) TCNICA:
Ejecute cada caso de uso, flujo bsico o funcin utilizando datos vlidos e
invlidos, para verificar que:
Los resultados esperados ocurren cuando se utiliza un dato vlido.
Los mensajes de error o de advertencia aparecen en el momento
adecuado, cuando se utiliza un dato invlido.
Cada regla de negocios es aplicada adecuadamente.

Identifique o describa aquellos aspectos (internos o externos) que
impactan la implementacin y ejecucin de las pruebas del Sistema.
3.6. PRUEBAS DE DESEMPEO:

A) OBJETIVO DE LA PRUEBA:
Validar el tiempo de respuesta para las transacciones o funciones de
negocios bajo las siguientes dos condiciones:
Volumen normal anticipado
Volumen mximo anticipado.
Las pruebas de carga miden la capacidad del sistema para continuar
funcionando apropiadamente bajo diferentes condiciones de carga.
La meta de las pruebas de carga es determinar y asegurar que el sistema
funciona apropiadamente an ms all de la carga de trabajo mxima
esperada. Adicionalmente, las pruebas de carga evalan las caractersticas
de desempeo (tiempos de respuesta, tasas de transacciones y otros
aspectos sensibles al tiempo).
C) TCNICAS:
Use los scripts desarrollados para Pruebas del Negocio.
Modifique archivos de datos (para incrementar el nmero de transacciones
o veces que cada transaccin ocurre).
D) CRITERIOS DE COMPLEJITITUD:
Mltiples transacciones, mltiples usuarios. Se completaron las pruebas de
los scripts sin ninguna falla y dentro del tiempo esperado.
Las pruebas de carga deben ser ejecutadas en una mquina dedicada
o en un tiempo dedicado. Esto permite control total y medidas
precisas.
La Base de datos utilizada para pruebas de desempeo debe ser de
un tamao real o proporcionalmente ms grande que la diseada.

3.7. PRUEBA DE CARGA:
A) OBJETIVOS DE PRUEBA:
Verificar el tiempo de respuesta del sistema para transacciones o casos de
uso de negocios, bajo diferentes condiciones de carga.
Las pruebas de carga miden la capacidad del sistema para continuar
funcionando apropiadamente bajo diferentes condiciones de carga.
La meta de las pruebas de carga es determinar y asegurar que el sistema
funciona apropiadamente an ms all de la carga de trabajo mxima
esperada. Adicionalmente, las pruebas de carga evalan las caractersticas
de desempeo (tiempos de respuesta, tasas de transacciones y otros
aspectos sensibles al tiempo).
C) TECNICA:
Use los scripts desarrollados para Pruebas del Negocio.
Modifique archivos de datos (para incrementar el nmero de transacciones
o veces que cada transaccin ocurre).
D) CRITERIO DE COMPLETITUD:
Mltiples transacciones, mltiples usuarios. Se completaron las pruebas
de los scripts sin ninguna falla y dentro del tiempo esperado.
Las pruebas de carga deben ser ejecutadas en una mquina dedicada o
en un tiempo dedicado. Esto permite control total y medidas precisas
La Base de datos utilizada para pruebas de desempeo debe ser de un
tamao real o proporcionalmente ms grande que la diseada.
3.8. PRUEBA DE STRESS

Verificar que el sistema funciona apropiadamente y sin errores, bajo estas
condiciones de stress:
Memoria baja o no disponible en el servidor.
Mximo nmero de clientes conectados o simulados (actuales o
fsicamente posibles)
Mltiples usuarios desempeando la misma transaccin con los mismos
datos.
El peor caso de volumen de transacciones (ver pruebas de desempeo).
NOTAS: La meta de las pruebas de stress tambin es identificar y
documentar las condiciones bajo las cuales el sistema FALLA.
Las pruebas de stress se proponen encontrar errores debidos a recursos
bajos o completitud de recursos. Poca memoria o espacio en disco puede
revelar defectos en el sistema que no son aparentes bajo condiciones
normales. Otros defectos pueden resultar de incluir recursos compartidos,
como bloqueos de base de datos o ancho de banda de la red. Las pruebas
de stress identifican la carga mxima que el sistema puede manejar.
El objetivo de esta prueba es investigar el comportamiento del sistema bajo
condiciones que sobrecargan sus recursos. No debe confundirse con las
pruebas de volumen: un esfuerzo grande es un pico de volumen de datos
que se presenta en un corto perodo de tiempo.
Puesto que la prueba de esfuerzo involucra un elemento de tiempo, no
resulta aplicable a muchos programas, por ejemplo, a un compilador o a
una rutina de pagos.
Es aplicable, sin embargo, a programas que trabajan bajo cargas variables,
interactivos, de tiempo real y de control de proceso.
Aunque muchas pruebas de esfuerzo representan condiciones que el
programa encontrar realmente durante su utilizacin, muchas otras
sern en verdad situaciones que nunca ocurrirn en la realidad. Esto no
implica, sin embargo, que estas pruebas no sean tiles.

Si se detectan errores durante estas condiciones imposibles, la prueba

es valiosa porque es de esperar que los mismos errores puedan
presentarse en situaciones reales, algo menos exigentes.
C) TECNICA:
Use los scripts utilizados en las pruebas de desempeo.
Para probar recursos limitados, las pruebas se deben correr en un servidor
con configuracin reducida (o limitada).
Para las pruebas de stress restantes, deben utilizarse mltiples clientes,
ya sea corriendo los mismos scripts o scripts complementarios para
producir el peor caso de volumen de transacciones
Todas las pruebas planeadas han sido ejecutadas y excedidas sin que el
sistema falle. (O si las condiciones en que el sistema falle ocurren por fuera
de las condiciones especificadas).
Producir stress en la red puede requerir herramientas de red para
sobrecargarla de trfico.
El espacio en disco utilizado para el sistema debe ser reducido
temporalmente para limitar el espacio disponible para el crecimiento de la
Base de datos.
Sincronizacin de varios clientes accediendo simultneamente los mismos
registros.
3.9. PRUEBAS DE VOLUMEN
Verificar que la aplicacin funciona adecuadamente bajo los siguientes
escenarios de volumen:
o Mximo (actual o fsicamente posible) nmero de clientes conectados (o
simulados), todos ejecutando la misma funcin (peor caso de desempeo)
por un perodo extendido.
o Mximo tamao de base de datos (actual o escalado) y mltiples
consultas ejecutadas simultneamente

Las pruebas de volumen hacen referencia a grandes cantidades de datos
para determinar los lmites en que se causa que el Sistema falle. Tambin
identifican la carga mxima o volumen que el sistema puede manejar en
un perodo dado. Por ejemplo, si el sistema est procesando un conjunto
de registros de Base de datos para generar un reporte, una prueba de
volumen podra usar una Base de datos de prueba grande y verificar que
el sistema se comporta normalmente y produce el reporte correctamente.
El objetivo de esta prueba es someter al sistema a grandes volmenes de
datos para determinar si el mismo puede manejar el volumen de datos
especificado en sus requisitos.
Algunos ejemplos de escenarios de prueba de volmenes:
Un compilador puede ser alimentado por un programa para compilar que
sea absurdamente grande.
Un editor de nexos puede recibir un programa que contenga miles de
mdulos.
Un simulador de circuito electrnico puede recibir un circuito diseado
con miles de componentes.
Puesto que obviamente, la prueba de volumen es una prueba costosa,
tanto en tiempo de mquina como en personal, se debe tratar de no
exceder los lmites. Sin embargo, todo programa debera ser expuesto, al
menos, a algunas pruebas de volumen.
C) TECNICA:
Utilice los scripts diseados para las pruebas de desempeo.
Deben usarse mltiples clientes, ya sea corriendo las mismas pruebas o
pruebas complementarias para producir el peor caso de volumen (ver
pruebas de stress) por un perodo extendido.
Se utiliza un tamao mximo de Base de datos. (actual, escalado o con
datos representativos) y mltiples clientes para correr consultas
simultneamente para perodos extendidos.

Todas las pruebas planeadas han sido ejecutadas y los lmites

especificados en el sistema se han conseguido o excedido sin que el
sistema falle.
Qu perodo de tiempo debera considerarse como aceptable para
condiciones de volumen alto?
3.10 PRUEBAS DE RECUPERACION Y TOLERANCIA A FALLAS
Verificar que los procesos de recuperacin (manual o automtica)

restauran apropiadamente la Base de datos, aplicaciones y sistemas, y los
llevan a un estado conocido o deseado. Los siguientes tipos de condiciones
deben incluirse en la prueba:
Interrupcin de electricidad en el cliente.

Interrupcin de electricidad en el servidor
Interrupcin en la comunicacin hacia el servidor (cadas de red)
Interrupcin en la comunicacin con los controladores de disco.
Ciclos incompletos (procesos de consultas interrumpidos, procesos de
sincronizacin de datos interrumpidos)
Llaves o apuntadores de base de datos invlidos
Elementos corruptos o invlidos en la base de datos.
Estas pruebas aseguran que una aplicacin o sistema se recupere de una

variedad de anomalas de hardware, software o red con prdidas de datos
o fallas de integridad.
Las pruebas de tolerancia a fallas aseguran que, para aquellos sistemas

que deben mantenerse corriendo, cuando una condicin de falla ocurre,
los sistemas alternos o de respaldo pueden tomar control del sistema sin
prdida de datos o transacciones.
Las pruebas de recuperacin son contrarias a las pruebas en que la

aplicacin o sistema es expuesto a condiciones extremas (o condiciones

simuladas), tales como fallas en dispositivos en entrada/salida o llaves o

apuntadores invlidos de base de datos. Los procesos de recuperacin se
invocan y la aplicacin es monitoreada y/o inspeccionada para verificar
que stos mecanismos se han ejecutado en forma apropiada.
El objetivo de esta prueba es determinar la habilidad del sistema para

recuperarse de una falla de hardware o software. Esta prueba evala las
caractersticas de contingencia construidas en el sistema para procesar
interrupciones y para volver a puntos especficos en el ciclo de
procesamiento del sistema. La recuperacin debe ser considerada en el
proceso de diseo. Errores de programacin o de datos pueden ser
incorporados ex profeso en un sistema para determinar si se puede
recuperar de ellos. Las fallas de equipo (por ejemplo, errores de paridad en
memoria, errores en dispositivos de entrada/salida) pueden ser
simuladas.
C) TECNICA:
Se deben utilizar las pruebas creadas para la Funcionalidad del sistema y

Procesos de Negocios para crear una serie de transacciones. Una vez se
alcanza el punto inicial de las pruebas de recuperacin, se deben realizar
o simular las siguientes acciones:
Interrupcin de electricidad en el cliente.

Interrupcin de electricidad en el servidor: simular o iniciar
procedimientos de prdida de energa para el servidor.
Interrupcin de la comunicacin en la red. (desconectar fsicamente los
cables o apagar los hubs o routers)
Interrupcin de la comunicacin con los controladores de disco: simular o
eliminar fsicamente la comunicacin con uno o ms controladores o
dispositivos.
Una vez se realizan estas acciones, se deben ejecutar series de
transacciones, y luego, una vez alcanzado el segundo punto de pruebas,
se deben invocar los procedimientos de recuperacin.
Las pruebas para ciclos incompletos utilizan la misma tcnica que se
describe arriba, excepto que los procesos de Base de datos deban ser
abortados o terminados prematuramente.

Las pruebas para estas condiciones requieren que se llegue a un estado

conocido previamente en la Base de datos. Algunos campos, apuntadores
y llaves deben ser modificados manualmente, valindose de las
herramientas que ofrezca la SSPD. Las transacciones adicionales deben
ser ejecutadas utilizando las pruebas para Funcionalidad de la aplicacin
y para Procesos de Negocios.
En todos los casos mencionados, la Base de datos, aplicacin y otros

sistemas deben retornar a un estado conocido y deseado, una vez se
completan los procedimientos de recuperacin. Este estado podra incluir
que el dao de datos se limite solamente a los campos, llaves o
apuntadores que se sabe que fueron alterados, y reportes indicando los
procesos o transacciones que no fueron completadas debido a las
interrupciones producidas.
Las pruebas de recuperacin pueden llegar a ser molestas. Los
procedimientos para desconectar cables o simular prdida de electricidad
pueden ser poco factibles o deseables. Podran llegar a requerirse mtodos
alternativos, como herramientas de diagnstico.
Se requiere la participacin de personal de la red, administradores de la

base de datos y del sistema.
Estas pruebas deben ser ejecutadas en horas no laborables o en mquinas
aisladas.
3.11. PRUEBA DE MULTIPLES SITIOS:
Detectar fallas en configuraciones y comunicaciones de datos entre
mltiples sitios.
El propsito de esta prueba es evaluar el correcto funcionamiento del
sistema o subsistema en mltiples instalaciones.
C) TECNICA:
Realizar casos de prueba que verifiquen mnimo lo siguiente:

Consistencia de las opciones de configuracin para el sistema a travs de

los sitios
Empaquetamiento del sistema para mltiples instalaciones
Sincronizacin de datos entre sitios
Comunicacin de datos entre sistemas en diferentes sitios
Rompimiento de funciones de sistema a travs de los sitios.
Consistencia de controles y seguridad a travs de los sitios
Ninguna
3.12. PRUEBA DE COMPATIBILIDAD Y CONVERSION:
Buscar problemas de compatibilidad y conversin en los sistemas.
El propsito es demostrar que los objetivos de compatibilidad no han sido
logrados y que los procedimientos de conversin no funcionan.
La mayora de los programas que se desarrollan no son completamente
nuevos; con frecuencia son reemplazos de partes deficientes, ya sea de
sistemas de procesamiento de datos, o sistemas manuales.
Como tales, los programas tienen a menudo objetivos especficos con
respecto a su compatibilidad y a sus procedimientos de conversin con el
sistema existente.
C) TECNICA:
Desarrollar casos de prueba que permitan detectar deficiencias con:
Compatibilidad entre programas
Conversin de datos

Ninguna
3.13. PRUEBAS DE INTEGRIDAD DE DATOS Y BASE DE DATOS
Asegurar que los mtodos de acceso y procesos funcionan adecuadamente

y sin ocasionar corrupcin de datos.
La Base de datos y los procesos de Base de datos deben ser probados como
sistemas separados del proyecto. Estos sistemas deberan ser probados
sin usar interfaces de usuario (como las interfaces de datos). Se necesita
realizar investigacin adicional en el DBMS para identificar las
herramientas y tcnicas que podran existir para soportar las pruebas
identificadas ms adelante.
C) TECNICA:
Invoque cada mtodo de acceso y proceso de la Base de datos, utilizando

en cada uno datos vlidos e invlidos.
Analice la Base de datos, para asegurar que los datos han sido grabados
apropiadamente, que todos los eventos de Base de datos se ejecutaron en
forma correcta y revise los datos retornados en diferentes consultas.
Todos los mtodos de acceso y procesos de la Base de datos funcionan

como fueron diseados y sin corrupcin de datos
Las pruebas pueden requerir un ambiente de DBMS o controladores para

ingresar o modificar datos directamente en la Base de datos.
Se debe utilizar un conjunto pequeo de datos para incrementar la
visibilidad de cualquier evento anormal o inesperado.
Los procesos pueden ser invocados manualmente.
3.14. PRUEBAS DE SEGURIDAD Y CONTROL DE ACCESO

Nivel de seguridad de la aplicacin: Verifica que un actor solo pueda

acceder a las funciones y datos que su usuario tiene permitido.
Nivel de Seguridad del Sistema: Verificar que solo los actores con acceso
al sistema y a la aplicacin estn habilitados para accederla.
Las pruebas de seguridad y control de acceso se centran en dos reas

claves de seguridad:
Seguridad del sistema, incluyendo acceso a datos o Funciones de negocios

y
Seguridad del sistema, incluyendo ingresos y accesos remotos al sistema.
Las pruebas de seguridad de la aplicacin garantizan que, con base en la
seguridad deseada, los usuarios estn restringidos a funciones especficas
o su acceso est limitado nicamente a los datos que est autorizado a
acceder. Por ejemplo, cada usuario puede estar autorizado a crear nuevas
cuentas, pero slo los administradores pueden borrarlas. Si existe
seguridad a nivel de datos, la prueba garantiza que un usuario tpico 1
puede ver toda la informacin de clientes, incluyendo datos financieros;
sin embargo, el usuario 2 solamente puede ver los datos institucionales
del mismo cliente.
Las pruebas de seguridad del sistema garantizan que solamente aquellos

usuarios autorizados a acceder al sistema son capaces de ejecutar las
funciones del sistema a travs de los mecanismos apropiados.
Debido a la creciente preocupacin de la sociedad por la privacidad de la

informacin, muchos programas tienen objetivos especficos de seguridad.
El objetivo de esta prueba es evaluar el funcionamiento correcto de los

controles de seguridad del sistema para asegurar la integridad y
confidencialidad de los datos. El foco principal es probar la vulnerabilidad
del sistema frente a accesos o manipulaciones no autorizadas. Una
manera de encontrar esos casos de prueba es estudiar problemas
conocidos de seguridad en sistemas similares y tratar de mostrar la
existencia de problemas parecidos en el sistema que se examina.

Algunas consideraciones de prueba son:
Controles de acceso fsico

Acceso a estructuras de datos especficas a travs de los programas de
aplicacin.
Seguridad en sitios remotos
Existencia de datos confidenciales en reportes y pantallas
Controles manuales, incluyendo aquellos para autorizacin y aprobacin,
formularios, documentacin numerada, transmisin de datos, balances y
conversin de datos.
Controles automticos, incluyendo aquellos para edicin de datos,
chequeo de mquinas, errores del operador, acceso a datos elementales y
archivos, acceso a funciones, auditora, entre otros.
C) TECNICA:
Funciones / Seguridad de Datos: Identificar cada tipo de usuario y las

funciones y datos a los que se debe autorizar.
Crear pruebas para cada tipo de usuario y verificar cada permiso, creando
transacciones especficas para cada tipo de usuario.
Modificar tipos de usuarios y volver a ejecutar las pruebas. En cada caso,
verificar si los datos o funciones adicionales quedan correctamente
permitidos o denegados.
Acceso al sistema (ver consideraciones especiales)
Para cada tipo de usuario conocido, las funciones y datos apropiados y

todas las transacciones funcionan como se esperaba.
El acceso al sistema debe ser revisado y discutido con los administradores

de la red y/o del sistema. Esta prueba puede no ser requerida como tal,
sino como una funcin de los administradores de red o del sistema.

4. PRUEBAS DE VALIDACION A SISTEMAS A LA MEDIDA:
4.1. PRUEBA DEL CICLO DEL NEGOCIO

Asegurar que el sistema funciona de acuerdo con el modelo de negocios
emulando todos los eventos en el tiempo y en funcin del tiempo.
Las pruebas del ciclo de negocio deberan emular las actividades ejecutadas
en el a travs del tiempo. Debera identificarse un periodo, como por ejemplo
un ao, y las transacciones y actividades que podran ocurrir durante un
periodo de un ao deberan ejecutarse. Incluyendo todos los ciclos y eventos
diarios, semanales y mensuales que sean datos sensitivos, como las agendas.
C) TCNICA:
Ejecute cada caso de uso, flujo bsico o funcin utilizando datos vlidos e
invlidos, para verificar que:
Incremente el nmero de veces en que una funcin es ejecutada para
simular diferentes usuarios sobre un periodo especificado
Todas las fechas o funciones que involucren tiempos sern probadas
con datos vlidos e invlidos de fechas o periodos de tiempo.
Todas las funciones ocurren en un periodo de tiempo sern ejecutadas
en el tiempo apropiado.
Los resultados esperados ocurren cuando los datos vlidos son usados.
Los mensajes de error o de advertencia aparecen en el momento
adecuado, cuando se utiliza un dato invlido.
Cada regla de negocios es aplicada adecuadamente.

D) CONSIDERACIONES ESPECIALES:
Las fechas y eventos del sistema pueden requerir actividades
especiales de soporte.
Se requiere un modelo de negocios para identificar requisitos y
procedimientos de prueba apropiados.
4.2. PRUEBA DE GUIA:

Las navegaciones a travs de los objetos de la prueba reflejan las
funcionalidades del negocio y requisitos, se realiza una navegacin
ventana por ventana, usando los modos de acceso (tabuladores,
movimientos del mouse, teclas rpidas, etc)
Los objetos de la ventana y caractersticas, tales como mens, medidas,
posiciones, estados y focos se verifican conforme a los estndares.
La prueba de interfaz de usuario verifica la interaccin del usuario con el
software. El objetivo es asegurar que la interfaz tiene apropiada navegacin a
travs de las diferentes funcionalidades. Adicionalmente, las pruebas de
interfaz aseguran que el objeto de la interfaz a ser probada se encuentra dentro
de los estndares de la industria
C) TCNICA:
Pruebas de crear / modificar cada ventana para verificar la adecuada
navegacin y estado de los objetos.
Cada ventana elegida ser totalmente verificada y comparada con similares en
el mercado logrando una buena aceptacin dentro del estndar.
E) CONSIDERACIONES ESPECIALES: NINGUNA
4.3. PRUEBAS DE ESTILO

Comprobar que la aplicacin sigue los estndares de estilo propios del cliente.
Se entienden como tales el formato de las ventanas, colores corporativos, tipos de
letra etc.
C) TCNICA:
Se realiza una navegacin por la aplicacin verificando si se cumplen con
los estndares de GUI del cliente.
Validar objetos grficos contra el manual de estilos del cliente.
Todos los defectos que se identificaron han sido tenidos en cuenta
Solicitar al cliente el manual de estilos, en caso de no existir, hacer un
levantamiento preliminar de este con base en la informacin corporativa
existente.
4.4. PRUEBAS DE ACEPTACION

Determinacin por parte del cliente de la aceptacin o rechazo del sistema
desarrollado.
B) DESCRIPCION DE LA PRUEBA
La prueba de aceptacin es ejecutada antes de que la aplicacin sea
instalada dentro de un ambiente de produccin. La prueba de aceptacin
es generalmente desarrollada y ejecutada por el cliente o un especialista de
la aplicacin y es conducida a determinar como el sistema satisface sus
criterios de aceptacin validando los requisitos que han sido levantados
para el desarrollo, incluyendo a documentacin y procesos de negocio.
Basado en esta prueba el cliente determina si acepta o rechaza el sistema
Estas pruebas estn destinadas a probar que el producto est listo para el
uso operativo. Suelen ser un subconjunto de las Pruebas de Sistema.

Sirve para que el usuario pueda validar si el producto final se ajusta a los
requisitos fijados, es decir, si el producto est listo para ser implantado para
el uso operativo en el entorno del usuario.
Esta prueba es complementada por la prueba de estilo.
C) TECNICA:
Realizacin de los documentos de planes de prueba de aceptacin y
especificacin de los mismos, basados en los criterios de aceptacin del cliente.
Los casos prueba de aceptacin han de ser planificados, organizados y
formalizados de manera que se determine el cumplimiento de los requisitos del
sistema. Para la realizacin de estas pruebas se necesita disponer de los
siguientes documentos:
Especificacin de requisitos del sistema.
Manual de usuario.
Manual de administrador.
Realizar Pruebas de estilo
Las Pruebas de Aceptacin se suelen realizar en un entorno de pre-produccin.
4.5. PRUEBAS DE INSTALACION

Verificar y validar que el sistema se instala apropiadamente en cada cliente,
bajo las siguientes condiciones:
Instalaciones nuevas, nuevas mquinas a las que nunca se les ha
instalado el sistema.
Actualizar mquinas previamente instaladas con el sistema.
Instalar versiones viejas en mquinas previamente instaladas con el
sistema.

Las pruebas de instalacin tienen dos propsitos. El primero es asegurar que el
sistema puede ser instalado en todas las configuraciones posibles, tales como
nuevas instalaciones, actualizaciones, instalaciones completas o personalizadas,
y bajo condiciones normales o anormales; estas ltimas incluyen insuficiente
espacio en disco, falta de privilegios para algunas tareas, etc.
El segundo propsito es verificar que, una vez instalado, el sistema opera
correctamente. Esto usualmente implica correr un nmero significativo de
pruebas de Funcionalidad.
C) TCNICAS:
Disear sripts para validar las condiciones de la mquina a instalar.
Realizar la instalacin
Las transacciones de la aplicacin se ejecutan sin fallas.
Qu transacciones del sistema se deben seleccionar para realizar una prueba
confiable de que el sistema ha sido instalado exitosamente y no hace falta ningn
componente del sistema?
4.6. PRUEBAS FUNCIONALES

Se asegura la trabajo apropiado de los requisitos funcionales, incluyendo la
navegacin, entrada de datos, procesamiento y obtencin de resultados
Las pruebas Funcionales deben enfocarse en los requisitos funcionales, las
pruebas pueden estar basadas directamente en los Casos de Uso (o funciones
de negocio), y las reglas del negocio. Las metas de estas pruebas son:
Verificar la apropiada aceptacin de datos,
Verificar el procesamiento y recuperacin y la implementacin adecuada
de las reglas del negocio.
Este tipo de pruebas estn basadas en tcnicas de caja negra, que es, verificar
la aplicacin (y sus procesos internos) mediante la interaccin con la aplicacin
va GUI y analizar la salida (resultados). Lo que se identifica a continuacin es
un diseo preliminar de las pruebas recomendadas para cada aplicacin.

C) TECNICA:
Se ejecuta cada caso de uso, flujo de caso de uso, o funcin, usando datos
vlidos e invlidos, para verificar lo siguiente:
Que los resultados esperados ocurran cuando se usen datos vlidos.
Que sean desplegados los mensajes apropiados de error y precaucin
cuando se usan datos invlidos.
Que se aplique apropiadamente cada regla de negocio.
E) CONDIDERACIONES ESPECIALES:
Identifique o describa aquellos aspectos (internos o externos) que impactan la
implementacin y ejecucin de las pruebas de funcionalidad
4.7. PRUEBAS DE DOCUMENTACION Y PROCEDIMIENTO

A) OBJETIVO DE LA PRUEBA: Evaluar la documentacin del usuario
Evaluar la exactitud y claridad de la documentacin del usuario y para determinar
si el manual de procedimientos trabajar correctamente como una parte integral
del sistema.
Muchos defectos son identificados cuando un probador competente chequea
totalmente los manuales y documentacin del usuario.
Muchos programas son parte de sistemas mayores, no completamente
automatizados, que contienen procedimientos realizados por operadores.
Cualquier procedimiento humano, tal como los que llevan a cabo el operador, el
administrador de la base de datos, o el usuario de terminal, debe ser probado
durante la prueba de sistemas.
C) TCNICA:
Revisar la documentacin del proyecto contra las funcionalidades del sistema y su
configuracin fsica.
Todos los defectos que se identificaron han sido tenidos en cuenta

E) CONSIDERACIONES ESPECIALES: Ninguna.
4.8. PRUEBA DE USABILIDAD

A) OBJETIVO DE LA PRUEBA: Determinar la usabilidad del sistema
Determina cun bien el usuario podr usar y entender la aplicacin. Identifica
las reas de diseo que hacen al sistema de difcil uso para el usuario.
La prueba de usabilidad detecta problemas relacionados con la conveniencia y
practicidad del sistema desde el punto de vista del usuario
C) TCNICA:
Verificar que la aplicacin no presenta los siguientes problemas de
usabilidad tpicos:
El sistema es demasiado complejo y difcil de usar.
Es difcil instalar y entender el sistema
La recuperacin de errores es pobre y los mensajes de error no tienen
significado
La sintaxis de los comandos es difcil de aprender y recordar
El sistema obliga al usuario a recordar formatos y secuencias fijas
Los procedimientos no son simples ni obvios
El sistema no tiene instrucciones de ayuda por computadora y tiene
manuales pobres.
Los diagramas, pantallas, reportes y grficos son de calidad y
apariencia pobre
El sistema carece de herramientas de construccin adecuadas y
requiere mltiples comandos
La lgica y conveniencia de los botones, switches, displays y
mensajes de ayuda deben ser testeados. (La prueba de usabilidad
puede ser conducida por un grupo separado si es posible.
Se deben crear casos de prueba para comprobar que se puede operar
en el sistema de forma adecuada.

E) CONSIDERACIONES ESPECIALES: Ninguna
4.9. PRUEBA DE CAMPO

Correr el sistema en el ambiente real para encontrar errores y validar el
producto contra sus especificaciones originales.
Realizar un subconjunto vlido de pruebas de sistema.
C) TECNICA:
Determinar que pruebas de sistema sern corridas para validar el sistema en
produccin.
5. PRUEBAS DE VALIDACIONES A APLICACIONES GENRICAS

5.1. PRUEBAS ALFA
Prueba de aceptacin para detectar errores en el sistema bajo un ambiente
controlado.
La verificacin involucra la ejecucin de partes o todo del sistema en
ambientes simulados, con el fin de encontrar errores.
La retroalimentacin de esta fase produce cambios en el software para
resolver los errores y fallas que se descubren.
C) TCNICA:
Realizar las pruebas de sistema bajo las siguientes caractersticas:
se llevan a cabo en el lugar en donde fue desarrollado el sw,

en un ambiente controlado, en el cual el desarrollador est presente.

Se selecciona un grupo de usuarios para el alpha test y se les pide trabajen
con el sistema como parte de las pruebas.
D) CRITERIOS DE COMPLETITUD
5.2. PRUEBAS BETA

Realizar la validacin del sistema por parte del usuario.
Prueba de aceptacin donde La validacin (o pruebas beta) involucra el uso
del software en un ambiente real.
C) TECNICA:
Se selecciona un grupo de usuarios que ponen a trabajar el sistema en un
ambiente real. Usan el sistema en sus actividades cotidianas, procesan
transacciones y producen salidas normales del sistema.
Las transacciones y personas que usan el sistema son reales y trabajan en
su rea de trabajo real.
El desarrollador no esta presente.
Los usuarios estn advertidos de que estn usando un sistema que puede
fallar.
Los usuarios realizan pruebas a su antojo realizando uso de la aplicacin.
Se establece un periodo de pruebas beta en el que los errores detectados no
sean de carcter crtico para el sistema
Se deben considerar mecanismos de comunicacin entre los desarrolladores
y los usuarios de manera que los errores detectados puedan ser corregidos.
6. DISEO DE CAOSOS DE PREBA ( VALORES INTERESANTES)

Para disear correctamente los casos de prueba, stos debern usar valores
interesantes
Se considera un valor interesante aquel que permita recorrer la mayor cantidad
posible de cdigo fuente
En funcin del criterio de cobertura elegido
7. OBTENCIN DE VALORES INTERESANTES:

Para un ejemplo real, el conjunto de valores a probar para conseguir cobertura total
de sentencias puede ser muy grande
Para proponer valores podemos ayudarnos de tcnicas como:
7.1. CLASES DE EQUIVALENCIA:

Dividir el dominio de entrada en clases de equivalencia con valores que
provocan un mismo comportamiento.
7.2. VALORES DE LIMITE:

Qu conjuntos de tres valores recorrentodas las sentencias del mtodo
getTipo()?

8. CRITERIOS DE COBERTURA PARA VALORES INTERESANTES:
Grado en que los diferentes valores interesantes

seleccionados se utilizan en la batera de casos de prueba:
1-wise:
Se satisface cuando cada valor interesante de cada parmetro se incluye al
menos en un caso de prueba
2-wise:
Se satisface cuando cada par de valores interesantes se incluye al menos en
un caso de prueba

CONSIDERACIONES
Identificar cada caso de prueba y asociarlo explcitamente con la clase a
probar
Declarar el propsito de la prueba
Desarrollar una lista de pasos a seguir
Declarar una lista de estados del objeto a probar
Lista de mensajes y operaciones que se ejecutarn
Lista de excepciones que pueden ocurrir
Lista de externas necesarias para 1.80
9. DOCUMENTO DISEO DE PRUEBAS:

Realizar la definicin de: escenarios, eventos, casos de pruebas y matriz de
trazabilidad de las pruebas en el documento de diseo de pruebas. Documento diseo.
En esa seccin se debe incluir la referencia al documento.
A continuacin, se describen los campos que se deben ingresar en cada una de las
hojas del documento de diseo.
9.1. ESCENARIOS DE PRUEBAS:
No. Escenario Escenario Descripcin
Descripcin y objetivo del escenario.

Identificador de
Nombre de escenario Incluir los actores que
escenario
interactan en los escenarios.
9.2. EVENTOS DE PRUEBAS:
No. Evento Escenario Evento Descripcin
Identificador de Descripcin y objetivo del

Nombre del evento 1
evento 1 evento 1.
Nombre de
escenario
Identificador de Descripcin y objetivo del
Nombre del evento 2
evento 2 evento 2.

9.3. CASOS DE PRUEBAS
Nombre significativo del caso de prueba que permita

Caso de prueba
identificar el propsito de la prueba.
Identificador nico del caso de prueba.
Se recomienda que inicie la nomenclatura del nombre:

Identificador CPNNNN_NombreCasoDePrueba. Donde CP corresponde a las
caso de prueba siglas de casos de prueba, NNNN corresponde a la numeracin
nica del caso de prueba y el NombeCasoDePrueba corresponde
al nombre significativo asignado en el campo caso de prueba.
Definir el modulo, servicio o funcin que probara con el caso

Funcin probar
de prueba.
Describir que funcionalidad que ser probada con el caso de

Objetivo
prueba.
Descripcin Describir y explicar el propsito el caso de prueba.
Criterios de Definir los criterios de aceptacin, que permiten determinar

xito que el caso de prueba ejecutado es exitoso
Criterios de Definir los criterios que permiten determinar que el caso de

falla prueba ejecutado es fallido
Describir las condiciones y el estado en las que se debe

encontrar el sistema para la ejecucin del caso de prueba, en caso
Precondiciones
de ser necesario incluir los casos de pruebas que se deben
ejecutar previo al caso de prueba.
Perfil del Perfil del usuario en el sistema con el que se ejecutara la

usuario prueba.
Necesidades Definir las necesidades para la ejecucin de los casos de

para el caso de pruebas, como por ejemplo los datos de pruebas, las condiciones
prueba adicionales a tener en cuenta, configuracin de la prueba.
Autor Nombre de la persona que disea el caso de prueba
Fecha de
Fecha en la que se disea el caso de prueba
creacin

Otro
Id Req Regl Requ Doc
Casos de documento
Condicin de uerimient a de erimiento umento
pruebas
prueba o negocio anterior tcnico
Incluir el
Incluir los
identificador Desc Desc Desc Desc
identificadores Describi
de la ribir la ribir la ribir la ribir la
de los casos de r la ubicacin
condicin de ubicacin ubicacin ubicacin ubicacin
prueba
prueba
No
Usuario del sistema Sistema
paso
Accin del usuario en el

sistema, definir las entradas
Orden Respuesta
requeridas en el paso y que
Flujo del caso en el que se realiza el usuario durante el del sistema a la
de prueba ejecuta el accin realizada
paso, en caso que presente
paso por el usuario
entradas, describir que hace el
usuario con las entradas.
Post Describir el estado del sistema luego de la ejecucin de caso

condiciones de prueba.

9.4. MATRIZ DE TRAZABILIDAD DE PRUEBAS:
9.5. EJECUCION DE PRUEBAS DE SOFTWARE:
Es el periodo de tiempo en el ciclo de vida de desarrollo software, durante el cual

los componentes de un producto software son ejecutados y el producto software
es evaluado para determinar si los requisitos han sido satisfechos.
En esta parte de ejecucin de proyectos de desarrollo de software suele ser el ms
importante y es un momento en el que hay varios que estn pendientes sobre la
calidad del software.
Se realiza principalmente para dar a conocer a las reas de pruebas, desarrollo,

funcionales y rea de negocio cual es la situacin de las pruebas (que fallos han
sido reconocidos y cuales faltan por analizar).

Lo ms recomendable antes de empezar es hacer un test de clasificacin de la

versin (qualification testing) para evaluar que la aplicacin es lo
suficientemente estable para comenzar la ejecucin de las pruebas. De nada
sirve comenzar una ronda de test si al cabo de cinco golpes de ratn la
aplicacin rompe. Tiene que tener un mnimo de estabilidad.
9.6. PROCESO DE UNA EJECUCION FORMAL:

Comnmente se piensa que realizar la ejecucin de pruebas de software es
simplemente probar el software realizando una serie de casos al azar para luego
hacer un reporte sobre posibles errores, sin embargo, para productos de
complejidad media en adelante, lo recomendable es implementar de manera
formal una metodologa de pruebas.
Mayormente se implementa los siguientes pasos:

1) PLANEACION DE PRUEBAS:
Tiene como base presentar un documento para describir el proceso y estrategias a tratar
durante el desarrollo de las pruebas llamado el TEST PLAN.
Alcance de la prueba:
Determina que funcionalidades del producto y/o software sern probadas durante el
transcurso de la prueba. Que funcionalidades y que tanto se le debe dar importancia se
conoce gracias a un anlisis de riesgos realizado de manera previa, que tienen en cuenta
variables tales como el impacto que podra ocasionar la falla de una funcionalidad y la
probabilidad de falla de una funcionalidad.
Tipos de Prueba:
Como es de esperarse no todos los procesos son iguales lo cual implica que las pruebas
no van a ser las mismas a usar, en este caso interviene el lder de ejecucin que se
encarga de plantear preguntas para llegar a determinar los tipos de prueba a usar. Los
posibles tipos de prueba a aplicar son: pruebas de stress, pruebas de rendimiento,
pruebas de carga, pruebas funcionales, pruebas de usabilidad, pruebas de regresin,
entre otros.
Criterios de Salida:
Entre las partes involucradas en el proceso, se define de manera formal, bajo qu

condiciones se puede considerar que una actividad de pruebas fue finalizada. Los
criterios de salida se deben definir para cada nivel de pruebas a ejecutar. Algunos
ejemplos de criterios de salida que pueden ser utilizados son: porcentaje de
funcionalidades de alto riesgo probadas con xito, nmero defectos crticos y/o mayores
aceptados, etc
2) DISEO DE PRUEBAS
Una vez elaborado y aprobado el plan de pruebas, el equipo de trabajo debe iniciar el
anlisis de toda la documentacin, con el objetivo de idear los casos de prueba. Los
puntos importantes para iniciar este diseo pueden ser: casos de uso, historias de
usuario, arquitectura del sistema, diseos, manuales de usuario, manuales tcnicos,
etc. Al momento de hacer un diseo se debe tener en cuenta casos positivos y
negativos. Los casos de prueba negativos permiten validar cmo se comporta el
sistema ante situaciones atpicas y permite verificar la robustez del sistema, atributo

que constituye uno de los requerimientos no funcionales indispensable para

cualquier software.
3) IMPLEMENTACIN DE PRUEBAS:
Este proceso debe comenzar con reconocer datos de prueba con los cuales poder
ejecutar los casos de prueba diseados. La ejecucin de estos casos, puede realizarse
de manera manual o automatizada. Cuando se detecte un fallo en el sistema, este
debe ser documentado y registrado en una herramienta que permita gestionar los
defectos (Bug Tracker).
Una vez el defecto ha sido corregido por la firma desarrolladora en su respectivo
proceso de depuracin, es necesario realizar un re-test que permita confirmar que el
defecto fue solucionado de manera exitosa. Por ltimo, es indispensable ejecutar un
ciclo de regresin que nos permita garantizar, que los defectos corregidos en el proceso
de depuracin de la firma, no hayan desencadenado otros tipos de defectos en el
sistema.
4) EVALUACION DE CRITERIOS DE SALIDA:

Los criterios de salida son imprescindibles para poder identificar cuando un proceso
o un ciclo de prueba son aceptados. Para esto, es conveniente definir una serie de
mtricas que permitirn al finalizar un proceso de pruebas, comparar los resultados
obtenidos contra las mtricas definidas, s los resultados obtenidos no superan la
mtricas definidas, no es posible continuar con el siguiente ciclo de pruebas.
5) CIERRE DEL PROCESO:

Durante este periodo se deben cerrar las incidencias reportadas, se debe verificar si
los entregables planeados han sido entregados y aprobados en los cuales estn los
reportes de error y xito de las pruebas realizadas, se deben finalizar y aprobar los
documentos de soporte de prueba.

10. EJEMPLOS DE EJECUCION DE PRUEBAS:
11. BIBLIOGRAFA:
https://sg.com.mx/content/view/508
https://www.ecured.cu/Pruebas_de_software
https://www.uv.mx/personal/jfernandez/files/2010/07/Cap1-Significado.pdf
https://analidiseorienobjet.wikispaces.com/file/view/pruebas+de+software.pdf
http://www.scielo.org.co/pdf/rfing/v24n39/v24n39a04.pdf
http://www.softqanetwork.com/software-testing-life-cycle
http://www.pmoinformatica.com/2015/06/modelo-informe-pruebas-software.html
https://pruebasdelsoftware.wordpress.com/tag/ejecucion-de-pruebas/

Prueba de Sofware 1

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Prueba de Sofware 1

Uploaded by

Copyright:

Available Formats

UNIVERSIDAD NACIONAL DE TRUJILLO

ESCUELA ACADMICO PROFESIONAL DE

"AO DE LA CONSOLIDACIN DEL MAR DE GRAU"

Mg. Vidal Melgarejo, Zoraida Yanet

Aranda Carranza Jean Piero

Garca Hiplito, Irvin Luis Alonso

Ruiz Obando, Ronald Alexander

Sucre Gamboa, Carlos Andrs

Vargas Ros, Junior Edward

PRUEBAS DE SOFWARE - 2017-0 Pgina 2 de 48

2.2. VALIDACIN: ............................................................................................................ 6

2.3. PRUEBAS (TEST): ..................................................................................................... 6

2.4. CASO DE PRUEBA (TEST CASE) ........................................................................... 7

2.5. DEFECTO ( DEFECT FAULF BUG):.................................................................... 7

2.6. FALLO (FAILURE): .................................................................................................... 7

2.7. ERROR (ERROR): ..................................................................................................... 7

2.8. IDEAS PARADOJICAS DE LAS PRUEBAS: ........................................................... 8

2.9. RECOMENDACIONES PARA UNAS PRUEBAS EXITOSAS: ............................... 8

2.10. PROCESO DE PRUEBAS SOFWARE: ................................................................. 9

3. PRUEBAS DE SISTEMA .................................................................................................12

3.3. PRUEBAS DE REGRESIN: ...................................................................................14

3.4. PRUEBA DE HUMO ( SMOKE TESTING O AD HOC ) ........................................15

3.5. PRUEBAS DE SISTEMA: .........................................................................................16

3.6. PRUEBAS DE DESEMPEO: ..................................................................................18

3.7. PRUEBA DE CARGA: ...................................................................................................19

3.8. PRUEBA DE STRESS....................................................................................................19

3.9. PRUEBAS DE VOLUMEN .............................................................................................21

PRUEBAS DE SOFWARE - 2017-0 Pgina 3 de 48

3.10 PRUEBAS DE RECUPERACION Y TOLERANCIA A FALLAS ...................................23

3.11. PRUEBA DE MULTIPLES SITIOS: .............................................................................25

3.12. PRUEBA DE COMPATIBILIDAD Y CONVERSION: ..................................................26

3.13. PRUEBAS DE INTEGRIDAD DE DATOS Y BASE DE DATOS ...............................27

3.14. PRUEBAS DE SEGURIDAD Y CONTROL DE ACCESO ..........................................27

4. PRUEBAS DE VALIDACION A SISTEMAS A LA MEDIDA: .......................................30

4.2. PRUEBA DE GUIA: ...................................................................................................31

4.3. PRUEBAS DE ESTILO .............................................................................................31

4.4. PRUEBAS DE ACEPTACION ..................................................................................32

4.5. PRUEBAS DE INSTALACION .................................................................................33

4.7. PRUEBAS DE DOCUMENTACION Y PROCEDIMIENTO ....................................35

4.8. PRUEBA DE USABILIDAD ......................................................................................36

4.9. PRUEBA DE CAMPO................................................................................................37

5. PRUEBAS DE VALIDACIONES A APLICACIONES GENRICAS .............................37

6. DISEO DE CAOSOS DE PREBA ( VALORES INTERESANTES).............................38

9.2. EVENTOS DE PRUEBAS: ........................................................................................41

9.3. CASOS DE PRUEBAS ..............................................................................................42

9.4. MATRIZ DE TRAZABILIDAD DE PRUEBAS: .......................................................44

9.5. EJECUCION DE PRUEBAS DE SOFTWARE: .......................................................44

9.6. PROCESO DE UNA EJECUCION FORMAL: .........................................................45

10. EJEMPLOS DE EJECUCION DE PRUEBAS: ...........................................................48

PRUEBAS DE SOFWARE - 2017-0 Pgina 4 de 48

En la actualidad, las empresas , por lo general, no acostumbran a llevar procesos de

La prueba de Software es un proceso que se realiza por diversos motivos,

Este proceso puede realizarse de manera sencilla e informal o de modo muy

En su sencillez, el proceso descrito deja una serie de interrogantes:

En este captulo se detallar y definir el proceso descrito y se buscar respuesta a los

PRUEBAS DE SOFWARE - 2017-0 Pgina 5 de 48

2.3. PRUEBAS (TEST):

PRUEBAS DE SOFWARE - 2017-0 Pgina 6 de 48

2.4. CASO DE PRUEBA (TEST CASE)

Un conjunto de entradas, condiciones de ejecucin y resultados esperados

2.5. DEFECTO ( DEFECT FAULF BUG):

2.6. FALLO (FAILURE):

2.7. ERROR (ERROR):

Tiene varias excepciones: