Teoria-2n-Parcial PDF - Test i Qualitat del Software

Teoria-2n-Parcial.pdf tottii24 Test i Qualitat del Software 3º Grado en Ingeniería Informática Escuela de Ingeniería Universidad Autónoma de Barcelona Reservados todos los derechos. No se permite la explotación ec...

Teoria-2n-Parcial.pdf tottii24 Test i Qualitat del Software 3º Grado en Ingeniería Informática Escuela de Ingeniería Universidad Autónoma de Barcelona Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. a64b0469ff35958ef4ab887a898bd50bdfbbe91a-11368059 Bugs Bugzilla 1. Terminologia d'un defecte 1.1. Defect or bug Tindrem un defecte (o error) quan el comportament d'una aplicació sigui diferent de l'esperat. Qualsevol desviació del que s'esmenta als requisits es pot considerar un defecte, per exemple, pot ser un resultat diferent o una interfície d'usuari diferent. 1.2. Error or mistake Problemes en el disseny del programari o en el codi font que sorgeixen d'un bug. Per tant, els bugs són conseqüència dels errors. Per exemple, si feu clic a un botó, no activa una acció esperada, és possible que tinguem un error al codi que implica aquest botó. 1.3. Crash Es produeix quan una aplicació deixa de funcionar i surt. Sovint podeu obtenir registres de crash que incloguin els detalls exactes de l'estat abans que l'aplicació es bloquegi, pot ser útil reproduir el problema i trobar l'error al codi. 1.4. Debugging El procés per trobar el motiu d'un error. Normalment, executem "pas a pas" l'aplicació, comprovant l'estat de les variables del nostre codi, el flux entre mètodes, de manera que podem descobrir el problema i solucionar l'error. 2. Tipus d'error Els defectes funcionals són aquests casos en què el comportament del programari no compleix els requisits funcionals. o Exemple, un usuari omple un formulari i feu clic al botó per enviar-lo, però aquest botó no activa cap acció. Els defectes d'usabilitat fan que una aplicació sigui incòmode d'utilitzar, anomenem això una mala experiència d'usuari. o Exemple: una interfície d'usuari per la qual és difícil de navegar, que té massa clics al seu flux de treball o que no us guia de manera natural, es pot considerar defectes/errors d'usabilitat. o Per identificar aquests defectes, podem fer servir les directrius d'accessibilitat de contingut web (WCAG). Els defectes de rendiment són aquells relacionats amb la velocitat, l'estabilitat, el temps de resposta i el consum de recursos del programari i es descobreixen durant les proves de rendiment. o Un exemple d'un defecte de rendiment és que el temps de resposta d'un sistema és X vegades més llarg del que s'indica als requisits. Els errors de seguretat fan que el vostre projecte sigui vulnerable. Aquest error obre el vostre programari, la vostra empresa i els vostres clients a un atac potencial greu. Aquests atacs poden ser costosos si provoquen violacions de dades. o L'Open Web Application Security Project (OWASP) enumera deu riscos de seguretat, però alguns dels més comuns són els errors de xifratge, la susceptibilitat a les injeccions SQL, les vulnerabilitats XSS, els desbordaments de buffers, els errors lògics i l'autenticació inferior. Un error de compatibilitat podria mostrar un comportament inesperat executant una aplicació en un sistema operatiu diferent o utilitzant un maquinari diferent. o Els defectes es poden trobar a la UI com a canvis en la mida de la lletra, l'alineació del contingut, el scroll bar, etc. Però també es poden provocar una comunicació de maquinari específica o altres dependències d'aplicació. o Relacionat amb aquest tipus d'error, també podem tenir un problema de retrocompatibilitat, que fa que una nova versió de l'aplicació perdi la interoperabilitat amb altres sistemes. Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. a64b0469ff35958ef4ab887a898bd50bdfbbe91a-11368059 Hi ha molts altres tipus d'errors que es poden considerar un error. La majoria d'ells són errors que es poden detectar durant la compilació o l'execució de proves unitàries, de manera que potser l'usuari final no els trobi mai en producció. o Alguns exemples són errors de sintaxi, errors a nivell d'unitat, errors d'integració a nivell de sistema, errors fora de límits, duplicació de codi i tipus de dades mistmatc 3. Gravetat d'un error La gravetat de l'error a les proves és un grau d'impacte que té un error a l'aplicació de programari. Solien classificar-se com a crítics, majors, normals, menors i de millora/cosmètica. Aquest valor el pot Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. establir l'usuari que detecti l'error. Crític: aquest defecte indica l'aturada completa del procés, res no pot continuar Major: És un defecte molt greu i col·lapsa el sistema. No obstant això, algunes parts del sistema continuen funcionant Normal: provoca un comportament no desitjat, però el sistema encara funciona Menor: no provocarà cap avaria important del sistema Millora: es pot considerar com una millora, en lloc d'un error. 4. Prioritat d'un error La prioritat es defineix com l'ordre en què s'han de corregir els errors. Un error que deixa el sistema inutilitzable té una prioritat més alta. La prioritat està impulsada pel valor empresarial mentre que la gravetat està impulsada per la funcionalitat, de manera que la prioritat es decideix en consulta amb el gestor o el client. Baix: l'error es pot solucionar més tard. Altres errors més greus tenen prioritat Mitjà: l'error es pot solucionar en el curs normal de desenvolupament i prova. Alt: l'error s'ha de resoldre el més aviat possible, ja que afecta negativament el sistema i el fa inutilitzable fins que es resolgui. 5. Cicle de vida dels errors Els estats del cicle de vida d'un defecte són: Nou: Es registra per primera vegada. Verificat: El defecte s'ha resolt i verificat. Assignat: S'assigna a l'equip de Tornar a obrir: El defecte persisteix i es torna desenvolupadors. al cicle. Obert: El desenvolupador comença a Tancat: El defecte ja no existeix. treballar-hi. Duplicat: És un error repetit. Solucionat: El defecte es corregeix i es No vàlid: No és un defecte real. verifica. Diferit: Es posposa per una futura versió. Pendent de tornar a provar: S'envia al No és un error: No afecta la funcionalitat de verificador per a proves. l'aplicació. 6. Eines de seguiment d'errors Jira, Bugzilla, Redmine, Mantis, Backlog i altres eines com GitHub o GitLab permeten gestionar errors, projectes i proves amb funcionalitats com registre, seguiment i fluxos de treball. Inclouen camps clau com identificador, descripció, passos per reproduir, prioritat, severitat i estat. Abre tu Cuenta NoCuenta con el código WUOLAH10 y llévate 10 € al hacer tu primer pago Test i Qualitat del Software Banc d'apunts de la a64b0469ff35958ef4ab887a898bd50bdfbbe91a-11368059 Exploratory Testing 1. Introducció Què és i què no és el ET: No és una tècnica concreta i específica Si és una actitud, una manera de fer, una mentalitat Un procés on es testeja mentre s’explora Sovint se l’anomena ad hoc testing Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. És un procés on, simultàniament (i amb retroalimentació): o S’aprèn o Es dissenya el test o S’executa el test ▪ L’estratègia del test es va modificant a mesura que coneixem el sistema. Resultats de l’ET: o Un conjunt de notes sobre el producte o Errors trobats o Un informe concís dels passos realitzats al fer el test No depèn d’instruccions preestablertes o programades (defined o scripted), per tant, o Com que és un procés creatiu, depèn de l’habilitat del tester. o El tester no es pregunta “quin test m’han dit que faci o em toca fer?” sinó “quin bon test puc fer ara?” o Pot ser més productiu que scripted-tests Com que és una activitat creativa: o ET per parelles. Mentre un tester pensa i executa nous testos, l’altre pot pensar nous tests, provar el mateix en altres plataformes, buscar documentació. NO és incompatible amb test preestablert o scripted (test cases, test scripts, etc) sinó que és complementari.... i de fet, tampoc es pot dir si es fa o no es fa ET, sinó que el ET és un espectre continu que va del pur scripted test al ET pur. Elements importants en el ET: Test design: Un tester de ET és principalment un test designer, ja que es requereix l’habilitat d’analitzar el producte, avaluar riscos, pensar críticament,... Observació crítica: Un tester d’ET és un bon observador per veure comportaments foscos o no evidents a simple vista. Pensament crític: Necessari per analitzar un sistema. Produir noves idees: Són necessàries per definir nous tests (també s’anomenen atacks). En quines situacions és útil? Quan es necessita Feedback immediat d’un nou producte o funcionalitat. Aprendre ràpid el producte. Trobar el Bug més important i es disposa d’un temps limitat. Aïllar i investigar un defecte concret. Investigar l’estat d’un risc concret. Ja s’ha realitzat test scripting i es vol una nova aproximació. Improvisar test scripting. Analitzar el producte i fer test planning. Millorar els tests existents és majoritàriament útil un cop el producte ja s’ha (parcialment) desenvolupat, però també mentre s’està desenvolupant! Abre tu Cuenta NoCuenta con el código WUOLAH10 y llévate 10 € al hacer tu primer pago a64b0469ff35958ef4ab887a898bd50bdfbbe91a-11368059 2. Consells pràctics L’experiència demostra que els bons “attacks” a un software quan es fa ET són: ▪ Atac 1: apliqueu entrades que obliguen a que tots els missatges d'error es produeixin almenys una vegada ▪ Atac 2: aplica entrades que obliguen el programari a establir valors predeterminats ▪ Atac 3: Exploreu conjunts de caràcters permesos i valors de significat potencialment especials als camps de cadena ▪ Atac 4: desbordament dels buffers d'entrada en camps o paràmetres de cadena ▪ Atac 5: Trobeu entrades que puguin interactuar i provar combinacions dels seus valors ▪ Atac 6: Repetiu la mateixa entrada o sèrie d'entrades nombroses vegades ▪ Atac 7: Coneix el domini del problema i pensa en casos especials de combinacions d'entrada que obliguen a generar sortides no vàlides ▪ Atac 8: forçar les propietats d'una sortida a canviar ▪ Atac 9: força la pantalla a actualitzar-se per trobar problemes de renderització en aplicacions amb sortida gràfica ▪ Atac 10: força les estructures de dades (conegudes pel codi font o endevinades) a emmagatzemar massa o massa pocs valors ▪ Atac 11: investigar maneres alternatives de modificar les restriccions internes a les propietats de les dades, a més de la mida en la creació de l'estructura de dades ▪ Atac 12: experimenta amb combinacions d'operands i operadors que poden provocar que el programari falli ▪ Atac 13: Força una funció a cridar-se recursivament ▪ Atac 14: Trobeu funcions que comparteixen dades o interaccionen malament Prova des de la interfície del sistema de fitxers 1. Ompliu el sistema de fitxers a màxima capacitat 2. Força el suport a estar ocupat o no disponible 3. Simula els mitjans d'emmagatzematge danyats 4. Assigna un nom de fitxer invàlid 5. Varieu els permisos dels fitxers 6. Varieu o malmeteu el contingut dels fitxers Prova des de la interfície de programari/SO 1. Errors de memòria (insuficient, bloqueig) 2. Errors de xarxa (desconnexió, xarxa no instal·lada, xarxa baixa, versió de Winsock incorrecta, ports disponibles...) 3. CONCLUSIÓ 1. Simplement, passar pels atacs pot exercir una gran part de la funcionalitat de l'aplicació 2. Un atac exitós sol significa experimentar amb dotzenes de possibilitats i perseguir una sèrie de carrerons sense sortida 3. Els atacs proporcionen objectius concrets a partir dels quals dissenyar casos de prova 4. Per tant, cada prova té un propòsit i es pot controlar el progrés 5. Planificació sobre la marxa, però forma eficaç d'esbrinar errors Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. a64b0469ff35958ef4ab887a898bd50bdfbbe91a-11368059 Test Automation 1. Introducció Què és? El procés d’automatitzar les proves de regressió. Avantatges: o Reduir l’esforç necessari per fer test o Augmentar el nombre de tests a executar en un temps limitat (pot estalviar fins a un 80% Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. del temps de test manual) Quins aspectes que defineixen la qualitat d’un test case pot millorar l’automatització? Efectivitat en la detecció de defectes Exemplaritat (testejar més d’una cosa a la vegada) Economia (esforços i recursos per executar-lo) Mantenibilitat i expansió (quan es modifica el SW) o Nota: Efectivitat i exemplaritat només depenen de les habilitats del tester Avantatges: Executar tests de regressió Més test en menys temps (o més sovint) Genera més seguretat en el SW Executar testos impossibles d’executar manualment: Exemples? o Proves on-line amb 200 connexions, dades d’una base de dades, atributs interns d’una GUI, events generats en una GUI, etc … Millorar la precisió: o Executant tasques repetitives i avorrides (entrar inputs, textes, etc) que són propenses a error. Consistència en/i la repetibilitat del test o Executar el test exactament igual cada cop Reutilització del test Desavantatges? Esperances no realistes (el automated testing no és la panacea!) Porta fàcilment a fer mals testos: o Es preferible millorar l’efectivitat del test que no la de l’automatizació (“Automating chaos just gives faster chaos”) Creure que l’automatizació descobrirà nous defectes o Els defectes es solen trobar en la primera execució d’un test. El regression testing només assegura que cap efecte secundari ens tornarà a produir un nou error (i, per tant, serà un error menys probable). Manteniment no sempre és fàcil (canviar el SW pot significar canviar el test) Missatge: L’automatització no sempre és bona! Es pot automatitzar el disseny d’un test case? La imaginació i habilitat d’un dissenyador humà no es poden substituir, però … Les eines d’automatització dels test inputs poden ajudar. N’hi ha de tres tipus: Code-based o Paràmetres per executar un path, … Interface-based o En una GUI es poden visitar tots els objectes sensibles (botons, caselles), visitar tots els links d’una pagina web, … (tècnica anomenada monkey test) Abre tu Cuenta NoCuenta con el código WUOLAH10 y llévate 10 € al hacer tu primer pago a64b0469ff35958ef4ab887a898bd50bdfbbe91a-11368059 Specification-based o A partir de llenguatge natural (o quasi) poden generar inputs i els outputs corresponents: valors límit, particions equivalents, … Que suggereix el darrer punt? Es poden automatitzar les proves de caixa negra!!! Limitacions del automated testing: NO substitueix el manual testing !!!!!!!! Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. o Hi ha testing que MAI es podrà realitzar de forma automàtica o Només s’hauria d’automatitzar el manual testing que s’executa molt NO s’hauria d’automatitzar: o Test que s’executa rarament o SW volàtil (que canvia molt, sobretot la seva interfície) o SW fàcilment verificable per un humà i difícilment per una màquina. Exemple?: ▪ Imatge, esquema de colors, estètica, sò … o Interacció amb hardware (sobretot quan no podem controlar perfectament l’estat del hardware) Si el SW és inestable ➔ Manual testing! Manual testing (85% errors) / Automated testing (15%) o (en aquest cas hem de considerar el JUnit com manual testing) No millora l’efectivitat del test (no troba més ni millors errors) Les eines NO són intel·ligents: o Un usuari pot veure que el comportament del SW és incorrecte tot i que els outputs siguin els esperats 2. Scripting L’automatització és fàcil amb scripting, però és avorrida i pesada Avantatges de l’scripting detallat: Testers executen sempre el mateix test Errors de SW més fàcils de reproduir Qualsevol pot executar el test (programadors, testers, …) Fàcil d’automatitzar Desavantatges: Difícil de crear Molt texte/instruccions redundant És verbose Avorrit d’executar (el tester no fa gran cosa excepte mirar) Overhead de feina Esforç per crear el script La informació està documentada dos cops (a la descripció del test i al script) o Informació hauria de ser llegible per humans i per l’eina de test. Hi ha 2 tipus: Manual scripts (JUnit) Escrits per usuaris humans Solen ser legibles Serveixen com a documentació Automated scripts (Jubula) Creats per un SW Difícils de llegir Abre tu Cuenta NoCuenta con el código WUOLAH10 y llévate 10 € al hacer tu primer pago a64b0469ff35958ef4ab887a898bd50bdfbbe91a-11368059 Si són creats perquè s’ha fet recording, tenen una utilitat limitada 2.1. Recording Procés de gravació de les accions realitzades per l’usuari Desavantatges: Solen crear scripts il·legibles Només són útils si s’han de reexecutar Molt centrats en aspectes específics fàcilment volàtils: o Posició en la pantalla, bitmaps, cadenes de caràcters, ordre en una llista … Si el SW canvia mínimament el script pot fàcilment deixar de funcionar. NO automatitzar testing fent recording!!! Recording NO fa test, ja que no es fa cap comprovació de la sortida (outcomes)!!! o Si no es comprova el outcome NO es fa automated test, es fa automated input. Per tant, si volem fer automated testing, hem de fer?: Automated comparison 2.2. Outcome Comparison Tipus?: Dynamic comparison o Realitzat DURANT l’execució del test o Com es compara ho decideix el tester (imatges, llistes, element dins una llista, posició en la pantalla, elements en la pantalla … ). Post-execution comparison o Realitzat DESPRÉS de l’execució del test Automated comparison NO és una tasca trivial Hi ha moltes coses a comparar o Triar dynamic o post-execution depèn del què es compara i quan es compara. Els scripts es tornen complexes Més informació a comparar Més susceptibles als canvis (del SW i del test case) 2.3. Scripting techniques Tècniques: Linear scripts Shared scripts Structured scripting Data-driven scripts 3. Automated comparison Verification és el procés de chequejar els outcomes a través d’una comparison. Tipus: Dynamic i post-execution Per què comparar automàticament? o Una comparació és probablement una tasca molt automatitzable o Sense automated comparison no tenim automated testing Simple comparison o Comparació EXACTA del outcome i el resultat esperat Complex comparison o Comparació amb diferències esperades: output amb ordre diferent, diferències dins un rang (comparació de floats, …) Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. a64b0469ff35958ef4ab887a898bd50bdfbbe91a-11368059 Quanta informació s’ha de comparar? o Molta: Serem molt sensibles a petits (irrellevants?) canvis o Poca: Més robust, però menys acurat Filtres: o És un pas d’edició o transformació: Eliminació de dades, extracció, conversió, ordenació o S’apliquen tant als outcomes com als resultats esperats Avantatges: o Reutilitzables o Criteri de comparació específic Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. o Outcomes complexos poden ser analitzats per eines simples 4. Altres Quins tests hem d’automatitzar primer? o Repetitius i human error-prone o Testing funcional (Què fa el SW) ➔ Test Driven Development o Els més importants o Els que s’executen més cops o Els més fàcils d’automatitzar Do not automate too much too soon (en oposició a “test a little, code a little”) Utilitzar test-selectors: o Permeten executar diferents tipus de test (short tests, tests that failed the firsttime, performance test, load tests, …) Designing SW for (automated) testability o De manera similar al TDD, podem desenvolupar el codi tenint en ment la manera en què farem el test ➔ En podríem dir ATDD Software Quality Assurance: (SQA) 1. Introducció Objectiu Enginyeria del Software: SW de qualitat! →La qualitat es construeix, no es pot afegir al final Qualitat: Externa: la percebuda per l’usuari Interna: la percebuda pels desenvolupadors Com s’assoleix?: o Complint especificacions: funcionals i no funcionals. o Desenvolupant seguint procediments Standard o Característiques implícites: mantenible, segur, documentat Quins factors defineixen la Qualitat? (i què mesuren): Característiques operatives (funcionament del SW) o Correcció: Grau de compliment dels requeriments o Fiabilitat: Exactitud del funcionament o Eficiència: Quantitat de recursos necessaris o Facilitat d’us i aprenentatge o Seguretat Revisió del producte (facilitat dels canvis) o Facilitat de manteniment: Esforç per localitzar i arreglar un defecte o Flexibilitat: Esforç per fer les millores o Facilitat de prova Abre tu Cuenta NoCuenta con el código WUOLAH10 y llévate 10 € al hacer tu primer pago a64b0469ff35958ef4ab887a898bd50bdfbbe91a-11368059 Transició del producte (adaptabilitat a nous entorns) o Portabilitat: Esforç per migrar o Reusabilitat: Quantitat de SW que es pot reaprofitar per a altres apliacions o Interoperativitat: Esforç per acoplar el SW a un altre sistema 2. Standards Defineixen característiques de: Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. Tipus de productes de SW (programes, manuals, documents d’especificació, disseny, proves, …) Processos d’enginyeria (com fer revisions tècniques formals, com aplicar mètriques, com fer gestió de la configuració, models de desenvolupament, …) Avantatges: Descriuen les millors (o més apropiades) pràctiques de treball: (dictades per l’experiència) Evita repetir errors habituals Assegura que tothom (desenvolupadors, testers, etc) Segueix les mateixes pràctiques. Afavoreix la continuïtat de la feina quan algú abandona un projecte Redueix esforç d’aprenentatge Es comunica, coordina i entén millor Desavantatges: Costosos de desenvolupar ➔ Cal recórrer a standards d’organitzacions mundials (IEEE, ISO, ANSI…) i adaptar-los. La seva aplicació (i verificació) porta més feina (però també més qualitat) Poden estar desfasats respecte tècniques més modernes (SW orientat a objecte, nous llenguatges, sistemes operatius…) Han d’estar al servei del projecte, no al revés! o S’ha de seguir un standard, però s’ha de modificar o canviar si no és útil. o S’ha d’adaptar a les nostres necessitats. 2.1. Fonts dels estàndards organitzacions nacionals i internacionals d’estandardització o ISO International Standards Organization o British Standards Institute o American Society for Testing and Materials grups professionals o industrials o IEEE o ANSI o EIA agències governamentals o DoD departament de defensa dels Estats Units o DEF Britsh Defence Standards o NIST National Institute of Standards and Technology http://www.nist.gov o ESA European Space Agency http://www.estec.esa.nl/ecss empreses: Bellcore Communications Research centres de recerca: SEI Software Engineering Institute 3. Quality Metrics Definició (segons la IEEE): Una mesura quantitativa del grau en què un element posseeix un cert grau de Qualitat respecte a algun aspecte (p. Ex. fiabilitat, reusabilitat, portabilitat …). Una funció: o Input: Dades sobre el SW o Output: Valor numèric (que és la mesura quantitativa anterior) Abre tu Cuenta NoCuenta con el código WUOLAH10 y llévate 10 € al hacer tu primer pago a64b0469ff35958ef4ab887a898bd50bdfbbe91a-11368059 Objectius: Facilitar el control, planificació i actuació del procés de gestió de desenvolupament del SW. Basat en: o Desviacions respecte al grau de performance previst. o Desviacions respecte al timetable i el pressupost previst. Identificar moments per millorar el procés de desenvolupament (preventive corrections). Basat en: o Acumulació de mètriques sobre el grau de performance dels equips de desenvolupament, unitats, etc. Desavantatges No existeix una mètrica global per a tot ➔ Es limiten a certs aspectes o No hi ha un acord sobre quines són les millors o Moltes prenen significat només quan es comparen amb els valors per a altres projectes o Es poden veure afectades per diferents factors (estil de codi, complexitat del codi, percentatge de codi reutilitzat, volum de documentació, …) Com mesurem la Qualitat? o És difícil obtenir una única mesura de Qualitat del SW: ▪ on mi és una mètrica, i c i un pes subjectiu Tipus de mètriques: Fases del sistema SW o Mètriques de procés: Relacionades amb el procés de desenvolupament del SW o Mètriques de manteniment: Relacionades amb la facilitat de manteniment o Mètriques del producte: Relacionades amb les funcionalitats del SW Mesures de Conceptes concrets o Qualitat del codi o Timetable o Efectivitat (d’eliminació d’errors) o Productivitat Mesura de mida/volum del SW Mesura comptatge d’errors KLOC: (mètrica clàssica) Nombre de milers de línies de codi. NFP (Number of Function Points): Nombre de recursos humans necessaris per desenvolupar un SW o funcionalitat 3.1. Mètriques de procés Error density mètrics Error severity metrics Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. a64b0469ff35958ef4ab887a898bd50bdfbbe91a-11368059 SW process timetable mètrics Error removal effectivenes mètrics Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. Process productivity metrics 3.2. Mètriques de manteniment HD (Help Desk Service) calls density mètrics Severity of HD calls metrics and HD success mètrics HD productivity and effectiveness mètrics Failures density mètrics Abre tu Cuenta NoCuenta con el código WUOLAH10 y llévate 10 € al hacer tu primer pago a64b0469ff35958ef4ab887a898bd50bdfbbe91a-11368059 3.3. Mètriques del producte Mètriques de producte Mètriques Orientades a Objecte Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. 3.4. Mètriques - Exemples Mètriques d’anàlisi Especificat o manca d’ambigüitat Q1 = nui / nr nui nombre de requeriments interpretats de la mateixa manera per tots els revisors nr nombre total de requeriments Mètriques d’anàlisi i disseny complexitat del disseny de l’arquitectura de mòduls o complexitat d’estructura S(i) = fout 2(i) o complexitat de dades D(i) = v(i) / (fout (i) +1) o complexitat del disseny C = ∑i S(i) + D(i) fout : expansió, nombre de mòduls invocats directament pel mòdul i v(i) : nombre de variables d’entrada i sortida del mòdul i complexitat MHK o MHK = l(i) [ fin(i) + fout (i) ] o fin : concentració, nombre de mòduls que invoquen directament al mòdul i o l(i) : nombre de sentències amb què s’ha programat el mòdul i 3.5. Mètriques orientades a la dificultat del test PPP percentage of public and protected o % d’atributs publics d’una classe respecte privats i protegits, comptant els heredats o PPP alt incrementa la probabilitat d’efectes col·laterals imprevistos entre classes ➔ dissenyar més proves APD acces to public data members o nombre de mètodes que accedeixen directament (sense cridar mètodes d’accés) a atributs d’alguna altra classe, anant en contra doncs de l’encapsulament de les classes o APD alt ➔ alta probabilitat d’efectes col·laterals entre classes NRC number of root classes o nombre de jerarquies d’herència o NCR alt ➔ creix l’esforç de prova necessari 3.6. Procés de mesura Ha de ser automàtic. Existeixen eines, però són complexes o cares. Les dades es recullen durant el projecte, no al final No s’han de recollir més dades de les necessàries ❖ Preguntes més probables d’examen: Pesos, Fin, Fout , Compte de línies, ultimes... Abre tu Cuenta NoCuenta con el código WUOLAH10 y llévate 10 € al hacer tu primer pago a64b0469ff35958ef4ab887a898bd50bdfbbe91a-11368059 WebPerformance Testing 1. Definicions Performance testing: Rendiment, velocitat, … Load testing: Capacitat de càrrega Factors que afecten al Client performance? Condicions de la xarxa Recursos necessaris Execució de scripts (número, bugs, velocitat, dades …) Rendering d’imatges Performance del server Factors que afecten al Server performance? Configuració del host (memoria, cloud, connexió DB, …) Data acces (DB, cached, …) Third party services Computing requirements (processos, calculs, …) Client load (numero de clients) ➔ Perfomance i Load testing van junts Un client eficient (amb cache) pot reduir el load del server Un server eficient pot augmentar el seu load 2. Eines i exemple Performance Testing Què hem de tenir en compte al fer testing? Quan és visible la pàgina? Quan es pot utilitzar (quan l’usuari hi pot interaccionar) Com es gestionen els recursos (càrrega d’imatges, scripts…) Quan scripting hi ha? S’optimitza la utilització de la xarxa? (d’on es carreguen les imatges?, del server o d’un altre servidor?) 3. Eines Load Testing Testegen la càrrega en el server Open source, comercials Locals, cloud UI, script Eines molt complexes. Permeten simular: Nombre de connexions Distribució temporal de connexions Tipus de connexió Jmeter 4. Resum Per client i server, testejar aviat i freqüentment. Assegurar-se que el client es pot adaptar a diferents situacions del server i la xarxa. Trobar els límits de performance del server. Assegurar-se que l’aplicació està preparada per a les “masses”. Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. a64b0469ff35958ef4ab887a898bd50bdfbbe91a-11368059 Revisions tècniques formals (RTF) 1. Introducció - Revisions tècniques formals Revisió tècnica: Activitat de grup destinada a examinar si un producte o procés és correcte Missió: trobar defectes, MAI trobar culpables Les persones del grup són expertes en el tema a examen Cada persona assumeix un (o diversos) rol concret Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. Per què es fan? per poder detectar defectes sense haver d’esperar a poder executar codi per detectar defectes/errors al més aviat possible, quan el cost de reparació és menor perquè altres persones tenen visions complementàries a la nostra: detecció de defectes més efectiva Tipus principals de revisions tècniques: Peer-review Walk-through o Discussió informal sobre un artefacte de SW. o Pot incloure una discussió sobre com corregir els errors. Revisions o inspeccions tècniques formals o Discussió formal. Existeix un procediment i uns rols definits per als participants. o Només detecció de defectes, no resolució. o Resolucions per majoria i de compliment obligat. Errors: És interessant detectar-los el més a prop possible d’on es produeixen (sobretot, en captura de requeriments, d’anàlisi i de disseny). o El cost d’un error (p. Ex.) de disseny augmenta durant el desenvolupament del SW (basat en experiència de projectes grans) o Entre el 50 - 60 % dels errors s’introdueixen en la fase de disseny. o Efectivitat RTF ~ 75% 2. Rols Responsable (cap de projecte): Demana una RTF al productor. Participa però no intervé. No es considera un rol ni un participant de la RTF. Rols dels participants Moderador: o Organitza la RTF. Responsable que es segueixin els passos i directrius de la RTF. Productor: o Pot demanar la RTF. El seu treball és el que s’avalua a la RTF. Dona aclariments (no justificacions!). Vocal (reader): o Enumera els aspectes que es revisen en la RTF. Marca el ritme. Transcriptor: o Fa un resum de la RTF i anota els defectes trobats. Revisor (els dos anteriors i el moderador també ho poden ser): o Revisen a fons el treball fet pel productor. Abre tu Cuenta NoCuenta con el código WUOLAH10 y llévate 10 € al hacer tu primer pago a64b0469ff35958ef4ab887a898bd50bdfbbe91a-11368059 2.1. Directrius Definir criteris per proposar una RTF: o Pocs criteris → massa errors i poca eficiència o Molts criteris → massa lents Tenir una checklist (per cada rol) o Orienten el procés de revisió Revisar el producte, NO el Productor!!!! Mai qüestionar-lo!! o Una bona actitud és fer preguntes que el faci veure els errors, però no donar-li la culpa. Reservados todos los derechos. No se permite la explotación económica ni la transformación de esta obra. Queda permitida la impresión en su totalidad. El Productor dona aclariments: o Diu què i com és alguna cosa, NO per què ho ha fet així. Temps dels Revisors: o Han de tenir un temps prudencial d’acord amb la càrrega a revisar. Duració màxima: 2 hores!!! Objectiu clar: o Trobar errors, NO corregir-los!!! 3. Procediment 1. El Moderador convoca amb temps suficient als futurs assistents a la RTF, i els lliura el material necessari: document(s) a revisar + checklists 2. Els Revisors revisen aquest material 3. Durant la RTF: a) El Moderador demana als Revisors si estan preparats (També pot preguntar quant temps s’ha dedicat a fer la revisió) b) El Vocal (reader) diu quin és el primer bloc a inspeccionar (línies de codi, text, disseny, etc) c) El Moderador demana potencials defectes als Revisors. Es discuteix sobre cadascun d’ells fins a arribar a un consens (és un error o no?, de quin tipus? …) El Productor no té vot!!! d) El Transcriptor ho registra en un imprès. e) Es torna al pas b) fins a acabar tots els errors. f) Abans d’acabar el Moderador demana al Transcriptor que repassi en veu alta tots els errors trobats. g) L’equip decideix què fer. L’artefacte “passa” el test?, passa amb correccions menors?, o és necessària una altra RTF? Què es pot sotmetre a una RTF? Pràcticament tot!!! Document captura de requeriments: especificació de casos d’ús, requeriments no funcionals … Documents de disseny: diagrames UML de classes, activitats, estats, arquitectura de sistema … Codi font Pla de proves, documents, especificació de proves … Etc … Abre tu Cuenta NoCuenta con el código WUOLAH10 y llévate 10 € al hacer tu primer pago