1. UNIVERSIDAD TECNOLOGICA DE COAHUILA
CARRERA:
Ing. Tecnologías de la información
ASIGNATURA:
Optativa II
PROFESOR:
Luis Carlos Gonzalez Valdez
9ITIN A
Saber Unidad II
ALUMNO:
Cantú Martínez Matías Arturo
García Encina Marlon Javier
Calderón Llamas Felipe Daniel
5 de Agosto del 2014 Ramos Arizpe, Coah.

2. IEEE 12207
Esta norma establece un marco de referencia común para los procesos del ciclo
de vida del software, con una terminología bien definida a la que puede hacer
referencia la industria del software. Contiene procesos, actividades y tareas para
aplicar durante la adquisición de un sistema que contiene software, un producto
software puro o un servicio software, y durante el suministro, desarrollo, operación
y mantenimiento de productos software. El software incluye la parte software del
firmware .Esta norma incluye también un proceso que puede emplearse para
definir, controlar y mejorar los procesos del ciclo de vida del software. Esta
revisión se integra la norma ISO / IEC 12207:1995, con sus dos enmiendas y se
coordinó con la revisión paralela de la norma ISO / IEC 15288:2002 (procesos del
ciclo de vida del sistema) para alinear la estructura, los términos y los procesos
organizativos y de proyecto correspondientes. Esta norma se puede utilizar
independiente o en conjunto con ISO / IEC 15288, y suministra un modelo de
referencia de proceso que apoya la evaluación de capacidad de proceso de
acuerdo con la norma ISO / IEC 15504-2 (evaluación del proceso).
Los procesos en el que este se divide son:

3. Procesos de Adquisición
 Actividades y tareas que el comprador, cliente o usuario utilizan para
adquirir un sistema producto o software.
 Preparación y publicación de una solicitud de ofertas.
 Selección del sumistrador del software.
 Gestión de los procesos de adquisición hasta la aceptación del producto

Proceso de suministro
1. Se inicia al preparar una propuesta para atender una petición de un
comprador, o por la firma de un contrato con el comprador para
proporcionarle un producto software
2. Identificación de procedimientos y recursos para gestionar bien el proyecto.
3. Desarrollo de los planes del proyecto.
4. Ejecución de los planes del proyecto hasta la entrega del producto software
al comprador.
Proceso de desarrollo
Contiene las actividades y tareas realizadas por el desarrollador
 Implementación del proceso.
 Análisis de requisitos del sistema.
 Diseño de la arquitectura del sistema.
 Análisis de los requisitos del software.
 Diseño de la arquitectura del software.
 Diseño detallado del software.
 Codificación y prueba del software.
 Integración del software.
 Prueba del software.
 Integración del sistema.
 Prueba del sistema.
 Instalación del software.
 Soporte del proceso de
 Aceptación del software.

4. Proceso de explotación
Explotación del software y del soporte del mismo. El sistema debe ser
operado de acuerdo con la documentación del usuario en su entorno
previsto sino:
 Desarrollar un plan para llevar a cabo las actividades y tareas de este
proceso.
 Procedimientos para comprobar el producto software en su entorno de
operación, enviando informes de problemas y peticiones de modificación al
Proceso de mantenimiento
 El operador debe proporcionar asistencia a los usuarios
1. El software o la documentación necesitan ser modificado, debido a
problemas o a necesidades de mejora o adaptación, por ejemplo:
2. Nuevos errores detectados
3. Necesidad de mejoras
4. Migración a un nuevo entorno operativo
Procesos de soporte
 Si rven de apoyo al resto de procesos
Proceso de documentación
 Registrar la información producida por cualquier proceso o actividad del
ciclo de vida
 Gestiona los documentos necesarios para todas las personas involucradas
en el proceso software: directores, ingenieros, personal de desarrollo,
usuarios del sistema, etc.

5. Proceso de gestión de la configuración
 Configuración del software involucra: Programas, Documentación y Datos.
 En aplicaciones grandes, la gestión de la configuración del software se
