Verificación y Validación de Software M.C M. C Said Zamo mora ra
Temario Análisi Análisis s del Ciclo Ciclo de Vida Vida VVS Pruebas de Software
Medio Medio Curso Curso 20/03/2018
Verificación formal Medición y estimación
Ordinario 04/06/2018
Extrardinario 15/06/2018
Evaluación
%
Tareas (4)
40 (8 +2)
Examen Medio Curso
20
Examen Ordinario
20
Producto In Integrador
20
Contacto Dudas:
[email protected] Asun Asunto to:: Mate Materi ria. a. Tareas:
[email protected] Asun Asunto to:: Mate Materi ria, a,Hora Hora,, # Tarea,Matr ,Matríc ícul ula a o Colo Colorr.
•
Fechas de entrega de tareas
Tarea 1 – 09 Abril Tarea area 2 - 09 Abril Abril Tarea 3 – 18 de Mayo Tarea 4 – 04 de Junio
• Texto:
•
Software Verification and Validation
•
An Engineering and Scientific Approach
•
Marcus Marcus S. Fishe Fisherr
•
https://link.springer.com/boo k/10.1007/978-0-387-479392
Verificación erificación y Validación alidació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) •
Inve Invest stig igar ar sobr sobre e los los sigu siguie ient ntes es inci incide dent ntes es con con “bugs”, que que los los ocasion sionó ó, que que pro problem blema a podí podían an causa ausarr y como omo se ha resue esuelt lto o el pro problem blema. a.
•
•
NAS NASA, mape mapeo o de la capa apa de ozono ono (197 (19788-19 1985 85)) NORA NORAD D (198 (1980) 0) Thera Therac-2 c-25 5 (1985) (1985) Helicópte Helicóptero ro Chinook Chinook (Escocia, (Escocia,1994) 1994) Avión vión de comba mbate JAS 39 (Sue (Sueccia, ia, 1995 1995)) Cohe Cohete te Aria Ariane ne 5 (199 (1996) 6)
•
NASA NASA,, Sond Sonda a par para Orbi Orbittar Ma Mart rte e (199 (1999) 9)
• • • •
Actividad 1.1 (Parte 2) (Equipo) •
Encuentre tres ejemplos adicionales a los anteriores y realicé la investig investigación ación correspond correspondient iente. e.
Defectos en el software. •
Los prog progrramas mas que que desar esarrrolla ollam mos contien tienen en def defecto ctos, per pero lo impo import rtan antte es saber cuantos y de que tipo.
•
Los defectos en el software se ocasionan en la mayoría de los casos por: Defini Definició ción n de requer requerimi imient entos os erróne errónea, a, incom incomple pleta ta e incons inconsis isten tente te.. Falla allass en el dise diseño ño fund fundam amen enttal del del soft softw ware. are. Error Errores es en implem implement entaci ación. ón. Def Defecto ectoss en los los sist sistem emas as de sopo soport rte. e. Prueba Pruebass incomp incomplet letas, as, mala mala verifi verificac cación ió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 soft softw ware are def defectu ectuos oso o en las las sigu siguie ient ntes es área áreass (1 por por área área): ):
•
Apli Apliccació ción de la ley ley Comunicaciones Control Control electora electorall Exploración Exploración espacial espacial Mane Ma nejo jo de dine dinerro Militar Redes Redes eléctr eléctrica icass Transporte
• • • • • • •
Especificación •
Antes de poder decir que el soft oftware contiene ene errores se debe definir nir las las func funcio ione ness del del mism mismo. o.
•
La mayoría de los errores en el software se encuentran en las espe specificacione ones, 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 hace algo lgo que que se indi indicca en las las espe especcific ifica acion cione es.
•
Hace Ha ce algo algo que que las las espe especi cifi fica caci cion ones es indi indica can n que que no debe debe hace hacerr.
•
Hace Ha ce algo lgo que que no est está menc mencio iona nado do en la espe especi cifi ficcación ción..
•
No hace hace alg algo que que no esta menc mencio iona nado do en las espe specifi cificcacion ciones es per pero deb debería ería hacer.
•
El soft softw ware are es difí difíci cill de ente entend nder er,, usar usar,, etc. etc.
Actividad 1.2 (Individual) •
Inv Investi estigu gue e un ejem ejempl plo o de un soft softw ware are comer omerccial ial que que pres presen entta err errores ores conocidos y a partir de sus especificaciones e identifique el tipo de def defect ecto que que pres presen entta y cual cual de las las regla eglass inc incumpl umple. e.
¿Qué hacer con los bugs? •
Los Los bugs bugs debe deben n ser ser enc encontr ontrad ados os,, corr orregid egidos os y se debe deben n solu soluci cion onar ar sus sus efectos medi ediante procesos de comproba obación y análisis que aseg seguran 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 llam llamad ado o Verif erific icac ación ión y Valida alidaci ción ón de Softw Softwar are. e.
Verificación erificación y Validación Validaciónde de Software Seguri Seguridad dad en el software M.C Said Zamora 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 vuln vulner erab abililid idad ades es y la maner nera en que que pued pueden en ser evitad itadas as..
•
Se trat trata a de lidi lidiar ar con los riesgos provocados por por la funcionalidad del software.
La segurid seguridad ad en el software softwareinc inclu luye ye:: •
Interacc Interacción ión humano-c humano-comput omputadora adora
Accesos • Ac •
Encriptaci Encriptación ón y Protocolo Protocolos s de manejo de información. información.
Admini nist stra raci ción ón de riesgos, Audi Audito torí ría a y Monitoreo Monitoreo • Admi •
Legislación
Muchas del de las amenazas de segu seguri rida dad d se derivan de errores en elsoftware. Activi vida dad d 1.3 1.3 (Equ (Equip ipo o) • Acti •
• • • • • • •
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 principa principales les deseguridad deseguridad •
Prevención
•
Detección
•
Reacción
Activ Activida idad d 1.4 1.4 Discusió Discusión n grupal • A
partir de la sigu siguie ient nte e noti notici cia a discu iscutta una estr estrat ateg egia ia que podr podría ía evit evitar ar estas situaciones en el futuro futuro toman omando do en cuenta los aspectos princi principal pales es de segu seguri rida dad. d.
•
http://money.cnn.com/2015/06/05/technology/applehttp://money.cnn.com/2015/06/ 05/technology/applebugs/index.html
•
Seenvía envía una una conclusión indivi individua duall ygrupal. grupal.
En algu alguna nass ocas ocasiiones ones cubrir un aspecto de seguridad seguridad llev lleva a a nuevasvulner nuevas vulnerabilidade abilidadess •
SSH
•
www.cert.org/advisories for fo r (Ope (Open) n)S SSH •
CA-200 CA-2002-3 2-36 6 Mult Mu ltip iple le Vulnerabilities in SSHImplementations (Diciembre16)
•
CA-2003-2 CA-2003-24: 4: Buffer Management Vulner Vulnerabi ability lity in Open penSSH (Septiembre 16)
Actividad 1.5(Equipo) •
Utilizando www.cert.org/advisories for fo r (Ope (Open) n)SS SSH H
•
Analice dos cas casos os en los los que el SSHcomo mejo mejora ra de seguridad seguridad ha provocado provocado peores peores problemas y como como se se podrían haber evitado. evitado.
Verificación erificación y Validación Validaciónde de Software Panorama Panorama de las pruebas de software softwa re M.C Said Said Zamora Zamora
Modelos de desarrollo deSoftware •
Repr Repres esen enta tan n la idealidad idealidad del desarrollo.
•
Ningún desa esarrollo llo sigue el modelo elo al pie pie de la letr letra a debi ebido a que: ue: •
Las especifica ificacion iones nunc nunca a corres orrespond ponden en tota to talme lmente nte a las las necesida idades del del cliente.
•
Nunca existe el suficiente tiempo para realizar todas laspruebas.
Axiomas de las prueb pruebas as desoftw desoftware are • • • • • • • • •
Esimposible probar completamente unprogra un programa. ma. Las pruebas de softw software are son ejercicios ejercicios basados basados enriesgos. en riesgos. No es es posible demostrar demostrar la ausenc ausencia ia de de errores mediante mediante laspruebas. las pruebas. Entre mas mas errores se encuentran, mas mas errores habrá. No todos los errores pueden serarreglado ser arreglados. s. En ocasio ocasiones nes es difíci difícill reconocer un erro errorr como tal. tal. Las especificaciones nunca sonfin son finale ales. s. Los “ testers” no son las personas mas populares en el proyecto de desarrollo. Las pruebas de software software comprenden una profesión técnica y disciplinada.
¿Por qué seconsideran axiomas?
Es imposible probar complet completamen amente te unpro unprogr grama. ama. •
Se deberían probar todas las entradas y observar todas sus salidas posi posibl bles es , cons consid ider eran ando do que que las espe espec cifi ificaci cacion one es son corr correc ecta tas s y est están completas.
•
N entradas x Y rutas de proceso = Z salidas, donde Z es numero muy grande.
•
Las especificac especificaciones iones están están sujetas sujetas aint a interp erpret retaci ación. ón.
Las prue prueba bass de software son ejercicios basa basado doss en riesgos. •
Si no se analizan todas las entradas se esta tomando un ries riesgo go..
•
Si se hacen pruebas exce excesi siva vas s el costo y tiem tiempo po de desarrollo hacen el proyecto no viable, si se hacen muy pocas pruebas, la probabilidad de fallas aument a y eso hace que sean mayores los costos de desarrollo.
No es posi posibl ble e dem demostrarl ar la aus ausenci ncia de err errore ores median mediante te lasprueba las pruebas. s. Activi vida dad d 1.6 1.6 (Equip uipo) • Acti •
¿En que consiste la doctrina deDijkstra?
•
¿Cóm ¿Cómo o se relaciona relaciona con este axioma? axioma?
Entre ma mass err errores oresse se encu ncuentran, an, ma mass err errores ores habrá. •
Regularment Regularmente e se se cometen los mismos errores en múlt m últipl iples es ocasio ocasiones nes..
Activi vida dad d 1.6 1.6 (Parte 2) Equipo ipo. • Acti •
¿En que consiste la paradoja del del pesticida? pesticida? Hin Hint: t: Boris Beizer Beizer
No todos odos los los err errores pued puede en ser ser arreglados. • •
No hay tiempo suficiente (no puede haber cambios en la fecha limite, Y2K) No es es un error error (Dam (Damn n you, wrong specificatio specifications) ns)
Esmuy arriesgado arregl arreglarl arlo o No vale vale la pena pena arreglarlo
En ocas ocasio ione ness es difícil reconoc nocer un err errorc or como omo tal. •
Siexiste un problema problema en en el software software y nadie lo lo encue encuentra, ntra, ¿e ¿esun error? error?
•
(Par (Parado adoja ja del árbol árbol que cae cae en el bosque) bosque)
•
Los errores que no han sido descubiertos se llaman errores erroreslatentes. latentes.
Las especificaciones nunca sonfinales. •
El desarrollo llo de software persigue obje bjetivo ivos móviles deb debido ido a fuer fuerte te comp ompetitividad idad entr ntre productos, ciclos de salda al mercado cortos y facilid facilidad ad para para reali realiza zarr mejor mejoras as,,
Los “testers” no son las personas mas populares en el proyecto dedesarrollo. •
Sus actividadesinclu actividades incluyen: yen:
•
Encon Encontr trar ar errores errores
•
Encon Encontr trarl arlos os pronto pronto
Asegurarse de que que sean corr correg egid idos os.. • As
Las pruebas de software software comprendenu comprendenuna na profesión profesión técni técnica ca y disciplinada. disciplinada . desarr rrol ollo los s • A desa
mas elabo aborado rados s, se requ requie iere ren n méto método dos s mas com complej plejos os,, además de que la producción en masa del software requiere de metodo metodologí logías as aplic aplicab able les s a much muchos os casos diferentes. diferentes.
Actividad 1.7(Equipo) •
Investigu tigue una metod todología para la detec tección de errores en el software software y analice su sus ventajas y desventa desventajas. jas.
Activ Activida idad d NP1 (Individu (Individual) al) •
Seleccione un axioma de las pruebas de softwar ware y provea t res ejemplos reale reales s (¡fuen (¡fuentes tes!) !) donde se 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) Investigación)
•
Disminución de probabilidad de ocurrencia(Mitigación/ 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 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/ e ntrada/salida 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 e l programa.
Pruebas de fallos. •
Esta diseñada para utilizar casos prueba que rompan al programa.
•
Los casos de prueba se seleccionan estratégicamente 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.
•
Requiere una perspectiva de usuario final.
•
Los criterios no son precisos.
•
La planeación de las pruebas puede iniciar pronto.
Sistema.
Salidas esperadas.
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 frontera en la operación del software.
•
Pruebas datos validos dentro de los limites posibles.
•
Pruebas los casos de frontera. frontera.
•
Prueban datos fuera de los límites establecidos.
GIGO •
Garb Ga rbag age e in, in, garba garbage ge out. 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:
::= 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) ::= | () | or> ::= + | - | * | / ::= | ::= 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 •
Deli Delimi mittador ador falt altante ante (x+y (x+y
•
Deli Delimi mita tado dorr err erroneo oneo (x+y (x+y]]
•
No es un deli delimi mittador ador (x+y (x+y 1
•
Delimi Delimita tador dores es mal acopl acoplado adoss (x+y)) (x+y))
Fuentes de la Sintaxis •
Colaboracion Colaboracion entre entre diseñador y tester tester
•
Manuales
•
Pantallas de ayuda
•
Documentos de diseño
•
Prototipos
•
Experimentacion
En pruebas de sintaxis • No subestimar a los casos “normales”.
•
No exceder exceder las combian combianciones ciones de prueba. 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 s er especificada en un procesador de texto.
•
Utilice funciones de reemplazo para para incluir entradas inadecuadas.
•
Utilice el diagrama sintáctico.
•
No se deben usar procesos aleatorios aleatorios automaticos 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.