Menú

Prova de fum contra proves de seny: diferència amb exemples

smoke testing vs sanity testing

Proveu El Nostre Instrument Per Eliminar Problemes

Exploreu les diferències entre les proves de fum i les proves de seny amb detall amb exemples:

En aquest tutorial, aprendrem què són les proves de seny i les proves de fum en proves de programari. També aprendrem les diferències clau entre la prova de seny i fum amb exemples senzills.

La majoria de les vegades ens confonem entre el significat de Proves de seny i Proves de fum. En primer lloc, aquestes dues proves són molt “ diferent ”I es realitzen durant les diferents etapes d’un cicle de proves.

Proves de fum i proves de seny

Què aprendreu:

Proves de seny

Les proves de seny es fan quan, com a control de qualitat, no disposem del temps suficient per executar tots els casos de prova, ja sigui Proves funcionals , IU, SO o proves de navegador.

Per tant, jo definiria,

'Sanity Testing com a execució de la prova que es fa per tocar cada implementació i el seu impacte, però no a fons ni en profunditat, pot incloure proves funcionals, de la IU, de la versió, etc. en funció de la implementació i el seu impacte'.

No caiem tots en una situació en què hem de tancar la sessió d'aquí a un o dos dies, però la versió per a les proves encara no es publica?

quina és la clau de seguretat del router

Ah, sí, us aposto que també heu d'afrontar aquesta situació almenys una vegada a la vostra experiència de proves de programari. Bé, m'hi vaig enfrontar molt perquè els meus projectes eren majoritàriament àgils i, de vegades, se'ns va demanar que el lliuréssim el mateix dia. Vaja, com puc provar i alliberar la versió en poques hores?

De vegades em tornava boig perquè, encara que fos una petita funcionalitat, la implicació podria ser enorme. I com a cirereta del pastís, els clients de vegades simplement es neguen a dedicar temps addicional. Com podria completar tota la prova en poques hores, verificar totes les funcions, Errors i alliberar-lo?

proves de seny

La resposta a tots aquests problemes va ser molt senzilla, és a dir, només fer servir Estratègia de proves de seny.

Quan fem aquesta prova per trobar un mòdul, una funcionalitat o un sistema complet, el fitxer Provar casos d'execució se seleccionen de manera que tocaran tots els trossos importants, és a dir, proves amples però superficials.

De vegades, les proves es fan fins i tot aleatòriament sense casos de prova. Però recorda, La prova de seny només s’ha de fer quan s’està executant poc temps; no l’utilitzi mai per a les seves versions habituals. Teòricament, aquesta prova és un subconjunt de Proves de regressió .

La meva experiència

Experiència de proves de seny

Fora dels meus més de vuit anys de carrera professional en proves de programari, vaig estar treballant durant 3 anys Metodòleg àgil y i aquell va ser el moment en què vaig utilitzar sobretot una prova de seny.

Totes les grans versions es van planificar i executar de manera sistemàtica, però de vegades es va demanar que es lliuressin petites versions com més aviat millor. No vam tenir molt de temps per documentar els casos de prova, executar-los, fer la documentació d’errors, fer la regressió i seguir tot el procés.

Per tant, els següents són alguns dels punts clau que solia seguir en aquestes situacions:

# 1) Seieu amb el gerent i l’equip de desenvolupadors quan estiguin discutint sobre la implementació perquè han de treballar ràpidament i, per tant, no podem esperar que ens ho expliquin per separat.

Això també us ajudaria a fer-vos una idea de què implementaran, a quina àrea afectarà, etc., això és molt important, ja que de vegades simplement no ens adonem de les implicacions i si hi ha alguna funcionalitat existent es veurà obstaculitzat (en el pitjor dels casos).

# 2) Com que no teniu temps, quan l'equip de desenvolupament estigui treballant en la implementació, podeu anotar els casos de prova aproximadament en eines com Evernote, etc. Però assegureu-vos que els escriviu en algun lloc per afegir-los més tard a l'eina de casos de prova.

# 3) Mantingueu el vostre banc de proves preparat segons la implementació i, si creieu que hi ha indicadors vermells, com ara la creació de dades específiques, si un banc de proves trigarà temps (i és una prova important per a la versió), aixequeu-los immediatament i informeu el vostre gestor o PO sobre el bloqueig de carreteres.

