Meni

Preizkušanje dima vs preizkusom razumnosti: razlika med primeri

smoke testing vs sanity testing

Preizkusite Naš Instrument Za Odpravo Težav

Podrobno raziščite razlike med preskušanjem dima in preizkušanjem razumnosti s primeri:

V tej vadnici bomo izvedeli, kaj je preizkušanje razumnosti in preizkušanje dima pri testiranju programske opreme. S preprostimi primeri bomo izvedeli tudi ključne razlike med testiranjem Sanity in Smoke.

V večini primerov se zmedemo med pomenom preizkušanja razumnosti in preskušanja dima. Prvič, ti dve testiranji sta zelo dobri drugačen 'In se izvajajo v različnih fazah preskusnega cikla.

Preizkušanje dima in ugotavljanje zdrave pameti

Kaj se boste naučili:

Preverjanje razumnosti

Preizkušanje razumnosti se opravi, ko kot QA nimamo dovolj časa za izvajanje vseh testnih primerov, pa naj bo to Funkcionalno preskušanje , Uporabniški vmesnik, OS ali brskalnik.

Zato bi opredelil,

'Preskušanje razumnosti kot izvedba preizkusa, ki se izvede tako, da se dotakne vsake izvedbe in njenega vpliva, vendar ne temeljito ali poglobljeno, lahko vključuje preizkušanje funkcionalnosti, uporabniškega vmesnika, različice itd., Odvisno od izvedbe in njenega vpliva.'

Ali ne pademo vsi v situacijo, ko se moramo odjaviti čez dan ali dva, vendar gradnja za testiranje še vedno ni izdana?

ročna vprašanja in vprašanja za avtomatizacijo

Ah, da, stavim, da ste se tudi vi morali vsaj enkrat soočiti s to situacijo v svojem preizkušanju programske opreme. No, s tem sem se veliko soočal, ker so bili moji projekti večinoma gibčni in včasih so nas prosili, da jih dostavimo še isti dan. Ups, kako lahko preizkusim in sprostim gradnjo v nekaj urah?

Včasih sem se obnorel, ker četudi bi šlo za majhno funkcionalnost, bi to lahko imelo ogromno. In kot pika na i, stranke včasih preprosto nočejo dati dodatnega časa. Kako lahko v nekaj urah opravim celotno testiranje, preverim vsako funkcionalnost, Napake in ga sprostite?

preizkušanje razumnosti

Odgovor na vse tovrstne težave je bil zelo preprost, torej samo z uporabo Strategija preizkušanja razumnosti.

Ko opravimo to testiranje modula ali funkcionalnosti ali celotnega sistema, se Testni primeri za izvedbo so izbrani tako, da se bodo dotaknili vseh pomembnih kosov istega, tj. širokega, a plitvega preskušanja.

Včasih se testiranje izvaja celo naključno, brez testnih primerov. Ampak ne pozabite, Preizkus zdravega počutja je treba opraviti le, če vam primanjkuje časa, tega nikoli ne uporabljajte za redne izdaje. Teoretično je to testiranje podmnožica Preskušanje regresije .

Moje izkušnje

Izkušnje s preizkušanjem razumnosti

Od moje 8+ let kariere v preizkušanju programske opreme sem tri leta delal v Agilni metodolog y in takrat sem večinoma uporabljal test zdravja.

Vse velike izdaje so bile načrtovane in izvedene sistematično, včasih pa so prosili majhne izdaje, da jih dostavijo čim prej. Nismo dobili veliko časa za dokumentiranje testnih primerov, izvedbo, izdelavo dokumentacije o napakah, regresijo in sledenje celotnemu postopku.

Zato je nekaj ključnih napotkov, ki sem jih v teh situacijah upošteval:

# 1) Ko se pogovarjate o izvedbi, posedite z vodjo in ekipo za razvijalce, ker morajo delati hitro, zato ne moremo pričakovati, da nam bodo pojasnili ločeno.