convierte en un problema.
Proceso de aseguramiento de la calidad
 Aporta confianza en que los procesos y los productos software del ciclo de
vida cumplen con los requisitos especificados y se ajustan a los planes
establecidos.
 El Aseguramiento dela calidad puede ser: interno o externo. Usa resultados
de otros procesos de apoyo: verificación, validación, auditorías, etc.
Proceso de verificación
 Verificación horizontal:
Si los productos software de cada fase del ciclo de vida cumplen los requisitos
impuestos sobre ellos en las fases previas
 Verificación vertical:
¿Estamos construyendo correctamente el producto?
Proceso de validación
 Indica si el sistema o software final cumple con las necesidades del usuario.
También se puede validar una especificación
 Puede ser realizado por una organización de servicios independiente
(proceso de validación independiente).
 ¿Estamos construyendo el producto correcto?

6. Proceso de revisión conjunta
Evaluar el estado del software y sus productos en una actividad del ciclo de vida o
fase del proyecto. Se realiza durante todo el ciclo de vida:
 A nivel de gestión
 A nivel técnico del proyecto
Proceso de auditoria
Tipos de auditoria informática:
 De explotación
 De sistemas
 De comunicaciones
 De desarrollo de proyectos
 De seguridad
 Fraudes y delitos económicos producidos en las empresas (a veces por los
propios empleados, sin conocimiento dé la dirección)
 Problemas en privacidad y seguridad (auditoria de seguridad informática,
tanto lógica como física)
 La corrección de los datos de entrada (auditoria informática de datos)
 Problemas de diseño del sistema informático

7. Esta norma es aplicable a la adquisición de sistemas, productos y servicios
software, al suministro, desarrollo, operación y mantenimiento de productos
software, y a la parte software del firmware, independientemente de que sea
hecho interna o externamente a una organización. Incluye también aquellos
aspectos de la definición del sistema necesario para proporcionar el contexto de
los productos y servicios software .NOTA - Es necesario que los procesos usados
durante el ciclo de vida del software sean compatibles con los procesos usados
durante el ciclo de vida del sistema.
Esta norma está orientada para ser usada en situaciones en las que haya dos
partes, incluido el caso en que estas dos partes pertenezcan a la misma
organización. La situación puede ir desde un acuerdo informal, hasta un contrato
con responsabilidades legales. Esta norma puede ser usada por una sola parte
como una auto imposición., no está dirigida a productos software pree laborados,
a no ser que formen parte de un producto entregable .Esta norma está escrita para
adquisidores de sistemas y productos y servicios software, y para suministradores,
desarrolladores, operadores, mantenedores, gerentes, responsables de
aseguramiento de calidad y usuarios de productos software.
Se define como cumplimiento de esta norma la ejecución de todos los procesos,
actividades y tareas seleccionados de esta norma para el proyecto software,
mediante el Proceso de Adaptación. La ejecución de un proceso o una actividad
es completa cuando todas las tareas requeridas por el proceso o actividad se
llevan a cabo de acuerdo con los criterios preestablecidos y los requisitos
especificados en el contrato como aplicables describe la arquitectura de los
procesos del ciclo de vida del software, pero no especifica los detalles de cómo
implementar o llevar a cabo las actividades y tareas incluidas en los procesos.
Esta norma no pretende prescribir el nombre, el formato o el contenido explícito de
la documentación que se genere. Si bien esta norma puede requerir la elaboración
de diversos documentos de parecido tipo o clase (un ejemplo son los distintos
tipos de planes), esto no implica que dichos documentos se desarrollen, agrupen o
se mantengan separados de alguna manera. Estas decisiones se dejan para el
usuario de esta norma, no prescribe un método o un modelo de ciclo de vida
concreto para el desarrollo del software. Las partes en esta norma son las
responsables de seleccionar un modelo de ciclo de vida para el proyecto software,
y de elaborar una correspondencia entre los procesos, actividades y tareas de
esta norma y los de dicho modelo. Las partes son también responsables de
seleccionar y aplicar los métodos de desarrollo del software, y de llevar a cabo las
actividades y tareas adecuadas para el proyecto software.
Las actividades que pueden llevarse a cabo durante el ciclo de vida del software
en cinco procesos principales, ocho procesos de apoyo y cuatro procesos
organizativos. Cada proceso del ciclo de vida está dividido en un conjunto de
actividades; cada actividad se subdivide a su vez en un conjunto de tareas.
Los procesos principales del ciclo de vida son cinco procesos que dan servicio a
las partes principales durante el ciclo de vida del software. Una parte principal es

