You are on page 1of 48

UNIVERSIDAD NACIONAL DE TRUJILLO

ESCUELA ACADÉMICO PROFESIONAL DE
INGENERÍA DE SISTEMAS

PRUEBAS DE SOFWARE

2017

UNIVERSIDAD NACIONAL DE TRUJILLO
TECNOLOGÍA DE LA PROMAGACIÓN II

"AÑO DE LA CONSOLIDACIÓN DEL MAR DE GRAU"

TEMA:

Pruebas de Software

DOCENTE:

Mg. Vidal Melgarejo, Zoraida Yanet

CURSO:
Tecnología de La Programación II

ALUMNO:

 Aranda Carranza Jean Piero

 García Hipólito, Irvin Luis Alonso

 Ruiz Obando, Ronald Alexander

 Sucre Gamboa, Carlos Andrés

 Vargas Ríos, Junior Edward

CICLO:

V

PRUEBAS DE SOFWARE - 2017-0 Página 2 de 48

UNIVERSIDAD NACIONAL DE TRUJILLO
TECNOLOGÍA DE LA PROMAGACIÓN II

PRUEBAS DE SOFWARE
Contenido

1. INTRODUCCIÓN:.............................................................................................................. 5
2. DEFINICIONES ASOCIADAS:......................................................................................... 6
2.1. VERIFICACIÓN: Es el proceso de evaluación 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. VALIDACIÓN: ............................................................................................................ 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 REGRESIÓN: ...................................................................................14

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

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

3.6. PRUEBAS DE DESEMPEÑO: ..................................................................................18

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

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

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

PRUEBAS DE SOFWARE - 2017-0 Página 3 de 48

UNIVERSIDAD NACIONAL DE TRUJILLO
TECNOLOGÍA DE LA PROMAGACIÓN II

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 GENÉRICAS .............................37
5.2. PRUEBAS BETA .......................................................................................................38

6. DISEÑO DE CAOSOS DE PREBA ( VALORES INTERESANTES).............................38
7. OBTENCIÓN DE VALORES INTERESANTES: ............................................................39
9. DOCUMENTO DISEÑO 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. BIBLIOGRAFÍA: ...........................................................................................................48

PRUEBAS DE SOFWARE - 2017-0 Página 4 de 48

UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II 1. Este proceso puede realizarse de manera sencilla e informal o de modo muy riguroso y elaborado. que es de tipo experimental. si esta resulta la esperada o al menos resulta aceptable. no plantean cómo llegar a realizarlas. pero siempre bajo el mismo principio. pero que se reduce a unos cuantos pasos: se ejecuta el programa (o parte del mismo) en ciertas condiciones. el Proceso de Mejoramiento de Pruebas (TPI) y el Enfoque de Gestión de Pruebas (TMAP). En su sencillez. INTRODUCCIÓN: En la actualidad. el proceso descrito deja una serie de interrogantes:  ¿Por qué lo hacemos?  ¿Para qué sirve?  ¿Cómo determinar las condiciones y entradas adecuadas?  ¿Cómo saber que la respuesta obtenida es correcta?  ¿Cuántas veces debe repetirse o cómo saber cuándo parar? Y  ¿Debe aceptarse un producto después de cierto número de intentos? En este capítulo se detallará y definirá el proceso descrito y se buscará respuesta a los interrogantes. por lo general. En cierto momento se da por concluido el proceso y se toma una decisión: aceptar el producto como razonablemente bueno o rechazarlo. aplicando un conjunto de valores a sus entradas y se observa su respuesta. conscientemente o de manera casual. no acostumbran a llevar procesos de prueba formales en el desarrollo de productos de software. La prueba de Software es un proceso que se realiza por diversos motivos. como el Modelo de Madurez de Pruebas Integrado (TMMI). PRUEBAS DE SOFWARE . la razón principal de esta falencia radica en que estos modelos plantean cómo mejorar el proceso de pruebas a través del cumplimiento de objetivos y prácticas específicas. las empresas .2017-0 Página 5 de 48 . entonces se repite con otros valores o otras condiciones. a pesar de la existencia de un sinnúmero de modelos especializados. regresándolo a revisión. sin embargo.

PRUEBAS DE SOFWARE . VERIFICACIÓN: Es el proceso de evaluación 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. DEFINICIONES ASOCIADAS: 2.3.2. VALIDACIÓN: El proceso de evaluación 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. PRUEBAS (TEST): “Una actividad en la cual un sistema o uno de sus componentes se ejecuta en circunstancias previamente especificadas. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II 2. 2. los resultados se observan y registran y se realizan una evaluación de algún aspecto”.1. 2.2017-0 Página 6 de 48 .

4. un proceso.2017-0 Página 7 de 48 . PRUEBAS DE SOFWARE .  Una acción humaba que conduce a un resultado incorrecto (Error). 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. por ejemplo. CASO DE PRUEBA (TEST CASE) Un conjunto de entradas. ERROR (ERROR): Tiene varias excepciones:  La diferencia entre un valor calculado. especificado o teóricamente correcto (Fallo). UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II 2. una definición de datos o un paso de procesamiento incorrectos en un programa. 2.6. 2. 2.5. DEFECTO ( DEFECT FAULF “BUG”): Un defecto en el software como. condiciones de ejecución y resultados esperados desarrollados para un objetivo particular.  Un defecto (Defecto).7. observado o medido y el valor verdadero.  Un resultado Incorrecto (Fallo).

RECOMENDACIONES PARA UNAS PRUEBAS EXITOSAS: Cada casi de prueba debe definir el resultado de salida esperado que se comparará con el realmente obtenido.2017-0 Página 8 de 48 . Al generar casos de 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. así. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II 2. se deben incluir tanto datos de entrada válidos y esperados como no válidos e inesperados. ya que desea (consciente o inconscientemente) demostrar que funcionan sin problema. Además. PRUEBAS DE SOFWARE . 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 programador debe evitar probar sus propios programas.  El objetivo de las pruebas es la detección de defectos en el software (descubrir un error es el éxito de una prueba). es normal que las situaciones que olvido considerar al crear el programa queden de nuevo olvidados al crear los casos de prueba. 2. Se debe inspeccionar a conciencia el resultado de cada prueba.8. poder descubrir posibles síntomas de defectos.9.

10. que puede realizarse de diversas maneras: en una forma secuencial tradicional o de alguna manera iterativa. El esquema de la Figura 2 es muy general. llamada verificación. La comprobación de que el software cumple lo que se espera de él tiene dos variantes. En cualquiera de ellas existe la actividad de prueba. cumpliendo las especificaciones que se fijaron al inicio. si provoca efectos secundarios adversos. No deben hacerse planes de prueba suponiendo que. es decir.2017-0 Página 9 de 48 . Si se sigue el proceso secuencial tradicional. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II Las pruebas deben centrar en dos objetivos (es habitual olvidar el segundo):  Probar si el software no hace lo que debe hacer. Sin embargo. no hay defectos en los programas y. le resuelve su problema. el asegurarse que el software satisface las necesidades del cliente. dedicando pocos recursos a las pruebas Siempre hay defectos. prácticamente. siempre propensa a cometer equivocaciones. el uso principal se da dentro del proceso de desarrollo de software. Hasta aquí hemos hablado de pruebas como de algo normal. a lo que se denomina validación. los no documentados ni diseñados con cuidado. Las pruebas deben asegurarse PRUEBAS DE SOFWARE . Por otra parte. PROCESO DE PRUEBAS SOFWARE: El proceso de pruebas del software se puede realizar en diversos momentos y por diferentes causas. 2. Se puede descomponer como se muestra en la Figura 2.  Ya que suele ser necesario probar muchas veces el software y por tanto hay que tener claro que funciona y que no. las pruebas se realizan en las etapas finales del desarrollo. con poca labor de preparación inicial. es decir.  Probar si el software hace lo que debe hacer. donde ambas son necesarias: La comprobación de que el software se realizó correctamente. Se deben evitar los casos desechables. por lo tanto. pero. ¿por qué haces pruebas? La principal justificación está en la naturaleza humana. es decir.