To bi vam tudi pomagalo, da dobite idejo o tem, kaj bodo izvajali, na katero področje bo vplivalo itd., To je zelo pomembno, saj včasih preprosto ne zavedamo posledic in če obstaja kakšna obstoječa funkcionalnost bo ovirano (v najslabšem primeru).

#two) Ker vam primanjkuje časa, lahko razvojna skupina, ko dela na izvedbi, približno zapišete testne primere v orodjih, kot je Evernote itd. Pazite, da jih nekje zapišete, da jih boste lahko pozneje dodali orodje za testne primere.

# 3) Naj bo vaša testna plošča pripravljena v skladu z izvedbo in če menite, da obstajajo rdeče zastavice, kot je ustvarjanje določenih podatkov, če bo testna plošča potrebovala čas (in to je pomemben test za izdajo), nato te zastavice takoj dvignite in o tem obvestite svojega upravitelja ali PO glede zapore ceste.

Samo zato, ker si stranka želi čim prej, še ne pomeni, da bo QA izdal tudi, če bo na pol preizkušen.

# 4) Dogovorite se s svojo ekipo in upraviteljem, da boste zaradi časovne stiske napake sporočili samo razvojni skupini in formalni postopek dodajanja bo označevanje napak za različne stopnje v orodju za sledenje napak izvedeno pozneje, da boste prihranili čas .

# 5) Ko razvojna skupina testira na svojem koncu, se poskusite z njimi seznaniti (imenovano seznanjanje dev-QA) in opravite osnovni krog njihove namestitve, kar bo pomagalo, da se izognete gradnji, če osnovna izvedba ne uspe. .

# 6) Zdaj, ko imate gradnjo, najprej preizkusite poslovna pravila in vse primere uporabe. Preizkuse, kot so validacija polja, navigacija itd., Lahko shranite za pozneje.

# 7) Ne glede na napake, ki jih najdete, si jih zapišite in jih poskusite skupaj prijaviti razvijalcem, namesto da bi poročali posamezno, saj bodo z lahkoto delali na kupu.

# 8) Če imate zahtevo za splošno Testiranje učinkovitosti ali testiranje obremenitve ali obremenitve, nato se prepričajte, da imate ustrezen okvir za avtomatizacijo istega. Ker je skoraj nemogoče, da bi jih ročno preizkusili s preizkusom razumnosti.

# 9) To je najpomembnejši del in dejansko zadnji korak vaše strategije preizkušanja zdravja - »Ko pripravite e-poštno sporočilo o izdaji ali dokument, navedite vse preizkušene primere, ki ste jih izvedli, napake, najdene z označevalnikom stanja, in če je kaj ostalo nepreizkušeno omeniti z razlogi ' Poskusite napisati resnično zgodbo o svojem testiranju, ki bo vsem povedala, kaj je bilo preizkušeno, preverjeno in kaj ne.

Temu sem sledil religiozno, ko sem uporabljal to testiranje.

Naj povem svoje izkušnje:

# 1) Delali smo na spletnem mestu, ki je prikazovalo oglase na podlagi ključnih besed. Oglaševalci so dajali ponudbe za določene ključne besede, katerih zaslon je bil zasnovan za iste. Privzeta vrednost ponudbe je bila včasih prikazana kot 0,25 USD, kar bi ponudnik lahko celo spremenil.

Na tej privzeti ponudbi se je prikazovalo še eno mesto in jo je bilo mogoče spremeniti tudi na drugo vrednost. Naročnik je prišel s prošnjo za spremembo privzete vrednosti z 0,25 na 0,5 evra, vendar je omenil le očiten zaslon.

Med našo razpravo o pametnih mislih smo pozabili (?) Na ta drugi zaslon, ker ga v ta namen niso veliko uporabljali. Toda med testiranjem, ko sem izvedel osnovni primer ponudbe 0,5 USD in preveril od konca do konca, sem ugotovil, da cronjob za isto ni uspel, ker je na enem mestu našel 0,25 USD.

To sem sporočil svoji ekipi, spremembo smo izvedli in jo uspešno izvedli še isti dan.