8. la que inicia o lleva a cabo el desarrollo, operación o mantenimiento de productos
software. Estas partes principales son el adquisidor, el suministrador, el
desarrollador, el operador y el mantenedor de productos software.
Proceso de adquisición. Define las actividades del adquisidor, organización que
adquiere un sistema, producto software o servicio software.2) Proceso de
suministro. Define las actividades del suministrador, organización que proporciona
el sistema, producto software o servicio software al adquisidor.3) Proceso de
desarrollo. Define las actividades del desarrollador, organización que define y
desarrolla el producto software.
Proceso de operación. Define las actividades del operador, organización que
proporciona el servicio de operar un sistema informático en su entorno real, para
sus usuarios.5) Proceso de mantenimiento. Define las actividades del mantenedor,
organización que proporciona el servicio de mantenimiento del producto software;
esto es, la gestión de las modificaciones al producto software actualizada y
operativa. Este proceso incluye la migración y retirada del producto software
Un proceso de apoyo es el que apoya a otro proceso como parte esencial del
mismo, con un propósito bien definido, y contribuye al éxito y calidad del proyecto
software. Un proceso de apoyo se emplea y ejecuta por otro proceso según sus
necesidades
Proceso de documentación. Define las actividades para el registro de la
información producida por un proceso del ciclo de vida.2) Proceso de gestión de la
configuración. Define las actividades de gestión de la configuración.3) Proceso de
aseguramiento de la calidad. Define las actividades para asegurar, de una manera
objetiva, que los productos software y los procesos son conformes a sus requisitos
especificados y se ajustan a sus planes establecidos. Se pueden emplear
Revisiones Conjuntas, Auditorías, Verificación y Validación como técnicas de
Aseguramiento de la Calidad

9. ISO 9126
SO 9126: CALIDAD DEL SOFTWARE Y METRICAS DE EVALUACION
La sigla ISO responde a los términos en inglés "International Organization for
Standardization" que traducido al idioma español es "Organización Internacional
de Normalización". La ISO es la federación mundial de organismos de
normalización que estudia y aprueba aquellas normas de aplicación internacional.
La ISO, bajo la norma ISO-9126, ha establecido un estándar internacional para la
evaluación de la calidad de productos de software el cual fue publicado en 1992
con el nombre de “Information technology –Software product evaluation: Quality
characteristics and guidelines for their use”, en el cual se establecen las
características de calidad para productos de software.
El estándar ISO-9126 establece que cualquier componente de la calidad del
software puede ser descrito en términos de una o más de seis características
básicas, las cuales son: Funcionalidad, confiabilidad, usabilidad, eficiencia,
mantenibilidad y portabilidad; cada una de las cuales se detalla a través de un
conjunto de subcaracterísticas que permiten profundizar en la evaluación de la
calidad de productos de software.
ISO 9126 es un estándar internacional para la evaluación de la calidad del
software. Está reemplazado por el proyecto SQuaRE, ISO 25000:2005, el cual
sigue los mismos conceptos.

10. El estándar está dividido en cuatro partes las cuales dirigen, realidad, métricas
externas, métricas internas y calidad en las métricas de uso y expendido.
El modelo de calidad establecido en la primera parte del estándar, ISO 9126-
1, clasifica la calidad del software en un conjunto estructurado de
características y sus características de la siguiente manera:
 Funcionalidad - Un conjunto de atributos que se relacionan con la existencia
