Resum part 2 (2014)

Resumen Catalán
Universidad Universidad Autónoma de Barcelona (UAB)
Grado Ingeniería Informática - 3º curso
Asignatura Test i Qualitat del Software
Año del apunte 2014
Páginas 14
Fecha de subida 11/11/2015
Descargas 15
Subido por

Descripción

resum part 1 de Test i Qualitat del Software

Vista previa del texto

TEMA 6: TEST AUTOMATION Introducció Test automation: es el procés d’automatitzar les proves de regressió Avantatges:  Reduir l’esforç necessari per fer test  Augmentar el nombre de tests a executar en un temps limitat (pot estalviar un 80% del test manual)  Aspectes que defineixen la qualitat d’un test case:  Efectivitat en la detecció de defectes  Exemplaritat (testejar més d’una cosa a la vegada)  Economia (esforç i recursos per executar-lo)  Mantenibilitat expansió (quan es modifica el SW)  Avantatges:  Executar tests de regressió  Més tests en menys temps  Generar més seguretat en el SW  Executar test impossibles d’executar manualment: 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 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  Porta fàcilment a fer mals testos: o Es preferible millorar l’efectivitat del test que no la de l’automatització  Creure que l’automatització 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  Manteniment no sempre és fàcil (canviar el SW pot significar canviar el test) L’AUTOMATITZACIÓ NO SEMPRE ES BONA! Tipus d’eines d’automatització dels tests inputs:  Code-based: paràmetres per executar un path, ...
 Interface-based: En una GUI es poden visitar tots els objectes sensibles, visitar tots els links d’una pagina web, ...
 Specification-based: A partir de llenguatge natural poden generar inputs i els outputs corresponents: valors límit, particions equivalents, ..
ES PODEN AUTOMATITZAR LES PORVES DE CAIXA NEGRA! Limitacions del automated testing:  NO substitueix el manual testing o Hi ha testing que mai es podrà realitzar de forma automàtica o Nomes 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...
o Interacció amb hardware  Si el SW es inestable  Manual testing  Manual testing (85% errors) / Automated testing (15%)  No millora l’efectivitat del test (no troba més ni millors errors)  Les eines NO són Inteligents: o Un usuari pot veure que el comportament del SW és incorrecte tot i que els outputs siguin els esperats Scripting    Tipus   L’automatització és fàcil amb scripting, però es avorrida i pesada Avantatges de l’scripting detallat: o Testers executen sempre el mateix test o Errors de SW més fàcils de reproduir o Qualsevol pot executar el test (programadors, testers,...) o Fàcil d’automatitzar Desavantatges: o Dificil de crear o Molt texte/instruccions redundant o Es verbose o Avorrit d’executar (el tester no fa gran cosa excepte mirar) o Overhead de feina  Esforç per crear el script  La informació esta documentada dos cops (a la descripció del test i al script)  Informacio hauria de ser legible per humans i per l’eina de test Manual scripts o Escrits per usuaris humans  Solen ser legibles  Serveixen com a documentació Automated scripts o Creats per un SW  Dficils de llegir  Si són creats perquè s’ha fet recordin, tenen una utilitat limitada Recording: Procés de gravació de les accions realitzades per l’usuari  Desavantatges: o Solen crear scripts il·legibles o Nomes son útils si s’han de re-executar o Molt centrats en aspectes específics fàcilment volàtils:  Posició en la pantalla, bitmaps, cadenes de caràcters,...
o Si el SW canvia mínimament el script pot fàcilment deixar de funcionar NO automatitzar testing fent recordin!  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 Si volem fer automated testing, hem de fer automated comparison Outcome Conmparison Tipus:  Dynamic comparison o Realitzat DURANT l’execució del test o Com es compara ho decideix el tester (imatges, llistes, element dins una llista...)  Post-execution comparison o Realitzat DESPRES de l’execució del test o Tècniques d’scripting: Linear scripts  Es la sortida típica d’un software de recordin: caràcters, posicions del mouse...
 Pot incloure comparisons  Avantatges: o No es necessita un pla previ d’execució del test o Des del primer moment es pot fer automating o L’usuari no cal que sigui programador (d’scripts) o Es molt útil per fer demos  Quan utilitzar-lo o Per quasi qualsevol tasca repetitiva o Per automatitzar el set-up i clean-up o Omplir un fitxer o una base de dades o Repetir un input o Fer conversions  Desavantatges: o Es un procés intensiu i laboriós (de 2 a 10 cops el que costa executar un test manual) o Els inputs i les comparisons estan hard-coded en el script o No es reutilitzable o Vulnerable als canvis en el SW o Difícil de modificar o Es impràctic a llarg termini i mer fer molts test Structured scripting  Conte instruccions i estructures de control: o Seqüencies: instruccions d’execució o Seleccions: Decisions (“if”) o Interaccions: Bucles Shared Script  Script utilitzats per més d’un test  Avantatges: o Menys esforç per implementar un test o Manteniment inferior al de un linear script o Elimina repeticions o Es bò per sistemes petits (PC) o per provar una part petita d’un SW  Desavantatges: o Molts scripts a utilitzar o Manteniment encara relativament alt Data-driven script  Les dades es guarden en un fitxer a part  L’estructura de control es troba en el script  Avantatges: o El mateix script pot servir per molts tests (canviant les dades) Automated comparison  Verification: es el procés de chequejar els outcomes a través d’una comparison  Tipus: Dynamic i post-execution  Per què comprar automàticament? o Una comparació es probablement una tasca molt automatitzable o Sense automated comparison no tenim automated testing  Simple comparison o Comparació EXACTA del outcome i resultat esperat  Complex comparison o Comparació amb diferencies esperades: output amb ordre diferent, diferencies dins d’un rang...
 Quanta informació s’ha de comparar? o Molta: serem molt sensibles a petits canvis o Poca: mes robust, però menys acurat  Filtres: o Es un pas de edició o transformació: eliminació de dades, extracció, conversió...