#two) V okviru istega projekta (omenjenega zgoraj) smo morali dodati majhno besedilno polje za opombe / komentarje za ponudbe. Bila je zelo preprosta izvedba in zavezali smo se, da jo bomo izvedli še isti dan.

Kot sem že omenil, sem preizkusil vsa poslovna pravila in primere uporabe okoli njih in ko sem opravil nekaj preverjanja veljavnosti, sem ugotovil, da ko sem vnesel kombinacijo posebnih znakov, kot je, se je stran strmoglavila.

Premislili smo in ugotovili, da dejanski ponudniki v nobenem primeru ne bodo uporabljali takšnih kombinacij. Zato smo ga izdali z dobro pripravljenim zapisom o tej težavi. Naročnik je to sprejel kot napako, vendar se je strinjal z nami, da jo bomo uvedli pozneje, ker je šlo za hudo napako, ne pa tudi za predhodno.

# 3) Pred kratkim sem delal na projektu mobilne aplikacije in morali smo posodobiti čas dostave, prikazan v aplikaciji, glede na časovni pas. Ni ga bilo treba preizkusiti samo v aplikaciji, temveč tudi za spletno storitev.

Medtem ko je razvojna skupina delala na izvedbi, sem ustvaril skripte za avtomatizacijo za testiranje spletnih storitev in skripte DB za spreminjanje časovnega pasu postavke dostave. To mi je prihranilo trud in v kratkem času bi lahko dosegli boljše rezultate.

Preizkušanje razumnosti in regresijsko preskušanje

Spodaj je nekaj razlik med obema:


S. Št.		Preskušanje regresije


Preverjanje razumnosti
7.To testiranje je načrtovano za tedne ali celo mesece.

To večinoma traja največ 2-3 dni.

1.Regresijsko testiranje se opravi, da se preveri, ali celotni sistem in popravki napak dobro delujejo.Preverjanje razumnosti se izvaja naključno, da se preveri, ali vsaka funkcionalnost deluje po pričakovanjih.
dvaPri tem testiranju je regresiran vsak najmanjši del.
To ni načrtovano testiranje in se opravi le, kadar pride do časovne stiske.
3.
Gre za dobro dodelano in načrtovano testiranje.

To ni načrtovano testiranje in se opravi le, kadar pride do časovne stiske.

4.Za to testiranje je ustvarjena ustrezno zasnovana zbirka testnih primerov.

Morda ne bo vsakič mogoče ustvariti testnih primerov; ponavadi nastane grob nabor testnih primerov.

5.To vključuje poglobljeno preverjanje funkcionalnosti, uporabniškega vmesnika, zmogljivosti, testiranja brskalnika / operacijskega sistema itd., Kar pomeni, da je vsak vidik sistema regresiran.

To vključuje predvsem preverjanje poslovnih pravil in funkcionalnosti.

6.To je široko in globoko testiranje.

To je široko in plitvo testiranje.

Strategija za testiranje mobilnih aplikacij

Preizkušanje razumnosti mobilnih aplikacij

Verjetno se sprašujete, zakaj tukaj omenjam posebej mobilne aplikacije?

Razlog je v tem, da se različice operacijskega sistema in brskalnika za spletne ali namizne aplikacije ne razlikujejo veliko, predvsem pa so velikosti zaslona standardne. Toda pri mobilnih aplikacijah velikost zaslona, ​​mobilno omrežje, različice OS itd. Vplivajo na stabilnost, videz in skratka na uspeh vaše mobilne aplikacije.

Zato je oblikovanje strategije ključnega pomena, ko to testiranje izvajate v mobilni aplikaciji, saj vas ena napaka lahko privede v velike težave. Testiranje je treba opraviti pametno in previdno.

Sledi nekaj napotkov, ki vam bodo pomagali uspešno izvesti to testiranje v „mobilni aplikaciji“:

# 1) Najprej s svojo ekipo analizirajte vpliv različice OS na izvedbo.