de un conjunto de funciones y sus propiedades específicas. Las funciones son
aquellas que satisfacen las necesidades implícitas o explícitas.
 Adecuación - Atributos del software relacionados con la presencia y aptitud
de un conjunto de funciones para tareas especificadas.
 Exactitud - Atributos del software relacionados con la disposición de
resultados o efectos correctos o acordados.
 Interoperabilidad - Atributos del software que se relacionan con su
habilidad para la interacción con sistemas especificados.
 Seguridad - Atributos del software relacionados con su habilidad para
prevenir acceso no autorizado ya sea accidental o deliberado, a programas
y datos.
 Cumplimiento funcional.
 Fiabilidad - Un conjunto de atributos relacionados con la capacidad del
software de mantener su nivel de prestación bajo condiciones establecidas
durante un período establecido.
 Madurez - Atributos del software que se relacionan con la frecuencia de
falla por fallas en el software.
 Recuperabilidad - Atributos del software que se relacionan con la
capacidad para restablecer su nivel de desempeño y recuperar los datos
directamente afectos en caso de falla y en el tiempo y esfuerzo relacionado
para ello.
 Tolerancia a fallos - Atributos del software que se relacionan con su
habilidad para mantener un nivel especificado de desempeño en casos de
fallas de software o de una infracción a su interfaz especificada.

11.  Cumplimiento de Fiabilidad - La capacidad del producto software para
adherirse a normas, convenciones o legislación relacionadas con la
fiabilidad.
 Usabilidad - Un conjunto de atributos relacionados con el esfuerzo necesario
para su uso, y en la valoración individual de tal uso, por un establecido o
implicado conjunto de usuarios.
 Aprendizaje- Atributos del software que se relacionan al esfuerzo de los
usuarios para reconocer el concepto lógico y sus aplicaciones.
 Comprensión - Atributos del software que se relacionan al esfuerzo de los
usuarios para reconocer el concepto lógico y sus aplicaciones.
 Operatividad - Atributos del software que se relacionan con el esfuerzo del
usuario para la operación y control del software.
 Atractividad
 Eficiencia - Conjunto de atributos relacionados con la relación entre el nivel de
desempeño del software y la cantidad de recursos necesitados bajo
condiciones establecidas.
 Comportamiento en el tiempo - Atributos del software que se relacionan
con los tiempos de respuesta y procesamiento y en las tasas de
rendimientos en desempeñar su función.
 Comportamiento de recursos - Usar las cantidades y tipos de recursos
adecuados cuando el software lleva a cabo su función bajo condiciones
determinadas.
 Mantenibilidad - Conjunto de atributos relacionados con la facilidad de
extender, modificar o corregir errores en un sistema software.
 Estabilidad - Atributos del software relacionados con el riesgo de efectos
inesperados por modificaciones.
 Facilidad de análisis - Atributos del software relacionados con el esfuerzo
necesario para el diagnóstico de deficiencias o causas de fallos, o
identificaciones de partes a modificar.

12.  Facilidad de cambio - Atributos del software relacionados con el esfuerzo
necesario para la modificación, corrección de falla, o cambio de ambiente.
 Facilidad de pruebas - Atributos del software relacionados con el esfuerzo
necesario para validar el software modificado.
 Portabilidad - Conjunto de atributos relacionados con la capacidad de un
sistema software para ser transferido desde una plataforma a otra.
 Capacidad de instalación - Atributos del software relacionados con el
esfuerzo necesario para instalar el software en un ambiente especificado.
 Capacidad de reemplazamiento - Atributos del software relacionados con la
oportunidad y esfuerzo de usar el software en lugar de otro software
especificado en el ambiente de dicho software especificado.
 Adaptabilidad - Atributos del software relacionados con la oportunidad para
su adaptación a diferentes ambientes especificados sin aplicar otras
acciones o medios que los proporcionados para este propósito por el
software considerado.
 Co-Existencia - Coexistir con otro software independiente, en un entorno
