verificacion_validacion de software.pdf
Post on 23-Oct-2015
67 Views
Preview:
TRANSCRIPT
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 1
Validación y Verificación del
Software
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 2
“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
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 3
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.
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 4
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)
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 5
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.
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 6
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.
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 7
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.
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 8
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.
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 9
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.
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 10
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
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 11
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.
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 12
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.
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 13
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.
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 14
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
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 15
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
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 16
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
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 17
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.
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 18
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.
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 19
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
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 20
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
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 21
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.
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 22
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.
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 23
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)
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 24
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.
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 25
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.
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 26
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.
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 27
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
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 28
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.
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 29
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.
VERIFICACION Y VALIDACIÓN DEL SOFTWARE 30
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
top related