Poskusite najti odgovore na vprašanja, na primer, ali se bo vedenje v različicah razlikovalo? Bo izvedba delovala na najnižje podprti različici ali ne? Ali bodo pri izvedbi različic težave z zmogljivostjo? Ali obstaja kakšna posebna značilnost operacijskega sistema, ki bi lahko vplivala na vedenje izvedbe? itd.

#two) Na zgornji opombi analizirajte tudi modele telefonov, tj.Ali obstajajo funkcije telefona, ki bodo vplivale na izvedbo? Ali se izvajanje vedenja spreminja s sistemom GPS? Ali se vedenje implementacije spreminja s kamero telefona? itd. Če ugotovite, da to ne vpliva, se izogibajte testiranju na različnih modelih telefonov.

# 3) Če za izvedbo ne pride do sprememb uporabniškega vmesnika, priporočam, da testiranje uporabniškega vmesnika ostane najmanj prednostno, lahko obvestite skupino (če želite), da uporabniški vmesnik ne bo preizkušen.

# 4) Da bi prihranili svoj čas, se izogibajte testiranju na dobrih omrežjih, ker je očitno, da bo izvedba v močnem omrežju delovala po pričakovanjih. Priporočam, da začnete s testiranjem v omrežju 4G ali 3G.

# 5) To testiranje je treba opraviti v krajšem času, vendar se prepričajte, da opravite vsaj en terenski test, razen če gre zgolj za spremembo uporabniškega vmesnika.

# 6) Če morate preizkusiti matriko različnih OS in njihovo različico, predlagam, da to storite na pameten način. Na primer, za testiranje izberite pare najnižje, srednje in najnovejše različice OS. V dokumentu o izdaji lahko omenite, da ni preizkušena vsaka kombinacija.

# 7) V podobni vrstici za preizkus razumnosti izvajanja uporabniškega vmesnika uporabite majhne, ​​srednje in velike velikosti zaslona, ​​da prihranite čas. Uporabite lahko tudi simulator in emulator.

Previdnostni ukrepi

Preizkušanje razumnosti se izvaja, kadar vam primanjkuje časa, zato vam ni mogoče izvesti vsakega preizkusnega primera in kar je najpomembneje, nimate dovolj časa za načrtovanje testiranja. Da bi se izognili igram krivde, je bolje sprejeti previdnostne ukrepe.

V takih primerih so pomanjkanje pisne komunikacije, testne dokumentacije in izpusti zelo pogosti.

Da ne boste postali plen tega, poskrbite, da:

  • Nikoli ne sprejemite zgradbe za testiranje, dokler vam stranka ne izda pisne zahteve. Zgodi se, da stranke spremembe ali nove izvedbe sporočijo ustno ali v klepetu ali navadni podlogi v e-pošti in pričakujejo, da bomo to obravnavali kot zahtevo. Prisilite svojo stranko, da navede nekaj osnovnih funkcijskih točk in merila za sprejem.
  • Vedno si naredi grobe zapise svojih testnih primerov in napak, če nimaš dovolj časa, da bi jih lepo napisal. Nikoli ne puščajte teh brez dokumentov. Če je nekaj časa, ga delite s svojim vodjem ali ekipo, da bodo lahko, če kaj manjka, to zlahka opozorili.
  • Če vam in vaši ekipi primanjkuje časa, se prepričajte, da so napake v e-poštnem sporočilu označene v ustreznem stanju? Skupini lahko pošljete celoten seznam napak in poskrbite, da jih bodo razvijalci ustrezno označili. Žogo vedno imejte na igrišču drugega.
  • Če imate Okvir za avtomatizacijo pripravljeni, uporabite to in se izogibajte Ročno preskušanje , tako lahko v krajšem času pokrijete več.
  • Izogibajte se scenariju »sprostitev v 1 uri«, razen če ste stoodstotno prepričani, da boste lahko dostavili.
  • Nenazadnje, kot omenjeno zgoraj, pripravite podrobno e-poštno sporočilo, v katerem boste sporočili, kaj je preizkušeno, kaj je izpuščeno, razloge, tveganja, katere napake so odpravljene, kaj je »prepozno« itd.