común, compartiendo recursos comunes.
La subcaracterística Conformidad no está listada arriba ya que se aplica a todas
las características. Ejemplos son conformidad a la legislación referente a
usabilidad y fiabilidad.
Cada subcaracterística (como adaptabilidad) está dividida en atributos. Un atributo
es una entidad la cual puede ser verificada o medida en el producto software. Los
atributos no están definidos en el estándar, ya que varían entre diferentes
productos software.
Un producto software está definido en un sentido amplio como: los ejecutables,
código fuente, descripciones de arquitectura, y así. Como resultado, la noción de
usuario se amplía tanto a operadores como a programadores, los cuales son
usuarios de componentes como son bibliotecas software.
El estándar provee un entorno para que las organizaciones definan un modelo de
calidad para el producto software. Haciendo esto así, sin embargo, se lleva a cada
organización la tarea de especificar precisamente su propio modelo. Esto podría
ser hecho, por ejemplo, especificando los objetivos para las métricas de calidad
las cuales evalúan el grado de presencia de los atributos de calidad.

13. Métricas internas son aquellas que no dependen de la ejecución del software
(medidas estáticas).
Métricas externas son aquellas aplicables al software en ejecución.
La calidad en las métricas de uso están sólo disponibles cuando el producto final
es usado en condiciones reales.
Idealmente, la calidad interna no necesariamente implica calidad externa y esta a
su vez la calidad en el uso.
Este estándar proviene desde el modelo establecido en 1977 por McCall y sus
colegas, los cuales propusieron un modelo para especificar la calidad del software.
El modelo de calidad McCall está organizado sobre tres tipos de Características
de Calidad:
 Factores (especificar): Describen la visión externa del software, como es visto
por los usuarios.
 Criterios (construir): Describen la visión interna del software, como es visto por
el desarrollador.
 Métricas (controlar): Se definen y se usan para proveer una escala y método
para la medida.
ISO 9126 distingue entre fallo y no conformidad. Un fallo es el incumplimiento de
los requisitos previos, mientras que la no conformidad es el incumplimiento de los
requisitos especificados. Una distinción similar es la que se establece entre
validación y verificación.
PERFIL DE CALIDAD USANDO ISO/IEC 9126
Un perfil de calidad permite focalizar la definición o evaluación de calidad de un
producto de software en los criterios de calidad más importantes según el contexto
requerido.
En un perfil están definidos:
· Los atributos y subcaracterísticas relevantes para el producto de software.
· Las métricas que se usarán en la medición.
· Los rangos de aceptación de esas métricas.
El estándar provee un entorno para que las organizaciones definan un modelo de
calidad para el producto software. Haciendo esto así, sin embargo, se lleva a cada
organización la tarea de especificar precisamente su propio modelo. Esto podría
ser hecho, por ejemplo, especificando los objetivos para las métricas de calidad
las cuales evalúan el grado de presencia de los atributos de calidad.

14. Métricas internas son aquellas que no dependen de la ejecución del software
(medidas estáticas).
Métricas externas son aquellas aplicables al software en ejecución.
La calidad en las métricas de uso están sólo disponibles cuando el producto final
es usado en condiciones reales. Idealmente, la calidad interna determina la
calidad externa y esta a su vez la calidad en el uso.

15. Pruebas de software
1.- PRUEBA UNITARIA
 Objetivo de la Prueba:
Se focaliza en ejecutar cada módulo (o unidad minima a ser probada, ej = una
clase) lo que provee un mejor modo de manejar la integración de las unidades en
componentes mayores.
Busca asegurar que el código funciona de acuerdo con las especificaciones y que
el módulo lógico es válido.
 Descripción de la Prueba:
Particionar los módulos en pruebas en unidades lógicas fáciles de probar.
Por cada unidad hay que definir los casos de prueba (pruebas de caja blanca).
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; por lo tanto el
diseñador debe construirlos con acceso al código fuente de la unidad a probar.
Los aspectos a considerar son los siguientes: Rutinas de excepción, Rutinas de
error, Manejo de parámetros, Validaciones, Valores válidos, Valores límites,
Rangos, Mensajes posibles.
 Técnica:
Comparar el resultado esperado con el resultado obtenido.
Si existen errores, reportarlos.
 Criterio de Completitud:
Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identificaron han sido tenidos en cuenta.
 Consideraciones Especiales:
Para la elaboración de pruebas unitarias en java se puede utillizar el JUNIT y
CACTUS.

16. 2.- PRUEBAS DE INTEGRACIÓN
 Objetivo de la Prueba:
-Identificar errores introducidos por la combinación de programas probados
unitariamente.
-Determina cómo la base de datos de prueba será cargada.
-Verificar que las interfaces entre las entidades externas (usuarios) y las
aplicaciones funcionan correctamente.
-Verificar que las especificaciones de diseño sean alcanzadas.
-Determina el enfoque para avanzar desde un nivel de integración de las
componentes al siguiente.
 Descripción de la Prueba:
-Describe cómo verificar que las interfaces entre las componentes de software
funcionan correctamente.
-Determina cómo la base de datos de prueba será cargada.
-Determina el enfoque para avanzar desde un nivel de integración de las
componentes al siguiente.
-Decide qué acciones tomar cuando se descubren problemas.
Por cada Caso de Prueba ejecutado:
Comparar el resultado esperado con el resultado obtenido.
 Técnica:
Utilizar la técnica top-down. Se empieza con los módulos de nivel superior, y se
verifica que los módulos de nivel superior llaman a los de nivel inferior de manera
correcta, con los parámetros correctos.
Utilizar la técnica down-top. Se empieza con los módulos de nivel inferior, y se
verifica que los módulos de nivel inferior llaman a los de nivel superior de manera
correcta, con los parámetros correctos.
 Criterio de Completitud:
Todas las pruebas planeadas han sido ejecutadas.
Todos los defectos que se identificaron han sido tenidos en cuenta.
 Consideraciones Especiales:
Ninguna

17. 3.- PRUEBA DE LA CAJA BLANCA
La prueba de la caja blanca es un método de diseño de casos de prueba que usa
la estructura de control del diseño procedimental para derivar los casos de prueba.
Las pruebas de caja blanca intentan garantizar que:
• Se ejecutan al menos una vez todos los caminos independientes de cada módulo
• Se utilizan las decisiones en su parte verdadera y en su parte falsa
• Se ejecuten todos los bucles en sus límites
• Se utilizan todas las estructuras de datos internas
3.1. Prueba del camino básico
El método del camino básico (propuesto por McCabe) permite obtener una medida
de la complejidad de un diseño procedimental, y utilizar esta medida como guía
para la definición de una serie de caminos básicos de ejecución, diseñando casos
de prueba que garanticen que cada camino se ejecuta al menos una vez.
3.1.1. Notación del grafo de flujo o grafo del programa
Representa el flujo de control lógico con la siguiente notación:
A continuación se muestra un ejemplo basado en un diagrama de flujo que
representa la estructura de control del programa.

18. En el grafo de flujo
• Cada nodo representa una o más sentencias procedimentales
• Un solo nodo puede corresponder a una secuencia de pasos del proceso y a una
decisión
• Las flechas (aristas) representan el flujo de control

19. Cualquier representación del diseño procedimental se puede traducir a un grafo de
flujo.
Si en el diseño procedimental se utilizan condiciones compuestas, la generación
del grafo de flujo tiene que descomponer las condiciones compuestas en
condiciones sencillas, tal y como muestra la figura siguiente.
3.1.2. Complejidad ciclomática
Es una medida que proporciona una idea de la complejidad lógica de un
programa.
• La complejidad ciclomática coincide con el número de regiones del grafo de flujo
• La complejidad ciclomática, V(G), de un grafo de flujo G, se define como V(G) =
Aristas -Nodos +2
• La complejidad ciclomática, V(G), de un grafo de flujo G, también se define como
V(G) = Nodos de predicado + 1
A partir del grafo de flujo de la figura 4, la complejidad ciclomática sería:
• Como el grafo tiene cuatro regiones, V(G) = 4
• Como el grafo tiene 11 aristas y 9 nodos, V(G) = 11 - 9 - 2 = 4
• Como el grafo tiene 3 nodos predicado, V(G) = 3 + 1 = 4
A partir del valor de la complejidad ciclomática obtenemos el número de caminos
independientes, que nos dan un valor límite para el número de pruebas que
tenemos que diseñar.
En el ejemplo, el número de caminos independientes es 4, y los caminos
independientes son:

