Índice

II.- Fuente: Ing. De Software – Un Enfoque Práctico (Pressman), Cap. 18....................................1

1. Demuestre un ejemplo de verificación y validación, aplicado a su proyecto en el
nivel 1 de la materia................................................................................................................1
2. Estructure un GIP que considere adecuado para su proyecto, asumiendo que lo elabora
para una empresa específica....................................................................................................2
3. Para su proyecto, enfoque la estrategia de prueba como una espiral, detallando en
cada vuelta el objetivo que considera correcto perseguir........................................................4
4. Aplique a su proyecto cada una de las pruebas descritas en el capítulo, iniciando en la
prueba de Unidad. En cada caso, detalle quiénes, describa cómo (en pasos), qué probaría y
especifique los formatos en los cuales se especifiquen los resultados finales de cada prueba.
4
5. Para su proyecto, en el proceso de depuración, detalle un ejemplo de cada una de las
características de errores que expone el texto, y describa cómo las manejaría......................6
6. Aplique los diferentes enfoques de depuración (fuerza bruta, vuelta atrás y eliminación
de causa) a su proyecto, con ejemplo detallado de cada caso y respondiendo las 3 preguntas
sugeridas para el tercer enfoque..............................................................................................8
7. Responda las preguntas a final del capítulo: (1-5, 7-10)...................................................9
7.1. Haga una lista de algunos problemas que puedan estar asociados con la creación
de un grupo independiente de prueba. ¿Están formados por las mismas personas el GIP y
el grupo SQA?.......................................................................................................................9
7.2. ¿Es siempre posible desarrollar una estrategia de prueba de software que use la
secuencia de pasos de prueba descrita en la Sección 18.1.3? ¿Qué posibles
complicaciones pueden surgir para sistemas empotrados?.................................................9
7.3. Si sólo pudiera seleccionar tres métodos de diseño de casos de prueba para
aplicarlos durante la prueba de unidad, ¿cuáles serían y por qué?....................................10
7.4. Porqué es difícil de realizar la prueba unitaria a un módulo con alto nivel de
integración.........................................................................................................................10
7.5. ¿Cómo puede afectar la planificación del proyecto a la prueba de integración?...10
7.6. ¿Es posible o incluso deseable la prueba de unidad en cualquier circunstancia?
Ponga ejemplos que justifiquen su respuesta....................................................................11
7.7. ¿Quién debe llevar a cabo la prueba de validación -el desarrollador del software o
el usuario? Justifique su respuesta.....................................................................................11
II.- Fuente: Ing. De Software – Un Enfoque Práctico (Pressman), Cap. 18.

1. Demuestre un ejemplo de verificación y validación, aplicado a su

proyecto en el nivel 1 de la materia.

Inspeccion y prueba

Inspeccion del
V erificacion de softw are

Inspeccion
software

Analisis estatico
automatizaco

Prueba de integracion

Pruebas orientadas a
Pruebas
fallos

Banco de pruebas

 Fallos de datos
 ¿Las variables se inicializan antes de que se utilicen los valores?
 ¿Todas las constantes tienen nombre?
 ¿El límite superior de los arrays es igual al tamaño de los mismos?

 Fallos de control
 Para cada instrumento condicional, ¿Es correcta la condición?
 ¿Todos los ciclos terminan?
 ¿Los ciclos están delimitados correctamente?
 si se requiere un break, ¿Se ha incluido?

 Fallos de entrada y salida

 ¿Se utilizan todas las variables de entrada?
 Antes de que salgan, ¿Se le han asignado valores a las variables de
salida?
 ¿provocan corrupción de los datos las entradas no esperadas?

 Fallos de interfaz
  ¿Las llamadas a funciones y métodos tienen el número correcto de
parámetros?
 ¿Concuerdan los tipos de los parámetros formales y reales?
 ¿están los parámetros en el orden adecuado?
 ¿Existen funciones o procedimientos no invocados?

 Fallos de gestión de almacenamiento

 ¿si se utilizan almacenamiento dinámico, se asigna correctamente el
espacio?
 ¿Se desasigna explícitamente la memoria después de que se libera?

 Fallos de gestión de las excepciones

 ¿Se toman en cuenta todas las condiciones de errores posibles?

Identificar
Mantenimiento practicas
corporativas

Integracion y Analisis de
validacion requisitos

Verificacion Analisis

Codificacion Diseño
2. Estructure un GIP que considere adecuado para su proyecto, asumiendo que
lo elabora para una empresa específica.

Prototipo

Prueba de
Programas
 3. Para su proyecto, enfoque la estrategia de prueba como una espiral, detallando en
