Diapositiva 1

Testing y CalidadInspeccionesIntroduccin[1970] Creencia de la comunidad de programacin de que los programas son escritos aisladamente para que los ejecute una mquina y no para que las personas los lean.Por lo tanto, se crea que la nica manera de probar el programa era ejecutndolo.Proceso de non-computer based testing.Idealmente entre que se comienza a construir cdigo y el tiempo en que computer-based testing comienza. Sabemos que Mientras antes encontremos los errores, menores sern los costos de corregirlos. Presin sicolgica al iniciar el computer-based testing programadores tienden a aumentar sus tasas de introduccin de errores por bug que resuelven.Mtodos primarios de pruebas usados por humanos TiposInspecciones WalkthroughsAmbos incluyen un equipo de personas que leen o inspeccionan visualmente el cdigo.Incluyen tiempo de preparacinObjetivo: encontrar errores pero no sus soluciones. (test no debug)Mtodos primarios de pruebas usados por humanos VentajasCuando se encuentra un defecto usualmente se sabe la posicin en el cdigo.Permiten encontrar efectivamente un 30 a 70% ms de errores en la lgica de diseo y defectos en el cdigo. Inspecciones de cdigo2.1.-Inspecciones de SoftwareUna inspeccin de software es una revisin, acuciosa y minuciosa de productos de software , en busca de defectos.Las inspecciones buscan estos defectos en funcin de diversos criterios ( lgicos, funcionales, de implementacin, etc.) Estas inspecciones cambian de concepto de defecto, segn se avance en el proceso de construccin del software.En cada proceso, el defecto toda vez identificado, deber ser removido y revisado nuevamente hasta obtener el resultado esperado.La inspeccin es una actividad que se realiza en post de garantizar la calidad del producto final

Plan de garanta de calidad( definicin del plan de garanta de calidad IEEE 730-1989)El plan de calidad establece todas aquellas actividades que se realizarn para garantizar la calidad del sistema. Estas actividades son especficas para los diferentes productos de software obtenidos en las diferentes etapas del desarrollo y su aplicacin harn que el producto final cumpla con los requisitos planteados inicialmente.

El plan de garanta de calidad ( Documentos)Planificacin del proyecto, que incluye especificacin y validacin de requisitos del software (ERS) y estimacin.Planes de gestin: gestin de calidad y gestin de la configuracin del software (GCS), as como un seguimiento de la planeacin.Diseo de alto nivel, de todo el sistema.Diseo de bajo nivel, de los componentes del sistema.Plan de Pruebas.Informe de verificacin y validacin.Modelo de la amplificacin de defectos

Errores pasadosAl siguiente paso=Defectos * porcentaje de Eficiencia de deteccin de erroresEjemplo: Efecto de Amplificacin de Defectos

Ejemplo: Efecto de Amplificacin de Defectos con Revisiones

Inspecciones de cdigoConjunto de procedimientos y tcnicas para detectar erroresUsualmente consiste de cuatro personas.Moderador ingeniero de control de calidadProgramador DiseadorEspecialista de pruebasProcedimientoTerminada la sesin, el programador recibe una lista de erroresSi son substanciales entonces se cita a una reinspeccin.La lista es analizada y categorizada y la lista de errores tipicos mejorada para inspecciones futuras.Tiempo ptimo 90 a 120 minutos.Tasa tipica 150 sentencias por hora.Inspecciones de cdigoTpicos errores

datos de referenciaclculo1.- Utilizado Variable Unset? 1. Los clculos sobre las variables nonarithmetic?2. Los subndices dentro de lmites?2. Los clculos de modo mixto?3. Los subndices no enteros?3. Los clculos sobre las variables de diferentes longitudes?4. Referencias cuelgan?4. Tamao del objetivo menor que el tamao del valor asignado?5. atributos correctos cuando aliasing?5. desbordamiento resultado intermedio o por defecto?6. Grabar y estructura atributos partido?6. La divisin por cero?7. Clculo de direcciones de cadenas de bits?Pasar argumentos poco cuerdas?7. Base-2 inexactitudes?8. Sobre la base de almacenamiento atributos correcta?8. Valor de variable fuera del rango significativo?9. Definiciones de estructuras coinciden travs procedimientos?Precedencia 9. Operador entiende?10. Off-por-uno los errores en la indexacin o las operaciones subndices?Divisiones 10. Integer correcta?Requisitos de herencia 11. se cumplen?16

