verificacion_validacion de software.pdf

VERIFICACION Y VALIDACIÓN DEL SOFTWARE 1

Validación y Verificación del

Software


“Año de la inversión para el desarrollo rural y la seguridad alimentaria”

UNIVERSIDAD NACIONAL

“SAN LUIS GONZAGA” DE ICA

FACULTAD DE ING. DE SISTEMAS

VERIFICACIÓN Y VALIDACIÓN DEL

SOFTWARE

CURSO

CONTROL DE CALIDAD DE SOFTWARE

DOCENTE

Ing. Alonso Morales Loayza

INTEGRANTES

Delgado Valenzuela, Moisés Darwin

Flores Ccama, Miguel

Gonzales Carlos, Jorge Luis

Martínez Palomino, Kely Yine

Ramírez Paucar, Dennys Rudy

CICLO

VIII - S1

2013


Dedicatoria

Dedicamos este trabajo a Dios por guiarnos

en el buen camino.

A nuestros Padres ya que gracias a ellos

tenemos su apoyo y crecemos tanto como

profesionales y personas.

A nuestros docentes por su esfuerzo y

educación de calidad que nos brindan con

el fin de formar profesionales de calidad.


Objetivos

Objetivo final

El objetivo final del proceso de verificación y validación es comprobar que el

sistema está hecho para un propósito, lo cual significa que el sistema debe ser

suficientemente bueno para su uso establecido, al cual intenta llegar aplicando

técnicas específicas conocidas como: las pruebas y las revisiones.

Objetivo fundamental

Los objetivos de las actividades de verificación y validación son valorar y mejorar la

calidad de los productos del trabajo generados durante el desarrollo y modificación

del software. Debemos corregir todo posible fallo y alcanzar cierto grado de

perfección, así mismo, debemos garantizar la consistencia, confiabilidad, utilidad,

eficacia y el apego a los estándares del desarrollo de software. Para ello es necesario

encontrar defectos en el sistema que estamos desarrollando y asegurarnos que el

sistema será útil para el entorno de trabajo requerido.

Objetivo específico Introducir la verificación y validación del software y discutir, comprender la diferencia

entre ellos (V & V).

Describir el proceso de inspección del programa y su papel en la V & V.

Explicar el análisis estático como una técnica de verificación.

Describir el proceso de desarrollo de software de Sala Limpia.

Conocer las técnicas de pruebas para descubrir fallos en el código

Descubrir defectos (para corregirlos)

Revisar los productos (otra forma de detectar defectos)


Resumen

Durante y después del proceso de implementación, el programa que se está

desarrollando debe ser comprobado para asegurar que satisface su

especificación y entrega la funcionalidad esperada por las personas que pagan

por el software.

La verificación y la validación es el nombre dado a estos procesos de análisis y

pruebas, que son un conjunto de actividades que se realizan durante cada

etapa del proceso de software.

Según Boehm 1979 expreso la diferencia entre ellas: Validación: ¿estamos

construyendo el producto correcto? Verificación: ¿estamos construyendo el

producto correctamente?

Esto implica que la verificación debe estar de acuerdo con especificación,

satisfacer sus requerimientos funcionales y no funcionales. La validación sin

embargo es un proceso más general cuyo objetivo es que el software satisfaga

las expectativas del cliente.

El objetivo primordial es la seguridad de que el sistema está hecho para un

propósito.

Dentro de la verificación y validación existen dos conceptos complementarios

tales como: Inspecciones de software y Pruebas de software.

Las inspecciones son un proceso de verificación y validación estática en el que

un sistema se revisa para encontrar errores omisiones y anomalías.


El proceso de inspección siempre se realiza utilizando una lista de los errores o

fallos comunes de los programadores. Esta se somete a discusión por el

personal con experiencia y se actualiza frecuentemente según se vaya teniendo

experiencia.

Las Pruebas son básicamente un conjunto de actividades dentro del desarrollo

de software. Dependiendo del tipo de pruebas, estas actividades podrán ser

implementadas en cualquier momento de dicho proceso de desarrollo.

Las técnicas de prueba de software son aplicables como buenas prácticas en el

proceso de prueba en la etapa de desarrollo, cada una de ellas es importante y

mientras más compleja sea la codificación más de estas técnicas se utilizaran,

los códigos así como las interfaces tienen sus propias técnicas de prueba y en

cada una de ellas depende necesariamente de los involucrados en el desarrollo

y de qué manera aplicarlas.


INTRODUCCION

El interés que suscita el tema en cuestión, viene dado por su cada vez mayor peso en el

desarrollo software en la actualidad. La importancia del concepto de la verificación y

validación viene siendo reflejada desde hace más de 30 años, de hecho Michael S.

Deutsch en su estudio “Verification and Validation” establece que: “El desarrollo de

sistemas de software implica una serie de actividades de producción en las que las

posibilidades de que aparezca el fallo humano son enormes.

Los errores pueden empezar a darse desde el primer momento del proceso, en el que los

objetivos pueden estar especificados de forma errónea o imperfecta, así como en

posteriores pasos de diseño y de desarrollo. Debido a la imposibilidad humana de trabajar

y comunicar de forma perfecta, el desarrollo de software ha de ir acompañado de una

actividad que garantice la calidad.”

Los proyectos de desarrollo software han padecido tradicionalmente problemas de

calidad, tanto en el propio proceso de desarrollo como en los productos de entrega. Esta

problemática tiene su origen en las habituales desviaciones sobre los plazos y esfuerzos

previstos y en la frecuente aparición de fallos durante la implantación y operación de los

productos resultantes.

El primer problema pone de manifiesto una falta de calidad en el proceso de gestión de

los proyectos software: cuanto menor es ésta, peor es el grado de adherencia a los plazos

y a los esfuerzos previstos. El segundo problema indica la falta de calidad de los

productos desarrollados: cuanto menor es ésta, mayor es el número de defectos y,