cada vuelta el objetivo que considera correcto perseguir.

Para los grupos independientes de prueba, decidimos implementar las siguientes pruebas
integrales:

Probar las
Probar las clases de
operaciones
objetos Probar los grupos de
individuales
individualelmente y objetos
asociadas a los
sus dependencias
objetos.

Verificacion de los
Prueba aislada de valores que se
cada operacion de su asignan a los
interfaz atributos de las
clases

Ya que tiene la finalidad de detectar fallos resultantes de la interacción entre los componentes
de los grupos modulares interconectados entre sí, podríamos detallarlos de la siguiente
manera:

 Probar las operaciones individuales asociadas a los objetos: es prueba de funciones y

se pueden utilizar las técnicas de caja negra y/o caja blanca.
 Probar clases de objetos individualmente: dado que las diferentes funciones de una
clase están interrelacionadas requiere un método especial.
 Probar grupos de objetos: en este caso son apropiadas las integraciones descendentes
o ascendentes.
 Probar el sistema: la verificación y validación es la comparación con la especificación
de requisitos disponibles, y se realiza igual que en el caso funcional estructurado.

4. Aplique a su proyecto cada una de las pruebas descritas en el capítulo, iniciando en

la prueba de Unidad. En cada caso, detalle quiénes, describa cómo (en pasos), qué
probaría y especifique los formatos en los cuales se especifiquen los resultados
finales de cada prueba.

Prueba De Unidad

¿Como?

o Identificar los objetos participantes y los enlaces existentes entre ellos

o Identificar todas las variables que puedan determinar el
comportamiento del método (parámetros de entrada, variables de
estado, relación entre objetos, lenguajes de programación).
 o Se particiona el dominio de cada variable identificada: tipo y conjunto
de valores, valores validos e inválidos, restricciones invariantes y
condiciones.

¿Que?

o Interfaz
o Estructuras de datos locales
o Condiciones de limite
o Caminos independientes
o Caminos de manejo de errores

¿Quien?

o Programadores y analistas

Formato

o Caja Blanca

Prueba De Integración

¿Como?

o Utilizando técnicas de Top-Down, empezando por los módulos

superiores y verificando posteriormente los de nivel inferior.
o Verificando las pruebas planeadas.
o Tras cada prueba se reemplaza otro resguardo con el modulo real

¿Que?

o Módulos probados mediante prueba de unidad.

¿Quien?

o Programadores y desarrolladores

Formato

o Caja Blanca, Top-Down, Bottom-Up

Prueba De Sistema

¿Como?

Se ejecuta en cada caso de uso, flujo básico y/o función utilizando datos
validos e inválidos que verifiquen lo siguiente:

o Identificando y describiendo aquellos aspectos tanto internos como

externos que impactan la implementación y ejecución de las pruebas.
 ¿Qué?

o Funcionalidad
o Usabilidad
o Seguridad y controles
o Recuperación
o Modularidad

¿Quién?

o Testers y Analistas

Formato

o Funcional

Prueba De Validación

¿Cómo?

Se analizan las diferentes representaciones del sistema (diagramas de

requerimientos, diagramas de diseño y código fuente)

Depuración de los procesos; se localiza y corrigen los errores descubiertos.

Los errores se recuperan y hay que volver a probarlos en el sistema, es decir,

se hace una prueba de regresión

¿Qué?

o Garantía de calidad del software

o Correcta construcción del software
o Producción correcta del software
o Organización de las pruebas
o Análisis y Diseño
o Tareas constructivas

¿Quién?

o Analistas y desarrolladores

Formato

o Caja blanca, caja negra

5. Para su proyecto, en el proceso de depuración, detalle un ejemplo de cada una de

las características de errores que expone el texto, y describa cómo las manejaría.

 El síntoma y la causa pueden ser geográficamente remotos entre sí.

o ¿Cómo manejarlo?
 Los errores tienden a ser más fáciles de encontrar en pequeños
fragmentos de código que en los programas integrados. Usa un
arnés de prueba para probar el código aisladamente

 El síntoma puede desaparecer al corregir otro error.

o ¿Cómo manejarlo?
Usualmente es bueno solo corregir el problema específico que
observas en vez de perder tiempo haciendo una modificación
grande y ambiciosa que vaya a afectar a todo el programa.

 El síntoma puede estar producido por algo que no es un error.

o ¿Cómo manejarlo?
Para encontrar el error, disemina sentencias de impresión
aleatoriamente por todo el programa. Examina la salida para
ver dónde está el error. Si no puedes encontrarlos de este
modo, intenta cambiar cosas hasta que algo parezca funcionar.
No respaldes la versión original del programa, y no guardes
registro de los cambios que hagas. La programación es más
excitante si no estás muy seguro de lo que el programa está
haciendo.

 El sistema puede estar causado por un error humano que no sea