Kot preverjanje kakovosti bi morali presoditi, kateri je najpomembnejši del izvedbe, ki ga je treba preizkusiti, in kateri deli so lahko izpuščeni ali osnovno preizkušeni.

Tudi v kratkem času načrtujte strategijo, kako želite, in v danem časovnem okviru boste lahko dosegli najboljše.

Preskušanje dima

Preizkušanje dima ni izčrpno preskušanje, ampak gre za skupino testov, ki se izvedejo, da se preveri, ali osnovne funkcije te določene zgradbe delujejo v skladu s pričakovanji ali ne. To je in bi moral biti vedno prvi preizkus pri kateri koli 'novi' gradnji.

Ko razvojna skupina sprosti zgradbo v QA za testiranje, očitno ni mogoče preizkusiti celotne zgradbe in takoj preveriti, ali ima katera od izvedb napake ali je katera od delujočih funkcij pokvarjena.

Glede na to, kako bo QA zagotovil, da bodo osnovne funkcionalnosti dobro delovale?

Odgovor na to bo izvedba a Preskušanje dima .

Preskušanje dima

Ko so preskusi označeni kot preizkusi dima (v preskusnem paketu), QA sprejme šele nato gradnjo za poglobljeno testiranje in / ali regresijo. Če kateri od preskusov dima ne uspe, je gradnja zavrnjena, razvijalna skupina pa mora težavo odpraviti in sprostiti novo gradnjo.

Teoretično je preskus dima opredeljen kot preskušanje na površini, da se potrdi, da je zgradba, ki jo je razvojna skupina zagotovila ekipi QA, pripravljena na nadaljnje preskušanje. To testiranje opravi tudi razvojna skupina, preden gradijo ekipo QA.

To preskušanje se običajno uporablja pri integracijskem preskušanju, sistemskem preskusu in preizkusu ravni sprejemljivosti. Nikoli ne obravnavajte kot nadomestek dejanskega celotnega testiranja . Vsebuje tako pozitivne kot negativne teste, odvisno od izvedbe gradnje.

Primeri testiranja dima

To preskušanje se običajno uporablja za integracijo, sprejem in Testiranje sistema .

V svoji karieri QA sem vedno sprejel gradnjo šele potem, ko sem opravil dimni test. Torej, z nekaj primeri bomo razumeli, kaj je dimni test z vidika vseh teh treh testiranj.

# 1) Preskus sprejemljivosti

Vsakič, ko je gradnja sproščena za QA, preizkus dima v obliki Preskus sprejemljivosti je treba storiti.

V tem testu je prvi in ​​najpomembnejši dimni test preverjanje osnovne pričakovane funkcionalnosti izvedbe. Takole bi morali preveriti vse izvedbe za to določeno gradnjo.

Vzemimo naslednje primere kot izvedbe, izvedene v gradnji, da razumemo dimne teste za tiste:

  • Izvedla je funkcijo prijave, da je registriranim gonilnikom omogočila uspešno prijavo.
  • Izvedli smo funkcijo nadzorne plošče za prikaz poti, ki jih mora voznik danes izvesti.
  • Izvedena funkcionalnost za prikaz ustreznega sporočila, če za določen dan ne obstaja pot.

V zgornji gradnji bo na ravni sprejemljivosti test dima pomenil preverjanje, ali osnovne tri izvedbe dobro delujejo. Če je kateri od teh treh okvarjen, mora QA gradnjo zavrniti.

# 2) Integracijsko testiranje

To preskušanje se običajno opravi, ko so posamezni moduli uvedeni in preizkušeni. V Integracijsko preskušanje to testiranje se izvede, da se zagotovi, da vse osnovne integracijske in celovite funkcionalnosti delujejo v skladu s pričakovanji.

Lahko gre za integracijo dveh modulov ali vseh modulov skupaj, zato se bo kompleksnost dimnega testa razlikovala glede na stopnjo integracije.