Declaracin de datoscomparacin1. Todas las variables declaradas?1. La comparacin entre las variables incompatibles?2. Los atributos predeterminados entendieron?2. comparaciones de modo mixto?3. Arrays y cadenas inician correctamente?3. Relaciones de la comparacin de la correcta?4. longitudes, tipos y clases de almacenamiento correcto asignado?4. Las expresiones booleanas correcta?5. La inicializacin consistente con la clase de almacenamiento?5. Comparacin y expresiones booleanas mezclan?6. Las variables con nombres similares?6. Las comparaciones de la base-2 valores fraccionarios?Precedencia 7. Operador entiende?8. Evaluacin del compilador

17

Interfacesotras comprobaciones1. Nmero de parmetros de entrada igual nmero de argumentos?1. Cualquier variable no referenciados en la lista de referencias cruzadas?2. El parmetro y argumento atributos partido?2. Lista de atributos lo que se esperaba?3. Parmetro y el sistema de unidades argumento partido?3. Cualquier mensaje de aviso o informativos?4. Nmero de argumentos transmitidos a los llamados mdulos en igual nmero de parmetros?4. Entrada para comprobar la validez?5. Atributos de argumentos transmitidos a los llamados mdulos iguales a los atributos de los parmetros?5. Funcin falta?Sistema 6. Unidades de argumentos transmite a los llamados mdulos de igualdad al sistema de unidades de los parmetros?7. Nmero, atributos, y el orden de los argumentos de las funciones incorporadas en la correcta?8. Las referencias a parmetros no asociados con el punto actual de la entrada?9. argumentos de entrada slo alterados?10. definiciones de variables globales a travs de mdulos coherentes?11. Constantes pasan como argumentos?19Punto de TareaListar cada tipo de error tpico dos ejemplos, dentro del contexto del problemaInspecciones de cdigoEjemplo: inspecciones de FaganSesin 12Ingeniera de Software - 201222Inspecciones FaganDesarrolladas en 1972, por Michael FaganBeneficios: prevencin y reduccin de defectos, y por ende de costosProceso de inspeccin en 6 etapasSesin 12Ingeniera de Software - 201223Inspecciones FaganEtapasPlaneacin -- preparacin logstica (materiales, disponibilidades, fechas)Overview -- conocimiento general, asignacin de roles (autor, lector, tester, moderador)Preparacin -- estudio del material a ser inspeccionadoInspeccin -- bsqueda de defectosRetrabajo -- hacer las correccionesIteracin -- verificacin de lo realizado, y de la no introduccin de efectos secundariosRework

AutorInspeccin

TodosPreparacinModerador, Presentador, Inspectores OrientacinModerador, Autor, InspectoresPlanificacin

Moderador, AutorSeguimiento

Moderador, AutorWalkthroughsWalkthroughsConjunto de procedimientos y tcnicas de deteccin de error para lectores de cdigo La diferencia radica en las tcnicas empleadas para detectar errores.Tambin se lleva a cabo en una reunin de una a dos horas.Tres a cinco personasModeradorSecretarioTesterProgramador senior, experto en el lenguaje de programacin, un nuevo programador, el mantenedor del programa, alguien de otro proyecto o alguien del equipo de programacin.ProcedimientoTesters vienen a la reunin con un conjunto pequeo de casos de pruebas con representativas entradas y salidas esperadasDurante la reunin cada prueba es ejecutada mentalemente, probablemente paseando a los datos de prueba por la lgica del programa.Los casos deben ser simples.Son los gatilladores para el procesos de preguntas al programador.ProcedimientoAl igual que en las inspecciones, la actitud es fundamentalLos erorres no son debilidades de las personas que los introdujo. Son inherentes al difcil proceso de desarrollo.Tambin posee un proceso de follow-up Peer ratingsNo es una tcnica de testing pero si para facilitar la lectura del cdigo.Tcnica de evaluar annimamente programas en trminos de su calidad, mantenabilidad, extensibilidad, usabilidad y claridad.

ProcedimientoUn programador es seleccionado para servir como administrador del proceso.El administrador selecciona 6 a 20 participantes (se debe mantener el anonimato)Los participantes deben tener conocimiento parecidoA cada participante se le solicita cuatro de sus programas, donde dos deberan estar entre sus mejores trabajos y otros dos entre los ms pobres.

ProcedimientoSe distribuyen aleatoriamente a los participantesCada participante se le asignan hasta cuatro programas para revisar (mitad y mitad)Cada participantegasta hasta 30 minutos por programa y completa el formulario de evaluacinLuego de revisar todos los trabajos califica la calidad de los cuatro programas acorde a lo que recibi.Se entregan las revisiones a los autores. Formulario de evaluacinEscala de 1 a 7 (donde 7 siginifica definitivamente si, y 1 significa definitivamente no)Es el programa fcil de entender?Es el diseo de alto nivel visible y razonable?El el diseo de bajo nivel visible y razonable?Cuan fcil es modificar este programa?Estara orgulloso de haber escrito este programa?Comentarios generales y mejoras sugeridas. Preguntas