El fet que el client vulgui el més aviat possible, no vol dir que s’alliberarà un control de qualitat encara que estigui mig provat.

# 4) Feu un acord amb el vostre equip i el vostre gerent que, a causa de la reducció del temps, només comunicareu els errors a l’equip de desenvolupament i el procés formal d’addició, el marcatge dels errors per a les diferents etapes de l’eina de seguiment d’errors es farà més tard per estalviar temps .

# 5) Quan l’equip de desenvolupament estigui provant al final, intenteu emparellar-lo (anomenat emparellament dev-QA) i feu una ronda bàsica a la configuració mateixa, cosa que us ajudarà a evitar l’anada i la tornada de la compilació si la implementació bàsica falla. .

# 6) Ara que teniu la compilació, proveu primer les regles empresarials i tots els casos d’ús. Podeu mantenir proves com la validació d'un camp, la navegació, etc. per a més endavant.

# 7) Qualsevol error que trobeu, anoteu-los i intenteu informar-los junts als desenvolupadors en lloc d’informar-los individualment, perquè els serà fàcil treballar en un munt.

# 8) Si teniu un requisit general Proves de rendiment o Prova d'estrès o càrrega, i després assegureu-vos que disposeu d'un marc d'automatització adequat per al mateix. Perquè és gairebé impossible provar-los manualment amb una prova de seny.

# 9) Aquesta és la part més important i, de fet, l'últim pas de la vostra estratègia de prova de seny: 'Quan redacteu el correu electrònic de llançament o el document, mencioneu tots els casos de prova que heu executat, els errors trobats amb un marcador d'estat i si queda alguna cosa esmentat sense provar-ho amb els motius ' Proveu d’escriure una història nítida sobre les vostres proves que transmetrà a tothom allò que s’ha provat, verificat i allò que no.

Vaig seguir això religiosament quan feia servir aquesta prova.

Permeteu-me compartir la meva pròpia experiència:

# 1) Estàvem treballant en un lloc web i solia publicar anuncis basats en les paraules clau. Els anunciants solien fer una oferta per a paraules clau concretes que tenien una pantalla dissenyada per a la mateixa. El valor de l'oferta predeterminat solia mostrar-se com a 0,25 dòlars, que fins i tot el licitador podria canviar.

Hi havia un lloc més on apareixia aquesta oferta predeterminada i també es podia canviar a un altre valor. El client va presentar una sol·licitud per canviar el valor predeterminat de 0,25 $ a 0,5 $, però només va mencionar la pantalla òbvia.

Durant la nostra discussió sobre pluja d’idees, ens vam oblidar (?) D’aquesta altra pantalla perquè no s’utilitzava gaire amb aquest propòsit. Però, mentre feia proves quan vaig executar que el cas bàsic de l’oferta era de 0,5 dòlars i vaig comprovar de cap a extrem, vaig trobar que el cronjob del mateix fallava perquè en un lloc trobava 0,25 dòlars.

Ho vaig informar al meu equip i vam fer el canvi i el vam lliurar amb èxit el mateix dia.

# 2) En el mateix projecte (esmentat anteriorment), se’ns va demanar que afegíssim un petit camp de text per a les notes / comentaris per a la licitació. Va ser una implementació molt senzilla i ens vam comprometre a lliurar-la el mateix dia.

Per tant, com es va esmentar anteriorment, vaig provar totes les regles empresarials i casos d’ús al voltant i, quan vaig fer algunes proves de validació, vaig comprovar que quan vaig introduir una combinació de caràcters especials com, la pàgina es va bloquejar.

Ens ho vam plantejar i ens vam adonar que els licitadors reals no utilitzaran en cap cas aquestes combinacions. Per tant, l’hem publicat amb una nota ben redactada sobre el tema. El client va acceptar-ho com a error, però va acordar amb nosaltres implementar-lo més endavant perquè era un error greu, però no anterior.

# 3) Recentment, estava treballant en un projecte d'aplicacions mòbils i teníem el requisit d'actualitzar l'hora de lliurament que es mostra a l'aplicació segons la zona horària. No només s’havia de provar a l’aplicació, sinó també per al servei web.