Upoštevajmo naslednje primere izvedbe integracije za to testiranje:

  • Izvedena integracija modulov poti in postankov.
  • Izvedli smo integracijo posodobitve stanja prihoda in to prikazali na zaslonu postankov.
  • Izvedena integracija celotnega prevzema do modulov funkcionalnosti dostave.

V tej gradnji preskus dima ne bo le preveril teh treh osnovnih izvedb, ampak za tretjo izvedbo bo nekaj primerov preveril tudi popolno integracijo. Zelo pomaga pri odkrivanju vprašanj, ki se uvajajo pri integraciji, in tistih, ki jih razvojna skupina ni opazila.

# 3) Testiranje sistema

Kot že samo ime pove, testiranje dima na sistemski ravni vključuje preskuse najpomembnejših in najpogosteje uporabljenih delovnih tokov sistema. To se naredi šele, ko je celoten sistem pripravljen in preizkušen, in to testiranje na ravni sistema lahko imenujemo tudi testiranje dima pred regresijskim testiranjem.

Pred začetkom regresije celotnega sistema se v okviru preizkusa dima preskusijo osnovne značilnosti od konca do konca. Komplet za testiranje dima za celoten sistem obsega končne testne primere, ki jih bodo končni uporabniki uporabljali zelo pogosto.

Običajno se to naredi s pomočjo orodij za avtomatizacijo.

Pomen v metodologiji SCRUM

Dandanes projekti pri izvajanju projektov skorajda ne sledijo metodologiji Slap, večinoma vsi projekti sledijo Agile in SCRUM samo. V primerjavi s tradicionalno slapovsko metodo preizkušanje dima zelo pozdravlja SCRUM in Agile.

4 leta sem delal v SCRUM-u . In ker vemo, da so v SCRUM-u sprinti krajši, zato je izjemno pomembno, da opravite to testiranje, tako da lahko neuspešne gradnje takoj prijavite razvojni skupini in jih tudi popravite.

Sledi nekaj odvoz o pomembnosti tega testiranja v SCRUM-u:

  • Izven šprinta v štirinajstih dneh je polčas dodeljen QA, včasih pa se gradnje QA zavlečejo.
  • Pri sprintih je za ekipo najbolje, da se o težavah poroča v zgodnji fazi.
  • Vsaka zgodba ima niz kriterijev sprejemljivosti, zato je testiranje prvih 2-3 meril sprejemljivosti enako testiranju dimnosti te funkcionalnosti. Kupci zavrnejo dostavo, če ni izpolnjeno eno merilo.
  • Samo predstavljajte si, kaj se bo zgodilo, če vam bo razvojna skupina dostavila gradnjo v dveh dneh, za predstavitev pa ostanejo samo še trije dnevi in ​​naletite na osnovno okvaro funkcionalnosti.
  • V povprečju ima sprint zgodbe od 5 do 10, zato je pri gradnji pomembno zagotoviti, da je vsaka zgodba izvedena, kot je bilo pričakovano, preden jo sprejme v preizkušanje.
  • Ko je treba preizkusiti in regresirati celotni sistem, je aktivnosti namenjen šprint. Štirinajst dni morda malo manj za preizkus celotnega sistema, zato je zelo pomembno, da pred začetkom regresije preverimo najosnovnejše funkcionalnosti.

Preizkus dima proti preizkusu sprejemljivosti gradnje

Preizkušanje dima je neposredno povezano s preizkusi sprejemljivosti zgradb (BAT).

Pri BAT opravimo enako testiranje - da preverimo, ali gradnja ni uspela in ali sistem deluje dobro ali ne. Včasih se zgodi, da se pri izdelavi zgradbe uvedejo nekatere težave in ob dostavi zgradba ne deluje za QA.

Rekel bi, da je BAT del preverjanja dima, kajti če lahko sistem za preverjanje kakovosti sprejmete gradnjo za testiranje, če sistem odpove? Ne samo funkcionalnosti, tudi sam sistem mora delovati, preden QA nadaljuje s poglobljenim testiranjem.

Cikel preizkusa dima

