- Testi i tymit në skedarin zhargon
Fondacioni Wikimedia. 2010.
Shihni se çfarë është "Testi i tymit" në fjalorë të tjerë:
testi i tymit- emër Një metodë testimi për rrjedhjet në gypat e kullimit ose oxhaqet duke futur tym të dendur, shpesh duke përdorur një bombë tymi Hyrja kryesore: duhan… Fjalor i dobishëm anglisht
testi i tymit- Testi i bërë për të përcaktuar plotësinë e djegies ... Fjalor i termave automobilistik
testi i tymit- 1.emër a) Një provë për rrjedhjet që përfshin fryrjen e tymit në një tub ose tub. b) Një provë paraprake në një pajisje elektronike të sapondërtuar, që konsiston thjesht në aplikimin e energjisë elektrike, për t'u siguruar që nuk ka instalime elektrike të jashtëzakonshme... Wiktionary
Testimi i tymit- është një term i përdorur në hidraulik, riparimin e erës së drurit, elektronikë, zhvillimin e softuerit kompjuterik, dhe industria e argëtimit. Ai i referohet testit të parë të bërë pas riparimeve ose montimit të parë për të siguruar njëfarë sigurie se sistemi në provë do të... Wikipedia
Testimi i tymit- bzw. Rauchtest ist ein Begriff aus dem English, gebräuchlich im handwerklichen Bereich (z. B. in der Klempnerei, Elektronik oder beim Bau von Holzblasinstrumenten) wie auch in der Softwareentwicklung. Es bezeichnet den ersten ... ... Deutsch Wikipedia
tymi- është koleksioni i grimcave dhe gazeve të ngurta dhe të lëngëta në ajër [SFPE Handbook of Fire Protection Engineering] emetuar kur një material i nënshtrohet ... ... Wikipedia
Komplet testimi- Në zhvillimin e softuerit, një grup testesh, më pak i njohur si një grup verifikimi, është një koleksion rastesh testimi që synohen të përdoren për të testuar një program softuerësh për të treguar se ai ka një grup sjelljesh të specifikuara. Një grup testesh shpesh…… Wikipedia
Bombë tymi- Një bombë tymi është një fishekzjarrë e krijuar për të prodhuar tym pas ndezjes. Ndërsa ka pajisje gjeneruese të tymit që hidhen nga aeroplanët, termi bombë tymi përdoret për të përshkruar tre llojet e pajisjeve: # Një top tymi është një zgavër, qershi... Wikipedia
Testimi i tymit dhe sanitarit fillon menjëherë pas publikimit të versionit të ardhshëm të projektit. Për shumë testues të rinj, ky proces duket si kaos absolut. E keni njohur veten? Atëherë ky artikull është për ju. Tani do të shikojmë përkufizimet e tymit dhe testimit sanitar dhe do të tregojmë ndryshimin midis të dyve duke përdorur shembuj të lehtë për t'u kuptuar.
Testimi i tymit:
Testimi i tymit bëhet për të siguruar që ndërtimi që rezulton është i përshtatshëm për testim. Quhet gjithashtu një kontroll i ditës zero.
Është ky lloj testimi që do t'ju pengojë të humbni kohë. Është logjike që testimi i të gjithë aplikacionit nuk ka kuptim nëse ka probleme me të karakteristikat kryesore dhe gabimet kritike nuk janë rregulluar.
Testimi sanitar:
Testimi sanitar kryhet në fazën e lëshimit për të testuar funksionalitetin kryesor të aplikacionit. Zakonisht nuk shkojnë më tej. Ky testim nganjëherë referohet si një version i shkurtuar i testimit të regresionit.
Kur afati i lëshimit është i ngushtë, është pothuajse e pamundur të kryhet testimi rigoroz i regresionit. Në këtë rast, testimi sanitar bën një punë të shkëlqyer, i cili kontrollon funksionimin e funksioneve kryesore të aplikacionit.
Një shembull për të kuptuar më mirë ndryshimin midis tymit dhe testimit sanitar:
Ekziston një projekt për të cilin është planifikuar një lëshim fillestar. Ekipi i zhvillimit lëshon ndërtimin për testim, ekipi i testimit fillon të punojë. Testimi i parë është testimi i fitnesit. Duhet të zbuloni nëse mund të punoni me këtë version apo jo. Ky është testimi i tymit. Nëse ekipi jep miratimin për punë të mëtejshme me ndërtimin, ai dërgohet në faza më të thella të testimit. Le të imagjinojmë që ndërtimi ka tre module: "Hyrja", "Admin" dhe "Punonjës". Ekipi i testimit kontrollon performancën vetëm të funksioneve bazë të secilit prej moduleve, pa u futur thellë në kontrollimin e detajeve. Ky do të jetë testim sanitar.
Disa ndryshime të tjera midis tymit dhe testimit sanitar:
- Testimi i tymit kryhet nga zhvilluesit dhe testuesit;
- Testimi sanitar kryhet vetëm nga testues.
- Testimi i tymit mbulon të gjithë funksionalitetin kryesor të aplikacionit nga fillimi në fund;
- Testimi sanitar teston vetëm një komponent specifik të një aplikacioni.
- Testimi i tymit po kalon ndërtime të qëndrueshme dhe të paqëndrueshme;
- Një ndërtim relativisht i qëndrueshëm po i nënshtrohet testimit sanitar.
Kirill Flyagin, Projektuesi i Lojërave, Drejtues i QA
Le të bëjmë një analogji verore me këto lloj testimesh. Le të themi se dëshironi të blini një shalqi. Testimi i tymit është kur e kontrolloni vizualisht, shikoni shiritat, shtrydhni, trokitni, vlerësoni. Ka mjeshtra që arrijnë të blejnë një kokrra të kuqe vërtet të shijshme në këtë mënyrë. Në testimin sanitar, ju preni një piramidë në krye dhe kontrolloni ngjyrën e saj (si një nga komponentët) pa e ditur fare nëse i gjithë shalqiri është i njëjtë. Por ju jeni plotësisht të sigurt për pjesën e prerë.
Pasi të keni bërë ndryshimet e nevojshme, të tilla si rregullimi i një defekti / defekti, software duhet të ri-testohet për të konfirmuar që problemi është zgjidhur në të vërtetë. Më poshtë janë llojet e testimit që duhet të kryhen pas instalimit të softuerit për të konfirmuar funksionalitetin e aplikacionit ose korrektësinë e korrigjimit të defektit të kryer:
- Testimi i tymit(Testimi i tymit)
- Testimi i regresionit(Testimi i regresionit)
- Testimi i ndërtimit(Testi i verifikimit të ndërtimit)
- Testimi sanitar ose kontrolli i konsistencës / funksionalitetit(Testimi i shëndetit të shëndoshë)
Koncepti testimi i tymit ardhur nga mjedisi inxhinierik. Kur pajisjet e reja ("hardware") u vunë në punë, konsiderohej se testimi ishte i suksesshëm nëse nuk dilte tym nga instalimi. Në fushën e testimit të softuerit, synohet të kontrollojë sipërfaqësisht të gjitha modulet e aplikacionit për funksionueshmërinë dhe praninë e defekteve kritike dhe bllokuese të gjetura shpejt. Në bazë të rezultateve të testimit të tymit, konstatohet nëse pranohet apo jo. versioni i instaluar softuer për testim, funksionim ose dorëzim te klienti. Për të lehtësuar punën, për të kursyer kohë dhe burime njerëzore, rekomandohet zbatimi i automatizimit të rasteve të testimit për testimin e tymit.
Testimi i regresionitËshtë një lloj testimi që synon të kontrollojë ndryshimet e bëra në aplikacion ose mjedisi(rregullimi i defektit, bashkimi i kodeve, migrimi në një tjetër sistemi operativ, baza e të dhënave, serveri i uebit ose serveri i aplikacionit) për të konfirmuar që funksionaliteti para-ekzistues funksionon si më parë (shih gjithashtu Testimin Sanitar ose Konsistencën / Kontrollin Shëndetësor). Regresioni mund të jetë si më poshtë funksionale, dhe kështu jofunksionale testet.
Si rregull, për testimin e regresionit, rastet e testimit shkruhen në fazat e hershme zhvillimin dhe testimin. Kjo siguron që ndryshimet në version i ri aplikacionet nuk janë dëmtuar tashmë funksionalitetin ekzistues... Rekomandohet automatizimi i testeve të regresionit për të shpejtuar procesin e mëpasshëm të testimit dhe për të zbuluar defektet në fazat e hershme të zhvillimit të softuerit.
Vetë termi "test i regresionit", në varësi të kontekstit të përdorimit, mund të ketë kuptime të ndryshme. Sam Kaner, për shembull, përshkroi 3 lloje kryesore testimi i regresionit:
- Regresioni i gabimeve- një përpjekje për të vërtetuar se një gabim i rregulluar nuk është rregulluar në të vërtetë.
- Regresioni i gabimeve të vjetra- një përpjekje për të vërtetuar se një ndryshim i fundit në kod ose të dhëna ka thyer korrigjimin e gabimeve të vjetra, d.m.th. defektet e vjetra filluan të luanin përsëri.
- Regresioni efekte anesore(Regresioni i efekteve anësore)- një përpjekje për të vërtetuar se një ndryshim i fundit në kod ose të dhëna ka thyer pjesë të tjera të aplikacionit në zhvillim.
Testimi i shëndetit të shëndoshë ose testimi i shëndetit të shëndoshë - ky është testim shumë i synuar, i mjaftueshëm për të vërtetuar se një veçori e veçantë funksionon siç thuhet në specifikim. Është një nëngrup i testimit të regresionit. Përdoret për të përcaktuar shëndetin e një pjese të caktuar të aplikacionit pas ndryshimeve të bëra në të ose në mjedis. Zakonisht bëhet me dorë.
Dallimi midis testimit sanitar dhe testimit të tymit. Disa burime gabimisht besojnë se testimi sanitar dhe tymi janë e njëjta gjë. Ne besojmë se këto lloje të testimit kanë "vektorë lëvizjeje", drejtime në anët e ndryshme... Ndryshe nga testimi i tymit, testimi i shëndetit drejtohet thellë në funksionin që testohet, ndërsa testimi i tymit drejtohet në gjerësi për të mbuluar sa më shumë funksionalitet të jetë e mundur në kohën më të shkurtër të mundshme.
Testimi i ndërtimit(Build Verification Test) është testimi që synon të përcaktojë nëse versioni i lëshuar plotëson kriteret e cilësisë për fillimin e testimit. Për nga qëllimi i tij, ai është analog me Testimin e Tymit, që synon pranimin e një versioni të ri për testim ose funksionim të mëtejshëm. Mund të depërtojë më thellë, në varësi të kërkesave të cilësisë së versionit të lëshuar.
Testimi i instalimit - që synon verifikimin e instalimit dhe konfigurimit të suksesshëm, si dhe përditësimin ose heqjen e softuerit. Aktualisht, instalimi më i zakonshëm i softuerit përdoret instaluesit(programe të veçanta që vetë kërkojnë gjithashtu testim të duhur). Në kushte reale, mund të mos ketë instalues. Në këtë rast, do t'ju duhet të instaloni në mënyrë të pavarur softuerin, duke përdorur dokumentacionin në formën e udhëzimeve ose skedarëve readme, duke përshkruar hap pas hapi të gjithë hapat dhe kontrollet e nevojshme. Në sistemet e shpërndara, ku aplikacioni është vendosur në një mjedis tashmë funksional, një grup i thjeshtë udhëzimesh mund të mos jetë i mjaftueshëm. Për këtë, shpesh, shkruhet një Plan vendosjeje, i cili përfshin jo vetëm hapat për instalimin e aplikacionit, por edhe hapat për të rikthyer në versionin e mëparshëm, në rast dështimi. Vetë plani i instalimit duhet të kalojë gjithashtu një procedurë testimi për të shmangur problemet kur vihet në funksionim real. Kjo është veçanërisht e vërtetë nëse instalimi kryhet në sisteme ku çdo minutë ndërprerjeje është një humbje e reputacionit dhe një sasi e madhe fondesh, për shembull: banka, kompani financiare apo edhe rrjete banerash. Prandaj, testimi i instalimit mund të quhet një nga detyrat më të rëndësishme në sigurimin e cilësisë së softuerit.
Pikërisht si kjo Një qasje komplekse me shkrimin e planeve, verifikimin hap pas hapi të instalimit dhe rikthimin e instalimit, me të drejtë mund të quhet testimi i instalimit ose Testimi i instalimit.
Nëse dëshironi të krijoni një të thjeshtë program kompjuterik i cili përbëhet nga një skedar, ju vetëm duhet të grumbulloni dhe lidhni të gjithë kodin që shkruani në këtë skedar. Në fakt projekt i rregullt që ekipi i zhvillimit po punon, ka qindra, madje mijëra skedarë. Kjo "kontribuon" në faktin se procesi i krijimit të një programi të ekzekutueshëm bëhet më kompleks dhe kërkon kohë: ju duhet të "montoni" programin nga komponentë të ndryshëm.
Praktika e përdorur, për shembull, në Microsoft dhe disa kompani të tjera të zhvillimit të softuerit, është montimi (ndërtimi) i përditshëm i programit, i cili plotësohet nga testimi i tymit. Çdo ditë, pasi çdo skedar është mbledhur (rindërtuar, ndërtuar), lidhur (lidhur) dhe kombinuar në një program të ekzekutueshëm, vetë programi i nënshtrohet një grupi mjaft të thjeshtë testesh, qëllimi i të cilave është të shihet nëse programi " pi duhan” gjatë punës. Këto teste quhen tym (nga anglishtja smoke - smoke). Më shpesh sesa jo, ky proces është mjaft mirë i automatizuar (ose duhet të jetë).
PËRFITIMET. Ky proces i thjeshtë ofron disa përfitime të rëndësishme.
Minimizimi i rrezikut gjatë integrimit
Një nga rreziqet më të rëndësishme me të cilat përballet ekipi i zhvillimit është se vetë zhvilluesit punojnë me kodin veçmas, në mënyrë të pavarur nga njëri-tjetri, si rezultat i të cilit një program kompleks nuk funksionon siç pritej gjatë ndërtimit të kodit të krijuar. Në varësi të kohës kur u gjet papajtueshmëria në projekt, korrigjimi i programit mund të zgjasë më shumë sesa me integrimin e mëparshëm, veçanërisht nëse ndërfaqja e programit ndryshohet ose pas zbatimit të ndryshimeve të mëdha në pjesët kryesore të programit.
Montimi dhe ekzekutimi i përditshëm i testeve të tymit bën të mundur reduktimin e rrezikut të gabimeve të integrimit, përgjigjen në kohë dhe parandalimin e grumbullimit të tyre.
Reduktimi i rrezikut të produktit softuerik me cilësi të ulët
Cilësia e dobët e produktit varet drejtpërdrejt nga dështimet dhe problemet gjatë integrimit. Kryerja e një grupi minimal të testeve të tymit çdo ditë nuk lejon që defektet dhe problemet të fitojnë epërsinë në projekt. Nëse e keni sjellë projektin në një gjendje të qëndrueshme një herë, ai do të mbetet gjithmonë i qëndrueshëm. Duke bërë këtë, ju kurrë nuk do të lejoni që cilësia të degradohet deri në pikën ku ndodhin gabime.
Ndihmoni në diagnostikimin e gabimeve
Nëse një ditë produkti nuk është mbledhur (i mbledhur me gabime), atëherë me ndihmën e montimit të përditshëm dhe kryerjen e një grupi testesh tymi, është shumë më e lehtë të gjesh shkakun e problemit. Një produkt që funksionon dje dhe nuk funksionon sot është një aluzion i qartë se diçka nuk shkoi mirë midis dy ndërtimeve.
Përmirësimi i moralit
Nëse një produkt funksionon dhe çdo ditë fiton gjithnjë e më shumë cilësi dhe funksione të reja, morali i zhvilluesve, në teori, duhet të rritet dhe nuk ka fare rëndësi se çfarë duhet të bëjë saktësisht ky produkt. Është gjithmonë e këndshme për zhvilluesin të shikojë "fëmijën e trurit" të tij të punës, edhe nëse produkti shfaq një drejtkëndësh :)
Përdorimi i testeve të përditshme të ndërtimit dhe tymit
Këtu janë disa detaje të këtij parimi.
Ndërtimi i aplikacionit çdo ditë
Një pjesë themelore e asamblesë ditore është montimi i pjesës së fundit. Jim McCarthy në Dynamics of Software Development (Microsoft Press, 1995) e quajti ndërtimin e përditshëm të projektit rrahjet e tij të zemrës. Nëse nuk ka rrahje zemre, nuk ka projekt, ai ka vdekur. Më pak në mënyrë figurative, ndërtimi i përditshëm është përshkruar nga Michael Cusumano dhe Richard W. Selby si pulsi i sinkronizimit të projektit (Microsoft Secrets, The Free Press, 1995). Secili zhvillues shkruan kodin në mënyrën e tij dhe ai, kodi, mund të shkojë përtej kornizës së pranuar përgjithësisht për projektin - kjo është normale, por sa herë që zbatohet pulsi i orës, kodi kthehet në standard. Duke këmbëngulur për të zhvilluar me një puls sinkronizimi gjatë gjithë kohës, ju parandaloni që projekti të mos sinkronizohet plotësisht.
Në disa kompani, është zakon të mblidhni një projekt jo çdo ditë, por një herë në javë. Ky sistem është i gabuar sepse në rast të një "prishjeje" të projektit këtë javë, mund të duhen edhe disa javë para ndërtimit të ardhshëm të suksesshëm. Në këtë rast, kompania humbet të gjitha përfitimet e sistemit ditor të ndërtimit të projektit.
Po kontrollon për një ndërtim të dështuar
Në rastin e një ndërtimi ditor të projektit, supozohet se projekti duhet të funksionojë. Megjithatë, nëse projekti nuk funksionon, atëherë rregullimi i tij bëhet një detyrë me prioritet 1.
Çdo projekt ka standardin e vet dhe një shenjë të asaj që quhet "dështimi i montimit". Ky standard duhet të specifikojë një nivel cilësie që është i mjaftueshëm për të gjurmuar defektet e vogla dhe për të mos anashkaluar defektet që "bllokojnë" projektin.
Një ndërtim i mirë është ai që të paktën:
- të gjithë skedarët, bibliotekat dhe komponentët e tjerë janë përpiluar me sukses;
- lidhjet me të gjithë skedarët, bibliotekat dhe komponentët e tjerë janë të vlefshme;
- nuk përmban asnjë sistem të qëndrueshëm, duke përjashtuar mundësinë punë korrekte gabime në bllokimin e programit të aplikacionit;
- kalojnë të gjitha testet e tymit.
Testet e përditshme të tymit
Testet e tymit duhet të kryhen në të gjithë projektin nga fillimi në fund. Ato nuk kanë nevojë të jenë shteruese dhe gjithëpërfshirëse, por duhet të përfshijnë një kontroll mbi të gjitha funksionet kryesore. Testimi i tymit duhet të jetë mjaft i thellë në mënyrë që, nëse është i suksesshëm, projekti mund të quhet i qëndrueshëm dhe të quhet i tillë që t'i nënshtrohet testimit më të thellë.
Kuptimi i ndërtimit të përditshëm humbet pa testimin e tymit. Ky proces ruan cilësinë e produktit dhe nuk lejon asnjë problem integrimi. Pa këtë, procesi i përditshëm i ndërtimit është një humbje kohe, qëllimi i të cilit është kontrollimi i përpilimit.
Testimi i tymit duhet të zhvillohet në përputhje me projektin. Në fillim, testet e tymit do të kontrollojnë për diçka të thjeshtë, si p.sh. nëse projekti mund të lëshojë një mesazh "Hello, World!". Ndërsa sistemi evoluon, testet e tymit bëhen më të thelluara. Koha e shpenzuar në testet e para të tymit llogaritet në disa sekonda, por ndërsa sistemi rritet, rritet edhe sasia e kohës që kërkohet për testimin e tymit. Në fund të një projekti, testimi i tymit mund të zgjasë disa orë.
Përcaktimi i një grupi asambleje
Në shumicën e projekteve, ekziston një person specifik përgjegjës për kontrollin e ndërtimit të përditshëm të sistemit dhe kryerjen e testeve të tymit. Kjo punë është pjesë e detyrave të këtij punonjësi, por në projekte të mëdha mund të ketë më shumë punonjës të tillë dhe një punë e tillë është përgjegjësia e tyre kryesore. Për shembull, ishin katër persona në ekipin e ndërtimit për një projekt Windows NT 3.0 (Pascal Zachary, Treguesi!, Shtypi i Lirë, 1994).
Shto rishikim në montim vetëm nëse ka kuptim
Në mënyrë tipike, zhvilluesit individualë shkruajnë kodin mjaft ngadalë, saqë ndryshimet domethënëse mund të shtohen në sistem në baza ditore. Ata duhet të punojnë në shumicën e kodit dhe ta integrojnë atë në sistem çdo disa ditë.
|
Futja e një sistemi ndëshkimesh për ndërprerjen e lëshimit të ndërtimit të ardhshëm (lëshimi i një ndërtimi që nuk funksionon). |
Shumica e projekteve kanë një sistem ndëshkimesh për ndërprerjen e lëshimit të ndërtimit të ardhshëm. Në fillim të një projekti, ia vlen të bëhet e qartë se mbajtja e një projekti pune është prioriteti më i lartë. Dështimi për të lëshuar ndërtimin e ardhshëm mund të jetë një përjashtim, por jo një rregull. Këmbëngulni që zhvilluesit të lënë gjithçka derisa sistemi të funksionojë përsëri. Në rast të dështimeve të shpeshta të ndërtimit (lëshimi i një ndërtimi që nuk funksionon), mund të jetë e vështirë të rikthehet projekti në rrugën e duhur.
Theksojnë gjobat e vogla shkallë të lartë nevoja për të monitoruar cilësinë e ndërtimit të sistemit. Në disa projekte, zhvilluesve që janë përgjegjës për përplasjen e montimit u jepen shufra për të lëshuar një asamble të prishur. Një shenjë përkatëse varet në derën e zyrës së një zhvilluesi të tillë derisa ai të rregullojë montimin (me kusht që zhvilluesit të kenë zyra të veçanta :)). Në projekte të tjera, zhvilluesit fajtorë duhet të veshin brirë dhie artificiale ose të kontribuojnë një shumë të caktuar në "fondin moral" (shembuj janë marrë nga historia e kompanive reale).
Por për disa projekte janë vendosur dënime më të rënda. Për shembull, zhvilluesit e Microsoft-it në projekte me prioritet të lartë (Windows NT, Windows 95, Excel) mbanin pager dhe, nëse gjendej një kontroll, ata duhej të paraqiteshin në punë. Edhe nëse një avari ose gabim u zbulua në orën 3 të mëngjesit.
Montoni sistemin dhe "tymosni" atë edhe nën presion
Kur presioni i orarit të lëshimit të një projekti rritet, puna për të kontrolluar sistemin e ndërtuar çdo ditë mund të duket si humbje kohe. Megjithatë, nuk është kështu. V situata stresuese zhvilluesit shpesh bëjnë gabime. Ata ndjejnë një presion të tillë për të lëshuar implementime, gjë që në kushte normale thjesht nuk ekziston. Ata kontrollojnë kodin e tyre me testet e njësisë me shumë më pak kujdes sesa bëjnë zakonisht. Në situata të tilla, kodi tenton në një gjendje entropie shumë më shpejt sesa në situata më pak stresuese.
Kush përfiton nga ky proces? Disa zhvillues po protestojnë kundër ndërtimeve të përditshme, duke i justifikuar protestat e tyre si jopraktike dhe kërkojnë kohë. Por të gjitha sisteme komplekse kohët e fundit iu nënshtruan montimeve të përditshme dhe testeve të tymit. Në kohën e lëshimit të tij, Microsoft Windows NT 3.0 përmbante 5.6 milionë rreshta në 40,000 skedarë. Ndërtimi i plotë zgjati 19 orë dhe funksionoi në shumë kompjuterë. Përkundër kësaj, zhvilluesit arritën të montonin sistemin në baza ditore. Si një ekip profesionist, ekipi i zhvillimit të NT i detyrohet shumë suksesit të tij ndërtimit të përditshëm. Zhvilluesit që punojnë në projekte më pak komplekse dhe, për rrjedhojë, nuk përfitojnë nga procesi i përditshëm i ndërtimit, duhet të mendojnë për të gjetur një shpjegim të arsyeshëm.
Gabimet e thjeshta mund të jenë fatale për faqen tuaj - veçanërisht nëse jeni një kompani SaaS (eng. Software as a Service) si ne. Nëse një përdorues viziton faqen tuaj dhe nuk mund të përballojë një detyrë të thjeshtë, siç është regjistrimi ose rivendosja e tij fjalëkalimi i harruar, Ju rrezikoni ta humbni këtë përdorues përgjithmonë.
Ne e kemi përjetuar këtë në mënyrën e vështirë. Sigurisht, të kesh njerëzit e tu në ekip që teston aplikacionin dhe kërkon gabime është e rëndësishme, por jo gjithmonë e përshtatshme ose jo mjaftueshëm e plotë. Në këtë artikull, ne duam t'ju prezantojmë, shkencat humane, testet e botës së tymit.
Nëse keni ende pyetje, mund t'i plotësoni boshllëqet duke vizituar
Testimi i tymit fillimisht u shpik për të shpjeguar se si inxhinierët elektrikë kontrolluan nëse pajisja e tyre po funksiononte - ata e ndezën atë dhe nëse kishte tym ...
Prisni, si mund të zbatohet kjo për aplikacionet?
Rëndësia (dhe kosto-efektiviteti) i testeve të tymit është përgjithësisht i panjohur për menaxherët dhe bashkëthemeluesit humanitar. Testet sistematike të tymit mund të konsiderohen si një pjesë integrale e parandalimit të rritjes së gjasave për t'u hakuar. Ato minimizojnë gjasat që aplikacioni juaj i uebit ose i telefonit të prishet - dhe siç e dimë të gjithë, vetëm një dështim dhe ju mund të humbni një klient përgjithmonë.
Ky është një udhëzues hyrës se çfarë është, si mund të zbatohet, çfarë burimesh përdoren për ta kryer atë dhe shembuj për të udhëhequr lexuesit.
Testet e tymit janë krijuar për të testuar funksionalitetin bazë dhe duhet të jenë pjesë përbërëse e procesit tuaj të testimit. Ato mund të përfshijnë diçka kaq të thjeshtë si "A mund të regjistrohem?"
Testimi i tymit ndihmon për të siguruar që asnjë nga dështimet kryesore dhe të dukshme nuk i lihet rastësisë. Ju nuk duhet të bëni një test më të thellë derisa të keni teste 100% të tymit, sepse ato pastrojnë softuerin nga defektet themelore.
Hapi 1: Vendosni se çfarë të testoni
Përcaktoni se çfarë synon të arrijë aplikacioni juaj. Cilat janë hapat më të dukshëm "fëminorë" që duhen për t'u futur në të? Cilat janë kërkesat minimale jetike dhe në çfarë sekuence logjike do t'i renditnit ato?
Krijo një grup testimi. Një grup testesh është një koleksion i grupuar i rasteve testuese (rastet e testimit) të lidhura në një mënyrë të caktuar (për shembull, sipas funksionalitetit).
Testimi i tymit nuk do të përfshijë variabla ose pyetje "po sikur?". Ai supozon vetëm përgjigje po/jo, por përpara se të vazhdohet me testimin më të detajuar, të gjitha rastet e testimit duhet të kalojnë me një rezultat pozitiv.
Le të marrim si shembull krijimin e një forumi interaktiv. Që të funksionojë, më duhet:
- regjistroheni.
- krijoni emrin e përdoruesit.
- ngarkoni një foto në foton e profilit tuaj.
- shkruani mesazhe.
- përgjigjuni mesazheve.
Hapi 2: Shkrimi i rezultateve në një tabelë
Imazhi i mësipërm është një shembull nga ekipi ynë. Mund ta gjeni shabllonin. Kjo është e nevojshme për të mbajtur një shënim se çfarë funksionon për ne dhe çfarë jo - organizimi bazë do të kursejë shumë kohë në të ardhmen. Ne i kemi ndarë rezultatet tona në kalim, të pjesshëm dhe të dështuar.
- E përfunduar: Gjithçka po funksionon në mënyrë perfekte.
- Pjesërisht: fillimisht, mund të mos e kuptoni se disa veprime mund të ndahen ende, dhe për këtë arsye një pjesë funksionon dhe tjetra jo.
- Dështoi: Nuk funksionon.
Ne përshkruam hapat e saktë që donim të riprodhonim, dhe më pas, në kolonën tjetër, shtuam një përshkrim të shkurtër të asaj që presim në dalje. Shembull:
Hapi 3: automatizimi i testeve të tymit
Është shumë e rëndësishme të mos merret si aksiomë që nëse ndonjë veprim është kryer një herë, ai gjithmonë do të jetë me një rezultat pozitiv. Testet e tymit ju lejojnë të verifikoni vazhdimisht që funksionaliteti bazë nuk është dëmtuar me kalimin e kohës ose nuk është prishur për një periudhë të gjatë.
Mos e ndaloni testimin e tymit. kurrë.
Kur kompleti juaj i testit të tymit përfundon me një rezultat të suksesshëm për 100%, mendoni për automatizimin e tyre. Frekuenca e rekomanduar e testeve të tymit është çdo ditë nëse kompania juaj po zhvillohet çdo ditë.
Kërkesa minimale është kryerja e testeve të tymit para çdo lëshimi dhe pas çdo copëze.
Një rregull i përgjithshëm për një test tymi:
- Koha minimale: 30 minuta.
- Koha maksimale: 60 minuta.
V perspektivë të mëtejshme Automatizimi i testeve të tymit kursen kohë, por kryerja e të njëjtave teste pa pushim mund të bëjë që syri i njeriut të mos vërejë detaje, por makina mund të mos vërejë.