Mentre l'equip de desenvolupament treballava en la implementació, vaig crear els scripts d'automatització per a la prova del servei web i els scripts de base de dades per canviar la zona horària de l'element de lliurament. Això va salvar els meus esforços i podríem aconseguir millors resultats en poc temps.

Proves de seny contra proves de regressió

A continuació es detallen algunes diferències entre els dos:


S. No.		Proves de regressió


Proves de seny
7Aquesta prova està programada de vegades durant setmanes o fins i tot mesos.

La majoria abasta durant 2-3 dies com a màxim.

1Es fan proves de regressió per verificar que el sistema complet i les correccions d'errors funcionen bé.Les proves de seny es fan a l’atzar per verificar que cada funcionalitat funciona com s’esperava.
2Totes les parts més petites es regressen en aquesta prova.
Aquesta no és una prova planificada i només es fa quan hi ha un temps restringit.
3
És una prova ben elaborada i planificada.

Aquesta no és una prova planificada i només es fa quan hi ha un temps restringit.

4Es crea un conjunt adequat de casos de prova per a aquesta prova.

És possible que no sempre sigui possible crear els casos de prova; normalment es crea un conjunt aproximat de casos de prova.

5Això inclou la verificació en profunditat de la funcionalitat, la interfície d’usuari, el rendiment, les proves del navegador / sistema operatiu, etc., és a dir, es regressen tots els aspectes del sistema.

Això inclou principalment la verificació de les regles de negoci, la funcionalitat.

6Es tracta d’una prova àmplia i profunda.

Es tracta d’una prova àmplia i superficial.

Estratègia per a la prova d'aplicacions mòbils

Prova de seny de l’aplicació mòbil

Us heu de preguntar per què menciono específicament sobre les aplicacions mòbils aquí?

La raó és que la versió del sistema operatiu i del navegador per a aplicacions web o d’escriptori no varia molt i sobretot les mides de pantalla són estàndard. Però amb les aplicacions mòbils, la mida de la pantalla, la xarxa mòbil, les versions del sistema operatiu, etc. afecten l’estabilitat, l’aspecte i, en definitiva, l’èxit de la vostra aplicació mòbil.

Per tant, una formulació d’estratègia esdevé fonamental quan realitzeu aquesta prova en una aplicació per a mòbils, ja que un error pot causar problemes. Les proves s’han de fer de manera intel·ligent i amb precaució també.

A continuació s’indiquen alguns consells per ajudar-vos a realitzar aquesta prova amb èxit en una ‘aplicació mòbil’:

# 1) Primer de tot, analitzeu l’impacte de la versió del sistema operatiu en la implementació amb el vostre equip.

Intenteu trobar respostes a preguntes com ara, el comportament serà diferent entre les versions? La implementació funcionarà amb la versió més baixa compatible? Hi haurà problemes de rendiment per a la implementació de versions? Hi ha alguna característica específica del sistema operatiu que pugui afectar el comportament de la implementació? etc.

# 2) A la nota anterior, analitzeu també els models de telèfon, és a dir, hi ha alguna característica del telèfon que afecti la implementació? La implementació de canvis de comportament amb el GPS és? El comportament de la implementació canvia amb la càmera del telèfon? Si creieu que no hi ha cap impacte, eviteu fer proves en diferents models de telèfons.

# 3) Tret que hi hagi canvis en la interfície d’usuari per a la implementació, us recomanaria mantenir la prova d’interfície d’usuari amb la menor prioritat, podeu informar a l’equip (si voleu) que la interfície d’usuari no es provarà.

# 4) Per estalviar temps, eviteu fer proves en bones xarxes perquè és obvi que la implementació funcionarà com s’esperava en una xarxa forta. Recomanaria començar amb proves en una xarxa 4G o 3G.

# 5) Aquesta prova s'ha de fer en menys temps, però assegureu-vos que feu almenys una prova de camp, tret que es tracti d'un simple canvi d'UI.

# 6) Si heu de provar una matriu de SO diferent i la seva versió, us suggeriria que ho feu d’una manera intel·ligent. Per exemple, trieu els parells de versió del sistema operatiu més baixos, mitjans i els més recents per provar-los. Podeu esmentar al document de llançament que no es proven totes les combinacions.