Clases de pruebaPruebas usando caja negraIdentifica los defectos acorde al mal funcionamiento del software.Pruebas usando caja blanca (caja de vidrio)Examina los caminos internos de clculo identificando defectos.Clases de TestingAcorde a la IEEEPruebas usando caja negraPruebas que ignoran el mecanismo interno del sistema o de los componentes slo enfocandose en las salidas generadas en respuestas a las entradas seleccionadas y condiciones de ejecucin.Pruebas condicidas para evaluar la satisfaccin de un sistema o componente con los requerimientos funcionales especificados.Pruebas usando caja blanca (caja de vidrio)Pruebas que toman en cuenta los mecanismos internos de un sistema o componente.Clasificacin de los requerimientos de calidad

Clasificacin de los requerimientos de calidad

Clasificacin de los requerimientos de calidad

Cuando uso caja blanca o caja negra?

MetodologasCaja negraParticionamiento equivalenteAnlisis de valores lmiteGrafo causa efectoAdivinanza de erroresCaja blancaCubrimiento de sentenciasCubrimiento de caminosCaja blancaGrado en que los casos de prueba cubren la lgica del programa cdigo fuentePruebas de procesamiento de datos y correctitud de clculosCubrimiento?Cubrimiento de caminos (mtrica: porcentaje de caminos cubiertos)Cubrimiento de sentencias42Cubrimiento de caminosDiferentes caminos: IFTHENELSE or DO WHILE or DO UNTIL.Cubrirlos todos: imprcticoNmero de caminos posibles para un mdulo simple conteniendo 10 sentencias condicionales simples implica aproximadamente 1024 caminos al menos 1024 casos.Cubrimiento de lneasSe requiere que toda lnea sea ejecutada al menos una vez.Tipicamente se utiliza un diagrama de flujo.Ejemplo 1

CriterioEscribir suficientes casos de manera que cada decisin sea true o false al menos una vez.

Notacin grafos de flujoMuestra el flujo de control

Ejemplo Grafos de flujoRegiones: reas acotadas por reas y nodos.

48Ejemplo Grafos de flujo

Determinar las Rutas y Complejidad ciclomaticaV(G)=6Son 6 rutas

1-2-10-11-131-2-10-12-131-2-3-4-5-8-9-21-2-3-4-5-6-8-9-21-2-3-4-6-7-8-9-2

49Complejidad ciclo maticaProporciona cota superior para el numero de rutas independientes que forman el conjunto bsico => numero de pruebas que deben disearse y ejecutarse para garantizar cobertura de todo el programa

Calculo complejidad ciclomatica

V(G)= Numero de regiones del grafico

V(G)= E-N+2E=AritasN=nodos

V(G)= P+1P=Numero nodos predicados

50Ejemplo 2Servicio de Taxi Imperial para pasajeros. La tarifa se calcula del siguiente modo:Tarifa mnima: $800 (hasta 900 metros y tiempo de espera hasta 3 minutos)Por cada 300 metros adicionales o pare: $50 Por cada 2 minutos adicionales detenido o esperando: $20 Una maleta: sin cargo. Cada maleta adicional: $100Cargo nocturno: 25% efectivo para viajes entre las 21:00 y las 06:00Clientes regulares tienen un descuento de 10% y no tienen cargo nocturnoREALIZAR GRAFO DE FLUJO QUE PERMITA RESOLVER LA PROBLEMTICA, JUNTO A LOS CAMINOS POSIBLES Y LA COMPLEJIDAD CICLOMATICAMtrica de complejidad ciclomticaMcCabeMcCabe en 1976 desarroll la mtrica de complejidad ciclomtica de un programa.Este permite determinar el nmero mximo de caminos independientes necesarios para alcanzar un cubrimiento de lneas completas de un programa.La medida est basada en teora de grafosMtrica de complejidad ciclomticaMcCabeCamino independiente es definido con referencia a la sucesin de caminos independientes acumulados:Cualquier camino de un grafo de flujo del programa que incluya al menos una arista que no est incluida en ningn otro camino independiente.Mtrica de complejidad ciclomtica V(G) se expresa en tres maneras diferentesClculo de V(G)Grafo de flujo del programa

V(G) = ?????R es el nmero de regionesE nmero de aristasN nmero de nodosP nmero de decisiones contenidas en el grafo (nodos que tienen ms de una arista saliendo)V(G) = RV(G)=E-N+2V(G)=P+1