fácilmente detectado.
o ¿Cómo manejarlo?
Se recomienda en toda implementación de nuevo software,
diseñar un manual de usuario en el que se detallen los procesos
que conforman la funcionalidad del sistema. Con fin de reducir
costos por el mal uso de la mano humana.

 El síntoma puede ser el resultado de problemas de temporización en

vez de problemas de proceso.
o ¿Cómo manejarlo?
La idea de dividir el programa en secciones para ayudar a
detectar errores funciona especialmente bien para los errores
de sintaxis. Si tienes un error de sintaxis problemático, remueve
parte del código y recompila. Puedes no obtener ningún error
(debido a que el error está en la parte que removiste), obtener
el mismo error (lo que significa que necesitas remover una
parte diferente), u obtener un error distinto (porque habrás
engañado al compilador para que produjera un mensaje que
tiene más sentido).

 Puede ser difícil producir exactamente las condiciones de entrada.

o ¿Cómo manejarlo?
Un error que no ocurre predeciblemente es usualmente un
error de inicialización o uno de asignación de punteros. Si el
problema es que algunas veces la suma de un cálculo es
correcta y algunas veces no, probablemente una variable
involucrada en el cálculo no está siendo inicializada
apropiadamente; la mayor parte del tiempo solo ocurre cuando
no empieza en cero. Si el problema es un fenómeno extraño e
 impredecible y estás usando punteros, casi con certeza tienes
un puntero no inicializado o estás usando la memoria de un
puntero después que ha sido desasignada.

 El síntoma puede aparecer de forma intermitente.

o ¿Cómo manejarlo?
Localizar la fuente del error también usa el método científico.
Podrías sospechar que el error es resultado de un problema
específico, digamos un error de fuera del límite por uno.
Podrías entonces variar el parámetro que sospechas es el
causante del problema -una unidad por debajo del límite, en el
límite y una por encima del límite- y determinar si tu hipótesis
es correcta.

 El síntoma puede ser debido a causa que se distribuyen por una serie
de tareas ejecutándose en diferentes procesadores.
o ¿Cómo manejarlo?
La depuración es fácil si añades piezas a un sistema una a la
vez. Si agregas una pieza a un sistema y encuentras un nuevo
error, remueve la pieza y pruébala por separado. Métela en un
arnés de prueba y ejecuta la rutina de manera independiente
para determinar qué está mal.

6. Aplique los diferentes enfoques de depuración (fuerza bruta, vuelta atrás y

eliminación de causa) a su proyecto, con ejemplo detallado de cada caso y
respondiendo las 3 preguntas sugeridas para el tercer enfoque.

Fuerza Bruta Vuelta Atrás Eliminación De

Causas
Ejemplo Insertar En El Código Ejercitar Los Códigos Elegir Casos De
Sentencias De En Un Arnés De Pruebas Diferentes A
Impresión, Prueba. Los Errores Los Casos De Prueba
Exhibición En Tienden A Ser Más Que Ya Sabemos Que
Pantalla U Otro Fáciles En Los Son Erróneos O
Mecanismo Para Programas Correctos.
Registrar Las Integrados. Se Usa Ejecutarlos Para
Actividades Un Arnés De Prueba Generar Más Datos Y
Anormales. Para Probar El Usar Los Nuevos
Código Datos Para
Aisladamente. Agregarlos A Una
Lista De Posibles
Errores.

¿Se Repite La Causa Si, El Problema Es Si, El Error Puede Si, A Través De La
Del Error En Otra Producido Por Un Repetirse En Modularidad Del
Parte Del Programa? Patrón Lógico. Cualquier Parte Del Patrón Lógico Se
 Software. Puede Determinar El
Descubrimiento De
Otros Errores.

¿Cuál Es El Siguiente Lógico De Diseño De Estructura De

Error Que Se Podrá Datos
Presentar A Raíz De
La Corrección Que
Hoy Voy A Realizar?

¿Que Podríamos Producir Códigos Usar Estructuras Y Estructurar De

Haber Hecho Para Orientados A Funciones Para Manera Detallada
Prevenir Este Error Objetos Con Fin De Detectar Los Requerimientos
La Primera Vez? Que La Rápidamente El Mal Que Es Usuario
Programación Nata Empleo De Los Solicita.
Sea Mínima. Recursos.

7. Responda las preguntas a final del capítulo: (1-5, 7-10)