b entonces hay que probar con los valores a -1. b . UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II que cada parte funciones bien que las partes se combinen en subsistemas de manera eficaz y que el conjunto total opere correctamente.  Si la entrada es un conjunto de valores entonces hay que probar con los valores max-1. max.  Prueba de los valores limite  Los errores suelen situarse en los límites. b) Nivel de Integración: Analizan la interacción de las partes. a. PRUEBAS DE SOFWARE .  Si la entrada se encuentra en el rango a. c) Nivel de Sistemas: Analizan al sistema Completo. a + 1. b y b + 1..2017-0 Página 10 de 48 . min-1.1. Se identifican tres niveles de prueba: a) Nivel de Unidad: Orientada a las partes aisladas. min y min+1. max+1.

que empiece por 9 y la contraseña que sea una cadena de hasta 6 caracteres que empiece necesariamente por una letra y que puede contener letras. la primera un prefijo opcional de 3 dígitos. dígitos y el símbolo $ PREFIJO CONTRASEÑA  Se pueden diseñar casos de prueba.2017-0 Página 11 de 48 . PRUEBAS DE SOFWARE . UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II  Prueba de la partición equivalente  Método 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 código formado por 2 partes. cada uno de los cuales representa a un conjunto de casos de prueba.

UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II Pruebas en entornos y aplicaciones especializadas  Pruebas sobre ventanas. Busca asegurar que el código funciona de acuerdo con las especificaciones y que el módulo lógico es válido. ej = una clase) lo que provee un mejor modo de manejar la integración de las unidades en componentes mayores. Ejemplo Al cerrar(minimizar) la ventana se cierra ( minimiza) Al pulsar el botón.1. PRUEBAS DE SISTEMA 3. aparece en el campo de texto el resultado Buscar ayuda de como utilizar la interfaz 3.  Pruebas de documentación y de ayuda. PRUEBAS UNITARIAS: A) OBJETOS DE LA PRUEBA: Se focaliza en ejecutar cada módulo (o unidad minima a ser probada. PRUEBAS DE SOFWARE .2017-0 Página 12 de 48 .  Pruebas de entrada de datos.  Pruebas sobre menús y uso del ratón.

PRUEBAS DE SOFWARE . el diseñador debe construirlos con acceso al código fuente de la unidad a probar.  Por cada unidad hay que definir los casos de prueba (pruebas de caja blanca).2017-0 Página 13 de 48 . E) CONSIDERACIONES ESPERCIALES: Para la elaboración de pruebas unitarias en java se puede utilizar el JUNIT y CACTUS.  Para esto los casos de prueba deben diseñarse de forma tal que se recorran todos los caminos de ejecución posibles dentro del código bajo prueba. Validaciones. Rangos. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II B) DESCRIPCION DE LA PRUEBA:  Particionar los módulos en pruebas en unidades lógicas fáciles de probar.  Determina cómo la base de datos de prueba será cargada.2. Rutinas de error.  Todos los defectos que se identificaron han sido tenidos en cuenta. Valores límites. Mensajes posibles. PRUEBAS DE INTEGRACIÓN: A) OBJETOS DE LA PRUEBA:  Identificar errores introducidos por la combinación de programas probados unitariamente. 3.  Verificar que las interfaces entre las entidades externas (usuarios) y las aplicaciones funcionan correctamente. Manejo de parámetros. C) TÉCNICA:  Comparar el resultado esperado con el resultado obtenido. por lo tanto.  Si existen errores. Valores válidos.  Los aspectos a considerar son los siguientes: Rutinas de excepción.  Verificar que las especificaciones de diseño sean alcanzadas. reportarlos D) CRITERIOS DE COMPLETITUD:  Todas las pruebas planeadas han sido ejecutadas.

mantenimiento o desarrollo de la nueva versión del sistema buscando efectos adversos en otras partes. E) CONSIDERAIONES ESPECIALES: Ninguna 3. PRUEBAS DE SOFWARE .  Utilizar la técnica down-top. con los parámetros correctos. B) DESCRIPCION DE LA PRUEBA: En esta prueba se vuelve a probar el sistema a la luz de los cambios realizados durante el debugging. con los parámetros correctos. PRUEBAS DE REGRESIÓN: A) OBJETIVO DE PRUEBA: Determinar si los cambios recientes en una parte de la aplicación tienen efecto adverso en otras partes.3.  Determina el enfoque para avanzar desde un nivel de integración de las componentes al siguiente.  Todos los defectos que se identificaron han sido tenidos en cuenta. Se empieza con los módulos de nivel inferior. y se verifica que los módulos de nivel superior llaman a los de nivel inferior de manera correcta. Se empieza con los módulos de nivel superior.2017-0 Página 14 de 48 .  Decide qué acciones tomar cuando se descubren problemas C) TECNICAS:  Utilizar la técnica top-down. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II B) DESCRIPCION DE LA PRUEBA:  Describe cómo verificar que las interfaces entre las componentes de software funcionan correctamente. D) CRITERIOS DE COMPLEJIDAD:  Todas las pruebas planeadas han sido ejecutadas. y se verifica que los módulos de nivel inferior llaman a los de nivel superior de manera correcta.  Determina cómo la base de datos de prueba será cargada.

Permite detectar problemas que por lo regular no son detectados en las pruebas normales. Las pruebas de humo NO SON exhaustivas. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II C) TÉCNICA:  La prueba de regresión es una nueva corrida de casos de prueba previos.4. Desde que estas pruebas se repiten una y otra vez. B) DESCRIPCIÓN DE LA PRUEBA: Toma éste nombre debido a que su objetivo es probar el sistema constantemente buscando que saque “humo” o falle.  Todos los defectos que se identificaron han sido tenidos en cuenta.  Aquellos casos de uso (y los casos de prueba asociados) que descubren defectos tempranamente deben ser incluidos en la prueba de regresión. 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 fácil  Probar el sistema constantemente  Garantizar poco esfuerzo en la integración final del sistema  Asegurar los resultados de las pruebas unitarias  Se reducen los riesgos y a baja calidad. D) CRITERIO DE COMPLEJIDAD:  Todas las pruebas planeadas han sido ejecutadas.  La prueba de regresión es un buen candidato para automatización. pero van de extremo a extremo de la aplicación PRUEBAS DE SOFWARE .2017-0 Página 15 de 48 .  La prueba de viejas funcionalidades es más importante que la de nuevas funcionalidades. En algunos proyectos este tipo de prueba va junto con las pruebas funcionales. Algunas veces. si las Pruebas ocurren tarde en el ciclo de desarrollo está será una forma de garantizar el buen desarrollo. las herramientas para minimizar el esfuerzo del trabajo son útiles. E) CONSIDERACIONES ESPERCIALES: NINGUNA 3. para probar eficientemente.  Se requiere de políticas para ser creada la prueba de regresión y decidir qué casos de prueba incluir.