# 7) En una línia similar, per a la prova de seny d'implementació de la IU, utilitzeu mides de pantalla petites, mitjanes i grans per estalviar temps. També podeu utilitzar un simulador i un emulador.

Mesures cautelars

Les proves de seny es duen a terme quan s’està executant poc temps i, per tant, no us és possible executar tots els casos de prova i, sobretot, no se us dóna prou temps per planificar les proves. Per evitar els jocs de culpa, és millor prendre mesures de precaució.

En aquests casos, la manca de comunicació escrita, la documentació de proves i les fallades són força habituals.

Per assegurar-vos de no caure en presa d'això, assegureu-vos que:

  • No accepteu mai una compilació per provar-la fins que no rebeu cap requisit per escrit compartit pel client. Succeeix que els clients comuniquen canvis o implementacions noves verbalment o en xat o bé amb un senzill liner en un correu electrònic i esperen que ho tractem com un requisit. Obligueu el vostre client a proporcionar alguns punts bàsics de funcionalitat i criteris d'acceptació.
  • Preneu sempre notes detallades dels vostres casos de prova i errors si no teniu prou temps per escriure’ls correctament. No deixeu mai aquests indocumentats. Si hi ha una mica de temps, compartiu-lo amb el vostre líder o equip perquè, si falta alguna cosa, ho puguin assenyalar fàcilment.
  • Si el vostre equip i vosaltres no teniu temps, assegureu-vos que els errors estan marcats en un estat de correu electrònic adequat? Podeu enviar per correu electrònic la llista completa d’errors a l’equip i fer que els desenvolupadors els marquin adequadament. Mantingueu sempre la pilota a la pista de l’altre.
  • Si vostè té Marc d’automatització llest, utilitzeu-ho i eviteu fer-ho ManualTesting , d'aquesta manera en menys temps podeu cobrir més.
  • Eviteu l'escenari de 'llançament en 1 hora' tret que estigueu 100% segur que podreu lliurar.
  • Per últim, però no menys important, com es va esmentar anteriorment, redacteu un correu electrònic de llançament detallat que comuniqueu què es prova, què es deixa de banda, motius, riscos, quins errors es resolen, quins són els 'posteriors', etc.

Com a control de qualitat, heu de jutjar quina és la part més important de la implementació que cal provar i quines són les parts que es poden deixar de banda o provar bàsicament.

Fins i tot en poc temps, planifiqueu una estratègia sobre com voleu fer i podreu aconseguir el millor en el període de temps donat.

Proves de fum

Les proves de fum no són proves exhaustives, sinó que són un grup de proves que s’executen per verificar si les funcionalitats bàsiques d’aquesta versió concreta funcionen bé com s’esperava o no. Aquesta és i hauria de ser sempre la primera prova que es faci en qualsevol versió 'nova'.

Quan l’equip de desenvolupament publica una versió a la QA per provar-la, és evident que no és possible provar tota la compilació i verificar immediatament si alguna de les implementacions té errors o si alguna de les funcionalitats de treball està trencada.

Tenint en compte això, com es pot assegurar un control de qualitat que les funcions bàsiques funcionin bé?

La resposta a això serà realitzar un Proves de fum .

Proves de fum

Quan les proves es marquen com a proves de fum (a la suite de proves), només el QA accepta la compilació per fer proves en profunditat i / o regressió. Si alguna de les proves de fum falla, la compilació es rebutja i l'equip de desenvolupament ha de solucionar el problema i llançar una nova versió per provar-la.

Teòricament, la prova de fum es defineix com a prova de nivell superficial per certificar que la versió proporcionada per l'equip de desenvolupament a l'equip de control de qualitat està preparada per a proves posteriors. Aquesta prova també la realitza l’equip de desenvolupament abans de lliurar la compilació a l’equip de control de qualitat.

Aquestes proves s’utilitzen normalment en proves d’integració, proves de sistemes i proves de nivell d’acceptació. No tracteu mai això com un substitut de la prova completa per acabar . Consta de proves positives i negatives en funció de la implementació de la compilació.

Exemples de proves de fum

Aquesta prova s'utilitza normalment per a integració, acceptació i Proves del sistema .

A la meva carrera com a QA, sempre vaig acceptar una versió només després d’haver realitzat una prova de fum. Per tant, entenem què és una prova de fum des de la perspectiva de tots aquests tres tests, amb alguns exemples.