consecuentemente, mayor será el número de fallos que aparecerán durante la ejecución

del software.

Para hacer frente a esta situación la comunidad involucrada en el desarrollo del software

ha reaccionado con diversas iniciativas metodológicas, tales como:

• La definición de modelos de referencia, de esta forma nació el Modelo CMMI, diseñado

por el SEI, que establece cinco niveles de madurez, especificando para cada uno de ellos

los objetivos que deben ser cubiertos para que una organización pueda ser calificada con

el nivel de madurez correspondiente. Se calcula que el 75% de las organizaciones

dedicadas al desarrollo de software está en el nivel de madurez 1, es decir, en el más

bajo.

• El establecimiento de normas y guías para el desarrollo de software. Éstas han sido

promovidas o generadas por entidades de reconocido prestigio (IEEE, CEI, BSI, AENOR) y

se han orientado a definir el ciclo de vida del software, a normalizar la terminología o a

desarrollar aspectos específicos del ciclo de vida, tales como la documentación, la

verificación y validación o las pruebas de componentes.


PROCESO DE VERIFICACIÓN Y VALIDACIÓN

DE SOFTWARE (V&V)

1. Introducción 1.1 ¿Qué es Verificación y Validación?

La verificación y validación es el nombre que se da a los procesos de comprobación y

análisis que aseguran que el software que se desarrolla está acorde a su especificación y

cumple las necesidades de los clientes. La V&V es un proceso de ciclo de vida completo.

Inicia con las revisiones de los requerimientos y continúa con las revisiones del diseño y

las inspecciones del código hasta la prueba del producto. Existen actividades de V&V en

cada etapa del proceso de desarrollo del software.

El proceso de validación y verificación (V&V) [SOMM05] es un conjunto de

procedimientos, actividades, técnicas y herramientas que se utilizan paralelamente

al desarrollo de software, con el fin asegurar que un producto resuelve el

problema

Inicialmente planteado.

Ambos conceptos suelen tratarse como sinónimos, sin embargo, se refieren a cosas

completamente distintas:

1.2 Verificación.

Se enfoca más al proceso de evaluación del sistema o de los componentes, permite

determinar si los productos de una determinada fase del desarrollo satisfacen las

condiciones impuestas en el inicio de la misma. Responde la pregunta definida por

Boehm ¿Estamos construyendo el producto correctamente?, entonces el software

debería ajustarse a sus especificaciones iniciales.

IEEE: El proceso de evaluación de un sistema o componente para determinar si los

productos de una fase de desarrollo dado satisfacen las condiciones impuestas en el inicio

de la fase.

1.3 Validación Es una evaluación del sistema o componentes, pero solo se efectúa en el transcurso o al

final del proceso del desarrollo para determinar si cumple con lo especificado. Responde

la pregunta definida por Boehm ¿Estamos construyendo el producto correcto?,

entonces el software debería hacer lo que el cliente realmente quiere que haga.

IEEE: El proceso de evaluación de un sistema o componente durante o al final del proceso

de desarrollo para determinar si satisface los requisitos especificados.


1.4 Expectativas

Las expectativas de los usuarios del sistema y el entorno de mercado actual del sistema

son las siguientes:

Función de software: El nivel de confianza que se requiere depende de lo crítico que

sea el software para una organización. Por ejemplo, para controlar un sistema de

seguridad se requiere un nivel de confianza más alto para el software que para un

sistema de software que ha sido desarrollado para demostrar algunas ideas nuevas.

Expectativas del usuario: Muchos usuarios tiene pocas expectativas sobre su software

por lo que no se sorprenden si esta falla durante su uso, incluso están dispuestos a

aceptar estos fallos del sistema si los beneficios de uso son mayores que sus

desventajas. Sin embargo, actualmente es menos aceptable entregar sistemas no

fiables por lo que las compañías de software deben mejorar para la V&V de software.

Entorno de mercado: Cuando un sistema se comercializa, se debe tener en cuenta los

programas competidores, el precio que sus clientes están dispuestos a pagar por el

sistema y la agenda que se requiere para entregar dicho sistema. En caso que una

compañía tenga pocos competidores esta puede entregar un programa sin antes haber

sido completamente probado y depurado, debido a que es el primero en el mercado.

Asimismo, se sabe que los clientes pueden estar dispuestos a tolerar defectos en el

software si no están dispuestos a pagar precios altos por el producto.


2. Procesos de Verificación y Validación 2.1 Las inspecciones del software.

Fueron definidas por Fagan a principios de los años 70's para IBM, solo eran

exámenes estrictos que se dirigían al código fuente, actualmente están dirigidas a

los procesos, metodologías, planes o a cualquier artefacto producido en el

transcurso del desarrollo, detectando algún defecto en estos.

Las inspecciones son fundamentales para el aseguramiento de la calidad pues

establecen un orden en el proceso al mismo tiempo que se establece una mejora

continua. Son un proceso de mejora incremental ya que a medida que pasa el

tiempo en el desarrollo de software los defectos deben reducirse.

Analizan y comprueban las representaciones del sistema como el documento de

requerimientos, los diagramas de diseño y y el código fuente del programa. Se

aplica a todas las etapas del proceso de desarrollo. Las inspecciones se

complementan con algún tipo de análisis automático del texto fuente o de los

documentos asociados.

2.1.1 Ventajas

Pueden inspeccionarse versiones incompletas de un sistema sin costes

adicionales.

Existen dos razones por las que las inspecciones son más efectivas que las

pruebas:

Varios defectos se detectan en una sola inspección. El problema con las

pruebas es que sólo pueden detectar único fallo por prueba, ya que los

defectos de la primera que se detecte pueden afectar a la detección de las

siguientes.

Usa el conocimiento del dominio y del lenguaje de programación que se

utiliza. En esencia, es más probable que los revisores vean los tipos de

errores que comúnmente ocurre el lenguaje de programación particulares y

en los tipos particulares de la aplicación.

