Proves de programari
| Tipus | control de qualitat del programari i tipus de prova  |
|---|---|
| Part de | enginyeria de programari, gestió de qualitat i IEEE 1012 |
Les proves de programari o proves de software és un procés o investigació dut a terme per a proporcionar als responsables d'un producte o servei informació sobre qualitat del producte o servei que s'està provant.[1]
Glenford J. Myers va definir el terme al seu llibre "The Art of Software Testing", com «el procés d'execució d'un programa o sistema amb la intenció de trobar errors» i William C. Hetzel ho va fer com «qualsevol activitat destinada a l'avaluació d'un atribut o la capacitat d'un programa o sistema i la determinació de que aquesta compleix els resultats requerits»[2]
El programari no difereix molt de la resta de processos físics on es reben unes entrades i es produeixen unes sortides. On el programari es diferencia és amb la manera com falla. La majoria dels sistemes físics fallen d'una manera fixa (o amb variabilitat força baixa). Per contra, el programari pot fallar de moltes formes estranyes, i són les proves de programari les encarregades de detectar aquestes errades, tot i que detectar totes les diferents formes en les que pot fallar el programari no és factible.
Una pràctica comuna és que el procés de proves d'un programa sigui realitzat per un grup independent de "betatesters" en finalitzar el seu desenvolupament i abans de treure'l al mercat.
Una pràctica que ja és molt popular és distribuir de franc una versió no final del producte perquè siguin els mateixos consumidors els que la provin. En ambdós casos, la versió del producte en proves i que és anterior al final s'anomena beta, i a aquesta fase de proves, beta testing. Pot a més existir una versió anterior en el procés de desenvolupament anomenada alpha, en la qual el programa, encara que incomplet, disposa de funcionalitats bàsiques i pot ser testejat.
Finalment i abans de sortir al mercat, és cada vegada més habitual que es faci una fase de RTM testing (Release To Market), on es comprova cada funcionalitat del programa complet en entorns de producció. Una altra pràctica és que el procés de proves es realitzi des del mateix moment en què comença el desenvolupament i continuï fins que finalitza utilitzant un disseny en V.
Temes principals
[modifica]Àmbit d'aplicació
[modifica]L'objectiu principal de la prova és detectar fallades de programari per tal que els defectes pouguin ser descoberts i corregits. Aquesta és una activitat no trivial. Les proves no poden demostrar que el producte funciona correctament en totes les condicions, però sí que poden assegurar el seu correcte funcionament en condicions específiques. L'àmbit d'aplicació de proves de programari sovint inclou l'examen del codi, així com l'execució d'aquest codi en diversos ambients i condicionsi: fa el que se suposa que ha de fer. La informació derivada de les proves de programari es pot utilitzar per corregir el procés pel qual es desenvolupa el programari.
Tipus de prova
[modifica]Existeix molt de programari i cada part de codi s'ha d'examinar d'una manera específica, ja que no es pot comprovar la funcionalitat d'un programari que respon a uns determinats arguments de tipus enter amb arguments de tipus caràcter. Però en aquest apartat, ens referim a programari extens, on és necessari dividir el programari en diferents mòduls o components i aïllar-los per comprovar-ne la funcionalitat.
Dins l'enginyeria del software diferenciem entre el component a examinar, conegut pel nom de fixture, el codi necessari per cridar o invocar el component, amb el nom de test driver, i el codi necessari per simular els components requerits en l'execució del component, conegut per test stub. Les classes i objectes utilitzats en el test driver i el test stub, els agrupem en el que anomenem Mock Objects.
Proves dinàmiques i estàtiques
[modifica]Les proves estàtiques són aquelles que es realitzen implícitament mitjançant l'ús de validadors de codi que comproven la seva correcció (abans de realitzar proves compilades o de compilar). El cas del testeig dinàmic, és el que utilitzem quan dividim el programari en parts raonablement petites i el provem utilitzant stubs. D'aquesta manera podem arribar a provar el 100% del programari així com possibles extensions d'aquest de manera aïllada.
L'aproximació de la caixa
[modifica]S'han desenvolupat dos mètodes per examinar el programari. Per un costat el mètode de l'aproximació sobre caixa negra, que tracta el programari des de la vista d'un usuari, i l'altre sobre caixa blanca, que tracta el programari des de la vista d'un programador.
Aproximació a la caixa blanca
[modifica]També conegut amb els sobrenoms de caixa transparent o caixa de vidre, aquest mètode treballa sobre els mòduls interns en contraposició de la seva funcionalitat principal que seria la de servir a un usuari.
Sempre s'intenta fer els recorreguts corresponents sobre el programari a partir d'entrades concretes. Sabent com reaccionarà el programari i comprovant que la sortida és la que toca.
Aquest mètode requereix fer tot un programari igual o més complex per testejar, de manera que només s'utilitza en casos de comprovació global del codi (procurar que s'executi tot almenys una vegada) o bé, en les primeres etapes de programació del programari.
Aproximació a la caixa negra
[modifica]Com tothom sap, una caixa negra és una caixa en què, en donar-li una informació, no saps el que passa dins i, al final, reps una resposta. En el cas d'aquest mètode, creem un programari que utilitzi les funcionalitats especificades simulant un usuari. D'aquesta manera comprovem la funcionalitat final del programari.
La complexitat per dur a terme aquest tipus de prova és baixa a la llarga. És a dir, que per un programari complex i/o extens, aquest mètode és millor que el de la caixa blanca. Però per provar un únic mòdul o un programari de complexitat baixa, ens pot portar problemes.
Nivells de proves
[modifica]En general, hi ha quatre nivells reconeguts de proves: proves unitàries, proves d'integració, proves d'interfície de components, i proves del sistema. Les proves amb freqüència s'agrupen per on s'afegeixen en el procés de desenvolupament de programari, o pel nivell d'especificitat de la prova.
Unit testing
[modifica]Unit testing, també coneguda com la prova de components, es refereix a proves per verificar el funcionament d'una secció específica del codi, en general a nivell de funció. En un entorn orientat a objectes, això és en general a nivell de classe, i les proves unitàries mínimes inclouen els constructors i destructors.
Aquest tipus de proves s'escriuen normalment pels desenvolupadors a mesura que treballen en el codi (estil de caixa blanca), per assegurar que la funció específica està funcionant com s'esperava. Una funció pot tenir múltiples proves, per atrapar casos de cantonada o altres sucursals en el codi. Unit testing per si sol no pot verificar la funcionalitat d'una peça de programari, sinó que s'utilitza per assegurar que els blocs de construcció de l'obra de programari de forma independent l'un de l'altre.
Unit testing és un procés de desenvolupament de programari que consisteix en l'aplicació sincronitzada d'un ampli espectre d'estratègies de prevenció i detecció de defectes per tal de reduir els riscos de desenvolupament de programari, temps i costos. Es porta a terme pel desenvolupador de programari o un enginyer durant la fase de construcció del cicle de vida de desenvolupament de programari. En lloc de reemplaçar QA tradicional enfocat, s'augmenta la mateixa. Unit testing té com a objectiu eliminar els errors de construcció abans que es va promoure codi de control de qualitat; aquesta estratègia es pretén augmentar la qualitat del programari resultant, així com l'eficiència del desenvolupament general i el procés de control de qualitat.
En funció de les expectatives de l'organització per al desenvolupament de programari, proves unitàries podria incloure l'anàlisi estàtic de codi, anàlisi de flux de dades, anàlisi de les mètriques, les revisions de codi de parells, l'anàlisi de cobertura de codi i altres pràctiques de verificació de programari.
Les proves d'integració
[modifica]Les proves d'integració és qualsevol tipus de proves de programari que busca per verificar les interfícies entre els components contra un disseny de programari. Els components de programari es poden integrar de forma iterativa o tots junts ("big bang"). Normalment, el primer es considera una millor pràctica, ja que permet els problemes d'interfície que es troben amb més rapidesa i es van fixar.
Les proves d'integració treballa per exposar els defectes en les interfícies i la interacció entre els components integrats (mòduls). Grups cada vegada més grans de components de programari provades corresponents a elements del disseny arquitectònic s'integren i es proven fins que el programari funciona com un sistema.
Proves de la interfície de components
[modifica]La pràctica de les proves d'interfície de component es pot utilitzar per comprovar el maneig de les dades transmeses entre diferents unitats o components del subsistema, més enllà de les proves d'integració completa entre aquestes unitats. Les dades que es passen es pot considerar com "paquets de missatges" i els tipus de rang o de dades es pot comprovar, per les dades generades a partir d'una unitat, i la prova de validesa abans de passar a una altra unitat. Una de les opcions per a les proves d'interfície és mantenir un fitxer de registre separat dels elements de dades que es passa, sovint amb una marca de temps connectat per permetre l'anàlisi de milers de casos de dades passats entre les unitats durant dies o setmanes. Les proves poden incloure la comprovació del maneig d'alguns valors de les dades extrems, mentre que altres variables de la interfície es passen com a valors normals. Els valors de dades inusuals en una interfície pot ajudar a explicar el rendiment inesperat en la següent unitat. Proves de la interfície de components és una variació de les proves de requadre negre, amb el focus en els valors de les dades més enllà de les accions relacionades d'un component del subsistema.
Les proves del sistema
[modifica]Les proves del sistema, o les proves d'extrem a extrem, posa a prova un sistema completament integrat per verificar que compleix amb els seus requisits.[3] Per exemple, una prova del sistema es vegi involucrat proves d'una interfície d'inici de sessió, i després crear i editar una entrada, a més d'enviar o resultats d'impressió, seguits pel processament de resum o supressió (o arxiu) de les entrades, a continuació, tancament de sessió.
Proves d'Acceptació operacional
[modifica]Acceptació operacional s'utilitza per dur a terme la preparació operacional d'un producte, servei o sistema com a part d'un sistema de gestió de qualitat. OAT és un tipus comú de proves de programari no funcional, que s'utilitza principalment en projectes de desenvolupament de programari i manteniment de programari. Aquest tipus de proves se centra en la disponibilitat operacional del sistema que dona suport, i / o es converteixi en part de l'entorn de producció. Per tant, és també coneguda com la posada a disposició (ORT) o de preparació per a operacions i Assegurament (O & A) proves. Les proves funcionals dins de OAT es limita a aquelles proves que es requereixen per verificar els aspectes no funcionals del sistema.
A més, les proves de programari ha de garantir que la portabilitat del sistema, així com el treball com s'esperava, sinó també danyar o parcialment corrupta seu entorn operatiu o causar altres processos dins d'aquest entorn es converteixi en inoperant
Referències
[modifica]- ↑ Exploratory Testing Arxivat 2009-01-26 a Wayback Machine., Cem Kaner, Florida Institute of Technology, Quality Assurance Institute Worldwide Annual Software Testing Conference, Orlando, FL, November 2006
- ↑ Hetzel, William C. «The sorry state of software practice measurement and evaluation» (en anglès). [Consulta: 2 maig 2020].
- ↑ «8 Functional Testing Types Explained With Examples» (en anglès americà), 27-02-2019. [Consulta: 9 juliol 2021].
Bibliografia
[modifica]Brian Chess, Jacob West (Fortify Software) (2007). Secure Programming with Static Analysis. Addison-Wesley. ISBN 978-0-321-42477-8.
Beizer, B. (1990). Software Testing Techniques. Boston, International Thompson Computer Press. Beizer, B. (1995). Black Box Testing. New York, John Wiley & Sons, Inc. Improving Software Security with Precise Static and Runtime Analysis (PDF), Benjamin Livshits, section 7.3 "Static Techniques for Security". Stanford doctoral thesis, 2006.
Vegeu també
[modifica]Enllaços externs
[modifica]