Es útil el uso de programas de prueba automáticas que se encarguen de probar os casos de prueba ya ejecutados en realeases anteriores. volumen. La prueba de Sistema incluye: PRUEBAS DE SOFWARE .) asegurarán que la aplicación alcanzará sus objetivos de negocio. y la implementación apropiada de las reglas de negocios. se detiente el desarrollo hasta que el error es corregido. 3. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II C) TÉCNICA:  Realizar una integración de todo el sistema cada cierto periodo (se recomienda un día. En esta prueba se determina qué pruebas de Sistema (usabilidad.5. El objetivo de estas pruebas es verificar el ingreso. máximo una semana)  Realizar los casos de prueba asignados a los casos de uso finalizados ese día más los realizados en días anteriores  Buscar eficientemente errores D) CRITERIOS DE COMPLETITUD: Todas las pruebas planeadas han sido ejecutadas. verificar el sistema (y sus procesos internos). Este tipo de pruebas es útil en la programación extrema (extremme programming) y de sistemas complejos. Este tipo de pruebas se basan en técnicas de caja negra. desempeño. la interacción con las aplicaciones que lo usan via GUI y analizar las salidas o resultados. E) CONSIDERACIONES ESPECIALES: Cuando se encuentre un error en el release correspondiente al periodo elegido para hacer las integraciones del sistema. Todos los defectos que se identifcaron han sido tenidos en cuenta. procesamiento y recuperación apropiado de datos. PRUEBAS DE SISTEMA: A) OBJETIVO DE PRUEBA: Asegurar la apropiada navegación dentro del sistema.2017-0 Página 16 de 48 . B) DESCRIPCION DE LA PRUEBA: Las pruebas del sistema deben enfocarse en requisitos que puedan ser tomados directamente de casos de uso y reglas y funciones de negocios. procesamiento y recuperación. ésto es. ingreso de datos. etc.

 Todos los defectos que se identificaron han sido tenidos en cuenta. flujo básico o función utilizando datos válidos e inválidos.2017-0 Página 17 de 48 . los casos de prueba de las pruebas previas realizadas pueden frecuentemente ser reorganizados y rehusados durante la prueba de sistema. a diferencia de otras pruebas que sólo se centran en uno o dos aspectos del sistema al mismo tiempo. La prueba de sistema es compleja porque intenta validar un número de características al mismo tiempo. para verificar que:  Los resultados esperados ocurren cuando se utiliza un dato válido. No obstante. cuando se utiliza un dato inválido. PRUEBAS DE SOFWARE .  Los mensajes de error o de advertencia aparecen en el momento adecuado. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II Prueba funcionalidad Prueba de Usabilidad Prueba de Performance Prueba de Documentación y Procedimientos Prueba de Seguridad y Controles Prueba de Volumen Prueba de Esfuerzo (Stress) Prueba de recuperación Prueba de múltiples sitios Para sistemas web se recomienda especialmente realizar mínimo el siguiente grupo de pruebas de sistema: • Humo.  Cada regla de negocios es aplicada adecuadamente. deben ser desarrollados casos de prueba adicionales para aquellos aspectos del sistema. C) TÉCNICA: Ejecute cada caso de uso. tales como documentación. procedimientos y desempeño que no han sido probados durante la prueba unitaria y de integración. • Usabilidad • Performance • Funcionalidad Para capitalizar el trabajo hasta ahora completado. D) CRITERIOS DE COMPLETITUD:  Todas las pruebas planeadas han sido ejecutadas.

Modifique archivos de datos (para incrementar el número de transacciones o veces que cada transacción ocurre). Adicionalmente. múltiples usuarios. PRUEBAS DE SOFWARE . D) CRITERIOS DE COMPLEJITITUD: Múltiples transacciones. Esto permite control total y medidas precisas. E) CONSIDERACIONES ESPECIALES:  Las pruebas de carga deben ser ejecutadas en una máquina dedicada o en un tiempo dedicado.6. las pruebas de carga evalúan las características de desempeño (tiempos de respuesta. B) DESCRIPCIÓN DE LA PRUEBA: Las pruebas de carga miden la capacidad del sistema para continuar funcionando apropiadamente bajo diferentes condiciones de carga. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II E) CONSIDERACIONES ESPECIALES:  Identifique o describa aquellos aspectos (internos o externos) que impactan la implementación y ejecución de las pruebas del Sistema.·  La Base de datos utilizada para pruebas de desempeño debe ser de un tamaño real o proporcionalmente más grande que la diseñada. PRUEBAS DE DESEMPEÑO: 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 máximo anticipado.2017-0 Página 18 de 48 . C) TÉCNICAS: Use los scripts desarrollados para Pruebas del Negocio. Se completaron las pruebas de los scripts sin ninguna falla y dentro del tiempo esperado. 3. tasas de transacciones y otros aspectos sensibles al tiempo). La meta de las pruebas de carga es determinar y asegurar que el sistema funciona apropiadamente aún más allá de la carga de trabajo máxima esperada.

 Modifique archivos de datos (para incrementar el número de transacciones o veces que cada transacción ocurre).2017-0 Página 19 de 48 . 3. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II 3. múltiples usuarios. PRUEBA DE STRESS PRUEBAS DE SOFWARE . E) CONSIDERACIONES ESPECIALES: •Las pruebas de carga deben ser ejecutadas en una máquina dedicada o en un tiempo dedicado. tasas de transacciones y otros aspectos sensibles al tiempo). Esto permite control total y medidas precisas· •La Base de datos utilizada para pruebas de desempeño debe ser de un tamaño real o proporcionalmente más grande que la diseñada. Adicionalmente. C) TECNICA:  Use los scripts desarrollados para Pruebas del Negocio. D) CRITERIO DE COMPLETITUD: Múltiples transacciones. Se completaron las pruebas de los scripts sin ninguna falla y dentro del tiempo esperado. La meta de las pruebas de carga es determinar y asegurar que el sistema funciona apropiadamente aún más allá de la carga de trabajo máxima esperada. bajo diferentes condiciones de carga.8. las pruebas de carga evalúan las características de desempeño (tiempos de respuesta. PRUEBA DE CARGA: A) OBJETIVOS DE PRUEBA: Verificar el tiempo de respuesta del sistema para transacciones o casos de uso de negocios.7. B) DESCRIPCION DE LA PRUEBA: Las pruebas de carga miden la capacidad del sistema para continuar funcionando apropiadamente bajo diferentes condiciones de carga.

muchas otras serán en verdad situaciones que nunca ocurrirán en la realidad.2017-0 Página 20 de 48 . •Máximo número de clientes conectados o simulados (actuales o físicamente posibles) •Múltiples usuarios desempeñando la misma transacción con los mismos datos. sin embargo. B) DESCRIPCION DE LA PRUEBA: Las pruebas de stress se proponen encontrar errores debidos a recursos bajos o completitud de recursos. Puesto que la prueba de esfuerzo involucra un elemento de tiempo. Aunque muchas pruebas de esfuerzo representan condiciones que el programa encontrará realmente durante su utilización. No debe confundirse con las pruebas de volumen: un esfuerzo grande es un pico de volumen de datos que se presenta en un corto período de tiempo. NOTAS: La meta de las pruebas de stress también es identificar y documentar las condiciones bajo las cuales el sistema FALLA. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II A) OBJETIVOS DE PRUEBA: Verificar que el sistema funciona apropiadamente y sin errores. El objetivo de esta prueba es investigar el comportamiento del sistema bajo condiciones que sobrecargan sus recursos. por ejemplo. de tiempo real y de control de proceso. a un compilador o a una rutina de pagos. como bloqueos de base de datos o ancho de banda de la red. no resulta aplicable a muchos programas. Es aplicable. a programas que trabajan bajo cargas variables. que estas pruebas no sean útiles. 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. sin embargo. Esto no implica. Las pruebas de stress identifican la carga máxima que el sistema puede manejar. PRUEBAS DE SOFWARE . interactivos. bajo estas condiciones de stress: •Memoria baja o no disponible en el servidor. •El peor caso de volumen de transacciones (ver pruebas de desempeño).

 Sincronización de varios clientes accediendo simultáneamente los mismos registros. E) CONSIDERACIONES ESPECIALES:  Producir stress en la red puede requerir herramientas de red para sobrecargarla de tráfico. todos ejecutando la misma función (peor caso de desempeño) por un período extendido. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II Si se detectan errores durante estas condiciones “imposibles”.  Para las pruebas de stress restantes.  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. (O si las condiciones en que el sistema falle ocurren por fuera de las condiciones especificadas). 3. las pruebas se deben correr en un servidor con configuración reducida (o limitada). ya sea corriendo los mismos scripts o scripts complementarios para producir el peor caso de volumen de transacciones D) CRITERIO DE COMPLETITUD: Todas las pruebas planeadas han sido ejecutadas y excedidas sin que el sistema falle. la prueba es valiosa porque es de esperar que los mismos errores puedan presentarse en situaciones reales. C) TECNICA:  Use los scripts utilizados en las pruebas de desempeño. algo menos exigentes. deben utilizarse múltiples clientes.2017-0 Página 21 de 48 . PRUEBAS DE VOLUMEN A) OBJETIVOS DE PRUEBA: Verificar que la aplicación funciona adecuadamente bajo los siguientes escenarios de volumen: o Máximo (actual o físicamente posible) número de clientes conectados (o simulados).  Para probar recursos limitados. o Máximo tamaño de base de datos (actual o escalado) y múltiples consultas ejecutadas simultáneamente PRUEBAS DE SOFWARE .9.

