Verificación y Validación de Software CFG M.C Said Zamora
Optimización del código. •
Mejora el tiempo de ejecución.
•
Reduce el tamaño del programa.
•
Debe proveer los mismos resultados que el código original.
Eliminación de código muerto •
(1) x = y + 1;
•
(2) (2) y = 2 * z;
•
(3) (3) x=y+ x=y+z; z;
•
(4) (4) z = 1;
•
(5) z = x;
Variable terminal •
x = y + 1;
•
y = 2 * z;
•
if (t) x = y+z;
•
5z = 1;
•
z = x;
Flujo de control •
Información requerida: •
Variables Variables terminales
•
Información no es explicita
•
Se computa estadísticamente
•
Se caracterizan las ejecuciones dinámicas
•
Considerar ramas tomadas en el flujo de control
Grafica de Flujo de Control •
Representa gráficamente gráficamente el flujo de información en el programa.
•
Utiliza nodos como nodos básicos bás icos de programación.
•
Utiliza aristas de conexión.
Actividad •
Identificar:
•
Nodos
•
Aristas
•
Rutas
•
Rutas terminales.
•
Entradas y salidas de cada nodo
Realizar el CFG •
while (c) { x=y+1; y = 2 * z; if (d) (d) x = y+z; y+z; z = 1; } z = x;
Verificación y Validación alidación de de Software Pruebas de caja blanca M.C Said Zamora
Pruebas de flujo de control •
•
Estr Estra ategia egia de prue prueba bass estr estruc uctu turradas adas que que uti utiliz lizan el fluj flujo o de contr ontrol ol del del progr program ama a como como model modelo. o. Su naturaleza radica en selec elecccionar un conju onjun nto de caminos prueba eba a través del programa, el cual es elegido con la finalidad de llevar a cabo abo un sis sistema ema de prue prueba bass con alt alta confi onfiab abil iliidad. dad.
Las pruebas de flujo de control asumen que •
Las Las espec especifi ifica caci cion ones es está están n corr correc ecta tas. s.
•
Los Los dat datos est están defi defini nid dos y se acc acceden eden adec adecua uad damen amentte.
•
No hay otros errores mas lo que afectan al flujo de control.
•
(PE/POO)
Gráficos de flujo de control •
Representaciones graficas graficas de la estructura de control de un programa.
•
Sus primitivas son: •
Decisión (if/case)
•
Unión (end if/end loop/go to)
•
Bloque de Proceso (Una entrada/ entrada/ una salida, sin saltos)
Caminos •
•
•
Un camino a través de un programa es una secuencia de declaraciones que empiezan con una entrada, unión o decisión y termi ermina nan n en otr otro de est estos elem elemen enttos. os. Pueden pasar sar a través de muchas unione ones, procesos esos o decis ecisiiones y en algunos casos mas de una vez. Los caminos consisten de segmentos, el segmento mas pequeño es un eslabón o proceso eso único que se enc encuent entra ent entre dos nodos.
Caminos •
•
La longitud de un camino es el numero de eslabones que este contiene Un camino de entrada/salida o completo, es aquel que inicia en la entrada de una rutina y termina al fin de la misma.
Revisión total •
Se recorre cada camino de inicio a fin.
•
Se analiz liza cada declaración ión al meno enos una vez.
•
Se analiza cada rama al menos una vez.
Criterios para las pruebas de flujo de control control •
Cami Camino noss anal analiz izad ados os = 100% 100% P
•
Decl Declar arac acio ione ness anal analiz izad adas as = 100% 100% Pa
•
Ramas analizadas = 100% Pb
•
Pa Pb P
•
Se recom ecomie ien nda cober obertu turra de ramas amas y dec declar laracio acion nes de 25% 25%
Selección de caminos •
•
•
Se deben elegir caminos suficientes para alcanzar la cobertura de decl declar arac acio iones nes y ramas. amas. Se recom ecomie iend nda a recor ecorrrer much muchos os camin aminos os simp simple less que que poc pocos per pero mas mas complejos. No hay error en recorrer caminos que analizan el mismo código mas de una vez.
Proceso de pruebas. •
•
•
Real Realiz izar ar las prue prueba bass Observar el resultado y compararlo con el resultado esperado. (Corr (Correcc ección ión por coinci coinciden dencia cia)) La instrument entación de los caminos es necesar saria para confirmar que el resul esulttado ado fue fue obt obtenid enido o por por el camin amino o que que se espe esperraba. aba.
Instrumentación de caminos. •
•
Progr Programa ama de rastr rastreo eo inter interpr pret etati ativo vo Ejecuta cada declaración en orden y registra los valores intermedio s de los cálculos y las etiquetas de declaración que han sid sido recorridas.
Pruebas de flujos de datos. •
•
Utiliz iliza a el grafo de flujo de control para anal nalizar anoma omalías en los datos con la finalidad de desarrollar estrategias de selección de caminos par para una una revis evisió ión n tot total Son estrategias de pruebas basadas en la selección de caminos a través del flujo de control del programa con la finalidad de explorar sec secuenc uencia iass de even eventtos relac elacio iona nado doss al est estado ado de los los obje objettos. os.
•
Se deb deben eleg elegir ir sufi sufici cien enttes camin aminos os con la fina finali lid dad de inic inicia iali lizzar cada ada objeto de datos antes de su uso y utilizar todos los objetos al menos una una vez.
Categorías •
•
Defini Definido do,, cread creado, o, inicia inicializ lizado ado (Esta declarado, se le asigna un nuevo valor , es un archivo que ha sido sido abier abierto to,, se asig asigna na diná dinámi mica came ment nte) e)
•
No defi defini nido do
•
Util Utiliizado ado en cálcu álculo loss o en pred predic icad ados os..
•
read (x, y);
•
z = x + 2;
•
if (z < y)
•
•
•
•
w = x + 1; else y = y + 1; print (x, y, w,z);
•
•
Detección estática de anomalías: Se realiza en el código fuente sin ejecutarlo. (Compiladores) No funciona en variables en desuso, arre arregl glos, os, punt punter eros os y falsa alsass anom anomal alía ías. s. Detección dinámica de anomalías: Se realiza mientras el programa est esta ejec ejecut után ándo dose se y se basa basa en valor alores es int interme ermedi dios os de su ejec ejecuc ució ión. n.
Modelado de flujo de datos •
•
Se basa en el grafico de flujo de control. Cada eslabón es identificado mediante símbolos o secuencias de símbolos que denotan la secuencia de operaciones de datos en ese esla eslabó bón n respe especcto a la varia ariabl ble e de int interés erés..
. •
•
Segmento de camino simple : Cada nodo es a lo mucho visitado una vez. Segmento de camino libre de lazos: Cada nodo es recorrido como muc mucho una vez. ez.
Camino DU •
•
Segmento de camino tal que si el ultimo eslabón tiene utilidad para X, ent entonce oncess el camin amino o es simp simplle y clar laramen amentte defi defin nido. ido. DU corresponde a una tripleta (x, d, u) donde x es una variable, d es un nodo donde se contiene la definición de x y u es una declaración o nodo predicado que utiliza a x y donde hay un sub camino en la grafica de flujo desde d a u donde no se define a x en algún otro mome moment nto o entr entre e ello ellos. s.
Caminos claramente definidos. •
Un camino (i, n1, …, nm, j) esta clarament ente definido respect ecto a x desd esde el nodo i al nodo j si no contiene definiciones de x en los nodos intermedios.
Estrategias para realizar pruebas de flujo de datos. •
•
Todos los caminos DU: Requiere que todos los caminos DU de cada definición de cada variable para cada use de esa definición sean anal analiz izad adas as en algu alguna na prue prueba ba.. Todos odos los los usos usos..
•
read (x,y);
•
for (i = 1; i <= 2; i++) print (“hello”);
•
•
Sa;
•
if (y < 0) Sb;
•
•
•
else print (x);
Todos los usos. •
•
Requ equiere ere que al men menos un camin mino de cada definición de cada variable de cada uso de esa definici ición sea analizado por cada prueba eba. Al menos un camino claramente definido de cada definición de cada variable para cada uso de esa definición sea analizado por alguna prue prueba ba AU es meno menoss efecti ectiv vo que que ADUP ADUP..
Verificación y Validación alidación de de Software Pruebas para sitios web M.C Said Zamora
Como hacer pruebas a un sitio web. •
•
Se trata como omo caja negr egra Cada pagina se interpreta como un estado y los hipervínculos como las las tran transi sici cion ones es entr entre e ello ellos. s.
Hipervínculos. •
Cada vinculo debe ser revisado para para garantizar garantizar su correcta transición.
•
Asegurar su obviedad.
•
Si abre un mensaje de correo electrónico, electrónico, se debe verificar. verificar.
•
Se deben buscar paginas huérfanas.
Gráficos y Formas. •
•
•
¿Se muestran correctamente? correctamente? ¿Están posicionados adecuadamente y muestran las etiquetas correctas? ¿Su flujo de datos es adecuado?
Pruebas de caja gris •
•
Se realizan pruebas de caja negra pero se complementan con revis evisio ione ness del del códi código go par para iden identi tifi fica carr como omo func funcio iona na la pagi pagina na.. Las pruebas de caja blanca se deben realizar sobre el contenido dinámico, bases de datos, paginas generadas automáticamente, segur segurida idad, d, desem desempe peño ño del del servi servido dorr.
Pruebas de configuración configuración y compatibilidad. compatibilidad. •
Plataforma Plataforma de Hardware.
•
Versión del navegador. navegador.
•
Plug ins.
•
Opciones del navegador.
•
Resolución y colores disponibles.
•
Tamaño de texto
•
Velocidad de conexión.
Herramientas para prueba •
www.netmechanic.com
•
Generalmen Generalmente te revisan: revisan: •
•
•
•
Compatib Compatibilida ilidad d del navega navegador dor.. Probl Problem emas as de desem desempe peño. ño. Hipervínc Hipervínculos ulos rotos. rotos. Mala ortogr ortografía. afía.
Verificación y Validación alidación de de Software Inspección de código M.C Said Zamora
Pruebas estáticas de caja blanca •
•
Proceso mediante el cual se analiza cuidadosa y metódicamente el diseño del software, su arquitectura o código para encontrara encontrara errores sin ejecutarlo. Se realizan en una revisión formal del código con la necesidad de identificar problemas de acuerdo a un marco de referencia especificado.
Inspecciones informales del código •
Revisiones por pares.
•
Tutoriales
Inspección formal del código. •
Quien presenta el código no es su autor.
•
Los demás participantes funcionan como inspectores.
•
•
Existe un moderar que se asegura de que se sigan las reglas de referencia. Se realiza un reporte, si es requerido, cambios y una Re inspección.
Checklist: Errores en referencias de datos. •
•
Referencias Referencias a variables no inicializadas. Los índices de los arreglos son enteros y no se exceden sus limites en el uso.
•
Referencias Referencias a indices o arreglos.
•
Uso de variables, constates constates y parámetros.
•
Tipo de datos y su correspondencia con las variables.
•
Punteros y uso de memoria.
•
Definición de estructuras de datos.
Checklist: Errores de declaración de datos •
Las variables tienen el tipo, longitud y clase correctos.
•
La inicialización de la variable es consistente con su tipo.
•
Nombres de las variables.
•
Variables declaradas pero pe ro no utilizadas.
•
Modulo de declaración de variables.
Checklist: Errores de computo •
Diferentes tipos de variable en los cálculos.
•
Mismo tipo de variable pero diferente tamaño.
•
Desbordamiento.
•
Errores de división y modulares.
•
Valores fuera de rango en las variables.
•
Revisión de paréntesis.
Checklist: Errores de comparación •
Operadores relacionales correctos
•
Comparaciones con valores de numero flotante.
•
Consistencia en operadores booleanos.
Checklist: Errores de flujo de control. •
Los lazos tienen fin.
•
Los switch cierran adecuadamente,
•
Switchs anidados en lazos.
•
Lazos que nunca son ejecutados.
Checklist: Errores en los parámetros de una subrutina. •
Las constantes conservan su valor al llegar a la subrutina.
•
Unidades adecuadas.
•
Tipos y tamaños de parámetros coinciden.
Checklist: Errores E/S •
Disponibilidad de archivos y periféricos.
•
Uso de dispositivos externos.
•
Propiedad de los mensajes de error.
•
Uso adecuado de excepciones.
Checklist •
Prueba Lint: http://www.jslint.com/
•
Uso de sistemas operativos
•
Uso de ASCII y Unicode
Verificación y Validación alidación de de Software Documentación M.C Said Zamora
En la antigüedad… •
•
La documentación consistía en un archivo readme.txt en un disco fle flexibl xible e y much muchos os comen omenttario arioss en el códig ódigo. o. La revisión de la documentación consistía solamente en revisar la orog orogrrafía afía de la mism misma. a.
Tipos de documentación documentación •
•
•
•
•
•
•
•
•
•
•
Texto xto y gráf gráfic icos os en el empa empaqu que. e. Mate Ma teria riall de mark marketing. eting. Regis Registr tros os y gara garant ntía. ía. Acuer cuerd do de uso de la lice licen ncia. cia. Etiquetas. Instru Instrucci ccione oness de instal instalaci ación ón y config configur uraci ación ón.. Manu Ma nual al de usua usuari rio. o. Ayuda yuda en líne línea. a. Tutori utoriale aless y sesion sesiones es de entr entrena enamie mient nto o automa automatiz tizada adas. s. Muestr Muestras, as, ejempl ejemplos os y plant plantill illas. as. Mensaj Mensajes es de erro errorr.
Pruebas a la documentación. documentación. •
•
•
Mejo Mejorra la usab usabil ilid idad ad,, conf confia iabi bili lida dad d y dism dismin inuy uye e los los costo ostoss de at aten enci ción ón.. Las pruebas de la documentación ión form orman parte de las las prueba ebas de caja negra. Un error en la documentación es tan grave como uno en el código.
Documentos para pruebas en el software. Vagame agament nte e acopla acoplado doss al código código::
•
• •
•
Manual Manu ales es de usua usuari rio o e info inform rmac ació ión n del del empa empaqu que. e. Prueba Pruebass de especi especific ficaci ación ón e inspec inspecció ción n del softw software are..
Acopla Acoplados dos al códig código: o: • •
Tutori utoriale ales, s, entr entrena enami mient entos, os, video videoss y manual manuales es con víncul vínculos. os. Prue Prueba bass de caja caja blan blanca ca y negr negra. a.
Checklist: Pruebas de documentación documentación •
Audiencia objetivo.
•
Terminología.
•
Contenido y temas.
•
Hechos.
•
Todos los pasos.
•
Figuras y capturas de pantalla.
•
Muestras y ejemplos.
•
Ortografía y gramática.
Manuales de referencia automáticos •
Doxygen
•
Javadoc
•
ROBODoc
•
POD
•
TwinText
Verificación y Validación alidación de de Software Métricas M.C Said Zamora
Cuantificación en el software •
No usar sar líneas de código como omo medid edida a del tamañ maño del sof software.
•
Usar Usar nume numerro de prue prueba bass norm normal aliz izad adas as..
•
El tamaño del progr ograma se define en fun función del numero ero espe sperado de errores, las pru prueba ebas requ equerida idas para enc encontrarlas y la efectividad de las las técn técnic icas as util utiliz izad adas. as.
Taxonomía axonomía de las las métricas •
•
Métri étriccas ling lingüí üísstic ticas: as: Evalúa alúan n prop propiiedad edades es del del text xto o del del prog progrrama sin sin interpr interpreta etarr su signif signific icado. ado. Métri étriccas estr estruc uctu turrales ales:: Evalúa alúan n las las relac elacio ione ness estr estruc uctu turrales ales entr entre e los los obje objettos en un prog progrrama. ama.
Líneas de código •
•
Es una medida de la complejidad del software, es tan útil como el tamañ ta maño o del del softw softwar are. e. www.locmetrics.com
Longitud de programa de Halstead •
H = n1log2(n1) + n2log2(n2)
•
n1 : numero ero de operadores en el programa.
•
n2 : numero de opera erandos en el programa.
•
if (y < 0) •
•
pow pow = - y;
else •
pow = y;
•
z = 1.0;
•
while (pow != 0) { •
•
•
•
z = z * x; pow pow = pow pow - 1;
} if (y < 0) •
z = 1.0 / z;
Predicción de errores de Halstead •
B = (N 1 + N2)log2(n1+n2)/3000
•
n1 : numero de operadores o peradores distintos distintos en el programa.
•
n2 : numero de operandos ope randos distintos en el programa.
•
•
N1 :
numero de operadores ope radores totales en el programa.
N2 : numero de operandos o perandos totales en el programa.
Métricas estructurales. estructurales. •
Se ignora la complejidad lingüística.
•
Se analiza la complejidad del flujo de control y de datos.
•
Las métricas se basan en el grafico de flujo del programa.
Complejidad ciclomática. ciclomática. •
La complejidad complejidad ciclomátic ciclomática a de McCabe se define como como M = L – N + 2P
•
L es el numero de lazos en el grafico.
•
N es el numero de nodos
•
P es el numero de elementos desconectados.
•
Propiedad: La complejidad de muchos grafos evaluados en conjunto es equivalente a la suma de las complejidades individuales de esos grafos.
Condicionales compuestos. compuestos. •
Cada predicado de cada condicional compuesta debe ser evaluada por separado.
Uso de la complejidad ciclomática para evaluar el grado de terminación del plan de pruebas. •
Número de casos prueba que proveen cobertura cobertura de ramas.
•
Si el número de casos es menor a M entonces:
•
•
•
•
M se calculo incorrectamente. La cobertura esta incompleta. La cobertura es completa pero se pueden elegir caminos mas sencillos. Se puede simplificar el código.
Cuadrados latinos •
http://wpd.ugr.es/~bioestad/wp-content/uploads/Latinos.pdf http://wpd.ugr.es/~bioestad/wp-content/uploads/Latinos.pdf