Naslednji diagram poteka pojasnjuje cikel preskušanja dima.

Ko je gradnja uvedena v QA, sledi osnovni cikel, da če preizkus dima opravi, ekipa QA sprejme gradnjo v nadaljnje testiranje, če pa ne uspe, je gradnja zavrnjena, dokler se odpravljene težave ne odpravijo.

Preskusni cikel

Cikel preizkusa dima

Kdo naj opravi dimni test?

Kdo Ikona

V to vrsto testiranja ni vključena celotna ekipa, da bi se izognili izgubi časa vseh vprašanj kakovosti.

predloga poročila o izvedbi testa v

Testiranje dima v idealnem primeru izvede vodja QA, ki se na podlagi rezultata odloči, ali bo gradnjo posredoval ekipi za nadaljnje testiranje ali jo zavrnil. Ali v odsotnosti vodstva lahko QA sami opravijo to testiranje.

Včasih, ko je projekt obsežen, lahko skupina za preverjanje kakovosti opravi tudi to testiranje, da preveri, ali obstajajo prodajalci. Toda v primeru SCRUM-a ni tako, ker je SCRUM ravna struktura brez potencialnih strank ali voditeljev in vsak preizkuševalec ima svoje odgovornosti do svojih zgodb.

Zato posamezni nadzorniki kakovosti opravijo to testiranje za svoje zgodbe.

Zakaj bi morali avtomatizirati teste dima?

To testiranje je prvi test, ki ga je treba opraviti na gradnji, ki so jo izdale razvojne skupine. Na podlagi rezultatov tega testiranja se opravi nadaljnje testiranje (ali pa je gradnja zavrnjena).

Najboljši način za to testiranje je uporaba orodja za avtomatizacijo in načrtovanje zagona dimnega kompleta, ko se ustvari nova zgradba. Morda razmišljate, zakaj bi “Avtomatizirati paket za testiranje dima”?

Oglejmo si naslednji primer:

Recimo, da vas do izpusta čaka še en teden, in od skupaj 500 testnih primerov je v kompletu za testiranje dima 80–90. Če začnete izvajati vse te 80-90 testne primere ročno, si predstavljajte, koliko časa si boste vzeli? Mislim, da 4-5 dni (najmanj).

Če pa uporabljate avtomatizacijo in ustvarite skripte za zagon vseh teh 80-90 testnih primerov, bi bilo idealno, da se ti zaženejo v 2-3 urah in rezultate boste imeli takoj s seboj. Ali vam ni prihranil dragocenega časa in vam dal veliko manj časa glede vgradnje?

Pet let nazaj sem preizkušal aplikacijo za finančne projekcije, ki je vnašala podatke o vaši plači, prihrankih itd. In predvidevala vaše davke, prihranke in dobiček, odvisno od finančnih pravil. Skupaj s tem smo imeli prilagoditve za države, ki so odvisne od države in njenih davčnih pravil, ki so se nekoč spreminjale (v kodi).

Za ta projekt sem imel 800 testnih primerov in 250 testnih primerov dima. Z uporabo selena bi lahko zlahka avtomatizirali in v 3-4 urah dobili rezultate teh 250 testnih primerov. To nam ni samo prihranilo časa, ampak nam je čim prej pokazalo razstave.

Zato, razen če je nemogoče avtomatizirati, za to testiranje uporabite pomoč avtomatizacije.

Prednosti in slabosti

Najprej si oglejmo prednosti, saj lahko v primerjavi z nekaj pomanjkljivostmi ponuja veliko.

Prednosti:

  • Enostaven za izvedbo.
  • Zmanjša tveganje.
  • Napake so odkrite v zelo zgodnji fazi.
  • Prihrani trud, čas in denar.
  • Zažene se hitro, če je avtomatiziran.
  • Najmanj integracijskih tveganj in težav.
  • Izboljša splošno kakovost sistema.