o S’apliquen tan als outcomes com als resultats esperats  Avantatges: o Reutilitzables o Criteri de comparació específic o Outcomes complexes poden ser analitzats per eines simples Altres     Quins tests hem d’automatitzar primer? o Repetitius i human error-prone o Testing funcional (que fa el SW)  Test Driven Development o Els mes importats o Els que s’executen mes cops o Els mes 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 first time,..) Designing SW for (automated) testability o De manera similar al TDD, podem desenvolupar el codi tenint en ment la manera en que farem el test  en podríem dir ATDD TEMA 7: MOCK OBJECTS Introducció Mock object: is an object created to stand in for an object that your code will be collaborating with. Your code can call methods on the mock object, wich will deliver results as set up by your tests.
Característiques:  Substitueixen els objectes amb els que interactua el SUT  Ofereixen una capa d’aillament  No implementen cap lògica de funcionalitat (excepte la mínima)  Son capes buides que proveeixen mètodes amb els que interactual el SUT  Son una “mentida”, una façana Exemple Volem desenvolupar codi de test (d’unitat) pel mètode AccountService.transfer()  Per quina classe necessitem un mock object? o AccountManager: es qui gestiona i necessita una DB que funcioni  Declaració de la classe AccountManager  Definició de la classe AccountService  Definició del mock MockAccountManager  Codi test Refactoring i Torjan Horses Refactoring: Abans hem utilitzat els mock objects segons el pattern Inversion of Control (IOC):  Externalització de la creació dels objectes necessaris (no es creen dins la classe)  Enviament a la classe a través de mètodes (constructors, setters, …).
Suposem el següent codi: Utilitzem mock objects i Inversion of Control IOC i això ens permetrà fer: Trojan Horse: Expectation: Caracterísitca d’un mock que comprova si el comportament d’un SUT és el correcte  Exemples: A través d’un mock podem comprovar si o AccountManager crida al metode close cada cop que acaba de fer una consulta a una base de dades o Un mètode obre un fitxer en disc i al final el tanca o (en C++) alocació i desalocació de memòria...
Best practices Quan utilitzar mock objects:  L’objecte real te un comportament no determinista  L’objecte real és difícil de configurar  L’objecte real és difícil de portar a un estat (network error)  L’objecte real és lent  L’objecte real és una API o UI  L’objecte real encara no existeix! - NO escriure logica de funcionament dins un mock - Només ha de fer el que el codi de test li diu que ha de fer - S’han de poder generar facilment - Són facilment “trencables” (breakable). NO necessiten testing! Avantatges dels mock objects:  Fer test sense esperar SW extern  Evitar problemes o efectes secundaris d’objectes externs  Permeten fer refactoring  Permeten comprobar patterns de comportament del SUT correctes TEMA 8: CAIXA BLANCA Caixa blanca: Testing que analiza i té en compte l’estructura interna del sistema. Analitza mòduls, funcions, blocs, sentencies, cobertura del codi, ...
No sempre executem TOT el codi quan executem tot els test case.
Control flow (camins bàsics) Tipus:  Statement coverage: totes les sentències s’executen com a mínim un cop.
 Decision (branch) coverage: totes les decisions (p.ex. condicionals) prenen els valors true o false.
 Condition coverage: totes les condicions (predicats) que formen l’expressió lògica d’una decisió prenen els valors true o false.