20. • 1-11
• 1-2-3-4-5-10-1-11
• 1-2-3-6-7-9-10-1-11
• 1-2-3-6-8-9-10-1-11
3.1.3. Pasos del diseño de pruebas mediante el camino básico
• Obtener el grafo de flujo, a partir del diseño o del código del módulo
• Obtener la complejidad ciclomática del grafo de flujo
• Definir el conjunto básico de caminos independientes
• Determinar los casos de prueba que permitan la ejecución de cada uno de los
caminos anteriores
• Ejecutar cada caso de prueba y comprobar que los resultados son los esperados
3.2. Prueba de bucles
Los bucles son la piedra angular de la inmensa mayoría de los algoritmos
implementados en software, por lo que tenemos que prestarles una atención
especial a la hora de realizar la prueba del software.
La prueba de bucles es una técnica de prueba de caja blanca que se centra en la
validez de las construcciones de los bucles.
Se pueden definir cuatro tipos de bucles diferentes:
• Bucles simples
• Bucles concatenados
• Bucles anidados
• Bucles no estructurados

21. 3.2.1. Bucles simples
A los bucles simples (de n iteraciones) se les tiene que aplicar el conjunto de
pruebas siguientes:
• Saltar el bucle
• Pasar sólo una vez por el bucle
• Pasar dos veces por el bucle
• Hacer m pasos del bucle con m < n
• Hacer n-1, n y n+1 pasos por el bucle
3.2.2. Bucles anidados
Si extendiésemos el conjunto de pruebas de los bucles simples a los bucles
anidados, el número de pruebas crecería geométricamente, por lo que Beizer
sugiere el siguiente conjunto de pruebas para bucles anidados:
• Comenzar con el bucle más interno, estableciendo los demás bucles a los
valores mínimos
• Llevar a cabo las pruebas de bucles simples para el bucle más interno,
conservando los valores de iteración de los bucles más externos a los valores
mínimos

22. • Progresar hacia fuera en el siguiente bucle más externo, y manteniendo los
bucles más externos a sus valores mínimos
• Continuar hasta que se hayan probado todos los bucles
3.2.3. Bucles concatenados
Probar los bucles concatenados mediante las técnicas de prueba para bucles
simples, considerándolos como bucles independientes.
2.2.4. Bucles no estructurados
Rediseñar estos bucles para que se ajusten a las construcciones de la
programación estructurada.
Ejemplo
Construir el Grafo de Flujo correspondiente a la siguiente especificación del
software en LDP.

23. Ejemplo
Construir el Grafo de Flujo correspondiente al siguiente código de un programa

24. Ejemplo:
DECISIONES LÓGICAS
-Validación del dominio
1. xMin = Val(txtxMin): xMax = Val(txtxMax)
2. If xMin < -5 Then
3. MsgBox "El limite inferior no debe ser menor a -5", vbCritical, "Error"
4. txtxMax.Text = ""
Label10(0).Caption = ""
txtxMin.SetFocus
Parabola.Cls
Exit Sub
7. End If
5. If xMax > 5 Then
3. MsgBox "El limite superior no debe ser mayor a 5", vbCritical, "Error"
4. txtxMin.Text = ""
txtxMax.Text = ""
Label10(0).Caption = ""
txtxMin.SetFocus
Parabola.Cls
Exit Sub
7. End If
6. If xMin >= xMax Then
3. MsgBox "El dominio no es válido", vbCritical, "Error"
4. txtxMin.Text = ""