Slabosti:

  • To preskušanje ni enako ali nadomestno za popolno funkcionalno preskušanje.
  • Tudi po opravljenem preskusu dima boste morda našli napake showstopper.
  • Ta vrsta testiranja je najprimernejša, če lahko avtomatizirate, saj se veliko časa porabi za ročno izvajanje testnih primerov, zlasti pri obsežnih projektih z okoli 700-800 testnimi primeri.

Testiranje dima je vsekakor treba opraviti pri vsaki gradnji, saj opozarja na večje okvare in prodajalce že v zgodnji fazi. To ne velja samo za nove funkcionalnosti, temveč tudi za integracijo modulov, odpravljanje težav in improvizacijo. Zelo preprost postopek je izvesti in doseči pravilen rezultat.

To preskušanje lahko obravnavamo kot vstopno točko za popolno funkcionalno preskušanje funkcionalnosti ali sistema (kot celote). Pred tem pa ekipa QA bi morala biti zelo jasna glede tega, katere teste je treba opraviti kot dimne teste . To testiranje lahko zmanjša napore, prihrani čas in izboljša kakovost sistema. V sprintih ima zelo pomembno mesto, saj je čas v sprintih manjši.

To testiranje je mogoče opraviti ročno in tudi s pomočjo orodij za avtomatizacijo. Toda najboljši in najprimernejši način je uporaba orodij za avtomatizacijo, s katerimi prihranite čas.

Razlika med preskušanjem dima in razuma

V večini primerov se zmedemo med pomenom preizkušanja razumnosti in preskušanja dima. Prvič, ti dve testiranji sta zelo dobri drugačen 'In se izvaja v različnih fazah preskusnega cikla.

S. Št.Preskušanje dima

Preverjanje razumnosti

1. Preizkušanje dima pomeni preveriti (osnovno), da izvedbe, izvedene v gradnji, dobro delujejo.Preizkušanje razumnosti pomeni, da na novo dodane funkcionalnosti, napake itd. Dobro delujejo.
dva To je prvo testiranje v začetni gradnji.Končano, ko je gradnja razmeroma stabilna.
3. Končano pri vsaki gradnji.Sestavljeno po stabilni gradnji po regresiji.

Sledi grafični prikaz njihovih razlik:

Preskušanje dima

PRESKUŠANJE DIMA

  • To preskušanje je nastalo v strojne opreme preizkus prakse prvega vklopa novega dela strojne opreme in ocene, da je uspešen, če se ne zažge in ne kadi. V industriji programske opreme je to preskušanje plitk in širok pristop, pri katerem se preizkušajo vsa področja uporabe, ne da bi se pregloboko preganjali.
  • Test dima je napisan po scenariju bodisi s pisnim sklopom testov bodisi z avtomatiziranim testom
  • Test dima je zasnovan tako, da se le delno dotakne vsakega dela aplikacije. Plitvo je in široko.
  • To testiranje se izvaja, da se zagotovi, ali najpomembnejše funkcije programa delujejo, vendar se ne ukvarja s podrobnejšimi podrobnostmi. (Na primer preverjanje gradnje).
  • To testiranje je običajen zdravstveni pregled do izdelave aplikacije, preden jo začnete poglabljati.

PRESKUŠANJE SANITETE

  • Preizkus zdravja je ozek regresijski test, ki se osredotoča na eno ali nekaj področij funkcionalnosti. Preverjanje razumnosti je običajno ozko in globoko.
  • Ta test je ponavadi nepisan.
  • Ta test se uporablja za ugotavljanje, da majhen del aplikacije po manjši spremembi še vedno deluje.
  • To testiranje je površinsko testiranje in se izvaja, kadar le površinsko testiranje zadošča, da dokaže, da aplikacija deluje v skladu s specifikacijami. Ta raven testiranja je podskupina regresijskega testiranja.
  • S tem se preveri, ali so zahteve izpolnjene ali ne, in se preverijo vse funkcije po širini.

Upam, da ste jasni glede razlik med tema dvema pomembnima in pomembnima vrstama testiranja programske opreme. Lahko delite svoje misli v spodnjem oddelku za komentarje !!

Priporočeno branje

^