Índice

I.- Fuente: Ing. De Software – Un Enfoque Práctico (Pressman), Cap. 17....................................................4

1. Elabore una tabla comparativa de todos los tipos de prueba abarcados en el capítulo, incluyendo el
tipo de errores al cual se enfoca, un grado de dificultad de aplicación según considere, del 1 al 5 (1 =
menos difícil) y 2 posibles inconvenientes para aplicarla........................................................................4
2. Aplique cada uno de estos tipos de prueba a su software. Para algunos tipos, como la prueba de
interfaz y documentación de ayuda, primero debe presentar el objeto aprobar (pantalla, ejemplo de
ayuda, etc.)..............................................................................................................................................5
3. Responda las preguntas a final del capítulo: (1-8, 11-18)................................................................6
7.1. Myers [MYE79] usa el siguiente programa como autocomprobación de su capacidad para
especificar una prueba adecuada: un programa lee tres valores enteros. Los tres valores se
interpretan como representación de la longitud de los tres lados de un triángulo. El programa
imprime un mensaje indicando si el triángulo es escaleno, isósceles o equilátero. Desarrolle un
conjunto de casos de prueba que considere que probará de forma adecuada este programa...........6
7.2. Diseñe e implemente el programa especificado en el Problema 17.1 (con tratamiento de
errores cuando sea necesario). Obtenga un grafo de flujo para el programa y aplique la prueba del
camino básico para Desarrollar casos de prueba que garanticen la comprobación de todas las
sentencias del pm grama. Ejecute los casos y muestre sus resultados................................................8
7.3. ¿Se le ocurren algunos objetivos de prueba adicionales que no se hayan mencionado en la
Sección 17.1. ? 302............................................................................................................................10
7.4. Aplique la técnica de prueba del camino básico a cualquiera de los programas que haya
implementado en los Problemas 17.4 a 17.11...................................................................................10
7.5. Especifique, diseñe e implemente una herramienta de software que calcule la complejidad
ciclomática para el lenguaje de programación que quiera. Utilice la matriz de grafos como
estructura de datos operativa en el diseño.......................................................................................11
7.6. Lea a Beizer [BE1901 y determine cómo puede ampliar el programa desarrollado en el
Problema 17.5 para que incluya varios pesos de enlace. Amplíe la herramienta para que procese las
probabilidades de ejecución o los tiempos de proceso de enlaces...................................................12
7.7. Use el enfoque de prueba de condiciones descrito en la Sección 17.5.1 para diseñar un
conjunto de casos de prueba para el programa creado en el Problema 17.2....................................12
7.8. Mediante el enfoque de prueba de flujo de datos descrito en la Sección 17.5.2, cree una
lista de cadenas de definición uso para el programa creado en el Problema 17.2............................12
7.9. Dé por lo menos tres ejemplos en los que la prueba de caja negra pueda dar la impresión de
que «todo está bien», Capítulo 17 TÉCNICAS DE PRUEBA DEL SOFTWARE mientras que la prueba de
caja blanca pudiera descubrir errores. Indique por lo menos tres ejemplos en los que la prueba de
caja blanca pueda dar la impresión de que «todo está bien», mientras que la prueba de caja negra
pudiera descubrir errores..................................................................................................................13
7.10. ¿Podría una prueba exhaustiva (incluso si fuera posible para pequeños programas)
garantizar que un programa es al 100 por 100 correcto?..................................................................13
7.11. Usando el método de la partición equivalente, obtenga un conjunto de casos de prueba
para el sistema HogarSegurodescrito anteriormente en el libro.......................................................13
7.12. Mediante el análisis de valores límite, obtenga un conjunto de casos de prueba para el
sistema SSRB descrito en el Problema 12.13.....................................................................................13
7.13. 17.15. Investigue un poco y escriba un breve documento sobre el mecanismo de
generación de tablas ortogonales para la prueba de datos...............................................................14
7.14. Seleccione una IGU específica para un programa con el que esté familiarizado y diseñe
una serie de pruebas para ejercitar la IGU........................................................................................15
7.15. Investigue en un sistema Cliente/Servidor que le sea familiar. Desarrolle un conjunto de
escenarios de usuario y genere un perfil operacional para el sistema..............................................15
7.16. Pruebe un manual de usuario (o una facilidad de ayuda) de una aplicación que utilice
frecuentemente. Encuentre al menos un error en la documentación...............................................15
 I.- Fuente: Ing. De Software – Un Enfoque Práctico (Pressman), Cap. 17.
1. Elabore una tabla comparativa de todos los tipos de prueba abarcados en el capítulo,
incluyendo el tipo de errores al cual se enfoca, un grado de dificultad de aplicación según
considere, del 1 al 5 (1 = menos difícil) y 2 posibles inconvenientes para aplicarla.

PRUEBAS Tipos De Errores Calificación Posibles

inconvenientes
Prueba de caja blanca Examen de las Errores lógicos, 4 Con lleva mucho
funciones Errores de ejecución tiempo , aumento
detallada y de los bucles, de los costos, difícil
específica. Errores de validez de implementación
los datos.
Prueba del camino básico Permite medir la Errores lógicos, 4 Complicación de
complejidad del prueba, aumento
diseño de de costos, conlleva
interfaz. mucho tiempo,
difícil
implementación.
Prueba de la estructura de Errores lógicos 3 Complicación de
control prueba, difícil
implementación
Prueba de caja negra Examen de las Errores lógicos. 4 El sistema puede
funciones que Error de interfaz. colapsar, no se
realiza el Error de estructura conoce de manera
producto. de datos. interna el sistema.
Funciones ausentes
Prueba de entorno Errores físicos. 3 El sistema puede
especializado arquitectura Errores lógicos. colapsar.
y aplicaciones
 2. Aplique cada uno de estos tipos de prueba a su software. Para algunos tipos, como la
prueba de interfaz y documentación de ayuda, primero debe presentar el objeto aprobar
(pantalla, ejemplo de ayuda, etc.)

En este caso vamos aplicar el proceso de caja negra para el proceso de asignación de aulas.

Prueba de caja negra Configuración Tiempo de Prueba

Prueba de conexión a la Iniciar sesión con cuenta de 20 min
base de datos administrador.
Prueba de mantenimientos Insertar datos establecidos 1:15 min
por el administrador para
realizar las pruebas.
Prueba de ingreso al Inicio de sesión con las 30 min
sistema diferentes cuentas de
usuarios
Pruebas de salida de Revisar la salida de datos 1h
información de asignación de aulas
Caja negra Falla Correcciones
Conexión a la base de datos No se encontraron errores No se aplicaron
en la conexión. correcciones.
Prueba de mantenimiento Se ingresaba cualquier
valor o carácter en los Validación de campos
campos, podía causar
 colapso del sistema o
información basura.
Prueba de ingreso del No se encontró ningún No se aplicaron
sistema error correcciones.
Prueba de salida de Aulas asignadas repetidas Actualizar estado de las
información aulas en el query
Documentación de ayuda:
Esta será una opción que estará en el menú con las posibles soluciones a
problemas que presente el sistema y con la opción de contactar al soporte
técnico.
Menu
Buscar:__________________________________________
Ver Sugerencias

Acerca de

Buscar

El boton Asignar A todo se encarga, de relacionar los datos que contiene el

sistema , entre caracteristicas de aulas y de materias , deficiencias por maestro, materias que
imparte dicho maestro , y todas los demas datos mostrados en pantalla anteriormente.

Con click derecho encima de lo que desee consultar, podra ver la informacion del mismo junto a sus
requerimientos

Para mas informacion contactar con soporte técnico 809-973-8559

3. Responda las preguntas a final del capítulo: (1-8, 11-18)
7.1. Myers [MYE79] usa el siguiente programa como autocomprobación de su capacidad para
especificar una prueba adecuada: un programa lee tres valores enteros. Los tres valores se
interpretan como representación de la longitud de los tres lados de un triángulo. El
programa imprime un mensaje indicando si el triángulo es escaleno, isósceles o equilátero.
Desarrolle un conjunto de casos de prueba que considere que probará de forma adecuada
este programa.

A B
C
Caso de caja negra
Aquí se muestra la interfaz gráfica, esta es analizada si la entrada de datos requerida y la salida
que representa son válidas.
Los datos digitados deben ser numéricos.
No se debe dejar campo en blanco.

Caso de Caja Blanca

7.2. Diseñe e implemente el programa especificado en el Problema 17.1 (con tratamiento de
errores cuando sea necesario). Obtenga un grafo de flujo para el programa y aplique la
prueba del camino básico para Desarrollar casos de prueba que garanticen la comprobación
de todas las sentencias del pm grama. Ejecute los casos y muestre sus resultados.
 B
A C

Leer

Formula Formula Formula

Resultado Resultado Resultado

Condición SI-NO de comparaciones de fórmulas para determinar si un triángulo es equilátero, isósceles

o escaleno.

Determinar triángulo equilátero

B A=IF(A == B && A == C)
              Determinar triangulo isósceles 
B= IF ((A == B && A! = C) || (B == C && B! = A))
A C Determinar Triangulo escaleno
             C= IF (A! = B && A! = C && B! = C)

Triangulo es Triangulo es Triangulo es

equilátero Isósceles escaleno
 Inicio
7.3. ¿Se le ocurren algunos objetivos de prueba adicionales que no se hayan mencionado en la
Sección 17.1. ? 302
1
 Leer A, B, Cla integración adecuada de los componentes.
Verificar
 Probar si el software no cumple con requerimientos
 Asegurarse de que los problemas de software han sido corregidos antes de la prueba de
validación.

7.4. IF(A == B la técnica de prueba

Aplique del==camino
IF ((A B básico a cualquiera de&&los programas que haya
IF (A! = B
&& A == C) && A! = C) || A! = C && B!
implementado en los Problemas 17.4
(B == C && a 17.11. = C) 1
B! = A))

Fin
 Inicio

Leer Valor A, N

A-N+2

Resultado Fin

7.5. Especifique, diseñe e implemente una herramienta de software que calcule la complejidad
ciclomática para el lenguaje de programación que quiera. Utilice la matriz de grafos como
estructura de datos operativa en el diseño.

La complejidad ciclomática es una métrica del software que proporciona una medición cuantitativa de la
complejidad lógica de un programa.

V (G) = A - N + 2
V (G)=8-7+2
V (G)= 3
 7.6. Lea a Beizer [BE1901 y determine cómo puede ampliar el programa desarrollado en el
Problema 17.5 para que incluya varios pesos de enlace. Amplíe la herramienta para que
procese las probabilidades de ejecución o los tiempos de proceso de enlaces.

 Se empieza creando un grafo de objetos y sus relaciones.

 Hacer una colección de nodos.
 Representando los pasos de una transición.
 Observación y pruebas de interfaces

Este identifica los 8 nodos del diagrama desde la lectura hasta el resultado y la impresión del proceso.
Este identifica las 7 aristas del diagrama.
Como resultado trae 3 procesos de ejecución: las tres fórmulas diferentes a través de cálculos para
determinar uno de las tres posibles condiciones.

7.7. Use el enfoque de prueba de condiciones descrito en la Sección 17.5.1 para diseñar un
conjunto de casos de prueba para el programa creado en el Problema 17.2.

 Utilizamos una condición compuesta en donde se comparan un valor de entrada con la

validación respectiva.
 Igualamos cada variable definida a cada formula en particular
 Aquí se compara los valores asignado en cada valor en a, b, o c
 Determinación de condiciones

Determinar triángulo equilátero

A= IF (A == B && A == C)
Determinar triangulo isósceles 
B= IF ((A == B && A! = C) || (B == C && B! = A))
Determinar Triangulo escaleno
C= IF (A! = B && A! = C && B! ==C)

7.8. Mediante el enfoque de prueba de flujo de datos descrito en la Sección 17.5.2, cree una lista
de cadenas de definición uso para el programa creado en el Problema 17.2.

Cadena de definición de uso

A= IF (A== B && A == C)
B= IF ((A == B && A! = C) || (B == C && B! = A))
C= IF (A! = B && A! = C && B! = C)
Estrategia de prueba DU
 7.9. Dé por lo menos tres ejemplos en los que la prueba de caja negra pueda dar la impresión de
que «todo está bien», Capítulo 17 TÉCNICAS DE PRUEBA DEL SOFTWARE mientras que
la prueba de caja blanca pudiera descubrir errores. Indique por lo menos tres ejemplos en los
que la prueba de caja blanca pueda dar la impresión de que «todo está bien», mientras que la
prueba de caja negra pudiera descubrir errores.

Caja Negra
 Donde se verifican que los datos de entrada sean correctos y que la validación está siendo
cumplida.
 Obtener un resultado similar a la que debe presentar el sistema.
Errores descubiertos por la caja blanca:
 Especificación de validación incorrecta
 Error en una de las condiciones que del modulo
Caja Blanca
 Tenga una programación lógica adecuada.
Errores descubiertos por la caja negra:
 No cumple con las condiciones.

7.10. ¿Podría una prueba exhaustiva (incluso si fuera posible para pequeños programas)
garantizar que un programa es al 100 por 100 correcto?

No, ya que no asegura la ausencia de errores.

7.11. Usando el método de la partición equivalente, obtenga un conjunto de casos de

prueba para el sistema HogarSegurodescrito anteriormente en el libro.

Entrada de Tipo Equivalencias

Sistema Validas no validas
Contraseñas Varchar Alfanumérico 8 No máximo de 8
posiciones Caracteres
Acontecimientos Varchar Caracteres
Acontecimientos Rango De 1 a 5 Número no mayor de 5
de prioridad
Tiempo Datetime Tiempo en horas No mayor de 24 a 72
horas

7.12. Mediante el análisis de valores límite, obtenga un conjunto de casos de prueba para
el sistema SSRB descrito en el Problema 12.13.

El departamento de obras públicas de una gran ciudad ha decidido desarrollar un sistema de

seguimiento y reparación de baches (SSRB) basado en página web. Con los siguientes requisitos:
Los ciudadanos pueden conectarse a la página e informar sobre la situación y la importancia del bache.
A medida que se informa sobre cada bache, se le asigna un número de identificación y se guarda con la
calle en la que se encuentra, su tamaño (en una escala de 1 a lo), su posición (en el medio, a un lado,
etc.), su distrito (determinado a partir de la calle) y una prioridad de reparación (determinada a partir de
su Tamaño). A cada bache se Is asocian datos de petición de obra, incluyendo la ubicación y el tamaño,
la brigada, el equipamiento asignado, las horas de reparación, el estado del bache (obra en curso,
reparado, reparación temporal, no reparado), la cantidad de m a j rial de relleno usado y el coste de la
reparación (calcula& con las horas dedicadas, el número de trabajadores, el material y el equipamiento
usados). Finalmente, se crea un archivo de daños para mantener la información sobre los &Os
Reportados debidos a la existencia del bache, incluyendo el nombre del ciudadano, su dirección, su
número de teléfono, el tipo de daño y el coste de subsana miento.

Condiciones Equivalencia Valida Equivalencia no Valida

Tamaño  Longitud Menor que 0

Posición  En el medio No seleccionar opción
 A La derecha
 A la izquierda
Prioridad  Tamaño Cantidad numérica
Estado  Reparación temporal Seleccionar una de las tres
 No reparado opciones
 En curso

Material Cantidad de material Cantidad de materiales menor que

0
Costo  Cant. Material Cantidad de cada uno menor que
 Equipamiento cero
 Número de trabajadores
 Horas trabajadas

7.13. 17.15. Investigue un poco y escriba un breve documento sobre el mecanismo de

generación de tablas ortogonales para la prueba de datos.

El método de prueba de la tabla ortogonal nos permite encontrar errores asociados con fallos
localizados. Estas pruebas detectan y aíslan todos los fallos de modalidad simple (un fallo de
modalidad simple es un problema que afecta a un solo parámetro); detecta todos los fallos de
modalidad doble (un fallo de modalidad doble es en el que están afectados los parámetros que
intervienen conjuntamente); además pueden asegurar la detección de fallos de modalidad
múltiple. Las pruebas de software planificadas con arreglos ortogonales son basadas
fundamentalmente en utilizar criterios de diseños de expertos cuyo objetivo es optimizar la
cantidad de pruebas a realizar para lo que se pueden utilizar software o tablas que están
disponibles para la identificación del número de pruebas a ejecutar teniendo el probador
(ingeniero de pruebas) la tarea de determinar el nivel.
 7.14. Seleccione una IGU específica para un programa con el que esté familiarizado y
diseñe una serie de pruebas para ejercitar la IGU.

Programa de facturación de x empresa.

Prueba de arquitectura cliente/servidor

 Los botones son estándares y el cliente puede identificarlos.
 Al digitar contraseñas registros de mayúsculas.
 Aviso al dejar campos obligatorios en blanco.
 Secuencia de módulos, o sea, nivel de respuesta desde uno hacia otro.
 Tabulaciones adecuadas.
 Probar todos tipos de enlace, tanto externos como internos.

7.15. Investigue en un sistema Cliente/Servidor que le sea familiar. Desarrolle un conjunto

de escenarios de usuario y genere un perfil operacional para el sistema.

QuickBook
Escenario: Proceso de registrar datos de empleados para cobrar en el banco
Se registra los empleados, que componen la empresa, el sueldo y sus respectivas derechos salariales,
estos son enviados a nóminas bancarias para proceder con el pago, mediante el sistema el usuario
deberá manejar botones, herramientas, sistema y la interacción del sistema bancario a quien asignara al
nómina.

Perfil operacional
 Ingeniería en Sistemas.
 Experiencia en sistemas operativos y administración de servidores.
 Conocimientos avanzados de Microsoft Office (Word, Excel y PowerPoint).
 Inglés intermedio.

7.16. Pruebe un manual de usuario (o una facilidad de ayuda) de una aplicación que
utilice frecuentemente. Encuentre al menos un error en la documentación.

 Lenguaje utilizado poco entendible.

 Mala traducción de las palabras.
 No especificación de imágenes en cuanto a búsqueda de errores.
 No detallan cada especificación.
 Las posibles imágenes que presentan no concuerda con los diferentes OS.