Verificación y

Validación de Software

M.C Said Zam ora

Temar io

Análisis del Ciclo de Vida

VVS
Medio Curso
Pruebas de Software 20/03/2018

Verificación formal
Ordinario
Medición y estimación 04/06/2018

Extrardinario
15/06/2018
Evalu ación

Tareas (4) 40 (8 +2)

Examen Medio Curso 20

Examen Ordinario 20

Producto Integrador 20
Cont act o
Dudas: dudassz@hotmail.com

Asunto:Materia.

Tareas: uanlfimerszptar@hotmail.com
Asunto:Materia,Hora, # Tarea,Matrícula o Color.
 • Fechas de entrega de tareas

Tarea 1 – 09 Abril
Tarea 2 - 09 Abril

Tarea 3 – 18 de Mayo
Tarea 4 – 04 de Junio
• Texto:

• Software
Verification and
Validation
• An Engineering and
Scientific Approach
• Marcus S. Fisher

• https://link.springer.com/boo
k/10.1007/978-0-387-47939-
2
Verificación y Validación de
Software

Introducción a la verificación y validación de software

M.C Said Zamora
Error de software (fallo o bug)
• Problema en un sistema de computo que provoca resultados no
deseados.

• En 1947 fue posible asociar un resultado no deseado en las

operaciones de la Harvard Mark II con una polilla que fue atrapada en
un relay, de ahí se asocia a los errores de software con el término
bug.
Actividad 1.1 (Equipo)
• Investigar sobre los siguientes incidentes con “bugs”, que los ocasionó, que
problema podían causar y como se ha resuelto el problema.

• NASA, mapeo de la capa de ozono (1978-1985)

• NORAD (1980)
• Therac-25 (1985)
• Helicóptero Chinook (Escocia,1994)
• Avión de combate JAS 39 (Suecia, 1995)
• Cohete Ariane 5 (1996)
• NASA, Sonda para Orbitar Marte (1999)
Actividad 1.1 (Parte 2) (Equipo)
• Encuentre tres ejemplos adicionales a los anteriores y realicé la
investigación correspondiente.
Defectos en el software.
• Los programas que desarrollamos contienen defectos, pero lo importante
es saber cuantos y de que tipo.

• Los defectos en el software se ocasionan en la mayoría de los casos por:

• Definición de requerimientos errónea, incompleta e inconsistente.
• Fallas en el diseño fundamental del software.
• Errores en implementación.
• Defectos en los sistemas de soporte.
• Pruebas incompletas, mala verificación.
• Evolución, crear nuevas fallas en un intento de resolver problemas
anteriores.
Actividad 1.1 (Parte 3) (Equipo)
• Proporcione ejemplos reales (incluir fuente) de efectos adversos de
software defectuoso en las siguientes áreas (1 por área):

• Aplicación de la ley
• Comunicaciones
• Control electoral
• Exploración espacial
• Manejo de dinero
• Militar
• Redes eléctricas
• Transporte
Especificación
• Antes de poder decir que el software contiene errores se debe definir
las funciones del mismo.

• La mayoría de los errores en el software se encuentran en las

especificaciones, no en el diseño o en el código.
Un error en el software ocurre al presentarse
al menos una de estas reglas.
• No hace algo que se indica en las especificaciones.

• Hace algo que las especificaciones indican que no debe hacer.

• Hace algo que no está mencionado en la especificación.

• No hace algo que no esta mencionado en las especificaciones pero debería

hacer.

• El software es difícil de entender, usar, etc.

Actividad 1.2 (Individual)

• Investigue un ejemplo de un software comercial que presenta errores

conocidos y a partir de sus especificaciones e identifique el tipo de
defecto que presenta y cual de las reglas incumple.
¿Qué hacer con los bugs?
• Los bugs deben ser encontrados, corregidos y se deben solucionar sus
efectos mediante procesos de comprobación y análisis que aseguran
que el desarrollo ocurre de acuerdo a su especificación y cumple con
el objetivo primordial de su diseño, este conjunto de procesos es
llamado Verificación y Validación de Software.
Verificación y Validaciónde
Software
Seguridad en el software

M.C Said Zamora

Seguridad en elsoftware
• Se refiere a los principios, métodos y tecnologías para hacer el
software mas seguro, identificando amenazas típicas y
vulnerabilidades y la manera en que pueden serevitadas.

• Se trata de lidiar con los riesgos provocados por la funcionalidad del

software.
La seguridad en el softwareincluye:
• Interacción humano-computadora
• Accesos
• Encriptación y Protocolos de manejo de información.
• Administración de riesgos, Auditoría y Monitoreo
• Legislación
Muchas de las amenazas deseguridad se derivan de
errores en elsoftware.
• Actividad 1.3 (Equipo)

• Investigué los siguientes errores de software que desembocaron en amenazas de

seguridad, como se provocaron, los daños que han causado y como se ha resuelto el
problema.

• BadUSB
• DrownAttack
• Glibc
• GoToFail
• Heartbleed
• POODLE
• Quadrooter
Aspectos principales deseguridad
• Prevención