# 1) Proves d'acceptació

Sempre que es publica una versió al control de qualitat, proveu el fum en forma de Proves d'acceptació s’hauria de fer.

En aquesta prova, la primera i més important prova de fum és verificar la funcionalitat bàsica esperada de la implementació. Així, hauríeu de verificar totes les implementacions d’aquesta compilació en particular.

Prenem els exemples següents com a implementacions realitzades en una compilació per entendre les proves de fum per a aquestes:

  • S'ha implementat la funcionalitat d'inici de sessió per permetre als controladors registrats iniciar la sessió correctament.
  • S'ha implementat la funcionalitat del tauler per mostrar les rutes que un controlador ha d'executar avui.
  • S'ha implementat la funcionalitat per mostrar un missatge adequat si no hi ha rutes per a un dia determinat.

A la versió anterior, a nivell d’acceptació, la prova de fum significarà verificar que les tres implementacions bàsiques funcionen bé. Si algun d’aquests tres es trenca, el QA hauria de rebutjar la compilació.

# 2) Proves d'integració

Aquesta prova sol fer-se quan s’implementen i proven els mòduls individuals. A la Proves d’integració a nivell, aquesta prova es realitza per assegurar-se que totes les funcionalitats bàsiques d’integració i de punta funcionen bé com s’esperava.

Pot ser la integració de dos mòduls o tots els mòduls junts, per tant, la complexitat de la prova de fum variarà en funció del nivell d’integració.

Considerem els següents exemples d'implementació d'integració per a aquesta prova:

  • Implementació de la integració de mòduls de rutes i parades.
  • S'ha implementat la integració de l'actualització de l'estat d'arribada i reflecteix el mateix a la pantalla de parades.
  • S'ha implementat la integració de recollida completa fins als mòduls de funcionalitat de lliurament.

En aquesta versió, la prova de fum no només verificarà aquestes tres implementacions bàsiques, sinó que, per a la tercera implementació, també es verificaran alguns casos per a una integració completa. Ajuda molt a conèixer els problemes que s’introdueixen en la integració i els que van passar desapercebuts per l’equip de desenvolupament.

# 3) Prova del sistema

Com el seu propi nom indica, per a nivell de sistema, les proves de fum inclouen proves dels fluxos de treball més importants i més utilitzats del sistema. Això només es fa després que el sistema complet estigui llest i provat, i aquesta prova per al nivell del sistema es pot anomenar prova de fum abans de fer proves de regressió.

Abans d'iniciar la regressió del sistema complet, les característiques bàsiques d'extrem a extrem es comproven com a part de la prova de fum. El conjunt de proves de fum per al sistema complet inclou casos de proves de punta a punta que els usuaris finals utilitzaran amb molta freqüència.

Normalment es fa amb l'ajuda d'eines d'automatització.

Importància en la metodologia SCRUM

Avui en dia, els projectes pràcticament no segueixen la metodologia Waterfall en la implementació del projecte, la majoria dels quals segueixen Agile i SCRUM només. En comparació amb el mètode tradicional de cascada, les proves de fum són molt respectades en SCRUM i Agile.

Vaig treballar durant 4 anys a SCRUM . I com sabem que a SCRUM, els sprints tenen una durada menor i, per tant, és extremadament important fer aquesta prova, de manera que les compilacions fallides es puguin comunicar immediatament a l’equip de desenvolupament i solucionar-les també.

A continuació se’n detallen alguns emportar sobre la importància d’aquestes proves a SCRUM:

  • Fora del sprint de quinze dies, la mitja part s’assigna al control de qualitat, però de vegades les versions del control de qualitat es retarden.
  • En els sprints, és millor per a l’equip que es comuniquin els problemes en una etapa inicial.
  • Cada història té un conjunt de criteris d’acceptació, per tant, provar els primers 2-3 criteris d’acceptació és igual a la prova de fum d’aquesta funcionalitat. Els clients rebutgen el lliurament si falla un criteri únic.
  • Imagineu què passarà si l’equip de desenvolupament us ha lliurat la versió de 2 dies i només queden 3 dies per a la demostració i us trobeu amb un error bàsic de funcionalitat.
  • De mitjana, un sprint té històries que van des del 5 al 10, de manera que, quan es dóna la compilació, és important assegurar-se que cada història s’implementi tal com s’esperava abans d’acceptar la compilació en proves.
  • Quan s'ha de provar i regressar el sistema complet, es dedica un esprint a l'activitat. Una quinzena potser poc menys per provar tot el sistema, per tant és molt important verificar les funcionalitats més bàsiques abans d’iniciar la regressió.

