what is incremental testing
Amb l’ajut d’aquest article, tractaré un dels importants enfocaments d’integració: les proves incrementals.
Al final d'aquesta secció, el públic tindrà un coneixement raonable de:
- Què són les proves incrementals?
- El seu objectiu
- Metodologies
- Avantatges
- Inconvenients
Què aprendreu:
- Què és la prova incremental
Què és la prova incremental
Les proves incrementals, també conegudes com a proves d’integració incremental, són un dels enfocaments de les proves d’integració i incorporen els seus conceptes fonamentals.
És com una prova que combina mòdul i integració estratègia de proves .
En aquesta prova, provem cada mòdul individualment en fase de prova unitària i, a continuació, els mòduls s’integren de forma incremental i es proven per garantir una interfície i una interacció fluïdes entre els mòduls.
En aquest enfocament, cada mòdul es combina de manera incremental, és a dir, un a un fins que tots els mòduls o components s’afegeixen lògicament per fer l’aplicació necessària, en lloc d’integrar tot el sistema alhora i després realitzar proves al producte final. Els mòduls integrats es posen a prova com a grup per assegurar la integració i el flux de dades entre els mòduls.
Igual que a les proves d'integració, el focus principal de fer aquestes proves és comprovar la interfície, els enllaços integrats i el flux d'informació entre mòduls. Aquest procés es repeteix fins que els mòduls es combinen i es proven amb èxit.
Exemple
Entenguem aquest concepte amb un exemple:
El sistema o l’aplicació de programari consisteix en els mòduls següents:
Enfocament de proves d’integració incremental
- Cada mòdul, és a dir, M1, M2, M3, etc. es prova individualment com a part de la prova unitària
- Els mòduls es combinen incrementalment, és a dir, un per un i es posen a prova per obtenir una interacció reeixida
- A la figura 2, es combina i prova el mòdul M1 i el mòdul M2
- A la Fig3, s’afegeix i prova el mòdul M3
- A la Fig4, s’afegeix el mòdul M4 i es fan proves per assegurar-se que tot funciona conjuntament amb èxit
- La resta de mòduls també s’afegeixen de manera incremental a cada pas i es posen a prova per obtenir una integració satisfactòria
Fig2
Fig3
aplicació de rellotge de temps lliure per a PC
Fig4
Objectiu de la prova incremental
- Per garantir que diferents mòduls funcionin junts després de la integració
- Identifiqueu els defectes anteriors i en cada fase. Això proporciona als desenvolupadors un avantatge per identificar on es troba el problema. Igual que si les proves després d’integrar M1 i M2 tenen èxit, però quan s’afegeix M3, la prova falla; això ajudarà el desenvolupador a segregar el problema
- Els problemes es poden solucionar en la fase inicial sense necessitat de reelaboració i amb un cost inferior
Metodologies de proves d’integració incremental
Abans de començar amb aquest tema, m’agradaria fer una breu introducció sobre Butlletins i conductors ja que utilitzarem aquests termes sovint.
Els socs i els controladors són pseudocodi o codi fictici que s’utilitzen a Integració o proves de components quan no es desenvolupen un o més mòduls, però són necessaris per provar algun altre mòdul.
Talons s'utilitzen en l'enfocament de proves de dalt a baix i es coneixen com a 'programes anomenats'. Els trossos ajuden a simular la interfície entre els mòduls de palanca inferior que no estan disponibles ni desenvolupats.
Conductors s'utilitzen en l'enfocament de proves de baix a dalt i es coneixen com a 'programes de trucades'. Els controladors ajuden a simular la interfície entre mòduls de nivell superior que no estan desenvolupats ni estan disponibles.
Una de les qüestions que se’ns pot ocórrer és per què no esperar a que es desenvolupin tots els mòduls d’aplicació en lloc d’utilitzar stub / driver abans de començar la prova?
La resposta senzilla és que augmenta el temps d'execució del projecte, ja que els provadors estaran inactius fins que es desenvolupin tots els mòduls. A més, això dificulta l’anàlisi d’arrels del defecte. Aquest tipus d’enfocament de proves es coneix com a proves d’integració de Big-Bang.
Ara que hem cobert Stubs i conductors, passem a diferents metodologies de proves incrementals:
# 1) De dalt a baix
Com el seu nom indica, les proves es realitzen de dalt a baix, és a dir, des del mòdul central fins al submòdul. Primer es proven els mòduls que emmarquen la capa superior de l’aplicació.
Aquest enfocament segueix el flux estructural de l'aplicació en proves. Els mòduls o components no disponibles o no desenvolupats se substitueixen per talons.
Entenguem això amb un exemple:
- Mòdul : Inici de sessió al lloc web també conegut com L
- Mòdul : Comanda aka O
- Resum de la comanda del mòdul també conegut com a SO (encara no desenvolupat)
- Mòdul : Pagament també conegut com a P
- Mòdul de pagament en efectiu també conegut com CP
- Mòdul Pagament de dèbit / crèdit també conegut com DP (encara no desenvolupat)
- Mòdul Wallet Payment aka WP (encara no desenvolupat)
- Mòdul: Reporting aka R (encara no desenvolupat)
Enfocament de proves d’integració incremental de dalt a baix
Es derivaran els següents casos de prova:
estructura de dades d’arbre c ++
Cas de prova 1: El mòdul L i el mòdul O s’integraran i es provaran
Cas de prova 2: Els mòduls L, O i P seran integrats i provats
Cas de prova 3: Els mòduls L, O, P i R s’integraran i es provaran.
I així successivament es deriven altres casos de prova.
Aquest tipus de proves en què tots els mòduls d'una capa s'integren i comproven per primera vegada es coneix com a 'amplitud'. Una altra categoria és 'profunditat primer'.
Els següents casos de prova es derivaran per a 'profunditat-primer':
Cas de prova 1: El mòdul L i el mòdul O s’integraran i es provaran
Cas de prova 2: El mòdul L, O i OS s’integraran i es provaran
Cas de prova 3: El mòdul L, O, OS, P s’integrarà i es provarà
Cas de prova 4: El mòdul L, O, OS, P, CP s’integrarà i es provarà
I així successivament es deriven altres casos de prova.
Mèrits de la metodologia descendent
- Exposició primerenca de defectes arquitectònics
- Descriu el funcionament d'una aplicació en conjunt en fases inicials i ajuda a la divulgació precoç de defectes de disseny
- Els principals punts de control es proven aviat
De-mèrits de la metodologia descendent
- Els mòduls significatius es proven a finals de cicle
- És molt difícil escriure condicions de prova
- Un taló no és una implementació perfecta del mòdul relacionat. Simula el flux de dades entre dos mòduls
# 2) De baix a dalt
En aquest enfocament, les proves es realitzen de baix a dalt, és a dir, els mòduls de la capa inferior s’integren i comproven primer i després s’integren seqüencialment altres mòduls a mesura que avancem. Els mòduls no disponibles o no desenvolupats són substituïts pels controladors.
Vegem un exemple esmentat a continuació per a una millor comprensió:
Els mòduls de classificació, notes, percentatge i grau esportiu encara no estan desenvolupats, de manera que se substituiran per un conductor relacionat:
Enfocament de proves d’integració incremental de baix cap amunt
Es derivaran els següents casos de prova:
Cas de prova 1: Proves d'unitats del mòdul Pràctic i Teòric
Cas de prova 2: Integració i proves de mòduls Marks-Practical-theory
Cas de prova3 : Integració i proves de mòduls Percentatge-Marques-Pràctica-Teoria
Cas de prova 4: Proves d'unitats de grau esportiu del mòdul
Cas de prova 5: Integració i proves de mòduls Rànquing-Grau esportiu-Percentatge-Marques-Pràctica-Teoria
Mèrits de la metodologia bottom-up
- Aquesta metodologia és molt útil per a aplicacions on s’utilitza el model de disseny de baix a dalt
- És més fàcil crear condicions de prova en un enfocament de baix a dalt
- Començar a provar al nivell inferior de la jerarquia significa provar els mòduls crítics o la funcionalitat en una fase inicial. Això ajuda a la descoberta primerenca d’errors
- Els defectes de la interfície es detecten en una fase inicial
De-mèrits de la metodologia bottom-up
- Els controladors són més difícils d’escriure que els registres
- Els defectes de disseny es detecten en la fase posterior
- En aquest enfocament, no disposem d'aplicacions de treball fins que es construeixi l'últim mòdul
- El controlador no és una implementació completa del mòdul relacionat. Simula el flux de dades entre dos mòduls.
# 3) Proves de sandvitx
Aquest enfocament és un híbrid de metodologia de dalt a baix i de baix a dalt. Stub i drivers s’utilitzen per a mòduls incomplets o no desenvolupats.
Enfocament de proves
- S’identifica una capa central a partir de la qual es fan proves de baix a dalt i de dalt a baix. Aquesta capa mitjana també es coneix com a capa objectiu
- La capa objectiu s’identifica segons l’enfocament heurístic, és a dir, seleccioneu una capa que permeti un ús mínim de Stubs i drivers
- Les proves de dalt a baix comencen des de la capa mitjana i es mou cap avall cap als mòduls de nivell inferior. Aquesta capa per sota de la capa mitjana es coneix com a capa inferior
- Les proves de baix a dalt també comencen des de la capa mitjana i es mouen cap als mòduls de capa superior. Aquesta capa per sobre de la capa mitjana es coneix com a capa superior
- Amb l'ús de controladors i controladors, es proven la interfície d'usuari i les funcions dels mòduls de nivell inferior respectivament
- Al final, només queda capa mitjana per a l'execució de la prova final
Exemple:
Els següents casos de prova es poden obtenir amb Sandwich Testing Strategy:
Cas de prova 1: Prova A, X, Y i Z individualment: la prova A passa a la prova de capa superior i la prova X, Y i Z passa a la prova de capa inferior
Cas de prova 2: Prova A, G, H i I
Cas de prova 3: Prova G, X i Y
Cas de prova 4: Test de mà Z
Cas de prova 5: Prova A, G, H, I, X, Y i Z
Mèrits de la metodologia de proves de sandvitx
- És molt beneficiós per a un gran projecte que té diversos subprojectes
- La metodologia de proves de dalt a baix i de baix a dalt pot funcionar un al costat de l’altre
De-merits de la metodologia de proves de sandvitx
- Abans de la unificació de mòduls, els subsistemes i les seves interfícies no es comproven a fons
- Major cost a causa de la participació de la metodologia de proves de dalt a baix i de baix a dalt
- No es recomana aquest tipus de proves per a un sistema en què els mòduls són molt interdependents
Conclusió
Les proves incrementals s’inclouen a la base de les proves d’integració. En aquest enfocament de proves, les proves d’integració es fan al mòdul individual com a part de les proves d’unitats i en la següent fase, els mòduls o components de l’aplicació s’integren de forma incremental i les proves es realitzen en mòduls combinats com a grup.
D’entre tres metodologies de proves d’integració incremental, l’elecció de la metodologia a escollir depèn de l’estructura de l’aplicació i també de la posició dels mòduls d’alt risc.
Les tres metodologies de proves incrementals pertanyen a la categoria Horitzontal a causa dels següents aspectes de comportament:
- Les tres metodologies se centren en les proves de capes
- Tots ells consideren un disseny estructural o jeràrquic
- Tots ells integren capes de manera incremental
Mèrits:
Amb aquest enfocament de proves, és més fàcil identificar aviat els defectes i també ajuda el desenvolupador a determinar la causa del problema. Com que utilitza els fonaments de les proves estructurades, aquest enfocament de proves és molt eficaç i precís.
Mèrits:
Aquest tipus d’enfocament de proves requereix molt de temps a causa de l’ús de talons i controladors. També és repetitiu.
Sobre la autor: Aquest útil tutorial està escrit per Neha B. És analista de qualitat principal certificada per ISTQB amb més de 8 anys d’experiència.
Feu-nos-ho saber si teniu cap dubte o suggeriment.
Lectura recomanada
- Les millors eines de prova de programari 2021 (Eines d'automatització de proves de control de qualitat)
- Què és la prova de components o la prova de mòduls (apreneu amb exemples)
- Prova de descàrrega de llibres electrònics
- Proves funcionals contra proves no funcionals
- Què és la prova de resistència en proves de programari (exemples)
- Prova de parelles o Tutorial de proves de tots els parells amb eines i exemples
- Tipus de proves de programari: diferents tipus de proves amb detalls
- Tutorial de proves de volum: exemples i eines de prova de volum