ya sea corriendo las mismas pruebas o pruebas complementarias para producir el peor caso de volumen (ver pruebas de stress) por un período extendido. Por ejemplo.  Se utiliza un tamaño máximo de Base de datos. C) TECNICA:  Utilice los scripts diseñados para las pruebas de desempeño. (actual.  Algunos ejemplos de escenarios de prueba de volúmenes:  Un compilador puede ser alimentado por un programa para compilar que sea absurdamente grande. al menos. Sin embargo.  Un simulador de circuito electrónico puede recibir un circuito diseñado con miles de componentes. una prueba de volumen podría usar una Base de datos de prueba grande y verificar que el sistema se comporta normalmente y produce el reporte correctamente. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II B) DESCRIPCION DE LA PRUEBA:  Las pruebas de volumen hacen referencia a grandes cantidades de datos para determinar los límites en que se causa que el Sistema falle. escalado o con datos representativos) y múltiples clientes para correr consultas simultáneamente para períodos extendidos. la prueba de volumen es una prueba costosa.  El objetivo de esta prueba es someter al sistema a grandes volúmenes de datos para determinar si el mismo puede manejar el volumen de datos especificado en sus requisitos.  Puesto que obviamente. tanto en tiempo de máquina como en personal. a algunas pruebas de volumen. se debe tratar de no exceder los límites. D) CRITERIO DE COMPLETITUD: PRUEBAS DE SOFWARE .  Deben usarse múltiples clientes. si el sistema está procesando un conjunto de registros de Base de datos para generar un reporte. todo programa debería ser expuesto.  Un editor de nexos puede recibir un programa que contenga miles de módulos. También identifican la carga máxima o volumen que el sistema puede manejar en un período dado.2017-0 Página 22 de 48 .

10 PRUEBAS DE RECUPERACION Y TOLERANCIA A FALLAS A) OBJETIVO DE LA PRUEBA: Verificar que los procesos de recuperación (manual o automática) restauran apropiadamente la Base de datos. Las pruebas de recuperación son contrarias a las pruebas en que la aplicación o sistema es expuesto a condiciones extremas (o condiciones PRUEBAS DE SOFWARE . E) CONSIDERACIONES ESPECIALES:  ¿Qué período de tiempo debería considerarse como aceptable para condiciones de volumen alto? 3. Los siguientes tipos de condiciones deben incluirse en la prueba:  Interrupción de electricidad en el cliente. y los llevan a un estado conocido o deseado.  Interrupción de electricidad en el servidor  Interrupción en la comunicación hacia el servidor (caídas de red)  Interrupción en la comunicación con los controladores de disco. Las pruebas de tolerancia a fallas aseguran que. cuando una condición de falla ocurre. B) DESCRIPCION DE LA PRUEBA: Estas pruebas aseguran que una aplicación o sistema se recupere de una variedad de anomalías de hardware. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II Todas las pruebas planeadas han sido ejecutadas y los límites especificados en el sistema se han conseguido o excedido sin que el sistema falle. los sistemas alternos o de respaldo pueden tomar control del sistema sin pérdida de datos o transacciones.  Ciclos incompletos (procesos de consultas interrumpidos. software o red con pérdidas de datos o fallas de integridad. para aquellos sistemas que deben mantenerse corriendo. procesos de sincronización de datos interrumpidos)  Llaves o apuntadores de base de datos inválidos  Elementos corruptos o inválidos en la base de datos. aplicaciones y sistemas.2017-0 Página 23 de 48 .

se deben invocar los procedimientos de recuperación. y luego.  Una vez se realizan estas acciones. PRUEBAS DE SOFWARE . errores de paridad en memoria. errores en dispositivos de entrada/salida) pueden ser simuladas.  Interrupción de electricidad en el servidor: simular o iniciar procedimientos de pérdida de energía para el servidor. una vez alcanzado el segundo punto de pruebas. Esta prueba evalúa las características de contingencia construidas en el sistema para procesar interrupciones y para volver a puntos específicos en el ciclo de procesamiento del sistema.  Las pruebas para ciclos incompletos utilizan la misma técnica que se describe arriba. C) TECNICA: Se deben utilizar las pruebas creadas para la Funcionalidad del sistema y Procesos de Negocios para crear una serie de transacciones.2017-0 Página 24 de 48 . Las fallas de equipo (por ejemplo. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II simuladas). Una vez se alcanza el punto inicial de las pruebas de recuperación. excepto que los procesos de Base de datos deban ser abortados o terminados prematuramente. Los procesos de recuperación se invocan y la aplicación es monitoreada y/o inspeccionada para verificar que éstos mecanismos se han ejecutado en forma apropiada. Errores de programación o de datos pueden ser incorporados ex profeso en un sistema para determinar si se puede recuperar de ellos. tales como fallas en dispositivos en entrada/salida o llaves o apuntadores inválidos de base de datos. se deben ejecutar series de transacciones. se deben realizar o simular las siguientes acciones:  Interrupción de electricidad en el cliente. El objetivo de esta prueba es determinar la habilidad del sistema para recuperarse de una falla de hardware o software. (desconectar físicamente los cables o apagar los hubs o routers)  Interrupción de la comunicación con los controladores de disco: simular o eliminar físicamente la comunicación con uno o más controladores o dispositivos. La recuperación debe ser considerada en el proceso de diseño.  Interrupción de la comunicación en la red.

B) DESCRIPCION DE LA PRUEBA: El propósito de esta prueba es evaluar el correcto funcionamiento del sistema o subsistema en múltiples instalaciones. y reportes indicando los procesos o transacciones que no fueron completadas debido a las interrupciones producidas. una vez se completan los procedimientos de recuperación. C) TECNICA: Realizar casos de prueba que verifiquen mínimo lo siguiente: PRUEBAS DE SOFWARE . la Base de datos. Los procedimientos para desconectar cables o simular pérdida de electricidad pueden ser poco factibles o deseables.  Se requiere la participación de personal de la red. apuntadores y llaves deben ser modificados manualmente. E) CONSIDERACIONES ESPECIALES: Las pruebas de recuperación pueden llegar a ser molestas. Este estado podría incluir que el daño de datos se limite solamente a los campos. aplicación y otros sistemas deben retornar a un estado conocido y deseado. como herramientas de diagnóstico. valiéndose de las herramientas que ofrezca la SSPD. llaves o apuntadores que se sabe que fueron alterados. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II  Las pruebas para estas condiciones requieren que se llegue a un estado conocido previamente en la Base de datos. D) CRITERIO DE COMPLETITUD: En todos los casos mencionados.  Estas pruebas deben ser ejecutadas en horas no laborables o en máquinas aisladas. administradores de la base de datos y del sistema.2017-0 Página 25 de 48 . Podrían llegar a requerirse métodos alternativos. 3.11. Algunos campos. PRUEBA DE MULTIPLES SITIOS: A) OBJETIVO DE LA PRUEBA: Detectar fallas en configuraciones y comunicaciones de datos entre múltiples sitios. Las transacciones adicionales deben ser ejecutadas utilizando las pruebas para Funcionalidad de la aplicación y para Procesos de Negocios.

