Tema 6: Qualitat del Software (2017)

Apunte Catalán
Universidad Universidad Autónoma de Barcelona (UAB)
Grado Ingeniería Informática - 2º curso
Asignatura Enginyeria del software
Año del apunte 2017
Páginas 8
Fecha de subida 10/06/2017
Descargas 1
Subido por

Vista previa del texto

TEMA 6 QUALITAT DEL SOFTWARE 1. INTRODUCCIÓ Prova: avaluació d’un sistema de forma anual o automàtica per tal de verificar que satisfà els requisits especificats.
- - Importància: o És impossible desenvolupar software sense errors (durant l’especificació, disseny, codificació o integració).
o El cost dels errors és molt gran (representa un 40% de l’esforç de desenvolupament en projectes normals i fins al 80% en sistemes crítics (control trànsit aeri, equips mèdics, etc.).
Objectius: o Descobrir errors (com més i més greus millor, de diferents tipus amb el menor esforç i temps possible).
o Un cas de prova és bo si té una alta probabilitat de detectar un error nou.
o La prova té èxit si troba errors.
o La prova no pot assegurar l’absència d’errors, només demostrar que n’hi ha.
Cicle de vida estàndard de desenvolupament del software: Requeriments Disseny Implementació Proves Redacció manual usuari Redacció manual tècnic Implantació Les proves permeten executar un sistema (o algunes de les seves parts) en un entorn controlat per detectar desviacions i comprovar si es compleixen els criteris d’acceptació.
Desviacions en els resultats observats indica un error (bug) de disseny o implementació.
Activitats de les proves: o Definició dels casos de prova o Execució de les proves La majoria dels defectes tenen la seva causa en una mala definició dels requeriments. El cost de corregir un error és més barat com més aviat es trobi.
Cicle de vida de desenvolupament del software amb proves integrades: 2. DISSENY DE CASOS DE PROVA Les principals activitats són: - Definició de casos de prova: es defineix quines propietats del sistema es provaran i com es provaran. Resultat => conjunt de casos de prova.
Execució de les proves: s’executa el sistema per cada cas de prova i s’avalua la desviació de la sortida esperada respecte la obtinguda. Aquesta activitat també és coneix amb terme genèric “Prova de software) o Prova de software: execució sistemàtica d’una unitat de software, objecte de prova, amb l’ànim de detectar errors.
Limitació de les proves: és quasi impossible provar totes les condicions d’entrada i sortida, per això, cal seleccionar bé els casos de prova per cobrir al màxim de situacions possibles.
Nivell de les proves (Model en V): N’hi ha 2 classes de proves: 1) Prova de CAIXA NEGRA: consisteix en fer proves per veure si totes les funcions són operatives, tenint en compte les especificacions. No té en compte l’estructura interna del sistema. En el cas del software la prova es centra en els requeriments: a. Funcions incorrectes b. Errors d’interfície, rendiment, inicialització, finalització.
c. Errors en estructures de dades o accés a la BD externes 2) Prova de CAIXA BLANCA: consisteix en fer proves per veure que “totes les peces encaixen”, coneixent l’estructura interna del sistema. En el cas del software, la prova es centra en examinar els diferents camins d’execució: a. Garantir que s’executa almenys una vegada totes les línies de codi.
b. Portar fins al límit l’execució dels bucles.
c. Garantir que totes les estructures de dades són utilitzades.
d. Garantir que el sistema és portat a tots els estats.
e. Garantir que s’executa el mecanisme d’excepcions.
No ens podem limitar només a fer proves de caixa blanca, ja que aquesta prova executa tots els camins possibles d’execució i això ens inviable. Ens hem de limitar a executar els camins més importants o els camins suficients per cobrir totes les sentències.
Proves de caixa blanca: camins bàsics Passos a seguir: 1) 2) 3) 4) 5) Representar el flux de control mitjançant un graf Comptar el nombre de camins bàsics independents Trobar un possible conjunt d’aquests camins Determinar un cas de prova que ens porti per cada camí Executar el codi comprovant si el resultat és o no l’esperat 1. Representar el flux de control mitjançant un graf de flux G Representacions en graf del flux de control: Exemple: Exemple: ordenació en pseudo-codi Hi ha tancaments que es poden ajuntar entre ells, ja que un node pot representar una o més sentències i, opcionalment, incloure un punt de decisió.
2. Comptar el nombre de camins bàsics independents: complexitat ciclomàtica V(G) Complexitat ciclomàtica: mètrica del software que proporciona una mesura quantitativa de la complexitat lògica d’un programa.
Camí d’execució independent: qualsevol camí del programa que introdueixi almenys un nou conjunt de sentències en l’execució o una nova condició.
Per calcular V(G) podem fer servir les diferents formes: 1) V(G) = nº de regions del graf 2) V(G) = nº d’arcs – nº de nodes + 2 3) V(G) = nº de nodes condició + 1 3. Trobar un possible conjunt de camins independents amb cardinalitat V(G) Possibles camins independents: - Camí 1 => 01-02-03-07-01-08 - Camí 2 => 01-02-04-06-07-01-08 - Camí 3 => 01-02-04-05-07-01-08 - Camí 4 => 01-02-03-07-01-02-04-06-07-01-08 (Aquest no seria un camí independent, ja que no introdueix una nova aresta.
4. Determinar un cas de prova per a cada camí independent Forçar els valors de variables de forma que l’execució del programa recorri el camí donat. Per fer-ho, en primer lloc, s’ha d’identificar els nodes condició.
5. Executar el codi comprovant si el resultat és o no l’esperat Durant el disseny dels casos de prova cal anotar els resultats esperats de ‘execució de la prova per fer una comparació amb els resultats obtinguts. En alguns casos, aquesta comparació es pot fer de forma automatitzada, per això cal un Ground Truth: - Conjunt d’entrades de les proves Conjunt de sortides esperades Mesura d’avaluació del rendiment (ex: nº resultats correctes / nº d’execucions) Representació d’un graf amb matriu d’adjacència: El procediment per obtenir el graf de flux i el conjunt de camins bàsics pot obtenir-se mitjançant una matriu d’adjacència del graf, utilitzant l’algorisme de Dijkstra.
𝛼, 𝛽, 𝛾, 𝛿, 𝜀, f, c, són pesos (ex: 𝛼 és el pes per anar des del node 01 al node 02.
Aquests pesos poden mesurar propietats interessants com: - Probabilitat d’execució Temps de processament Memòria necessària Recursos necessaris Matrius de connexions (1 (connexió) / 0 (no connexió)) Proves dels bucles: prova que es centra en la validesa de les construccions dels bucles.
Distingim 4 classes diferents de bucles: - Simples Niats Concatenats No estructurats Bucle simple Conjunt de proves: 1) Passar per alt el bucle 2) Passar només 1 vegada 3) Passar 2 vegades pel bucle 4) Fer m passos pel bucle m<n 5) Fer n-1, n i n+1 passos pel bucle Conjunt de proves: 1) Començar fent les proves del bucle simple amb el més intern.
2) Progressar cap a fora de la mateixa manera.
Bucle niat Bucles concatenats: si són bucles independents es poden fer proves de bucle simple, si no, fer proves de bucles niats.
Bucles no estructurats: mai es pot donar aquest cas, si es dona cal tornar a dissenyar com a bucle estructurat.
Prova de partició equivalent: consisteix en fer una partició de l’espai de possibles entrades del programa en classes equivalents respecte d’algun criteri.
Ex: sqrt(x): x>=0 classe vàlida; x<0 classe no vàlida.
3. ESTRATÈGIA DE PROVA Existeixen diferents nivells de les proves: o o o o Proves de components (o d’unitat) Proves d’integració Proves de sistema Proves d’acceptació Proves de components (o d’unitat) Prova de verificació dels mòduls, amb un component principal de caixa blanca a diferents nivells de detall on es proven: interfície del mòdul, estructures de dades locals, camins independents, condicions límit.
Pot requerir influir mòduls simulats com controladors (divers).
Proves d’unitat S’ha de verificar que la implementació d’una classe correspon a la seva especificació Procés: 1) Identificar casos de prova 2) Implementar un “test driver” que executi cadascun dels casos de prova, reculli els resultats i els compari amb els resultats esperats segons especif.
Proves d’integració Tècnica per construir el programa a partir dels mòduls a l’hora que es van duent a terme proves per detectar errors => integració incremental.
La integració incremental requereix la creació de controladors i resguards i pot ser de 2 tipus: descendent o ascendent. En tots dos es fan servir tècniques de caixa blanca i negra.
Proves de sistema Es prova el sistema comprovant si hi ha desviacions del seu comportament respecte dels requeriments. Quan el software és només una component d’un sistema més complex es fan proves de: recuperació, seguretat, resistència i rendiment.
Proves d’acceptació Es comprova si es proporcionen els serveis que el client i el desenvolupador van acordar. Inclou diferents proves individuals com: - - Proves de camp: es prova una versió beta en condicions reals.
Proves d’acceptació de l’usuari: els usuaris reals proves el sistema.
o Proves alfa: es duen a terme al lloc del desenvolupament, permet als desenvolupadors observar la prova (entorn controlat).
o Proves beta: es duen a terme al lloc de treball de l’usuari, són els usuaris qui registren els problemes observats (entorn no controlat).
Acceptació respecte el contracte: es proven les condicions incloses en el contracte per obtenir l’acceptació per part del client.
4. DEFINICIÓ DE CASOS DE PROVES BASADA EN REQUERIMENTS Els casos de proves es poden definir seguint 2 enfocaments: 1) Definició basada en el codi: l’estructura del codi font serveix com a referència (caixa blanca).
2) Definició basada en les especificacions: es consideren les entrades i sortides, no la implementació (caixa negra).
Escenaris de casos de proves: especifica interaccions a diferents nivells d’abstracció com tipus d’entrades i sortides esperades, i les interaccions entre els tipus d’actors implicats en la prova.
Tipus d’escenaris: - - Interns al sistema: proves de components i d’integració.
D’interacció: proves de sistema (interaccions del sistema amb usuaris o altres sistemes).
Context: proves d’acceptació.
N’hi ha dos tipus de definicions de casos de prova basada en requeriments: 1) Derivació directa: dels casos de prova a partir dels requeriments.
2) Derivació basada en models Derivació directa Consisteix en fer una partició de l’espai de possibles entrades del programa en classes equivalents respecte d’algun criteri (entrada vàlida, no vàlida, etc).
Derivació basada en models Quan els requeriments s’han especificat amb eines de modelat (UML), poden utilitzarse com a models de prova.
...

Comprar Previsualizar