Las inspecciones y pruebas de software tienen sus ventajas y desventajas por lo

que deberían utilizarse ambas en el proceso de V&V.

2.1.2 Roles en el proceso de inspección

El proceso de inspección de programa es actualmente un método muy utilizado

para la verificación de programas. La inspección de programas es un proceso


formal formado por un equipo de por lo menos cuatro personas, las cuales

analizan el código y señalan posibles defectos.

En las propuestas originales de Fagan, 1986 se sugieren roles tales como autor,

lector, probador y moderador. A medida que la inspección fue introducida con

éxito, han surgido también otras propuestas para los roles del equipo, los cuales

sugieren seis roles, tal y como se muestra en la figura.

EQUIPO DE INSCRIPCIÓN DE PROGRAMAS

Autor o Propietario El programador o diseñador responsable de generar el programa o documento. Responsable de reparar los defectos descubiertos durante el proceso de inspección.

Inspector Encuentra errores, omisiones o inconsistencias en los programas y documentos. También puede identificar cuestiones más generales que están fuera del ámbito de inspección.

Lector Presenta el código o documento en una reunión de inspección

Secretario Registra los resultados de la reunión de inspección

Presidente o Moderador Gestiona el proceso y facilita la inspección. Realiza un informe de resultados del proceso para el moderador jefe

Moderador Jefe Responsable de las mejoras del proceso de inspección actualización de las listas de comprobación, estándares de desarrollo

2.1.3 Etapas en el proceso de inspección

Existen requisitos esenciales antes que comience una inspección del programa,

los cuales son:

a. Se debe tener una especificación completa del código a inspeccionar, ya

que sería imposible realizarlo sin contar con ello.

b. Cada miembro del equipo de inspección esté familiarizado con los

estándares de la organización.

c. Cada miembro del equipo a inspeccionar cuente con una versión compilada

y actualizada del código.

El proceso de inspección tarda a lo más dos horas, el cual debería centrarse en

la detección de defectos.

Luego del proceso de inspección, el autor debería realizar los cambios

requeridos para corregir los problemas identificados. En la siguiente etapa, el

moderador debería decidir si se requiere una re inspección de código. En caso

que se decida que no es necesaria una re inspección completa y que además los

defectos han sido reparados con éxito, el programa será aprobado por el

moderador para su entrega.


El siguiente cuadro describe los procesos de estas inspecciones, ya que ambas

son muy parecidas y contienen casi las mismas etapas en el proceso de

inspección

Modelo de Fagan (1976) Modelo de Humphrey

(1989)

Planificación

Cuando los materiales para ser inspeccionados pasan por los criterios de entrada (por ejemplo, el código fuente compila con éxito sin errores de sintaxis), miembros del equipo de inspección se seleccionan, y se establecen los horario de la inspección (por ejemplo, tiempo y lugar).

Permite la selección de participantes y de la preparación de los criterios de la entrada.

Descripción Se dan instrucciones previas a los miembros del equipo del material a ser inspeccionado, y se asignan los papeles.

Se dan instrucciones previas a los miembros del equipo del material a ser inspeccionado, y se asignan los papeles.

Preparación

Los miembros del equipo estudian el material individualmente para prepararse para satisfacer los papeles asignados.

Los inspectores detectan los errores y registran en una sola lista de registro.

Inspección

El equipo realiza una reunión de inspección para encontrar defectos, y registrarlos. El propósito es la detección de los defectos o de violaciones de estándares, alternativas debe ser eliminada por el asesor.

En esta fase, el desarrollador explica los defectos encontrados y los inspectores aclaran también, el porque de los defectos. De esta forma se establece una lista de defectos que debe pasar a la siguiente fase.

Remodelar

El autor revisa el resumen de los defectos detectados, clarificando cuales son realmente defectos y que son mal entendidos en el proceso de la inspección. Entonces, el autor debe modificar para corregir los defectos.

El autor revisa el resumen de los defectos detectados, clarificando cuales son realmente defectos y que son mal entendidos en el proceso de la inspección. Entonces, el autor debe modificar para corregir los defectos.

Seguimiento

El asesor o el equipo entero de inspección repasa el producto otra vez, para asegurar que todos los arreglos son eficaces y de que no se ha introducido ningún defecto adicional durante la remodelación.

El asesor o el equipo entero de inspección repasa el producto otra vez, para asegurar que todos los arreglos son eficaces y de que no se ha introducido ningún defecto adicional durante la remodelación.

Análisis No aplica

La lista de defectos o de registro se pasa al autor para que la analice y verifique los defectos y se prepare para la inspección.


2.1.4 Comprobaciones de inspección

Debido a que la inspección de programas se encarga de la detección de errores,

estos se clasifican en las siguientes clases:

Clase de Defecto(Fallos)

Comprobación de Inspección

Defecto de Datos

¿Se Inicializa todas las variables antes que se utilicen sus valores? ¿Tiene nombre todas las constantes? ¿El límite superior de los vectores es igual al tamaño del vector o al tamaño 21? Si se utilizan cadenas de caracteres, ¿tienen un delimitar explícitamente asignado? Existe alguna posibilidad de que el búfer se desborde?

Defectos de Control

Para cadena sentencia condicional, ¿es correcta la condición? ¿Se garantiza que termina cada bucle? ¿Están puestas correctamente entre llaves las sentencias compuestas? En las sentencias case, ¿se tienen en cuenta todos los posibles casos?

Defectos Entrada/Salida ¿Se utilizan todas las variables de entrada? ¿Se les asigna un valor a todas las variables de salida? ¿Pueden provocar corrupciones de datos las entradas no esperadas?

Defectos de Interfaz

¿Las llamadas a funciones y a métodos tienen el número correcto de parámetros? ¿Concuerdan los tipos de parámetros reales y formales? ¿Están en orden todos los parámetros? Si los componentes acceden a memoria compartida, ¿tienen el mismo modelo de estructura de la memoria compartida?