los programas tienen a menudo objetivos específicos con respecto a su compatibilidad y a sus procedimientos de conversión con el sistema existente. o sistemas manuales.  Todos los defectos que se identificaron han sido tenidos en cuenta. E) CONSIDERACIONES ESPECIALES: PRUEBAS DE SOFWARE . B) DESCRIPCION DE LA PRUEBA: El propósito es demostrar que los objetivos de compatibilidad no han sido logrados y que los procedimientos de conversión no funcionan. PRUEBA DE COMPATIBILIDAD Y CONVERSION: A) OBJETIVO DE LA PRUEBA: Buscar problemas de compatibilidad y conversión en los sistemas. La mayoría de los programas que se desarrollan no son completamente nuevos.  Consistencia de controles y seguridad a través de los sitios D) CRITERIO DE COMPLETITUD:  Todas las pruebas planeadas han sido ejecutadas.  Todos los defectos que se identificaron han sido tenidos en cuenta. E) CONSIDERACIONES ESPECIALES: Ninguna 3. C) TECNICA: Desarrollar casos de prueba que permitan detectar deficiencias con:  Compatibilidad entre programas  Conversión de datos D) CRITERIO DE COMPLETITUD:  Todas las pruebas planeadas han sido ejecutadas.2017-0 Página 26 de 48 . con frecuencia son reemplazos de partes deficientes. Como tales. ya sea de sistemas de procesamiento de datos. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II  Consistencia de las opciones de configuración para el sistema a través de los sitios  Empaquetamiento del sistema para múltiples instalaciones  Sincronización de datos entre sitios  Comunicación de datos entre sistemas en diferentes sitios  Rompimiento de funciones de sistema a través de los sitios.12.

C) TECNICA:  Invoque cada método de acceso y proceso de la Base de datos.  Analice la Base de datos. utilizando en cada uno datos válidos e inválidos.2017-0 Página 27 de 48 . PRUEBAS DE INTEGRIDAD DE DATOS Y BASE DE DATOS A) OBJETIVO DE LA PRUEBA: Asegurar que los métodos de acceso y procesos funcionan adecuadamente y sin ocasionar corrupción de datos. PRUEBAS DE SEGURIDAD Y CONTROL DE ACCESO A) OBJETIVO DE LA PRUEBA: PRUEBAS DE SOFWARE .13. Se necesita realizar investigación adicional en el DBMS para identificar las herramientas y técnicas que podrían existir para soportar las pruebas identificadas más adelante.  Los procesos pueden ser invocados manualmente. Estos sistemas deberían ser probados sin usar interfaces de usuario (como las interfaces de datos). que todos los eventos de Base de datos se ejecutaron en forma correcta y revise los datos retornados en diferentes consultas.  Se debe utilizar un conjunto pequeño de datos para incrementar la visibilidad de cualquier evento anormal o inesperado. D) CRITERIO DE COMPLETITUD: Todos los métodos de acceso y procesos de la Base de datos funcionan como fueron diseñados y sin corrupción de datos E) CONSIDERACIONES ESPECIALES:  Las pruebas pueden requerir un ambiente de DBMS o controladores para ingresar o modificar datos directamente en la Base de datos. 3. B) DESCRIPCION DE LA PRUEBA: La Base de datos y los procesos de Base de datos deben ser probados como sistemas separados del proyecto. para asegurar que los datos han sido grabados apropiadamente. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II Ninguna 3.14.

Si existe seguridad a nivel de datos. sin embargo. B) DESCRIPCION DE LA PRUEBA: 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. muchos programas tienen objetivos específicos de seguridad. Las pruebas de seguridad de la aplicación garantizan que. la prueba garantiza que un usuario “típico” 1 puede ver toda la información de clientes. el usuario 2 solamente puede ver los datos institucionales del mismo cliente. Debido a la creciente preocupación de la sociedad por la privacidad de la información. 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 través de los mecanismos apropiados. Nivel de Seguridad del Sistema: Verificar que solo los actores con acceso al sistema y a la aplicación están habilitados para accederla. con base en la seguridad deseada. El foco principal es probar la vulnerabilidad del sistema frente a accesos o manipulaciones no autorizadas. Por ejemplo. los usuarios están restringidos a funciones específicas o su acceso está limitado únicamente a los datos que está autorizado a acceder. 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. PRUEBAS DE SOFWARE . cada usuario puede estar autorizado a crear nuevas cuentas. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II Nivel de seguridad de la aplicación: Verifica que un actor solo pueda acceder a las funciones y datos que su usuario tiene permitido. incluyendo datos financieros.2017-0 Página 28 de 48 . pero sólo los administradores pueden borrarlas. 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.

2017-0 Página 29 de 48 . En cada caso. sino como una función de los administradores de red o del sistema.  Acceso al sistema (ver consideraciones especiales) D) CRITERIO DE COMPLETITUD: Para cada tipo de usuario conocido.  Modificar tipos de usuarios y volver a ejecutar las pruebas. C) TECNICA: Funciones / Seguridad de Datos: Identificar cada tipo de usuario y las funciones y datos a los que se debe autorizar. las funciones y datos apropiados y todas las transacciones funcionan como se esperaba. incluyendo aquellos para edición de datos. documentación numerada. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II Algunas consideraciones de prueba son:  Controles de acceso físico  Acceso a estructuras de datos específicas a través de los programas de aplicación. Esta prueba puede no ser requerida como tal. balances y conversión de datos. errores del operador.  Seguridad en sitios remotos  Existencia de datos confidenciales en reportes y pantallas  Controles manuales. entre otros. formularios.  Crear pruebas para cada tipo de usuario y verificar cada permiso. auditoría. acceso a datos elementales y archivos. chequeo de máquinas. verificar si los datos o funciones adicionales quedan correctamente permitidos o denegados. PRUEBAS DE SOFWARE . incluyendo aquellos para autorización y aprobación.  Controles automáticos. E) CONSIDERACIONES ESPECIALES: El acceso al sistema debe ser revisado y discutido con los administradores de la red y/o del sistema. acceso a funciones. creando transacciones específicas para cada tipo de usuario. transmisión de datos.

para verificar que:  Incremente el número de veces en que una función es ejecutada para simular diferentes usuarios sobre un periodo especificado  Todas las fechas o funciones que involucren tiempos serán probadas con datos válidos e inválidos de fechas o periodos de tiempo.  Todas las funciones ocurren en un periodo de tiempo serán ejecutadas en el tiempo apropiado. B) DESCRIPCION DE LA PRUEBA: Las pruebas del ciclo de negocio deberían emular las actividades ejecutadas en el a través del tiempo.  Los resultados esperados ocurren cuando los datos válidos son usados. PRUEBAS DE SOFWARE .  Cada regla de negocios es aplicada adecuadamente. Incluyendo todos los ciclos y eventos diarios.1.  Los mensajes de error o de advertencia aparecen en el momento adecuado.2017-0 Página 30 de 48 . semanales y mensuales que sean datos sensitivos. y las transacciones y actividades que podrían ocurrir durante un periodo de un año deberían ejecutarse. como por ejemplo un año. flujo básico o función utilizando datos válidos e inválidos. como las agendas. Debería identificarse un periodo. PRUEBAS DE VALIDACION A SISTEMAS A LA MEDIDA: 4. PRUEBA DEL CICLO DEL NEGOCIO A) OBJETIVOS DE LA PRUEBA: Asegurar que el sistema funciona de acuerdo con el modelo de negocios emulando todos los eventos en el tiempo y en función del tiempo. C) TÉCNICA: Ejecute cada caso de uso. cuando se utiliza un dato inválido. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II 4.