Prova de fum contra proves d'acceptació

Les proves de fum estan directament relacionades amb les proves d’acceptació de la construcció (BAT).

A BAT, fem les mateixes proves: per verificar si la compilació no ha fallat i si el sistema funciona bé o no. De vegades, passa que quan es crea una compilació, s’introdueixen alguns problemes i, quan es lliura, la compilació no funciona per al control de qualitat.

Diria que les MTD formen part d’una comprovació de fum perquè, si el sistema falla, com podeu, com a QA, acceptar la compilació per provar-la? No només les funcionalitats, sinó que el propi sistema ha de funcionar abans que el control de qualitat realitzi les proves en profunditat.

Cicle de proves de fum

El següent diagrama de flux explica el cicle de proves de fum.

Un cop es desplega una compilació en un control de qualitat, el cicle bàsic que segueix és que, si la prova de fum passa, l’equip de control de qualitat accepta la compilació per fer proves posteriors, però si falla, la compilació es rebutja fins que es resolen els problemes informats.

Cicle de proves

Cicle de proves de fum

Qui hauria de realitzar la prova de fum?

Icona de qui

No tot l’equip participa en aquest tipus de proves per evitar la pèrdua de temps de tots els control de qualitat.

on veure animis en línia de forma gratuïta

Les proves de fum són realitzades idealment pel responsable de control de qualitat, que decideix en funció del resultat si passa la versió a l’equip per a proves posteriors o la rebutja. O, en absència del líder, els mateixos controladors de qualitat també poden realitzar aquesta prova.

De vegades, quan el projecte és de gran envergadura, un grup de control de qualitat també pot realitzar aquesta prova per comprovar si hi ha cap showstoppers. Però això no és així en el cas de SCRUM, ja que SCRUM és una estructura plana sense líders ni gestors i cada provador té les seves pròpies responsabilitats envers les seves històries.

Per tant, els QA individuals realitzen aquesta prova de les històries que posseeixen.

Per què hem d’automatitzar les proves de fum?

Aquesta prova és la primera prova que es fa en una versió publicada pels equips de desenvolupament. Basant-se en els resultats d’aquestes proves, es fan proves posteriors (o es rebutja la compilació).

La millor manera de fer aquesta prova és fer servir una eina d’automatització i programar el fum suite perquè s’executi quan es crea una nova versió. Potser estareu pensant per què ho hauria de fer? 'Automatitzeu el conjunt de proves de fum'?

Vegem el cas següent:

Suposem que us falta una setmana per alliberar-vos i que, del total de 500 casos de prova, el vostre conjunt de proves de fum consta de 80 a 90. Si comenceu a executar tots aquests casos de prova de 80 a 90 manualment, imagineu-vos quant de temps trigareu? Crec que 4-5 dies (mínim).

Però si utilitzeu l'automatització i creeu scripts per executar tots aquests 80-90 casos de prova, idealment, s'executaran en 2-3 hores i tindreu els resultats a l'instant. No us ha estalviat el vostre preuat temps i us ha donat molt menys temps sobre la construcció?

Fa 5 anys, estava provant una aplicació de projecció financera que prenia dades sobre el vostre salari, estalvis, etc. i projectava els vostres impostos, estalvis i beneficis en funció de les regles financeres. Juntament amb això, vam tenir personalitzacions per a països que depenen del país i de les seves normes fiscals que s’utilitzaven per canviar (al codi).

Per a aquest projecte, tenia 800 casos de proves i 250 casos de proves de fum. Amb l’ús de seleni, podríem automatitzar i obtenir fàcilment els resultats d’aquests 250 casos de prova en 3-4 hores. No només ens va estalviar temps, sinó que ens va mostrar el més aviat possible sobre els showstoppers.

Per tant, tret que sigui impossible automatitzar, feu servir l'ajut de l'automatització per a aquesta prova.

Avantatges i inconvenients