Defectos de Gestión de Almacenamiento

Si una estructura enlazada se modifica ¿Se reasigna correctamente todos los enlaces? Si se utiliza almacenamiento dinámico ¿Se asigna correctamente el espacio de memoria? ¿Se designa explícitamente el espacio de memoria cuando ya no se necesita?

Defectos de Manejo de Excepciones

¿Se tienen en cuenta todas las condiciones de error posibles?

2.1.5 Análisis estático automatizado

Los analizadores estáticos son herramientas de software que escanean el código

fuente de un programa y detectan posibles defectos y anomalías.

Pueden detectar si las sentencias están bien formadas, hacer inferencias sobre el

flujo de control del programa y calcular el conjunto de todos los posibles valores

para los datos del programa.


Complementan las facilidades de detección de los errores proporcionados por el

compilador del lenguaje. Pueden utilizarse como parte del proceso de inspección

o como una actividad separada del proceso de verificación y validación.

El objetivo del análisis estático automatizado es llamar la atención del inspector

sobre anomalías del programa, tales como variables que se utilizan sin

inicialización, variables que no se usan o datos cuyo valor podía estar fuera de

alcance

Es muy efectivo como soporte para las inspecciones. Es un suplemento pero no

puede reemplazar el proceso de inspección.

Etapas

Las etapas implicadas en el análisis estático comprenden:

Análisis del flujo de control: esta etapa identifica y resalta bucles con múltiples salidas o puntos de entrada y código no alcanzable.

Análisis de uso de los datos: Esta etapa revela cómo se utilizan las

variables del programa detectan variables que se utilizan sin inicialización previa, variables que se asignan dos veces y no se utilizan.

Análisis de interfaces: Este análisis comprueba la consistencia de las

declaraciones de funciones y procedimientos y su utilización.

Análisis del flujo de información: Esta fase identifica las dependencias entre las variables de entrada y salida. Mientras no detecte anomalías muestra cómo se deriva el valor de cada variable del programa a partir de otros valores de variables. En esta fase debería ser capaz de encontrar valores que han sido calculados erróneamente.

Análisis de caminos: esta fase del análisis semántico identifica los posibles

caminos del programa y muestra la sentencia ejecutadas en dicho camino.

Estas etapas generan gran cantidad de información que deben ser usadas con cuidado.

Utilización del Análisis estático

Particularmente valioso cuando un lenguaje como por ejemplo “C” es

utilizado, el cual tiene un tipeo débil y por lo tanto varios errores pueden

no ser detectados por el compilador.

Menos efectivo en términos de costos para lenguajes como Java, que tienen

fuerte controles de tipeo y pueden por lo tanto, detectar varios errores

durante la compilación


2.1.6 Características importantes del Proceso de V&V

La separación de intereses, por la cual se evitan conflictos de intereses

internos en una organización. Una organización independiente garantiza que

requisitos importantes no sean ignorados en el proceso de toma de decisiones.

La diferenciación de puntos de vista, esto supone una segunda opinión,

que siempre es interesante para eliminar ambigüedades u omisiones.

La efectividad y la productividad, las actividades de V&V son llevadas a

cabo por personal experto, con competencias específicas en el área de V&V.

2.1.7 Proceso de Depuración

Al proceso de eliminación de los errores que se descubren durante las fases de

prueba se denomina depuración.

Es un proceso independiente que no tiene porqué estar integrado:

La verificación y validación establece la existencia de defectos en el

programa.

La depuración es el proceso que localiza el origen y corrige estos

defectos.

No existe un proceso sencillo para la depuración de programas. Los mejores

depuradores buscan patrones en los resultados de las pruebas donde el

defecto se detecta, y para localizar el defecto utilizan el conocimiento que

tienen sobre el tipo de defecto, el patrón de salida, así como del lenguaje y

proceso de programación.

El conocimiento del proceso es importante. Los depuradores conocen los

errores de los programadores comunes (como olvidad incrementar un

contador, errores de direccionamiento de punteros en lenguaje C, etc.) y los

comparan contra los patrones observados.

Localizar los fallos es un proceso complejo porque los fallos no

necesariamente se localizan cerca del punto en que se detectan. Para

localizar un fallo de un programa el programador responsable de la

depuración tiene que diseñar programas de prueba adicionales que repitan el

fallo original y que ayudan a descubrir el origen del fallo. En estos casos las

herramientas de depuración que permiten rastrear el programa y visualizar los

resultados intermedios es de una gran ayuda.

Las herramientas de depuración son habitualmente parte de las herramientas

de apoyo al lenguaje y que sirven de base al compilador. Proporcionan un


entorno especial de ejecución que permiten acceder a las tablas de símbolos

del compilador, a través de ella a los valores de las variables del programa.

Habitualmente, permiten controlar la ejecución paso a paso sobre el código

del programa.

Después de que se descubre el origen del fallo en el programa, este debe

corregirse y entonces reevaluar el sistema. Esto implica repetir de nuevo las

pruebas anteriores (pruebas de regresión). Estas pruebas se hacen para

comprobar que los cambios introducidos resuelven definitivamente el fallo y

no introducen nuevos fallos. La estadística muestra que la reparación de un

fallo frecuentemente es incompleta y además introduce nuevos fallos.

Figura Proceso de Depuración

2.2 Pruebas de Software

Las Pruebas de Software, o "Testing" es una investigación empírica y técnica cuyo

objetivo es proporcionar información objetiva e independiente sobre la calidad del

producto bajo pruebas a la parte interesada o Stakeholder.

Las Pruebas de Software son una actividad más en el proceso de "Aseguramiento de la

Calidad"

Las Pruebas son básicamente un conjunto de actividades dentro del desarrollo de

software. Dependiendo del tipo de pruebas, estas actividades podrán ser

implementadas en cualquier momento de dicho proceso de desarrollo.

2.2.1 Planificación y diseño de pruebas de software

A. Planificación