4. E) CONSIDERACIONES ESPECIALES: NINGUNA 4.2. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II D) CONSIDERACIONES ESPECIALES:  Las fechas y eventos del sistema pueden requerir actividades especiales de soporte. posiciones. B) DESCRIPCIÓN DE LA PRUEBA: La prueba de interfaz de usuario verifica la interacción del usuario con el software. teclas rápidas.  Se requiere un modelo de negocios para identificar requisitos y procedimientos de prueba apropiados. D) CRITERIOS DE COMPLETITUD: Cada ventana elegida será totalmente verificada y comparada con similares en el mercado logrando una buena aceptación dentro del estándar. tales como menús. las pruebas de interfaz aseguran que el objeto de la interfaz a ser probada se encuentra dentro de los estándares de la industria C) TÉCNICA: Pruebas de crear / modificar cada ventana para verificar la adecuada navegación y estado de los objetos. medidas. se realiza una navegación ventana por ventana. PRUEBAS DE ESTILO PRUEBAS DE SOFWARE . El objetivo es asegurar que la interfaz tiene apropiada navegación a través de las diferentes funcionalidades. PRUEBA DE GUIA: A) OBJETIVOS DE LA PRUEBA:  Las navegaciones a través de los objetos de la prueba reflejan las funcionalidades del negocio y requisitos. usando los modos de acceso (tabuladores.3. movimientos del mouse. estados y focos se verifican conforme a los estándares. Adicionalmente. etc)  Los objetos de la ventana y características.2017-0 Página 31 de 48 .

Basado en esta prueba el cliente determina si acepta o rechaza el sistema Estas pruebas están destinadas a probar que el producto está listo para el uso operativo. 4. PRUEBAS DE SOFWARE . UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II A) OBJETIVO DE LA PRUEBA: Comprobar que la aplicación sigue los estándares de estilo propios del cliente. en caso de no existir. hacer un levantamiento preliminar de este con base en la información corporativa existente.4.  Validar objetos gráficos contra el manual de estilos del cliente.2017-0 Página 32 de 48 . B) DESCRIPCION DE LA PRUEBA: Se entienden como tales el formato de las ventanas. C) TÉCNICA:  Se realiza una navegación por la aplicación verificando si se cumplen con los estándares de GUI del cliente. La prueba de aceptación es generalmente desarrollada y ejecutada por el cliente o un especialista de la aplicación y es conducida a determinar como el sistema satisface sus criterios de aceptación validando los requisitos que han sido levantados para el desarrollo. incluyendo a documentación y procesos de negocio. PRUEBAS DE ACEPTACION A) OBJETIVOS DE PRUEBA: Determinación por parte del cliente de la aceptación o rechazo del sistema desarrollado. Suelen ser un subconjunto de las Pruebas de Sistema. B) DESCRIPCION DE LA PRUEBA La prueba de aceptación es ejecutada antes de que la aplicación sea instalada dentro de un ambiente de producción. colores corporativos. D) CRITERIO DE COMPLETITUD:  Todas las pruebas planeadas han sido ejecutadas.  Todos los defectos que se identificaron han sido tenidos en cuenta E) CONSIDERACIONES ESPECIALES: • Solicitar al cliente el manual de estilos. tipos de letra etc.

 Instalar versiones viejas en máquinas previamente instaladas con el sistema. es decir.5.  Manual de administrador. C) TECNICA: Realización de los documentos de planes de prueba de aceptación y especificación de los mismos. Para la realización de estas pruebas se necesita disponer de los siguientes documentos:  Especificación de requisitos del sistema. bajo las siguientes condiciones:  Instalaciones nuevas. Los casos prueba de aceptación han de ser planificados.  Realizar Pruebas de estilo D) CRITERIOS DE COMPLETITUD:  Todas las pruebas planeadas han sido ejecutadas. organizados y formalizados de manera que se determine el cumplimiento de los requisitos del sistema. PRUEBAS DE INSTALACION A) OBJETIVOS DE LA PRUEBA: Verificar y validar que el sistema se instala apropiadamente en cada cliente. 4. si el producto está listo para ser implantado para el uso operativo en el entorno del usuario. PRUEBAS DE SOFWARE .  Actualizar máquinas previamente instaladas con el sistema. E) CONSIDERACIONES ESPECIALES: Las Pruebas de Aceptación se suelen realizar en un entorno de pre-producción.2017-0 Página 33 de 48 .  Todos los defectos que se identificaron han sido tenidos en cuenta. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II Sirve para que el usuario pueda validar si el producto final se ajusta a los requisitos fijados. Esta prueba es complementada por la prueba de estilo. basados en los criterios de aceptación del cliente. nuevas máquinas a las que nunca se les ha instalado el sistema.  Manual de usuario.

el sistema opera correctamente. entrada de datos. las pruebas pueden estar basadas directamente en los Casos de Uso (o funciones de negocio). procesamiento y obtención de resultados B) DESCRIPCIÓN DE LA PRUEBA: Las pruebas Funcionales deben enfocarse en los requisitos funcionales.  Realizar la instalación D) CRITERIOS DE COMPLETITUD: Las transacciones de la aplicación se ejecutan sin fallas. incluyendo la navegación. etc. verificar la aplicación (y sus procesos internos) mediante la interacción con la aplicación vía GUI y analizar la salida (resultados). y las reglas del negocio. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II B) DESCRIPCIÓN DE LA PRUEBA: Las pruebas de instalación tienen dos propósitos. Este tipo de pruebas están basadas en técnicas de caja negra. falta de privilegios para algunas tareas. Las metas de estas pruebas son:  Verificar la apropiada aceptación de datos. actualizaciones. PRUEBAS FUNCIONALES A) OBJETIVOS DE LA PRUEBA: Se asegura la trabajo apropiado de los requisitos funcionales. PRUEBAS DE SOFWARE .  Verificar el procesamiento y recuperación y la implementación adecuada de las reglas del negocio. E) CONSIDERACIONES ESPECIALES: ¿Qué transacciones del sistema se deben seleccionar para realizar una prueba confiable de que el sistema ha sido instalado exitosamente y no hace falta ningún componente del sistema? 4.6.2017-0 Página 34 de 48 . Lo que se identifica a continuación es un diseño preliminar de las pruebas recomendadas para cada aplicación. una vez instalado. y bajo condiciones normales o anormales. C) TÉCNICAS:  Diseñar sripts para validar las condiciones de la máquina a instalar. Esto usualmente implica correr un número significativo de pruebas de Funcionalidad. El primero es asegurar que el sistema puede ser instalado en todas las configuraciones posibles. que es. instalaciones completas o personalizadas. tales como nuevas instalaciones. estas últimas incluyen insuficiente espacio en disco. El segundo propósito es verificar que.

