= EEE Seminarios y formacién Diag Hers Probador Certificado Nivel Basico Formacién para el “Prabador Certficado - Nivel Bdsico” de acuerdo al programa de estudios 2010 del ISTQB V1.0.6_8.1.0 DIAZ & HILTERSCHEID UUNTERNEHMENSBERATUNG GMBH Kurtstendomm 179 10707 Bedin ace ic snd als 0 - Generalidades parntencted 1 - Introduccion seecvanraaranaasciis aan caioebesad ash cesciacinesasaccs Formador Maria Narcisa Barrios Navas = (mbarrios@choucairtesting.com) Choucair Testing S.A Medellin a Teléfono: 057-4 4480510 Bogoté Teléfono: 057-1 256 9455ee ee eae —2 0 - Generalidades Diaz Hiterscheid . 01 - Introduccién Organizacién del curso ~ EXTERNOS: Miércoles, jueves, viemes y sGbado de Bam a Spm ~ INTERNOS: jueves y viernes de Spm a 9pm y sélbado de Bam a Spm (2 semanas) - Por favor, mantenge su telefono mévil y/o portal cpagados Presentacién de los asistentes y el profesor = Maria Narcisa Barrios Navas. Ing. de Sistemas. Universidad del Norte, Barranquilla, Certified Tester Foundation Level(CTFL) ~ Analista de Capacitacién ~ Choucair Testing S.A. 4 afios de experiencia en pruebas. Choucair Testing ~ Compara colombiana especialzada en servicios de pruebas de software con presencia intemacional - Creada en el afio 1999, pionera y lider en Pruebas de Software (Software Testing) en Colombia. - Componentes del Servicio: Personas, Metodologia y Gestién. ~ Pruebas en todas las etapas del ciclo de desarrollo, 0 - Generalidades DazHitescheid 02 Contenido El presente curso se ha desarrollacio de acuerdo con el programa de estudios del c! o 2010 de Probador Certificado - Nivel Basico (“Certified Tester - Foundation Level") Consta de siete capitulos: -Capitulo0 — Generalidades - Capitulo | Fundamentos de Pruebas - Capitulo | Pruebas a través del Ciclo de Vide Software - Capitulo Ill Técnicas Estaticas - Capitulo IV Técnicas de Disefio de Pruebas - Capitulo V Gestién de Pruebas - Capitulo VI Herramientas de Pruebas cnanear cum tetanic Pic ae eee == 0 - Generalidades neg 02- Contenido os wens Capitulo | - Fundamentos de pruebas = 1/01 aPorqué son necesarias las pruebas? 1/02 sQué son las pruebas? 1/03 Siete principios del proceso de pruebas 1/04 Proceso de pruebas basico 1/05 Psicologia en el proceso de pruebas 1/06 Cédigo ético Capitulo Il - Pruebas a través del ciclo de vida software - 1/01 Modelos de desarrollo software - /02 Niveles de prueba - 1/03 Tipos de pruebas - 11/04 Pruebas de mantenimiento epee aR 0 - Generalidades puznitercheig _02- Contenido case urncnaar NORTON nh Capitulo Ill - Técnicas estdticas ~ II/01 Técnicas estaticas y el proceso de pruebas - ll/02 Proceso de revisiones - III/03 Andlisis estatico con herramientas Capitulo IV - Técnicas de disefio de pruebas 1V/01 Proceso de desarrollo de prueba 1V/02 Categorias de las técnicas de disefio de prueba : 1V/03 Técnicas basadas en Ia especificacién o de caja negra 1V/04 Técnicas basadas en la estructura o de caja blanca & IV/05 Técnicas basadas en la experiencia IV/06 Seleccién de las técnicas de prueba Soe ae ndehnmetiebnbh i ins eded ba0 - Generalidades 02- Contenido Diaz Hiterscheid Capitulo V - Gestion de pruebas - V/01 Organizacién de prueba - V/02 Planificacién y estimacién del proceso de prueba - V/03 Seguimiento y control del estado de las pruebas - \/04 Gestién de la configuracién - V/05 Riesgo y proceso de prueba - V/06 Gestidn de incidencias Capitulo VI - Herramientas de pruebas - VI/01 Tipos de herramientas de prueba - VI/02 Uso efectivo de herramientas de prueba = VI/03 Introduccién de herramientas de prueba en una organizacién - VI/04 Resumen ait 0 - Generalidades 03 - Organizaciones Internacionales Diaz Hier Programa de capacitacién del IST@B™* - £7 1998, se desarrolla en Gran Bretafia un programa de capacitacién de multiples niveles ~ Los fundamentos del proceso de prueba software son formulados en el programa de estudios para el nivel basico fayobus for Founciaion Lever" (ecicién actual: Octubre de - Desde 2004 también se cuenta con certificaciones para el Nivel Avanzado |""Advanced Level”) ~ lefe de Prcbas (Tes! Man jester’), Probador Funcional (' - Se encuentra en preparacién el Nivel Experto - Los Comités de Pruebas (“Testing Boards") de cada pais conforman la estructura de la organizacion del “Intemational Software Testing Qualifications Board" ( ) ~ Por ejemplo en Espafia Spanish Software Testing Board (SST@B), en Alemania: The German Testing Board (GTB) “ISTQB = International Software Testing Qualifications Board2) 0 - Generalidades piaznitescheia 04 - Programas de estudio y examen El conjunto de diapositivas esté basado en el Programa de Estudios de Probador Certificado - Nivel Bdsico del ISTQB, versién 2010 (Marzo) - Acontinuacién del curso de formacién podra tendré lugar un examen al que puede asistir para obtener el certificado de pooeer Certificado, Nivel Basico (“Cerlified Tester, Foundation evel” zt - La evaluacién es realizada por un examinador perteneciente a una organizacién independiente (por ejemplo iSQI*) - Los temas de Ia evaiuacién estén extraidos de las secciones _ correspondientes a las impartidas durante el curso de formacién. El examen es de fipo seleccién moitipie, con una duracion de 60 minutos - Cada pregunta tiene una (de cuatro) Unica respuesta correcta. Se tiene que responder un total de 40 preguntas, cada una de igs cuales puede tener un peso relativo de uno 6 dos puntos. Para aprobar el examen de certificacién es necesario lograr un 65% del total de puntos + sa1= ntemotionciotvare quay ute - Definicién: Calidad software (segdn ISO/IEC 9126): a La totalidad de Ia funcionalidad y prestaciones de un producto. software que contribuyen con su.capacidad de satisfacer necesidades explicitas o implicitas. [Segun ISO 9126] - Definicién: Calidad (sequin IEEE Std 610): Grado en el cual uh componente, sistema o proceso satisface [equisitos especificados y/0 necesidades y expectativas del usuario/Cliente. [Seguin IEEE 610} ea tat bn Blah on Pageazs| - Fundamentos de pruebas 01 - gPorqué son necesarias las pruebas? Diaz Hiterschale Pruebas y la Calidad - Tipos de Aseguramiento de la Calidad (QA): ~ Actividades constuctivas con objeto ce prevenitdetactas, por ejemplo a través de la aplicacién de métodos apropiados de ingenierfa de software = Actividades analiticas con el objeto de detector defectos, por ejemplo a través de puuehas conducenles aa correccion de efectos y prevencion de fallos, inerementando osf a calidad del software 2 eat cts 868818 HES 1 - Fundamentos de pruebas 01 - gPorqué son necesarids las pruebas? iae Hiterscheid Aseguramiento de Ia calidad constructivo Proceso de calidad - Gest.on de ia calidad Consigna - losdefectos evitados no seauieren ser reparedos Organizacién ~ Los defectos introducidos en el pasado ne deben ser repetidos 2 S 6 Técnico ntorno de Desarrall Integrado (IDE) ~ Prevenir defectos Lo = De acuerdo a la norma ISO/IE la colidad satiware consiste an - puncionatidad _Atrbutosfuncionoles de cofdad abide SS © Usbided y © Efciencia Atoutos nosuncionales de calidad 7 Mantenibiidod a chet hes nce ee PuemP Cldidad he Setrcbtes eboney am ai. Jeredohd 5 P-, Epieebyreb t era I i| - Fundamentos de pruebas 01 - Porqué son necesarias las pruebas? Aseguramiento de Ia calidad analitico - Calidad de producto ~ Procedimiento de Verificacién y Pruebas Consigna: ~ Los defectos deben serdetectados tan 8 nfo Como seg 2 |lé Dosible respecto de! 2 lls Proceso g Gobertura de rama z a 3 Cobertura de condicién ~ Pruebas estdticas evaluacién sin la ejecucién det programa Cobertura de camino Revisiones /revisiones guiadas nalisis del flujo de control nalisis del fujo de datos Metricas del compilador/ analizador ~ Pruebas dinémicas incluye Ia ejecucion del programa Estatico ig hepatic tm eam) | - Fundamentos de pruebas 01 - zPorqué son necesarias las pruebas? ‘ovement Diaz Hitescheid Pruebas y la Calidad - Atributos funcionales de calidad - Funcionalidad significa! én: La funcionatidad satistace los atributos / capacidades Conecci requeridos - Completitud: La funcionalidad satistace todos los requisitos (funcionales) = Funcionalidad ("functionality") incluye (sequin ISO/IEC 9126) = Adecuacién ("suitability") - Exactitud ("accuracy") - Interoperabilidad ("interoperability - Seguridad ("security") - Cumplimiento de Tuncionalidad("tuncti ompliance") ) agate| - Fundamentos de pruebas 01 - ¢Porqué son necesarias las pruebas? ize Miterscheid Pruebas y la Calidad - Atributos no funcionales de calidad /1 + Flabilidad ("reliability") - Madurez("maturity”), tolerancia a defectos (“fault tolerance”) recuperabilidad ("recoverability"), cumplimiento de fiabilidad ("reliability compliance") - Coracteristicas: En determinadas condiciones, el software / sistema mantendré su capacidad / funcionalidad alo largo de un perfodo de tiempo - Fiabilidad = Calidad / tiempo - Usabilidad (“usability”) - Comprensibilidad |"understandability"}, aprendibiidad (“learnability”). operabilidad (“operability”), atractivo (‘atiractiveness"), cumplimiento de usabilidad| "usability compliance") - Caracteristicas : Facil de usar, fécil de aprender, conforme a normos, Uso intuitivo fn read = 1 - Fundamentos de pruebas 01 - ¢Porqué son necesarias las pruebas? Diaz Hiterscheidt Pruebas y Ia Calidad - Atributos no funcionales de calidad /2 - Fficiencia (“efficiency"): - Comportomiento del sistema: funcionalidad y respuesta temporal ~ Caracteristicas: El sistema requiere la utiizacién de un minimo de recursos (por ejemplo tiempo de CPU) pare ejecutar una tareo determinada => 5¢ stlree- los recerses Ferme echtwode - Mantenibilidad (“maintainability ~ Anaiizabilidad ("analysubiity"), mouificabitidad ("changeabiity") estabilidad ("stability"), testabilidad {testabilty"), cumpiimiento de mantenibilidad ("maintainablity compliance") - Caracteristicas: Medida del estuerzo requerido para realizar cambios enios componentes de un sistema2 ened Ceo tla 96.819 UTE | - Fundamentos de pruebas Diaz Hiterscheig OF - Porqué son necesarias las pruebas? se nauesehiivirthinuibsebruien sirens icromni Pruebas y la Calidad - Atributos no funcionales de calidad /3 - Portabilidad ("portability"): - Adaptabilidad ("adaptability"), instalabilidad ("installabilty"), coexistencia (“co-existence”), reemplazabilidad ("replaceabilty"), ‘cumplimiento de portabilidad ("portability compliance") - Capacidad del software de ser transferido a un nuevo entorno: (software. hardware, organizaci6n) = Caracteristicas: Facil de instalar y desinstalar, parametros sSachipheineeimtatecunmne sea) estan Fundamentos de pruebas omnitenches 01 - €Porqué son necesarias las pruebas? 1S Ce eC RNERE EMR ORT ODE RIS Atributos de la calidad - Algunos atributos de la calidad de un producto software se infiuyen mutuamente. Debido a esta interdependencia y en funcién del objeto de prueba, los atributos deberan ser i caracterizados por una prioridad. Por ejemplo eficiencia versus Portabilidad - Se realizaran distintos tipos de pruebas con el objeto de medir distintos tipos de atributo i bones Grenier) read oe— 1 - Fundamentos de pruebas z 01 - Porqué son necesarias las pruebas? ierscheid Objetivos de las pruebas Diaz Hitescheid a Adquitir conocimiento sobre los defectos en un objeto de prueba (“test object") Los defectos contenidos en un objeto de prueba deben ser detectados y descritos de tal forma que se facilite su correccién Confirmacién de Ia funcionalidad La funcionalidad del sistema debe ser implementada tal y como ha sido especificada, Generar informacién Se debe proporcionar informacién relativa a los posibles tiesgos relativos a un sistema software antes de su entrega a los usuarios La obtencién de esta informacién puede ser uno de los objetivos de las pruebas Ganar confianza Un sistema software que ha sido probado de forma adecuada se considera que cumple con la funcionalidad esperada y cuenta con un alto nivel de calidad — 1 - Fundamentos de pruebas 01 - ¢Porqué son necesarias las pruebas? q Cuanta: as son suficientes? Criterios de salidd ("exit criteria”) No enconirar (mas) defectos es un criterio apropi ido para finalizar las actividades de pruebas. Sin embargo son necesarias otras métricas para reflejar de forma adecuada el nivel de calidad alcanzado - Pruebas basadas en riesgos (“risk-based testing”) Einivel de riesgo determina el grado en el cual se ha probado, es decir: responsabilidad en caso de fallos, probabilidad de la ocurrencie de fallos, espectcs relatives @ factores econdmicos y propios del proyecto - Pruebas basadas en plazos y presupuesto (“time and budget testing”) La disponibilidad de recursos: (personal, tiempo, presupuesto} pueden determinar ia medida del esfuerzo del proceso de pruebas api 32 >— 1- Fundamentos de pruebas Diaz Hiterscheid 01 - éPorqué son necesarias las pruebas? st Maes ey Caso de prueba (“test case"), base de prueba (“test basis") - Caso de prueba (“test case") sequin IEEE Std, La definicién de un caso de prueba incluye, almenos, la siguiente informacién (sequin IEEE Std 610) ~ Precondiciones ~ Conjunto de valores de entrada - Conjunto de resultados esperados - Poscondiciones esperadas = Identificador énico - Dependencia de otros casos de prueba = Referencia al requisito que seré = Forma en la cual se debe ejecutar el caso de prueba y verificar los resultados [opcional) + Prioridad (opcional) - Base de prueba (“test basis” o “test base”) Conjunto de documentos que definen los requisitos de un componente o sistema. Utilizado como fundamento para el desarrollo de casos de prueba. cre peeindimninareanng onde ern —_ 1 - Fundamentos de pruebas cartitecchaa 01> gPorqué son necesarias las pruebas? _ ronreumaasseii Tahaan Toe asia reeabee Desarrollo software y revisiones - Cédigo (“code”), cédigo fuente (“source code”): Programa de ordenador escrito en un lenguaje de programacién que puede ser leido por una persona - Depuracién ("debugging"): Localizacién y correccién de defectos en el cédigo fuente - Desarrollo software (“software development”): Es un proceso complejo / secuencia de actividades cuyo objetivo es desarrollar un sistema basado en un ordenador. Normalmente sigue un modelo de desarrollo software. use en ihn sie sc agna3e1 - Fundamentos de pruebas 01 - gPorqué son necesarias las pruebas? Desarrollo software y revisiones ~ Requisito (“re Un requisito describe un Gizibute funcional deseado o considerado obligatorio Revision (“teview”) [segén IEEE Std 1028): Evaluacidn de un producto o del estado de un proyecto para detectar discrepancias respecto de los resultados planificados y para recomendar mejoras_ 535 sion mney ok tli rapaaiks =) | - Fundamentos de pruebas 01 - gPorqué son necesarias las pruebas? Diaz Hitercheid Resumen: - Los fallos del software pueden causar importantes dafios - La calidad del software es la suma de los atributos que se refieren ala capacidad del software de satisfacer un conjunto de requisitos dados - Elaseguramiento de la calidad constructive se ocupa de la prevencién de defectos - Elaseguramiento de Ia calidad analitico se ocupa de la deteccién y correccién de defectos - Los atributes funcionales y no funcionales de la calidad definen la calidad total del sistema ueba debe contar con eriterios de salida (“exit Alalcanzar los criterios de salida concluiran las, actividades de prueba - Los probadores (“testers”) buscan fallos en el sistema e informan sobre los mismos (proceso de pruebas - “testing”. Los desarrolladores buscan defectos y los corrigen (depuracién - “debugging") oc cs ine rabid a1 - Fundamentos de pruebas Diaz Hilterscheid Contenido oP Rann canara ies Capitulo | - Fundamentos de pruebas 1/01 aPorqué son necesarias las pruebas? 35 = 102.2 QUE SOR as PraSbas?, 1/03 Siete principios del proceso de pruebas 1/04 Proceso de pruebas basico 1/05 Psicologia en el proceso de pruebas 1/06 Cédigo ético Girth ieepinirtonh Ghai oa esast.9=) | - Fundamentos de pruebas 02 - .Qué son las pruebas? Diss Hiterscheet Probar significa mas que ejecutar pruebas - La ejecucién de pruebas es sélo una parte de las pruebas - El proceso de prueba incluye ~ Planificacién y control ~ Seleccién de condiciones de prueba ~ Disefto y ejecucién de casos de prueba - Comprobacién de resultados - Generacién de informes respecto del proceso de pruebas y el sistema sujeto a pruebas ~ Finalizacién y completar actividades de cierre - Larevisién de documentos, cédigo fuente y Ia realizacién de andlisis estatico también ayudan a prevenir ia aparicién de defectos en el cédigo —2 1 - Fundamentos de pruebas 02 - Qué son las pruebas? az Hitercheid Objetivos de las pruebas - Deteccién de defectos Puede ser - Pruebas de desarrollo ("development testing”): para causar tantos fallos ("failures") como sea posible = Pruebas de aceptacién ("acceptance testing"): para confimar que el sistema funciona como se espera - Generacién (logro) de confianza respecto del nivel de Calidad - Aportacion de n para la toma de decisiones - Prevencién de defectos forma: si| - Fundamentos de pruebas 02 - gQué son las pruebas? : Desarrollo Software = Depuracién (“debugging”): Proceso de encontrar, analizar y eliminar las causas de los fallos en el software ~ _Requisito (“requirement”): Condicién’o capacidad necesaria para un usuario con el objeto de solucionar un problema 0 lograr un objetivo que debe ser alcanzado 0 poseido por un sistema o componente de un. sistema, para satisfacer un contrato, estandar, especificacién u oiro documento impuesto formaimente. [Segin IEEE 610] = Revision (“review"): oe, Evaluacién de un producto o del estado de un proyecto para i detectar discrepancias con los resultados planificados y para ne recomendar mejoras. Algunos ejempios incluyen la revision de £ gesti6n, revision informal, revision técnica, inspeccién y revision Quiada’ [Segun IEEE 1028) : can ees ofimereectag snot 88 NO) eR ey ARERR = —2 1 - Fundamentos de pruebas a parnitescheid 02 - QUE son las pruebas? ae Pn nae ns mar sua so renee Pruebas y depuracién ("debugging") Depuracién an Detoccién = ‘dentificacion de defectos Correccién de dofectos - Probar y repetiria prueba (repeticion de pruebas - “re-testing") son actividades propias del proceso de pruebas. Las pruebas muestran los fallos 2 La repeticién de pruebas ("re-testing") verifica que el defecto : ha sido corregido - La depuracién y la correccién de defectos son actividades propias del desarrollador A través de la depuracién los desarrolladores pueden reproducir los fallos, analizar el estado del programa y detectar el defecto correspondiente con el objeto de CorregirloDiaz Hikerscheid vase ceteoes teste 810 wii — 2 | - Fundamentos de pruebas 02 - ~Qué son las pruebas? Resumen: El proceso bésico de prueba incluye = Planificacién y control = Seleccién de condiciones de prueba = Diseno y ejecucién de casos de prueba = Comprobacién de resultados Generacién de informes respecto del proceso de pruebas y el sistema sujeto a pruebas ~ Finalizacién y completar actividades de cierre ~ Los objelivos de las pruebas pueden ser: Ig deleccién de defectos, el nivel de calidad, Ia informacién para la toma de decisionés, prevencion de defectos - El proceso mental y las actividades involucradas en el disefio de prueba de forma temprana en el ciclo de vida - Las pruebas dinémicas significan a ejecucién del software, las pruebas estéticas significan la revision de documentos - Las pruebas dinémicas muestran fallos que han sido causados Bot dafectos, Ia depuracion detecto, analiza y elimina la couso el fallo2 1 - Fundamentos de pruebas DazHitesched Contenido Capitulo | - Fundamentos de pruebas - 1/01 gPorqué son necesarias las pruebas? - 1/02 ¢Qué son las pruebas? - 1/05 Psicologia en el proceso de pruebas - 1/06 Cédigo ético ‘boas hoh meinen mt ene) - rtecenan-naniesnccee IB =) 1 - Fundamentos de pruebas cozntercreg 03 Siete principios del proceso de pruebas is nao scmmna arabe ic eine ecbeace AT Principio defectos | proceso de pruebas demuestra la presencia de - Elproceso de pruebas puede probar Ja presencio de defectos - Las desviaciones identificadas a lo largo del proceso de pruebas demuestran la presencia de un fallo - La causa de un fallo puede no ser obvia - Elproceso de pruebas no puede demastrar Ia ausencia de efectos - Las pruebas reducen la probabilidad de la presencia de defecios que permanezcan sin ser detectados. La ausencia de fallos no demuestran la correccién de un producto software - Elmismo proceso de pruebas puede contener errores - Las condiciones de prueba pueden ser inapropiadas para detectar errores=> PoboserCercade—Nieionco 10.40 GERSs oss 1 - Fundamentos de pruebas 03 - Siete principios del proceso de pruebas scheid Principio 2: No es posible realizar pruebas exhaustivas - Pruebas exhaustivas (“exhaustive testing”) Enfoque de pruebas donde el conjunto de pruebas abarca todas las combinaciones de valores de entrada y precondiciones - Explosién de casos de prueba (“test case explosion”) Define el incremento exponencial de esfuerzo y coste en el caso de pruebas exhaustivas - Prueba de muestra ("sample test") La prueba incluye solamente a un supcanjunta (generado de forma sistemGtica 0 aleatoria) de todos los posibles valores de entrada ae ae - En condiciones reales, se utilizan generalmente pruebas de_ muestra. Probar todas las combinaciones posibles de entradas y precondiciones solo es econdmicamente viable en casos triviales 1 - Fundamentos de pruebas 03 - Siete principios del proceso de pruebas fae Hiterscheid Principio 3: Pruebas tempranas (“early testing") - Cuanto més temprana es la deteccién de un defecto, menos Costosa es su comreccién - Se obtiene una maxima rentabilidad cuando los errores son Corregidos antes de la implementacién - Los conceptos y especificaciones también pueden ser probados - Los defectos detectados en la fase de concepcién son corregidos con los menores esfuerzo y coste - La preparacién de una prueba también consume tiempo - Elproceso de pruebas implica més que sélo la ejecucién de pruebas - Las actividades de pruebas pueden ser preparadas antes de que el desarrollo se haya completado - Las actividades de pruebas {incluidas las revisiones) deben se ejecutadas en paralelo a Ia especificacién y disefio software regia= 1 - Fundamentos de pruebas Diaz Hiterscheid _ 03 - Siete principios del proceso de pruebas sirens =) | - Fundamentos de pruebas Dustitesheis 03 - Siete principios del proceso de pruebas Principio 4: Agrupamiento de defectos (“defect clustering”) - JEncuentre un defecto y encontrar més defectos “cerca”! - Los defectos aparecen agrupados como hongos o cucarachas - Vale la pena investigar un misrno médulo donde se ha detectado un defecto - Los probadores (“testers”) deben ser flexibles - Habiendo sido detectado un defecto es conveniente volver a considerar el rumbo de las pruebas posteriores - La identificacién/localizacién de un defecto puede ser investigada con un mayor grado de detalle, por ejemplo, as realizando pruebas adicionales o modificando pruebas hrs existentes in me ite sis amas eeanseasstis emai Principio 5: Paradoja del pesticida - Repetir pruebas en las mismas condiciones no es efectivo - Cada caso de prueba debe contar con una combinacién Gnica de pardmetros de entrada para un objeto de prueba particular, de lo contrario no se podré obtener informacién adicional - Sise ejecutan las mismas pruebas de forma reiterada no se @ podrdn encontrar nuevos defectos ("defects") - Las pruebas deben ser revisadas/modificadas regularmente para los distintos médulos de cédigo - Esnecesario repetir una prueba tras una modificacién del cédigo (correccién de defectos, nueva funcionalidad) - Laautomatizacién de pruebas puede resultar conveniente si un conjunto de casos de prueba se debe ejecutar frecuentementeeet Gitte rote 888 nS = 1 - Fundamentos de pruebas 03 - Siete principios del proceso de pruebas Die hiterchid Principio 6: Las pruebas dependen del contexto - Las pruebas se realizan de forma diferente en diferentes contextos - Objetos de prueba diferentes son probados de forma diferente - El controlador de! motor de un coche requiere pruebas diferentes respecto de aquellas para una aplicacién de “e Commerce” - Entorno de prueba (“test environment”, cama de prueba - “test bed") vs. entomno de produccién (“production environment") - Las pruebas tienen lugar en un entorno distinto del entorno de produccién, | entorno de pruebas debe ser muy similar al entorno de produccién - Siempre habré desviaciones entre el entorno de pruebas y el entomo de produccién. Estas desviaciones ponen en tela de juicio las conclusiones que se obtuvieran tras as pruebas —2 1 - Fundamentos de pruebas 03 - Siete principios del proceso de pruebas Diaz Hiterscheid Principio 7: La falacia de la ausencia de errores - Unproceso de pruebas adecuado detectard los fallos mas importantes - En la mayoria de los casos el proceso de pruebas no detectaré todos los defectos del sisterna (ver Principio 2), pero los defectos mas importantes deberian ser ae detectados - Esto por si solo no prueba la calidad del software - La funcionalidad del software puede no satisfacer las necesidades y expectativas de los usuarios - No se puede introducir la calidad a través de las pruebas, ella tiene que construire desde el principio! regis?Diaz Hiterscheid estes ews ie tse casa Capitulo | - Fundamentos de pruebas | - Fundamentos de pruebas 03 - Siete principios del proceso de pruebas Resumen: - Las pruebas pueden ayudar a detectar defectos en el software, sin embargo las mismas no pueden demostrar la ausencia de defectos - Para casos no triviales las pruebas exhaustivas son imposibles, las pruebas de muestra son necesarias - Las pruebas fempranas ayudan a reducir costes dado que los defectos descubiertos en fases tempranas del proceso software son coregidos con menor estuerzo : - Los defectos se presentan agrupados. El encontrar un defecto en una ubicacién determinada significa que probablemente se encontrard otro defecto a su alrededor - Larepeticién de pruebas idénticas no genera nueva informacién - Cada entorno particular determina Ia forma en Ia cual se ejecutarén/desarrollaran las pruebas. - Un software libre de errores no implica su adecuacién al uso 1S ksi ie renee e8i8 — 1 - Fundamentos de pruebas a Dastitencred Contenido 2 a ae aaa caacraacaa - 1/01 Porqué son necesarias las pruebas? - 1/02 Qué son las pruebas? - 1/03 Siete principios del proceso de pruebas SEW04 Fiscesaide pruebas basicoyy 7 ~ 1/05 Psicologia en el proceso de pruebas : = = 1/06 Cédigo ético i ehkaeainniertene nb ly 2 |—2 | - Fundamentos de pruebas 04 - Proceso de pruebas basico itescheid El proceso de pruebas como proceso dentro del proceso de desarrollo software = Dependiendo del enfoque seleccionado el proceso de pruebas tendra lugar en diferentes puntos del proceso de desarrollo = Los pruebas constituyen un proceso en si mismas = Elproceso de pruebas esté determinado por las siguientes fases: = Planificacién de pruebas y Control - Anélisis de pruebas y disefio de pruebas Implementacién de pruebas y ejecucién de pruebas = Evaluacién del ciiterio de finalizacién de pruebas y generacién de Informes de pruebas - Actividades de cierre de pruebas = Las fases del proceso de pruebas se podran superponer —2 1 - Fundamentos de pruebas 04 - Proceso de pruebas badsico Diaz Hiterschet El proceso de pruebas a lo largo del proceso de desarrollo software - jEl proceso de pruebas es més que la ejecucién de pruebas! = Incluye superposicién y vuelta atrds ("backtracking") - Cada fase del proceso de pruebas tiene lugar de forma concurrente con las fases del proceso de desarrollo software Peinentacn de pruebas cy Ejocucion de pruebas Hi 2 ga ie2 tet ancee-Nl Boo 926 810 ESE ss | - Fundamentos de pruebas 04 - Proceso de pruebas basico naa Diaz Hierscheid sssenanennn Control de pruebas - tareas principales - El control de pruebas es una actividad continua que influye en la planificacién de las pruebas. El plan de pruebas maestro. {'master tes! plan") puede ser mocificado en uncién de la informacién adquirida a partir delcontrolde prueba | - Elestado del proceso de pruebas se determina comparando él progreso logrado con respecio al plan de pruebas. Se iniciarén aquellas actividades que se consideraran necesarias consecuentemente - Se miden y analizan resultados - La evolucién de las pruebas, la cobertura de las pruebas y el cumplimiento de tos criterios de salida (“exit criteria”) de pruebas son objeto de seguimiento y son documentados - Se inician medidas correctivas - Se preparan y toman decisiones sic ymitaang ont es en) i So eee — 1 - Fundamentos de pruebas cucritencneg 04 - Proceso de pruebas basico sera ia sen ia Planificacién de pruebas - tareas principales - Determinar el alcance y riesgos - Identificar los objetivos de las pruebas y los criterios de salida de pruebas - Determinar el enfoque: técnicas de pruebas, cobertura de pruebas, equipo de pruebas - _Implementar el método de pruebas / estrategia de pruebas, planificacién del periodo de tiempo para el desarrollo de las actividades a seguir - Adauirir/obtener y programar recursos requetidos por las pruebas: personal, entomo de pruebas, presupuesto de pruebas= 1 - Fundamentos de pruebas eS 04 - Proceso de pruebas bésico : Diaz Hiterschest - Plan de prueba maestro (‘master test plan”): Es un documento en el que se describe el gicance, enfoque, recursas y calendario (“schedule”) de las actividades de pruebas previstas. Este documento incluye, pero no esté limitado a, los elementos de prueba (“test items"), caracteristicas que seran probadas, recursos y la planificacién de contingencias - Estrategia de prueba (“test strategy i6n a alto nivel de los niveles de prueba a llevar a cabo y los pruebas asociadas a ellos para una organizacion © programa (uno o mas proyectos) - Enfoque de prueba (“test approach”) La implementacién de la estrategia de prueba para un proyecto especifico. Normalmente incluye la decisiones tomadas con el objeto de lograr los objetivos del proyecto (de prueba) y el andllisis de riesgo, puntos de inicio ("starting points") tespecto del proceso de pruebas, técnicas de disefio de pruebas a aplicar, criterios de salida y tipos de prueba a elecutar ye ashrekesre me feb dacchs 5 ef enCogee me de Ina bipos ck preelrs ambos diten Camm ceeliter Ins proebes Mmestee tel plenng 2 testesiebsy S best epprecets ovate Cheats trate 045510 EES “= 1 - Fundamentos de pruebas 04 - Proceso de pruebas bdsico gina 3 faz Hiterscheid ih - Criterios de salida (“exit criteria")[segin Gilb and Graham]: Conjunto de condiciones genéricas y especificas, acordadas Eon los invalicrados, para que Un proceso sea considerada formalmente concivido. £1 propésite de los criterios de salida es évitar qui jared se considere concluid endo partes destac sin completar. Los criterios de salida son Utlizados como teferencia’para Ia elaboracién de informes y para planificar cuando se deben finalizar las pruebas. Lo anterior debe ser realizado para cada nivel de pruebas. Be rahe Be a ae agi Swe ie ie See2 etn Ceeads-MelBcoV1 188 po eed 1 - Fundamentos de pruebas 04 - Proceso de pruebas bésico Diaz Hiterscheid in tase Andlisis y disefio de pruebas - tareas principales /1 - Revisar las bases de prueba ("test basis”) {requisitos, arquitectura del sistema, disefio, interfaces). ~ Analisis de la arquitectura del sisiema, disefio det sistema incluyendo las interfaces entre los. objetos de prueba. - Analizar la testabilidad. ~ Evaluacién de Ia testabilidad de las bases de la pruebas y casos de prueba - Identificar y priorizar condiciones de prueba ("test conditions") en funcién de: ~ Anélisis de los elementos de prueba ("test item”) - Especificaciones de prueba - Comportamiento y estructura del software ei: ‘art menos insertions fea ceri z sda) 2 1 - Fundamentos de pruebas carnneacrea 04 - Proceso de pruebas bésico certo se aremasnasti aa mab mncavalbaiant tne ines ommatalaatia Andlisis y disefio de pruebas - tareas principales /2 ~ Disefiar pruebas / casos de prueba = Crear y priorizar casos de prueba de légico / alto nivel (casos de prueba sin datos de prueba especificos) - Los casos de prueba positives dan muestia de ia funcionalidad, los casos de prueba negatives comprueban situaciones en las que hay fratamiento de errores - _ Identificor condiciones de prueba espectficas y datos de prueba (“test data” necesarios - Evaluarla disponibilidad de datos de prueba y/o la viabilidad de generacién de datos de prueba: i net notre rime> eer MEE | - Fundamentos de pruebas vumreg _ 04- Proceso de pruebas bésico Andlisis y disefio de pruebas - tareas principales /3 - Disefiar el entorno de prueba (“test environment”) (cama de prueba - |"‘test bed")] ~ (Exclusivo} disponibilidad del entomo de prueba, venianas temporales ("time window’ etc - Definir la operacién del entomo de prueba, incluyendo ia administracion de usuario - Cargar conjuntos de datos (“data sets") y parametros del sistema ["system parameters") - Conectar al entorno de prueba con los sistemas adyacentes 2 1 - Fundamentos de pruebas Diaz Hiterscheig 04 - Proceso de pruebas basico Andlisis y disefio de pruebas - tareas principales /4 - Probar la infraestructura y herramientas de prueba (“test tools"), si fuera necesario ~ Procesos, procedimientos y responsabilidades ~ Seleccionar, prover, instalar y operar herramientas de prueba * Crear trazabilidad bidireccional ~ Entre las bases de las pruebas y casos de prueba aE eee Oe ee eee1 - Fundamentos de pruebas Diaz Hiterscheid 04 - Proceso de pruebas basico sian eames draco: - Datos de prueba (“test data”): Datos que existen en el sistema antes de que una prueba sea ejecutada, y que afecta 0 es afectado por el componente o sistema sujeto a pruebas - Datos de entrada (“input data”): Variable que-es leida por un componente [almacenada tanto dentro como fuera del sistema) - Cobertura de pruebas (“test coverage"): Grado en el que un elemento de especificado ha sido practicado por un juego de pruebas (expresado como un porcentaje). Utlizado con mayor frecuencia en pruebas de caja blanca con el objeto de determinar la cobertura de cédigo a heats menanbaang ies ear Potonecemeods-Mdtoiee 106518 . = 1 - Fundamentos de pruebas wf Vitersneg 04 - Proceso de pruebas bésico ® aac ade pice aaereaaeae - Ordculo de prueba (“test oracle"): & Fuente que permite determinar los resultados esperados de un software sujeto a pruebas: comparativas ("benchmarks") 2 (también resultado de pruebas previas), manuales de usuario o conocimiento especializado. No debe ser el cédigo. G doce atenee , banda a epben sober ol Se es ened mina teioe gone Nair1 - Fundamentos de pruebas 04 - Proceso de pruebas basico ect ii terscheid Implementacién y ejecucién de pruebas /1 - Finalizar, implementar y priorizar casos de prueba - Identificar datos de prueba - Desarrollar y priorizar procedimientos de prueba - Crear datos de prueba ~ Preparar orneses de prueba" ("test hamess" (opcional} ~ Redactar guiones de prueba automatizados* (automated test script”), si fuera necesario - Crear juegos de prveba* ["test suites") de fos procedimientos para una ejecucién de prueba eticiente - Verificar el entorno de prueba* (cama de prueba) “Ver glosario reheat | - Fundamentos de pruebas 04 - Proceso de pruebas basico 4 igvwineenreee'o ts sb alc dnomaee és Diaz Hiescheid Implementacién y ejecucién de pruebas /2 - Verificar y actualizar ia trazabilidad (bases de prueba - casos de prueba) - Fjecutar prueba (de forma manual o automatica) - Seguir secuencia de prueba ~_ Registrar resultados de prueba y andlisis = Registrar las identidades y versiones del software / hertamientas de prueba / productos de soporte de pruebe (“testware") = Comparar resultados reales "actual results") con resultados esperados ("expected results") - Informar y analizar incidencias con el objeto de establecer sus causa - Cédigo / producto de soporte de prueba / documento / ejecuci6n sac necis neces nnotarning ante is hi regina -_— a eo oe oe oe oe oe es eee akn Seis sas 1 - Fundamentos de pruebas Titesnag 04 - Proceso de pruebas bdsico mead aliiemateb iinet aire ated Sontag Implementacién y ejecucién de pruebas /3 - Repetir actividades de prueba para confirmar una correccién : - Repeticién de prueba (“re-test") [después de la coreccién de un defecto] - §jecutar prueba de regresién = As@gurar que ios cambios no han revelado olfos defectos 0 introducido nuevos defectos - eboaerCucode-Nrataiee 1186.15: ES = Fundamentos de pruebas @ Hi iteccheis 04 - Proceso de pruebas bésico rans chee taka Juego de pruebas (“test suite") / secuencia de pruebas (‘test sequence"): t Conjunto de cascs de prueba para un componente o sistema en pruebas, donde la poscondicién de una prueba es utilizada como precondicién de la siguiente Especificacién de procedimiento de pruebas (“test procedure specification") (escenario de prueba - “test scenario”): Documento que especifica la secuencia de acciones para la ejecucién de una prueba. También conocido como script de prueba o script de prueba manual. [SegUn IEEE 829] Ejecucién de pruebas ("test execution” Proceso de practicar una prueba produciendo resultados reales1 - Fundamentos de pruebas 04 - Proceso de pruebas basico Diaz Hiterschid ~ Registro de prueba (“test log”) [protocolo de prueba - ("test protocol”), informe de pruebas - “test report": Registro cronolégico de los detalles relevantes respecto ala ejecucion de pruebas. [IEEE 829]: cuando se desarrollaron las pruebas, qué resultados fueron generados - Pruebas de regresién (“regression tests"): Pruebas de un programa previamente probado que ha sufrido modificaciones, para gsegurarse que no se han inireducido 0 descubierto defectos en dreas del sofware qui ido. modificadas como resultado de los cambios realizados. Se realiza cuando el software o su entorno han sido modificados - Repeticién de pruebas (“re-testing"): Repeticién de una prueba tras la correccién de un defecto con el objeto de confirmar que el defecto ha sido eliminado con éxito = 1 - Fundamentos de pruebas piazritercheis 04 - Proceso de pruebas bdsico Evaluacién de criferios de salida - tareas principales - Evaluar la ejecucién de pruebas con respecto a objetivos definidos (por ejemplo, Cae eee] ctiterios de salida) Sea - Evaluar los registros de pruebas (resumen de las actividades de pruebas, resultados de prueba, comunicar criferio de salida} - Proporcionar informacién con el objeto de dar lugar a la decisién de si llevar a cabo pruebas adicionales aDiaz Hiterscheld sete aE BADR RE DN Sas Actividades de cierre de pruebas (“test | - Fundamentos de pruebas 04 - Proceso de pruebas basico closure”) - tareas principales Recopilar datos de |as actividades del proceso de pruebas finalizadas con el objeto de consolidar la experiencia, producto de soporte de prueba (‘teslware’), hechos y numeros Cerrar informes de incider jeneracién de MUdes de cambio para cualquier punto que permaneciera abierto Comprobar qué entregables planificades han sido entregados y probados Documentar ia aceptacién del sistema Finalizar y archivar los productos de soporte de prueba thestware’ "), el entorno de prueba y la Iiraestructura de prueba para un uso posterior, transferencia / traspaso a operaciones Analizar las lecciones aprendidas para futuros proyectos tii macién recopilada para mejorar la madi jel pr a ‘Se Sanibrtnerteningcan se ir : cae Diaz Hitersched 5 sezenatee = obivaiptibioeaaiet sakaimmiacaseetSraited 1 - Fundamentos de pruebas 04 - Proceso de pruebas bdsico Resumen: ay El proceso de prueba se puede dividir en diferentes fases, Planificacién de pruebas (“test planning") abarca actividades como la definicién del enfoque de pruebas para todas las fases asi como la planificacién de los recursos (tiempo, personal, Saf méquinas) . Disefio de pruebas (especificacién) abarca el disefio de casos de prueba y sus resultados esperados 2 Ejecucién de pruebas abarca la definicién de datos de prueba, la ejecucién de pruebas y la comparacién de resultados Evaluacién de pruebas y generacién de informes abarca la evaluacién del criterio de salida y el registro de los resultados de pruebas en forma escrita Control de prueba consiste en e! control de las actividades que “ cubren todas las fases del proceso de pruebas| - Fundamentos de pruebas Diaz Hilterscheid Contenido Capitulo | - Fundamentos de pruebas | ~ 1/01 gPorqué son necesarias las pruebas? = 1/02 Qué son las pruebas? - 1/03 Siete principios del proceso de pruebas ~ 1/04 Proceso de pruebas bésico 1/05'Psicologia én el proceso de pruebas Bs ~ 1/06 Cédigo ético i . " aga ee ee ee eee= 1 - Fundamentos de pruebas ‘srtiterche 05 - Psicologia en el proceso de pruebas seme ne semen ised aoe Roles y responsabilidades Rol: Desarrollador Rol: Probador (“Tester”) -Impiementa requisitos -Planifica las actividades de -Desarrolla estructuras pruebas. -Disefia y programa el software —_-Disefia casos de prueba ~Su-éxito-consiste-en la-ereacién. --Su.Unica preocupacién es de un producto encontrar defectos -Encontrar errores producidos por un desarrollador es su éxito Percepci iLa actividad del desarrollador es _jLa actividad del probador constructival ("tester") es destructival ‘Error! ilas pruebas también constituyen una actividad constructiva, su propésito es la eliminacién de defectos en un producto! cafe dn nnmmelmenssiana cnt hhc I - Fundamentos de pruebas Diarriitescheig _05 - Psicologia en el proceso de pruebas ESTE RADNER ERE LSTA TLS Caracteristicas personales de un buen probador (“tester”) /1 - Curios, perceptivo, atento a los detalles ~ no todo error se manifiestan de forma evidente = Con el objeto de comprender los escenarios practicos del cliente - Con el objeto de poder analizar la estructura de la prueba - Con el objeto de descubrir detalles de dénde se pueden manifestar fallos = Escéptico y con actitud critica - Los objetos de prueba contienen defectos. Usted solo debe. encontrarlos = No creer todo lo dicho por los desarrolladores - Nose debe temer al hecho de que se pudieran detectar defectos de imporiancia que pudieran tener un impacto sobre la evolucién del proyecto i Sede nanenes carmen nara spits1 - Fundamentos de pruebas 05 - Psicologia en el proceso de pruebas iterscheid Caracteristicas personales de un buen probador (“tester”) /2 - Aptitudes para la comunicacién - Necesarias para llevar malas noticias a los desarolladores ~ Necesarias para vencer estados de frustracién ~ Tanto cuestiones técnicas como précticas, relativas al uso de! sistema, deben ser entendidas y comunicadas - Una comunicacién posiiva puede ayudar a evitar o facilitar situaciones dificiles Para establecer una relacién de trabajo con los desarrolladores a corto plazo - Experiencia ~ Factores personales influyen en la ocurrencia de errores ~ La experiencia ayuda a identificar dénde se pueden acumular errores ‘eshte te van — 1 - Fundamentos de pruebas 05 - Psicologia en el proceso de pruebas Diaz Hitescheid Diferencias: disefiar - desarrollar - probar - El proceso de pruebas requiere un modo cie pensar distinto ala del disefio y desarrollo de sistemas software i ~ Objetivo comin: aportar un buen producto software ~ Cometido del disefto: ayudar al cliente a proveer/suministrar los requisitos adecuados ~ Cometido de los desarrolladores: convertr los requisites en tunciones - Cometido de los probadores ("testers"): evaivarlaimplementacién correcta de los requisitos del cliente - En principio, una persona puede asumir los tres roles en su trabajo ~ Se deben tener en cuenta las diferencias en objetives y modelos de roles ~ Es dificil pero posible - Otras soluciones (pruebas independientes) pueden ser més sencillas y aportar mejores resultados in re ee ee ee ee ee ee ee ee ee ee=> | - Fundamentos de pruebas 05 - Psicologia en el proceso de pruebas socom eambaaet iar Hiterscheid Pruebas independientes - La separacién de las responsabilidades en el proceso de pruebas apoya/promueve la evaluacién independiente de los resultados de las pruebas - Enel siguiente diagrama se representa el grado de independencia a través de un grafico de barras all stk chnoudcmaruinomeanine nen ven ere =) | - Fundamentos de pruebas partitexched 05 - Psicologia en el proceso de pruebas SERIES RENCE RNR I SABES ER LL Organizacién de pruebas - fipos /1 = Pruebas de desarrollador ~ Eidesarrollador nunca analizaré su “creacién" de forma imparcial (apego atectivo) ~ Sin embargo, 6! conoce e' objeto de prueba mejor que nods = Habre costes adicionales debido ala formacién/informacién de otras periones respecto de! objeto de prueba - Las personas tienden a pasar por alto sus propios defectos los desarolladores corren el riesgo de no reconocer detector evidentes - Enrores cometidos como consecuencia de una mala interpretacién de los requisitos se mantendran sin ser detectados ~ Elestablecimiento de grupos de prueba donde los desarrolladores prueben los productos de otros ayuda a evitar 0, al menos, reducir ia posibildad de ocurrencia de este tipo de dnomaliaIratosorCntenso- Wve io V1 B66 9 Ee 4. 1 - Fundamentos de pruebas 05 - Psicologia en el proceso de pruebas wi at tice Organizacién de pruebas - tipos /2 - Equipos de desarrollado ~ Los desarrolladores hablan el mismo lenguaje ~ Los costes de formacién/informacién en lo relativo a objetos de prueba se mantienen en un nivel moderado, especialmente cuando los equipos intercambian objetos de prueba ~ Peligro de generacién de conflictos entre equipos de desarrollo Un desarrollader que busca y encuentra un defecto no seré el mejor amigo del autor del abjeto de prueba analzado - Mezcla de actividades de desarrollo y pruebas Combios frecuentes en la forma de pensar Dificutta et control del presupuesto del proyecto. inven SABE sore ais = 1 - Fundamentos de pruebas 05 - Psicologia en el proceso de pruebas z Diaz Minescheid Organizacién de pruebas - tipos /3 - Equipos de pruebas - lacreacién de equipos de pivebas que den servicio a diferentes Greas de proyecto mejora la calidad de las pruebas Es importante que los equipos de prueba de diferentes Greas en el Proyecto trabajen de forma independiente roan == 1 - Fundamentos de pruebas Diaz Hiterscheid _ 05 - Psicologia en el proceso de pruebas Lo eS OE SHUI NAMA Organizacién de pruebas - tipos /4 al = Subcontratacién de pruebas (“externalizacién") - La separacién de las actividades de pruebas y desarrollo aportan la méxima independencia enire los objetos de prueba y el probador (rester") = Las actividades de pruebas subcontratadas (exteralizadas) son ejecutadas por personal con un conocimiento relativamente pequelo de los objelos de prueba y de los antecedentes del proyecto = Lacurva de aprendizaje implica altos costes, por lo tanto, se deberian_ involverera expertos Independientes en etopas tempranas del proyecto = Los expertos extemos cuentan con un aito nivel de conocimiento (“know how") del proceso de pruebas Est asegurado un dsero de prusbas apropiado = Se olcanza la optimizacin en el uso de métodos y heramientas - Disefio de casos de prueba de forma automatica - Generacién de casos de prueba asistida por ordenador, por ejemplo casos de prueba basados en documentos de especificaciones formales, también es independiente 1. Fundamentos de pruebas cartiteccheid 05 - Psicologia en el proceso de pruebas Hao sccameaannieasascabtensit Dificultades /1 - Incapacidad de comprensién mutua - Los desarrolladores deberian contar con un conocimiento basico de pruebas - Los probadores ("testers") deberian contar con un conocimiento bésico de desarrollo software - Especiaimente en situaciones de tensién, la deteccién de errores cometidos por alguien frecuentemente conduce a conflictos ~ La forma de documentar los defectos y Ia forma ena cual el defecto es descrito determinaré cémo se desarrollard la situacién - Las personas no deberian ser criicadas, los defectos deben ser descritos en téminos objetivos - La descripcién de los defectos deberia ayudar al desarrollador a encontrar el error ~ Los objetivos comunes siempre deben ser la cuestién principal seaianeceiennaes Ga rs emsvunstemsnere2 | - Fundamentos de pruebas 05 - Psicologia en el proceso de pruebas Diaz Hiterscheis “ se és Dificultades /2 - La comunicacién entre probadores |"‘testers"} y desarrolladores @s insuficiente o inexistente. Este hecho puede hacer imposible el trabajo conjunto = Los probadores ("testers") son vistos Unicamente como “portadores de malas noticias" ~ Mejora: intente ponerse en el lugar (rol) de Ia ola persona. gMi mensaje ha sido transmitido? gMe ha legac la respuesta? - Un proceso de pruebas sdlido requiere la distancia apropiada con respecto al objeto de prueba - Se adquiere un punto de vista independiente e imparcial a través de la distancia con respecto al desarrollo = Sin embargo, una distancia muy grande con respecto al objeto de prueba y el equipo de desarrollo conduciré a mayores esfuerzos y fiempo para las pruebas 1 - Fundamentos de pruebas 05 - Psicologia en el proceso de pruebas Diaz Hiterschaie Resumen - Las personas cometen errores, toda implementacién iene defectos - Lanaturaleza humana dificulta la posibilidad de hacer frente a los defectos propios [ceguera a los errores) - Desarrollador y probador ("tester") implican el encuentro de dos mundos distintos - i desarrollo es constructive - algo que no estaba ahi previamente es creado - El proceso de pruebas resulta destructive a primera vista - Se detectardn detectos! - Juntos, el desarrollo y las pruebas son constructivas en su objetivo de obtener un producto software con la menor cantidad de defectos posible - Las pruebas independientes aumentan Ia calidad del proceso de pruebas: En lugar de equipos de desarrolladores utilice equipos de prueba (probadores - “testers") 0 equipos con personal externo para pruebas saeieaat == ovaserCemeoso-NrlRaice Vi e851. EE 1 - Fundamentos de pruebas DazHiteschwia Contenido _scvomabasten a: oocURESTERiMMT Aor He manson Capitulo | - Fundamentos de pruebas - 01 gPorqué son necesarias las pruebas? - 02 gQué son las pruebas? S - 1/03 Siete principios del proceso de pruebas : - /04 Proceso de pruebas basico ‘ 1/05 Psicologia en el proceso de pruebas emer ct AR oh Paneee EE 1 - Fundamentos de pruebas 06 - Cédigo ético Diaz Hiterscheis Cédigo de conducta /1 Los individuos involucrados en el proceso de pruebas sofware fienen acceso a informacién muy privilegiada y critica. E| codigo de ética es necesario para asegurar que Ia informacién es utilizada de forma apropiada. - Pblico - Los probadores software certificados deben actuar conforme con el interés de su cliente y empleador, conforme con el interés pUblico, especialmente en aquellos trabajos relacionados con sistemas de seguridad critica donde se le podria solicitar Ia eliminacién de un informe de defectos de forma discreta, por ejemplo - Cliente y empleador - Los probadores software certificados deben actuar conforme con el interés de su cliente y empleador, conforme con el interés pUblico. Por ejemplo no fillrando a Internet informacién interna o privada del cliente o empleador. 1 - Fundamentos de pruebas 06 - Cédigo ético Diaz Hiltersceid Cédigo de conducta /2 - Producto - Los probadores suftware certificados asegurarén que los entregables que suministran (sobre los productos y sistemas que prueban) alcanzan los estandares profesionales mas altos. Significa que, trabajando como consultor no se omitan detalles importantes al cliente - Juicio - Los probadores software certificados mantendrén su integridac'e independencia en su juicio profesional. Tal vez un jefe de proyecto solicitara que se ocultaran defectos de importancia al promotor del proyecto ("business sponsor"), en el caso de que el probador accediera a la peticién resultaria en un menoscabo a la independencia y un fallo éticoDi etter eee -Mrlto 46.818 EE: 1 - Fundamentos de pruebas 06 - Cédigo ético at cago narksesan eE Hiterscheld Cédigo de conducta /3 - Gestién - Los gestores de prueba software certificados y responsables ("leaders") suscribirén y promoverén un enfoque ético a la gestion de las pruebas software. Favorecer-a un probador respecto a otro con el objeto de establecer una relacién de cardcter personal podria ser una seria contravencién a la ética de id gestién L - Profesién - Los probadores software cerlificados promoveran la integridad y reputacién de la profesién consistente con el interés pUblico. Hacer publico el efecto y formas en las que las pruebas software son un beneficio para la sociedad - Compaiieros de profesién - Los probadores software seran justos “ y solidarios con sus compafieros de profesin, y promoverdn la cooperacién con los desarrolladores de software pisaacpiaaceranemaeaa cine 5 eon ecm nana nt Es =) | - Fundamentos de pruebas Diaz Hiterscheid sera paonremaniben i aihaaamass hesinttbbaeremnat stars 06 - Cédigo ético Cédigo de conducta /4 Individualmente — Los probadores software certificados Participarén en procesos de formacién relacionados con su prdctica profesional de forma permanente y promoverdn un enfoque ético en la practica de la profesién. Una forma de mantener un aito nivel de conocimiento podria ser atendiendo ‘a cursos de formacién y leyendo libros ‘iii once an ra roanea Il - Pruebas a través del ciclo de vida software Contenido reir Capitulo Il - Pruebas a través del ciclo de vida software - 1/01 Modelos de desarrollo software - 1/02 Niveles de prueba - 1/03 Tipos de pruebas - 1/04 Pruebas de mantenimiento secant viet= Il- Pruebas a través del ciclo de vida software 2 Diartlitesehes Contenido nil fo Capitulo Il - Pruebas a través del ciclo de vida software 1/01 Modelos de desarrollo software ~ li/02 Niveles de prueba - 11/03 Tipos de pruebas - I/04 Pruebas de mantenimiento Se oes nciitimerndiing orb ani en = Il - Pruebas a través del ciclo de vida software Dartittescheig 01 - Modelos de desarrollo software narra sean dierent cant Raa Pruebas a través del modelo-V general (Modelo de desarrollo secuencial) - Elmodelo-V general es el modelo de desarrollo software més au utilizado s Desarrollo y pruebas son dos ramas iguales = Cada nivel de desarrollo tiene su correspondiente nivel de pruebas = Las pruebas (rama derecha) son disefiadas en paralelo al desarrollo software (rama izqvierda) Las actividades del proceso de pruebas tienen lugar a través del ciclo de vida software completoIl - Pruebas a través del ciclo de vida software 01 - Modelos de desarrollo software > once 18819 RES keescheid Pruebas a través del modelo-V general - Rama de desarrollo software ~ Definicién de requisitos Documentos de especificacién ~ Disefio funcional del sistema Disefio del flujo funcional del programa ~ Disefio técnico del sistema ~ Definicién de arquitectura J interfaces - Especificacién de los componentes ~ Estructura de los componentes Programacién + Creacién de cédigo ejecutable 2 aaa ica vain Il- Pruebas a través del ciclo de vida software partitescheg _01- Modelos de desarrollo software Pruebas a través del modelo-V general - Rama de pruebas software Pruebas de aceptacién ~ Pruebas formoles de los requisitos del cliente - Pruebas de sistema ~ Sistema integrado, espectficaciones ~ Pruebas de integracién = Interfaces de componentes + Pruebas de componente Funcionalidad del componente SS init ab sha 10:Il- Pruebas a través del ciclo de vida software castitestea 01 - Modelos de desarrollo software shear tans aa a CH Verificacién vs. Validacién : - Verificacién : - Comprobacién de la confommidad con los requisites establecidos (definicién segin ISO 9000) Cuestién clave: gSe ha procedide correctamente en la construccién der sistemar aaa: ietecae = gHemos sumado | més | correctamente? - Validacién - Comprobacién de Ia idaneidad para el uso esperado (definicién Z segun ISO 9000} ; - Cuestién clave: gHemos construido el sistema software correcto? ~ a€l objetivo era sumar 1 més 1 0 deberiamos haber restado? sustaining dn er —_ I- Pruebas a través del ciclo de vida software - Modelos de desarrollo software malin inmaaatine amine bet Diaz Hiterscheid svivanarencensial Verificacién dentro del modelo-V general - Cada nivel de desarrollo se verifica respecto de los contenidos eal del nivel que le precede - Verificar: comprobar la evidencia, substanciar = Verificar significa comprobar si los requisitos y definiciones de 1 niveles previos han sido implementados correctamente easIl - Pruebas a través del ciclo de vida software 1 - Modelos de desarrollo software Diaz Mitersceid Validacién dentro del modelo-V general - La validacién se refiere a la correccién de cada nivel de desarrollo - Volidiar: dar prueba de a aportacién de valor - Validar significa comprobar lo adecuado de los resultados de un nivel de desarrollo sits fh "ete eneepd imeem emis 2 ose cemcodn nna 8968838 BS ee Il - Pruebas a través del ciclo de vida software poctitenstaig 01 - Modelos de desarrollo software per denne abs REA ree sas 6 ha : Pruebas en el modelo-W - Elmodelo-W puede ser visto como una extensién del modelo-V general - Elmodelo-W lo pone de manifiesto de forma clara, ciertas actividades de aseguramiento de Ia calidad se desarrollaran en paralelo con el proceso de desarrolloIl - Pruebas a través'del ciclo de vida software ouzhitercreg _ 01 - Modelos de desarrollo software Ce a ah ERNE A Modelos iterativos: tipos de modelos iterativos /1 - Desarrollo software iterativo, ~ Las actividades: definicién de requisitos, disefio, desarrollo y pruebas se segmentan en pasos reducidos y se éjecutan de forma continua Se debe alcanzar el consentimiento con el cliente tras cada iteracién con el objeto de poder modificar el rumbo del proyecto si fuera necesario - Ejemplos de modelos iterativos: ~ Modelo prototipado: desarrollo rGpido de una répresentcicion del ~ sistema que pudiera ser objeto de uso, seguida de modificaciones sucesivas hasta que el sistema sea finalizado ~ Desarrollo répido de aplicaciones (“Rapid Application Development” - (RAD): La interfaz de Usuario se implementa uflizando Una funcionalidad previamente construida (“out-ot-the- box") simulando la funcionalidad que posteriormente sera desarroliada - Proceso unificado (“Rational Unified Process” - (RUP)): modelo ofientado a objeto y producto de la compara Rationai/IBM. Principalmente aporta el lenguaje de modelado UML y soporte al Proceso Unificado ~ Programacién extrema (“Extreme Programming” - (XP)): el desarrollo las pruebas tienen lugar sin Una especificacion de requisitos formalizada Ziti ment dnt ern —_ Il - Pruebas a través del ciclo de vida software Dartiitewched 01 - Modelos de desarrollo software sacaamereen nibble nimiiobions sir. saIl - Pruebas a través del ciclo de vida software 01 - Modelos de desarrollo software Hiterscheis Modelos iterativos: Caracteristicas - Caracteristicas de los modelos iterativos: - Cada iteracién contribuye con una caracteristica adicional del sistema a desarrollar - Cada iteracién puede ser probada por separado - Las pruebas de regresién y ia automatizacién de pruebas son elementos/factores de gran relevancia = En cada iteracién, ja verificacién (relacién con el nivel precedente) y la validacién (grado de correccién del producto dentro del nivel actual) se pueden efectuar por separado bane mies etme ay en my regia i Il - Pruebas a través del ciclo de vida software 01 - Modelos de desarrollo software Diaz Hitescheid Modelos iterativos: desarrollo guiado por pruebas (“Test driven development") - Basado en: juegos de casos de prueba - Preparacién de ciclos de prueba (“Test cycle") - Pruebas automatizadas con el uso de herramientas de prueba - Desarrollo de acuerdo a casos de prueba - Preparacién temprana de versiones de componentes para su prueba - Ejecucién automética de pruebas - Correccién de defectos para versiones futuras Repeticién de juegos de prueba hasta que no se detecten defectos Primero se disefan las pruebas, a continuacion se codifica (programa) el software: eon wie sata 68ll - Pruebas a través del ciclo de vida software ooatitenchag _ 01 Modelos de desarrollo software sean anarenieeaorren oo ctnasn nus - > ee ES Principios de todos los modelos - Cada actividad de desarrollo debe ser probada - Ninguna porcién del software puede quedar sin ser probada, si ha sido desarrollada tanto de forma “un procedimiento” o iterativa - Cada nivel de prueba deberia ser probado de forma especitica - Cada nivel de pruebas cuenta con objetivos de prueba propios = Las pruebas llevadas'a cabo en cadanivet deber retlejar estos objetivos - Elproceso de pruebas comienza mucho antes que Ia ejecucién de pruebas - Tan pronto como el desarrollo comienza puede comenzar la preparacién de las pruebas corespondientes ~ También es el caso de las revisiones de documentos comenzando por los conceptos, especificacién y el disefio global (en conjunto) aiaasaitodabanrg eit ern ain 16657 Il - Pruebas a través del ciclo de vida software pactitencheig 01 Modelos de desarrollo software sraeieow aaeaneilnsscertze sic semeiesert esate Resumen - Los modelos de desarrollo software son utilizados para el desarrollo software incluyendo las actividades del proceso de pruebas - Elmodelo més conocido es el modelo-V, el cual describe los niveles de desarrollo y niveles de prueba como dos ramas relacionadas - Los modelos iterativos mas importantes son RUP, XP y SCRUM - Las actividades de pruebas estan recomendadas en todos los niveles de desarrollotoate EET = Il - Pruebas a través del ciclo de vida software Diaz Hilterscheid Contenido Capitulo Il - Pruebas a través del ciclo de vida software -_ 1/01 Modelos de desarrollo software 11/02 Niveles de prueba 11/03 Tipos de pruebas - 1/04 Pruebas de mantenimiento a a 3Il - Pruebas a través del ciclo de vida software 02 - Niveles de prueba mined ss te eecevnnetect unica Diaz Hiterscheid Definicién - Prueba de componente (pruebas unitarias) - Pruebas de cada componente tras su J tealizacion/construccion ? - Dadas las convenciones de cada lenguaje de a programacién para la asignacién de nombres a sus fespectivos Componentes, se podra hacer. referencia a un componente como: ~ Prueba de médulo ("module tet") (por ejemoto en ~ Prueba de clase (“class fest")(por ejemplo en Javao C+] - Prueba de unidad (“unit test") (por ejemplo en Pascal) - Los componentes son referidos como médulos, clases 0 unidades. Dado que los desarroliadores posiblemenie pudieran estar involucrados en la ejecucién de pruebas, éstas también son fenominadas pruebas de desarrollador (developer's test) ea iy oi mmmtincng ait etn em Il - Pruebas a través del ciclo de vida software 02 - Niveles de prueba diskarieiasrensieranase ee: Diaz Hiterscheid tomar neces Pruebas de componente - Bases de prueba = Requisitos de componente 3 ~ Disefo detallado - Cédigo - Objetos de prueba ~ Componentes / clases / unidades / médulos ~ Programas - Conversién de datos / migracién de programas ees - Médulos de base de datos : Sanita ect nb ami nepaleeviieassia TERE Ss Il - Pruebas a través del ciclo de vida software 02 - Niveles de prueba Pruebas de componente: Alcance - Sdlo se prueban componentes individuales - Un. componente puede estar consfituido por un conjunto de unidades més pequenias Los objelos de prueba no siempre pueden ser probados en solitario (de forma auténoma} - Cada componente es probado de forma independiente = Descubriendo fallos producidos por defectos internos = Los efectos cruzados entre componentes quedan fuera del alcance de estas pruebas - Los casos de prueba podrén ser obtenidos a partir de: - Especificaciones de componente = Disefio software ~ Modelo de datos > tendonitis ih ose roams Il - Pruebas a través del ciclo de vida software 02 - Niveles de prueba Pruebas de componente: Pruebas funcionales / no funcionales /1 - Probar la funcionalidad - Toda funcionalidad debe ser probada, porlo menos, con un caso de prueba ~ Las funciones: Se realizan corectamente? = 4Se cumplen todas las especiticaciones? - Defectos detectados normaimente: ~ Defectos en el procesamiento de dates, normaimente en el entoino de los valores limite ("boundary values") - Funciones ausentes (“missing fun: _— 2 oe oe a on oe nn on on on on nn oe ll2 ota Cates Nl too¥ 9264819 Pst ee Il - Pruebas a través del ciclo de vida software 02 - Niveles de prueba sina sss Diaz Hiterscheid Pruebas de componente: Pruebas funcionales / no funcionales /2 - Probar la robustez (“testing robustness") (resistencia a datos de entrada invdlidos) - Los casos de prueba que comprueban datos de entrada invalidos se denominan pruebas negativas ("negative test”) - Un sistema robusto aporta un tratamiento apropiado para datos de entrada erréneos ~ La.aceptacién por parte del sistema de datos de entrada erréneos ‘puede producir fallos en un futuro procesamiento de los mismos (datos de Salida erréneos, fallo del sistema ("system crash")) - Pueden ser probados otros atributos no funcionales = Por ejemplo: pruebas de rendimiento y estrés, fiabilidad ‘Soe ere sistent cng Sn en sirmie) Pee Il - Pruebas a través del ciclo de vida software 02 - Niveles de prueba dL eatiebeea aman ies Pruebas de componente: Arnés de pruebas - La ejecucién de pruebas de componente requiere frecuentemente controladores ("drivers") y stubs ~ Un controlador (“driver”) gestiona/trata la interfaz de un componente = Los controladores (“ckivers") simulan datos de ‘enlrada, regisitan datos de saliday apoztan un amés de pruebas ("test hares ~ Los controladores ("ckivers")utiizan hertamientas de programacin - Un stub reemplaza o simula un componente que ain no se encuentra disponible o que no es parte del objeto de prueba ("test object") - Para programar controladores y/o stubs: - Se debe contar con conocimientos de programacién + Se necesita disponer del cédigo fuente - Podrdn ser necesarias herramientas especialesIl - Pruebas a través del ciclo de vida software 02 - Niveles de prueba titres Pruebas de componente: Métodos - Ei cédigo fuente se encuentra disponible para el probador (“tester”) ~ Caso “probador |"tester") = desarrollador”: Las pruebas se desarrolian con una fuerte orientacién hacia el desarrollo - Se podrd aplicar al disefio de casos de prueba el conocimiento de Ia funcionalidad, estructura de componentes y variables - Las pruebas funcionales seran pertinentes (con frecuencia) - Adicionalmente, el uso de depuradores (“debuggers”) y otras herramientas (por ejemplo marcos de prueba unitaria ~ unit test frameworks) de desarrollo peiinititan aeceso directo a las variables del programa - Elconocimiento del cédigo fuente permitiré la aplicacién de métodos de caja blanca ("white box") para pruebas de componente rohit > obodacetengs-HeeAeico 926818 EEE Il - Pruebas a través del ciclo de vida software 02 - Niveles de prueba Diaz Hiterscheid Resumen: Pruebas de componente - Un componente es la unidad mas pequefia especificada de un sistema - Prueba de médulo, de clase, de unidad y de desarrollador son utlizados como sinénimos - Los controladores (“drivers”) ejecutardn las funciones de un componente y las funciones adyacentes que son reemplazadas por stubs - Las pruebas de componente podrén comprobar caracteristicas funcionales y no funcionales de un sistemaOiaz Hitescheid ll - Pruebas a través del ciclo de vida software 02 - Niveles de prueba iterscheid Pruebas de integracién (también pruebas de interfaz) - Bases de prueba - Disefio software y del sistema - Arquitectura = Flujos de trabajo ("workflows") = Casos de uso - Objetos de prueba tipi - Implementacién de subsistema de base de datos - Infraestructura - Interfaces - Configuracién del sistema = Configuracién de datos (“data configuration") Il - Pruebas a través del ciclo de vida software 02 - Niveles de prueba Se ae seis Pruebas de integracién (también: pruebas de interfaz) - Cada componente ya ha sido probado en lo referente a su funcionalidad interna (prueba de componente). Las pruebas de infegracién comprueban las funciones externas tras las pruebas de componente - Comprueba ia interaccién entre elementos software {componentes) enire distintos sistemas o hardware y software : {normaimente tras las pruebas de sistema} - La integracién es la actividad en la cual se combinan 4 componenies software individuales en subsistemas més amplios o enuna serie de sistemas = Lasignificacién de un problema de multiplataforma (cross- platform) puede ser necesario - Laintegracién adicional/subsiguiente de subsistemas también es parte del proceso de integracién del sistema = Puede ser ejecutadas por desarrolladores, probadores o ambosenotertnts-ttone¥ 003816 HEUER —2 Il- Pruebas a través del ciclo de vida software 02 - Niveles de prueba Diaz Hiterscheid Pruebas de integracién: Alcance /1 ~ Las pruebas de integracién asumen que los componenies ya han sido probados - Las pruebas de integracién comprueban la interaccién mutua entre componentes (subsistemas) software entre si ~ Interfaces con otros componentes - Interfaces GUIs / MMIs - Las pruebas de integracién comprueban las interfaces con el entomo del sistema ~ Enla mayoria de los casos Ia interaccién probada es e! comportamiento del componente y el entorno simulado ~ En condiciones reales tactores adicionales del entomo pueden influir en el comportamiento del componente - Los casos de prueba podrén ser obtenidos a partir de: - Especificacién de interfaces ~ Disefio de fa arquitectura (diseno} Modelo de datos rains Il - Pruebas a través del ciclo de vida software 02 - Niveles de prueba Diaz Witercheid Pruebas de integracién: Alcance /2 : - Sera probado un (subsistema) sistema compuesto de componentes individuales “as - Cada componente tiene una interfaz externa y/o intema que Bs interactéa con otro componente del (subsistema) sistema - Son necesarios controladores de prueba (“drivers”) (los cuales i aportan el entorno al proceso del sistema o subsisterna) - Conel objeto de permit o producir entradas y salidas del (subsistema) sistema - Conel objeto de registrar datos - Los controladores de pruebas ("drivers") del componente podran ser reufilizadas en estas pruebas es= Il- Pruebas a través del ciclo de vida software cartneneg 02- Niveles de prueba Pruebas de integracién: alcance /3 ~ Herramientas de control (“monitoring tools”) pueden apoyar las actividades de pruebas registrando datos y controlando las mismas pruebas ~ Los stubs reemplazan componentes ausentes ~ Los stubs programados reemplazarén datos 0 funcionalidad de un componente que atin no ha sido integrado - Los stubs asumirén tareas elementales de componentes ausentes ORR eHiicmunmemareeeENE EN Be HAN $ rae TS) ented etn 86818 pe ee Il - Pruebas a través del ciclo de vida software 02 - Niveles de prueba DaarHilterscheid a recat aadreciaatames Pruebas de integracién: Enfoque - El propésito de las pruebas de integracién es detectar defectos en las interfaces. Las pruebas de integracién comprueban la correcta interaccién entre componentes ~ Enire otras razones, con el objeto de comprobar aspectos relativos al rendimiento y la seguridad, requiriendo pruebas (no funcionales) adicionales ss - Alreemplazar controladores ("drivers") y stubs de prueba por components reales se pueden generar nuevos defectos tales como: - Pérdida de datos, manipulacién errénea de datos o entradas ‘: enréneas He = Los componentes involucradis interpretan los datos de entrada de una manera distinta ; = Los datos son transferidos en un momento incorrecto: muy pronto, muy tarde, a una frecuencia distinta de la requerida bis bss onions et agarot Cates -Nl Bien V6 10 BE. Il - Pruebas a través del ciclo de vida software 4 02+ Niveles de prueba bia ies Pruebas de integracién: Estrategias /1 - Hay diferentes estrategias para las pruebas de integracién - Elenfoque incremental es un elemento comin a la mayoria de los estrategias (excepcion: estrategia “Big Bang") ~ Las estrategias ascendente ("bottom-up") y descendent (“top- down") son las utlizadas con mayor frecuencia - Laeleccién de una estrategia debe considerar también aquellos ‘aspectos relativos a la eficiencia de las pruebas - La estrategia de integracién determina ia magnitud del estuerzo ‘fequerido para las pruebas [por ejemplo ¢l uso de herramientas, programacion de controladores (‘crivers") y stubs, etc.] ~ La finalizacién de Ia construccién de componentes determina, para todos los tipos de estrategias, el intervalo temporal en el cual el componente eslara disponibie. Por Io tanto, Ia estrategia de desarrollo influye en la estrategia de integracién - Encada proyecto especifico se debe considerar el compromiso entre la reduccién de fiempo y la reduccién esfuerzo en pruebas: ~ Probar aquello que se encuentra finalizado: mayores costes en pruebos y menor tiempo ocioso - Seguir un plan de pruebas de integracién estricto: menores costes y mayor tiempo ocioso reg = Il - Pruebas a través del ciclo de vida software 02 - Niveles de prueba sii aaa atic Diaz Hiterscheid Pruebas de integracién: Estrategias /2 Pructos BE pructas SR. pructas ae y" I wdwnmis sdbage om om senna neon | oneal] sisens @ ae asenre iy SEL page do «Lhe we ee i iaianan adn deals Fig Pers ao intescedn> rrearcumme nan 2888 ME Il - Pruebas a través del ciclo de vida software 02 - Niveles de prueba edesbanasil odbderconatscs itn a Pruebas de integracién: estrategias /3 + Integracién ad-hoc = Los componentes serén probados, si fuera posible, inmediatamente después de haber sido finalizada su construccién y se hayan 2 finalizado las pruebas de componente : - Caracteristicas de Id integracién ad-hoc. - Inicio temprano de las actividades de prueba, dando lugar a un proceso de desarrollo software més corto en términos globales = Controladores ("drivers") y stubs serén necesarios dependiendo del fipo de componentes finalizados - Uso de fa integracién ad-hoc - Suna estrategia que puede ser aplicada en cualquier etapa del proyecto - Esuna estrategia que, normalmente, se apiica combinada con otras Cod Ab hes meche Prog re—enk, o medlih Jee to progyen—= se peecbe cone hitlimentadaetee i tnt Geran Il - Pruebas a través del ciclo de vida software paritescred 02 - Niveles de prueba ss aa ba ee Sona 2 otc 1B6818 BEE Resumen: Pruebas de integracién = Integracién significa construir grupos de componentes. - Las pruebas de integracién comprueban Ia interaccién entre componentes respecto de la especificacién de interfaces = Laintegracién ocure de forma ascendente ("bottom-up"), descendente (“top-down”) o en forma de “Big Bang” - _Integracién de subsistemas (estan constituidos por componentes integrados) también es un forma de integracién - Cualquier estrategia de integracién distinta a las anteriores es integracién ad-hoc rai eeespiressinen— Il - Pruebas a través del ciclo de vida software 02 - Niveles de prueba a Diaz Hiterscheid Pruebas de sistema ("‘system testing") - Bases. de prueba ~ Especificacién de requisitos software y de sistema ~ Cases de uso ~ Especificacién funcional ~Informes de anélisis de riesgos ("risk analysis reports") - Manuales de sistema, usuario y operaciones - Configuracién del sistema = Datos de configuracién ("configuration data") no rea Petes Catatonia V6 510 EE == Il - Pruebas a través del ciclo de vida software darniesched 02 - Niveles de prueba i cpierammsinise Arse ven Pruebas de sistema (“system testing") = Proceso de probar un sistema integrado con el objeto de comprobar el cumplimiento de requisites especificados - Las pruebas de sistema significa el comportamiento del sistema completo - Elalcance esta definido en el Plan de Prueba Maestro ("master test plan) 0 Plan de Prueba de Nivel ("level test plan") : - La calidad software es observada desde el punto de vista del usuario - Las pruebas de sistema se refieren a (segun ISO 9126) = Requisitos funcionales y no funcionales (Funcionalidad, fiabilidad, usabilidad, eficiencia, mantenibiidad, portabilidad) - Las caracteristicas de la calidad de datos son la base para las pruebas - Los casos de prueba podran ser obtenidos a partir de: ~ Especificaciones funcionales - Casos de uso - Procesos de negocio - Evaluacién de riesgostte ES Il- Pruebas a través del ciclo de vida software oashitencteg 02- Niveles de prueba eearoemeroiia Sonne Pruebas de sistema: alcance - Prueba de un sistema integrado desde el punto de vista del usuario : = Implementacién completa y corrécta de los requisitos ~ Despliegue en el entomo real del sistema con datos reales - Elentorno de pruebas deberia coincidir con el entomo real = No son necesarios stubs o controladores ("drivers") 5 = Todas las interfaces extemas son probadas en condiciones reales = Emulacién préxima al futuro entoro real del sistema - No se realizan pruebas en el entorno reall! = Los defectos inducidos podrian dafiar el entorno real = Unsofiware objeto de despliegue se encuentra en un estado de < cambio constante. La mayoria de las pruebas no serén reproducibles . rod Catenc tien 86 10 a Il- Pruebas a través del ciclo de vida software pactitenned 02 - Niveles de prueba nooner cone a cama iio ins Pruebas de sistema: requisitos funcionales /1 - Objetivo: comprobar que Ia funcionalidad implementada expone las caracteristicas requeridas Ee - Las caracteristicas a ser probadas incluyen (segun ISO 9126): - Adecuacién ("suitability") = Las funciones implementadas son adecuadas para su uso esperado? Exactitud ("accuracy") = Las funciones presentan los resultados comrectos (acordados)? Interoperabilidad ("interoperability") = gas interacciones con el entorno del sistemia presentan algin problema? Cumplimiento de funcionalidad ("compiiance") 25 = g€lsistema cumple con normas y regiamentos aplicables? = + Seguridad ["security") fa ~ 2£stén protegidos los datos/programas contra acceso no deseado 0 pérdida? S inane co ae im ale 154—2 I - Pruebas a través del ciclo de vida software stitewhes 02 Niveles de prueba ar baci SE RC Pruebas de gceptacién: aceptacién contractual y ‘aceptacién de regulacién (“regulation acceptance”) = gElsoftware satistace todos los requisitos contractuales? Con la aceptacién formal se cumpien hitos legales: comienzo de fase de garantia, hitos de abono (pago}, acuerdos de mantenimiento, etc, = Cfiterios de aceptacién verificables definidos en el momento del acuerdo contractual consfituyen una garantia para ambas partes. = Las pruebas de aceptacién deben tener en cuenta normas y, reglamentos gubemamentales, legales, industriales y de otro tipo {por ejemplo regiamento de seguridad “FMVSS 208: Federal Motor Vehicle Safety Standards") Pruebas de aceptacién: Pruebas de aceptacién de usuario = Normalmente el cliente selecciona casos de prueba para las pruebas de aceptacion = Normaimente se verifica la adecuacién al uso del sistema por parte de Usuarios de negocio, “ios clientes conocen su negocio" = Las pruebas se realizan utilizando el entomo del cliente. = Elentomo del cliente puede producir nuevos fallos z etc -inbe 888 = Il - Pruebas a través del ciclo de vida software Dortiteccheid _.02 - Niveles de prueba Rrra na Pruebas de aceptacién: pruebas de aceptacién operativa - Requiere que el software sea adecuado para su uso en un entorno de produccién = Infegracién del software en Ia infroestructura TI del cliente (Copios de seguridad/restauracién de sistemas, reinicio, instalacién capacidad de ser desinstalado, recuperacién en caso de desastres, etc) - Gestién de usuarios, interaccién con ficheros y estructuras de directorios en uso = Compatibiidad con otros sistemas (otros ordenadores, servidores de base de datos, etc.) - Tareas de mantenimiento - Tareas de carga y migracién de datos - Comprobaciones periédicas de vuinerabilidades de seguridad - Con frecuencia, las pruebas de aceptacién operativa son realizadas por el administrador de sistemas del clienteIl - Pruebas a través del ciclo de vida software vuenuneg 02 Niveles de prueba Pruebas de aceptacién: pruebas alpha y pruebas beta - Esnecesaria una versién preliminary estable del software - Pruebas realizadas en productos software comerciales (COTS* software) : - Elcliente uiliza el software para hacer el tratamiento de sus procesos de negocio cotidianos en las dependencias del proveedor [pruebas alpha - (“alpha testing")] 0 en sus propias dependencias [pruebas beta - (“beta testing")] - Se aporta informacién ("feedback") respecto de problemas detectados, usabilidad, etc. = Ventojas de las pruebas alpha y beta = Reduce el costo de las pruebas de aceptacién = Se utiizan distintos entornos = Involucran o un alio ndmero de usuarios *COTS = Commercial off the shelf eee wegen nine Il - Pruebas a través del ciclo de vida software ee 02 - Niveles de prueba lenin = reese uae ot 86818 ee Diaz Hiterscheid cemmprroensviiaaii eae Resumen: pruebas de aceptacion e - Las pruebas de aceptacién son las pruebas de sistema por parte del cliente ® - Laprueba de aceptacién es una actividad de coracter contractual, se verificard entonces que el software satisface los requisitos del cliente - Las pruebas alpha y beta son pruebas ejecutadas por clientes reales 0 potenciales, tanto en las dependencias de! desarrollador (alpha} como en las dependencias del cliente (beta) aE aR inh AA vognpiee > ~~~ mraques mar "1050 poanian aanar programas o aatos preci een! ee subgooodeCnieaie-bitaieeV1B6830 CEG ' = Il - Pruebas a través del ciclo de vida software Tuutemhee 03 Tipos de pruebas 1 B. Pruebas de caracteristicas software no funcionales - Objetivo: caracteristicas del producto software ojo t ~ ade qué forma el software lleva a cabo sus funciones? 7 70: - Las caracteristicas de calidad no funcionales { s fiabilidad, Usabilidad, eliciencia, mantenibiidad, portablidaa) a menudo son 1 vagas, incompletas o inexistentes, dificultando las pruebas | asociddas a las mismas - Ambito de aplicacién i - Las pruebas no funcionales se pueden llevar a cabo en todos los ' niveles Pruebas no funcionales tipicas: Pruebas de cargol “logs testing /pruckes de rencimionto, ("performance festina"] / pruebas de volumen (“volume testing") / 1 yebos de ls caracleristicas de seguridad [efectos adversos) del) -b Software| "Testing of safety feclures jeba de fiabiidad y robustez ("relbilty and robustness testing") 1 Pruebos de usabildad |"usabily testing") / pruebas de configuracién [eoniiguration fesing") - Blecucién = La conformidad con los requisitos no funcionales se miden utiizando ' requisiios funcionales [seleccionados) ies ‘de esirés ("stress festing®) ii ec in ean ‘ ee = IL- Pruebas a través del ciclo de vida software arkitexcwes 08 Tipos de pruebas sr i i a B. Pruebas no funcionales (pruebas de sistema) - Prueba de carga (“load test") ~ Sistema bajo carga (carga minima, mds usuarios/transacciones) - Prueba de rendimiento (“performance test") = Rapidez con la cual un sistema ejecuta una determinada funcién - Prueba de volumen (“volume test") - Procesamiento de grandes cantidades de datos / ficheros - Prueba de estrés (“stress test") = = Reaccién ala sobrecarga / recuperacién tras elretorno aun carga. normal 3 - Prueba de estabilidad (“stability test") Rendimiento en "modo de operacién continue! - Prueba de robustez (“test for robustness") ~ Reaccién a entradas erréneas o datos no especificados - Reaccién a fallos hardware / recuperacién ante situaciones de desostre 5 i ia ricer secre2 esate Getente-Ml bce 1065512 ERT Diaz Hiterschele Il - Pruebas a través del ciclo de vida software 03 - Tipos de pruebas B. Pruebas no funcionales (pruebas de sistema) Pruebas de cumplimiento ~ Cumplir normas y reglamentos [interme / externo) Pruebas de usabilidad - Estructurado, comprensible, facil de aprender por parte del usuario Otros aspectos no funcionales de calidad: = Portabilidad: adaptabilidad, reemplazabilidad, instalabilidad, coexistencia, cumplimiento de portabilidad - Mantenibilidad: analizabitidad, modificabilidad, estabilidad, testabilidad, cumplimiento de mantenibilidad - Fiabilidad: madurez, tolerancia a fallos, recuperabilidad, cumplimiento de fiabilidad “ese vince ernie amb ate emma reaiiaiae Diaz Hitersch Il- Pruebas a través del ciclo de vida software é wa _03- Tipos de pruebas : ocsnoCanace za a ovis sande ‘ C. Pruebas de Ia estructura software / Arquitectura (pruebas estructurales Objetivo: Cobertura - Andlisis de la estructura de un objeto de prueba (enfoque: caja blanca) ~ La finaiad de las pruebos es medi el grado en el cual la esiuctura __ del objeto de prueba ha sido cubierlo por los casos de prueba Ambito de aplicacién ~ Las pruebas estructurales son posibles en todos los niveles de pruebas, la cobertura del cédigo se realiza de forma conjunta alas pruebas de componente y de integracion mediante e! uso de ierramientas - Eldiseno de pruebas estructuraies se finaliza tras haber sido disentadas las pruebas funcionales, con el propésito de obtener un alto grado de cobertura Ejecucién ~ Se probard la estructura interna ie un objeto de prueba {por ‘ejemplo el flujo de control en el inferior de un componente, el flujo.a través de la estructura de un mend) : = Objetivo: fodos los elementos estructurales identificados deberén estar Cubierfos por casos de prueba “Selena todos bes aiecles dr Probes i regiees EEE Il - Pruebas a través del ciclo de vida software 03 - Tipos de pruebas Diss Hiterscheld D. Pruebas asociadas al cambio /1 - Objetivo: probar el objeto después de cambios - Después de que un objeto de pruebas 0 el entorno de su sistema ha sido objeto de modificacién los resultados de pruebas asociadas al cambio resultan invalides: las pruebas deben ser repetidas - Dos razones para modificar el software - Correccién de errores = Extensién funcional = Debido a los efectos secundarios de la funcionalidad extendida o nueva, es necesario también repetir pruebas ce Greas adyacentes ly Preebes esecedes cla bs: cescesion, cobaet etn Canin ie 88 Moe ==) Il- Pruebas a través del ciclo de vida software oartitescrea _03- Tipos de pruebas sir rest Getahics ramen D. Pruebas asociadas al cambio /2 (Repeticion de pruebas o pruebas de regresién) - Areas de aplicacién - Repetir una prueba de funcionalidad que ha sido verificada previamente se denomina prueba de regresion - Elgicance de la prueba Ge tecresisn depend deliesao— que la nueva implementacién de la fUncionalidad Jextensién Score 6 errores) impone alsistema - Elandlisis del riesgo se puede realizar con un anélisis de impacto - Las pruebas de confirmacién/regresién pueden ser realizadas en todos los niveles de prueba - Las pruebas fipicas después de un cambio: - Repeticién de prueba ["re-testing") [= pruebas tras la correccién. de erores] ~ Pruebas de regresién ("regression testing") [= pruebas para revelar / descubrir nuevos defectos introducidos recientemente] oaiba 18Il - Pruebas a través del ciclo de vida software 03 - Tipos de pruebas Diaz Hiterscheid D. Pruebas asociadas al cambio /3 - fjecucién = Bésicamente la ejecucién tiene lugar de la misma forma en ta cual se han ejecutado tas pruebas en iteraciones previas ~ En la mayoria de los casos, una prueba de regresién completa no es Viable dado sus altos costes y duracién = Un alto grado de moduloridad en el software permite unas pruebas de regresion reducidas més apropiadas - Citerios para la seleccién de casos de prueba de regresién: ~ Casos de prusba de prioridad alta ~ Probar solamente la funcionalidad esténdar,saltarse casos y votiaciones especiales = Probar solamente la configuracién utilzada con mayor recuencia Probar solamente subsstemas / zonas seleccionadas del objeto de pruebos ~ Sidurante fases tempranas del proyecto resulta evidente que clertas pruebas son adecuadas para las pruebas de regresién, se deberé Considerar la automatizacién de estas pruebas = Il- Pruebas a través del ciclo de vida software Darniteschea 03 Tipos de pruebas sennnescs abi emiaiamaen a oscrscsscs sini Resumen - Enniveles de prueba distintos se utilizan tipos de pruebas distintos - Los tipos de pruebas son: funcionales, no funcionales, estucturales y pruebas relacionadas a cambios - Las pruebas funcionales comprueban el comportamiento entrada / salida de un objeto de prueba - Los pruebas no funcionales comprueban las caracteristicas de un producto - Las pruebas no funcionales incluyen, pero no estan limitadas a, pruebas de carga, pruebas de estrés, pruebas de rendimiento, pruebas de robustez - Los pruebas estructurales habituales son pruebas que comprueban el flujo de control y datos en el objeto de prueba midiendo el grado de cobertura - Pruebas importantes después de un cambio: repeticién de pruebas (“re-fests") y pruebas de regresién (“regression testswiocovi sna 10 Se —2 Il - Pruebas a través del ciclo de vida software Contenido Diaz Hiterscheid Capitulo Il - Pruebas a través del ciclo de vida software - 1/01 Modelos de desarrollo software - 1/02 Niveles de prueba 1/03 Tips de pruebas ii/04 Pruebas de manténimiento reat> ee po Re Il - Pruebas a través del ciclo de vida software 04. Pruebas de mantenimiento Dl iterched Pruebas posteriores a la aceptacién del producto /1 - Elcliente ha aprobado el producto y es puesto en produccién - ciclo de desarrollo inicial, inclvidas las pruebas asociadas, ha sido completado - Elmismo software se encuentra al comienzo del ciclo de vida: + Seré utilizado por muchos afios, seré ampliado + Esmuy probable que ain contenga defectos, por lo tanto sera modificado y coregido - Necesitaré adaptarse a nuevas condiciones y deberé integrarse a nuevos entomos ~ Necesitaré cambiar o extender los datos de cenfiguracién + Seré retirado, se exiraeré del entomo de produccién - {Cualquier nueva versién del producto, cada nueva actualizacién y cada cambio del software requiere pruebas adicionales! 6 cag Moe ee tenedanaing BN BN NS? opie 18 > eee Pee Il - Pruebas a través del ciclo de vida software 04 - Pruebas de mantenimiento tiadamanintie wa Dic Hitercheis mas ivsccntioal Pruebas posteriores a la aceptacién del producto /2 - Configuracién = Composicién de un componente o de un sistema detinido como el numero, naturoleza e interconexiones de las partes que lo constituyen - Andlisis de impacto = Valoracién del cambio en las capas de documentacién de desarrollo, documentacién de pruebas y componentes, con el objeto de implementar un cambio dado en requisites especificados : - Pruebas de mantenimiento ~ Pruebas de los cambios en un sistema en operacién 0 el impacto de un entorno modificado para un sistema en operaciéneneancatrse- te Vibe EE as. —2 Il- Pruebas a través del ciclo de vida software 04 - Pruebas de mantenimiento Diaz Hiterscheid Pruebas posteriores a la aceptacién del producto /3 - Elmantenimiento de software cubre dos campos diferenciados: - Mantenimiento tal como: coreccién de errores o implementacién de “hot-fixes”, que han sido parte de Ia versién inicial del software Distribuciones de software planificados: adaptaciones como resultado una modificacién/cambio del entorno o nuevos requisitos del cliente - Alcance de las pruebas de mantenimiento: - “Holfixes" y la comeccién de defectos requiere la repeticion de pruebas ("re-test") - Laampliacién de la funcionalidad requiere nuevos casos de prueba La migracién a otra platatorra requiere pruebas operativas (“operational testing’ - Adicionalmente, son necesorias pruebas de regresién intensivas Los era weenie oe Seman TE, 2 evnecomean-tae ites EET Il - Pruebas a través del ciclo de vida software ces porting 04 - Pruebas de mantenimiento Pruebas posteriores a la aceptacién del producto /4 - Elalcance de las pruebas depende del impacto del cambio - Elandlisis de impacto se utiliza para determinar las Greas afectadas con el objeto de decidir la cantidad de pruebas de regresion - Pueden ocurtir problemas si la decumentacién del software antigua falta o es incompleta - Retirada del software “i ~ Las pruebas tras Ia retirada del software pueden inclu: = Pruebas de migracién de datos ~ Vetiicacién del archivo de datos y programas = Pruebas en paralelo de sistemas nuevo y su antecedente= Il - Pruebas a través del ciclo de vida software itercheig 04> Pruebas de mantenimiento Resumen - Una vez desarrollado el software necesita ser adaptado a nuevas condiciones, los errores deben ser corregidos - Un anéllsis de impacto puede ayudar a juzgar los cambios asociados a riesgos - Las pruebas de mantenimiento aseguran que = Las nuevas funciones son implementadas de forma correcta (nuevos casos de prueba) 4 - Los errores han sido corregidos de forma exitosa (casos de prueba 2: antiguos) - La funcionalidad, que ya ha sido verificada, no ha sido afectada (pruebas de regresién) - Siel software debe ser retirado, pueden ser necesarias pruebas de migracién o pruebas en paralelo : ba hrmeeeencinmiacing remem see,= Ill - Técnicas estéticas Diaz Hilterscheid Contenido Capitulo Ill - Técnicas estdticas = Il/01 Técnicas estaticas y el proceso de pruebas - IlI/02 Proceso de revisiones ~ I/03 Andlisis estatico con herramientas sad il Técnicas estéticas Contenido Diaz Hiterscheiat Capitulo Ill - Técnicas estéticas IWOT Wenicds estGticas y el proceso de pivebas, ~~ = IlI/02 Proceso de revisions - III/03 Andlisis estatico con herramientas: snc ine_ ‘ire enspnnerwinmenseg anna ese 2 Ill - Técnicas estdticas Daz Hitec 2 potent toc 859 aS Ill - Técnicas estaticas durbiitercheig 01 - Técnicas estdticas y el proceso de pruebas Enfoque basico - Las técnicas estaticas de pruebas comprenden varios métodos que no ejecutan el componente o sistema objeto de la prueba - Los pruebas estaticas incluyen: = Revisiones (“reviews”) (actividad manual) Andlisis estdtico (“static analysis") (actividad basada en herramientas) = Las técnicas estaticas complementan los métodos dinémicos = Las pruebas estaticas detectan c¢ ios (defectos) er de lales jenuuont - [os conceptos también son analizados, no sdlo el cédigo ejecutable. oe = Los defectos / desviaciones son detectados en una fase temprana, f. antes de que sean implementadas en el cédigo ~ Las pruebas estdticas byeden descubit defecias ave-no ctables en las pruebas dinamicas ~ Documentos de alfa calidad concucen a productos de alte a ~ Incluso si una especificacién revisada no contiene ningin defecto, la ferpretacién de Ia especificacion y creacién del disefio pueden ser jectuosas 01 - Técnicas estaticas y el proceso de pruebas seaman” seein elesd Objetivos de las revisiones - Las revisiones se realizan con el objeto mejorar la calidad del producto = Las revisiones se utiizan para verificar la correcta transicién de una fase a la siguiente, segin esta definido en el lado izquierde del modelo- - Ladeteccién temprana de errores ahorra costes - Enel transcurso de las revisiones se podrian gym detectar los siguientes defectos: - Defects en las especificaciones = Defectos en el disefio y arquitectura del software ~ efectos en las especificaciones de interfaces - Mantenibilidad insuficiente ~ Desviaciones con respecto a estindares acordadés (por ejemplo guias de a programacién) reer,—2 Ill - Técnicas estaticas 01 - Técnicas estaticas y el proceso de pruebas Diaz Hiterscheid Ventajas y desventajas de las revisiones - Ventajas - Costes més bajos y un alto potencial de ahorro = Los defectos en la documentacién son detectados y coegidos de forma temprona = Los documentos de alta calidad mejoran el proceso de desarrollo = Mejora el indice de eomunicacién / intercambio de conocimiento ("know-how") - Desventajas ~ Se podtian presentar situaciones de tensién en el caso de enfrentamientos cirectos con el autor = Los expertos involucradas en las revisiones deben adquitir conocimientos especificos de! producto, es necesaria una buena preparacién = Inversion considerable de fiempo {del 10% - 15% del presupuesto total) - - Moderador y parlicipantes influyen directamente en la calidad de la revision tit seo Na vedpstonIll - Técnicas estaticas Diaz Hilterscheid Contenido sSianantora 260 samaeecan es Capitulo Ill - Técnicas estdticas -_II/01 Técnicas estéticas y el proceso de pruebas 1/62 Proceso de mn z ~ I1l/03 Andlisis estatico con herramientas ‘Sneed Ill - Técnicas estéticas cartiencheis _ 02- Proceso de revisiones soar anannnaan ie ieboasireeebaem in sadoaeraniect 2 Pot Crt ste 186512 ES Actividades de una revisién formal /1 - Planificacién f = Definicién de los criterios de Ia revision (lstas de comprobacién. tipo de revision) Seleccién del personal (revisores, moderador,...) Asignacién de roles y tiempo en el calendario del proyecto (quien i hace qué) - Definicién de los criterios de entrada y salida para revisiones formales - Seleccionar qué partes de los documentos serdn revisadas ae {dependiendo de Ia importancia o complejidad) Ae - Inicio (“kick-off”) = Distbucién de documentos (a los revisores) - Explicacién de los objetivos, proceso y documentos llistas de comprobacién} - Comprobacién de los criterios de entrada (para revisiones mas formales) 2 Eshediee gb Ppend erIll - Técnicas estaticas 02 - Proceso de revisiones Diaz Hiterscheid Actividades de una revisi6n formal /2 - Preparacién individual = Los revisores inspeccionan los objetos. identifican elementos que requieren aclaracién - Identificacién de defectos potenciales, preguntas y comentarios - Reunién de revision = Reunién de los miembros de la revision, los revisores presentan sus resultados = Discusién o registro, con resultados documentados = identificacién de defectos, presentacién de recomendaciones respecto del tratamiento de los defecto, toma de decisiones respecto de los defectos - Examen / Evaluacién / Registro ~ Durante cualquier reunién fisica/seguimiento de comunicaciones électrénicas del grupo - Reconstruccién (“rework”) ~ Elautor cortige cuaiquier defecto identificado por los inspectores = Registro de estado actualizado de defectos roam esinsim sae ala bod Cutcode- eos 1196.15.18 a 2 Ill- Técnicas estéticas @ pastutenned 02 - Proceso de revisiones i a ss Actividades de una revisién formal /3 - Seguimiento (“follow up") = Comprobacién de que los defectos han sido tratados/recogida de métricas x4 = Decisién de mantener una segunda reunién de revisién si fuera necesario| - Comprobacién de los ctiterios de salida (revisiones formales) para dar el visto buenoIll - Técnicas estaticas bustilterched 02 - Proceso de revisiones sess cased a Roles y responsabilidades /1 - Jefe de proyecto (“manager”) - Inicia la revision, decide respecto de los participant - Asigna tiempo en el calendario del proyecto - Determina sise han alcanzado los objetivos de Ia revisién - Moderador (“moderator”) + Difige la reunién / 1a discusién, hace de mediador, concluye resultados - Planificacién de la revision / ejecucién de la revision / seguimiento posterior ~ Sobre quien recae Ia responsabilidad del éxito de la revision - Autor (“author’ = Redactor 0 responsable jefe del objeto de la revision = Expone su trabajo a la critica, lleva a cabo los cambios recomendados tage june naeemaeiening ami oy Ill - Técnicas estaticas 02 - Proceso de revisiones Sicidaeascnaareaers 2686 Roles y responsabilidades /2 = Revisor (“reviewer’) [también inspectores ("inspectors") 0 comprobadores ("checkers")] - Individuos con un baggje técnico o de negocio especificos + Detecta defectos, desviaciones, éreas problematicas, etc. = Bios representan diferentes perspectivas y roles en el proceso de revision - Deberian tomar parte en cualquier reunién de revision - Eseriba (“scribe”) - Documenta todos los asuntos, problemas y puntos que hubieran sido identificados - Los protocolos serén preparados de forma conjunta con un proyector tal vez en el caso de revisiones importantes. Posteriormente se contaré con un protocolo verficado Las revisiones observan los productos software 0 productos resultado del trabajo desde distintos puntos de vista. Las listas de comprobacién pueden hacer las revisiones mas eficientes. Una lista de comprobacién con los problemas tipicos puede ayudar a descubrir anomalias no detectadas previamente Diaz Hiterscheid esare0s ieIll - Técnicas estaticas 02 - Proceso de revisiones Roles y responsabilidades /3 - lista de comprobacién (“checklist”) - Ejemplo (depende del objeto de revisién) ~ Identiticar la audiencia objetivo = Crear un loge para el software = Crear un sitio Web para promocionar el software = Defi requisitos minimos del sistema - Optimizar el sitio Web para motores de busqueda (SEO) Configurar el Orden de las Paginas en el sitio Web - Crear una lista de beneficios clave (“key benefits list") = Los tétminos son correctos y tnicos = Los requisitos estan completos y son Unicos - Los comentanos estan "hablando" y en el lenguaje esperado = Todas las variables del eédigo comienzan con una “V" ~ Todas las constantes del cédigo serén nombradas en Maydsculos ~ Las interfaces son consistentes y con las mismas métricas 2 Ill Técnicas estaticas He neg 02 - Proceso de revisiones a coeliac. eb Seba Tipos de revisiones (IEEE 1028) /1 : - Elproceso basico de una revisién - como se esquematiza aqui - se apiica a las siguientes variantes: . A. Inspeccién{"inspection") B. Revisi6n guiada ("walkthrough") C. Revision técnica( "technical review") D. Revisién informal ("informal review") - Eslas variaciones difieren en algunos aspectos de la préctica de basica esbozadacapac seein = Ill - Técnicas estdticas piztitercheg 02 - Proceso de revisiones sashtateaite anaes sr SAbi Tipos de revisiones (IEEE 1028) /2 - Una diferencia adicional de las revisiones se presenta dependiendo de Ia naturaleza del objeto de Ia revision: producto 0 proceso ~ Proceso de desarrollo SW o proceso del proyecto = CMAN, ISO/IEC 18504, TPIson términos relecionades con a mejora del proceso = También denominade tevisién de geslién ("management review"), estas revsiones no interieren dicectomente en ol proceso de pruebas, no forman parte de este curso = Documentos / productos del proceso de desarrollo ~ Estas son las revisiones tratadas en el presente curso. sca parcis menaaninoen cri arma = I- Técnicas estaticas Diaz Hilterscheid 02 - Proceso de revisiones Tipos de revisiones (IEEE 1028) /3 - A. Inspeccién: caracteristicas relevantes = Los .evisores inspeccionan al objeto sujeto a revision haciendo uso de listas de comprobacién y métricas (por ejemplo, problemas por pagina} = Un moderador capacitado (formacién especifica) e independiente dirige Ia revision = La viabilidad de la revisin del objeto es valorada de forma previa a larevision - Criterios de entrada y salida especificados (previamente} para la aceptacién del producto software ~ Proceso formal basado en reglas y listas de comprobacién para las actividades de preparacién, ejecucion, documentacién y seguimiento - Normaimente realizada / ejecutada como una evaluacién entre pares = Preparacién previa ala reunién = Informe de inspeccién incluyendo Ia lista de hallazgos ("findings") Sai AcIll - Técnicas estdticas 02 - Proceso de re Diag Hiterscheia Tipos de revisiones (IEEE 1028) /4 - A. Inspeccién: ventajas y desventajas = Sesiones formales y organizadas con roles claramente definidos = Requiere actividades intensivos de preparacién y seguimiento ~ Son necesarios e! moderador y el escriba Propésito principal: deteccién de defectos utilizando un método estructurado Ill - Técnicas estaticas 02 - Proceso de revisiones s Tipos de revisiones (IEEE 1028) /5 Diaz Hiterscheid - _B. Revisién guiada (“walkthrough”): caracteristicas relevantes = Opcionaimente puede haber una preparacién de los revisores previa G la reunion ~ Sesiones abiertas ("open-ended - Peden tomar Ia forma de escenarios ("scenarios"), simulada (“dry run"), participacién grupal de pares Participation = Lareunién es dirigida por el autor - Noes necesario un moderador distinto (el autor modera) - Alo largo de la presentacién por parte del autor los revisores tratan de detectar desviaciones y/o dreas que representen un problema ~ Eemplos para el uso de revisiones guiadas: ~ Revision guiada de documentos = Revision guiada de Un defo preliminer de interfaz de usuario = Revisién guiada de modelo de datos del proceso de negocio jecucién ‘peer group=> Ill - Técnicas estéticas Diaz Hilterscheid 02 - Proceso de revisiones ii en Tipos de revisiones (IEEE 1028) /6 Revisién guiada (“walkthrough”): ventajas y desventajas Esfuerzo reducido en la preparacién de la sesién de revisién, pero es una sesion de resultado abierto E Una sesién puede ser iniciada a través de nofificaciones realizadas con poca antelacién El autor tiene una gran influencia sobre el resultado: dado que él mismo modera Ia revision, hay un riesgo de dominacién por su parte (puntos critico no abordados en profundidad) Posibilidad limitada de control, dado que el autor también se encuentra a cargo de cualquier actividad de seguimiento aaa cidasees mane s ream == Ill - Técnicas estéticas Diaz Hitched eu sr aoe ditties irhuaea etna 02 - Proceso de revisiones Tipos de revisiones (IEEE 1028) /7 - C. Revisin técnica (“technical review"): caracteristicas relevantes La meta del examen es un aspecto técnico del objeto en revision: 2es apto para el uso? Son necesarios expertos, preferentemente externos con la Participacién opcional de miembros responsables de la organizacién ("management") Se puede ejecutar como una revision entre pares (“peer review") sin la participacién de responsables de la organizacién Liderada, idealmente, por un moderador entrenado / formado espectficamente para la funcién, no por el autor Preparacién previa ala reunién por parte de los revisores Uso de listas de comprobacién con el objeto de no olvidar cosas importantes at sd niinninaip BRE Cdr) siiIll - Técnicas estaticas 02 - Proceso de revisiones Diaz Hiterscheid Tipos de revisiones (IEEE 1028) /8 - C. Revision técnica (“technical review"): caracteristicas relevantes - Elpanel de expertos presenta sus recomendaciones con cardcter undnime: ~ Preparacién de un informe de revisién que incluye la lista de hallazgos, el veredicto respecto de si el producto software cumple con los requisitos = Larevisién técnica puede ser muy formal o informal, dependiendo de Ia importancia > Instone MEER aNee Ill - Técnicas estaticas 02 - Proceso de revisiones erieindtemncsopst maser Na Oe iar Hiterscheid Tipos de revisiones (IEEE 1028) /9 - C. Revisién técnica (“technical review"): objetivo principales Discusién durante la revision - Tomar decisiones - Evaluar alternatives - Detectar defectos - Resolver problemas técnicos - Comprobar a conformidad (estandares, planes, especificaciones, normativa) reds aelll - Técnicas estaticas 02 - Proceso de revisiones > moet tte 8 ES Diaz Hiterscheid Tipos de revisiones (IEEE 1028) /10 - _D. Revisiones informales: caracteristicas relevantes = E5la forma de revision mas simple - Frecuentemente iniciada por el autor - Solamente estardn involucrados revisores (uno o més) - No es necesaria ninguna reunién por separado - Los resultados pueden ser registrados en forma de una lista de accién = Normalmente se inicia / desarrolla con la solicitud de la revision de un documento a un compariero de trabajo ~ También denominada: revisién entre pares ("peer review") Fed war nace ar emt Il - Técnicas estdticas oartiteccieg 02 - Proceso de revisiones sgortrne sce nies tnaenernaaneraraeims Tipos de revisiones (IEEE 1028) /11 - _D. Revisiones informales: ventajas y desventajas = Fécil de ejecutar, incluso en los casos de notificaciones realizadas con poca antelacién i ~ Rentable| ~ No requiere protocol ‘lei ening cot desc ag "3=) Ill- Técnicas estéticas 02 - Proceso de revisiones faz Hiterscheia Factores de éxito de una revision /1 - Las revisiones se deben desarrollar orientadas al logro de objetivos, es decir, las desviaciones en el objeto revisado deben ser establecidas de forma imparcial - Elautor del objeto revisado deberd ser motivado de una forma positiva por ia revision (‘su documento sera atin mejor" en lugar de “su documento es de baja calidad”) = Uso sistemdtico de las técnicas y plantillas implantadas - Eluso de listas de comprobacién mejoraré Ia eficiencia de la revision - Para la ejecucién apropiada de las revisiones seré necesario un presupuesto apropiado (10% al 15% del costo total del desarrollo) - Hacer uso del efecto de las lecciones aprendidas, utilizar la retroalimentacién para implementar un proceso de mejora continua = I- Técnicas estaticas oosnitescheig _02 > Proceso de revisiones Factores de éxito de una revisién /2 - Las revisiones deben ser desarrolladas en un ambiente de confianza - Elresultado no seré utlizado para evaluar a los participantes de la revisién = Los probadores son revisores valorados que contribuyen con la revision y también aprenden sobre el producto de tal forma que les permite prepara pruebas de forma temprana - Involucrar a la gente adecuada en funcién de los objetivos de la revision - Hay un énfasis en el aprendizaje y en la mejora del proceso ese= Ill - Técnicas estéticas caritenthes 02 - Proceso de revisiones Sores rarer BTR Resumen i - Enel transcurso de las pruebas estdticas no se ejecuta el objeto de prueba - Las revisiones pueden tener lugar en fases tempranas del = proceso de desarrollo, ellas complementan/extienden los = métodos de pruebas dinémicas - Fases de una revision: = Planificacién - preparacién - preparacién individual - reunion ~ reconstrucci6n - seguimiento. => 9)7 - Roles y fareas para una revision: = Director - moderador - escriba - autor - evaluador/revisor ~>O)F - Tipos de revisione: = Inspeccién (inspection) - revisién guiada ("walkthrough") - revision técnica (technical review") - revisién informal ("informal review") ‘ iealipeaenibngnhasitn ge ison ssa oo iiaIll - Técnicas estaticas Contenido Capitulo Ill - Técnicas estéticas - III/01 Técnicas estéticas y el proceso de pruebas 1i1/02 Proceso de revisiones nyhemmamientas Ba iwi ibis es arm roi reomcaten tases: EAE Ill - Técnicas estaticas @ 03 - Andi estdtico con herramientas iaz Hiterscheid iones Terminologia y defini ~ Anélisis estatico (Definicién) i - Es aquella tarea que consiste en anglizarun objeto de prueba {por ejemplo cédigo fuente, scrip! (guién), requisito} sin eiecutar el objeto de pruebo. - Posibles aspectos a ser comprobados con andlisis estatico: i - Reglas y estandares de programacién - Disefio de un programa [andlisis del flujo de control} = Uso de datos (andlisis del flujo de datos) - Complejidad de la estructura de un programa + métticas, por ejemplo nimero ciclomatico ste nt omg regan2 Il - Técnicas estéticas pastitencte 03- Anélisis estdtico con herramientas ERED meen be Sa Aspectos generales /1 - Todos los objetos de prueba deben tener una estructura formal - sto es especialmente importante cuando se utiizan heramientas de pruebas ~ Conmucha frecuencia no se generan documentos formaimente - Enla préctica, lenguajes de modelado, programacién y de creacién de scripts ("scripting language") cumplen con la regia, dé la misma forma que algunos diagramas - Elandlisis estético de un programa mediante el uso de herramientas se desarrolla con un esfuerzo menor que el i necesario en una inspeccién ~ Porlo tanto con mucha frecuencia, el andisis estatico de ejecuta de forma previa a que tenga lugar una revision = Para detectar légica ausente o errénea (bucles potencialmente infinitos) - Para detectar consirucciones excesivamente complicadas, vulnerabilidades en el 4mbito de la seguridad interfaces inconsistentes, etc. a 1 bute iach niet ning ont dete? > etm cate tribe L8 De Il - Técnicas estaticas Dasntescteig _03 - Andlisis estdtico con herramientas -sShecaitennesncaoinsiaseans Seema rao Aspectos generales /2 El valor del andlsis estatico es la prevencién de defectos: = Para encontrar defectos tan pronto como sea posible antesde la ejecucién de pruebas - Para advertir sobre aspectos sospechosos de! cédigo - Para detectar discrepancias en el disefio a través del cdiculo de métricas como la medida de alta complejidad - Estos defectos pueden no ser encontrados facilmente con pruebas dindmicas - Detectando inconsistencias y dependencias = Para comprobar la mantenibilidad del cédigo o disefio Scape ineghtettsaee crimes oania—2 Ill - Técnicas estdticas Diaz —_ Ill - Técnicas estdticas Diaz Hilterscheidt pea 03 - Andlisis estatico con herramientas ‘a Aspectos generales /3 - Herramientas que deben ser utiizadas: Compiladores y herramientas de andiisis (analizadores} - Compilador = Detecta errores sintécticos en el cédigo fuente de un programa - Crea dates de referencia del programa (por ejemplo lista de referencia cruzada, llamada jerérquica, tabla de simbolos) ~ Comprueba Ia consistencia entre os tipos de variables - Detecta variables no deciaradas y cédigo inaccesible (cédigo muerto) - Analizador: trata aspectos adicionales tales como: - Convenciones y estandares ~ Métricas de complejidad - Acoplamiento de objetos 03 - Andlisis estético con herramientas omrmosarirPa ea maumensrinds sted cama Andlisis del flujo de control /1 = Propésito ~ Detector defectos causados por un desarrallo anémalo del codigo {ramas muertas, cédigo muerto, etc.) - Método = La estructura del cédigo se representa como un diagrama de control de flujo - Grafe dirigido ~ Los nodos representan sentencias o secuencias de sentencias = Las arislas representan a transferencic del iujo de control, como en ecisiones y bucles Construccién mediante herramientosIll - Técnicas estaticas buztitescheg 03 - Andlisis estdtico con herramientas serene et ee : Andlisis del flujo de control /2 - Resultados - Visi6n del conjunto del cédigo del programa comprensible - Las anomalias* pueden ser detectadas facilmente, los defectos se hacen evidentes - Bucles abandonados por saltos - Ramos muertas ~ Retomos multiples - Ungrafo de un flujo de control es una versién simplificada de un diagrama de fiujo *Anomalia: une ineguiaricad o inconsistencia “Seat hin emineenmsngentac ity ens) = Ill - Técnicas estdticas parnitescheg 03 - Andlisis estético con herramientas aoniaasarone ten bie mnice: Sniavhabmen. sniSsiaesacaaara os Andlisis del flujo de datos /1 = Propésito = Deteccién de anomalias en el flujo de datos con la asistencia de los diagramas de control de flujo y Conjeturas racionales respecto de las 5S secuencias del fivjo de datos : - Beneficios ~ Deteccién fiable de anomalias en el flujo de datos is = Se puede detectar facilmente Ia localizacién exacta de defectos = Esun buen complemento para otfos métodos de pruebas - Desventajas - Limitado a un rango reducido de fipos de defectos a Ill - Técnicas estéticas a 03 - Andlisis estatico con herramientas eee asa Diaz Hiltersch Andlisis del flujo de datos /3 - Ejemplo de anomalia en flujo de datos aa nese, fon valores de | ros iti an aio Exe sompio poster tov varabis ton teliente cone | Seambladce avis de una || - Lavan pw ect nse | funtion anoelin {Seemaemcsiomcasn | Orderades por vir rice i i | vo Mita ot n,n Me Lavan tn tes in| HM nin i) i “coaegnenimcemivonte || 1 atte: Seana sina tte | "Meron ima) & tr dei sine) pre nvr tig nat ne) help + om Min = dre | meysdedd i | Ciclo Cobedor 7=) Ill - Técnicas estéticas pustennes 03 Anélisis estético con herramientas Las métricas y su cdiculo = Ciertos aspectos de la calidad de un programa pueden ser medidios uilizando métricas = Lamétrica sdlo fiene relevancia para el aspecto medido (considerado} = La complejidad estatica de un programa puede ser medida. = Actuaimente hay oproximadomente 100 métricas diferentes disponibles - Métricas diferentes fratan aspectos diferentes de la complejidad de programa = Tamafio del programa (por ejemplo lineas de cédigo (“Lines of Code -LOC")) = €structuras de control del programa (por ejemplo némero Ciclomatico) tructuras de control de datos (por ejemplo métrica de Halstead ("Holsiead-Metiic") = Es dificil comparar dos métricas diferentes, incluso cuando ambas abordan el mismo atributo del programa! 2 Meter robe TMK Set em) Pagina 201) Ill - Técnicas estaticas 03 - Andlisis estdtico con herramientas ae Diaz Hiterscheid er ee ee Peers Las métricas y su implicacién /1 - NGmero ciclomatico v(G) HOpnennt2p ay - Métrica que mide la complejidad estatica de un programa basada en su grafo de fiujo de control = Mide los caminos linealmente independientes, como indice de la testabilidad y mantenibilidad = Elnémero ciclomético se define de la siguiente forma: Nomero de aritas: i = Nomero de nodos n = Numero de partes del programa independientes inspeccionadas: p (normaimente 1). - Valores hasta 10 son aceptables. Para valores superiores el : cédigo debe ser reconstuido ("reworked") /mejorado fovena § practica, McCabe) :Ill - Técnicas estaticas 03 - Andlisis estético con herramientas abide ibrar > mvoarCviese Hie 118010 EE Se Diaz Hi Las métricas y su implicacién /2 INGj=e—n¥2p] = Bjemplo Ili/03-2 - (Numero ciclomético} - El grafo de la derecha tiene: | partes independientes: = 14 nodes: = 1 aristos: - Esto conduce al numero ciclomatico: v(G)= en + 2p viG7 Ure-ntzP en Jos pesos an ee baz : nen sia) Si os C19 be Heder ger 15 meter ble 6 testeebh lll - Técnicas estdticas 03 - Andlisis estdtico con herramientas eso aboncpbarcwedit | oi techs Las métricas y su implicacién /3 = Ndmero ciclomético (por McCabe] - implicacién = Elnémero ciclomético puede ser ullizado como un valor objetivo para revisiones de cédigo = ELnGmero ciclomético también puede ser calculado como el niémero de decisiones independientes més uno. Silas dos formas de cdiculo aportan resultados diferentes se puede deber a: : = Roms superfiues = Romas fltontes - Elnimero ciclomatico también aporta un indice del némero de casos de prueba necesarios (para alcanzar cobertura de decisién) be woten rodeos drlos qee sela~ dobl poise, Se bene C00 & se tle :Ill - Técnicas estaticas 03 - Andlisis estatico con herramientas > rtm etch iinv8.589 ES Diaz Hiterschelet Resumen - Andlisis estatico - Con el uso de herramientas para la realzacién de aniilsis estatico (compiladores, analizadores) el cédigo de! programa puede ser objeto de inspeccién sin ser ejecutado - Conel-uso de herramientas se puede realizar el andlisis estético de un programa con menor esfuerzo que el necesario para una inspeccién - Resultado del andlisis - Ediagrama de flujo de control presenta el flujo del programa y permite la deteccién de “ramas muertas" y cédigo inalcanzable ~ Las anomatias en los datos se detectan utiizando el andlisis del flujo de datos = Las métricas pueden ser utiizadas para evalvar la complejidad estructural conduciendo a una estimacién del esfuerzo esperado en pruebas 2 Garant vnnhmereaiany cnn fr nam rogaaiaists 7 bmp: ledoves csbebice Ze A cleeaderes \dercenveches oe erat? | xo _ ae Lt : smoelgar be, Aapiery Clgo Anolis Eleye we? ae >> Ti peaink de contrat cu alse al v Dall a, nate | belo Grek Jobin ee deGrctos RLerncede = Godign mete = Bedesnfintes |erat aang EE == IV - Técnicas de disefio de pruebas Diaz Hilterscheid Contenido Capitulo IV - Técnicas de disefio de pruebas - IV/01 Proceso de desarrollo de prueba 1V/02 Categorias de las técnicas de disefio de prueba = 1/03 Técnicas basadas en la especificacién o de caja negra - 1V/04 Técnicas basadas en la estructura o de caja blanca - 1V/05 Técnicas basadas en la experiencia 1V/06 Seleccién de las técnicas de prueba i co es Oa »sitiar= = IV - Técnicas de disefio de pruebas Contenido Diaz Hitescheid Capitulo IV - Técnicas de disefio de pruebas ~ 1V/02 Categorias de las fécnicas de - IV/03 Técnicas basadas en a especificacién o de caja negra ~ IV/04 Técnicas basadas en la estructura o de caja blanca - IV/05 Técnicas basadas en.la experiencia - IV/06 Seleccién de las técnicas de prueba expen nin it ene gna 8IV - Técnicas de disefio de pruebas _Proceso de desanolio de prueba Obtencién de casos de prueba a partir de requisitos El disefio de casos de prueba debe ser un proceso controlado Los casos de prueba pueden ser creados formal o informalmente, dependiendo de las caracteristicas del proyecto y la madurez del proceso en uso escenario de pruebas : IV - Técnicas de disefio de pruebas partitesched 01 - Proceso de desarrollo de prueba Raa Cra iain oe Vai Trazabilidad Las pruebas deben ser trazables: Qué casos de prueba han sido incluidos en el catélogo de pruebas, basados en qué requisitos? Las consecuencias de los cambios en los requisitos sobre las pruebas a realizar pueden ser identificadas directamente La trazabilidad - ayuda a determinar la cobertura de requisitos, - permite establecer la calidad de los casos de prueba en base a = trazas claras respecto de requisitos = resultados esperados i casa oaiavenanduatcesa aieIV - Técnicas de disefio de pruebas 01 - Proceso de desarrollo de prueba faz Hiescheid Definiciones - Objeto de prueba (“test object”): Elemento a ser revisado: un docuriento 0 una pieza de software en el proceso de desarrollo de software - Condicién de prueba (“test condition"): Elemento 0 evento de un componente 0 sistema que deberia ser verificado por uno o mas casos de prueba - Criterios de prueba (“test criteria”): El objeto de prueba debe cumplir los criterios de prueba con el objeto de superar la prueba - Calendario de ejecucién de prueba (“test execution schedule") Un esquema para Ia ejecucién de procedimientos de prueba. Los procedimientos de prueba estan incluidos en el calendario de ejecucién de prueba en sus contextos y en el orden en el cual deben ser ejecutados sition in es ea oy = IV - Técnicas de disefio de pruebas cmniuenes 01 Proceso de desarrollo de prueba Definiciones ; teh - Espectficacién de disefio de prueba 9 “et Documento que especifica las condiciones de prueba (elementos de cobertura)_ para el elemento de prueba, el enfogue de prucbas de forma detaliada eidentficales coro os de prueba de alto nivel asociados. [SegUn IEEE 829) es 6 & ee? - Especificacién de casos de prueba 39° 54°77, sey Documento que especifica un conjunto de casos de fare (objetivos, entradas, acciones de prueba, resultados esperados y precondiciones dé ejecucién) para un elemento de prueba: [SegUn IEEE 829] a ES ce iin ch agitite (emensaee IV - Técnicas de disefio de pruebas 01 - Proceso de desarrollo de prueba ae Hitescheid Descripcién de un caso de prueba segtn el estandar IEEE 2 - Precondiciones (“preconditions”): situacién previa a la ejecucion de pruebas 9 caracteristicas de un objeto de pruebas antes de llevar ala practica (ejecucién) un caso de prueba = Valores de entrada (“input values”): descripcién de los datos de entrada de un objeto de pruebas = Resultados esperados (“expected results"): datos de salida que se espera que produzca un objeto de pruebas = Poscondiciones (“post conditions”): caracteristicas de un objeto de prueba tras la ejecucién de pruebas, descripcién de su situacién tras la ejecucién de las pruebas - Dependencias (“dependencies”): orden de ejecucién de casos de prueba, razon de las dependencias = Identificador distinguible (“distinct identification”): Identificador o cédigo con el objeto de vincular, por ejemplo, un informe de errores al caso de prueba en el cual ha sido detectado - Requisitos (“requirements”): coracteristicas del objeto de pruebas que el caso de prueba debe evaluar 7 {oo oa vnepbmenrberans or wren IV - Técnicas de disefio de pruebas 01 - Proceso de desarrollo de prueba rs aansanal Diaz Hikerscheid ascent eae Combinacién de casos de prueba Los casos de prueba se pueden combinar en juegos de pruebas (“test suites") y escenarios de pruebas Una especificacién de procedimiento de prueba: define la secuencia de acciones para la ejecucién de Un caso de prueba individual o un juego de pruebas. és un script (guién) 0 “guién cinematografico” para la prueba describiendo los pasos, fratamienfo y/o actividades necesarias para la ejecucién de la prueba Los juegos de prueba pueden ser codificados y ejecutados de forma aufomaiica Con ei uso de herramienfas apropiadas El plan de prueba (dindmico) establece Ia secuencia de las pruebas pianificadas, quien debe realizarlas y cuando. Se deben Considerar las restricciones como las prioridades, la disponibilidad de recursos, Ia infraestructura de prueba, etc. El calendario de ejecucién de prueba define el orden de la ‘ejecucion de los procedimientos de prueba y automatizacién fe scripts de prueba utilizando para la asignacién de prioridad, pruebas de regresion, etc. ried= IV - Técnicas de disefio de pruebas 01 - Proceso de desarrollo de prueba Diaz Hiterscheid Resumen - Los casos de prueba y los juegos de pruebas (“test suites") son obtenidos a partir de los requisitos o caracteristicas de los objetos de pruebas - Componentes de la descripcién de un caso de prueba: "- Cédigo/Identificador = Valores de entrada ("input values") = Precondiciones ("pre-condifions") - Resultados esperados (“expected results") = Poscondiciones ("post-conditions") - Dependencias ("dependencies") Requisitos a partir de los cuales se ha obtenido el caso de prueba Arde, i 2 a a a a oo oe ee le le lo leIV - Técnicas de disefio de pruebas Contenido aco scrmaie seoncemtiovea > ee far Mikerscheid Capitulo IV - Técnicas de disefio de pruebas IV/01 Proceso de desarrollo de prueba WO EaleGorias de las Técnicas de dkehio de pweba 1V/03 Técnicas basadas en la especificacion o de caja negra 1V/04 Técnicos basadas en la estructura o de caja blanca 1V/05 Técnicas basadas en la experiencia IV/06 Seleccién de las técnicas de prueba : be ahddasinchanbntaetometeeniomio) IV - Técnicas de disefio de pruebas 02 - Categorias de las técnicas de disefio de prueba a risen seid nat oe D> Tees ERE 5 Diaz Hiescheid snamsuemscectiain Pruebas de caja negra (“black box") y caja blanca (“white box") = Las pruebas dinémicas se dividen en dos categorias/grupos. & - La agrupacién se realiza en funcién del caracter basico del método utilizado para obtener los casos de prueba - Cada grupo tiene sus propios métodos para disefiar casos de prueba indica “Cobertura de rama “Cobentra de condicon “Cobertura de camino ‘Aseguramiento de a calidad anaitico “Revsiones /Rovisiones guiadas ‘ewanahroughs) “Andis el uo de conto nai el fulo de datos “Meas compladeranatzader estiticoreenter Ceteo- Wt D6E9 REE = IV - Técnicas de disefio de pruebas : 02 - Categorias de las técnicas de disefio de prueba Diaz Hiterscheid Técnica: caja negra ("black box") - El probador observa el objeto de prueba como una caja negra - La estructura intemna del objeto de prueba es irrelevante o x desconocida : - Los casos de prueba se obtienen a partir del andlisis de la especificacién {funcional y no funcional) de un componente o sistema - Prueba del comportamiento entrada / salida ("input / output”) : = _jLa funcionalidad es el foco de atencién! sea - La técnica de caja negra también se denomina prueba funcional o prueba orientada ala especificacién Zi objeto de proche 2 IV - Técnicas de disefio de pruebas 2 pmnieeneg 02- Categorias de las técnicas de disefio de prueba Técnicas basadas en la estructura o de caja blanca (“white box") ss - Elprobador conoce Ia estructura interna del programa / cédigo - Es decir, la jerarquia de los componentes, flujo de control, flujo de datos, etc. = Las casos de prueba son seleccionados en base a la estructura intema del programa / cédigo = Alo largo de las pruebas es posible que se interfiera con la ejecucién de otto tipo de prueba - jla.estructura del programa es el foco de atencién! = La técnica de caja blanca también es conocida como prueba la estructura 0 prueba basada en el flujo de controlpoco tae v5.9 (EEE —_ IV - Técnicas de disefio de pruebas partiitencheg 02 - Categorias de las técnicas de disefio de prueba _savaanemamsninaatan AEROS ie ei Categorias de las técnicas de disefio de pruebas - visién general - Métodos basados en Ia especificacién - Elobjeto de prueba ha sido seleccionado de acuerdo con el modelo funcional software - La cobertura de Ia especificacién puede ser medida (por ejemplo. el porcentoje de fa especificacién cubierta por casos de prueba) ee - Métodos basados en Ia estructura - Laestructura interna del objeto de prueba es utlizada para disefiar los casos de prueba (cédigo/sentencias, menbs, llamadas, etc.) - Elporcentoje de cobertura es medido y utiizado como fuente para la creacién de casos de prueba adicionales =. Métodos basados en la experiencia = Elconocimiento y experiencia respecto de los objetos de prueba y su entomo son las fuentes para el disenio de casos de prueba - Elconocimiento y experiencia respecto de posibles puntos débiles, i osibles errores y errores previos son Utiizados para determinar / Sc definir casos de prueba ‘oc bigest a ee 2 gina ~ aoc 8 Pee = IV - Técnicas de disefio de pruebas dactitenchsig 02 - Categorias de las técnicas de disefio de prueba rateieoseen roma ai asicinicrsronna csi Resumen - Los casos de prueba pueden ser disefiados utilizando diferentes métodos - Sila funcionalidad especificada es el objetivo de las pruebas, los métodos utilizados se denominan métodos basados en la especificacién o métodos de caja negra (“black box"). - Sila estructura interna de un objeto es investigada, los métodos utilizados se denominan métodos basados en la : estructura o métodos de caja blanca (“white box"). 7 - Los métodos basados en Ia experiencia utilizan el conocimiento y la habilidad del personal involucrado en el disefio de casos de prueba. ‘Si thet nino rcs ait regina a= IV - Técnicas de disefio de pruebas ee Diaz Hilterscheid Contenido ig stooped oa ite Capitulo IV - Técnicas de disefio de pruebas - 1V/01 Proceso de desarrollo de prueba - 1V/02 Categorias de las técnicas de disefio de prueba Ode caja near) caja blanca [PRP AWS Tericas Basadas en la especificacic ~ 1V/04 Técnicas basadas en la estructura « - IV/05 Técnicas basadas en la experiencia ~ 1V/06 Seleccién de las técnicas de prueba Se asa rnin onic vag 2IV - Técnicas de disefio de pruebas oichtenneig 03 - Técnicas basadas en la especificacion o de caja negra Visién general - Enel presente apartado se explicaran en detalle los siguientes métodos de caja negra: ~ Parlicién de equivalencia (segrhentacién de equivalencia) o clase de equivalencia ~ Andlisis de valores limite Tablas de decisién & gratices causa-) - Pruebas de transicién de estado - Pruebas de caso de uso - Lalista anterior da cuenta de los métodos més importantes y conocidos - Otros métodos de caja negra son: - Pruebas estacisticas - Pruebas duaies (algoritmo dual - "pairwise" = Pruebas de humo ik disease moc er 2 ee IV - Técnicas de disefio de pruebas oartitenches ,,03 - Técnicas basadas en la especificacién o de caja negra PR ARE te RA TEA ARE IS UTES TTS ne General - Las pruebas funcionales estan dirigidas a verificar la comeccién y la completitud de una funcién - _2£stan disponibles en el médulo todas las funciones especificadas? ~ elas funciones ejecutadas presentan resultados correctos? - la ejecucién de casos de prueba deberian ser ejecutades con una baja redundancia, pero sin embargo con cardcter integral / : completo : - Probar lo menos posible, pero - Probar tanto como sea necesario, sh ibs ldiaeinantenmm nb ces car ciz06IV - Técnicas de disefio de pruebas g 03 Técnicas basadas en Ia especificacin o de caja negra Particién de equivalencia o clase de equivalencia (CE) - Laparticién en clases de equivalencia es lo que la mayoria de los probadores hacen de forma intuitiva: dividen los posibles valores en clases, mediante lo cual observan = Valores de enfrada “input values") de un programa (uso habitval delmétodo Ce) ~ Valores de saga ("output values") de un programa (uso poco habitual del método CE) = Elrango de valores definido se agrupa en clases de equivalenciapara las cuales se aplican las siguientes reglas: - Todos los valores para los cuales se espera que el programa tenga un comportamiento comin se agrupan en una clase de equivalencia Ce) = Las clases de equivalencia ne pueden superponerse y no pueden presentar ningin salto (discontinuidad) = Las clases de equivalencia pueden consistir en un rango de valores (por ejemplo, 0100 (valores de entrada no validos) = - Se pueden definir CE adicionales, conteniendo, pero no limitadas a: ~ Entradas no numéricas - Nimeros muy grandes o muy pequefios - Formatos numéricos no admitidos ‘tahoe ennai ste em > er EES IV - Técnicas de disefio de pruebas : pastitencned ,03- Técnicas basadas en la especificacién o de caja negra scaareanor ar tla these cSiaibakeoee cer cist : . Particién de equivalencia: variables de entrada x - Todas las variables de entradas (“input variables ") del objeto de prueba son identificadas, por ejemplo, ~ Campos de una interfaz Grafica de Usuario ("GUI") - Parémetros de una funcién (por ejemplo, componente de prueba} - Se define un rango para cada valor de entrada ("input") - Este rango define la suma del todas las clases de equivalencia validas (CE,) - - Las clases de equivalencia no validas (CE,,) estén constituidas por : aquellos valores no pertenecientes al rango = Aquellos valores que deben ser tratados de una forma diferente (conocidos 0 sospechosos) son asignados a una clase de equivalencia aparteon =) IV - Técnicas de disefio de pruebas pir Hitercheig 03 - Técnicas basadas en Ia especificacién o de caja negra Particién de equivalencia - ejemplo - Un programa espera un valor porcentaje de acuerdo a los siguientes requisitos: - S6lo se admiten valores enteros ~ Opertenece al rango y es su limite inferior ~ 100 pertenece al rango y es su limite superior - Son vélidos todos lo nimeros del 0 al 100, son no valides todos los numeros negativos, los n’meros mayores que 100, todos los numeros decimales y todos los valores no numéricos (por ejemplo, “paco") - Una clase de equivalencia: Osxs 100 = Ira clase de equivalencia no valida: x <0 ~ 2da clase de equivalencia no valida: x> 100 = ra clase de equivalencia no valida: x= no entero - dla clase de equivalencia no valida: x= no numérico (n.n.} IV - Técnicas de disefio de pruebas 03 - Técnicas basadas en la especificacién o de caja negra sum D> Ve ee iar Hiterschaid Sone noes a Particién de equivalencia - ejemplo - Elporcentaje sera presentado en un diagrama de barra. Se Z aplicaran los siguientes requisitos adicionales (ambos valores incluidos: Valores entre 0 y 15: barra color gris Valores entre 16 y 50: barra color verde ue ~ Valores entre 51 y 85: barra color amarillo a = Valores entre 86 y 100: barra color rojo - Ahora hay cuatro clases de equivalencia vdlidas en lugar de una: Ira clase de equivalencia valida: OSx<15 - 2da clase de equivalencia vélida: 165 x50 2 = 1a clase de equivalencia valida: 51. escorts. 19 ‘SERS Diaz Hiterscheid Clase de equivalencia ~ seleccién de representantes - Enel Ultimo paso, se determina un representante de cada clase de equivalencia asi como el resultado esperado para cada uno de ellos EC; xno entero Og: x1non numérico vata nanometer eri ronan! metre eta i4 EE — IV - Técnicas de disefio de pruebas pocmtened 03 Técnicas basadas en la especificacién o de caja negra cians eee titanate rnlesaaerie aaa Ejercicio: Clases de equivalencia - Extraer de una especificacién [tienda on-line) - Todos los valores de entrada - Clases de equivalencia vélidas = Clases de equivalencia no validas hi eG ise, ga: IV - Técnicas de disefio de pruebas 03 - Técnicas basadas en Ia especificacién o de caja negra Diaz Hiterscheld Particién en clases de equivalencia - ejemplo 2/1 - Andlisis de Ia especificacién Parte del cédigo de un programa trata el precio final de un articulo en base o su precio de venta al public, un descuento en % y el precio del porte (6. 90 12 eut0s, dependiendo del ipo de porte) Suposiciones: = Elprecio de venta al pUblico de un ariiculo esta dado por un numero con dos decimales - Eldescuento es el valor porcentual sin decimales entre 0% y 100% El precio del porte puede ser 6,96 12 é > pote Cte Meee V2 RE IV - Técnicas de disefio de pruebas 03 - Técnicas basadas en Ia especificacién o de caja negra itseanieatecntemaseaanaiy 7: ize Hiterscheid Parficién en clases de equivalencia : ejemplo 2/2 , - Casos de prueba para CE validas ~ Las clases de equivalencia validas aportan las siguientes combinaciones 0 casos de prueba: 101, 102 y 103 Prec de poe Ey ver noice2 IV - Técnicas de dis@fio de pruebas Diaz Hitescheid Parficién en clases de equivalencia : ejemplo 2/3 = Los siguientes casos de prueba han sido generados utilizando CE no vélidas, cada una en combinacién con CE vélidas de otros elementos: cae ihoimsoenanmencii cons ema 03 - Técnicas basadas en la especificacién o de caja negra = IV - Técnicas de disefio de pruebas 03 - Técnicas basadas en la especificacién o de caja negra Stiionearcmincnessnataar ste Diaz Hitescheid Particién en clases de equivalencia: ejemplo 2/4 - Se obtienen 10 casos de prueba: 3 casos de prueba positivos {valores validos) y 7 casos de prueba negativos (valores no validos) razIV - Técnicas de disefio de pruebas 03 - Técnicas basadas en la especificacién o de caja negra a esc istabeanaaeiee az rscheid Particién de equivalencia: basado en Ia salida (“output based") = Las clases de equivalencia también pueden ser generadas a partir de los valores de salida esperados ~ El método ufilizado es anélogo al anterior, aplicado a los valores de salida ~ Lo variable (elemento) es enionces la salida (“output”) (por ejemplo, el valor de un campo en la "GUI") = Las clases de equivalencia son generadas para todos los posibles valores de la salida definidos = Se determina un representante para cada clase de equivalencia de los valores de salida ~ Entonces, el valor de entrada, que conduc al valor representante, es obtenido/identificado - Mayores costes y esfuerzo dado que los valores de entrada deben ser obtenidos para una salida determinada de forma recursive IV - Técnicas de disefio de pruebas 03 - Técnicas basadas en Ia especificacién o de caja negra Diaz Hittercheid Particién en clases de equivalencia - en general /1 - Particién ~ La calidad de fa prueba depende de la segmentacién precisa de voriables/elernentos en clases de equivalencia, = CE que no hubieran sido identificadas presentan el riesgo de posibles omisiones, dado que los representontes utiizados no cubren todas las posibilidades - Casos de prueba = Elmétodo de la clase de equivalencia aporta casos de prueba para los cuales ain debe ser seleccionado un representante - Las combinaciones de datos de prueba son seleccionados definiendo el o os representantes de cada clase de equivalencia_— - on | IV - Técnicas de disefio de pruebas 03 - Técnicas basadas en la especificacién o de caja negra Diaz hiterscheid 2 siiscennaetiaa Particién en clases de equivalencia - en general /2 - Seleccién de representantes - Todo valor perteneciente a la CE puede ser un representante de la misma. Los dptimos son = Valores caracteristicos (“typical valves) (tiizados con frecuencia) = Valores problemétices ("problem values") (sospechosos de product fallos) © Valores lite ("boundary valves") {en la frontera de la CE) fi - Los representantes de CE vélidas se pueden combinar ~ Los representantes de CE no vélidas no se pueden combinar - Representantes de una CE no vélida sdlo se puede combinar con otros representantes de CE validas - Para casos de prueba los representantes de CE invdlidos deben combinarse siempre con los mismos valores de otros CE validos {combinaciones esténdar) - Laseleccién de representantes implica que la funcién en el programa/sistema utiiza operaciones de comparacién Jenna aNRAcIaied “ i = IV - Técnicas de disefio de pruebas ae 03 - Técnicas basadas en la especificacién o de caja negra nosrmoemnnnibc tieriiaraakinnitabar airmen oat Particién en clases de equivalencia - en general /3 + = La cobertura de clases de equivalencia puede ser utilizada como criterio, de salida para finalizar las actividades del proceso de pruebas Ot beginirnaumertaenay hn un ers= oboe BEI BREE Ss SP IV - Técnicas de disefio de pruebas 03 - Técnicas basadas en la especificacién o de caja negra Diae Hitewcheid Particién en clases de equivalencia - Transicién - La transicién de una especificacién 0 definicién funcional en clases de equivalencia - Con frecuencio es una tarea dificil debido ala carencia de documentacién precisa y completa - Los limites no definidos o las descripciones faltantes hacen ificil la definicién de las clases de equivalencia - Con frecuencia, es necesario mantener contacto con el cliente con el objeto de completar la informacién eves Conte attire S060 EEE IV - Técnicas de disefio de pruebas 03 - Técnicas basadas en Ia especificacién o de caja negra Se ién en clases de equivalencia - Beneficios /1 - Beneficios ~ Méiodo sistematico para el disefto de casos de prueba. es decir, con una minima cantidad de casos de prueba se puede esperar un valor de cobertura especifico = La particién del rango del valores en clases de equivalencia a partir de las especificaciones cubre los requisitos funcionales - La.asignacién de prioridades a la clases de equivalencia puede ser utllizada para la asignacién de prioridades a los casos de prueba (los valores de entrada utiizacos con poca frecuencia deben ser los Uitimos en ser probados} = Las pruebas de las excepciones conocidas esté cubierta por los casos de prueba de acuerdo con las clases de equivalencia negativas - La particién de equivalencia es aplicable a todos las niveles de prueba—_ IV - Técnicas de disefio de pruebas custiteschea , 03 - Técnicas basadas en la especificacién o de caja negra icles st Partie n en clases de equivalencia - Beneficios /2 - Beneficios - Puede ser uilizada para lograr objetivos de cobertura de entradas y salidas ~ Puede ser utilizada para entradas manuales (humans) 0 via interfaces de un sistema 0 parametros de interfaces en pruebas de integracién ‘Se nag mea "i : 2 oC trie 86 2818 ee IV - Técnicas de disefio de pruebas dunitesreg _03- Técnicas basadas en la especificacién o de caja negra FTC UE REE SRN SERRE ENEMA 1S “ Andlisis de valores limite /1 ~ Elandlisis de voiores limite ampli la técnica de particién en Clases de equivalencia introduciendo una regla para seleccionar representantes = Los valores frontera (valores limite] de la clase de equivalencia deben ser probados de forma intensiva - aPorqué prestar més atencién a los limites? ~ Frecuentemente los limites del rango de valores no estén bien definidos o conducen a cistintas interpretaciones ~ Comprobar silos limites han sido implementados (programados) correctamente - Observacién importante - jla experiencia demvestra que, con mucha frecuencia, los errores fienen lugar en los limites del rango de valores! El andllisis de los valores limite puede ser aplicado en fodos los niveles de prueba. Es facil de aplicar y su capacidad de deteccién de defectos es alta en el caso de especificaciones Q detalladas Sia aie minmaiecing th sa cer regetIV - Técnicas de disefio de pruebas 03 - Técnicas basadas en Ia especificacién o de caja negra site = Andlisis de valores limite /2 = Elandlisis de valores limite asume que: = La clase de equivalencia esté compuesta de un rango continuo de valores (no por un valor individual o un corjunto de valores discretos) = Se pueden defini os limites para el rango de valores - Como extensién a la particién en clases de equivalencia el andlisis de-valores limite es un método que sugiere la seleccion de representantes ~ Particién en clases de equivatencia: = Evalda un valor tipico} de la clase de equivalencia ~ Analisis de valores limite: = Evaldalos valoces limite (rontera) y su entomo Se viiiza el siguiente esqvema incessant a 0 Se IV - Técnicas de disefio de pruebas 03 - Técnicas basadas en Ia especificacién o de caja negra spas aaa nacaseaais Definicién de valores limite ~ Elesquema bésico sélo puede ser aplicado cuando el range de " valores ha sido definido de conformidad con el mismo esquema. = Eneste caso no son necesarias pruebas adicionales para un valor en elinterior del rango de valores Si un CE esta definido como un Unico valor numérico, por ejemplo, x = 5, los valores correspondientes al entomo también serén utilizados = Los representantes (de la clase y su entorno) son: 4,5 y 6 ” ronsrestate NO8818 i IV - Técnicas de disefio de pruebas 03 - Técnicas basadas en a especificacién 0 de caja negra Andlisis de valores limite para CE no valida - Los valores limite para clases de equivalencia no validas tienen poce sentido - Los representantes de una CE no vélida en la frontera de una CE Vélida ya se encuentran cubiertas a través del esquema basico - Para rangos de valores definidos como un conjunto de valores, en general, no es posible definir los valores limite - Por ejemplo: Soltero, casado, divorciado, viudo {ied umnbinb stand cers z eat : IV - Técnicas de disefio de pruebas Dactitescrea , 03 - Técnicas basadas en la especificacién o de caja negra _sShoecpuanennetited Uiuaieamamiaeal aeeabicae cio asda Andlisis de valores limite ejemplo 3a - Ejemplo 3a: = Rango de valores para un descuento en %: 0.00 = x < 100.00 = Defini 3 clases: + 1.CEx<0.00 = 2.080.005 100,00 + 3.Cé:x> 100.00 ~ Andlisis de valores limite Exfiende los representantes o: 2.CE: -0,01; 0,00; 0,01; 99,99; 100,00; 100,01 - Nota importants - En lugar de un representante para la CE valida, ahora hay seis, representanies (cuatro valides y dos no validos) aah cer taeiaty : sahIV - Técnicas de disefio de pruebas acién o de caja negra > tno ets inbir 1265810 EE 03 - Técnicas basadas en la especi wees sees Hiterscheid Andlisis de valores limite ejemplo 3b = Esquema bésico: seleccionar tres valores con el objeto de ser probados - el valor limite exacto y dos valores pertenecientes al entomno [dentro y fuera de la CE} - Punto de vista alternativo: dado que el valor limite pertenece a la CE, s6lo son necesarios dos valores para las pruebas, uno perteneciente al CE y otro no perteneciente al CE - Ejemplo 3b: - Rango de valores para un descuento en %: 0,00 s x s 100,00 - CE valido: 0,00 sx < 100,00 ~ Andlisis de valores limite Los representantes adicionales son: -0.01:; 0,00: 100, 0,01 - mismo compertamiento que 0,00 99.99 - mismo comportamiento que 100,00 - Un error de programacién causado por un operador de comparacién erréneo sera detectado con los dos valores limite (frontera) 100,01 IV - Técnicas de disefio de pruebas 03 - Técnicas basadas en la especificacién o de caja negra iia cit te i aR Diaz ilterscheid Pruebas de tabla de decisién (“decision table testing ")/1 = La particién en clases de equivalencia y el andiisis de valores limite tratan entradas en condiciones aisladas = Sin embargo, una condicién de entrada puede tener efectos sélo en combinacién con otras condiciones de entrada = Todos los métodos descritos previamente no tienen en cuenta el efecto de dependencias y combinaciones = Eluso del conjunto completo de las combinaciones de todas las Clases de equivalencia de entrada conduce, normaimente, a un numero muy alto de casos de prueba (explosi6n de casos de prueba) - Con la ayuda del gréfico causa-efecto ("cause-effect graph") y tablas de decisién obtenidas a partir de aquellos, la cantidad de combinaciones posibles se puede reducir de forma sistemética aun subconjunto de las mismas Deine imate eto reais> rect 88 TS IV - Técnicas de disefio de pruebas pertitenches 03 - Técnicas basadas en la especificacién o de caja negra TERS SN Pe LNCS ER 4 Pruebas de tabla de decision (“decision table testing ")/2 ~ Hlgrdiico causa-electo Ceause- effect araph’) utiliza un lenguaje formal - El gréfico causa-efecto ("cause-effect graph") se genera iraduciendo la especificacién (normalmente informal) de un objeto de prueba a un lenguaije formal ~ lobjeta de prueba esté sometido a una determinada cantidad de efectos que se remontan a sus respectivas causas ~ Elementos 8 operadores légicos: = Aseveracién ("Assertion") {Si causa A - entonces efecto €) ~ Negacién ("Negation") [Si causa A - entonces no efecto E) ®—®e e—e - over = (Sicausa A 0 B- entonces efecto &) @ = ¥ ("and") = [Sicausa Ay 8 - entonces efecto E} ‘tbe oie ss = IV - Técnicas de disefio de pruebas pmniteereg 03 Técnicas basadas en Ia especificacién o de caja negra Ganon emia aia oeeena nine awit Pruebas de tabla de decisin (“decision table testing ")/3 - Otros elementos del grdfico causa-efecto (“cause-effect graph’): = Exclusivo ("exclusive") (0 causa A 0 causa 8) _—e ~e inclusive") (Por lo menos una de las dos caUsos: A o 8) <® < “8 = Uno y sélo uno (Una y exactamente una de las dos causas: A or B) Ex = Inclusive om ~e = Requerido ("required") (Si causa A entonces también causa B) ,® ~® RC (esearch natant cise ‘eens |)ee Ceticode- Minti ¥1105.6510 a IV - Técnicas de disefio de pruebas 03 - Técnicas basadas en la especificacién o de caja negra Pruebas de tabla de decisién (“decision table testing ")/4 Ejemplo 5: Banca Online (“Online-Banking ~ Elusvario se identifica a través de su numero de cuenta y PIN. Si tuviera suficiente cobertura podré realizar una transferencia. Para poder realizar la transferencia debe introducir los datos del receptor yun TAN vélido. Cobertura @ Realizar transferencia Receptor correcto =>@ TAN identificado como ulizado Za Ng Denegarransterencia TAN valido © Solicitar TAN nuevamente einen a ah vate IV - Técnicas de disefio de pruebas 03 - Técnicas basadas en Ia especificacién o de caja negra ines Pruebas de tabla de decisién (“decision table testing ")/5 - Ejemplo 5: Banca Online (“Online-Banking") me epoca] ee CaS] el NO P| NO aarmaemey no [ST] © WD si ene HN NO - Cada columna de la tabla representa un caso de prueba - Construccién de Ia tabla de decisién: Seleccionar un efecto - Retroceder en el diagrama para identificar la causa. - Cada combinacién de causas esté representada por una columna én la tabla de decision (un caso de prueba) - Combinaciones de causas idénticas, conducentes a efectos distintos, se pueden fusionar para formar un Gnico caso de pruebaetree inte 4 (RR IV - Técnicas de disefio de pruebas faz Hiterscheid Pruebas de tabla de decisi6n (“decision table testing ")/6 - Uso préctico - Laespecificacién esta dividida en partes faciles de gestionar, por lo tanto conduce a una tabla de decisién con un tamario préctico - Es dificil deducir valores limite a partir del grafico causa-efecto (‘cause-effect graph’) o de la tabla de decision = Esrecomendable combinar casos de prueba obtenidos a partir de tablas de decision con valores obtenidos a partir de un andlisis de valores limite = Elnémero de causas y efectos analizados determinarén la complejidad del grafico causa-efecto ("cause-effect grap! para n precondiciones cuyos posibles valores puedan ser verdadero 0 falso, se pueden generar 2" casos de prueba - Para sistemas de gran tamafio este método sdlo es controlable con el apoyo de herramientas ari nameehce ombn et = IV - Técnicas de disefio de pruebas paantercred 03 - Técnicas basadas en Ia especificacién o de caja negra “noc yao smndimanislicciaaiee escent: Aa Pruebas de tabla de decisién (“decision table testing ") /7 - Beneficios - Identificacién sistemética de combinaciones de entradas {combinaciones de causas) que no podrian ser identificadas utilizando otros métodos - Los casos de prueba son faciles de obtener a partir de la tabla de decision ~ Facilidad de determinar una cobertura suficiente de casos de prueba, por ejemplo, por lo menos un caso de prueba por cada columna de Ia tabla de decision = Elnémero de casos de prueba se puede reducir por la fusién sistematica de columnas de la tabla de decisién - Desventajas = Elestablecimiento de un gran numero de causas conduce a resultados complejos y extensos = Porlo tanto, se puede incurrir en muchos errores en Ia aplicacién de este método - Esto hace necesario el uso de una herramienta 03 - Técnicas basadas en la especificacién o de caja negra vesIV - Técnicas de disefio de pruebas itewneg 03 Técnicas basadas en la especificacién o de caja negra Pruebas de transicion de estado /1 - Muchos métodos sélo tienen en cuenta el comportamiento del sistema en términos de datos de entrada (“input data") y datos de salida (“output data”) - Nose tiene en cuenta los diferentes estados que pueda tomar el objeto de prueba - Por ejemplo, el resultado de acciones que hubieran ocurrido en el pasado - acciones que hubieran causado que el objeto de prueba adquiera un determinado estado intemo - Los distintos estados que puede tomar un objeto de prueba se modelan a través de diagramas de transicién de estado - Elandlisis de la transicién de estado s¢ utiliza para definir casos de prueba basados en Ia transicién de estact - Los pruebas de transicién de estado con frecuencia se ufilizan en la industria del software embebido y automatizacién técnica en general > et Cueado-ttiieV306.818 MES IV - Técnicas de disefio de pruebas 03 - Técnicas basadas en la especificacién o de caja negra amid. 4) eat" amet ede Diaz Hitescheid Pruebas de transicién de estado /2 - Pata determinar los casos de prueba utilizando un diagrama de transicién de estado se construye Un érbol de transicién ~ Elestado inicial es la raiz del &rbo - Para cada estado que pueda ser alcanzado desde el estado inicial se crea un nodo que esta conectado la raiz por una rama - Esta operacién se repite y finaliza cuando: = Elestodo del nodo es un estado final (une hoja det érbo) ° = Elmismo nodo con el mismo estado yaes parte del érbol “eta ceca eae aig rns ib en ome ronaesemer IV - Técnicas de disefio de pruebas 03 - Técnicas basadas en Ia especificacién o de caja negra Sobek nents epee ANE Pruebas de transicién de estado /2 - Cada camino desde la raiz una hoja entonces representa un caso de prueba de prueba de transicién de estado - El Grbol de transicién de estado para este ejemplo conduce a los siguientes seis casos de prueba no nacido eatado_| muerte muerte po nacido cdo (SEE rmvero. i ‘oltero viudo casaso | ‘oer muerte . ‘oka vorclado ecards IV - Técnicas de disefio de pruebas 03 - Técnicas basadas en Ia especificacién o de caja negra Diaz Hiterscheid * RAS ncibink 2 iba once (Agi RAT Arbol de transicién de estado El Grol de transicict de estado de nuestro ejemplo utilizando ‘ transiciones invalidas.. (casos de prueba negativos, prueba de robustez) - Ejemplo: dos a transiciones invélid posibles - hay mas: - Las transiciones imposibles entre estados no se pueden probar= ee MESS IV - Técnicas de disefio de pruebas 03 - Técnicas basadas en la especificacién o de caja negra rscheid Pruebas de transicién de estado - Resumen Criterios de salida de prueba ~ Todo estado ha sido alcanzado, por lo menos, una vez - Toda transicién ha sido ejecutada, por lo menos, una vez - Beneficios y desventajas de este método = Buen método de prueba para objetos de prueba que pueden ser descrito como méquinas de estado = Buen método de prueba para probar clases, sélo si el ciclo de vida del objeto esté disponible = Con mucha frecuencia, los estados son més bien complejos, es decir, hacen falta una gran cantidad de parametros para describir el estado. ~ En es05 casos el disefio de casos de prueba y el andlss de los resultados, puede ser cific y requerir mucho tiempo - Sélo cubriendo todos los estados no se garantiza una cobertura completa de prueba sii 208) IV - Técnicas de disefio de pruebas 03 - Técnicas basadas en la especificacién o de caja negra ee Diaz Hiterscheid eae psn ooo Salata sabe sh Pruebas basadas en casos de uso /1 = Los casos de prueba se obtienen directamente a partir de los casos de Uso del objeto de prueba = Elobjeto de prueba es visto como un sistema reaccionando con actores = Un caso de uso describe Ia interaccién de todos los actores involuerados conduciendo a un resultado final por parte del sistema = Todo caso de uso tiene precondiclones que deben se cumplidas con el objeto de ejecutar el caso de Us0 [caso de prueba) de forma satistactoria = Todo coso de uso tiene poscondiciones que describen el sistema tras la ejecucién del caso de us0 [caso de prueba) = Los casos de uso son elementos del Lenguaje Unificado de Modelado (“Unified Modeling Language" - UML") : = Eidiagrama de casos de uso es uno de los 13 diferentes tipos de diagramas ‘ vtilzado por UML = Un diograma de casos de uso describe un comportomiento, no describe una secuencia de eventos H Un diagrama de casos de uso muesta la reaccién del sistema desde el punto de vista del usuario “UML es un lenguaje de especificacién ne propietario para el modelado de objetos oi iiIV - Técnicas de disefio de pruebas 03 - Técnicas basadas en Ia especificacién o de caja negra lazHiterschel Pruebas basadas en casos de uso /2 - Ejemplo de un diagrama de caso de uso sencillo (fuente: Wikipedia), = Eldiagrama de Ia izquierda describe la funcionalidad de un Sistema "Restaurant" sencilo Los casos de uso estin representados pot. évalosy los actores estén representados = == por figuras de palo : Elactor "Patron" puede comer comida | ("Eat Food"), pagar por la comida ("Pay for Food"}o beber vino ("Drink Wine") El actor cocinero ("Chef") slo puede preparar comida. Observar que los actores “Patron y "Cashier" estén involucrados en el caso de uso “Pay for Food" (pagar poria’ comida) La caja define los limites del sistema "Restaurant", es decir, los casos de uso representados son parte del sistema a modelar y no los actores ‘taealiincinatbinamnaiiag nine iemit 2 VE ee IV - Técnicas de disefio de pruebas carritestreé _.03~ Técnicas basadas en la especificacién o de caja negra ORS a 5 RN OS ORR RR RRS ATOR St Pruebas basadas en casos de uso /3 - Cada caso de uso describe una cierta tarea (interaccién usuario-sistema) - La descripcién de un caso de uso incluye, pero no estd limitado a - Precondiciones - Resultados esperados / comportamiento del sistema = Poscondiciones - Estos elementos descriptivos también son los casos de prueba correspondientes - Cada caso de uso puede se utilizado como la fuente para un caso de prueba = Cada altenativa en el diagrama corresponde a un caso de prueba separado - Normalmente la informacién aportada por un caso de uso no fiene suficiente detalle para definir casos de prueba de forma directa, Son necesarios datos adicionales (datos de entrada, resultados esperados) para construir/desarrollar un caso de prueba st ados para definir ici ees astaIV - Técnicas de disefio de pruebas 03 - Técnicas basadas en la especificacién o de caja negra pee paces Diaz Miter Pruebas basadas en casos de uso - Resumen - Beneficios - Pruebas apropiadas para pruebas de aceptacién y pruebas de sistema, dado que cada caso de uso describe un escenario de usuario a probar - Util para disefiar pruebas de aceptacién con Ia participacién del cliente/usuario = Pruebas apropiadas si las especificaciones del sistema se encuentran aisponibles en UML - Puede ser combinada con otras técnicas de prueba basadas en la especificacién - Desventajas = Nula obtencién de casos de pruena adicionales més allé de la informacién aportada por el caso de uso - Porlo tanto este método deberia ser utiizado s6lo en combinacién con otros métodos de diserio sistematico de casos de prueba => IV - Técnicas de disefio de pruebas 03 - Técnicas basadas en la especificacién 0 de caja negra sfrinniraegatr ott or mornin Diaz Hiterscheid Técnicas de caja negra (“black box") - Conclusiones : generales /1 - El objetivo principal de las pruebas de caja negra (black box) es probar a funcionalidad del sistema = Por lo tanto el resullado de las pruebas depende de la calidad de la especificacién del sistema (por ejemplo, la complefitud, especificaciones faltantes 0 erréneas conducen a maios casos de prueba} = Silas especificaciones son eréneas, también serdn enéneosloscasosde prueba, La: pruebas se ejecutan/desarrollan solamente para is funciones Geseritas. Una especiicacisn fatlante de una funcionalidad requerida no Sera detectada durante los pruebas - Siel objeto de prueba posee funciones que no han sido especificadas, éstas no seran evaluadas: ~ Tales funciones superfiuas pueden causar problemas en las dreas de Ic estabilidad y seguridad (por ejemplo, software para un cojero ‘utomético) iIV - Técnicas de disefio de pruebas pashitescheig 03 - Técnicas basadas en la especificacién o de caja negra S Scie huartte ¢ * ead Técnicas de caja negra (“black box") - Conclusiones 5 generales /2 - Apesar de estas desventajas, las pruebas funcionales consti{uyen Ia actividad de pruebas més importante ~ Los métodos de caja negra (black box) son utlizados siempre en el proceso de pruebas ~ Las desventajas pueden ser compensadas con el uso de métodos adicionales de disefio de casos de prueba. por ejemplo, pruebas de caja blanca o pruebas basadas en la experiencia’ a cecomaiaeneme ve > Diaz Hiterscheid aemnaroaea ile anise iraR aR ened Técnicas de caja negra ("black box") - Resumen - Métodos de caja negra ("black box") Particién equivalente (segmentacién de equivalencia} 0 clase de equivaiencia - Anélisis de valores limite : - Gréficos causa-efecto & Tablas de decisién - Pruebas de transicién de estado - Pruebas de caso de uso - Las pruebas de caja negra [black box) verifican funciones ees especificadas: si las funciones no son especificadas, éstas no son probadas. - El cédigo adicional (es decir cédigo que no deberia estar) no puede ser detectado utiizando pruebas de caja negra [black box}. ‘ccna a i: esoce Catenee-Nittancs 6.6510 Pe ae —2 IV - Técnicas de disefio de pruebas Contenido Diag Hlterscheid Haast anes hla Siiibem misan se rian eae Capitulo IV - Técnicas de disefio de pruebas - IV/01 Proceso de desarrollo de prueba - 1V/02 Categorias de las técnicas de disefio de prueba ie -_1V/03 Técnicas basados en la especificacién o de cojanegra = IV/05 Técnicas basadas en la experiencia - IV/06 Seleccién de las técnicas de prueba hina sai TIV - Técnicas de disefio de pruebas 04 - Técnicas basadas en Ia estructura o de caja blanca Técnicas basadas en Ia estructura o de caja blanca (“white box") /1 = Enel presente apartado se explicardn en detalle las siguientes técnicas de caja blanca "white box"): - Pruebas de sentencia y cobertura ("statement testing and coverage’) - Pruebas de decisién y cobertura ("decision testing and coverage") - Pruebas de condicién y cobertura (“condition testing and coverage") = Pruebas de coberiura de camino y ("path testing coverage") - Observacién: Estas técnicas representan las técnicas de pruebas dinémicas més importantes y utiizadas de forma mds frecuente, Estas técnicas estan relacionadas con las técnicas de andiisis estatico descritas anteriormente = Otras técnicas de caja blanca son las siguientes (no limitada ala enumeracién): = SLYSC ("LCSAJ - Linear Code Sequence And Jump): Secuencia Lineal y Salto de Cédigo + Técnicas basadas en el flujo de datos seb agmiitimestmeeanane on ur ems) > Te ES 2 IV - Técnicas de disefio de pruebas 04 - Técnicas basadas en Ia estructura o de caja blanca Diaz Hitescheid sth seme toto esas es Su Técnicas basadas en la estructura o de caja blanca (“white box") /2 ~ Esté basada en la estructura identificada del software o del sistema = Nivel de componente: [a estructura de un componente software, es decir sentencias, decisiones, ramas, distintos caminos = Nivel de integracién: Ia estructura puede ser un arbol de llamada (un diagrama en el cual unos médulos llaman a otros médulos) ~ Nivel de sistema: [a estructura puede ser una estructura de un mend, un proceso de negocio o Ia estructura de una pagina web = Tres técnicas de disefio de pruebas estructurales relacionadas al cédigo para cobertura del cédigo basadas en sentencias, ramas y decisiones ‘a epeauelonamiomini tntIV - Técnicas de disefio de pruebas 04 - Técnicas basadas en Ia estructura o de caja blanca * aon: Diaz Hiterscheid Técnicas de caja blanca (“white box") - herramientas /1 - Durante las pruebas de caja blanca, el programa objeto de las pruebas es ejecutado de la misma forma que las pruebas de Caja negra. Ambas categorias (caja bianca y caja negra) Conforman las pruebas dindmicas = La feoria establece que todas las partes de un programa deberian ser ejecutadas por lo menos una vez durante las pruebas - El grado de cobertura de un programa se mide con el uso de hetramientas [por ejemplo, analizadores de cobertura) - Lainstrumentacién del cédigo se lleva a cabo con el objeto de contar la ejecucion de caminos, es decir se insertan contadores en ‘el cédigo del programa det obicto de prueba - Estos contadores son inicializados a cero, cada ejecucién del camino especifico incrementaré el contador correspondiente - Los contadores que mantienen el valor cero tras las pruebas indican las partes del programa que atin no han sido ejecutadas Aa vel: IV - Técnicas de disefio de pruebas - 04 - Técnicas basadas en Ia estructura o de caja blanca “aon reliling te iar Hiterscheid ease Técnicas de caja blanca (“white box") - herramientas /2 - Las técnicas de caja blanca requieren el apoyo de herramientas 4 en muchas Greas, a saber: Especificacién de caso de prueba = Generacién automética del diagrame del fujo de control a patti de! cédigo fuente del programa - Bjecucién de la prueba = Herramientas para monitorzar y controlar el fujo de! programa dentro del objeto de prueba - Elsoporte de herramientas asegura Ia calidad de las pruebas e incrementa su eficiencia - Dada la complejidad de las mediciones necesarias para las pruebas de caja blanca, la ejecucién manual de pruebas implica = Consumo de tiempo, consumo de recursos : = Dificuliad en la implementacién y propensién a exrores ogc?neccemetetocvscse SRR IV - Técnicas de disefio de pruebas ojaehiterched 04 - Técnicas basadas en Ia estructura o de caja blanca Principales tipos de cobertura - Cobertura de sentencia ("statement coverage") - Porcentaje de sentencias ejecutables que han sido practicadas por los casos de prueba - También puede ser aplicado a médulos, clases, elementos de un meno, et€. - Cobertura de decisién (= cobertura de rama} (“decision Coverage = branch coverage") Porcentaje de resultados de decisin que han sido practicados por los casos de prueba - Cobertura de camino (“path coverage") - Porcentaje de caminos de ejecucién que han sido practicados por casos de prueba i - Cobertura de condicién ("condition coverage") = Porcentaje de todos los resultados individuales de condicién que afectan de forma independiente al resultado de una decisién que ha sido practicada por casos de prueba - La cobertura de condici6n se presenta en distintos grados, por ejemplo, cobertura de condicién simple, cobertura de condicién multiple y coberiura de condicion muttiple minima ‘i nemesis te ein IV - Técnicas de disefio de pruebas cavmtesnea 04 Técnicas basadas en la estructura o de caja blanca spentrscortnrats icles Hibintersuntmecra moot Cobertura de sentencia ("Statement coverage") El foco de la atencién es la sentencia del cédigo de un programa = 2Qué casos de prueba son necesarios con el objeto de ejecutar todas (o un porcentaje determinado) las sentencias del céaigo existentes? - La base de este anélsis es el grdfico (0 diagrama) de flujo de control ("control flow graph") = Todas las instrucciones estén representadas por nodos y el flujo de control entre instrucciones esta representado por una arista (flecha} eet - Las instrucciones multiples se combinan en un nodo independiente si solamente pueden ser ejecutados en una secuencia particular ; El objetivo de la prueba (criterio de salida) es lograrla cobertura de un porcentaje especifico de todas las sentencias, denominado cobertura de sentencia. (Co cobertura de cédigo - “code coverage") |Cobertura de sentencia (Co) = Numero de sentencias ejeculadas «ooo, i I : ‘Nimero total de sentencias 5 ‘bi bahediit oneal em ein sii) ewadeCenteoes-svetonco 166.8810 es IV - Técnicas de disefio de pruebas 04 - Técnicas basadas en Ia estructura o de caja blanca wi faz Hiterscheid Cobertura de sentencia ("Statement 5 coverage") - Ejemplo 1/1 - Ejemplo 1v/02-1. - Se evalua el siguiente segmento de cédigo de un programa, que esta representado por el diagrama del flujo de control (imagen a la derecho} > Ot fi: => IV - Técnicas de disefio de pruebas oartiteneig 04 - Técnicas basadas en la estructura o de caja blanca murmamnceneer-é Serena. nti ti deat oi Cobertura de sentencia (“Statement coverage") - Ejemplo 1/2 - Considerar el programa representado por el grafico (0 diagrama) de flujo de control (imagen a Ia derecha} Contiene dos sentencias “if” y un bucle "do-while” dentro de Ia segunda sentencia - Hay tres “caminos" diferentes a través del segmento de programa. - La primera sentencia “if* permite dos direcciones. - La direccién de la derecha de la primera sentencia "if" se divide nuevamente a partir de una segunda sentencia “if - Todas las sentencias de este programa pueden ser alcanzadas haciendo uso de este camino a la derecha. - Un solo caso de prueba seré suficiente para alcanzar el 100% de cobertura de sentencia.—_, IV - Técnicas de disefio de pruebas omnnenenig .04- Técnicas basadas en Ia estructura o de caja blanca Pine nn ao Cobertura de sentencia ("Statement coverage") - Ejemplo 2 ~ Ejemplo 1V/02-2 - Eneste ejemplo el grafico (" ligeramente més complejo: ~ Elprograma contiene las sentencias (dentro de una sentencia “if") - Cuatro caminos diferentes conducen a través de este segmento de programa - La primera sentencia "if" permite dos direcciones - En cada rama de la sentencia "it" otra sentencia “if" permite nuevamente dos direcciones diferentes - Para una cobertura de sentencia del 100% hacen falta cuatro casos de prueba fiagrama") es yunbucle sareunssscaunementengcrtlminsy reales IV - Técnicas de disefio de pruebas 04 - Técnicas basadas en Ia estructura o de caja blanca CARE Tee A NR SR SES AS Sa Ierscheid Cobertura de sentencia (“Statement coverage") - Conclusiones generales - La medicién de la cobertura se realiza con el uso de herramientas diseiadas de forma especifica - Estas herramientas se denominan Herramientas de Andisis de Cobertura ("Coverage Analysis Tools ") o Analizadores de Cobertura (Coverage Analyzers") - Beneficios/desventajas de este método = Seré detectado el cédigo muerto, es decir, cédigo constitvide por sentencias que nunca se ejecutan = Sihay cédigo muerto en el programa, no se podrdé lograr una cobertura del 100% ; = No podran ser detectadas insirucciones faltantes, es decir, cédigo : ‘que es necesario con el objeto de cumplir con Ia especificacién ~ Los pruebas se desarolion solamente respecto de sentencias ejecutadas: Hlodo el cécigo puede ser alconzado/elecutado? = Elcédigo fallonte no puede ser detectado utiizando técricas de cojo lanes (ands de cobertra) og rei neice tsi aaa* También denominadas cobertura de rama (branch cove : Sache hoa nh ee ogi Hiterscheia Cobertura de decision (“decision coverage’ 2 reo Condes Boo VISE E10 Ps as nerscheid oneness ieee va eR Cobertura de decisién (“decision coverag: eon Cemicoso-Nvet86ie9 1.106. 6510 Ps Ee ee IV - Técnicas de disefio de pruebas 04 - Técnicas basadas en Ia estructura o de caja blanca stemuemor nee En lugar de las sentencias, la cobertura de decision se centra en el flujo de control en un segmento de programa (no los nodos . sino las aristas del diagrama de flujo de control) - Todas las aristas del diagrama de flujo de control tienen que ser Gubierfas al menos una vez = gQué casos de prueba son necesarios para cubrir cada arista del diagrama de flujo de control al menos una vez? El propésito de esta prueba (criterio de salida) es lograr la cobertura de un porcentaje especifico de todas las decisiones, denominado cobertura de decisién (C, cobertura de decision - “decision coverage"; cobertura de rama - "branch coverage") Sindnimo de: IV - Técnicas de disefio de pruebas 04 - Técnicas basadas en Ia estructura o de caja blanca ") Ejemplo 1 Ejemplo 1V/02-3. El grafico ("diagrama") de fivjo de control [imagen a la derecha) representa el segmento de un programa objeto de la evaluacién Tres caminos diferentes conducen a través del diagrama de este segmento de programa - La primera sentencia “it” conduce a dos direcciones diferentes - Un-camino de Ia primera sentencia "if" se divide nuevamente en dos caminos diferentes, uno de los cuales contiene un bucle - Solamente se puede alcanzar todas las aristas a través de Una Combinacidn de los tres Caminos posibles - Son necesarios tres casos de prueba para alcanzar una coberiura de decisién del 100% - Utiizando solamente las dos direcciones de la derecha, pueden ser cubierlas nueve de diez arisias (C, = 90%) raging |seu Faz Se ee cam IV - Técnicas de disefio de pruebas oacrnemneg 04- Técnicas basadas en Ia estructura o de caja blanca ai sare arcvelnabase ea Cobertura de decision (“de Ejemplo 2 - Elemplo 1V/02-4 = Eneste ejemplo el grafico ("“diagrama") es ligeramente més complejo = Cuatro "caminos" diferentes conducen a través del segmento de programa = La primera sentencia “if" permite dos direcciones - En.ambas ramas de Ia sentencia "if" otra sentencia “if* permite nuevamente dos direcciones diferentes - Eneste ejemplo, el bucle no se cuenta como una decisié \ agicional - Utilizando sélo un caso de prueba, pueden ser cubiertas 7 de 15 aristas. Esto resulta en un valor de C=46,67% = Son necesarios cuatro casos de prueba para lograr una cobertura de decision del 100% = in este ejemplo, son necesarios el mismo conjunto de casos de prueba para lograr una cobertura de sentencia del 100%! 2) © (b<6)) s6lo puede ser verdadera o falsa = Elcamino (del programa) a ejecutar depende solamente del resultado final de la condicién combinada * Aquellos fallos debidos a una implementacién errénea de las partes de una decisién combinada pueden no ser detectados 9b ce seat rook iS IV - Técnicas de disefio de pruebas 04 - Técnicas basadas en la estructura o de caja blanca 3 nica a EE Diaz Hilerscheid sccm © Rains Pruebas de condicién y cobertura - Se tiene en cuenta la complejidad de una condicién que esté Cconstituida por multiples condiciones atémicas ~ Una condicién atémica no puede ser dividida en sentencias condicionales mas pequenios - _ &ste método tiene por objetivo detectar defectos que resuiten de la implementacién de condiciones mulfipies (condiciones ‘combinadas) ~ Las condiciones multiples estén constitvidas por condiciones aigmicas, que se combinan con el uso de operadores logicos como: i OR, AND, XOR, etc. a Ejemplo: {(a>2) OR (b<6)) % = Las condiciones atémicas no contienen operadores l6gicos, sélo contienen operadores relacionales y el operador NOT [=, >, <, etc.). - Hay tres tipos de cobertura de condicién, - Cobertura de condicién simple ("simple condition coverage’ - Cobertura de condicién multiple ("multiple condition coverage"). ~ Minima cobertura de condicién maltiple (“minimum multiple Condition coverage’).IV - Técnicas de disefio de pruebas 04 - Técnicas basadas en Ia estructura o de caja blanca tae Hiterscheid Cobertura de condicién simple ("simple condition coverage") - Cada sub-condicién atémica de una sentencia condicional combinada tiene que tomar, al menos una vez, los valores légicos verdadero (“true) asi como falso ("false") - Este ejemplo se utiliza para explicar ia cobertura de condicién utiizando una expresion con una condicién moittiple = Con sélo dos casos de prueba se puede lograr una cobertura de condicién simple ~ Cade sub-condicion ha tomade los valores verdadero ("trve) y faso ("false") - Sin embargo. el resultado combinado es verdadero ("“true"}en ambos casos = Inve OR folse = true = folse OR true = true ‘Stace neon mRang sibiRaiS IV - Técnicas de disefio de pruebas 04 - Técnicas basadas en Ia estructura o de caja blanca Diaz iterscheid cas be cemunindb naib tatiana Se SO Cobertura de condicién miltiple (“multiple condition coverage") - Todas las combinaciones que puedan ser creadas utilizando permutaciones de las sub condiciones alémicas deben formar parte de las pruebas ~ Este ejemplo se utiliza para explicar ia cobertura de condicién utiizando una ‘expresién con una condicién multiple - Con cuatro casos de prueba se puede lograr una cobertura de condicién multiple ~ Se han creado todas los combinaciones de los valores verdadero ("true") y faiso ("false") Se han logrado todos los posibles resultados de la. condici6n moltipie ise) ae BI mora do coso de prusba so incremenia [eeow | de forma potencial z mero de condiciones atémicas \imero de casos de prueba ogi 28IV - Técnicas de disefio de pruebas oaths 04- Técnicas basadas en la estructura o de caja blanca Minima cobertura de condicién multiple (“Minimum multiple condition coverage”) Todas las combinaciones que puedan ser creadas utilizando los resultados légicos de cada sub-condicién deben ser parte de las pruebas, sdlo si el cambio del resultado de una sub-condicién cambia el resultado de la condicién combinada - ste ejemplo se utiliza para explicaria cobertura de condicién utilizando una expresién con una condicién multiple: - Los cambios de una sub-condicién cambian el resultado global para tres de cuatro casos de prueba Séio para el caso? (hue OR Wve = tue} elcombio en osu conclcion no resultore en un combo en ld Concicion global ste caso de prueba puede ser omitoot Mi - El numero de casos de prueba se puede reducir Gun valor entre nly 2n Si cerbinde eno de los de bos rvningcoiivainsnnw gle La decietaes obbnge el oes Sreeliedo predo lms eee eae IV - Técnicas de disefio de pruebas 04 - Técnicas basadas en Ia estructura o de caja blanca staccato Cobertura de condicién (“condition coverage”) - conclusiones generales - Lacobertura de condicién simple es un instrumento débil para probar condiciones moltiples - La cobertura de condicién multiple es un método mucho mejor - Asegura cobertura de sentencia y decision = Sin embargo, tiene como resultado un alto numero de casos de prueba: 2° = La ejecucién de algunas combinaciones no es posible = Por ejemplo "x > 5 AND x < 10” ambas sub condiciones no pueden ser falsas al mismo tiempo - La minima cobertura de condi debido a: Reduce el nimero de casos de prueba [de (n+1} a (2n)] - Las coberturas de sentencia y decision también son cubiertas - Tiene en cuenta la complejidad de las sentencias de decision iple es incluso mejor, Todas las decisiones complejas deben ser probadas - la minima cobertura de condicién miltiple es adecuada para lograr este objetivoIV - Técnicas de disefio de pruebas 04 - Técnicas basadas en Ia estructura o de caja blanca jitter Stade Biase Prueba de camino y cobertura ("‘path testing and coverage") n - La cobertura de camino se centra en Ia ejecucién de todos los posibles caminos a través de un programa = Un camino es una combinacién de segmentos de programa (en un grGlico T'diagrama”) de flujo de controt ona secuenciarde nodos y aristas alternados) = Para cobertura de decision, un solo camino a través de un bucle es suficiente. Para la cobertura de camine hay casos de prueba adicionales = Un caso de prueba ne entrante al bucle = Uncato de pruebe adicional para cada ejecucién del bucte - Esto puede conducir a un némero muy alto de casos de prueba _siernunesnedimeretnnbaiioosnin tent eterno B68 (RES IV - Técnicas de disefio de pruebas omriteneg 04 - Técnicas basadas en la estructura o de caja blanca | Ronrvass ment absaitsonEe ion neler Prueba de camino y cobertura (“‘path testing and coverage") /2 = Elfoco del andiisis de cobertura es el grafico ("“diagrama") de fiujo de control = Las sentencias son nodos - El flujo de control esta representado por las aristas - Cada camino es una via Unica desde el inicio al fin del diagrama de flujo de control = Elobjetivo de esta prueba (criterio de salida) es aleanzar un porcentaje definido de cobertura de camino i nos cubiertos |Cobertura de camino ‘Nimmare de caminos cUblerioe! =100%| ‘Numero total de caminos | ban tis cetsibmenerteat.n Gab seman reine) tit> en IV - Técnicas de disefio de pruebas : 04 - Técnicas basadas en la estructura o de caja blanca z Diez Hi Cobertura de camino (“path coverage ") - Ejemplo 1 - Ejemplo 1V/02-5: - El gréfico ("diagrama") de flujo de control de la imagen ala derecha, representa el segmento de programa a ser evaluado. Contiene tres sentencias “i = Tres caminos diferentes conducen a través del diagrama de este segmento de programa logran una cobertura de decisin completa - Sin embargo, pueden ser ejecutados cinco posibles caminos distintos ~ Son necesatios cinco casos de prueba para lograr un 100% de cobertura de camino = S6lo dos son necesarios para un 100% de cobertura CO {de sentencia), ires son necesarios para un 100% de cobertura Cl (rama o decision) =) IV - Técnicas de disefio de pruebas 04 - Técnicas basadas en Ia estructura o de caja blanca Scar RE ae ice tase Diaz Hltescheid seater Cobertura de camino (“path coverage ") - Ejemplo 2 Ejemplo 1V/02-6: - Eidiagrama de fiujo de control de la imagen ala derecha, representa el segmento de programa a ser evaluado. Contiene dos sentencias “if" y un bucle en. / el interior de la segunda sentencia if i] - Tres caminos diferentes que conducen a través del diagrama de este segmento de programa logran una cobertura de decision completa - Sie bucle se ejecuta dos veces, son posibles cuatro caminos diferentes - Cada incremento en el contador del bucle afiade un nuevo caso de prueba> Tee REET IV - Técnicas de disefio de pruebas 04 - Técnicas basadas en la estructura o de caja blanca fe Seti naa avila a Te: 4 Diaz Hiterscheid prseesaasnac cei Cobertura de camino (“path coverage ") - conclusiones generales - £1100% de cobertura de camino sélo se puede lograr en programas muy simples = Un solo bucle puede conducir a una explosién de casos de prueba dado que, toda posible ejecucién de un bucle constituye un nuevo caso de prueba - Tedricamente es posible un némero indefinido de caminos - La cobertura de camino es més exhaustiva que la cobertura de sentencia y de decisién - Cada posible camino a través del programa es ejecutado - 100% de cobertura de camino incluye 100% de cobertura de a decisién, que a su vezincluye 100% de cobertura de sentencia 4 ‘gmp ent ete Seine a z 2 2 IV - Técnicas de disefio de pruebas parritenches 04 ~ Técnicas basadas en Ia estructura o de coja blanca ar ipicit naar ie on aie Soaks ramercc meta Ejercicio: Técnicas de caja blanca Utilizando un diagrama de flujo de control (parte 1) y pseudo: cédigo (parte 2) se tiene de determinar el minimo numero de casos de prueba para lograr 100% de cobertura de: - Sentencias ~) obdes - Ramas / decisiones > sien ples stom perobes minions cnet shes - Caminos iain sa athaba catense inten 106.618 ale IV - Técnicas de disefio de pruebas 04 - Técnicas basadas en Ia estructura o de caja blanca st webs ine ere" Diaz Miterscheid Resumen - Los métodos de caja blanca y caja negra son métodos dindmicos, el objeto de prueba es ejecutado durante las ruebas - _Elmétodo de caja blanca (white-box) comprende: ~ Cobertura de sentencia (“statement coverage”) - Cobertura de decisién (“decision coverage") Sie - Cobertura de camino (“path coverage") - Cobertuar de condicién (“condition coverage") [simple (" milfiple (“mulfiple"), minimo multiple ("minimum multipie")] - S6lo se puede probar cédigo existente. Habiendo funciones faltantes, este hecho no puede ser detectado. Sin embargo el cédigo muerto o superfluo puede ser defectado con las pruebas de caja blanca - Principalmente, los métodos de caja blanca son utilizados en pruebas de bajo nivel como pruebas de componente o pruebas de integracién - Los métodos difieren en Ia intensidad de las pruebas (profundidad de la prueba} ~ Dependiendo del método, el nimero de casos de prueba es distinto ingle"),—_ IV - Técnicas de disefio de pruebas Contenido Diaz Hiterscheia Capitulo IV - Técnicas de disefio de pruebas - 1V/01 Proceso de desarrollo de prueba - IV/02 Categorias de las técnicas de disefio de prueba - 1V/03 Técnicas basadas en Ia especificacién o de caja negra -_IV/04 Técnicas basadas en la estructura o de caja blanca [ET EV SEE DE ES iv/05Téenicas basadas én la expenencia /06 Seleccién de las técnicas de prueba anemibasinenringabstaonm gem corey 2: etetcutcode- teste i0es12 Peni ane IV - Técnicas de disefio de pruebas 05 - Técnicas basadas en la experiencia sian Diaz Hitescheid Definicién de técnicas basadas en la experiencia - Préctica para la creacién de casos de prueba sin un claro enfoque metodolégico, basada ena intuicién y experiencia del | 8 probador ill. | il - Los casos de prueba estan 2s qeareera basados en la intuicién y 3 “aber de rams experiencia 2 “oben fe ondn = 2D6nde se han acumulado 3 errores en el pasado? 5 = gDénde falla normaimente el i See software? 2 | Cwantnoughsy S| Anat co mio de cont t “Andlisis del flujo de datos. atte rsgnatba