V(G) = 6V(G)=21-17+2=6V(G)=P+1=5+1

54Conjunto mximo de caminos independientes

Ventaja: slo debemos probar 6 caminos en vez de 24En general respecto a la mtricaJones en 1996 dice que programas con complejidad ciclomtica menos que 5 son considerados generalmente simples de entender. Ms de 5 y hasta 10, medianamente compleja. Entre 10 y 20 compleja, sobre 20 complejidad alta. Si supera 50 entonces es imprctica para propsitos de pruebas.Otros como Fenton dice que no hay soporte estadstico para esta aseveracin.56Caja negraParticin de equivalenciaAnlisis de valor frontera

Si se desea pagar extra las pruebas de correctitud, mantenabilidad pueden ser realizados usando caja blanca.

57Pruebas de Caja Negra.Intenta encontrar errores de las siguientes categoras:Funciones Incorrectas o Ausentes.Errores de Interfaz.Errores en estructuras de datos o acceso a bases de datos externas.Errores de rendimiento.Errores de inicializacin y terminacin.Pruebas de Caja Negra. Variantes de pruebas de caja negra.

a) Mtodos de prueba basados en grafos.b) Particin Equivalente.c) Anlisis de valores lmite.d) Prueba de Comparacin.e) Conjetura de Errores.Mtodos de prueba basados en grafosPasos a seguir para una prueba de cajaNegra:

Las pruebas basadas en grafos empiezan con la definicin de todos los nodos y peso de nodos.Una vez que se han identificado los nodos, se deberan establecer los enlaces y los pesos de enlaces.Cada relacin es estudiada separadamente, de manera que se puedan obtener casos de prueba.Definir una serie de pruebas que verifique que todos los objetos tienen entre ellos la relaciones esperadas

Particin equivalentePasos para identificar clases de equivalencia.

Identificacin de las condiciones de entrada del programa.

Identificar las clases de equivalencia:Datos vlidos.Datos no vlidos.Particin equivalentePasos para identificar casos de prueba.

Asignar un nmero nico para cada clase de equivalencia.Escribir casos de pruebas para todas las clases vlidas.Escribir casos de pruebas para todas las clases no vlidas.Ejemplo de clases de equivalenciaAplicacin bancaria en la que el operador debe proporcionar un cdigo, un nombre y una operacin.Condicin de EntradaClases VlidasClases InvlidasCdigo de rea# de 3 dgitos que noempieza con 0 ni 1:1) 200 cdigo 9992) Cdigo < 200.3) Cdigo > 999.4) No es nmero.NombrePara identificar la operacin 5) Seis caracteres.6) Menos de 6 caracteres.7) Ms de 6 caracteres.OrdenUna de las Siguientes 8) Cheque9) Depsito10) Pago factura11)Retiro de fondos 12) Ninguna orden vlidaAnlisis de valores limiteUn mayor numero de errores ocurre en las fronteras deldominio de entrada y no en el centro.Complementa a la particin de equivalenciaLas reglas para identificar las clases son:

Si una condicin de entrada especifica un rango que deben generar casos para los extremos.Si la condicin de entrada especifica un nmero finito y consecutivo de valores, escribir casos para los nmeros mximo, mnimo, uno ms del mximo y uno menos del mnimo de valoresUsar la regla 1 para la condicin de salida.Usar la regla 2 para cada condicin de salida.Prueba de ComparacinSe desarrollan versiones independientes de una aplicacin con las mismas especificaciones.Probar todas las versiones con los mismos datos de prueba.Luego se ejecutan las versiones en paralelo y se hace una comparacin en tiempo real de los resultados.Conjetura de ErroresEnumerar una lista de equivocaciones que pueden cometer los desarrolladores.Generar casos de prueba en base a dicha lista.La generacin de casos se obtiene en base a la intuicin o la experiencia. Pruebas AleatoriasSe simula los posibles datos de entrada en la secuencia y frecuencia que pueden aparecer en la practica.Si el proceso de generacin se ha realizado correctamente, se crearn eventualmente todas las posibles entradas del programa en todas las posibles combinaciones y permutaciones. Baja probabilidad de encontrar errores.ReferenciasThe Art Of Software Testing G. Myers Captulo 4Software Testing and Quality Assurance Theory and Practice. Naik,Tripathy. Captulo 4.Manage Software Testing. Farrell y Vinay. Captulo 11 y 12Software Quality Assurance From Theory to Implementation (Galin). Captulo 9Software Engineering Theory And Practice S. L. Pfleeger. Captulo 9.

Preguntas