• Detección

• Reacción
Actividad 1.4 Discusióngrupal
• A partir de la siguiente noticia discuta una estrategia que podría
evitar estas situaciones en el futuro tomando en cuenta los aspectos
principales de seguridad.

• http://money.cnn.com/2015/06/05/technology/apple-
bugs/index.html

• Seenvía una conclusión individual ygrupal.

En algunas ocasiones cubrirun aspecto de
seguridad lleva a nuevasvulnerabilidades
• SSH

• www.cert.org/advisories for (Open)SSH

• CA-2002-36 Multiple Vulnerabilities in SSHImplementations (Diciembre16)

• CA-2003-24: Buffer Management Vulnerability in OpenSSH (Septiembre 16)

Actividad 1.5(Equipo)
• Utilizando www.cert.org/advisories for (Open)SSH

• Analice dos casos en los que el SSHcomo mejora de seguridad ha provocado

peores problemas y como se podrían haberevitado.
Verificación y Validaciónde
Software
Panorama de las pruebas de software

M.C Said Zamora

Modelos de desarrollo deSoftware
• Representan la idealidad del desarrollo.

• Ningún desarrollo sigue el modelo al pie de la letra debido a que:

• Las especificaciones nunca corresponden totalmente a las necesidades del

cliente.

• Nunca existe el suficiente tiempo para realizar todas laspruebas.

Axiomas de las pruebas desoftware
• Esimposible probar completamente unprograma.
• Las pruebas de software son ejercicios basados enriesgos.
• No es posible demostrar la ausencia de errores mediante las pruebas.
• Entre mas errores se encuentran, mas errores habrá.
• No todos los errores pueden serarreglados.
• En ocasiones es difícil reconocer un error como tal.
• Las especificaciones nunca sonfinales.
• Los “testers” no son las personas mas populares en el proyecto de
desarrollo.
• Las pruebas de software comprenden una profesión técnica y disciplinada.
¿Por qué seconsideran
axiomas?
Es imposible probar completamente unprograma.

• Se deberían probar todas las entradas y observar todas sus salidas

posibles , considerando que las especificaciones son correctas y están
completas.

• N entradas x Yrutas de proceso = Z salidas, donde Z es numero muy

grande.

• Las especificaciones están sujetas ainterpretación.

Las pruebas de software son ejerciciosbasados en
riesgos.
• Si no se analizan todas las
entradas se esta tomando
un riesgo.

• Si se hacen pruebas
excesivas el costo y tiempo
de desarrollo hacen el
proyecto no viable, si se
hacen muy pocas pruebas,
la probabilidad de fallas
aumenta y eso hace que
sean mayores los costos de
desarrollo.
No es posible demostrar la ausencia de errores
mediante laspruebas.
• Actividad 1.6 (Equipo)
• ¿En que consiste la doctrina deDijkstra?
• ¿Cómo se relaciona con este axioma?
Entre mas errores se encuentran,mas errores
habrá.
• Regularmente se cometen los mismos errores en múltiples ocasiones.

• Actividad 1.6 (Parte 2) Equipo.

• ¿En que consiste la paradoja del pesticida? Hint: Boris Beizer

No todos los errorespueden ser arreglados.

• No hay tiempo suficiente (no puede haber cambios en la fecha limite,

Y2K)
• No es un error (Damn you, wrong specifications)

Esmuy arriesgado arreglarlo

No vale la pena arreglarlo

En ocasiones es difícilreconocer un error como
tal.
• Siexiste un problema en el software y nadie lo encuentra, ¿esun error?
• (Paradoja del árbol que cae en elbosque)

• Los errores que no han sido descubiertos se llaman erroreslatentes.

Las especificaciones nunca sonfinales.

• El desarrollo de software persigue objetivos móviles debido a fuerte

competitividad entre productos, ciclos de salda al mercado cortos y
facilidad para realizar mejoras,
Los “testers” no son las personas mas
populares en el proyecto dedesarrollo.

• Sus actividadesincluyen:
• Encontrar errores
• Encontrarlos pronto
• Asegurarse de que sean corregidos.
Las pruebas de software comprendenuna
profesión técnica y disciplinada.
• A desarrollos mas elaborados, se requieren métodos mas complejos,
además de que la producción en masa del software requiere de
metodologías aplicables a muchos casos diferentes.
Actividad 1.7(Equipo)
• Investigue una metodología para la detección de errores en el
software y analice sus ventajas y desventajas.
Actividad NP1 (Individual)
• Seleccione un axioma de las pruebas de software y provea
tres ejemplos reales (¡fuentes!) donde se cumple
totalmente.
Administración de Riesgos
• Potencial de ocurrencia de las consecuencias negativas de un evento.

• Probabilidad de ocurrencia

• Cualitativas
• Cuantitativas

• Consecuencias

• Cualitativas
• Cuantitativas
Etapas
• Identificar

• Analizar

• Planear

• Rastrear

• Controlar
Identificación de riesgos

• Lluvia de ideas

• Lista de revisión

• Lecciones aprendidas