o Composed condition ((X and Y) or C): els casos de prova han de cobrir tots els valors true o false de cada condició de l’expressió lògica.
o Simple condition (A): Degenera a decision coverage (però simple condition coverage no assegura decision coverage)  Path coverage: s’executen tots els path.
o Errors lògics i assumpcions incorrectes són inversament proporcionals a la probabilitat d’execució del path.
o És probable que un path no testejat contingui errors o El testing exhaustiu NO és possible o Passos per realitzar-lo:  Convertir el codi (o unitat) en un flow graph (diagrama de fluxe)  Calcular una mesura de la complexitat lògica de la unitat.
 Utilitzar la mesura per derivar un conjunt “bàsic” de paths independents i definir els seus test cases.
o El conjunt de paths per fer path coverage NO és únic! o Complexitat ciclomàtica  És una mètrica, V(G), que descriu la complexitat lògica d’un diagrama de fluxe (flow graph), G.
 V(G) està directament relacionat al nombre d’errors  V(G)=10 és un límit superior pràctic a l’hora de fer el testing Loop testing: Loop simple:  Test cases o Evitar el loop o Una passada pel loop o Dues passades pel loop o m passades pel loop m<n o (n-1), n, (n+1) passades pel loop on n és el nombre màxim possible de passades Pregunta: Aquest esquema equival a? Valors límit pel nombre de passades pel loop Loops aniuats:     Si extenem el test pel loop simple  explosió en el nombre de tests Reduim el nombre de tests o Començar amb un test simple pel loop més interior, fixant els demés loops al valor mínim Testejar un loop més extern (com si fos un loop simple) mantenint el nombre d’iteracions dels loops interiors a valors habituals.
Continuar fins testejar tots els loops..
Data flow (cadenes definició-ús) Definicions: V: conjunt de variables N: conjunt de nodes E: conjunt d’arcs Definició/escriptura de variables (n): def(i) = {x en V | x té una definició en el bloc i} Ús computacional de variables (n) c-use(i) = { x en V | x té un c-use al bloc i} Predicat de variable (arc) - p-use(i,j) = {x en V | x té un p-use a l’arc (i,j)} objectiu: - Cobrir els path que van de la definició de la variable a la seva utilització.
Exemples: - Un path per def (all-defs) - Un path per definició a tots els c-uses (all-c-uses) - Un path per definició a tots els p-uses (all-p-uses) - Un path per definició a tots els c-uses i p-uses (all-uses) - Tots els path (sense loops) de definició a tots els p-uses i cuses (all du-paths) Tipus de data flow testing:  All-defs: Test cases cobreixen cada definició de cada variable per al menys una utilització de la variable.
 All c-uses: Hi ha al menys un path de cada definició de variable a cada c-use.
 All p-uses: Hi ha al menys un path de cada definició de variable a cada p-use.
 All c-uses/some-p-uses: Igual que all c-uses, pero si hi ha variables no cobertes s’utilitzen p-uses.
 All p-uses/some-c-uses: Igual que all p-uses, pero si hi ha variables no cobertes s’utilitzen c-uses.
 All uses: Hi ha al menys un path de cada definició de variable a cada ùs (p-use i c-use)  All-du paths: Tots els possibles path de cada definció de cada variable a cada ús sense considerar els loops.