El propósito del plan de pruebas es explicitar el alcance, enfoque, recursos

requeridos, calendario, responsables y manejo de riesgos de un proceso de pruebas.

Note que puede haber un plan global que explicite el énfasis a realizar sobre los

distintos tipos de pruebas (verificación, integración e integración).

Resultado de

Pruebas Especificación

Localizar

error

Diseñar

reparación error

Reparación

de error

Volver a

probar

Casos de

pruebas


Un plan de pruebas incluye:

1. Identificador del plan

Preferiblemente de alguna forma mnemónica que permita relacionarlo con su alcance,

por ej. TP-Global (plan global del proceso de pruebas), TP-Req-Seguridad1 (plan de

verificación del requerimiento 1 de seguridad), TP-Contr-X (plan de verificación del

contrato asociado al evento de sistema X), TP-Unit-Despachador.iniciar (plan de

prueba unitario para el método iniciar de la clase Despachador). Como todo artefacto

del desarrollo, está sujeto a control de configuración, por lo que debe distinguirse

adicionalmente la versión y fecha del plan.

2. Alcance.

Indica el tipo de prueba y las propiedades/elementos del software a ser probado.

3. Ítems a probar.

Indica la configuración a probar y las condiciones mínimas que debe cumplir para

comenzar a aplicarle el plan. Por un lado, es difícil y riesgoso probar una configuración

que aún reporta fallas; por otro lado, si esperamos a que todos los módulos estén

perfectos, puede que detectemos fallas graves demasiado tarde.

4. Estrategia.

Describe la técnica, patrón y/o herramientas a utilizarse en el diseño de los casos de

prueba. Por ejemplo, en el caso de pruebas unitarias de un procedimiento, esta

sección podría indicar: "Se aplicará la estrategia caja-negra de fronteras de la

precondición" o "Ejercicio de los caminos ciclomáticos válidos". En lo posible la

estrategia debe precisar el número mínimo de casos de prueba a diseñar, por ej. 100%

de las fronteras, 60% de los caminos ciclomáticos... La estrategia también explicita el

grado de automatización que se exigirá, tanto para la generación de casos de prueba

como para su ejecución.

5. Categorización de la configuración.

Explicita las condiciones bajo las cuales, el plan debe ser:

Suspendido, Repetido; Culminado.

En algunas circunstancias (las cuales deben ser explicitadas) el proceso de prueba

debe suspenderse en vista de los defectos o fallas que se han detectado. Al corregirse

los defectos, el proceso de prueba previsto por el plan puede continuar, pero debe

explicitarse a partir de qué punto, ya que puede ser necesario repetir algunas

pruebas. Los criterios de culminación pueden ser tan simples como aprobar el número

mínimo de casos de prueba diseñados o tan complejos como tomar en cuenta no sólo

el número mínimo, sino también el tiempo previsto para las pruebas y la tasa de

detección de fallas.


6. Tangibles.

Explicita los documentos a entregarse al culminar el proceso previsto por el plan p. ej.

subplanes, especificación de pruebas, casos de prueba, resumen gerencial del proceso

y bitácora de pruebas.

7. Procedimientos especiales.

Identifica el grafo de las tareas necesarias para preparar y ejecutar las pruebas, así

como cualquier habilidad especial que se requiere.

8. Recursos.

Especifica las propiedades necesarias y deseables del ambiente de prueba, incluyendo

las características del hardware, el software de sistemas (p. ej. el sistema de

operación), cualquier otro software necesario para llevar a cabo las pruebas, así como

la colocación específica del software a probar (p. ej. qué módulos se colocan en qué

máquinas de una red local) y la configuración del software de apoyo.

La sección incluye un estimado de los recursos humanos necesarios para el proceso.

También se indican cualquier requerimiento especial del proceso: actualización de

licencias, espacio de oficina, tiempo en la máquina de producción, seguridad.

9. Calendario.

Esta sección describe los hitos del proceso de prueba y el grafo de dependencia en el

tiempo de las tareas a realizar.

10. Manejo de riesgos.

Explicita los riesgos del plan, las acciones mitigantes y de contigencia.

11. Responsables.

Especifica quién es el responsable de cada una de las tareas previstas en el plan.

B. Diseño de casos de prueba

El diseño de casos de prueba es una parte de las pruebas de componentes y

sistemas en las que se diseña los casos de prueba (entradas y salidas esperadas) para

probar el sistema. El objetivo del proceso de diseño de casos de pruebas es crear un

conjunto de casos de pruebas que sean efectivos descubriendo defectos y muestren

que el sistema satisface sus requerimientos.


Para diseñar un caso de prueba, se selecciona una característica del sistema o

componente que se está probando. A continuación, se selecciona un conjunto de

entradas que ejecutan dicha característica, documentan las salidas esperadas o rango

de salidas y, donde sea posible, se diseña una prueba automatizada que prueba

que las salidas reales y esperadas fueron las mismas.

Existen varias aproximaciones que pueden seguirse para diseñar casos de pruebas

las dos principales son:

Pruebas Funcionales: En donde se identifican particiones de entrada y salida

y se diseñan pruebas para que el sistema ejecute entradas de todas las

particiones y genere salidas en todas las particiones. Las particiones son

grupos de datos que tienen características comunes, como todos los números

negativos, todos los nombres con menos de 30 caracteres, todos los eventos

provocados por la elección de opciones en un menú, y así sucesivamente.

Pruebas Estructurales: En donde se utiliza el conocimiento de la estructura

del programa para diseñar pruebas que ejecuten toldas las partes del

programa. Esencialmente, cuando se prueba un programa, debería intentarse

ejecutar cada sentencia al menos una vez. Las pruebas estructurales ayudan a

identificar casos de prueba que puedan hacer esto posible

En general cuando se diseñan casos de pruebas se debería comenzar por las

pruebas de más alto nivel, a partir de los requerimientos y luego de forma