La verificación comprueba que el software está de acuerdo con su especificación. Se
comprueba que el sistema cumple los requerimientos funcionales y no funcionales que se le
han especificado.

La validación se debe de asegurar de que el software cumple las expectativas del cliente. Su
finalidad es probar que el software hace lo que el usuario espera a diferencia de lo que se ha
especificado.

7.1. Haga una lista de algunos problemas que puedan estar asociados con la creación
de un grupo independiente de prueba. ¿Están formados por las mismas personas el
GIP y el grupo SQA?

Los grupos GIP incluyen figuras tanto internas como externas del proceso de desarrollo, pues
el responsable del software trabaja a lo largo del proceso de prueba. Por otra parte, se
centra en figuras externas; ya que una prueba independiente garantiza la calidad del
software y consigue un grado de independencia que no sería posible si fuera una parte de la
organización desarrolladora de software.

Con la creación de un grupo independiente de prueba, pueden surgir los siguientes

problemas:

 El responsable del desarrollo no debería entrar en el proceso de prueba.

 El software debe de ser “puesto a salvo” de extraños que puedan probarlo de forma
desconsiderada.
 Los encargados de las pruebas solo aparecen en el proyecto cuando comienzan las
etapas de prueba.
 7.2. ¿Es siempre posible desarrollar una estrategia de prueba de software que use la
secuencia de pasos de prueba descrita en la Sección 18.1.3? ¿Qué posibles
complicaciones pueden surgir para sistemas empotrados?

Para los sistemas de tiempo real y sistemas empotrados, es inaceptable el software que
proporciona las funciones requeridas, pero no se ajusta a los requerimientos de rendimiento.
Las pruebas de rendimiento están diseñadas para probar el rendimiento del software en
tiempo de ejecución para probar el rendimiento del software en tiempo de ejecución dentro
del contexto de un sistema integrado.

Las posibles complicaciones que pueden surgir son:

o El nivel de depuración es mayor.

o Presenta más fuentes de riesgos
o Tomas más tiempo en implementar.
o Es difícil de controlar los detalles de todos los niveles del sistema.

7.3. Si sólo pudiera seleccionar tres métodos de diseño de casos de prueba para
aplicarlos durante la prueba de unidad, ¿cuáles serían y por qué?

Considero que durante las pruebas de unidad los diseños de casos de pruebas son esenciales.
Las más efectivas para descubrir gran cantidad de errores son las siguientes

o Cálculos
o Comparaciones
o Flujo de control

7.4. Porqué es difícil de realizar la prueba unitaria a un módulo con alto nivel de
integración.

Las pruebas unitarias a un módulo de alto nivel de integración son sumamente tediosas, pues
cada una de las iteraciones debe de ser evaluadas y aprobadas. Es decir, que mientras más
iteraciones tenga el modulo, más pruebas hay que realizar.

Al probar cada módulo individualmente es necesario crear módulos auxiliares para que
simulen las acciones de los módulos invocados por el modulo que se está aprobando. Así
mismo se han de crear módulos conductores para establecer las precondiciones necesarias,
llamar al módulo objeto de la prueba y examinar los resultados de las pruebas.

7.5. ¿Cómo puede afectar la planificación del proyecto a la prueba de integración?

Si no se planifica la realización de las pruebas de integración, en el cronograma de desarrollo
e implantación del sistema previamente, realizar las pruebas a desfase o únicamente al final
del desarrollo del sistema, puede ocasionar un fuerte retraso, ya que habrá sin lugar a dudas
cambios imprevistos y modificaciones que realizarle al sistema y así, no se podrá cumplir con
las actividades establecidas en el cronograma para las fechas indicadas en él.

7.6. ¿Es posible o incluso deseable la prueba de unidad en cualquier circunstancia?

Ponga ejemplos que justifiquen su respuesta.

No, no es posible implementar pruebas unitarias en todo tipo de situaciones. Para ser así, un
módulo como un componente software debe de cumplir con las siguientes características:

o Debe ser un bloque básico de construcción de programas.

o Debe implementar una función independiente simple.
o Podrá ser probado al cien por cien por separado.
o No deberá tener más de 500 líneas de código.

7.7. ¿Quién debe llevar a cabo la prueba de validación -el desarrollador del software o
el usuario? Justifique su respuesta

Considero que las pruebas de validación deben de ser empleadas por el desarrollador del
software ya que es un proceso secuencial que se consigue mediante una serie de pruebas de
caja negra que garantizan la conformidad de los requisitos y se llevan a cabo cuando se ha
terminado la prueba de integración de software. Utilizando recursos como código fuente e
interfaces.