Si el temps és un problema:  Utilitzar all p-uses en comptes de all-uses  Utilitzar all-uses en comptes de all-dupaths  A la pràctica, all-dupaths és el més pràtic TEMA 9: REVISIONS TÈCNIQUES FORMALS (RTF) Introducció 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 Per què es fan?  per poder detectar defectes sense haver d’esperar a poder executar codi  per detectar defectes/errors el 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 o É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).
 El cost d’un error (p.ex.) de disseny augmenta durant el desenvolupament del SW (basat en experiència de projectes grans)  Entre el 50 - 60 % dels errors s’introdueixen en la fase de disseny.
 Efectivitat RTF 75%  Rols Moderador:  Organitza la RTF. Responsable que es segueixin els passos i directrius de la RTF.
Productor:  Demana la RTF. El seu treball és el que s’avalua a la RTF. Dona aclariments (no justificacions!).
Responsable (cap de projecte):  Demana una RTF al productor. Participa però no intervé.
Vocal (reader):  Enumera els aspectes que es revisen en la RTF. Marca el ritme.
Transcriptor:  Fa un resum de la RTF i anota els defectes trobats.
Revisor (els dos anteriors també ho són):  Revisen a fons el treball fet pel productor.
Directrius:   Definir criteris per proposar una RTF: o Poques  massa errors i poca eficiència o Moltes massa lent 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.
 El Productor dona aclaracions: 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 Trobat errors, NO corregir-los!!! 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: o a) El Moderador demana als Revisors si estan preparats (També pot preguntar quant temps s’ha dedicat a fer la revisió) o b) El Vocal (reader) diu quin és el primer bloc a inspeccionar (linies de codi, texte, disseny, etc) o c) El Moderador demana potencials defectes als Revisors. Es discuteix sobre cadascun d’ells fins arribar a un consens (és un error o no?, de quin tipus? …) El Productor no té vot !!! o d) El Transcriptor ho registra en un imprès.
o e) Es torna al pas 2 fins acabar tots els errors.
o f) Abans d’acabar el Moderador demana al Transcriptor que repassi en veu alta tots els errors trobats.
o g) L’equip decideix que fer. L’artefacte “passa” el test?, passa amb correccions menors?, o és necessaria una altra RTF? Què es pot sotmetre a una RTF? Pràcticament tot  Document captura de requeriments: especifiació 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 … TEMA 10: SOFTWARE QUALITY ASSURANCE (SQA) Introducció Objectiu de la enginyeria del software:  Software 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  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 Standards Defineixen característiques de:  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) o Segueix les mateixes pràctiques.
  Afavoreix la continuïtat de la feina quan algú abandona un projecte  Redueix esforç d’aprenentatge o Es comunica, coordina i entén millor Desavantatges:  Costosos de desenvolupar  Cal recórrer a estàndards 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.
Quality Metrics Una mesura quantitativa del grau en què un element posseeix un cert grau de Qualitat respecte algun aspecte (p ex. fiabilitat, reusabilitat, portabilitat …).
Una funció:  Input: Dades sobre el SW  Output: Valor numèric (que és la mesura quantitativa anterior) 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 el 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.
Requeriments:  Generals: o Rellevant o Vàlid o Fiable o Entenible o Mutualment exclusiva amb altres mètriques  Operatius: o Fàcil i simple o Inmune a intervencions esbiaixades per usuaris interessats Desavantatges:  No existeix una mètrica global per a tot  Es limiten a certs aspectes  No hi ha un acord sobre quines són les millors  Moltes prenen significat només quan es comparen amb els valors per a altres projectes  Es poden veure afectades per diferents factors (estil de codi, complexitat del codi, percentatge de codi reutilitzat, volum de documentatió, …) 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 Procés de mesura  Ha de ser automàtic. Existeixen eines, pero 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 ...

Comprar Previsualizar