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.

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:

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.

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

Sirven 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.

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?

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

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

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

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.

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.

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.

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.

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.

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.

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.

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

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.

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

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:

• 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

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

• 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.

Ejemplo

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

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 = ""

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

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)

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)

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.

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

• Sufijo: Número de cuatro dígitos

• Ordenes: "Cheque", "Depósito", "Pago factura"

• Palabra clave: Valor alfanumérico de 6 dígitos