• Incertidumbres individuales

• Cuestionario Taxonómico

• Análisis de V V
Métodos para análisis de riesgos
Tipos de consecuencias
• Catastróficas

• Criticas

• Marginales

• Negligibles
Exposición a riesgos
Planeación
• Declaración de Riesgos
• Descripción
• Atributos
• Exposición

• Nivel de Exposición (Observación/)

• Nivel de Información (/ Investigación)

• Disminución de probabilidad de ocurrencia(Mitigación/ Aceptación)

Plan de Administración de Riesgos
• Revisión

• Organización

• Procesos

• Comunicación

• Recursos y Tiempos

• Bases de datos de riesgos

Estructura de comunicación embebida
Estructura de comunicación interna
Estructura de comunicación independiente
Pruebas de caja negra dinámicas.
• Son dinámicas porque se realizan durante la ejecución del programa.

• No se tiene conocimiento de como esta implementado el programa.

• Requiere un programa ejecutable y al menos un manual de usuario.

• Los casos prueba se formulan como pares entrada/salida esperada-

Datos y Casos de Prueba.
• Datos de prueba: Entradas formuladas para probar el sistema.

• Casos de prueba: Entradas de prueba y sus resultados predichos de

acuerdo a la especificación del sistema.
Prueba a pasar
• Se asegura que el software al menos funciona.

• No busca forzar la capacidad del software.

• Utiliza casos de prueba sencillos y directos.

• No trata de romper el programa.

Pruebas de fallos.
• Esta diseñada para utilizar casos prueba que rompan al programa.

• Los casos de prueba se seleccionan estratégicamente para probar

debilidades comunes en el software.
Características de las pruebas de caja negra.
• El programa es tratado como un caja negra.
Casos de prueba

• Los detalles de la implementación no son relevantes.

Sistema.
• Requiere una perspectiva de usuario final.

• Los criterios no son precisos.

Salidas
esperadas.
• La planeación de las pruebas puede iniciar pronto.
Partición de equivalencias.
• Proceso mediante el cual se reduce el conjunto de posibles casos de
prueba a un conjunto pequeño pero efectivo.
• Entradas que cumplen con las condiciones previas.

• Entradas donde una condición previa no se cumple.

• Entradas conde el elemento clave se encuentra en el arreglo.

• Entradas conde el elemento clave no se encuentra en el arreglo.

Arreglo Elemento
Valor único Esta en el arreglo
Valor único No esta en el arreglo
Mas de un valor Primer elemento del arreglo
Mas de un valor Ultimo elemento del arreglo
Mas de un valor Elemento en medio del arreglo
Mas de un valor No esta en el arreglo
Limites de los datos de entrada.
• Son condiciones de frontera en la operación del software.

• Pruebas datos validos dentro de los limites posibles.

• Pruebas los casos de frontera.

• Prueban datos fuera de los límites establecidos.

GIGO
• Garbage in, garbage out.

• Falta de validaciones.

• Prueba la tolerancia del sistema para datos inadecuados.

• Se debe ser creativos con las basura.

Notación BNF (Backus-Naur Form).
• Notación BNF: <elemento no terminal>::= Definición1 | Definición2 | ...
• Los elementos terminales, o sea, que pertenecen al vocabulario, se escriben tal
cual.
• Los elementos no terminales se escriben entre los símbolos <>.

• Ejemplo: Descripción sintáctica de una expresión matemática en notación BNF:

• ---> 4*(3+1)
• <expresión> ::= <numero> | (<expresión>) | <expresión><operador><expresión>
• <operador> ::= + | - | * | /
• <numero> ::= <digito> | <numero><digito>
• <digito> ::= 1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 0
Generación de casos prueba.
• No se reconoce una entrada adecuada.
• Se aceptan entradas inadecuadas.
• El programa colapsa al tratar de reconocer una entrada.

• Se debe generar un error a la vez, considerando el resto de variables

sin presencia de errores. Después se sigue con dos o mas errores
simultáneos.
Errores de delimitación
• Delimitador faltante (x+y
• Delimitador erroneo (x+y]
• No es un delimitador (x+y 1
• Delimitadores mal acoplados (x+y))
Fuentes de la Sintaxis
• Colaboracion entre diseñador y tester
• Manuales
• Pantallas de ayuda
• Documentos de diseño
• Prototipos
• Experimentacion
En pruebas de sintaxis
• No subestimar a los casos “normales”.

• No exceder las combianciones de prueba.

• Si se automatizan las pruebas, no se debe incluir las pruebas GIGO en

el proceso de automatización.
Automatización del diseño.
• La cobertura del conjunto de entradas adecuadas puede ser
especificada en un procesador de texto.

• Utilice funciones de reemplazo para incluir entradas inadecuadas.

• Utilice el diagrama sintáctico.

• No se deben usar procesos aleatorios automaticos para generar

entradas de datos.
Diagramas sintácticos.
• Es una representación gráfica de la sintaxis.
• Los elementos terminales se inscriben en una elipse. Los elementos
no terminales se inscriben en un rectángulo.