usando datos válidos e inválidos. o función. el administrador de la base de datos. D) CRITERIOS DE COMPLETITUD:  Todas las pruebas planeadas han sido ejecutadas. flujo de caso de uso.  Que se aplique apropiadamente cada regla de negocio.  Que sean desplegados los mensajes apropiados de error y precaución cuando se usan datos inválidos. E) CONDIDERACIONES ESPECIALES: Identifique o describa aquellos aspectos (internos o externos) que impactan la implementación y ejecución de las pruebas de funcionalidad 4. Cualquier procedimiento humano. que contienen procedimientos realizados por operadores. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II C) TECNICA: Se ejecuta cada caso de uso. para verificar lo siguiente:  Que los resultados esperados ocurran cuando se usen datos válidos. D) CRITERIO DE COMPLETITUD:  Todas las pruebas planeadas han sido ejecutadas. debe ser probado durante la prueba de sistemas. PRUEBAS DE DOCUMENTACION Y PROCEDIMIENTO A) OBJETIVO DE LA PRUEBA: Evaluar la documentación del usuario B) DESCRIPCION DE LA PRUEBA: Evaluar la exactitud y claridad de la documentación del usuario y para determinar si el manual de procedimientos trabajará correctamente como una parte integral del sistema.  Todos los defectos que se identificaron han sido tenidos en cuenta PRUEBAS DE SOFWARE .7. no completamente automatizados. Muchos programas son parte de sistemas mayores. tal como los que llevan a cabo el operador.2017-0 Página 35 de 48 .  Todos los defectos que se identificaron han sido tenidos en cuenta. C) TÉCNICA: Revisar la documentación del proyecto contra las funcionalidades del sistema y su configuración física. o el usuario de terminal. Muchos defectos son identificados cuando un probador competente chequea totalmente los manuales y documentación del usuario.

switches. displays y mensajes de ayuda deben ser testeados. pantallas. (La prueba de usabilidad puede ser conducida por un grupo separado si es posible. La prueba de usabilidad detecta problemas relacionados con la conveniencia y practicidad del sistema desde el punto de vista del usuario C) TÉCNICA: Verificar que la aplicación no presenta los siguientes problemas de usabilidad típicos:  El sistema es demasiado complejo y difícil de usar. reportes y gráficos son de calidad y apariencia pobre  El sistema carece de herramientas de construcción adecuadas y requiere múltiples comandos  La lógica y conveniencia de los botones.  Se deben crear casos de prueba para comprobar que se puede operar en el sistema de forma adecuada. Identifica las áreas de diseño que hacen al sistema de difícil uso para el usuario.  Los diagramas. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II E) CONSIDERACIONES ESPECIALES: Ninguna.  Es difícil instalar y entender el sistema  La recuperación de errores es pobre y los mensajes de error no tienen significado  La sintaxis de los comandos es difícil 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. 4.8. PRUEBAS DE SOFWARE .2017-0 Página 36 de 48 . PRUEBA DE USABILIDAD A) OBJETIVO DE LA PRUEBA: Determinar la usabilidad del sistema B) DESCRIPCION DE LA PRUEBA: Determina cuán bien el usuario podrá usar y entender la aplicación.

PRUEBAS DE SOFWARE .1. C) TÉCNICA: Realizar las pruebas de sistema bajo las siguientes características:  se llevan a cabo en el lugar en donde fue desarrollado el sw.9. B) DESCRIPCION DE LA PRUEBA: Realizar un subconjunto válido de pruebas de sistema. con el fin de encontrar errores.2017-0 Página 37 de 48 . PRUEBAS ALFA A) OBJETIVOS DE LA PRUEBA: Prueba de aceptación para detectar errores en el sistema bajo un ambiente controlado.  Todos los defectos que se identificaron han sido tenidos en cuenta. E) CONSIDERACIONES ESPECIALES: Ninguna 4. 5. D) CRITERIO DE COMPLETITUD:  Todas las pruebas planeadas han sido ejecutadas. B) DESCRIPCION DE LA PRUEBA: La verificación involucra la ejecución de partes o todo del sistema en ambientes simulados. PRUEBAS DE VALIDACIONES A APLICACIONES GENÉRICAS 5. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II D) CRITERIO DE COMPLETITUD:  Todas las pruebas planeadas han sido ejecutadas. La retroalimentación de esta fase produce cambios en el software para resolver los errores y fallas que se descubren.  Todos los defectos que se identificaron han sido tenidos en cuenta. PRUEBA DE CAMPO A) OBJETIVO DE LA PRUEBA: Correr el sistema en el ambiente real para encontrar errores y validar el producto contra sus especificaciones originales. C) TECNICA: Determinar que pruebas de sistema serán corridas para validar el sistema en producción.

2. C) TECNICA: Se selecciona un grupo de usuarios que ponen a trabajar el sistema en un ambiente real. DISEÑO DE CAOSOS DE PREBA ( VALORES INTERESANTES) PRUEBAS DE SOFWARE .2017-0 Página 38 de 48 .  Todos los defectos que se identificaron han sido tenidos en cuenta. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II  en un ambiente controlado. procesan transacciones y producen salidas normales del sistema. PRUEBAS BETA A) OBJETIVO DE LA PRUEBA: Realizar la validación del sistema por parte del usuario. 6. D) CRITERIOS DE COMPLETITUD: Se establece un periodo de pruebas beta en el que los errores detectados no sean de carácter crítico para el sistema E) CONSIDERACIONES ESPECIALES: Se deben considerar mecanismos de comunicación entre los desarrolladores y los usuarios de manera que los errores detectados puedan ser corregidos. Usan el sistema en sus actividades cotidianas. B) DESCRIPCIÓN DE LA PRUEBA: Prueba de aceptación donde La validación (o pruebas beta) involucra el uso del software en un ambiente real. El desarrollador no esta presente. Las transacciones y personas que usan el sistema son reales y trabajan en su área de trabajo real. Los usuarios están advertidos de que están usando un sistema que puede fallar. D) CRITERIOS DE COMPLETITUD  Todas las pruebas planeadas han sido ejecutadas. Se selecciona un grupo de usuarios para el alpha test y se les pide trabajen con el sistema como parte de las pruebas. Los usuarios realizan pruebas a su antojo realizando uso de la aplicación. en el cual el desarrollador está presente. 5.

éstos deberán usar “valores interesantes” Se considera un valor interesante aquel que permita recorrer la mayor cantidad posible de código fuente En función del criterio de cobertura elegido 7. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II Para diseñar correctamente los casos de prueba. VALORES DE LIMITE: ¿Qué conjuntos de tres valores recorrentodas las sentencias del método getTipo()? PRUEBAS DE SOFWARE .2017-0 Página 39 de 48 . el conjunto de valores a probar para conseguir cobertura total de sentencias puede ser muy grande Para proponer valores podemos ayudarnos de técnicas como: 7. 7. OBTENCIÓN DE VALORES INTERESANTES: Para un ejemplo real.2.1. CLASES DE EQUIVALENCIA: Dividir el dominio de entrada en clases de equivalencia con valores que provocan un mismo comportamiento.

2017-0 Página 40 de 48 . UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II 8. CRITERIOS DE COBERTURA PARA VALORES INTERESANTES: Grado en que los diferentes valores interesantes seleccionados se utilizan en la batería de casos de prueba: • 1-wise: Se satisface cuando cada valor interesante de cada parámetro 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 PRUEBAS DE SOFWARE .

En esa sección se debe incluir la referencia al documento. EVENTOS DE PRUEBAS: No.1. ESCENARIOS DE PRUEBAS: No. Escenario Escenario Descripción Descripción y objetivo del escenario. Evento Escenario Evento Descripción Identificador de Descripción y objetivo del Nombre del evento 1 evento 1 evento 1. Identificador de Nombre de escenario Incluir los actores que escenario interactúan en los escenarios. Nombre de escenario Identificador de Descripción y objetivo del Nombre del evento 2 evento 2 evento 2. 9.2017-0 Página 41 de 48 .2. eventos. 9. A continuación.80 9. DOCUMENTO DISEÑO DE PRUEBAS: Realizar la definición de: escenarios. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II CONSIDERACIONES  Identificar cada caso de prueba y asociarlo explícitamente con la clase a probar  Declarar el propósito 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 ejecutarán  Lista de excepciones que pueden ocurrir  Lista de externas necesarias para 1. casos de pruebas y matriz de trazabilidad de las pruebas en el documento de diseño de pruebas. PRUEBAS DE SOFWARE . se describen los campos que se deben ingresar en cada una de las hojas del documento de diseño. Documento diseño.