25. txtxMax.Text = ""
txtxMin.SetFocus
Exit Sub
7. End If
- Calculo de tabla de valores para puntos intermedios (razón de cambio 0.5)
1. If x <>
2. m = x + 0.5
3. n = (m ^ 2) + (4 * m) + 5
4. k = Label12.Count
5. Load Label12(k)
With Label12(k)
.Top = Label12(k - 1).Top + 665
.Caption = Str(m)
.Visible = True End With
6. l = Label13.Count
7. Load Label13(l)
With Label13(l)
.Top = Label13(l - 1).Top + 665
.Caption = Str(n)
.Visible = True

26. End With
8. End If
- Calculo para el Ymin y el Ymax
1. Ymin = f(xMin)
2. If f(xMax) < ymin =" f(xMax)">
4. If xMin < ymin =" f(Xv)">
1. Ymax = f(xMin)

27. 2. If f(xMax) > Ymax Then 3. Ymax = f(xMax)
4. If xMin <> Ymax Then 7. Ymax = f(Xv)
BUCLES
DIAGRAMA DE FLUJO DE DATOS (DFD)

29. 4.- PRUEBA DE LA CAJA NEGRA
Las pruebas de caja negra se llevan a cabo sobre la interfaz del software,
obviando el comportamiento interno y la estructura del programa.
Los casos de prueba de la caja negra pretenden demostrar que:
• Las funciones del software son operativas
• La entrada se acepta de forma correcta
• Se produce una salida correcta
• La integridad de la información externa se mantiene
A continuación se derivan conjuntos de condiciones de entrada que utilicen todos
los requisitos funcionales de un programa.
Las pruebas de caja negra pretenden encontrar estos tipos de errores:
• Funciones incorrectas o ausentes
• Errores en la interfaz
• Errores en estructuras de datos o en accesos a bases de datos externas
• Errores de rendimiento
• Errores de inicialización y de terminación
Los tipos de prueba de cana negra que vamos a estudiar son:
• Prueba de partición equivalente
• Prueba de análisis de valores límites
4.1. Prueba de partición equivalente
Este método de prueba de caja negra divide el dominio de entrada de un
programa en clases de datos, a partir de las cuales deriva los casos de prueba.
Cada una de estas clases de equivalencia representa a un conjunto de estados
válidos o inválidos para las condiciones de entrada.

30. 4.1.1. Identificación de las clases de equivalencia
Se identifican clases de equivalencia válidas e inválidas con la siguiente tabla
A continuación se siguen estas directrices:
• Si una condición de entrada especifica un rango de valores (p.e, entre 1 y 999),
se define una CEV (1 <= valor <= 999) y dos CEI (valor < 1 y valor > 999)
• Si una CE requiere un valor específico (p.e., el primer carácter tiene que ser una
letra), se define una CEV (una letra) y una CEI (no es una letra)
• Si una CE especifica un conjunto de valores de entrada, se define una CEV para
cada uno de los valores válidos, y una CEI (p.e., CEV para "Moto", "Coche" y
"Camión", y CEI para "Bicicleta")
• Si una condición de entrada especifica el número de valores (p.e., una casa
puede tener uno o dos propietarios), identificar una CEV y dos CEI (0 propietarios
y 3 propietarios)
4.1.2. Identificación de casos de prueba
Seguir estos pasos
• Asignar un número único a cada clase de equivalencia
• Escribir casos de prueba hasta que sean cubiertas todas las CEV, intentando
cubrir en cada caso tantas CEV como sea posible
• Para cada CEI, escribir un caso de prueba, cubriendo en cada caso una CEI
Ejemplo
Diseñar casos de prueba de partición equivalente para un software que capte
estos datos de entrada:
• Código de área: En blanco o un número de tres dígitos
• Prefijo: Número de tres dígitos que no comiencen por 0 ó 1

31. • Sufijo: Número de cuatro dígitos
• Ordenes: "Cheque", "Depósito", "Pago factura"
• Palabra clave: Valor alfanumérico de 6 dígitos