progresiva añadir pruebas más detalladas como las pruebas estructurales o de

particiones.

I. Pruebas Funcionales

Las pruebas funcionales o las pruebas de Caja Negra, se basan en los datos de entrada

y los datos de salida, buscando solamente el resultado sin preocuparse como se

consiguió este.

Sin embargo en estas pruebas los datos de entrada y los resultados de salida

de un programa normalmente se pueden agrupar en varias clases diferentes que

tienen características comunes tales como números positivos, números negativos y

selecciones de menú.

Los programas normalmente se comportan de una forma similar para todos los

miembros de una clase. Es decir, si se prueba un programa que realiza algún cálculo y

requiere 2 números positivos, entonces se esperara que el programa se comporte

de la misma forma para todos los números positivos.

Debido a este comportamiento equivalente, estas clases de denominan a menudo

particiones de equivalencia o dominios. Una aproximación sistemática al diseño

de casos de prueba se basa en identificar todas las particiones para un sistema o


componente. Los casos de prueba se diseñan para que las entradas o salidas

pertenezcan a estas particiones.

Las particiones de equivalencia son conjuntos de datos en donde todos los miembros

de los conjuntos deberían ser procesados de forma equivalente.

Las particiones de equivalencia de salida son resultados del programa que tienen

características comunes, por lo que pueden considerarse como una clase

diferente.

También se identifican particiones en donde las entradas están fuera de otras

particiones que se han elegido. Estas prueban si el programa maneja entradas

inválidas de forma correcta. Las entradas validas e inválidas también forman

particiones de equivalencia.

Se identifican particiones usando las especificaciones del programa o

documentación del usuario y, a partir de la propia experiencia, se predice que

clases de valores de entrada es probable que detecten errores.

Cuando se están probando problemas con secuencias, vectores o listas, existen

varias recomendaciones que a menudo son útiles para diseñar casos de prueba:

1. Probar el software con secuencias que reúne solo un valor. Los

programadores piensan de forma natural que las secuencias están formadas por


varios valores y como consecuencia, el programa puede no funcionar

correctamente cuando se te presenta una secuencia de un único valor.

2. Utiliza varias secuencias de diferentes tamaños en distintas pruebas. Esto

disminuye la probabilidad de que un programa con defectos produzca

accidentalmente una salida correcta debido a alguna característica ocasional en

la entrada.

3. Generar pruebas para acceder al primer elemento, al elemento central y al

último elemento de la secuencia. Esta aproximación pone de manifiesto problemas

en los límites de la partición

II. Pruebas estructurales

Las pruebas estructurales se derivan a partir del conocimiento de la estructura

e implementación del software. Estas se denominan a veces pruebas de “caja

blanca” para distinguirlas de las pruebas de caja negra.

La comprensión del algoritmo utilizado en un componente puede ayudar a

identificar particiones y casos de prueba.

A. Enfoque práctico recomendado para el diseño de casos

El enfoque práctico pretende ser una serie de recomendaciones para el mejor

diseño de casos de pruebas considerando criterios básicos y de distintas

técnicas

1. Si la especificación contiene combinaciones de condiciones de entrada,

comenzar formando grafos de causa-efecto (ayudan la comprensión de dichas

combinaciones).

2. En todos los casos, usar análisis de valores límites para añadir casos de pruebas.

3. Identificar las clases válidas y no válidas de equivalencia para la entrada y la

salida, y añadir los casos no incluidos anteriormente.


4. Utilizar la técnica de conjetura de errores para añadir nuevos casos,

referidos a valores especiales.

5. Ejecutar los casos generados hasta el momento y analizar la cobertura obtenida.

6. Examinar la lógica del programa para añadir los casos precisos (de caja blanca)

para cumplir el criterio de cobertura elegido si los resultados de la ejecución del

punto anterior indican que no se ha satisfecho el criterio de cobertura

elegido.

A veces los desarrolladores se cuestionan por qué se debe examinar todos los

caminos de un programa si es que la funcionalidad ha sido demostrada con las pruebas

de requisitos:

Los errores lógicos y las suposiciones incorrectas son inversamente proporcionales a

la probabilidad de que se ejecute un camino del programa

Se suele creer que un camino lógico tiene pocas probabilidades de ejecutarse

cuando, en realidad, se puede ejecutar regularmente.

Los errores tipográficos son aleatorios; pueden aparecer en cualquier parte del

programa (sea muy usada o no).

La probabilidad y la importancia de un trozo de código suele ser calculada de forma

muy subjetiva.

B. Documentación del diseño de pruebas

Como se mencionó la documentación es una parte fundamental de las pruebas para

poder tener una guía exacta de lo que se realiza y no desperdiciar horas de

trabajo.


Se genera inicialmente la especificación del diseño de la prueba (que surge de la

ampliación y el detalle del plan de pruebas).

A partir de este diseño, se prueba definir con detalle cada uno de los casos

mencionados escuetamente en el díselo de la prueba (se fijan los datos de pruebas

exactos, los resultados esperados, etc.).

Tras generar los casos de prueba detallados se debe especificar cómo

proceder en detalle de la ejecución de dichos casos (procedimiento de

prueba).

Toda la documentación debe ser básica para la ejecución de la prueba pero son los

procedimientos los que determinan como se desarrollara la ejecución.

C. Plan de Pruebas:

Señalar el enfoque, los recursos y el esquema de actividades, así como los

elementos a probar, las características, las actividades, el personal responsable y los

riesgos asociados.

Estructura fijada en el estándar:

Identificador único del documento

Introducción y resumen de elementos y características a probar

Elementos software a probar

Características a probar

Características que no se probarán

Enfoque general de la prueba

Criterios de paso/fallo para cada elemento

Criterios de suspensión y requisitos de reanudación

Documentos a entregar

Actividades de preparación y ejecución de pruebas

Necesidades de entorno

Responsabilidades en la organización y realización de las pruebas

Necesidades de personal y formación

Esquema de tiempos