Definir el modulo. NNNN corresponde a la numeración única del caso de prueba y el NombeCasoDePrueba corresponde al nombre significativo asignado en el campo caso de prueba. configuración de la prueba. 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 ejecución del caso de prueba. Perfil del Perfil del usuario en el sistema con el que se ejecutara la usuario prueba.3. Donde CP corresponde a las caso de prueba siglas de casos de prueba. como por ejemplo los datos de pruebas. Identificador único del caso de prueba. Se recomienda que inicie la nomenclatura del nombre: Identificador CPNNNN_NombreCasoDePrueba. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II 9. las condiciones prueba adicionales a tener en cuenta.2017-0 Página 42 de 48 . Necesidades Definir las necesidades para la ejecución de los casos de para el caso de pruebas. Autor Nombre de la persona que diseña el caso de prueba Fecha de Fecha en la que se diseña el caso de prueba creación PRUEBAS DE SOFWARE . CASOS DE PRUEBAS Nombre significativo del caso de prueba que permita Caso de prueba identificar el propósito de la prueba. Descripción Describir y explicar el propósito el caso de prueba. Criterios de Definir los criterios de aceptación. en caso Precondiciones de ser necesario incluir los casos de pruebas que se deben ejecutar previo al caso de prueba. servicio o función que probara con el caso Función probar de prueba. Describir que funcionalidad que será probada con el caso de Objetivo prueba.

PRUEBAS DE SOFWARE . en caso que presente paso por el usuario entradas.2017-0 Página 43 de 48 . Post Describir el estado del sistema luego de la ejecución de caso condiciones de prueba. describir que hace el usuario con las entradas. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II Otro Id Req Regl Requ Doc Casos de documento Condición de uerimient a de erimiento umento pruebas prueba o negocio anterior técnico 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 ubicación condición de ubicación ubicación ubicación ubicación prueba prueba No Usuario del sistema Sistema paso Acción 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 acción realizada paso.

UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II 9. desarrollo.2017-0 Página 44 de 48 . Se realiza principalmente para dar a conocer a las áreas de pruebas. funcionales y área de negocio cual es la situación de las pruebas (que fallos han sido reconocidos y cuales faltan por analizar). MATRIZ DE TRAZABILIDAD DE PRUEBAS: 9. En esta parte de ejecución de proyectos de desarrollo de software suele ser el más importante y es un momento en el que hay varios que están pendientes sobre la calidad del software.4.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. PRUEBAS DE SOFWARE .

Tiene que tener un mínimo de estabilidad. lo recomendable es implementar de manera formal una metodología de pruebas.6. “De nada sirve comenzar una ronda de test si al cabo de cinco golpes de ratón la aplicación rompe. Mayormente se implementa los siguientes pasos: PRUEBAS DE SOFWARE . sin embargo. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II Lo más recomendable antes de empezar es hacer un test de clasificación de la versión (qualification testing) para evaluar que la aplicación es lo suficientemente estable para comenzar la ejecución de las pruebas. PROCESO DE UNA EJECUCION FORMAL: Comúnmente se piensa que realizar la ejecución de pruebas de software es simplemente probar el software realizando una serie de casos al azar para luego hacer un reporte sobre posibles errores.2017-0 Página 45 de 48 . para productos de complejidad media en adelante.” 9.

Los criterios de salida se deben definir para cada nivel de pruebas a ejecutar. Los posibles tipos de prueba a aplicar son: pruebas de stress. manuales técnicos. pruebas funcionales. Los casos de prueba negativos permiten validar cómo se comporta el sistema ante situaciones atípicas y permite verificar la robustez del sistema. pruebas de carga. Algunos ejemplos de criterios de salida que pueden ser utilizados son: porcentaje de funcionalidades de alto riesgo probadas con éxito. pruebas de regresión. pruebas de usabilidad. Que funcionalidades y que tanto se le debe dar importancia se conoce gracias a un análisis de riesgos realizado de manera previa. atributo PRUEBAS DE SOFWARE . etc. entre otros. con el objetivo de idear los casos de prueba. bajo qué condiciones se puede considerar que una actividad de pruebas fue finalizada. se define de manera formal. • 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. etc 2) DISEÑO DE PRUEBAS Una vez elaborado y aprobado el plan de pruebas. diseños. en este caso interviene el líder de ejecución que se encarga de plantear preguntas para llegar a determinar los tipos de prueba a usar. arquitectura del sistema. historias de usuario. Los puntos importantes para iniciar este diseño pueden ser: casos de uso. el equipo de trabajo debe iniciar el análisis de toda la documentación. • Criterios de Salida: Entre las partes involucradas en el proceso. número defectos críticos y/o mayores aceptados.2017-0 Página 46 de 48 . pruebas de rendimiento. que tienen en cuenta variables tales como el impacto que podría ocasionar la falla de una funcionalidad y la probabilidad de falla de una funcionalidad. Al momento de hacer un diseño se debe tener en cuenta casos positivos y negativos. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II 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 serán probadas durante el transcurso de la prueba. manuales de usuario.

UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II que constituye uno de los requerimientos no funcionales indispensable para cualquier software. se debe verificar si los entregables planeados han sido entregados y aprobados en los cuales están los reportes de error y éxito de las pruebas realizadas. La ejecución de estos casos.2017-0 Página 47 de 48 . se deben finalizar y aprobar los documentos de soporte de prueba. no hayan desencadenado otros tipos de defectos en el sistema. Por último. PRUEBAS DE SOFWARE . 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. comparar los resultados obtenidos contra las métricas definidas. Cuando se detecte un fallo en el sistema. puede realizarse de manera manual o automatizada. es necesario realizar un re-test que permita confirmar que el defecto fue solucionado de manera exitosa. 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 depuración. sí los resultados obtenidos no superan la métricas definidas. no es posible continuar con el siguiente ciclo de pruebas. que los defectos corregidos en el proceso de depuración de la firma. 5) CIERRE DEL PROCESO: Durante este periodo se deben cerrar las incidencias reportadas. es indispensable ejecutar un ciclo de regresión que nos permita garantizar. es conveniente definir una serie de métricas que permitirán al finalizar un proceso de pruebas. 3) IMPLEMENTACIÓN DE PRUEBAS: Este proceso debe comenzar con reconocer datos de prueba con los cuales poder ejecutar los casos de prueba diseñados.

co/pdf/rfing/v24n39/v24n39a04.com/2015/06/modelo-informe-pruebas-software. UNIVERSIDAD NACIONAL DE TRUJILLO TECNOLOGÍA DE LA PROMAGACIÓN II 10.wordpress.pdf  http://www.com.pmoinformatica.com/tag/ejecucion-de-pruebas/ PRUEBAS DE SOFWARE .scielo.uv.2017-0 Página 48 de 48 .mx/content/view/508  https://www. EJEMPLOS DE EJECUCION DE PRUEBAS: 11.html  https://pruebasdelsoftware.wikispaces.org.com/software-testing-life-cycle  http://www.com/file/view/pruebas+de+software.pdf  http://www.mx/personal/jfernandez/files/2010/07/Cap1-Significado. BIBLIOGRAFÍA:  https://sg.softqanetwork.cu/Pruebas_de_software  https://www.ecured.pdf  https://analidiseorienobjet.