Primer fem una ullada als avantatges, ja que té molt a oferir en comparació amb els seus pocs desavantatges.

Avantatges:

  • Fàcil de realitzar.
  • Redueix el risc.
  • Els defectes s’identifiquen en una etapa molt primerenca.
  • Estalvia esforços, temps i diners.
  • Funciona ràpidament si està automatitzat.
  • Problemes i riscos d'integració mínims.
  • Millora la qualitat general del sistema.

Desavantatges:

  • Aquesta prova no és igual ni substitueix la prova funcional completa.
  • Fins i tot després de passar la prova de fum, és possible que trobeu errors de showstopper.
  • Aquest tipus de proves és el més adequat si podeu automatitzar una altra vegada que es dedica molt temps a executar manualment els casos de prova, especialment en projectes a gran escala que tinguin al voltant de 700-800 casos de prova.

Les proves de fum s’haurien de fer definitivament en totes les versions, ja que assenyalen les falles més importants i els detectors en una etapa molt primerenca. Això no només s'aplica a les noves funcionalitats, sinó també a la integració de mòduls, la resolució de problemes i la improvisació. És un procés molt senzill de realitzar i obtenir el resultat correcte.

Aquesta prova es pot tractar com el punt d'entrada per a una prova funcional completa de la funcionalitat o del sistema (en conjunt). Però abans, l’equip de control de qualitat hauria de tenir molt clar quines proves s’han de fer com a proves de fum . Aquesta prova pot minimitzar els esforços, estalviar temps i millorar la qualitat del sistema. Ocupa un lloc molt important en els esports, ja que el temps en els esports és menor.

Aquesta prova es pot fer manualment i també amb l'ajut d'eines d'automatització. Però la millor manera i preferida és utilitzar eines d’automatització per estalviar temps.

Diferència entre les proves de fum i seny

La majoria de les vegades ens confonem entre el significat de Proves de seny i Proves de fum. En primer lloc, aquestes dues proves són molt “ diferent ”I realitzat durant les diferents etapes d’un cicle de proves.

S. No.Proves de fum

Proves de seny

1 Prova de fum significa verificar (bàsic) que les implementacions realitzades en una compilació funcionen bé.Provar el seny significa comprovar que les funcionalitats, els errors, etc., recentment afegits, funcionen bé.
2 Aquesta és la primera prova de la versió inicial.Fet quan la compilació és relativament estable.
3 Fet a cada versió.Fet en versions estables després de la regressió.

A continuació es mostra una representació esquemàtica de les seves diferències:

Proves de fum

PROVA DE FUMS

  • Aquestes proves es van originar al maquinari provar la pràctica d’encendre per primera vegada una nova peça de maquinari i considerar-la un èxit si no pren foc i fuma. A la indústria del programari, aquesta prova és un enfocament superficial i ampli mitjançant el qual es posen a prova totes les àrees de l’aplicació sense aprofundir massa.
  • Una prova de fum es guiona, ja sigui mitjançant un conjunt de proves escrites o una prova automatitzada
  • Una prova de fum està dissenyada per tocar totes les parts de l’aplicació d’una manera superficial. És poc profund i ample.
  • Aquesta prova es realitza per assegurar-se si les funcions més crucials d’un programa funcionen, però no molestar-se amb els detalls més fins. (Com ara la verificació de la compilació).
  • Aquestes proves són una revisió normal de la salut de la compilació d'una aplicació abans de provar-la en profunditat.

PROVES DE SANITAT

  • Una prova de seny és una prova de regressió estreta que se centra en una o algunes àrees de funcionalitat. Les proves de seny solen ser estretes i profundes.
  • Aquesta prova sol estar sense script.
  • Aquesta prova s'utilitza per determinar que una petita secció de l'aplicació encara funciona després d'un canvi menor.
  • Aquesta prova és una prova superficial, es realitza sempre que una prova superficial és suficient per demostrar que l'aplicació funciona segons les especificacions. Aquest nivell de proves és un subconjunt de proves de regressió.
  • Es tracta de verificar si es compleixen o no els requisits, comprovant totes les funcions.

Espero que tingueu clares les diferències entre aquests dos grans i importants tipus de proves de programari. No dubteu a compartir els vostres pensaments a la secció de comentaris de sota !!

Lectura recomanada

^