Riesgos asumidos por el plan y planes de contingencias

Aprobaciones y firmas con nombre y puesto desempeñado

D. Especificación del Diseño de Pruebas

Especificar los refinamientos necesarios sobre el enfoque reflejado en el plan e

identificar las características que se deben probar con este diseño de pruebas

Identificador único para la especificación. Proporcionar también una

referencia del plan asociado (si existe)

Características a probar de los elementos software (y combinaciones de

características)


Detalles sobre el plan de pruebas del que surge este diseño, incluyendo las

técnicas de prueba específica y los métodos de análisis de resultados

Identificación de cada prueba:

Identificador

Casos que se van a utilizar

Procedimientos que se van a seguir

Criterios de paso/fallo de la prueba (criterios para determinar si una

característica o combinación de características ha pasado con éxito la

prueba o no).

E. Especificación de Caso de Pruebas

Definir uno de los casos de prueba identificando por una especificación del

diseño de las pruebas

Identificador único de la especificación

Elementos software (por ejemplo, módulos) que se van a probar: definir dichos

elementos y las características que ejercitará este caso

Especificaciones de cada entrada requerida para ejecutar el caso (incluyendo

las relaciones entre las diversas entradas; por ejemplo, la sincronización de

las mismas)

Especificaciones de todas las salidas y las características requeridas (por

ejemplo, el tiempo respuesta) para los elementos que se van a probar

Necesidades de entorno (hardware, software y otras como, por ejemplo, el

personal)

Requisitos especiales de procedimiento (o restricciones especiales en los

procedimientos para ejecutar este caso).

Dependencias entre casos (por ejemplo, listar los identificadores de los casos

que se van a ejecutar antes de este caso de prueba)

F. Especificaciones del Procedimiento de Prueba

Especificar los pasos para la ejecución de un conjunto de casos de prueba o,

más generalmente, los pasos utilizados para analizar un elemento software con el

propósito de evaluar un conjunto de características del mismo.

Identificador único de la especificación y referencia a la correspondiente

especificación de diseño de prueba.

Objetivo del procedimiento y lista de casos que se ejecutan con él.

Requisitos especiales para la ejecución (por ejemplo, entorno especial o

personal especial).

Pasos en el procedimiento. Además de la manera de registrar los resultados y

los incidentes de la ejecución, se debe especificar:

La secuencia necesaria de acciones para preparar la ejecución.

Acciones necesarias para empezar la ejecución.

Acciones necesarias durante la ejecución.


Cómo se realizarán las medidas (por ejemplo, el tiempo de respuesta)

Acciones necesarias para suspender la prueba (cuando los acontecimientos no

previstos lo obliguen).

Puntos para reinicio de la ejecución y acciones necesarias para el reinicio en estos

puntos.

Acciones necesarias para detener ordenadamente la ejecución.

Acciones necesarias para restaurar el entorno y dejarlo en la situación

existente antes de las pruebas.

Acciones necesarias para tratar los acontecimientos anómalos.

2.2.2 Ejecución de Pruebas de Software

Es la identificación y resolución de problemas antes de ponerlos en producción. Para

asegurarse de que sus aplicaciones funcionen y se ejecuten según los requisitos

empresariales en producción, necesita probarlos antes de la implementación. Junto con

pruebas manuales, para la máxima reutilización y eficacia, deben automatizarse

determinados componentes. La ejecución de pruebas le permite detectar y

solucionar problemas de las aplicaciones antes de ponerlas en producción con el

objetivo de que pueda utilizarlas con seguridad. La ejecución de pruebas evalúa la

capa GUI de la aplicación, así como los componentes fundamentales para una

cobertura integral, junto con pruebas de rendimiento para asegurar la calidad

adecuada en producción.


2.3 Ciclo de Prueba de Software

Existen múltiples enfoques del ciclo de la prueba de software basados en las

experiencias de distintos profesionales, si bien todos son válidos existen pasos que

podemos considerar comunes y que se podrían agrupar entre todos los distintos

modelos.


a) Planear

Es establecer los objetivos y procesos necesarios para conseguir resultados de acuerdo con

los requisitos del cliente y las políticas de la organización.

1. Identificar servicios

2. Identificar clientes

3. Identificar requerimientos de los clientes

4. Trasladar los requerimientos del cliente a especificaciones

5. Identificar los pasos claves del proceso (diagrama de flujo)

6. Identificar y seleccionar los parámetros de medición

7. Determinar la capacidad del proceso

8. Identificar con quien compararse

Un caso de prueba bien diseñado tiene gran posibilidad de llegar resultados más

fiables y eficientes, mejorar el rendimiento del sistema, y reducir los costos en tres

categorías (Perry, 1995):

b) Hacer o ejecutar


Hacer las condiciones. Realizar trabajo de entrenamiento y aprendizaje.

Acordar el procedimiento. Se procede a ejecutar la prueba según los parámetros

previamente fijados y se documentan los resultados haciendo un seguimiento del

camino de los fallos, si hubiera, dentro del sistema y sus características. Generando un

historial de las ejecuciones. La ejecución de las pruebas debería ser en un mínimo

de tiempo y con el mínimo de esfuerzo.

La ejecución nos genera: documentación de los detalles de la prueba y sus salidas, lista

de fallos y sus orígenes. Vemos que en este punto la documentación es muy

importante pues lo que buscamos es expresar de la mejor manera el error y resultados.

Para ello la documentación tiene que ser detallada pero en un lenguaje formal.

c) Chequear o Verificar

Chequear el programa y los resultados obtenidos. En este punto se comparan los resultados

obtenidos de las pruebas con los resultados esperados: información obtenida, tiempos

de respuesta, respuestas ante ataques a la seguridad, etc.

Donde se falla o que parte del software necesita ser reformulada, con el listado de

los errores se generaran informes a los stakeholders. Se generaran sugerencias y

niveles de prioridad a los errores.

d) Actuar

Tomar los cursos de acción decididos respectos de los errores hallados sea reparar,

replantear o implementar alguna otra solución. Se documentaran los detalles de las

modificaciones del software y se pedirá que se ejecuten de nuevo pruebas a los

sectores que han sido modificados.

Definiciones Incorrectas sobre Pruebas de Software

Existen muchas definiciones incorrectas sobre las pruebas del software que conducen a

una inadecuada aplicación de este proceso, por ejemplo [PRESS05]: “Las

pruebas demuestran que no hay errores”, o “Las pruebas demuestran que

un programa funciona correctamente”. Según Edgar Dijkstra “Las pruebas

pueden demostrar la presencia de errores, no su ausencia”. Por lo tanto, se realizan

con el fin de detectar errores que, una vez corregidos, mejoran la calidad o la

fiabilidad del mismo. Existen distintos tipos de pruebas en función de la unidad

de software a la que se aplique y del objetivo que se persiga, por ejemplo, las

pruebas de unidad, de integración, de sistema y de aceptación.


Conclusiones

La verificación y la validación no son lo mismo, ya que la verificación muestra que un

programa satisface su especificación; la validación, que el programa realiza lo que el

usuario requiere.

Las técnicas de verificación estática examinan y analizan el código fuente del

programa para la detección de errores.

Las inspecciones de programa son efectivas para encontrar errores en el programa, y

tiene por objetivo encontrar estos defectos.

Los planes de prueba incluyen los elementos a probar, la agenda de pruebas, los

procedimientos para gestionar el proceso de software y cualquier otro problema que

pueda surgir.

El desarrollo de software de Sala Limpia se basa en técnicas estáticas para la

verificación de programas y pruebas estadísticas para la fiabilidad del sistema.


BIBLIOGRAFÍA http://www.ctr.unican.es/asignaturas/Ingenieria_Software_4_F/Doc/M7_09_V

erificacionValidacion-2011.pdf

http://e-

archivo.uc3m.es/bitstream/handle/10016/12880/PFC_Jorge_Zamora_Hernande

z.pdf?sequence=1

http://www.fing.edu.uy/tecnoinf/mvd/cursos/ingsoft/material/teorico/is09-

Verificacion-Validacion.pdf

http://blog.pucp.edu.pe/item/69595/validacion-y-verificacion-del-software

http://www.fi.upm.es/masteris/sites/www.fi.upm.es.masteris/files/proceso_

V&V_pruebas%20unitarias.pdf

http://clases3gingsof.wikifoundry.com/page/Validaci%C3%B3n

http://www.es.sogeti.com/PageFiles/173/Validacion%20vs%20Testing_Antonio

%20Alvarez.pdf

http://juankenny.blogspot.com/2012/08/vvs-la-verificacion-y-validacion-

de.html

http://sistemas.uniandes.edu.co/~csof5101/dokuwiki/lib/exe/fetch.php?medi

a=principal:csof6101-clase5-1.pdf

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.129.1032&rep=rep

1&type=pdf

http://www.buenastareas.com/ensayos/Verificacion-y-Validacion-De-

Sofware/312349.html

http://prezi.com/nf3wsgks8hs3/validacion-y-verificacion-de-software/

http://www.slideshare.net/jalsina/calidad-del-software-cap1-6051510

http://desasof2004.blogspot.com/2009/06/plan-de-pruebas-de-software.html

http://www.ctr.unican.es/asignaturas/Ingenieria_Software_4_F/Doc/M7_09_VerificacionValidacion-2011.pdf

http://www.ctr.unican.es/asignaturas/Ingenieria_Software_4_F/Doc/M7_09_VerificacionValidacion-2011.pdf

http://e-archivo.uc3m.es/bitstream/handle/10016/12880/PFC_Jorge_Zamora_Hernandez.pdf?sequence=1



http://www.fing.edu.uy/tecnoinf/mvd/cursos/ingsoft/material/teorico/is09-Verificacion-Validacion.pdf

http://www.fing.edu.uy/tecnoinf/mvd/cursos/ingsoft/material/teorico/is09-Verificacion-Validacion.pdf

http://blog.pucp.edu.pe/item/69595/validacion-y-verificacion-del-software

http://www.fi.upm.es/masteris/sites/www.fi.upm.es.masteris/files/proceso_V&V_pruebas%20unitarias.pdf

http://www.fi.upm.es/masteris/sites/www.fi.upm.es.masteris/files/proceso_V&V_pruebas%20unitarias.pdf

http://clases3gingsof.wikifoundry.com/page/Validaci%C3%B3n

http://www.es.sogeti.com/PageFiles/173/Validacion%20vs%20Testing_Antonio%20Alvarez.pdf

http://www.es.sogeti.com/PageFiles/173/Validacion%20vs%20Testing_Antonio%20Alvarez.pdf

http://juankenny.blogspot.com/2012/08/vvs-la-verificacion-y-validacion-de.html

http://juankenny.blogspot.com/2012/08/vvs-la-verificacion-y-validacion-de.html

http://sistemas.uniandes.edu.co/~csof5101/dokuwiki/lib/exe/fetch.php?media=principal:csof6101-clase5-1.pdf

http://sistemas.uniandes.edu.co/~csof5101/dokuwiki/lib/exe/fetch.php?media=principal:csof6101-clase5-1.pdf

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.129.1032&rep=rep1&type=pdf

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.129.1032&rep=rep1&type=pdf

http://www.buenastareas.com/ensayos/Verificacion-y-Validacion-De-Sofware/312349.html

http://www.buenastareas.com/ensayos/Verificacion-y-Validacion-De-Sofware/312349.html

http://prezi.com/nf3wsgks8hs3/validacion-y-verificacion-de-software/

http://www.slideshare.net/jalsina/calidad-del-software-cap1-6051510

http://desasof2004.blogspot.com/2009/06/plan-de-pruebas-de-software.html

verificacion_validacion de software.pdf

Documents